Geometry Boost List: [ggl] projections

Subject: [ggl] projections
From: Barend Gehrels (Barend.Gehrels)
Date: 2009-05-17 07:36:42

Hi,

>>>>> [Barend: ] The projection functions forward/inverse return true/false ...
>>>>>
>>>>>         
>>> [Barend: ] should they raise an exception here? It is
>>> here different than in WKT. The point might be not in reach of the 
>>> projection. That is not really "exceptional", it just can happen.
>>> Should it then raise an exception? It is not really an error.
>>> However, propagating true/false is also not that nice. So what will
>>> we do here... We've to think about this carefully.
>>>     
>>
>> [Mateusz: ] IMHO, it depends on how the point-out-of-proj is considered in
>> terms of the state of program/engine.
>> If the result is still usable, though not accurate, then exception is too "strong" option.
>>   
> [Barend: ] OK, this accurateness is a good idea! I was thinking about 
> that further. Each projected point has an "accurateness". (Usually) 
> the center of a projection will have a high accurateness. At points on 
> "the border" the accurateness will be very low. So that information 
> should be returned somehow. I was first thinking of a scale from 0 to 
> 1, but the actually distance (deviation, in meters) of the projected 
> point seems more appropriate and better measurable. So let's say we 
> have Mercator and project the city Lima. It's near the equator so the 
> distance between the center (in this case the equator above Lima) and 
> measured via the projection vs measured via the Earth ellipsoid is not 
> much. Then let's say we project the city Godth?b, in Greenland, 
> well-known for its bad display on most maps. The deviation in meters 
> between the equator below, and Godth?b, will often be very large. We 
> can return that deviation. One problem though, calculating deviation 
> increases calculation time... Though the (currently used, not 
> well-known) Andoyer-distance is not too slow.
>
> Performance penalty could be solved by introducing "laziness". 
> Projecting a point results in a "projection structure". Like the 
> "distance_struct' for cartesian distances. It returns immediately, 
> having done nearly nothing. As soon as converted to a point, it does 
> the actual projection. If the "deviation()" method, or double() 
> conversion, or so is called, it calculates the deviation. OK, if the 
> user still wants to have both, the performance decreases then. But if 
> he wants only the projection, the performance is the same as it was... 
> He then can also request deviation only, and if it is not too bad get 
> the projected point as well.
>

There are more things about projections related to this.

1) We can project (transform) points but also linestrings and polygons, 
etc. If a polygon (e.g. Russia) is projected and some points are 
accepted (currently return true) but other points are not (currently 
return false), then the "transform" function on the whole geometry 
returns false. However, that is not the ideal behaviour.
See e.g. 
http://geometrylibrary.geodan.nl/structprojection_1_1aeqd__ellipsoid.html 
where Russia is not displayed.

It would be much better if Russia was partly displayed there. So the 
correct behaviour might be:
- the projection functions return true/false, as it is now
- the projection-transform-strategy (for non-points) evaluates the 
project-return-value and connects all successfully projected points, and 
returns true (unless nothing is projected)
- for points it might still raise an exception and/or give some 
indication of accurateness

There will then be straight lines which might not be straight in the 
source geometry. This can be solved by transform again, by the following 
behaviour (which was actually already planned):
- transformation of a segment will be done iteratively: transforming 
both endpoints, transforming the midpoint. If the midpoint is NOT upon 
the transformed segment, it will be added and the procedure will be 
repeated, until the midpoint is (more or less) on the transformed segment.
This will create curved lines from straight lines in projections or 
transformations from spherical-to-cartesian. Hartmut mentioned that it 
should also be the other way round, so going from a cuved line to a 
straight line might imply that some (unnecessary) points are omitted. 
This is in fact a sort of simplify, but in another contect.

This "creating curved lines" will have the right effect in the image of 
the URL above, Russia will be partly depicted, having a curved line at 
the border of the projection. Didn't implement or try this yet but this 
is the expectation.

2) This will not solve all problems. Linestrings or polygons might be 
"split" by the projection, a country might be displayed partly left and 
partly right. If this is the case, the points may not be connected. 
Separate linestrings/polygons have to be built. This asks for another 
output of the transform: either an output-iterator, or a multi-geometry 
(this is also the case in intersections).
However, it might be difficult to determine if a segment is connected or 
splitted. We need information on the "separation info" of a projection. 
This is often the international date line, but can also be something 
completely different, and there might be more than one.
E.g. 
http://geometrylibrary.geodan.nl/structprojection_1_1bipc__spheroid.html 
where some graticule lines are connected, while it had been better if 
they had stopped there.

Point 1 might solve this problem (projecting a midpoint on a segment 
will return false, and therefore those segments should not be connected) 
but I'm not sure if this is always the case, it probably depends on how 
the specific projection algorithm is implemented.

3) Looking to 
http://geometrylibrary.geodan.nl/structprojection_1_1aeqd__ellipsoid.html 
again, it is clear that there is more that is not valid. Australia and 
New Zealand are displayed but are actually on the other side of the 
globe, in this view. The projection algorithm (here Azimuthal 
Equidistant) should actually return false in these cases, I think. It 
might be solved (see point 4) but that is not sure. Otherwise we should 
dive into these cases.

4) I based the projections on proj4. proj4 is based on the work of 
Gerald Evenden, then of the USGS. I recently saw that Gerald has created 
a new branch/revival, "libproj4". This library has the same structure 
(macro's etc) and it will not require much adaptions to the conversion. 
libproj4 is actively developed now by the expert and contains more 
projections. It might be a better starting point then proj4.
http://home.comcast.net/~gevenden56/geodesy/project/
The license seems to allow these things, as in proj4

Regards, Barend

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20090517/dd5e4314/attachment.html