[postgis-devel] Geodetic issues
pramsey at opengeo.org
Thu Sep 1 12:26:44 PDT 2011
On Thu, Sep 1, 2011 at 11:37 AM, Chris Hodgson <chodgson at refractions.net> wrote:
> Paul, I think these questions are primarily for you - in light of a few
> recent bug reports, I'm trying to figure out what is going in in geography
> land (I apologize for being blissfully ignorant of much of the work done so
> - Is it illegal to have a point on the poles? From ptarray_check_geodetic()
> in /liblwgeom/lwgeodetic.c
> if ( pt.x < -180.0 || pt.y < -90.0 || pt.x > 180.0 || pt.y > 90.0 ) return
> It seems kind wierd that it is ok to have a polygon the circumnavigates the
> pole, but not a point on the pole?
It is weird, and I cannot access my last year self to figure out WTF I
was thinking doing strict less-than rather than less-than-equals. I
think it's just going to have to change.
> Are pretty big hacks that have no hope for any kind of polar-encircling data
> or other globe-wrapping data like for example satellite swaths? And really
Yes, they are localized hacks, *however* it is worth checking the
_Best_SRID code to understand where the failures are. For polar
proximity/crossing and even dateline crossing, things will work fine
(appropriate local projections will be chosen). The hacks fall apart
not when things are in the wrong place, but when they are the wrong
size: too big and there is no good local projection to auto-choose.
> the only way around these issues, which also could end up addressing
> everything from isvalid to union is to write a geodetic-aware equivalent to
> GEOS (or make JTS/GEOS "geodetic aware")?
Yes, the "long term" would be to move to full geodetic support in a
lower library, or to continue with the liblwgeom geodetics.
> Are there any plans for moving
> forward with something like that? I recognize there would be a large amount
> of work involved (probably more than writing JTS or GEOS as is, for planar
> geometries?). Is this the direction we would want to go? Or am I wrong and
> these aren't big hacks but are "the way to do it" and just need further
> tweaking to handle the ugly cases?
No, you're right. The hacks as currently conceived will always have
some kinds of issues with them. There are two ways forward though. One
is to actually do constructive geometry in spherical space, and David
Skea has said he's continuing to work on this stuff (in his Abundant
Spare Time). The other is to recognize that it's possible to do
constructive geometry in planar space for each local operation on a
spherical object, and then back project the results when complete. So
an approach would be to move the hack to a lower level of the
algorithm and then deal with the corner cases. Which would probably be
best done at the GEOS level.
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
More information about the postgis-devel