[OSM-dev] [OSM-talk] Xml design

Nigel Magnay nigel.magnay at gmail.com
Mon Jan 8 09:52:27 GMT 2007


> >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.

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. 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
>




More information about the dev mailing list