[OSM-newbies] use of colon in tags

[Serge Wroclawski]

On Sat, Aug 18, 2012 at 5:30 AM, Dudley Ibbett <dudleyibbett at hotmail.com> wrote:
> Hi
>
> I am currently exploring the possibility of add a tag for the "condition" of
> dry stone walls and also stiles.
>
> I note in the documentation there has been discussion about tags such as
> highway_condition and these have not been accepted.  The one use I have
> found is in "building:condition=".
>
> I have contacted the Dry Stone Wall Association to see if there have a
> classification system for condition and I would then intend to use
> "dry_stone:condition=".  The system would be unique to dry_stone walls as
> the have a tendency to deteriorate in a specific way so it would be
> appropriate to use "wall:condition".

There are two issues here, firstly, the drywall classification, and
secondly the use of colons.

I think it's important to remember, when working with OSM, that it is
designed to be a general purposes database. Once you have information
which is difficult to survey, or that requires specialized knowledge,
this information will often be lost, and will actually just come out
as noise. That doesn't mean your proposal should be dismissed, but you
want to think about the utility of not only the information, but the
surveyability of any new tag.

As for the use of the colon, while some folks on the tagging list love
colons, I can tell you that for most OSM users and most OSM
developers, they're problematic.

An extreme example was a proposal made on the list for tagging pet
shops with pet_shop:sells:puppies.

This kind of information is unlikely to be surveyed and makes the job
of parsing tags very difficult.

Often what happens in OSM is that the tagging people are (to put it
kindly) "detail oriented", but most contributors are not. In fact, you
will find that most of these tagging proposals are irrelevant in that
other unofficial tags are in greater use due to simplicity.

These complicated tagging schemes don't get adopted by the tools
(editors, renderers, etc.) and so they remain marginalized.

It's always best to focus on the simplest use cases and work from
there, rather than focusing on the details, in OSM.

- Serge