Proposal:Golf cart path

Golf Cart Path value, key, and value
Proposal status:	Proposed (under way)
Proposed by:	Lectrician1
Tagging:	highway=cart_path
Applies to:
Definition:	tags for golf cart paths and crossings
Statistics:
Rendered as:	current osm-carto
Draft started:	18-12-20
RFC start:	22-12-20

Proposal

This proposal aims at simplifying and improving the tagging scheme similar to Key:golf cart by establishing a dedicated tag under the service road Key.

Create these features for use on only Ways:

• highway=cart_path
• cart_path=*
• cart_path=crossing

Depreciate:

• golf=cartpath

Rationale

highway=cart_path

Infers

• golf_cart=designated
• foot=yes
• motor_vehicle=no

Use

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.

Problems

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 creates conflicts in:

• Rendering
• Issue validation
• Tagging in-general

Solution

This proposal aims to condense this down to just to the highway=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).

Comparisons and Reasons

highway=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 another highway=* value?

This proposal has transitioned from using the highway=* Key, to not using, and back:

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: - This conflict could be avoided and no additional access tagging or inferences need to be made. - 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.

Exceptions

• 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.

cart_path=*

For use of cartpath values.

cart_path=crossing

Infers

• highway=crossing
• golf_cart=yes

Reasoning

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

Use

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

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

• highway=crossing
• golf_cart=yes

golf=cartpath

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

Examples

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

OSM

Tagging

Example	Tagging
	Golf Cart Path Way: highway=cart_path surface=concrete smoothness=excellent
	Golf Cart Crossing Way: highway=cart_path cart_path=crossing Node: highway=crossing golf_cart=designated
	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 carthpath themselves, so they should use: Way: highway=service service=parking_aisle golf_cart=designated Area: amenity=parking parking=surface golf_cart=designated

Rendering

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.

OSM

See this issue on osm-carto about the implementation of this rendering and the conflicts that occured when deciding what tagging received this rendering.

Features/Pages affected

• Depreciate Tag:golf=cartpath and add notice to Key:golf
• Add tag highway=cart_path to Key:highway
• Recommend using highway=cart_path instead of other highway features on Key:golf_cart

External discussions

OSM World Discord Server

• Initial questioning of possible proposal
• Pre-RFC announcement

Tagging Mailing List

• RFC

Comments

Please comment on the discussion page.