ST_DumpPoints may return latitude just over 90 depending on execution order

[realityexists]

Windows 7 x64, PostgreSQL 9.2.1, PostGIS r10557

I've run into a weird problem, apparently with ST_DumpPoints. I have a function which "normalises" geometries to ensure that their coordinates are within the -180/+180 and -90/+90 range, so they can be cast to geography. On PostgreSQL 9.1.4 this worked fine. When I upgraded to 9.2.1 it began to return incorrect results, translating some latitudes of 90 to -90, but not consistently. It appears that ST_DumpPoints sometimes returns points with latitude just over 90 (somewhere between 90.000000000000001 and 90.0000000000001), which caused my function to translate them to -90. Whether it returns these "90+" points seems to depend on several things:

1) The order in which geometries are evaluated. 2) Whether I attempt to cast the geometry to geography beforehand. 3) PostgreSQL version.

The attached repro contains two polygons and the function is run on the exterior ring of each. If it's done for "ULMM" first, then "PAZA" the results are correct (no 90+ latitudes), but if "ULMM" is processed second then the 90+ latitudes occur - but only on PostgreSQL 9.2, not 9.1. If you comment out the cast to geography then they occur regardless of order and PostgreSQL version.

While there's an easy workaround, I'm still concerned that these "just out of range" latitudes may cause other problems down the track. I would expect ST_DumpPoints to never return such values or, if the problem is with the input data, at least return them consistently.

[pramsey]

Can you check again in the context of #799 and #310 having gone in?

[realityexists]

I can't test it on Windows at the moment due to #2094, but on Linux the problem doesn't occur on r10680 and it did before - that's promising. The problem doesn't occur even when using the old functions (from r10237), so it's probably #799 that fixed it rather than #310.

#799 seems to be the built-in version of my function anyway, which is great - very happy to see that.

[realityexists]

OK, tested on Windows 7 x64, r10691, PostgreSQL 9.2.1. The original problem no longer occurs, but this:

SELECT ST_AsText(ST_SnapToGrid(ST_Transform(ST_GeomFromText('POINT(180 50)', 4269), 4326), 0.00001)::geography)

returns POINT(-180 50) instead of POINT(180 50) as it used to. Note that if you remove the cast to geography it still returns "POINT(180 50)". I suspect it's something similar to the original problem with the longitude being "just over" 180.

I think the behaviour of ST_AsText and other string-returning functions should be consistent with ::geography, ie. if the value is close enough to 180 for ST_AsText to display it as "180" then it's also close enough for ::geography to convert it to 180, not -180. Anything else just gets really confusing.

[pramsey]

I dunno, it's supposedly caught in the normalization. r10732

[realityexists]

Tried the query above, it still returns exactly the same thing on r10734. By the way, the problem occurs both ways: substituting "POINT(-180 50)" returns "POINT(180 50)".

[pramsey]

Simpler yet:

select ST_AsText(ST_SnapToGrid(ST_GeomFromText('POINT(180 50)'), 0.00001)::geography);

[realityexists]

Still happens as of r11092 (on 32-bit Linux). Would be really nice to get this fixed as it's forcing us to run an old version (r10557) which doesn't have this problem.

[realityexists]

OK, I've tracked it down to changeset r10670 and realised it's a regression of #1292. So I've reopened that to track this issue and will retest the original issue in this ticket once that one is fixed.

[realityexists]

Retested at r11113 and it seems to be fine.