[Marble-devel] Review Request: Default range normalization of GeoDataCoordinates

[Bernhard Beschow]

> On May 22, 2012, 10:50 a.m., Bernhard Beschow wrote:
> > I wonder if it is a good idea to "fix" wrong usage of our API because "fixing" introduces the potential of surprises. I'd expect the API to return garbage if I pass garbage (garbage-in-garbage-out principle) rather than having it perform arbitrary changes in the background. After all, fixing usually depends on the context and in addition, there are more efficient methods to ensure intended behavior of corner cases such as unit tests.
> > 
> > Moreover, I don't like the flags approach which adds even more complexity to our API. In particular, it'll be hard to predict the behavior of instances of GeoDataCoordinates ("does the instance normalize or not?"). I think that a isNormalized() method, perhaps in conjunction with Q_ASSERT(), could catch wrong usage of our API and will not add additional complexity.
> 
> Torsten Rahn wrote:
>     We think about adding this patch since there have been multiple people who had passed longitudes from 0 to 360 degrees to Marble (and therefore bumped into misrenderings). Actually there is nothing bad about it: On planets like Venus the [0;360] interval is even common standard (http://www2.jpl.nasa.gov/magellan/guide3.html). Also it's quite natural to expect that a method that takes angles as a parameter performs well even if for multiples of PI/180° (sine, cosine, tan ... which also happily take values like 3 * M_PI). 
>     So this kind of input is far from "garbage". It seems to be common practice for some, so we shouldn't harass people and annoy them with unnecessary asserts if they just want to display their data.
>     So personally I think that for all cases where the intention is clear (e.g. 54°N, 200°E) we should do the conversion automatically. We should not unnecessarily harass people to change their habits there. For cases where the input seems to be ambigious or unusual (e.g. 120°N, 20°E) a Q_ASSERT() might be a reasonable practice.
>     I also don't think that flags are bad as long as they have a merit and as long as they are not necessary for the usual default use cases.

I totally agree that our API should allow for passing multiples of PI/180°. So where is the point of automatically normalizing the values behind the scene? Doesn't that introduce unexpected behavior? And why is it not sufficient to use Q_ASSERT( foo.isNormalized() ) in unusual cases?


- Bernhard


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104990/#review14035
-----------------------------------------------------------


On May 19, 2012, 9:15 a.m., Dennis Nienhüser wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104990/
> -----------------------------------------------------------
> 
> (Updated May 19, 2012, 9:15 a.m.)
> 
> 
> Review request for Marble.
> 
> 
> Description
> -------
> 
> We don't officially support non-normalized coordinates (lon outside -180...180 degree, lat outside -90..90 degree). To avoid potential pitfalls when developers using Marble as a library ignore that, it might make sense to normalize coordinates behind the scenes. The patch adds that for GeoDataCoordinates, which should cover most cases. It's controlled by a flag (using QFlags for future extensibility) which defaults to normalization.
> 
> 
> Diffs
> -----
> 
>   src/lib/geodata/data/GeoDataCoordinates.h 8929430 
>   src/lib/geodata/data/GeoDataCoordinates.cpp c1563a6 
>   src/lib/geodata/data/GeoDataCoordinates_p.h 14c5164 
> 
> Diff: http://git.reviewboard.kde.org/r/104990/diff/
> 
> 
> Testing
> -------
> 
> The major concern should be performance.
> 
> Loading a long route (2500 km, 35.000 coordinates), the performance was pretty much identical (~200 ms) for several runs with and without normalization
> 
> The startup time for parsing the various files at startup increases slighty from around 1200 ms on my system to around 1300 ms. We might reduce this difference when we remove now unnecessary calls to normalizeLonLat e.g. in GeoDataLatLonBox::fromString. It could even lead to performance improvements later on.
> 
> A callgrind log measuring the start, initialization and shutdown of Marble shows that 0.07% of the time (110.000 calls) was spent in normalizeLonLat(). From that 50.000 calls could be spared when removing the normalization in GeoDataLatLonBox::fromString. In summary, the runtime overhead seems to be small.
> 
> 
> Thanks,
> 
> Dennis Nienhüser
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/marble-devel/attachments/20120522/deb289c5/attachment.html>