Proposal:Safari Route Relation Type

Safari Route Relation Type
Proposal status:	Voting (under way)
Proposed by:	PizzaTreeIsland
Tagging:	route=safari
Applies to:
Definition:	A new route relation type for routes, usually inside safari zoos, where animals are roaming free and visitors can drive through in a car or a bus.
Statistics:
Draft started:	2026-04-07
RFC start:	2026-04-12
Vote start:	2026-04-28
Vote end:	2026-05-12

Example of a safari route where tourists can take their own car and drive through animal enclosures.

Proposal

This proposal suggests to map designated routes where tourists can take their car or attend a bus ride, usually inside safari zoos, as route relations. The tag route=safari should be established to use on these kinds of relations. The routes should be official and established. The tag is not supposed to be used on roads/routes that happen to be used by some hotel for their safari tours sometimes.

Rationale

There are 125 safari parks mapped as of writing this and a number of additional safari tour routes that is impossible to determine because there is no uniform data structure for them. Mapping touristic routes for hiking, biking or canoeing is already well established inside OpenStreetMap with thousands of examples of such route relations. Mapping safari drive routes in a similar way could inherit the already existing structure while giving the clear advantage of searchability.

Of course, tourists planning to visit a safari zoo will more likely search for the zoo itself rather than for a route relation, but there are also safari routes that are not part of mapped safari parks (see examples). Mapping the routes as relations in addition to just the roads being inside a safari park way has the additional advantage of giving a clearly machine readable structure, mostly for 3rd party platforms that specialize in trail planning (like alltrails or komoot). Humans looking at the map can easily piece together all the different oneway roads leading from the entrance to the exit through all the animal enclosures, but that is less trivial to automate and ambiguity can lead to issues, especially if there are also service routes that are meant for staff only and that are not part of the touristic route.

Having an established and well documented relation structure for safari tours brings additional advantages: Additional tags like access=*, fee=*, or opening_hours=* will more likely be kept consistent. I've also seen places where the name=* tag has arguably been misused in a descriptive way to circumvent the issue of the missing safari route relation type.

Tagging

Map the paths as ways and tag them as usual. Since this proposal mostly aims at car or bus routes mostly inside safari parks, highway=service will likely be the correct classification, though other path types are conceivable. oneway=* tagging is often applicable.

Then, add all ways to a relation with type=route and the newly established tag route=safari. Use member roles according to the established structure for route relations. For more details on good practice for more complex (hiking) route relations I recommend the talk Many paths lead to the summit - Complex hiking and cycling routes in OpenStreetMap held at the 2025 State of the Map Europe conference.

Optional tags might include:

• name=*
• access=customers (or any other applicable value)
• fee=*
• opening_hours=*
• operator=*
• Transportation type specific access tags like motorcycle=no or foot=no.

Examples

I added route relations in Serengetipark Hodenhagen in Germany, which is a typical example of a safari route inside a dedicated safari zoo, as well as to Arapaho National Wildlife Refuge in Colorado, USA, which is an example of a very similar dedicated safari drive, though this one is not part of a touristic safari zoo where the regular zoo tagging would apply.

Impact on Data Consumers

Because this proposal does not affect existing tags and would only lead to new relations being created, data consumers are not impacted. However, there are new opportunities for specialized renderers, travel planing platforms and other 3rd party services, if they decide to implement safari road specific applications.

Features/Pages affected

• Tag:zoo=safari park
• Key:route
• Relation:route

External discussions

The idea for the original proposal started in Note 4330704. I then proposed Proposal:Safari Service Road, pivoting to a route based approach instead after gathering community feedback.

• RFC in the Forum: https://community.openstreetmap.org/t/rfc-feature-proposal-safari-route-relation-type/142996

Voting

Instructions for voting

• Log in to the wiki if you are not already logged in.
• Scroll back down and click "Edit source" next to the title "Voting". Copy and paste the appropriate code from this table on its own line at the bottom of the text area:

To get this output	you type	Description
I approve this proposal.	{{vote|yes}} --~~~~	Feel free to also explain why you support the proposal!
I oppose this proposal. reason	{{vote|no}} reason --~~~~	Replace reason with your reason(s) for voting no.
I have comments but abstain from voting on this proposal. comments	{{vote|abstain}} comments --~~~~	If you don't want to vote yes or no but do have something to say. Replace comments with your comments.

Note: The ~~~~ automatically inserts your name and the current date.
For more types of votes you can cast, see Template:Vote. See also how vote outcome is processed.

• I approve this proposal. I mapped the stated example in Colorado and we need some way of being able to identify this type of road. For the record, I preferred the original proposal --IamPersistent (talk) 22:28, 28 April 2026 (UTC)
• I approve this proposal. Comment on my initial abstain vote: It's not clear to me whether the tag describes a road type (i. e. a physical feature like highway=tertiary) as indicated by "where tourists can take their car" or an itinerary (i. e. a non-tangible, abstract feature like route=bus) as indicated by "The tag is not supposed to be used on roads/routes that happen to be used by some hotel for their safari tours sometimes". --Martianfreeloader (talk) 07:01, 29 April 2026 (UTC)

Replying to

 Martianfreeloader (on OSM · edits · contribs · heatmap · comments): You can think of them like hiking route relations: They are a collection of the real, physical hiking paths, but are themselves not entirely tangible. The information value, aside from additional tags like fee or operator, lies in which tangible road objects are grouped together. --PizzaTreeIsland (talk) 07:33, 29 April 2026 (UTC)

Thanks. I've changed my vote from abstain to yes. --Martianfreeloader (talk) 10:17, 1 May 2026 (UTC

• I approve this proposal. Makes sense to define that in the wiki and not only to use it. Should be something extractable from e.g. maps or signposting on the ground. There is no reason against it as it doesn't conflict with other mappings. Additional information can easily be put into the route relation. Maybe additional keys could be useful. Segubi (talk)
• I approve this proposal. --Zimtschnecke (talk) 18:14, 1 May 2026 (UTC)
• I approve this proposal. --MDe (talk) 12:11, 3 May 2026 (UTC)
• I approve this proposal. It makes sense to do that. --Sébastien P (talk) 13:58, 3 May 2026 (UTC)
• I approve this proposal. --Caboulot (talk) 14:43, 3 May 2026 (UTC)
• I approve this proposal. --Tomas09 (talk) 17:11, 3 May 2026 (UTC)
• I approve this proposal. --Fxvxbvbcbc (talk) 02:39, 4 May 2026 (UTC)
• I approve this proposal. --Kytta (talk) 08:06, 4 May 2026 (UTC)
• I approve this proposal. --Reino Baptista (talk) 13:22, 4 May 2026 (UTC)
• I approve this proposal. --Ceirios (sgwrs) 15:27, 4 May 2026 (UTC)
• I approve this proposal. --HuggeK (talk) 12:20, 5 May 2026 (UTC)