highway=turning_circle should be proportionally smaller on highway=service

[matkoniecz]

on highway=service
http://www.openstreetmap.org/?mlat=50.0722&mlon=19.9207#map=16/50.0722/19.9207

on highway=residential
http://www.openstreetmap.org/?mlat=50.0822&mlon=19.8926#map=16/50.0822/19.8926

[matthijsmelissen]

Thank you for reporting that. Unfortunately, the turning_circle itself does not have a tag that registers on what type of highway it is, and getting information from connecting roads is not that easy. Does anyone have an idea on how to handle this?

[gravitystorm]

the type of road that the turning circle is on is already computed. The tag int_tc_type can be used. See e.g.

openstreetmap-carto/roads.mss

Line 209 in 8a270f7

[int_tc_type = 'service'][zoom >= 16] {

The problem is that we don't take into account the INT-minor classification when looking at service road turning circles, so driveways are very thin but the turning circle is generic for all highway=service.

[matthijsmelissen]

Ah, I see. Taking into account INT-minor would involve a change to the osm2pgsql style, right?

[gravitystorm]

No, INT-minor (like int_tc_type) is a synthetic tag created in the sql queries. e.g.

openstreetmap-carto/project.mml

Line 676 in 8a270f7

"table": "(select way,highway,tunnel,\n case when service in ('parking_aisle','drive-through','driveway') then 'INT-minor'::text else 'INT-normal'::text end as service\n from planet_osm_line\n where highway in ('motorway','motorway_link','trunk','trunk_link','primary','primary_link','secondary','secondary_link','tertiary','tertiary_link','residential','unclassified','road','service','pedestrian','raceway','living_street')\n order by z_order) as roads_casing",

And of course, since we're using it for the width of the service roads, we can also use it for the diameter of the turning circles by copying the sql around.

[matthijsmelissen]

Ok, in the case I can implement this.