Zero-area changeset

[pnorman]

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)?

[RicoElectrico]

And for those (quite improbable, but still) where one coordinate is equal? These should be a line, then?

[jlevente]

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.