The following sentence applies to a situation I am currently mapping (a major freeway is blocked by a collapsed bridge):

I think this depends a bit on the situation: If the collapsed bridge is removed in the next two or three weeks I would not tag the motorway with access=no, but if it’s not sure how long the motorway is blocked and it could be blocked for a few months I think it’s ok to add an access restriction.

One use case for OpenStreetMap data are for example offline routing applications for smart phones. The data for these apps are usually at least a few days or weeks old, sometimes even a few months. People will be very upset when they are routed off the motorway for no obvious reason, because a temporary road closure was still in the data. If we want people to use OSM data for routing we have to make sure that this does not happen.

Most tools don’t render or otherwise obviously support the draft “temporary:” namespace, I have used it, but I had to add non-temporary access tags to make the data useful to anyone.

That’s a chicken-and-egg problem. The more people use the temporarytags, the more likely it is, that routers support it.

The conditional restrictions syntax depends on the opening hours syntax, which has apparently gone out of its way to disallow specifying specific dates, being overly focused on repeating intervals only. This makes it useless for tagging temporary situations.

You could use something like access:conditional=no @ (Sep 28 - Dec 31), you just have to make sure to delete it after the freeway is reopened.

The user could also be taking notes with the OSMAnd App. You can add notes anonymously there while navigating. Maybe the user has an old database for offline routing which might explain the notes for things that are already there. Some mappers are taking notes with this app and go through them later. So, I would wait a week or two, maybe the user will go through the notes and solve them.

Hi,

I just had a look at the Berlin Fernsehturm and found several issues which might cause the missing label and the broken rendering:

• The Fernsehturm consists of many different overlapping building=yes ways which should actually be building:part=yes. This is probably a leftover from early 3D-mapping when the building:part key was not yet used.
• The main tags are on a building-relation which is not yet an approved nor widely used feature. It is also not supported on simple editors like iD etc. Instead there should be an area (or multipolygon) for the whole building complex with the main tags.
• The Fernsehturm is many features in one: tourism=attraction, tourism=viewpoint, man_made=communication_tower. Not all of these tags are compatible with each other. Maybe the whole building complex should get the tourism=attraction, while the tower part gets the tourism=viewpoint and man_made=communication_tower. I think all the other man_made=tower tags should be deleted.
• There have been a lot of 3d experiments going on for the tower with different tagging schemes.
• There is a broken multipolygon with overlapping and touching inner rings for the pedestrian area around it, which probably causes the rendering issues.
• There are some entrance and housenumber nodes near the building, where it is not really clear where they belong to.

The Berliner Fernsehturm is a very famous building in Germany, so a lot of mappers probably tried to “improve” it and added more and more tags and details.

I think the whole building complex needs a cleanup by an experienced mapper (with 3d tagging experience) who knows the area/building. The same probably applies to the other buildings you mentioned.

I don’t think posting an issue for the renderer helps here. The building relation has been proposed 7 years ago and is still not approved nor is it really clear from the proposal how it should be used. The problem with the pedestrian area overlapping parts of the building is due to a broken multipolygon which is a tagging issue and not a renderer issue.

Nice work. I like the fences and the 3d tagging.

The roads could have some more details like maxspeed, number of lanes for the “Landesstraßen”, surface and sidewalks (if they are not separated from the road use the sidewalk-key and not separate footways).

Also some access restrictions could be useful. E.g. most of the small service ways seem to be private, not sure about the tracks, they might be restricted to agricultural vehicles.

And if you are interested in public transport you could add the local bus routes and add some more details to the railway line.

You see there’s always more to do :). Have fun!