Zero-area changeset
Opened this issue · 2 comments
A changeset that only touches a node without moving it can have min_lat=max_lat and min_lon=max_lon.
These are currently encoded as polygons, but zero-area polygons are very hard to make normally. e.g. this SQL doesn't work on those changesets
UPDATE osm_changeset_40m
SET geom = ST_SetSRID(ST_Makebox2d(ST_MakePoint(min_lon, min_lat), ST_MakePoint(max_lon, max_lat)),4326)::geometry(Polygon,4326)
WHERE geom IS NULL;;
Would it be better to have these as points and change the geometry constraint to geometry(Geometry,4326)
?
And for those (quite improbable, but still) where one coordinate is equal? These should be a line, then?
I never saw this issue as a problem. The way I see it, your query fails because ST_Makebox2d
returns a BOX2D
which is a different data type from geometry
. Instead of casting, you could just build a geometry straight off, e.g.
select st_astext(st_setsrid(st_makeenvelope(0, 0, 0, 0),4326))
which gives you POLYGON((0 0,0 0,0 0,0 0,0 0))
I personally don't like mixed geometries, so I'm OK with storing everything with polygon geometries, and filtering these cases with st_isvalid
, which will obviously be false
for those cases you mention. If for some reason I ever need the point (or line) representation of these changesets, I can always use st_makevalid
to get those point geometries.
BTW, from the wiki, this is how API_v06 behaves so I'm not even sure if we should see 1 dimension bounding boxes. (I don't currently have a changeset dump imported so can't check).
As an optimisation the server will create a buffer slightly larger than the objects to avoid having to update the bounding box too often. Thus a changeset may have a different bounding box than its reversion, and the distance between bounding box and the next node may not be constant for all four directions.