[Marble-devel] Problems with projections

Torsten Rahn torsten.rahn at credativ.de
Sat Feb 16 12:25:44 CET 2008


Hi,

As already announced in previous mails we are about to refactor Marble's 
architecture a bit to take into account plugins and lots of other new 
exciting stuff.

Currently Inge is working on introducing Projection classes. He has just 
refactored Marble Widget to get split into MarbleWidget and Marble Map to 
allow maps that either don't require a widget (e.g. for plasmoids or maps 
that are meant for printing). Now Inge is refactoring our ViewParams class 
(which as an object is owned by MarbleMap). This will mostly lead to having 
three pointers in ViewParams which control large areas of the view:

1.) AbstractProjection* currentProjection  ( contains: projection settings and 
conversion methods )
2.) ViewportParams* viewportParams  ( contains: QSize of the viewport, zoom, 
focus )
3.) MapTheme* currentMapTheme (contains: map properties like "bool 
hasCities", "bool showCities" and all the other stuff that is specific to the 
current map)

Concerning projections: I've just realized that while we have conversion 
methods between screen and geocoordinates which return error states we don't 
deal with all kinds of scenarios in other places.

E.g. for the Mercator projection we have the special case where the 
northern/southern pole is located in +/-infinity. Therefore we limit the 
visible share of the projection to a latitude range of [ - atan( sinh( 
M_PI ); + atan( sinh( M_PI ) ) ]  .
So for the projection class we need to introduce upper and lower limit 
properties for latitude and longitude. 
I suggest that we also add boolean return values for MarbleMap::rotateTo, 
rotateBy and zoomBy / zoomView which indicate whether the desired rotation is 
valid or not. The question is how we deal with these situations appropriately 
especially taking into account "switching the projection" while centering on 
a place that is invalid to show on the target projection (e.g. the 
North/South Pole). 
Should we support these invalid coordinates internally in the "planet 
orientation model" and should we just mark on the view that the desired place 
is not viewable with the current projection.
Or should we do everything in our inputHandlers not to get any invalid 
coordinates stored by the "planet orientation model"?

I think the first solution is the way to go given that for placemarks we store 
coordinates that are invalid as well in some projections already. But I feel 
that adding error return values would still be something we need to add to 
inform the application that the action that the app is about to ask from the 
widget is not  possible.

We also need a good way to tell the user in terms of userface that the current 
selection can't get shown on the selected map (currently we just move to the 
most extreme latitude and stay there).

Torsten



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


More information about the Marble-devel mailing list