[OSM-talk] Xml design

[Andy Robinson]

Like Imi I'm in favour of the "anything goes" tagging. However I'm also in
favour of using separately an accepted set of tags for generic map rendering
just as others need an alternative set of accepted tags for route planning.
Map Features was my first attempt at the map rendering version and I'm now
working on a new version aimed at map rendering which is much stricter but
hopefully equally extensible. However, I still plan to use keys and values
that do not fit with the current or future Map Features set and always plan
to do so. That's the only realistic and easy way to produce unique one-off
and personalised maps, something we should encourage rather that restrict.

My proposed new Map Features type set will be based around Namespace use to
ensure it does not conflict with loose keys and values.

Cheers,

Andy

Andy Robinson
Andy_J_Robinson at blueyonder.co.uk 

>-----Original Message-----
>From: talk-bounces at openstreetmap.org [mailto:talk-
>bounces at openstreetmap.org] On Behalf Of Scott
>Sent: 08 January 2007 9:16 AM
>To: talk at openstreetmap.org
>Subject: Re: [OSM-talk] Xml design
>
>
>
>On 1/7/2007, "Nigel Magnay" <nigel.magnay at gmail.com> wrote:
>
>>Regardless of the XML output format (which is just a transformation),
>>tags ought to be able to be namespaced in a way that allows easy
>>identification of tags that "should" be consistent. This would allow
>>both the identification of mistakes and maintain the 'freeform'
>>tagging flexibility that we currently have.
>>
>>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.
>
>
>>
>>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