[OSM-talk] keys

[Martyn Welch]

This seems quite reasonable, after-all the prefix of the name space could be 
automatically applied by any editor configured to just use one name space.

For example, JOSM could have a preference to allow lock to a specific name 
space, this could lock the key box only allow certain keys and even certain 
values if this is deemed appropriate. This would also simplify the task of 
tagging the ways.

I guess we should have a good discussion about the keys and values to allow, 
thus hopefully reaching a concensus and not polluting whatever is to be 
considered the core name space.

Martyn

On Monday 12 June 2006 13:24, Etienne wrote:
> I think the use of namespaces would be a good thing.
>
> These should not be confused with XML namespaces athough they could look
> similar and work in much the same way.
>
> Tags could have an optional prefix that indicates which scheme they belong
> to.  For example, the Map Features scheme could be designated as mf, and so
> tags that are part of that scheme could be entered like this:
>
>   mf:highway=secondary
>   mf:name=High Street
>
> Or, using the XML schema:
>   <way id='123'>
>     <tag k='mf:highway' v='secondary'/>
>     <tag k='mf:name' v='High Street'/>
>   </way>
>
> It would be valid for a way, segment or node to have tags from more than
> one namespace so that the same feature can be tagged in multiple different
> ways.  For example, a mountain road might be a ski piste during the winter.
> if there was an OpenPisteMap scheme designated as opm then that road could
> be tagged like this:
>
>   mf:highway=unclassified
>   mf:name=Rue de Cote de Bette
>   opm:piste=green
>   opm:name=Piste de Chard Suisse
>
> It also occurs to me that it might be reasonable to allow namespaces to
> have some structure, so that, for example, Map Features can have regional
> variants.  mf.us:highway=freeway, mf.de:highway=autobahn.  This would allow
> local variations while still retaining some grouping of all those schemes
> that have allegiance to the Map Features church.
>
> Ultimately there would need to be a lookup table or registry somewhere of
> namespace names containing pointers to the definitions of the keys that
> belong to that namespace.  There would be sever uses for this.  Joe Public
> needs to be able to find out exactly what mf:abutters=mixed means.
> Renderers need to be able to find a set of rules for rendering tags marked
> up with a particular scheme.  Validators (manual or automatic) would be
> able to find all the valid possibilities for keys and values of a scheme,
> and also tags that don't belong to any namespace or belong to an
> unregistered namespace.
>
> Etienne
>
> On 6/12/06, Andy Robinson <Andy_J_Robinson at blueyonder.co.uk> wrote:
> > The discussions over the last few days about keys and values raised an
> > important point which I don't think has been really looked at before.
> >
> > Currently there is no convention for the format of a key other than what
> > is
> > already in use and that does not necessarily help with the management of
> > tagging (when received from the database) as the database grows. The more
> > keys that are generated the more complicated the analysis or rendering of
> > those keys will be.
> >
> > I think to a large extent we need a coding perspective on this. For those
> > editing data its easy to use whatever convention there is, provided it is
> > both logical (and by that I also mean easy to understand and relate to
> > for non-coders) as well as sufficiently flexible to enable any extension
> > of use
> > that a user may wish.
> >
> > A few ideas were floating around in the previous emails, including the
> > use of Namspace referencing (which I think is a good idea), although
> > guidance on
> > namespace use between keys and values is required. Personally I would
> > prefer
> > to avoid coding type convention unless that's hidden under the hood of
> > the editng software. What the user should see (if there is anything to
> > see at all) should be obvious and descriptive.
> >
> > I did not put the "value" part of the equation into this discussion as I
> > think that's where the full flexibility should always be, albeit that the
> > project may wish with time to adopt a default set of values to go with
> > certain default keys.
> >
> > Anyway, this hopefully opens up the discussion. Suggest that ideas are
> > noted
> > on the extra "keys" section I just added to:
> >
> > http://wiki.openstreetmap.org/index.php/Key_Value_System
> >
> > Cheers,
> >
> > Andy
> >
> > Andy Robinson
> > Andy_J_Robinson at blueyonder.co.uk
> >
> >
> >
> > _______________________________________________
> > talk mailing list
> > talk at openstreetmap.org
> > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

-- 

Martyn Welch (welchm at comp.lancs.ac.uk)

PGP Key : http://ubicomp.lancs.ac.uk/~martyn/pgpkey/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20060612/ce7b3879/attachment.pgp>