[OSM-dev] Server-side data validation
ppawel at fastmail.fm
Fri Jul 13 19:25:30 BST 2012
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
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
On Fri, Jul 13, 2012, at 20:11, Frederik Ramm wrote:
> 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.)
> Frederik Ramm ## eMail frederik at remote.org ## N49°00'09" E008°23'33"
> dev mailing list
> dev at openstreetmap.org
More information about the dev