[Marble-devel] altitude profiles

[Torsten Rahn]

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. 
In fact we do this already for the base imagery (satellite view, srtm, etc). 
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.

Am Sonntag, 26. September 2010 22:53:08 schrieb Niko Sams:
> > You mean a float item? Or a Dialog? Maybe you can make the code generic
> > enough so that it can be used for both.
> I was thinking of a float item.

Cool, if you keep the code modular then application authors can also reuse it 
for displaying it in a widget. 
Ideally there would also be some dedicated API in libmarblewidget to query the 
elevation for some geodetic coordinates.
 
> I would like to have the best possible resolution.

Yes, me too.
 
> 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?).

> 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 :-)

> Imho option 1. should work for us.

Option 1 is against Marble's philosophy as detailed in the Manifesto.


Hope this all doesn't sound too negative ;-) But I just want to avoid that 
Marble becomes slow inefficient patchwork code ....

Best Regards,

Torsten
 

-- 
Torsten Rahn
Senior Consultant

basysKom GmbH
Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany
Tel: +49 6151 3969-961 | Fax: -736|
torsten.rahn at basyskom.de | www.basyskom.de

Handelsregister: Darmstadt HRB 9352
Geschaeftsfuehrung: Eva Brucherseifer