ST_DumpPoints may return latitude just over 90 depending on execution order
|Reported by:||realityexists||Owned by:||pramsey|
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.