simplified water polygons and ST_GeoHash()

[imagico]

running get-external-data.py i get:

Traceback (most recent call last):
  File "./get-external-data.py", line 225, in <module>
    main()
  File "./get-external-data.py", line 219, in main
    this_table.index()
  File "./get-external-data.py", line 81, in index
    '''.format(name=self._name, temp_schema=self._temp_schema))
psycopg2.InternalError: Geohash requires inputs in decimal degrees, got (-180 -85.0511, -180 -85).

This is due to the code using ST_GeoHash() for indexing and clustering which requires transforming coordinates back into geographic which the simplified water polygons are not suited for - see gravitystorm/openstreetmap-carto#2101 which is essentially due to the same problem.

You can work around this by clipping the data before or after the import into PostGIS but generally using ST_GeoHash() in this context for proximity ordering of geometries is a bad idea - because map rendering should not depend on transforming coordinates into geographic, in particular transforming a bounding box in projected coordinates into geographic cannot generally be expected to produce a meaningful geometry. And even if that is not a problem (unmodified OSM data, rendering in Mercator) ST_GeoHash() is not a good solution for this problem - see:

https://en.wikipedia.org/wiki/Geohash#Limitations_when_used_for_deciding_proximity

Using what ST_GeoHash() does but in projected coordinates (which PostGIS does not allow at the moment) would probably be a suitable generic method.

Yes, this is probably outside the scope here but wanted to mention it none the less.

[pnorman]

I wonder why you're hitting that error but I'm not.

I'm using GeoHash for ordering, not modifying a geometry and saving the modified geometry. A GeoHash ordering does significantly better than a way ordering, or clustering on a gist index on geom.

[pnorman]

What does SELECT postgis_full_version(); report, and can you still reproduce this?