I have noticed that the connecting roads that are used for U-turns are systematically tagged with “highway=service” instead of eg “highway=secondary_link”. This seems to be deliberate as I see it all over the place. Why is that? Background: I am using OSM for routing and want to remove highways tagged service, but I do need the U-turn bits.
Hi Leevilux, I agree hw=service does not fit well here. Secondary or secondary_link would be better.
On the other hand I have doubts your approach removing hw=service from routing would work well in general (unless you have a very specific application in mind). All sorts of publicly accessible roads are tagged with hw=service: ways on parking lots, access roads to properties off the main road, ways on larger gas stations, etc.
@tzorn: interesting point. I guess it depends on what should be achieved. I am interested in the type of routing that is concerned with “main roads” rather than “back alleys”.
Well, as long as you correct highway=service to a better matching tag I see no problem. If you just change it because you don’t like the routes calculated by a router this would be a bad idea.
I see in the history of https://www.openstreetmap.org/way/24658684 that the change was made by Polarbear almost 3 years ago.
Polarbear is not a novice mapper, perhaps you could contact him and ask why he changed it from secondary to service. It had the value secondary for almost 6 years, it was unclassified before that.
I don’t think it’s quite systematically wrong as it is probably more a mixture of vagueness how to tag all these little short connections and a bunch of different mappers.
From mapping regularily in Berlin I know that you will find all types (hw=, hw=_link and hw=service) for different turning points, median parking access points, minor links etc. Not sure what is used the most here, probably hw=service though.
Asked myself a couple of times what is best to use for the really small connections. The documentation isn’t quite clear on that. I would probably be in favour for *_link though.
By the way, we have good and yearly updated aerial imagery availablein Berlin. So no need to link to Google.
Well consider an example. The user wants to be routed to Tempelhofer Damm 118 in Berlin. Your router needs to find the road that takes the user there. The best navigational and closest option would be the hw=service in front (this one is wrongly tagged as service=parking_aisle, but this is another matter). Without having that in your database you might end up taking the user onto the motorway which is the closest other highway.
That’s a good point. I guess I want to disallow matchings to motorways in general. The match I would like to see is to tempelhofer damm though, precisely here: 52.46923, 13.38548, not in front of the building.
I disagree that a turning point should be tagged as *_link road.
A link is, colloquially speaking, a ramp that carries significant traffic from one road to another. Example https://www.openstreetmap.org/way/334005619 given above is a *_link.
A turning point in a dual carriageway system is not even a road or a lane. It is a place where the physical divider between the opposing carriageways has a gap and a paved surface. It’s intention is that places on the other side of the divider are accessible occasionally, without making a u-turn over the next big junction, which might be more dangerous.
Also, “not even a road” seems a bit exaggerated to me. I believe it is usually the same asphalt as the roads it links to and I know that it can have the usual turning markings on it, the white arrows, see e.g. here: https://goo.gl/maps/urBASR4HRyB2
By the way, the wiki page of “link” also explicitly mentions so-called “internal turning lanes”, see https://wiki.openstreetmap.org/wiki/Highway_link, which suggests to me that links might have a broader meaning than your description.
Perfect example for a service road. The only purpose is to reach the customer parking (way 83709017) on the opposite side of the dual carriageway. So, it is effectively the extension of the building passage onto the car park, thus it even fits your “last 100 m” criterion.
Effectively it is a wideing of the eastbound carriageway, and as such it has an arrow on it. Better visible in Geoportal/DOP2018 and mapillary, than google.
Please note that OSM has a linear abstraction for roads, which is required for one of its primary purposes, vector navigation. Thus you need some node/way connectivity to calculate a routing graph. Thus some auxiliary constructs are necessary, one is this kind of connection between dual carriageways, another one is how we map junctions of two dual carriageways.
If you want to solve you routing problem, you should not exclude service roads from your database, but instead give them a higher cost penalty so they are only selected if really needed.
I agree, but this is not what some people think. There are several contributors changing, e.g. from unclassified to *_link turning points, because is their understanding of the wiki definition.
So, when my nuvi with osm maps says “Take the ramp …” almost never there is a ramp.
I think these parts of the roads are designed to serve the function of turning around not the function of reaching a parking space. They are certainly not “perfect examples” of a service function. What do the following roads service?
Can you make these clickable? I don’t know what you are referring to here.
I can’t see the relevance. My point is that the tag “highway=service” is wrong and doesn’t fit the other uses of the same tag. Now “secondary_link” might also be wrong here, but that doesn’t make “service” right.
Thank you for thinking about my routing problem, but that has nothing to do with the issue. The routing problem is merely why I discovered the issue in the first place.
These are all a few meter stretches of pavement connecting two carriageways of the same road. In my opinion this makes them clearly belonging to this road and I would tag them with the same highway tag as the road itself. Not _link and certainly not service.
I think your suggestion is a good compromise. There is not enough “ramp” to be a link and there is not a clear enough “destination” to be a service road. Maybe I will write to a city planer and ask them specifically about the design purpose. If I get a response I will post it here.
BTW I am also willing to do the re-tagging work in Berlin, given that Polarbear does not veto.
I have no strong opinion, but have used all of the ‘bad’ tagging in the past.
‘service’ because it didn’t need a name and turns / U-turns are an exceptional condition. But I can see how it complicates routing to insert a service road in the middle of a route rather than the closest way to start / end a route.
_link because it doesn’t need a name and it ‘links’ roads to each other. But that may not be the same way a traffic engineer would view the usage of a _link road.
If this is the new preferred way to tag center connectors, I can see massive retag projects coming. It does lead to issues when editing because of editors warning of lacking Refs and names.
