[OSM-talk] keys

[Etienne]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20060612/f11c113a/attachment.html>