OpenStreetMap

The wrong side of mapping transient events in OSM

Posted by Pieren on 3 March 2014 in English (English)

Mid-February, I sent a message to the main OSM mailing list reporting someone mapping the floods in UK 5 weeks ago.

Since few weeks, flood waters have subsided and the media frenzy have moved somewhere else. But the "natural=water" polygon in OSM is still there. Even if it is removed now (and it will probably after this blog post), how long time such transient data remains in OSM copies around the world either on statc maps or GPS devices or data dumps ?

Again, a good reason to reject all transient events in OSM, no ?

Comment from Vincent de Phily on 3 March 2014 at 17:04

I'd agree with you in this particular instance, but where do you put the limit on what is "transient" ? Something that disappears after 1 day ? week ? month ? year ? How certain must the end date be ? Roadworks come to mind as something that everybody will rate differently.

I'm playing the devil's advocate here, but I think that "I feel this feature is permanent enough to map" is likely to always win because bikesheding will ensure that "permanent enough" never gets a good definition.

Hide this comment

Comment from maxolasersquad on 3 March 2014 at 17:14

I would say that if one is willing to keep the map up to date with the ground situation as it changes, then go for it. If not then it is probably best to leave things alone.

When OSM notes show up with a description like, "Speed limit 45 mom while under construction." I just leave those alone. Who knows how long it will take after construction is complete for the speed limit to be reset.

A good case for mapping transient events is disaster relief. If disaster workers are on the ground working, it may be critical for them to know that a low area is now a river. It would, of course, be equally critical to know when the water has receded again.

Hide this comment

Comment from Rovastar on 4 March 2014 at 03:34

The irony of this is the Twitter post that ' reported' this was actually a tweet about how good osm is because this had been mapped.

Hide this comment

Comment from jutezak on 4 March 2014 at 07:03

Also keep in mind that OSM data gets copied and teh copies used, for example for navigation.

It could make sense to mark transient changes as such. For the speed limit, that is straightforward and an exporter could disregard the temporary tags, instead using unlerlying permanent tags.

For road changes (for example, near Eindhoven (NL) a reconstruction of an important roundabout caused a closure of multiple months) the roads should be tagged as 'no access temporarily' and re-arranged and the tags removed. FWIW Google maps showed the roundabout as really 'gone' during the works - but no one is supposed to export their map data.

Thus I think it could work in a clean way.

For the longer term I feel multiple OSM 'layers' are the solution: a base map with things that do not change much, like actual roads, road names, and buildings, rivers etc. A separate layer then contains attributes such as maxspeed, one way tags, etc. And another layer could contain detailed data about businesses (the name of the restaurant ion a specific building, for example). The UI doesn't need to change, but there could be lower barriers to entry for changing attributes on a road or business. Exports of the changes can be a lot quicker. And the risk of someone deleting the whole road when it is just closed for repaving is reduced.

Hide this comment

Comment from HannesHH on 4 March 2014 at 11:37

Some of the biggest public coverage comes from the humanitarian mapping after disasters which by definition is transient. Maybe on the long run OSM needs some flags about the estimated live span of objects?

Hide this comment

Comment from Vincent de Phily on 4 March 2014 at 11:53

Re "flags about the estimated live span of objects" we do have end_date along with other suggestions. But there is a fair amount of resistance to the idea, because of the risk of making a big mess (very few tools support the end_date tag, for starters), and many people would rather shove that data away to OpenHistoricalMap.

Hide this comment

Comment from Pieren on 4 March 2014 at 13:15

disasters which by definition is transient

We don't map disasters but the consequences of disasters. A collapsed building is something more than "transient" I guess. But some tiles of a roof damaged by wind which can be quickly repaired is more "transient". Add an "end_date" tag doesn't help since no one is able to predict the future (for instance, damaged buildings can be just repaired or renovated or fully rebuilt from scratch). "start/end_date" should be reserved for dates in the past. My concern is more about access tags which have a possible long term impact on offline copies e.g. in small devices like navi systems. Also some contributors are just attracted by the project when "events" are widely present in the media. But once the rescue teams and TV reporters are gone, the armchair mappers are just leaving the "transient" data.

Hide this comment

Comment from lezurdis on 4 March 2014 at 18:03

Another example with a forgotten transient attribute, a road closed for less than a month :

And compare its neighbour :

Sad to say ... 2 years to detect a routing error.

Hide this comment

Comment from Chris Fleming on 4 March 2014 at 21:21

I actually wonder is we need specific tagging for transient events. So for example the naive user would pick up the normal road, but a more sophisticated user could render the road as closed. In addition it could include an expected end time.

Hide this comment

Comment from Pieren on 5 March 2014 at 12:46

Perharps we should distinguish a permanent attribute (e.g. "access=no" because it's always 'no') to a temporary attribute ("access=no" because the road is repaired), not by using sub-tags like "start/end_date" which doesn't say which attribute/s is/are temporary, can be easily ignored by data consumers or never updated by the contributors but with a special namespace which would be automatically destroyed at a planned time (a bot). Something like "transient:access:=no". It should be all defined in a single tag, including its validity period (a time duration or a date), to avoid incomplete information (which could be the case if you split the details in 2 or more tags).
Advantage of this method is that permanent attributes are clearly separated from the transient ones. Data consumers could decide to take into account the transient details or not in their use. For instance, a car navi system could ignore the "transient:*" tags in OSM (or just the ones covered by the validity period) but a disaster map renderer could highlight all these "transient:" atributes in his rendering style.

Hide this comment

Comment from SomeoneElse on 6 March 2014 at 13:00

You said above "Since few weeks, flood waters have subsided and the media frenzy have moved somewhere else.". The second of those statements is true to an extent, but the first isn't necessarily so.

According to a BBC TV news report yesterday, flooding in the levels has dropped around 0.5m, and the reporter was still able to do the usual piece to camera with acres of water in the background.

So yes, there is a discussion to be had about when and how transient events are mapped, and how long an event has to be to be considered "not transient", but don't assume that because the media have moved on that the events over. People in the Philippines are still getting back on their feet after last November, there's still a civil war in Syria, etc.

Hide this comment

Leave a comment

Parsed with Markdown

  • Headings

    # Heading
    ## Subheading

  • Unordered list

    * First item
    * Second item

  • Ordered list

    1. First item
    2. Second item

  • Link

    [Text](URL)
  • Image

    ![Alt text](URL)

Login to leave a comment