[Marble-devel] [Patch] fix access to local maps

[Torsten Rahn]

On Saturday 12 April 2008 23:22:08 Jens-Michael Hoffmann wrote:
> Am Samstag, 12. April 2008 20:44:39 schrieb Torsten Rahn:
> > Be aware though that "MapTheme" is soon to be replaced by the new
> > MapThemeManager class (and support from our new DGML2 parser).
>
> Thanks for the hint, I was just starting to refactor MapTheme a little bit.
>
>  I would like to improve the support for OpenStreetMap, so this is where
> I'm working at the moment.

Hi Jens-Michael,

Sounds great.

Please have a look at our "design documents" in marble/docs to find out what 
our current refactoring is working towards. - Any suggestions and input is 
appreciated of course.

What approach did you have in mind?

There are several possible approaches: And we'd like to support solution A1 or 
A2 in the short term (for KDE 4.1) and solution B1.) in the mid term future 
(somewhen after KDE 4.1).

A) Texture tile 

A1.) Create your own tile set for Marble - This would probably deliver the 
highest quality (as you'd create tiles in Equirectangular projection as 
opposed to the Mercator projection that OSM is using).  But it would require 
you to render your own tiles (KDE would very likely provide server space for 
that however). 
Ideally Marble would be extended to deal with transparent overlay texture 
tiles to be able to render the OSM data on top of other map themes. For this 
we should extend the MergedLayerPainter (soon: "MergedLayerDecorator") class 
(which is currently being refactored by David Roberts I guess).

A2.) Reuse the tileset that OSM is publically offering: This would require to 
introduce an interface for alternative TileLoader classes. The tile loader 
for OSM would need to "translate" the lat/lon position requested into OSM 
tile positions and would download the tiles needed and would possibly need to 
get reprojected (depending on which approach would be taken in detail).

B) Polygon / Vector rendering

As a GSoC project it has been suggested that similar to the texture tiles that 
get downloaded we'd create "vector tiles" which contain the polygons needed 
to draw the vector data on the fly. This is a lot more complex than approach 
A and will require some larger refactoring. We are currently in the planning 
stage for this one. There are two possible methods:

B1.) (re-)render the data live onto the widget for each frame that gets 
displayed.

B2.) render the data onto the texture tiles. This would require the data to 
only get drawn onto the tiles once.

Given that texture tile are Marble's most obvious performance bottleneck and 
given that approach B1.) would give us better render quality, speed and more 
flexibility (in terms of being able to select objects) we'd like to go for 
approach B1.)

Any input? Suggestions? :-)

Best Wishes,

Torsten


> Bye
>
> Jens-Michael
> _______________________________________________
> Marble-devel mailing list
> Marble-devel at kde.org
> https://mail.kde.org/mailman/listinfo/marble-devel



-- 
 Torsten Rahn

 Tel.: 0 21 61 - 46 43 - 192

credativ GmbH, HRB Mönchengladbach 12080
Hohenzollernstr. 133, 41061 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz