[OSM-dev] Server-side data validation

[Paweł Paprota]

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 frederik at remote.org  ##  N49°00'09" E008°23'33"
> 
> 
> 
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev