Proposal:Golf cart path

From OpenStreetMap Wiki
(Redirected from Proposed features/cartpath)
Jump to navigation Jump to search
Golf Cart Path tagging improvements
Proposal status: Proposed (under way)
Proposed by: Lectrician1
Tagging: highway=golf_cart_path
Applies to: way
Definition: tags for golf cart paths and crossings

Rendered as: current osm-carto
Draft started: 2020-12-18
RFC start: 2020-12-22


This proposal aims at simplifying and improving the currently flawed tagging scheme for Golf Cart Paths.

Create these features for use on only way Ways:


Current Tagging

The combination of golf=cartpath and/or the access tag golf_cart=*, and a highway=* tag are the suggested tags currently used on all golf cart paths.


See also Previous discussions on this topic and chronology

  1. Originally, mapping cart paths was not documented and was usually done using highway=* tags like path/track/footway.
  2. golf=cartpath was added as a value to the de facto golf=* Key and its Tag page was created by User:Cr7371 in April 2019.

It's Wiki Tag page Tag:golf=cartpath states that it can be used with:

  • highway=service "for cart paths that are wide enough for full-size motor vehicles"
  • Or in all other cases (typical golf cart paths): highway=path

It also states that golf_cart=* "was approved to be used with highway tags instead of this tag".

Therefore, it recommends "just to be safe", that typical golf cart paths be tagged:

Editor Presets


Preset Name: Golf Cartpath


iD uses both golf=cartpath and golf_cart=designated as-reccomended, but decided




There are extreme variances in tagging conventions for cart paths in golf courses. Most specifically, whether highway=service, highway=path, or highway=track should be used.

This given freedom in tagging is the likely source of these variances.

In this single area alone, all three types of currently suggested highway tags are used (paths, service roads, tracks):

This creates conflicts in:


This proposal aims to condense the tagging down to just to the highway=golf_cart_path tag.

It solves the conflicts noted above by:

  • Rendering to be more easily-implemented, without having to worry about different highway tagging classifications.
  • Allow for issue validators like Osmose to easily ignore the ways that have the tagging scheme, as they are often disconnected from other road networks.
  • Simpler, structured, and more tagging potential (see crossing value below).

Proposed Tags




Golf Cart paths are specifically constructed for golf carts use in golf courses. As seen from the variance in tagging, they can have similar properties of many highway features. However, it is clear that their use is for golf carts and pedestrians.

This tag is meant only for golf cart paths in golf courses.

If typical types of roads are commonly used/meant for golf carts, the golf_cart=* access tag should be used instead.

highway=golf_cart_path vs. golf_cart=*

The current Key:golf cart is very similar to this proposal. It states that the Key can be used on either highway=service or highway=path.

highway=path was not chosen because:

  • It's a muddy and ambiguous tag
  • Having such a specific value under it would confuse data consumers themselves
Why such a long value?

The RFC on the tagging mailing list prompted users to voice their concerns about the terminology of the initially proposed tag highway=cartpath.

The change to the current tag progressed in this discussion:

  1. Peter Elderson: "When I saw "cartpath" in the subject, my first thought was NOT golf carts. My first thought was of a two-wheeled vehicle pulled by one or two horses."[1]
  2. Andy Townsend: "Is "golf cart" actually British English for the thing that you're referring to?"[2]
  3. miketho: "If I saw a general map with the term "cart path", or if the term came up in general conversation, I either wouldn't know to what it referred, or I would assume it was a path for animal drawn carts as another person posted in this thread." "Although a bit wordy, I think in the context of OSM "golf_cart_path" makes more sense than "cart_path", if the standard term is "golf car" then "golf_car_path" works too."[3]
  4. I then asked if changing the proposal to highway=golf_car_path would be okay. User:Mateusz Konieczny stated yes.[4]
  5. A conversation then followed questioning the global popularity of the term "golf cart" vs. "golf car". The community decided that even though British English is the preferred language, "golf cart" is the most commonly recognized term globally, even if it might not be technically correct. Another factor was the already-approved golf_cart=* access tag that already had acceptance in terminology. Replacing this to fit new terminology would be costly. The conversation regarding the change from highway=golf_car_path to the current highway=golf_cart_path can be read here.
Why another highway=* value?

This proposal has transitioned from using the highway=* Key, to using the highway=service, and back (linked conversations):

  1. The initial proposal used the highway=* key because there seemed to be so much variation in possible tagging keys and it seemed like golf cart paths were very separate and distinct in purpose compared to other roadways.
  2. Then, community members were weary about creating another highway tag and wanted stick with one of the current implementations (highway=service). Keeping it under service meant that possible mapping conflicts between golf cart paths that might be used by both carts and maintenance vehicles could be minimized.
  3. User:Minh Nguyen brought up that routing problems in the past have been caused by golf cart paths using the highway=service tag. This was because data consumers were regarding highway=service as an accessible route and not accounting for the golf=cartpath tag. Keeping the new tag under service would not avoid this conflict.

We concluded that making a new highway value was best because:

  1. This conflict could be avoided and no additional access tagging or inferences need to be made.
  2. Golf cart paths are distinct features that only golf carts and pedestrians use and should not be utilized by typical data consumers other than renderers and golf courses for routing. Think of this as another highway=bridleway. It is meant to describe a specific and distinct feature with 1 purpose.


  • Roads that can and do accommodate vehicles greater in size than a golf cart should use the highway=service tag. For example, service roads that are wider than the course cart paths and are used by golf course maintenance vehicles to get around the course. Golf cart paths are distinct features that are part of golf course design. Golf course maintenance vehicles may sometimes use them, but their primary use is for golf carts.


For available use of values.




Similar to how footway=* and cycleway=* have dedicated crossing values, golf_cart_path=* should as well because they commonly cross streets.


Should be tagged on a golf car path way that crosses another highway=* feature.

A shared intersecting node between the golf_cart_path=crossing way and the highway way needs to be created and have the tags:


Because highway=golf_cart_path will be established, it doesn't make sense to have this identical tag.

Tagging Examples

Example Tagging
Golf cart.jpg

Golf Cart Path

way Way:

A1AnRoad-NorthOfCR798-GolfCartCrossing (31838446984).jpg

Golf Cart Crossing

way Way:

node Node:

Golf carts at Circlestone Country Club.JPG

Golf Cart Parking Lot

Related, but included to show the example of a golf cart parking area. These parking areas usually have access to normal vehicles and are not a small and distinguished cart path themselves, so they should use:

way Way:

area Area:


The rendering below is for highway=track, however I think it looks nicer against the green backdrop than what a service road on osm-carto does. It also is thinner.

Issue Validation

Features/Pages affected

External discussions

OSM World Discord Server

Tagging Mailing List

Previous discussions on this topic and chronology


Please comment on the discussion page.