[Marble-devel] Re: altitude profiles

[Niko Sams]

On Mon, Sep 27, 2010 at 01:22, Torsten Rahn <torsten.rahn at basyskom.de> wrote:
> Hi Niko,
>
>> And who would run the server that
>> serves the tiles?
>
> Server space is no issue: Just get in touch with dirk at kde.org (Dirk Müller,
> our KDE Sysadmin).
>
> We can use kde.org servers for providing tiles - at least as long as it's
> about Gigabytes of data.
ok, I thought that might be not that easy.

> In fact we do this already for the base imagery (satellite view, srtm, etc).
where can I find the code for that?

> Also especially for base data we want full control over the servers. I'm not
> keen on the idea of downloading stuff from NASA servers where the data
> suddenly disappears or gets moved elsewhere and we can do nothing about it.
yeah, that is true of course.

>> The original SRTM data is in tile files with 1° resolution, with a
>> filesize of max 2MB
>> each tile (in my area).
>
> 2 MB is unfortunately too big: Think about:
>
> * it takes about a minute to download a 2MB file on an average 3G/GPRS
> connection. That is unacceptable.
> * We also want to run Marble on phones/tablets/embedded devices.
> * There should be an efficient way to apply the SRTM data to the imagery tiles
> (e.g. as surface meshes or via a blending filter for the stacked tiles)
> * Ideally we'd reuse our own code for managing the chunks of data that are
> kept in memory (how would this work with the 2MB tiles?).
Ok, i see your point.

>
>> There exists even C++ code for directly
>> reading those files.
>
> That's nice. But I rather see the advantage of that in being able to
> preprocess the data so that it fits our requirements.
>
> Marble is also a Qt library. Code that is integrated with Marble should also
> get evaluated based on design and API considerations :-)
My only reason for directly using the existing files it just that I
don't have to
think about a new format. Could you give me some hints on where to
find examples how this could be implemented...

> Hope this all doesn't sound too negative ;-) But I just want to avoid that
> Marble becomes slow inefficient patchwork code ....
Of course not, that's why I started this brainstorming.

Niko