On 1/9/07, <b class="gmail_sendername">SteveC</b> <<a href="mailto:steve@asklater.com">steve@asklater.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

* @ 07/01/07 12:21:01 PM <a href="mailto:scott@waye.co.uk">scott@waye.co.uk</a> wrote:<br>> Some thoughts:<br>><br>> With the current XML design of k="" v="" it would seem very difficult to<br>

> create a useful XSD for the data.  A tight XSD would help to avoid<br>> duplication,spelling mistakes, reduce the xml size, and would allow for<br>> the gui to present useful drop downs.  For example we currently have

<br><br>My concern is that if someone wants to invent a tag they just type it<br>in, but if we're going to validate then they now have to get involved in<br>comittees and standards processes.<br><br>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?

</blockquote><div><br>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.<br><br>The problems being addressed in this thread seem to boil down to several points:

<br>1) There's data being put into the database with spelling mistakes in the tags<br>2) People aren't sure what to tag things as and would like some help from their editor<br>3) Some data is not entered correctly for a particular use to easily take advantage of it (or makes it completely impossible)

<br></div><br></div>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 

<span style="font-style: italic;">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.

<br><br>