Opened 9 years ago
Last modified 5 years ago
#3121 new defect
way_area might get zero when using 4326
Reported by: | TobWen | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | osm2pgsql | Version: | |
Keywords: | Cc: |
Description
When using projection 4326 on osm2pgsql import, way_area might get zero if it's too small. This can mess up sorting.
Possible solutions:
- multiplicate with 10.000 (or anything big),
- calculate way_area using 900913,
- calculate way_area on psql
Remarks:
- is a bad workaround,
- is hard to implent, since GEOS uses already projected coordinates,
- is somehow slow and uses triggers
Change History (4)
comment:1 Changed 9 years ago by
comment:2 Changed 9 years ago by
Owner: | changed from jburgess to jburgess777@… |
---|
comment:3 Changed 9 years ago by
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 ;-(
comment:4 Changed 5 years ago by
Component: | mapnik → osm2pgsql |
---|
Note: See
TracTickets for help on using
tickets.
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.