Proposal talk:Temporary
reason/cause annotation
I suggest adding something to this proposal (if only in the examples) showing the recommended way to say what is causing this temporary change. In some cases it will be obvious from tags, (eg if you do temporary:construction=yes) but in other cases (like a street festival) people will probably want to know _why_ the street is closed. How should we tag that? temporary_note=*? Thanks, -- JasonWoof 22:29, 23 January 2011 (UTC)
- Well, construction=* I would interpret as "a new (previously nonexistent) road is being built" - but I get your point. If we wanted to do something like temporary:cause=*, we'd need a near-exhaustive list of all possible causes - which I think is difficult for a potentially wide range of applications. The note=* tag is already around for notes on a map feature (intended for presentation to the map user), so indeed temporary:note=* may be a good idea for freeform text. Being potentially language-bound, I would also consider temporary:note:it=* and the like for extra languages (the main tag should be in the local language). --Stanton 23:01, 3 February 2011 (UTC)
- Thanks Stanton! I can't think of any compeling example where rendering or routing software would need to know the cause. I was thinking of just messages for people. So the temporary:note=* method sounds perfect. -- JasonWoof 01:45, 13 February 2011 (UTC)
- I support JasonWoof, adding a tag like temporary=XXX would clearly indicate tho cause of the temporary "event". --Fx99 06:53, 6 May 2012 (BST)
Thanks Stanton! I can't think of any compeling example where rendering or routing software would need to know the cause. I was thinking of just messages for people. So the temporary:note=* method sounds perfect. -- JasonWoof 01:45, 13 February 2011 (UTC)
Example 6: Humanitarian Mapping
Another example: Widespread flooding in raining season leads to (temporary) displacement of thousands of people, spontaneous camps are built in Hacienda San José.
landuse=farmland
temporary:tourism=camp_site
temporary:refugee=yes
name=Hacienda San José
temporary:name=Hacienda San José Refugee Camp
temporary:date_on=2012-11-01
temporary:date_off=2013-01-30
In this case, the tagging author (humanitarian organisation) should revise the date off. I support this proposal, it can help humanitarian mapping, which is generally time-limited. --Federico Explorador 21:18, 2 June 2012 (BST)
Proposal status
- I read the proposal (I've got the same idea this morning :-p) and it looks good for me, so when will start the RFC, and later the vote ? --Dri60 14:52, 3 April 2011 (BST)
- Is someone going to get this proposal further? I Think it is very useful. --Hedaja (talk) 15:38, 7 November 2014 (UTC)
- I would support it if the proposal was extended to support multiple temporary changes. For example maxspeed=80, temporary:1:maxspeed=50, temporary:1:date_on=..., temporary:2:maxspeed=30, temporary:2:date_on=.... Construction works are often performed in multiple phases, with different modifications during every phase. --Pbb (talk) 10:52, 17 September 2015 (UTC)
- Absolutely agree this could use further development. My hometown is full of roadworks & construction stuff so my routeplanner sends me the wrong way regularly, so I would be really happy if OsmAnd could work with it. Looking at Proposal_process#Proposed, however, we first need to address some of the issues mentioned here and get the draft on the main page finalised. Glozzie (talk) 07:11, 13 May 2016 (UTC)
Direction dependence
I would suggest that in addition, a direction should be available to indicate if the restriction applies to only one direction of traffic. Chaz6 13:38, 25 January 2013 (UTC)
- This would simply use the "temporary:" prefix on existing tags for permanent items that apply to only one direction. This is the beauty of this proposal: All the other osm tags can be added to the temporary conditions. For example one could indicate that a oneway restriction on a road is temporarily lifted, to allow two-way traffic while some other road is temporarily closed. - User:Jbohmdk 16:49, 8 August 2013 (UTC)
Multiple temporal changes
The system needs to be open for multiple temporal changes. Both with overlapping timeframes and successive. Say for example a road that is both closed for private cars during the summer, and is closed for reconstruction works during some period. -- Pbb (talk) 22:21, 2 April 2013 (UTC)
- an option to achieve this could be via namespaces with tags like "temporary:x:*". x could be simply numeric or even a more telling string --GNius (talk) 16:13, 21 January 2015 (UTC)
- I think the solution with time range added to the tag itself, and semicolon for multiple values, could work. See Talk:Proposed features/temporary (conditional)#Multiple temporal changes. --Pbb (talk) 08:01, 23 May 2016 (UTC)
Why not use a relation
We've been talking at lot about this on talk-gb after the flooding otf the Somerset Levels, where the floods were mapped as natural=water, and the destruction of the sea-wall at Dawlish which meant that the main railway was out of action. In the former everything was done with new ways, but in the latter the temporary closure of the railway requires splitting the line and affects major relations. In general this is likely to cause things to go wrong, and anyway it's not clear that we want that sort of edit anyway.
My idea is instead of altering the existing way, one adds a new way sharing the nodes, and they are linked with a relation of type temporary. A temporary relation would have to have a finish date, and could be removed automatically by a bot. Ideally the additional way would also be marked in some way to distinguish it from the permanent feature (this needs to happen in the relation as well) which would allow the temporary way to carry a whole array of free-form tagging.
In the former case there would be no permanent members of the relation just the temporary one with the natural=water as a transient member. In the latter the transient member could either carry additional tags: access=no, impassable=yes, or the full range of railway tags. Exactly how to process the latter cases for routing and rendering apps I have not worked out, although for rendering it could possibly be tweaked by adding a layer=5 tag. The real point is that the temporary relation would allow anything NOT interested in this info to ignore it, and the relation could be used for semi-automatic management of temporary objects. SK53 (talk) 16:36, 7 February 2014 (UTC)
- This method has the problem that it would be highly susceptible to breakage by novice users or users with "simple" editors like iD. They often break polygons, relations and layer roads over roads even if there is a single object at the spot. Requiring the layering of objects on top of each other (like the example road) by design seems to just multiply the problem. I think automatic removal of tags can be done also with the proposed "temporary:" tag schema. Automatic removal of the object can also be done if a specific tag is set onto the object. But any automatic removal carries the risk that the temporary event does not finish on the expected date and the objects/tags are removed prematurely. Aceman444 (talk) 14:52, 5 January 2015 (UTC)
- The relation idea just came to me as well. It also has the upside that it can applied to many objects at the same time. Besides, if there is a planned time sequence of properties to change (such as: the road is blocked for four weeks, then it is a one-way street for three weeks, then it is open for vehicles up to 3.5 t for a week, and then all restrictions are gone) could easily formulated with a bunch of relations, while the current proposal makes it impossible to have such kinds of sequences.
- About the problem that novice users could break things: don't we have this problem always? --glglgl ✉ 15:35, 24 April 2018 (UTC)
Avoid mapping very temporary stuff
We actually need to make a general Good Practice guideline for mappers, to tell them to avoid mapping temporary things. But... well I'm not suggesting a blanket ban. There's shades-of-grey. I mean I think there's been agreement in the past that certain types of very temporary things don't belong in OpenStreetMap. But there's also been a fair amount of temporary stuff getting mapped in a way which is widely accepted. I asked a question about this here: Question:What is the recommended way to tag temporary road works and traffic situations?, and User:joto gave a good answer.
It's one of those things where you have to draw the line somewhere, because you can think of silly extremes. There was a jokey mailing list discussion back when we first got access to imagery in OpenStreetMap. Hurray! We can map out where the sheep are in the farmer fields! but then... do we shuffle the nodes around as they move?? :-) OK so that's silly. Less extreme example: We could add and remove a road whenever tower bridge opens and closes. Also pretty silly! (certainly not what the OpenStreetMap database and API is designed for) . So where's the line that we're drawing there? So far we just trusted it to people's common sense. As I say, this needs fleshing out on a wiki page linked of Good Practice, with various examples I suppose.
...And then we should think about how it fits with this proposed tagging scheme. I mean I don't think it will have any affect on the proposal at all, except that, somewhere near the top of the text, it should acknowledge that some types of temporary data shouldn't be added, and link the wiki page explaining more. The tagging scheme itself seems useful, for those cases where the temporary data is welcomed.
-- Harry Wood (talk) 04:12, 23 December 2015 (UTC)
Automated deletion
"A temporary relation would have to have a finish date, and could be removed automatically by a bot." - SK53 (talk)
- "any automatic removal carries the risk that the temporary event does not finish on the expected date and the objects/tags are removed prematurely." - Aceman444 (talk)
- Maybe instead of automatic deletion, a bot could automatically create a note? Then these can be picked up by regular users for removal/updating the date if applicable. On the other hand: I'm not too sure that in every area notes are handled quickly enough not to pollute the map: I think there might be a higher chance that temporary stuff doesn't get removed manually after the temporary situation has changed back to original situation (irl), than there is a chance that temporary things are removed (automatically) prematurely. Glozzie (talk) 07:04, 13 May 2016 (UTC)