Your focus on avoiding dataloss is commendable, but you aren’t the first to propose this approach. Unfortunately, we’ve been trying to get an answer for over two years and don’t seem to be any closer to one, hence what amounts to a pile-on this time. We can continue to run out the clock in hopes of a perfect solution, but all that means in reality is that service=driveway2 will have become a de facto established tag, to everyone else’s dismay.
6 Likes
I would summarize the plea for service=driveway2 as “This is a driveway, too”.
In Nederland, a driveway (“oprit”, “inrit”) has variants.
Most are short private driveways to a single house or garage (“oprit”)
Some are slightly longer driveways eg to the back of a property (“inrit”
Some are much longer, but still lead from the road to a property (house or complex), usually starting with a gate (“oprijlaan”)
Some are shared driveways, servicing multiple properties (“gedeelde inrit”, “gezamenlijke oprijlaan”)
Some shared driveways turn into a private service road giving access to multiple regular driveways. That is when we no longer call it a driveway, but still a (private) service road, even if some access is usually granted.
This service road may be public access: still a service road, but definitely not a driveway.
Some have another exit: then it’s still a service road, because the main function is to give access to the driveways to the properties.
If such a service road gives access to a common parking, we will definitely not call it a driveway. It’s a service road (“dienstweg”) or access road (“toegangsweg”).
Long story short, I think it is fine for the Dutch situation to come up with more specific service=* values for the non-driveway variants of service roads. I don’t think they will gain much usage, but you never know.
I don’t think the value driveway2 will be seen as adequate for these variants of service roads.
BTW Nederland has the concept of “A driveway construction”, which means that a regular street, where it links to another road, has the construction of a driveway entry (sloped, table across sidewalk, different paving) and this has legal value, because traffic on driveways or roads constructed as driveways has to give way to the larger road.
In response to @mnalis but overall I think the topic has surfaced several times in this thread and elsewhere:
For example, such distinguishing may allow apps like StreetComplete to ask for
service=*details on allhighway=serviceways which missservice=*tag.
It is true that a tag that basically means that a highway=service road is none of the service=* values used but “just” a very minor road would be handy for the cited purpose. See also the ticket New Quest: What type of service road is this? (#808) in the app’s issue tracker.
However, the introduction of a presumed service=general that catches all other cases except for the ones currently defined means that no other service=* tag value should be added later, as the introduction of another documented value would mean an implicit redefinition of a presumed service=general.
So, I am not saying that such a tag would be a bad idea, but before such a tag is introduced, we should be really sure that there are no other service road categories for which it would make sense to have a value.
See also the mailing list discussion [Tagging] RFC: service=? for all highway=service (service=parking needed, primarily, I think) for a request for comments of a related now inactive proposal.
2 Likes
YM such as service=maintenance, for tracks and roads allowing vehicles and crews to access railways, structures, canals, major dykes, masts, wind mills, etc for maintenance.
1 Like
I hesitate to say this because of the potential downsides, but if we’re unsure of the best categories, could we do a service=described + service:description=((concise note of function))? This could lead to a pool of text that can be easily searched to pull together common uses for tag proposals. Alternately it could just lead to a load of bloat in the database that no one wants to clean up on the basis of it being potentially useful “at some point”.
For generic service roads in things like shopping plazas and business parks that seem to have their own individual hierarchies, we could potentially reuse primary, secondary etc. for these as a way of representing the internal structure without getting too caught up in the minutiae of reflecting the facility type in the service type. I think these are fairly generic terms for ranking, but if having them as service types is too prone to confusion with the highway type then as an alternate major, minor and intermediate might work (not quite in that order).
2 Likes
I like this idea. I’m always finding service roads tagged service=parking_aisle or service=driveway that should just be plain highway=service. Seems like some mappers assume they are supposed to always pick one of the service= values. service=primary would at least let me indicate that no this road really shouldn’t be tagged as a driveway or parking aisle.
what about service=access_road?
service=access_road could be fine, although I don’t think it really adds any meaning beyond highway=service because “service road” and “access road” are synonymous terms. service=primary, service=main, service=major, or similar would communicate that this service road is slightly more important to the network than other service roads (what we currently rely on the lack of a service= tag to mean).
1 Like
from the common service values, not all are access roads though, “alley” isn’t, and I am not sure about parking aisle or drive-through (maybe yes?)
The term “access road” may have multiple meanings. In a certain specific context, perhaps an alley, a parking aisle, or a drive-through might not be considered access roads. However, in general “access road” just means a road that provides access to a specific thing, location, place, facility, building, etc. So broadly the same meaning as highway=service. An alley provides access to the back side of buildings, a parking aisle provides access to the parking spaces in a given row of a parking lot, and a drive-through provides access to order and pickup windows.
I think roads, including service roads, generally provide access. service=* values should specify what kind of service road it is. A service road to access something for maintenance should state that it serves maintenance.
Establishing a hierarchy of service roads seems a poor solution to me. It would guarantee endless debate and unsolvable differences of opinion about importance, and differences in actual usage, which means data users simply would disregard the tag altogether because of worldwide inconsistency in actual meaning.
2 Likes
An alley provides access to the back side of buildings,
actually the term alley is used also in other context (in the US urban typology it is what you describe), in historic centres and also elsewhere, these are narrow ways, too narrow to be considered a street, you can find them in most or all parts of the world, often too small to drive a car. They don’t only provide access to the back but also to the front, in Italy many houses in villages and parts of the towns and cities are only or mostly accessible with alleys (and steps and footways).
a parking aisle provides access to the parking spaces in a given row of a parking lot, and a drive-through provides access to order and pickup windows.
yes, I thought about it, alleys are the odd one maybe. Also, if alleys are service, why not highway=residential (provides access to the houses) or trunk_link (provides access to a trunk)? Maybe we should have highway=alley as a first class type, distinguished from highway=residential like path from track, or bluntly a footway that is a road
1 Like
I used
highway=path path=service service=alley, for back house, path, mainly used by residentials for back entrance property. To express the service character, not so attractive to plan your route along.
highway=path path=alley, path in front of the house (?)
you can use key service with all key highway.
highway=service service=alley
highway=residential residential=service service=alley back house, maybe highway=service is better, but this give more the residential use, express the service character.
highway=residential residential=alley front house.
No need for a highway=alley.
access= and else and width gives, who can access.
even with footway and cyclway, alley, riding walking in between. path gives the flavour of both.
express the driveway then use driveway=*
I only mean it in the manner of “relative to that facility/development”, which is why I prefer it to the major, minor tagging which I think is more likely to be compared across facilities. Tagging as service=main as @ezekielf suggests would be more intuitive for this although the terms for the subsidiary levels would be less obvious (on the rare occasions these are needed). This would have the advantage of being similar to our entrance=* tagging which I don’t think causes too much confusion.
I did think it might be useful to try to flip it on its head with aggregator or collector levels that increase in value with increasing importance. From a data consumer/renderer perspective this might implicitly de-prioritise smaller/simpler facilities as they’re unlikely to get above level 1 e.g. aggregating traffic from the parking aisles and drive-through into one service road. I didn’t suggest this because I couldn’t think of anything pithy to use as a tag and it might have negative consequences for “large but simple” facilities. I suspect that it’s easier to programatically de-weight small facilities than it is to boost larger ones, but that’s all theoretical to me.
I see! But that would be incompatible with the functional tagging e.g. service=parking_aisle, wouldnt it?
service=alley looks like a non-functional value, but the definition sort of states that it is meant for vehicle access to housing utilities, suggesting alternatives for other narrow streets or passages.
For maintenance roads I see no value in tagging those as primary or secondary service roads, I would rather tag service=maintenance, meaning a service road for crew access to a large (often infrastructural) utility object.
I do have mixed feelings about the lack of explicit function in the tag, as you say there is generally an implicit ‘for access’ in the service, but the other values are fairly explicit. I don’t think it would be too much of a conflict, as these are often multi-function (leading to a variety of service road types) rather than dedicated to one specific thing like getting to your parking space.
Calling them collector with a separate collector_level where necessary for the overall hierarchy might solve this as if something was doing dual duty as a parking aisle and a widened road leading to the alley for the loading docks, it could retain its normal parking aisle tagging and have its prominence recorded separately.
I would prefer the scheme to only require two tags rather than three, but I could go either way on this.
Is our considered opinion that service=driveway2 is useful as is (in use), should be left as a basis for better tagging (deprecated) or should just be removed even if we develop finer tagging (discardable)?
This discussion is about service=driveway2, not about service=driveway.
1 Like
Thank you everyone who participated in this thread. I assess that the consensus is to remove service=driveway2 without replacement. I trust that this process has been sufficient to satisfy any concerns that the DWG has about this mechanical edit being sufficiently discussed.
The edits were completed in the following changesets:
Singapore:
Japan:
34 Likes