Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

way_area might get zero when using 4326 #3121

Open
openstreetmap-trac opened this issue Jul 23, 2021 · 2 comments
Open

way_area might get zero when using 4326 #3121

openstreetmap-trac opened this issue Jul 23, 2021 · 2 comments

Comments

@openstreetmap-trac
Copy link

Reporter: TobWen
[Submitted to the original trac issue database at 2.49pm, Wednesday, 14th July 2010]

When using projection 4326 on osm2pgsql import, way_area might get zero if it's too small. This can mess up sorting.

Possible solutions:

  1. multiplicate with 10.000 (or anything big),
  2. calculate way_area using 900913,
  3. calculate way_area on psql

Remarks:

  1. is a bad workaround,
  2. is hard to implent, since GEOS uses already projected coordinates,
  3. is somehow slow and uses triggers
@openstreetmap-trac
Copy link
Author

Author: Ldp
[Added to the original trac issue at 9.04pm, Wednesday, 14th July 2010]

I'd prefer if way_area was consistently correct, independent of the projection. If we start making more rendering decisions based on polygon size, it needs to make the same decisions for both 900913 and 4326.

@openstreetmap-trac
Copy link
Author

Author: TobWen
[Added to the original trac issue at 9.14pm, Wednesday, 14th July 2010]

I've done some calculations directly using spheroid geometry (geodetic on WGS84). It's valid all over the globe, even on very big polygons. The problem is the area is built up by GEOS when the coordinates are projected already. So I never can grab the original coordinates calculate the geodetic area ;-(

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant