[OSM-talk] Xml design

[Dave]

On 1/9/07, SteveC <steve at asklater.com> wrote:
>
> * @ 07/01/07 12:21:01 PM scott at waye.co.uk wrote:
> > Some thoughts:
> >
> > With the current XML design of k="" v="" it would seem very difficult to
> > create a useful XSD for the data.  A tight XSD would help to avoid
> > duplication,spelling mistakes, reduce the xml size, and would allow for
> > the gui to present useful drop downs.  For example we currently have
>
> My concern is that if someone wants to invent a tag they just type it
> in, but if we're going to validate then they now have to get involved in
> comittees and standards processes.
>
> Is a good midpoint to have OSM as it currently is, and a processor which
> spits out 'map features compatible' .osm files?
>
> Already the renderers in general ignore broken spellings which has
> helped point out things I've done wrong to me. Is it just this feedback
> loop is a bit weak for bad data?


I'm not sure validation is really the best way to achieve what people are
after. I think what's really needed is a better abstraction from the data
model.

The problems being addressed in this thread seem to boil down to several
points:
1) There's data being put into the database with spelling mistakes in the
tags
2) People aren't sure what to tag things as and would like some help from
their editor
3) Some data is not entered correctly for a particular use to easily take
advantage of it (or makes it completely impossible)

There's a horrible temptation to build some universal general solution which
ends up with supplying a drop down box populated from an XSchema file or
other whizzy something with X in it, to markup line data. Definitely better
than nothing, and in the case of JOSM already done, unfortunately "build a
line, then tag it" isn't really what most people expect to find. In a really
nice user interface the user is supplied with a road tool, which, in fact,
gives them the option of what kind of road to build before they do it, then
a pile of nicely thought through check boxes and data fields for extra
properties. They can then name it, add it's number, and do other stuff. We
should be playing with Sim City more to figure out how to build the editor
GUIs.

This user interface with nothing to type apart from the street names solves
most of 1), 2), and 3). And there's no need to do anything to the server.

Now obviously, more advanced usage requires support too, and here drop down
boxes and some of the gritty data model internals can be exposed, but this
really should be an extra. It's a bit like having to type in the image
filter matrix on photoshop all the time, when all you really want to do is
make it go blurry a bit.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20070109/5e6e0bc1/attachment.html>