Hi Frederik, Thanks for the response. I realize that I have oversimplified with writing about transferring JOSM validators to the server-side - not to throw big words around but I have some years of experience as software architect and worked with systems not unlike OSM so even that I am not expert on OSM, I can see problems with adding another layer to the OSM server.
I am not trying to argue with the core principles (the lightweight tagging model etc.) of OSM - I am just trying to get an idea what will happen if I do something with that topic - piece of design of piece of code, whatever. Is it going to be considered or are you set on doing things one way and I should rather think about writing my own piece of software that runs on OSM data? This discussion is similar to my question about usability improvements... another big topic that I am trying to wrap my head around - what is the current status, who to talk to etc. So please excuse any oversimplifications and maybe some over eagerness on my side - but I want to help with some, for now I just don't know where to start :-) Paweł On Fri, Jul 13, 2012, at 20:11, Frederik Ramm wrote: > 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 [email protected] ## N49°00'09" E008°23'33" > > > > _______________________________________________ > dev mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/dev _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
