Proposal talk:Golf cart path

From OpenStreetMap Wiki
Jump to navigation Jump to search

Cartpath crossing

Resolved: Bit of unnecessary text removed, shared node with highway=crossing + golf_cart=yes mentioned

Regarding: 

There is no good convention other than highway=crossing + golf_cart=yes which was noted on the Key:golf cart page, but only until recently and concerningly, was added to the Tag:highway=crossing page.

Not sure why this is "concerningly", but I was the one that added the golfer crossing tagging to highway=crossing, which if you'll note from the relevant talk page discussion was based on your input!

I believe the proposed cartpath=crossing needs additional clarity. You're proposing it to be analogous to footway=crossing and cycleway=crossing -- that's good, but you need to clarify that cartpath=crossing is only used on way just like footway/cycleway are. The actual node (or nodes for a divided road) where the cart path and the road intersect still need to get tagged highway=crossing + golf_cart=yes. This needs to be spelled out, because the proposal makes it sound like one of them replaces the other. --ZeLonewolf (talk) 19:51, 22 December 2020 (UTC)

In the Proposal section it notes that all three proposed features are for use on ways only. I added a bit of reiteration in the cartpath=service section as well. --Lectrician1 (talk) 20:08, 22 December 2020 (UTC)

Multiservice

Resolved: When golf cartpaths meet ways with other service=* values, use those values instead and/or include golf_cart=designated

Are there cases where something is both driveway and cartpath? For example driveway to house and also used as cart path section?

Or driveway for golf carts only? Mateusz Konieczny (talk) 08:54, 23 December 2020 (UTC)

I'm sure I've come across a driveway or parking aisle that was needed to connect from one golf cart path to another, but I'd probably keep using that other service=* value, giving it priority over cartpath. In case it helps, here are some other edge cases where golf carts are used but not for golf, so whether it qualifies as a "cartpath" might be more subjective:
 – Minh Nguyễn 💬 09:56, 23 December 2020 (UTC)
And as noted in the proposal, adding the access value golf_cart=designated/yes is always available. Minh's explanation is correct. --Lectrician1 (talk) 17:40, 23 December 2020 (UTC)

Switch back to highway. Roadworthiness, not motorization.

Resolved: Primary tag switched from service=cartpath to highway=cart_path

We need to maintain a clear distinction between roads designed for roadworthy vehicles and paths that aren't designed for them. The proposal states, "Golf carts are motor vehicles." This is technically true, but Key:access lists electric bicycles under "non-motorized vehicle" rather than "motorized vehicle", and for good reason: the motor alone doesn't make it roadworthy. Some jurisdictions consider some golf carts to be roadworthy, but that doesn't mean that a path designed for golf carts is designed for motor vehicles in general. If a path in San Francisco were designed and designated for electric kick scooters, I think it would probably be tagged highway=path or highway=footway, not highway=service.

This proposal replaces the golf=cartpath "trolltag" with another problematic tag, service=cartpath. The current crop of routers only uses the service=* key to adjust speed penalties, not to infer access restrictions. A router could conceivably special-case service=cartpath to imply motor_vehicle=no, but highway=service and service=* are already so established that requiring this special case could cause unnecessary disruption and latent bugs. For example, this editor issue was created in response to a real-world accident caused by a router that sent a delivery van down a golf cart path that was designed for smaller, slower golf carts. The way was tagged highway=service golf=cartpath, but that tagging combination was unfortunately introduced as an editor preset without input from any router developer, so no router recognizes that it implies motor_vehicle=no.

highway=path is admittedly an ambiguous tag on its own, but on the bright side, that means data consumers are making fewer assumptions about it, so there's less risk of breakage. Combining the tag with golf_cart=designated or service=cartpath would make the meaning clear. Golf cart paths are normally designed to be usable by pedestrians, so if a data consumer currently assumes highway=path is walkable, there's less trouble than if a data consumer assumes highway=service service=cartpath is for cars.

If it's really necessary to overload highway=service for paths that bend the decade-long understanding of that tag, then this proposal and eventual service=cartpath page should make it very clear that motor_vehicle=no must be combined with it, similar to how service=emergency_access is typically qualified by access=* or emergency=*.

 – Minh Nguyễn 💬 09:41, 23 December 2020 (UTC)

If you saw the first section of this talk page, the original proposal was for highway=cartpath. I think I chose this not thinking about the specific access cases that you noted here, but just the general disagreement between so many Key/values. Comparingly, this tagging confusion has been caused by the access problems you noted.
After thinking about it, I think the best solution would be to return the proposal back to highway=cartpath. If you think about it, there are actually only 2 potential data consumers for this: Cartography (osm-carto) & golf courses themselves for routing. No other service should be using them for routing.
The problems you noted like other motor vehicles using them, annoying requirement of adding specific tags, etc. could all be easily ignored.
Making it path=cartpath is also an option, but path=* is such a muddy and ambiguous tag, having such a specific value under it would confuse data consumers themselves.
Reclarifying why this proposal was created, having this tag is meant for the specific use on golf cartpaths in golf courses and nowhere else. This is for both ease in mapping/editing and routers.
Is this the best approach? --Lectrician1 (talk) 18:13, 23 December 2020 (UTC)
I have no trouble with highway=cartpath idea, my negative reaction when it first appeared was caused by how it was introduced Mateusz Konieczny (talk) 18:32, 23 December 2020 (UTC)

A dedicated highway=* value seems reasonable to me. It would complement other tags for specialized pathways, such as highway=bridleway. Aside from procedural concerns, the objections in this openstreetmap-carto issue seem to focus on the use of a key other than highway=*, which can be inconvenient for rendering import pipelines. So bringing the tagging back to highway=* should improve the chances of renderer support. I don't think developers of general-purpose routers will mourn the inability to automatically route pedestrians through golf courses.

I'm unsure about the specific spelling cartpath. It seems to have been chosen for consistency with golf=cartpath, but without the "golf" in the key, it could cause some confusion with other kinds of carts, like horse-drawn carriages or go-karts, which sometimes have dedicated paths too. The vehicles are known as "golf carts" or "golf cars" even when they aren't used on golf courses, so I think we should take this opportunity to establish a more descriptive tag, like highway=golf_cart_path.

 – Minh Nguyễn 💬 20:40, 23 December 2020 (UTC)

Apparently, "cart path" is an established term for these things, at least among golfers. Shows you how much I know about golf! But it's usually spelled "cart path", not "cartpath", so cart_path might be worth considering. – Minh Nguyễn 💬 20:46, 23 December 2020 (UTC)

This won't work

Resolved: Developer of plugin contacted about potential tagging change via an issue on the repo for plugin

The single biggest consumer of detailed OSM golf data is The Golf Club 2019, and the single biggest producer of detailed golf data is people who use that software. Any attempt to change golf-related tagging will need to coordinate with that community and ensure the tools are updated, otherwise, it'll just be ignored. --Carnildo (talk) 18:45, 23 December 2020 (UTC)

Do you have contact to them? We can let them know Mateusz Konieczny (talk) 19:40, 23 December 2020 (UTC)
The Golf Club's players tend to use iD, right? If this proposal passes and iD is updated, would we expect those players to manually enter the old tags, or would they manually enter the old tags, perhaps after consulting outdated in-game documentation? – Minh Nguyễn 💬 20:43, 23 December 2020 (UTC)
A plugin for the game, not the game itself, relies on OSM. This is the plugin. I have created an issue on the repo about this proposal. --Lectrician1 (talk) 21:17, 23 December 2020 (UTC)

Common term is golf cart even in Britain

Resolved: Switched to golf_cart_path=*

As discussed on the Tagging list, while some golf cart manufactures like to advertise these as “golf cars”, they are commonly called “golf carts” even in Britain: https://lists.openstreetmap.org/pipermail/tagging/2021-January/057883.html

I agree. "Golf Cart" is quite an normal, accepted and understood term in British English; see the stats quoted in the Tagging List discussion, quoted above. (I have 68 years' experience as a native speaker - and counting!) Therefore I strongly recommend that, in this proposal "cart" should be retained and NOT changed to "car". This could greatly reduce the amount of change needed to existing tagging. --PeterPan99 (talk) 14:21, 3 January 2021 (UTC)

The statement of this section is just incorrect. My local golf club signage only uses the term "golf buggy" (see attached photo). The OSM standard is to use British English except in cases of clear confusion (pavement/sidewalk): the fact that golf cart may be understood to refer to a buggy, There is also potential for confusion (as demonstrated by wikipedia re-directs) with simple trolleys for golf bags. A more convincing reason is that "cart" is historically the tag used on OSM. Note many paths which could be interpreted as buggy/cart paths on golf courses are merely areas which get heavily worn (and/or muddy) which have therefore had gravel laid. I would imagine many are wide enough for buggies, but usage is still relatively rare on UK golf courses. Also most are not really highways in any meaningful sense as they are merely short unconnected stretches (which is why, at least in UK) the golf key was appropriate. SK53 (talk) 16:49, 7 January 2021 (UTC)
Golf Buggy signage in England

Graceful degradation

Resolved: Proposal confusion in whether the tag was using highway=* or service=*. Confusing Talk page Topic archived.

Sticking to a subtag of highway=service (such as highway=service + service=golf_car_path) will bring graceful degradation: applications aware of service=golf_car_path will take it into account while those that are not will still render highway=service. Tagging highway=golf_car_path will leave most applications unable to make sense of that rare value.

--liotier (talk) 10:43, 3 January 2021 (UTC)

On the other hand highway=service + service=golf_car_path can be considered trolltag if someone considers golf cart path to not be a service road (is cart path big enough to drive full-size cars there? I have no experience here but judging from https://www.msn.com/en-us/money/companies/an-amazon-driver-got-his-truck-stuck-in-a-golf-cart-tunnel-he-blamed-his-gps/ar-BB1aV34I it appears to be borderline - you can sometimes fit car there, sometimes not, cars cannot really pass anything else from other side ). I guess the question is "is it useful to have fallback of golf cart path to highway=service" Mateusz Konieczny (talk) 11:58, 3 January 2021 (UTC)
So, potentially:
a. The Golf Club could erect signage, showing the clearance height through the tunnel (and the driver could be aware of the height of his vehicle),
b. A mapper could map the height restriction on the way (and routing apps could only use routes with clearances greater than the user's vehicle).
c. Routers could be made aware of the (new) usage of "highway=service; service=golf_car(t)_path" and avoid using it.
...or any combination of the above.
--PeterPan99 (talk) 14:45, 3 January 2021 (UTC)
That's a lot of things dependent on categorizing a road that only has 1 purpose, to allow for golf cart travel on golf courses. Think of this tag as another highway=bridleway. It only has 1 purpose. Mappers and users should not have to go through that hassle when mapping might not even be specific enough to account for those discrepancies. IDK. Maybe you were being sarcastic?
As described in the conversation that switch the proposal from service=cartpath to it's current state, there are only 2 categories of data consumers who should take use to golf cart path data: Those who want data for golf courses (golf courses themselves, golf games, etc.) and renderers. No other standard service should be using them for routing.
I feel like we're going in circles. If there's anything else anyone would like me to add to the section dedicated to clarifying why a highway value, please let me know. --Lectrician1 (talk) 18:54, 3 January 2021 (UTC)
Please accept my apologies, if I did not make myself clear in my comment above. My intention was to support the possibility of using "highway=service; service=golf_car(t)_path". I had not read carefully enough to realise that you had now accepted the counter-argument and were now proposing a new, top-level tag highway=*. In my defence, the first line of this Discussion Page at the time was (and still is), "Main proposal tag changed from highway=cartpath to highway=service + service=cartpath", so I naively thought that was the current proposal. --PeterPan99 (talk) 09:51, 4 January 2021 (UTC)
I archived that section Mateusz Konieczny (talk) 09:58, 4 January 2021 (UTC)

Please keep golf= trolltag - Comment by the Developer of the "The Golf Club" Lidar Tools

Cr7371 (talk) The original idea behind the golf= is that there are paths of various materials (grass, concrete, dirt, native area, gravel) that are designated for specific game play purposes within the game of golf. These are almost always private access only, non-routable, not connected the the main routing graph paths. In fact, most are not safe for all other use cases. Running, walking, or other non-gameplay use of these paths can lead to permanent injury or death because of the risk of being hit by a golf ball while "on the field of play". I tried to be clear to all involve that this is only for the rules of an active game of golf according to the USGA and R&A provisions. It's most definitely NOT for "golf course communities" where people drive vehicles that may serve double purpose as a golf cart. There is never "navigation" within a golf course, you follow the specified route in the intended directions.

With that clarification attempted, every other golf= tag is modifies another valid tag to indicate that it has a specific rules provision within the game of golf. For instance. golf=green specifies that this is the putting surface and has rules implications for an area also tagged as landuse=grass. Here is the complete list of golf= tags https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dgolf_course#Details_within_a_golf_course All of them correspond to specific rule sets during a round of golf. With this in mind, it's not that the base tag is being modified, it's that that line feature represents a specific ruleset that needs to be followed along that line.

That being said, if the golf= tag can be preserved and understood to not be a routing feature but a ruleset feature, whatever the base tag is doesn't matter for this use case. It could even be the basic line with no other tags as an extreme example, but a poor one as it won't show on the editor. I think 99.9% of users using this tag will be using an automatic editor so consistency can be enforced through the editors. I can make an attempt to support the outcome of this RFC if it results in changes. --unsigned comment by User:Cr7371

@Cr7371: The definition and usage of this tag is exactly for golf cart paths in golf courses. This means that all of the ways currently tagged as golf=cartpath fit perfectly into this definition and can be safely replaced with highway=golf_cart_path. It also fits into the "rulesets" inference of golf, it just doesn't use the golf=* key anymore.
Also, one of the main reasons behind creating highway=golf_cart_path is that you don't have to use an erroneous highway=* tag and in addition add golf=cartpath.
Yes, depreciating golf=cartpath and removing it from it's handy family of golf=* tags may seem uncomfortable; but in the end, I feel that the simplified tagging, both for mappers and data consumers alike (they only have to use one tag), will be significantly better than the current situation.
I am doing this in benefit of the respect for the rules of golf and routing alike (I'm a golfer myself!). I hope my proposal reflects this.
--Lectrician1 (talk) 01:13, 9 April 2021 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Golf_cart_path&oldid=2514142"