[OSM-talk] "proprietary" keys and values, machine readable vs. humans

John F. Eldredge john at jfeldredge.com
Tue Jan 24 13:57:40 GMT 2012


Martin Koppenhoefer <dieterdreist at gmail.com> wrote:

> 2012/1/24 Jonathan Bennett <openstreetmap at jonno.cix.co.uk>:
> > On 24/01/2012 11:22, Martin Koppenhoefer wrote:
> >> I wonder if this kind of tagging should be tolerated. In the wiki I
> >> found no documentation regarding this tag, and therefore this data
> >> seems unusable for most mappers.
> >
> > Perhaps not, but systematically removing it won't improve anything
> > (since most apps will just ignore the tags), and will actually
> increase
> > the amount of storage needed (since a new version of the objects in
> > question will be created).
> >
> > We have (or at least, should have) a simple principle in OSM: Ignore
> > what you don't understand. That applies to mappers and to
> applications
> > using the data. The alternative is edit wars where one mapper things
> a
> > particular tag -- that otherwise does them no harm -- is "wrong" and
> > starts removing them and their creator puts them back.
> 
> 
> While I understand the idea behind (deletions also occupy space/need
> computing power, at least if performed via the API), I still feel that
> we should have a policy to request tags and values to be human
> readable.
> 
> How would you improve / modify (say split) an object where you don't
> understand part of the tags applied to it?
> 
> Imagine that this tendency grows stronger and a few imports later our
> db would have more crypted keys then "readable" ones. If osm is about
> open data, it should be really open, not only freely available but
> unusable because crypted. Why should we use free and open ressources
> to distribute free-but-not-open content?
> 
> cheers,
> Martin
> 

In cases where data is arranged in multiple tables, and the purpose of a particular field is to link two tables together, rather than directly describing an attribute, it is best to use an otherwise-arbitrary numeric value as the link value.  That way, updating the descriptive fields doesn't break the link.  Also, it is best to have an attribute described in just one of a group of associated records; otherwise, it is easy to get contradictions.

-- 
John F. Eldredge --  john at jfeldredge.com
"Reserve your right to think, for even to think wrongly is better than not to think at all." -- Hypatia of Alexandria



More information about the talk mailing list