[OSM-dev] Multipolygon processing (was: osm2spatialite!)

[Frederik Ramm]

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