[Tile-serving] [openstreetmap/osm2pgsql] Set projection in flex output in column config (#1277)

[mboeringa]

@joto,

Nice to see work continuing on osm2pgsql. However, I am slightly confused by this particular pull request, and have a couple of questions and remarks:

- Personally, i think there is little sense in setting an individual projection on each geometry column of every table created. I doubt if there are many people who would desire to have a mixed projection database, unless you foresee demand from people running a dual projection database e.g. latlong 4326 + Web Mercator 3857. Technically, with this pull request, one would be able with flex output to output the same (or different) content in two different tables with different projection in during import session / run of osm2pgsql, something which is clearly impossible in the current osm2pgsql. However, I think this is an edge case, especially considering many users are already complaining about lack of disk space with the ever growing OSM data, and most users will simply choose between either 4326 or 3857 (of course the option output any projection is still highly desirable for country extracts).

- As to area calculation, I would suggest to calculate geodesic area instead of Web Mercator. We all know the severe limitations of Web Mercator in terms of accurate areas and lengths. I actually implemented that for my own renderer in custom Python code, and it works well with PostGIS. I probably don't have to tell you, but it requires something like this:

If the data is in 4326:
`ST_Area(way::geography,<spheroid_option: True/False>)`

If the data is in any other projection:
`ST_Area(ST_Transform(way,4326)::geography,<spheroid_option: True/False>)`

By the way, _I ran into an issue with the spheroid option_, that I think may have been, or is a current bug, in PostGIS: if setting the spheroid option to **False**, thus using a faster **sphere** based calculation, I experienced crashes with data near the international date line. When I switched to **True** to use a **spheroid**, sacrificing some speed but getting more accurate results, the issue went away. I haven't been able to delve deeper into this, but suspect it to be a bug and not a data issue considering the spheroid option works.

- Extending on this, and looking at some the code comments, you write:

" in web mercator, or you can set the `projection` parameter of the column to `4326` to calculate it with WGS84 coordinates."

What exactly do you mean "with WGS84 coordinates". I guess you mean just using the lat/long values "as-is", calculating some quite meaningless value? Or something else, like the geodesic area I suggested?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/osm2pgsql/pull/1277#issuecomment-702278766
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tile-serving/attachments/20201001/10003069/attachment.htm>