Runway, taxiway areas should not be rendered

[jeisenbe]

Expected behavior

• The centerline of an aeroway=runway or aeroway=taxiway should be rendered, similar to linear highway features.
• We should not render the precise area of an aeroway=runway mapped as a closed way or multipolygon, since we don’t render area:aeroway= or area:highway=
• The area mapping of runways (as a closed way or multipolygon) is uncommon: it has only been used about 5000 times - https://overpass-turbo.eu/s/14r3 - compared to about 1000 area:aeroway=runway (https://taginfo.openstreetmap.org/tags/area%3Aaeroway=runway#overview) - and compared to 55k aeroway=runway overall: https://taginfo.openstreetmap.org/keys/aeroway '
• Rendering the area alone leads to mappers forgetting to map the centerline of the runway as a linear feature.
• Since we don’t adjust the width of the runway renderging based on the width= tag we are unfairly encouraging double-mapping of the area + linear way instead of just linear way + width= (used on 23% of runway features) which is usually providing just as much information.

Actual behavior

• aeroway=runway and aeroway=taxiway mapped as closed ways (or multipolygons) are rendered as as a polygon with color @aeroway-fill = #bbc - same as linear runways and taxiways.

• openstreetmap-carto/style/roads.mss

  Lines 2706 to 2744 in 3618861

  	#highway-area-fill {
  	[feature = 'highway_living_street'][zoom >= 14] {
  	polygon-fill: @living-street-fill;
  	}
  	[feature = 'highway_service'] {
  	[zoom >= 14] {
  	polygon-fill: #fff;
  	}
  	}
  	[feature = 'highway_footway'],
  	[feature = 'highway_pedestrian'] {
  	[zoom >= 15] {
  	polygon-fill: @pedestrian-fill;
  	}
  	}
  	[feature = 'highway_platform'],
  	[feature = 'railway_platform'] {
  	[zoom >= 16] {
  	polygon-fill: #bbbbbb;
  	polygon-gamma: 0.65;
  	}
  	}
  	[feature = 'aeroway_runway'][zoom >= 11] {
  	polygon-fill: @runway-fill;
  	}
  	[feature = 'aeroway_taxiway'][zoom >= 13] {
  	polygon-fill: @taxiway-fill;
  	}
  	[feature = 'aeroway_helipad'][zoom >= 16] {
  	polygon-fill: @helipad-fill;
  	}
  	}

Links and screenshots illustrating the problem

https://www.openstreetmap.org/#map=17/34.94902/-117.86569
Extra-wide runways mapped as areas (though they also have linear ways down the center at least)

https://www.openstreetmap.org/#map=18/36.02450/-119.05629
Runway and taxiways mapped only as areas, linear runway way is missing.

[jeisenbe]

If we do want to render these areas, I believe we ought to change the linear runway rendering so it is apparent if it is missing, e.g. have a dashed centerline which would render above the areas.

[imagico]

Was previously discussed in #1853, see in particular #1853 (comment)

Back then there were objections to removing polygons rendering of runways but it is well possible the public opinion has shifted since then.

As pointed out in the comment linked above currently high zoom runway and taxiway line rendering seems unnecessarily ugly and thereby encouraging polygon drawing.

[jdhoek]

If we do want to render these areas, I believe we ought to change the linear runway rendering so it is apparent if it is missing, e.g. have a dashed centerline which would render above the areas.

I like that idea. Runways are huge in terms of size, and could benefit from such detailing.

Runways always look off to me when zooming in or out, which is probably due to their real-world massive width. Is there a practical objection to using width=* to render it?

[imagico]

The reason for closing #1853 was the complexity of the method (which is due to the lack of native support for ground unit rendering in Mapnik/Carto).

In other context i have more recently used a different approach to this by the way - encapsulating the necessary complexity in a function:

create or replace function scale_factor (geometry)
  returns numeric
  language sql
  immutable
  returns null on null input
as $func$
select ST_DistanceSphere(ST_Transform(ST_Translate(geom, 0, 1), 4326), ST_Transform(geom, 4326))::numeric from (select ST_Centroid($1) as geom) as p
$func$;

If this is preferable here i am not sure - just an option to consider.

[jdhoek]

How do I call scale_factor(geom) in project.mml after adding the function to the database? That is, how do I do something like tags->'width' * scale_factor(geom) AS width?

[imagico]

scale_factor() converts map units (mercator meters) into ground meters. You use it in combinations with the usual method to convert between map units and pixels (!scale_denominator!*0.001*0.28).

[jdhoek]

Promising start for a bit of experimenting. Bugs:

• I can't figure out how to get a value from the SQL query into line-dasharray in the stylesheet to have that match the 1 m line-width of the centreline. line-dasharray takes whole numbers in an array like 20, 30, can I pass them to it from outside? line-dasharray: [sql_field] fails. Any ideas? I could just scale it for every zoom-factor, but the centreline of a runway is big as well, and it seems to look better when kept at the same scale as the runway itself.
• Very naively assuming all runways have a width in metres. 😄 Obviously needs preprocessing in case of feet/miles and explicit unit values like 50 m instead of 50.
• Where do I put scale_factor in the project? I just entered it in the shell of the Docker container now.
• scale_factor(way)*(1/!scale_denominator!)*10000: seems to work. Feels a bit magic-numbery with that 10000.

diff --git a/project.mml b/project.mml
index 22869c1..1217e79 100644
--- a/project.mml
+++ b/project.mml
@@ -1035,11 +1035,23 @@ Layer:
         (SELECT
             way,
             aeroway,
-            bridge IN ('yes', 'boardwalk', 'cantilever', 'covered', 'low_water_crossing', 'movable', 'trestle', 'viaduct') AS bridge
-          FROM planet_osm_line
-          WHERE aeroway IN ('runway', 'taxiway')
-          ORDER BY bridge NULLS FIRST,
-            CASE WHEN aeroway = 'runway' THEN 1 ELSE 0 END
+            bridge,
+            width,
+            sf*width::real AS area_width,
+            sf AS line_width
+          FROM
+          (SELECT
+              way,
+              aeroway,
+              bridge IN ('yes', 'boardwalk', 'cantilever', 'covered', 'low_water_crossing', 'movable', 'trestle', 'viaduct') AS bridge,
+              tags->'width' AS width,
+              scale_factor(way)*(1/!scale_denominator!)*10000 AS sf
+            FROM planet_osm_line
+            WHERE aeroway IN ('runway', 'taxiway')
+            ORDER BY bridge NULLS FIRST,
+              CASE WHEN aeroway = 'runway' THEN 1 ELSE 0 END
+            ) _
         ) AS aeroways
     properties:
       cache-features: true
diff --git a/style/roads.mss b/style/roads.mss
index c750ba2..255663c 100644
--- a/style/roads.mss
+++ b/style/roads.mss
@@ -2975,12 +2975,12 @@ tertiary is rendered from z10 and is not included in osm_planet_roads. */
       }
       ::fill {
         line-color: @runway-fill;
-        line-width: 2;
-        [zoom >= 12] { line-width: 4; }
-        [zoom >= 13] { line-width: 6; }
-        [zoom >= 14] { line-width: 12; }
-        [zoom >= 15] { line-width: 18; }
-        [zoom >= 16] { line-width: 24; }
+        line-width: [area_width];
+      }
+      ::centerline {
+        line-width: [line_width];
+        line-color: white;
+        line-dasharray: 20,30;
       }
     }
   }

[imagico]

As said the conversion factor between pixels and map units is !scale_denominator!*0.001*0.28. In other words:

pixels = ground_meters / NULLIF(scale_factor(way)*!scale_denominator!*0.001*0.28, 0)

[jdhoek]

This screenshot includes support for aeroway=runway plus runway=displaced_threshold (proposal). I have added this to see how this styling works when looking forward to future improvements of aeroway=runway-tagging. It can of course be ignored for now, but was useful to me to tweak the appearance: