highway=track renders at a lower zoom level than highway=service

[btwhite92]

Currently, "highway=service" stops rendering at z=13 and "highway=track" at z=12. At z=13, this causes 'track's to appear disconnected. The problem is illustrated below, where 'service' roads are used to access specific facilities (as shown: an antenna facility, fire lookout, and parking area for a trailhead), and 'track' roads are used only for forestry/recreational purposes:

'Service' roads generally perform more important functions than 'track' roads, and thus 'track' roads should render at no lower a zoom level than 'service' roads do.

[Adamant36]

"Service' roads generally perform more important functions than 'track' roads"

That really depends on the individual service or track road doesn't it? I don't think a driveway in most instances is more important then a forest access road.

There's two ways to go about this in my opinion. Render one lower or the other higher. Neither one sounds that great. Plus, things with highway=service should probably be tagged more specifically. I'm seen more than a few service roads stripped of specific tagging due to the current rendering. That's another issue though, I guess. Except to say, rendering of service roads could generally be improved.

[btwhite92]

I agree that more specific service tagging would be useful, though would likely open up another pandora's box of road tagging issues. Common minor service roads (driveways, drivethroughs, etc) don't show at z=14 for good reason and aren't really what I'm referring to here. I would consider an otherwise unspecified service road to be of similar importance to the average track, both being minor ways used primarily to access a specific facility. Thus, they should stop rendering at the same zoom. If a way serves as some kind of through-route through the forest (improved road surface, connects forest facilities, on USFS lands: USFS classification as Collector or Artery or horizontal reference signage) then it should probably be tagged as at least unclassified, rather than track.

[Adamant36]

Common minor service roads (driveways, drivethroughs, etc) don't show at z=14 for good reason and aren't really what I'm referring to here.

Things tagged as highway=service without a more specific tag can be driveways etc though. Since it's essentially a catch all for any type of service road that the person doing the edit just doesn't feel like tagging more detailed. I've seen plenty of driveways just tagged as highway=service and a lot of driveways get the service=driveway tags stripped from them because highway=service renders thicker/at a different zoom level. Which is what I was talking about above.

Unless I'm miss understanding what your saying. Which is totally possible.

[imagico]

Thanks for the report, @btwhite92 - this is a valid concern.

The German style which unifies service roads and grade1 tracks into a common design by the way has the same problem - CC @giggls.

[giggls]

In German style unification of service and track starts at zoomlevel 14.
I'm doing the same as upstream in 13 AFAIR. IMO service should be extended to 13 as well.

[btwhite92]

I've seen plenty of driveways just tagged as highway=service and a lot of driveways get the service=driveway tags stripped from them because highway=service renders thicker/at a different zoom level.

I would consider that a tagging problem, not a rendering one. Most unspecified service roads in well-tagged areas are more significant than a parking lot aisle or driveway, which is why they are rendered at lower zoom than those. My argument is that these otherwise-unspecified service roads are more or less equal in importance to tracks (they're basically service roads for agricultural and forestry lands), so they should stop rendering at the same level. If it's been agreed that service roads are too insignificant to merit rendering at z=13, then the same should be done for tracks due to their similarity.

Should we be specifying every highway=service with a service=*? Probably, but I think that's a discussion for tagging talk rather than osm-carto.

[matkoniecz]

and a lot of driveways get the service=driveway tags stripped from them because highway=service renders thicker/at a different zoom level.

It is a blatant case of tagging for the renderer ( https://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer ) that should be reverted.

[imagico]

If anyone decides to work on this - it is related to #1591.

[Adamant36]

It is a blatant case of tagging for the renderer ( https://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer ) that should be reverted.

Totally. I usually revert it when I see it. Unfortunately a lot of it that I've seen came from Telenav editors and they should really know better. I think it's a good example of why/how rendering could be improved at least.

[btwhite92]

We already dropped rendering of quite a few minor features at z=13 with #3467 that I would consider to be on the same order of importance as a track. Might be easiest to just drop track at this zoom as well? That narrows #1591 to dealing with just z=14, at least relative to the ticket's initial complaint.

I might be able to work on this myself; if I have some time in the next couple of days I'll set a tile server up on my computer and play around a bit.

[Prince-Kassad]

Dropping tracks from z13 will probably be met by a lot of resistance from community members who use the slippy map for hiking. highway=track is by definition only used in rural areas and never in urban settings so it doesn't face the same issues as e. g. highway=footway.

I have to admit I would not have supported some of the changes in #3467, for example lack of highway=pedestrian on z13 produces visible gaps in European city centers and just makes the map look strange. And highway=pedestrian areas (as opposed to ways) only start getting rendered from z15 which means underground parkings under highway=pedestrian areas get to show up on z14 that would be covered up on higher zoom levels.

[jeisenbe]

I would support moving highway=service back to z13 rather than removing highway=track from this level.

[jeisenbe]

Is anyone have a reason to oppose rendering highway=service at z13 again?

This would go along with the suggestion to restore the rending of highway=pedestrian at z13 in #3849 and #3961.

[tomass]

Until it is not defined what highway=service without service=* means, or much better - until there will be a default service=* value, you will not be able to understand what type of service road mappers are actually thinking of.
Then without a clear data hierarchy of where service stands in regards of other types like track you will not have a clear data hierarchy.
Without data hierarchy it will be impossible to clearly define a visual hierarchy.
Without visual hierarchy there will not be a clear message and therefore there will always be mappers who will ask service to be moved to larger and to smaller scale, rendered thinner and thicker.

[btwhite92]

Until it is not defined what highway=service without service=* means, or much better - until there will be a default service=* value, you will not be able to understand what type of service road mappers are actually thinking of.

There are too many types of service roads to come up with classifications for them all, let alone differentiated rendering. I'm not understanding what the opposition is to an unspecified service road just meaning "service road that isn't one of the common documented subtypes". As explained in a comment on #3850, there really isn't room to render more than a 'major' and 'minor' type of service road regardless. Defaulting unspecified service roads to the 'major' rendering style seems perfectly appropriate to me, both in terms of rendering and tagging semantics.

I am in favor of returning rendering of 'major' service roads (not 'minor') to z13 as a solution to this issue.

[tomass]

Classification can be very broad. The reasons why service=* tags are mandatory:

• definition "it is not one of X" does not say anything on what it actually is
• without default value (when missing service= has a special value which cannot be explicitly stated by adding some specific service= value, even if it is service=default) it is impossible to fully complete information on service roads in a specific region (because when service tag is missing you do not know if it was identified as "default service", or it was not checked at all).

Both are very important, but the first one makes it impossible to put a service way into a hierarchy which is essential thing in both GIS and cartography.

As a side note: you only need a class in classification when you have an actual use for it. Otherwise it can simply be "major" and "minor" (with corresponding descriptions). Inventing classes/tags for theoretical purposes is wasting everyone's time.

[matkoniecz]

The reasons why service=* tags are mandatory:

It may be a good idea to have service tag for every situation (and in principle I support this). But current tagging situation is that it is possible to have road that should have highway=service and no service tag.

And inventing new tags should happen on the tagging mailing list and/or OSM Wiki and/or other places where inventing new tags is on topic.

[zekefarwell]

Just found this issue because it's been bugging me seeing gaps where highway=service should be at zoom 13. I'm pretty sure I've tagged some roads as unclassified because they led to sections of track that looked disconnected at zoom 13 when service was used. Maybe incorrect in hindsight, but the visual feedback of the rendered map made service seem less important than track, and therefore the wrong choice. I think rendering highway=service and noservice tag at z13 would be good.