[postgis-users] Why should these boxes intersect?

pcreso at pcreso.com pcreso at pcreso.com
Thu Jul 12 12:17:01 PDT 2012


Coming from New Zealand, near 180, I think it is fair to say that a geometry with 
left lon > right lon is not wrong. Just that Postgis fails to interpret such correctly.

A polygon such as POLYGON((179 -45,181 -45,181 -46,179 -46,179 -45))
is obviously crossing the dateline, and is geographically identical to 
POLYGON((179 -45,-179 -45,-179 -46,179 -46,179,-45))

However it is not interpreted as such.This is not a problem unique to Postgis, and the casting of geometries to geographies, and vice versa for some geography functions, means that in Postgis, the geography datatype is still not a complete solution.

It is a topological as well as a geometric problem. Polygons crossing 180 need to be split/merged, not just "moved".

See the map of a mercator projection covering New Zealand here:
http://www.spatialreference.org/ref/epsg/3994/


(& if anyone knows who to contact to get the proj4txt values for this projection added to the web site, please let me know)

Cheers,

  Brent Wood


--- On Fri, 7/13/12, Sandro Santilli <strk at keybit.net> wrote:

From: Sandro Santilli <strk at keybit.net>
Subject: Re: [postgis-users] Why should these boxes intersect?
To: "PostGIS Users Discussion" <postgis-users at postgis.refractions.net>
Cc: "DrYSG" <ygutfreund at draper.com>
Date: Friday, July 13, 2012, 3:14 AM

Yechezkal, the reason why your solution isn't taken is because
it assumes that the geometry is expressed in long/lat.
This isn't always the case.
The semantic of units, and thus the value of the anti-meridian
(if any) depends on the spatial reference system.

The GEOGRAPHY type was introduced specifically for this: add knowledge
about the earth shape.

In GEOMETRY semantic, a box with minx > maxx would be just wrong.
We choose to swap rather than throw an exception. Such choice could
be debatable.

--strk;

  ,------o-. 
  |   __/  |    Delivering high quality PostGIS 2.1
  |  / 2.1 |    http://strk.keybit.net - http://vizzuality.com
  `-o------'


On Thu, Jul 12, 2012 at 07:55:27AM -0700, DrYSG wrote:
> Thank you Paul,
> 
> You certainly are the expert, and I have learned a great deal from you
> posts, as well as the PostGIS book which sits on my desk with
> your introduction.
> 
> So I will hope you will excuse the chutzpah, but to me it feels like
> something is broken, and I don't think it is that hard to fix.
> 
> What do you think about this as an improvement to ST_intersects:
> 
> 1. Implement a "pre-pass" check for polygons that span the anti-meridian
> (180 longitude) (e.g. intersect with anti-meridian)
> 2. If there is intersection:
>     a. Split the polygon into shards by the anti-meridian
>     b. perform normal ST_Intersects of the shards against the other polygon (or
> shards)
>     c. Boolean AND the results
>     d. use short-circuit logic if any intersection results in false
> 3. If no intersection proceed as normal
> 
> Notes: 
> 
> 1. I say something feels broken because I sense it in your article & there
> is no clue in the documentation about this.
> 2. The test #1 can be very low overhead (just checking if the all longitudes
> are positive, all negative or mixed (and short circuiting if there are any
> mixed which would indicate a span of the anti-meridian)
> 3. The case where there is a span of the anti-meridian will be rare (who has
> that much data in the pacific?)
> 4. Yes, the code for handling the shards is not very elegant, but that
> branch would not often be taken
> 5. Note that my geometry column of the database is GIST indexed and the
> Boston rectangle is still picking up the one in the pacific, so the bounding
> box optimization for indexed search seems to be not working so well.
> 6. ST_Within might have this same issue, but the same fix should work for it
> (symmetry is wonderful!). 
> 
> The reason I do not want to go to GEOGRAPHY types is that my application is
> using using a view-box (of a map) as the search box
> against a 20 Million record database of map objects (images, features, etc.)
> that are all represented as by rectangular bounding
> boxes. The PostGIS notes talk a lot about he overheard of GEOGRAPHY types,
> and it is overkill in this case. All I want to know
> is what is in the view-box - and rough estimates will work for that.
> 
> - Yechezkal
> 
> --
> View this message in context: http://postgis.17.n6.nabble.com/Why-should-these-boxes-intersect-tp4998895p4998924.html
> Sent from the PostGIS - User mailing list archive at Nabble.com.
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20120712/87224be0/attachment.html>


More information about the postgis-users mailing list