[OSM-talk] Xml design

[Scott]

On 1/8/2007, "Nigel Magnay" <nigel.magnay at gmail.com> wrote:

>> >So I could say
>> ><tag ns="osm1.0" k="highway" v="unclassified" />
>> >
>> >and
>> ><tag ns="nigelmtags" k="rambling" v="excellent"/>
>>
>> You dont need to have a new namespace for this xsd:any would suffice.
>> (http://www.w3.org/TR/xmlschema-0/#any)
>>
>> Anyway the issue is the misspelling which namespaces alone will not solve.
>>
>
>I don't mean namespace in the XSD sense, I mean it in the sense of
>creating an vocabulary for a set of name, value pairs. The XML
>representation is just a distraction here.

I agree, its the concept that's important.

>
>Something that would be very useful would be
>1) Add a namespace (vocabulary) part to the key, value pairs
>2) Create a template in the wiki for vocabularies, so I could go to
>'osm tag vocabulary' or 'nigelm tag vocabulary' and add and remove
>values from the page.
>3) On a scheduled basis,
>   i) push the changed pages from the wiki into a table in the
>database (e.g. VOCAB (namespace string, key string, value string)
>   ii) run a query selecting any rows from the database that have
>invalid content (this is an easy fast query).
>   iii) put the results of the invalid rows (or say the top 100) back
>onto a related wiki page as 'invalidly named items'
>4) In addition to publishing planet.osm, publish vocabularies.osm,
>containing the data from (3).
>
>This gives you the flickr-like ability to do unconstrained tagging
>wherever you like, which is good; but also to identify tags that you
>*want* to be correct (spelling, known tag, etc), if you so choose. 

Sounds fine.  I'd be happy with that, its like having an XSD, but
different :-)

>It
>also allows you to create equivalence mappings, (what uk mappers call
>motorway, german mappers call autobahn) which could be useful for
>renderers.
>
>>
>> >
>> >If you want to "validate" the output in some way (which I'm not sure
>> >it ever can be invalid if the tags are always freeform), then you
>> >could use something like schematron rather than XSD (which is really
>> >only designed to validate structure anyway, and is horribly horribly
>> >broken) or perhaps RelaxNG. There's also nothing stopping you XSLTing
>> >out particular tag vocabularies into something more easily passed
>> >through a schema. I suspect though that trying to run planet.osm
>> >through a schema validator, you'll be here until the heat-death of the
>> >universe... ;-))
>>
>> I'm am not trying to validate, but am trying to use the data in a route
>> planner.  I just want to pick the highway tags, but I cannot as they
>> have different names.  I will have similar problems in calculating costs
>> based on highway type, and junctions.
>>
>> >
>> >
>> >On 07/01/07, scott <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
>> >>
>> >>   <way id="4073353" timestamp="2006-12-13T01:57:16+00:00">
>> >>     <seg id="65667" />
>> >>     <seg id="65652" />
>> >>     <tag k="created_by" v="JOSM" />
>> >>     <tag k="highway" v="unclassified" />
>> >>     <tag k="oneway" v="true" />
>> >>   </way>
>> >>
>> >> What I am proposing is to have
>> >>
>> >>   <way id="4073353" timestamp="2006-12-13T01:57:16+00:00"
>> >> created_by="JOSM" highway="unclassified oneway="true">
>> >>     <seg id="65667" />
>> >>     <seg id="65652" />
>> >>   </way>
>> >>
>> >> We could then have an XSD which lists the valid values for the highway
>> >> attribute, and applications like JOSM could present those in a drop
>> >> down.  Presently, for example, in the database we have the following
>> >> attributes:
>> >>
>> >> abbutter
>> >> abbutters
>> >> abutment
>> >> abutters
>> >> abuttors
>> >>
>> >> we also have at least 10 versions (these are just the ones that begin
>> >> with h) of highway:
>> >>
>> >> hgihway
>> >> hifgway
>> >> highawy
>> >> highjway
>> >> highwau
>> >> highway
>> >> highway:
>> >> highwy
>> >> higway
>> >> hoghway
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> The argument might be put forward that the current design allows more
>> >> flexibility.  But I dont buy that.  There is nothing to stop you
>> >> extending the XSD when needed.  That is what the X stands for,
>> >> extensibility.
>> >>
>> >> I dont care if they are stored in the SQL database as name value pairs,
>> >> thats a different issue, and the current implementation is fine as far
>> >> as I'm concerned.
>> >>
>> >> Any thoughts?
>> >>
>> >> --
>> >> Scott
>> >>
>> >> _______________________________________________
>> >> talk mailing list
>> >> talk at openstreetmap.org
>> >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>> >>
>> >
>> >_______________________________________________
>> >talk mailing list
>> >talk at openstreetmap.org
>> >http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>>
>> _______________________________________________
>> talk mailing list
>> talk at openstreetmap.org
>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>>