[OSM-dev] Multipolygon processing (was: osm2spatialite!)
Frederik Ramm
frederik at remote.org
Fri Feb 18 15:23:59 GMT 2011
Hi,
On 02/18/11 14:56, Jukka Rahkonen wrote:
>>> Once you have found a perfect solution, how about placing it somewhere
>>> in front of the OSM database instead?
[...]
>> No, for several reasons. One of them is purely technical
> I was thinking about the same. What are the other reasons? One that comes
> into my mind is a Simple Feature wise invalid case where the inner ring is
> touching outer ring in two or more points. Do we need other (multi)polygon
> types which are invalid by the restricting simple feature rules?
One is the case where we allow multiple touching inner rings. It isn't
allowed in OGC SF because it makes little sense (why not have ONE big
inner ring then), but we allow it because the inner rings might have a
"life of their own" by virtue of extra tags.
But generally, the OSM database is really not intended to make any
decisions about whether or not the objects you store in it make sense;
rejecting objects on the basis that they don't is something we very
rarely do (checks have been built in over time for one-noded ways, for
example, but you may have ways that go from node A to node A). It is
meant to be really low-level, just a thin layer on top of SQL.
Also, such checks would bring with them stricter ordering constraints
for uploads. E.g. if the API were to check for the validity of a
multipolygon and you were to move a node so that the polygon is invalid,
but at the same time you remove the node from the polygon - then the
editor would have to take care to first transmit the polygon edit and
then the node edit. But what if, in the same session, you have added
another node to the polygon (making it temporarily invalid) but then
moving the node so that it became valid again - then the editor would
have to send one of the node edits first, then the polygon edit, and
then the other node edit... and so on!
Bye
Frederik
More information about the dev
mailing list