Proposal talk:Safari Service Road

This proposed tagging seems to conflate roads through safari parks, that is, within specially designed zoos, with roads through the wilderness that are marketed as good for wildlife viewing. These strike me as not the same thing at all, and I don't think they should be tagged the same. Some new tag, like service=safari_park or something, might be suitable for the first, but roads through the wilderness seem more similar to a scenic drive or auto tour, which are usually tagged as road route relations or with scenic=yes. --Willkmis (talk) 20:23, 22 March 2026 (UTC)

The tag aims purely at safari roads which are designated for that purpose. As far as I understand, the roads in the Colorado example wouldn't have been built if it was not for a safari drive attraction. That's why I think the tags still fit there. It would be a different story if the roads were not solely part of any sort of tourist attraction, but also a normal road people would use to get places.In these cases,I agree the service=safari tag doesn't make sense, but I feel like that is an important distinction. --PizzaTreeIsland (talk) 20:39, 22 March 2026 (UTC)

Unclear proposal

The proposal text is limited and does not tell me what this is other than roads inside a zoo.

If it is for a route you must/can drive through a large animal enclosure, then I think a route relation is better. You could propose route=safari tagged on the relation to make them easy to find.

The proposal does not mention if this is suited (or not) to large reserves that are described "safari" like Kruger National Park. These have many roads in that you can use to see the animals, you will often have different options. There are different types of roads within those safari parks. Main roads and smaller roads, also service roads that only go to specific buildings (for public access or deliveries). LastGrape/Gregory 15:21, 29 March 2026 (UTC)

I have edited the Proposal segment to further specify what I meant.

You're right that a route relation makes a lot of sense for this purpose, but as I have written, none of the examples I could find are mapped that way. An additional tag for the type of road seems like a less invasive change to the way these features are currently mapped, somewhat uniformly all over the world.

I had not made this clear earlier so this one is on me, but I do explicitly not mean roads that happen to be scenic and that happen to be used by tourists sometimes as part of a safari tour, but roads that were specifically built for the purpose of driving through or around animal enclosures. In that case, the conflict of the "main type of road" or the "main purpose of that road" you are alluding to does not happen. Instead, those roads are already mapped as highway=service, only that there is no further specification, leading to ambiguous tagging or at least lack of specificity PizzaTreeIsland (talk) 18:02, 29 March 2026 (UTC)

This proposal is redundant

If you want to find service roads in safari parks, you shouldn't be creating a tag for them. Instead, you use a GIS tool like Overpass or QGIS to select all (relevant) safari parks and then query service roads within their boundaries. We shouldn't tag objects based on where they are located, otherwise we'd only be creating a new version of the old is_in=* tags. --501ghost (talk) 17:50, 29 March 2026 (UTC)

I disagree because there are service roads for staff/emergency access/whatever inside those safari zoos that are not built for tourists and there are also safari roads that perfectly fit the definition I am trying to give but that are not mapped as part of /inside of safari parks. See my second example for that. PizzaTreeIsland (talk) 17:57, 29 March 2026 (UTC)

Car/bus oriented proposal

Thank you for the proposal and discussion. Eventhough I can understand where you are coming from I would vote for a solution which is not limited to a transportation methods. There are zoo with safari by foot, train on track, boat... Even swimming or snorkling?

1. Having paths/highways going through an enclosure or reserve represented by a surface should already be enough to detect those safari, eventhough I can understand that it is less straightforward to query and process. Alternatively, consider putting attributes on the enclosures or reserves instead of on the path crossing it to avoid being stuck with one transportation mode and separate the paths scheme from the zoo scheme.
2. If on the path itself, I would recommend to look for tags which can be applied to any type of way (safari=yes? Just an idea) or to consider some kind of safari/scenic relations.

LeTopographeFou (talk) 17:35, 30 March 2026 (UTC)

Thank you for your comment! I get where you're coming from. Your ideas would further connect different kinds of safari experience together by using a common tag, which I can see an appeal in. I think that would also make it more complicated, though, because the distinguation between a safari type object and a "normal" object falls apart a bit. There is next to no ambiguity if a safari road for car/bus tourism is a safari road, but where exactly is the line between a walking safari path and a normal footpah inside any normal zoo? Additionally, the safari roads I wanted to describe are clearly roads so I chose something that fits the road tagging structure. Making it work with footpaths, railroads and whatever else could work, but would make it fit less well into the road tags. It would additionally not solve the problem of the "missing" service value, although I admit that problem is not huge. My approach was coming from mapping road infrastructure and seeing a need for a tag for this very specific kind of feature. Making it more universal has some advantages, but brings its own problems.

Regarding using route relations instead: I agree it is a perfect use for relations, and a route type called safari also came to mind when I first got the idea (you can read in the note comments linked under external discussion), but I eventually decided against using relations because they're, as far as I can tell, never used already, so adding a new tag to an existing structure felt less invasive than restructuring how those features are mapped completely. In addition to, again, the "issue" of the missing service value if the safari info gets mapped inside the relation instead of the road itself. PizzaTreeIsland (talk) 18:09, 30 March 2026 (UTC)

I agree that a generic tag may be more useful.

A tag like safari=yes could apply on a node/way or route=safari on a relation describing an on purpose built structure and not only on highway=service.

Examples :

• a marked snorkeling route ; more info (fr);
• a road in a zoo that should probably be a highway=service but was not be created as such

But you are right: what is the difference between these elements and a normal foot path inside a zoo? should it be also tagged as safari=yes? Maybe...

I can see that we could then also have botanical=yes, geology=yes... Actually we already have Tag:route=fitness trail for example, but only for relations and that seems to be fine to me.

We shouldn't say that we can't use a route relation because for now data consumers don't use them...

→ I would prefer a relation, with route=safari MDe (talk) 08:28, 6 April 2026 (UTC)

I agree the route relation format fits the logic very well and since so many people have brought it up, I am considerintlg rewriting the proposal accordingly. It can't be a coincidence that so many people come to the same conclusion. PizzaTreeIsland (talk) 08:37, 6 April 2026 (UTC)