[OSM-talk] Burning Man (was: revert changesets??)
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 ascho...@gmail.com should be deleted then. Burning man follows a no trace policy. as alternative it must be at least tagged different to disappear from maps. Hilarious! :) He's talking about the Leave No Trace ethic that guides our effort to leave a minimal impact on the Black Rock desert environment. For a temporary city of 50,000, the cleanliness of the event is extraordinary. [http://www.burningman.com/environment/] As for digital traces, Burning Man very much encourages it. That's the guiding principle for the Burning Man Earth project, we collectively collect hundreds of gigabytes of data at the event. [http://earth.burningman.com/ http://www.slideshare.net/mikel_maron/burning-man-earth-at-web-20-expo-presentation]. As for the EFF criticism, I suggest reading Burning Man's response on the complexity of the issue [http://blog.burningman.com/?p=4599] OK! So the Burning Man event itself is open to the public for one week. There's approximately 1 month set up prior, and 1 month tear down. The rest of the year, nothing much happens in that geographic location at all. Each year, the event moves slightly to a different position, to minimize the impact on the desert. That's why you see two similar looking city layouts, slightly offset. Despite being physically gone, the importance of the city remains all year long, pretty much up until the time the city starts reconstruction in July. And even beyond that, the layout retains importance as geographic context to photos, videos, memories. If you look at the flickr map, the background map depends on whether the photo was taken in 2008 or 2009. [http://www.aaronland.info/weblog/2009/09/18/fivethings/#burningman] THENWHAT? 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 historic mapper Frankie Roberto [http://www.slideshare.net/frankieroberto/mapp-history-on-open-street-map]. The start_date was the start_date of the event in 2008, and the end_date was the day before the opening of the 2009 event. I haven't yet added start_date and end_date tags to 2009 data. For example .. http://www.openstreetmap.org/browse/node/290073903 I realize it's not perfect, but I think trying to represent both the physical presence, and temporal relevance of this data, in a combination of more than two tags, would have just been overly complex. Open to suggestions though. 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 osm2pgsql/mapnik style rules. Another option is a seperate project more tuned to historic data, though that certainly has it's drawbacks. In the mean time, Burning Man is such an isolated place and event, I think it's a good place to continue to experiement with these problems. So if it's all to same to you .. don't delete the Man! As Aaron said in his post, there's another year before we need to figure out what to do! Dave F. dave...@madasafish.com As I was considering doing a similar thing for Glastonbury, I was wondering what the consensus on mapping temporary (but regular) structures? I guess Glastonbury has a very similar circumstance to Burning Man. I don't think there's consensus, but happy to keep discussing the possibilities. Mikel ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Burning Man (was: revert changesets??)
From: Aun Johnsen li...@gimnechiske.org Date: Fri, Dec 18, 2009 at 12:06 PM Subject: Re: [OSM-talk] Burning Man (was: revert changesets??) To: Mikel Maron mikel_ma...@yahoo.com 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. On Fri, Dec 18, 2009 at 11:51 AM, Mikel Maron mikel_ma...@yahoo.comwrote: 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 ascho...@gmail.com should be deleted then. Burning man follows a no trace policy. as alternative it must be at least tagged different to disappear from maps. Hilarious! :) He's talking about the Leave No Trace ethic that guides our effort to leave a minimal impact on the Black Rock desert environment. For a temporary city of 50,000, the cleanliness of the event is extraordinary. [ http://www.burningman.com/environment/] As for digital traces, Burning Man very much encourages it. That's the guiding principle for the Burning Man Earth project, we collectively collect hundreds of gigabytes of data at the event. [http://earth.burningman.com/ http://www.slideshare.net/mikel_maron/burning-man-earth-at-web-20-expo-presentation]. As for the EFF criticism, I suggest reading Burning Man's response on the complexity of the issue [http://blog.burningman.com/?p=4599] OK! So the Burning Man event itself is open to the public for one week. There's approximately 1 month set up prior, and 1 month tear down. The rest of the year, nothing much happens in that geographic location at all. Each year, the event moves slightly to a different position, to minimize the impact on the desert. That's why you see two similar looking city layouts, slightly offset. Despite being physically gone, the importance of the city remains all year long, pretty much up until the time the city starts reconstruction in July. And even beyond that, the layout retains importance as geographic context to photos, videos, memories. If you look at the flickr map, the background map depends on whether the photo was taken in 2008 or 2009. [ http://www.aaronland.info/weblog/2009/09/18/fivethings/#burningman] THENWHAT? 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 historic mapper Frankie Roberto [http://www.slideshare.net/frankieroberto/mapp-history-on-open-street-map]. The start_date was the start_date of the event in 2008, and the end_date was the day before the opening of the 2009 event. I haven't yet added start_date and end_date tags to 2009 data. For example .. http://www.openstreetmap.org/browse/node/290073903 I realize it's not perfect, but I think trying to represent both the physical presence, and temporal relevance of this data, in a combination of more than two tags, would have just been overly complex. Open to suggestions though. 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 osm2pgsql/mapnik style rules. Another option is a seperate project more tuned to historic data, though that certainly has it's drawbacks. In the mean time, Burning Man is such an isolated place and event, I think it's a good place to continue to experiement with these problems. So if it's all to same to you .. don't delete the Man! As Aaron said in his post, there's another year before we need to figure out what to do! Dave F. dave...@madasafish.com As I was considering doing a similar thing for Glastonbury, I was wondering what the consensus on mapping temporary (but regular) structures? I guess Glastonbury has a very similar circumstance to Burning Man. I don't think there's consensus, but happy to keep discussing the possibilities. Mikel ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Burning Man (was: revert changesets??)
2009/12/18 Mikel Maron mikel_ma...@yahoo.com: 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 that hold a completely different purpose, the discussion page has a lot more suggestions on what else could be used: http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/4th_Dimension ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Burning Man (was: revert changesets??)
2009/12/18 Aun Johnsen li...@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. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Burning Man (was: revert changesets??)
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 osm2pgsql/mapnik style rules. Another option is a seperate project more tuned to historic data, though that certainly has it's drawbacks. In the mean time, Burning Man is such an isolated place and event, I think it's a good place to continue to experiement with these problems. So if it's all to same to you .. don't delete the Man! As Aaron said in his post, there's another year before we need to figure out what to do! not isolated enough, someone found it and started the discussion. I knew about it and didn't change anything for that reason and left it to the creators of the data. but any mapper not knowing about burning man might wipe it out without asking. Dave F. dave...@madasafish.com As I was considering doing a similar thing for Glastonbury, I was wondering what the consensus on mapping temporary (but regular) structures? I guess Glastonbury has a very similar circumstance to Burning Man. I don't think there's consensus, but happy to keep discussing the possibilities. Mikel ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Burning Man (was: revert changesets??)
On Fri, Dec 18, 2009 at 12:12 PM, John Smith deltafoxtrot...@gmail.comwrote: 2009/12/18 Aun Johnsen li...@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. It is not only rendering software, but all software that use the spatial data in some way or another. Yes the ideal is that everything supports 4D correctly, but reality isn't that way. My opinion is that the best is to prefix such tags in a way that removes it from the data structure used by most renderers, routing, etc, but preserves the data as is. If a generic prefix or a project specific prefix is the best is something I have offered no thought, and since I'm not working with such projects is nothing I need to think about. I would rather see you come up with a prefix to hide the data than that somebody decides to clean out the mess. I am completely for using OSM for special purpose maps, but that shouldn't in the same way clutter up a general purpose map. The burning man is an example of OSM usage in special purpose maps, European E-number highways is an example of OSM usage in general purpose maps. There are a lot of tags with mtb: prefix, that is an example of special purpose maps. You get my point? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Burning Man (was: revert changesets??)
On Fri, Dec 18, 2009 at 12:12 PM, John Smith deltafoxtrot...@gmail.com wrote: 2009/12/18 Aun Johnsen li...@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 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Burning Man (was: revert changesets??)
On Fri, Dec 18, 2009 at 4:24 PM, Aun Johnsen li...@gimnechiske.org 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 such, and any routing programs of that era would have followed them. Since the tagging evolved beyond just types of road, most software has stopped rendering unknown objects as unclassified roads. So this kind of change (where all software has to gradually abandon assumptions about the data) has been done before? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Burning Man (was: revert changesets??)
On Fri, Dec 18, 2009 at 6:16 PM, John Smith deltafoxtrot...@gmail.com wrote: 2009/12/19 Andy Allan gravityst...@gmail.com: 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. I'd love to bury my head in the sand and pretend things are always simple assumptions too, but unfortunately the world has vastly different ideas and you can either accept them or not, but it's clearly obvious some people want to map these types of temporary things, and even past things like the Pompai example. Yes, I never said they shouldn't be mapped. What I am suggesting is that things which do not exist can be mapped, but since the mapping of things that do not exist is a niche passtime then appropriate measures should be taken not to confuse people working with mainstream data. If you are suggesting that highway=residential should also be used to describe things that aren't actually residential roads (but used to be), then I suggest that you are going out of your way to make life difficult for everyone, yet to no advantage of the few. 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. Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Burning Man (was: revert changesets??)
2009/12/19 Andy Allan gravityst...@gmail.com: 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 historical information, not just what is current. I'm guessing by the time this becomes an issue that renderers and editors will have caught up, but that doesn't mean we should do things a certain way because the data can't be handled properly at present. Like OJ W wrote, untagged ways used to be rendered as unclassified but that changed because the underlying data shifted from just roads to much more information and it no longer made sense to do things that way. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Burning Man (was: revert changesets??)
On Fri, Dec 18, 2009 at 11:11 PM, OJ W ojwli...@googlemail.com 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 visible' in terms of OSM tags) p.s. I still agree with Andy in 'ease-of-use matters' and with Frankie on 'tags should have time-limits'. It's not trivial like many tag disussions. (but don't underestimate the software) When my neighborhood changes I remove the old map and draw a new, the old map becomes cruft I don't want to edit it again. But it would be nice to have a way to say that there exists an older version of the map. Burning Man is ok since it's shifted every year, but cities/festivals/markets 4D cakes are really hard to handle. -- /emj ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [talk-au] [OSM-talk] Burning Man (was: revert changesets??)
2009/12/19 Aun Johnsen li...@gimnechiske.org: For changing roads, I think the future of changesets will allow us to revert changes as well as have a way to retrieve historical data. I guess that a future API version will allow you to see how the world looked in 2009, so that non-existing roads doesn't need to be saved in the dataset anymore. Until this can be done by the API this way, we should tag it in a way that allows us to preserv this data, without cluttering general maps or confusing users. Andy was the one that brought up roads, I was commenting on event areas and areas that got wiped out due to volcanos, so I don't see the point in tagging roads this way since the data is already in the database and can be pulled out using some of the history APIs people have been coding, as for the even areas there seems to be very little if any noticible harm being cause at present due to the niche nature. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
