[OSM-talk] Burning Man (was: revert changesets??)

Andy Allan gravitystorm at gmail.com
Fri Dec 18 17:46:07 GMT 2009


On Fri, Dec 18, 2009 at 12:12 PM, John Smith <deltafoxtrot256 at gmail.com> wrote:
> 2009/12/18 Aun Johnsen <lists at gimnechiske.org>:
>> Just a suggestion that I think will satisfy both camps:
>> When the burning man us remapped (i.e. moved), add the prefix burning_man:
>> to all tags, that will retain them in the database, erase them from maps,
>> but still allow for special interest maps to render them.
>> This can also work for Glastonbury, Roskilde, and many other yearly events
>> that impacts the area where they occure.
>
> I disagree, if something should be added to "hide" information because
> rendering software isn't yet coded to handle the 4th D, it should be
> more generic, however I think 4th D tagging should just be figured
> out/used/whatever and then let the rendering software/editors play
> catch up like with any other new set of tags.

Hi John,

I prefer the principle of least surprise when working with OSM data.
The most basic analysis of the data should have the least gotchas
possible. So we should avoid tagging things as "This is a foo. (By the
way, no it's not)" and "This is a baz. (Psst, it was a baz three years
ago, but not any more)" - especially when there are many different
caveats we can put on the information.

We already have this with the "highway=construction
construction=primary" so that at first search for the primary roads
you only get the actual primary roads. Principle of least surprise.
We've had similar discussions on the use of amenity=old_pub (and
variants) so that consumers of the data aren't surprised by lots of
things-that-aren't-there showing up by default. And especially for
things that aren't there any more, and can no longer be verified
on-the-ground, I think the onus is on hiding that from the 90+% of
consumers who aren't interested in that kind of stuff. I'd therefore
support the start and end date tags, but the other tags for
non-existent features should also be masked/obscured (e.g. by using a
prefix).

On a separate, but related, point, when people are discussing adding
and removing data from the database, it would be nice to take a more
slow-paced view on things. Not everyone does minutely updates. It
would be nice to consider someone making an engraved sign from OSM
data, for example if roadworks makes a street into a one-way street
just for a day or two I wouldn't like that to be in the main database.
Someone could print out a map and put it on a noticeboard and if they
picked the wrong day it would look like that street is permanently
one-way.

Cheers,
Andy




More information about the talk mailing list