Hi, On 13.07.2012 19:27, Paweł Paprota wrote:
What is the current consensus within OSM dev community on this aspect of OSM architecture?
Historically, the OSM API was meant to be (very) little more than an SQL database with a spatial index and history. It was placed at a very, very low level, without any understanding about the data - just taking it and storing it.
Later, some - very few - consistency checks were added, i.e. the database now makes sure that you do not reference an object that doesn't exist, or delete an object that is still "in use".
Until today, the database has no concept of what a multipolygon is, or whether one-node ways or consecutive identical nodes in a way make sense; and it doesn't even begin to look at tags.
There are good reasons for this, most notably the flexibility to do even "unexpected" things, but also the avoidance of complexity. The server processes thounsands of updates in one minute, and it has enough work to do as it is, making sure that all of the 879 members of your relation actually still exist. Some checks sound easy enough but when you look closely they might actually require loading and inspecting lots of other objects (think of a route relation where you would like to make sure it is contiguous - requires loading all member ways and comparing end nodes!). And some checks sound sensible enough but then suddenly someone invents a use case where, say, a one-node way suddenly makes sense.
It is an issue that is worth debating - what aspects of data integrity should the server attempt to guarantee - but is is *certainly* not as easy as "let's just take JOSM's validator checks and implement them server-side". (Not least because these checks are too zealous for that.)
Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
