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 _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
