Utility poles rendered within tertiary highways at z16 to z18

[jidanni]

Despite one's best efforts in the editor
openstreetmap/iD#6925 (comment)
it is still a fact that most utility poles will end up getting rendered within a road.

Everybody knows that utility poles are on the side of a road, not within it. Don't get me wrong: rendering utility poles is very important. Just please, when rendering a road, render the pole to the nearest edge. Thanks.

Autopilot cars will also thank you, no more fear of slamming in to them.

Don't worry. If they are really in the center of a road, they will be on a traffic island.

[jeisenbe]

Area discussed in the linked comment: https://www.openstreetmap.org/#map=17/24.19249/120.87513

Node example: https://www.openstreetmap.org/node/4778301333#map=19/24.19948/120.87570
(Is this a very narrow road, with the poles quite close to the edge? This node is only 1 meter from the centerline of the highway=tertiary way. Perhaps the source of the data for the road and the source for the poles are not aligned properly? It will also be easier to understand once the power=minor_line is mapped)

However, many of the properly-aligned poles and roads will show overlap at z16 and z17 in places like Taiwan which are near the equator, since the tertiary road rendering at z16 and z17 is over 20 meters wide (10 pixels is 24 meters at the equator at z16, and 18 pixels is 21.6 meter at z17). Since many tertiary roads are only 6 to 8 meters wide, the rendering is quite a bit wider than the real feature at these zoom levels.

We could improve this a little by narrowing the rendering of tertiary highways at z16 to z19. This would probably require changing the color to yellow, which means that motorways would need a new rendering as well.

when rendering a road, render the pole to the nearest edge.

This isn't very easy to do with this map style and the rendering toolchain we use. It might also confuse mappers if poles close to roads were moved farther out, but those farther away were at the precise location. Such pre-processing of data is more feasible for specialized map styles and custom maps.

[jidanni]

Streetview gives you a general idea. Anyway trying to better position these pole will in fact probably just make things worse, as we are not supposed to "edit for the renderer" anyway.

Different sized roads at different latitudes? There should be a formula to keep them the same size no matter what latitude!

Yes, yellow would be better than "red dashes" etc.

[pnorman]

This isn't very easy to do with this map style and the rendering toolchain we use. It might also confuse mappers if poles close to roads were moved farther out, but those farther away were at the precise location. Such pre-processing of data is more feasible for specialized map styles and custom maps.

It's both not possible, and not something we want to do. It's not practical to reposition poles or other POIs away from roads given the constraints of processing that can be done in a reasonable amount of SQL. It's not something we want to do because we want to avoid preprocessing or altering geometries as one of the style goals because it's used for mapper feedback.

[jidanni]

because it's used for mapper feedback.

OK, I will from now on place roadside poles 12 meters away from centerlines of two meter wide roads despite
https://wiki.openstreetmap.org/wiki/Good_practice#Don.27t_map_for_the_renderer .

[kennykb]

On Wed, Oct 9, 2019 at 2:47 PM 積丹尼 Dan Jacobson ***@***.***> wrote: because it's used for mapper feedback. OK, I will from now on place roadside poles 12 meters away from centerlines of two meter wide roads despite https://wiki.openstreetmap.org/wiki/Good_practice#Don.27t_map_for_the_renderer .

A better request might be to ask the renderer to pay attention to `width=*` on highways at very high zoom levels, so that the road will be rendered at a suitably narrow width, and then leave the utility poles right where they are. At a low zoom level, there's probably nothing that can be done to keep the poles off the road - once they're less than a pixel apart, a rendering would either have to distort the geometry or accept the collision. The design of the main renderer is that it's geometric rather than schematic, so (except for rendering linear features with a given minimum width) it doesn't distort some features to accommodate others. -- 73 de ke9tv/2, Kevin

[jeisenbe]

While @pnorman is correct that we can't completely fix this issue, we could keep it open until we render tertiary roads more narrowly. If tertiary roads were 30% narrower, many of the poles in the example images would not overlap with the road rendering at z17 and z18.

@kennykb suggests adjusting by width= tags - this was considered too complex back with #1853 for aeroway=runway

[kocio-pl]

So this is related to #3540 - it would help to avoid artificial fusing one-way tertiary lines.

[jidanni]

Well all I know is mom and pop editors hurriedly pick "minor road" etc. thus would never think of width=. Plus twisty country roads don't have much of a constant width in poorer countries. Also in the editor one is simply focused on "put the pole next to the road", which he does, and expects it to stay that way...

[jeisenbe]

I've edited the title to "Utility poles rendered within tertiary highways at z16 to z18" and reopened the issue, since we can partially solve this by a narrower rendering of highway=tertiary

[newtestaccount4949]

tertiary roads are often already quite difficult to distinguish from residential roads at z16 to z18, so narrowing isn't the best idea

[jeisenbe]

Right, we can only narrow highway=tertiary significantly if we also change the color. See #3540 for an option.

[goldfndr]

Would it be workable to use secondary's color and unclassified's width for tertiary? (and perhaps narrower tertiary_link roads)

[jeisenbe]

@goldfndr - see #3540 for that idea

[goldfndr]

The closest comment I can see to this idea is your comment, but I apparently misinterpreted your "switch the color spectrum" language as "increase the color spectrum", like I did for your comment above. My apologies.

(I did note that construction=secondary uses the secondary color at a narrower width, but it also uses a dasharray, so it's easily distinguished.)