@joto commented on this pull request.
I have two problems with this:
a) Everything working with tiles in osm2pgsql assumes 3857 and we don't
guarantee that it works with anything else. Presumably you have tested this in
your case, but I think we still need to figure out what the guarantees of
osm2pgsql are here and we should have tests to make sure we keep those
guarantees.
b) It is not obvious that the implementation here is correct for all cases. We
could have several geometries with different SRIDs for instance (although I
have never seen that). Or no `extent` is set for the raster columns (which is
currently the case in a database I have on hand here). It all hinges on obscure
settings in the `raster_columns` and `geometry_columns` views and the behaviour
of the `ST_EstimatedExtent()` function.
I am not saying this is wrong, I am just not sure we are understanding all the
ramifications well enough. And maybe we can improve the implementation. We can
run more than one query for instance, first getting the SRID then doing
something else or so. That might make this more readable than putting
everything into the one query. And it would give us the chance of generating
better warning/error messages.
> schema, table, column);
} else {
result = db_connection.exec(
+ "WITH srid AS ("
+ " SELECT ST_SRID({}) AS srid FROM {} LIMIT 1"
The column and table name should be quoted.
`ST_SRID("{}") AS srid FROM "{}" LIMIT 1`
--
Reply to this email directly or view it on GitHub:
https://github.com/osm2pgsql-dev/osm2pgsql/pull/2498#pullrequestreview-5168535860
You are receiving this because you are subscribed to this thread.
Message ID: <osm2pgsql-dev/osm2pgsql/pull/2498/review/[email protected]>_______________________________________________
Tile-serving mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/tile-serving
