# Geometry :

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

Geometry list run by mateusz at loskot.net