Hi
As the mapper for Burning Man, let me explain a little bit about the festival,
and how I've attempted to represent it in OSM.
But first...
Apollinaris Schoell
> should be deleted then. Burning man follows a no trace policy. as alternative
> it must be at least tagged different to disappe
From: Aun Johnsen
Date: Fri, Dec 18, 2009 at 12:06 PM
Subject: Re: [OSM-talk] Burning Man (was: revert changesets??)
To: Mikel Maron
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
On Fri, Dec 18, 2009 at 12:12 PM, John Smith wrote:
> 2009/12/18 Aun Johnsen :
> > 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
2009/12/18 Mikel Maron :
> So that's the situation. I decided to represent the temporality by adding
> "start_date" and "end_date" tags to the 2008 data, one of the suggestions of
I agree with comments on the 4D page about this that
start_date/end_date is a bit conflicting with other similar tags
2009/12/18 Aun Johnsen :
> 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.
> T
On 18 Dec 2009, at 3:51 , Mikel Maron wrote:
>
> Of course, we now have a map with data shown past the end_date for the 2008
> event. The most obvious option is tuning the renderers to data past it's end
> date. There's downsides to that .. larger planet size, increased complexity
> in osm2pg
On Fri, Dec 18, 2009 at 12:12 PM, John Smith wrote:
> 2009/12/18 Aun Johnsen :
>> 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,
>> bu
On Fri, Dec 18, 2009 at 4:24 PM, Aun Johnsen wrote:
> It is not only rendering software, but all software that use the spatial
> data in some way or another.
A few years ago, you could pretty much assume that any untagged
segment in the OSM database was a road. Renderers would display them
as su
2009/12/19 Andy Allan :
> 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 th
On Fri, Dec 18, 2009 at 6:16 PM, John Smith wrote:
> 2009/12/19 Andy Allan :
>> 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
2009/12/19 Andy Allan :
> Those who are interested in historical maps will need to know about
> the "4th dimension" and whatever tags are involved. Those who aren't,
> shouldn't need to.
Initially it may well be a niche activity, but long term roads move
etc, and it's often useful to know historic
filtering-out historical data (date_end doesn't exist or is in the
past) is 1 or 2 rules. Any application needs tens or hundreds of
rules to even begin to understand OSM (try defining 'can you cycle on
this' or 'is this wet' or 'is this visible' in terms of OSM tags)
p.s. I still agree with Andy
On Fri, Dec 18, 2009 at 11:11 PM, OJ W wrote:
> filtering-out historical data (date_end doesn't exist or is in the
> past) is 1 or 2 rules. Any application needs tens or hundreds of
> rules to even begin to understand OSM (try defining 'can you cycle on
> this' or 'is this wet' or 'is this visibl
13 matches
Mail list logo
