Runway and taxiway rendering rework

[pnorman]

Changes proposed in this pull request:

• Refactor aeroways to their own layers. Fixes separate aeroways from rail/road query #2169
• Add a dashed centerline to runways
• Scale runway and taxiways past zoom 16
• Stop rendering runway and taxiway areas. Fixes Runway, taxiway areas should not be rendered #4340

zoom 15 YVR

zoom 17 YNJ

zoom 19 WA07

zoom 16 FRA

zoom 15 SIN

cc @jdhoek

[imagico]

Not looked at this in more detail but a quick remark on the line width progression. What you have right now is this:

For runways:

zoom	line width	max. ground width (in m at 0°)	ratio to previous
12	4	153	-
13	6	115	0.75
14	12	115	1
15	18	86	0.75
16	24	57	0.67
17	40	48	0.83
18	56	33	0.7
19	72	21	0.64

For taxiways:

zoom	line width	max. ground width (in m at 0°)	ratio to previous
13	2	38	-
14	4	38	1
15	6	29	0.75
16	8	19	0.67
17	11	13	0.69
18	16	10	0.73
19	72	7	0.69

As you can see in both cases you have a non-uniform progression, for runways more so than for taxiways.

Also note that the runway width will at low latitudes not drop to less than 21 meters - which is wider than most small informal airstrips you can find in many countries in rural areas. Like for example here:

https://www.openstreetmap.org/#map=12/3.9992/-73.2627

Such runways would with this change even at the highest zoom level be drawn wider than the actual width and potentially covering other features in the map.

The highly variable width runways can have from less than ten meters to 50 meters or more is the main reason why i had suggested in #1853 this would be a good candidate for introducing ground unit rendering based on tagged or heuristically estimated width. We don't have to do this but it would make it much easier to achieve a decent display of very small and very large runways likewise and at different latitudes.

[mboeringa]

Such runways would with this change even at the highest zoom level be drawn wider than the actual width and potentially covering other features in the map.

I don't think that is a particular problem with runways. Even if the actual width of the prepared rural runway is narrow, obstacle clearance will usually be much bigger, and no significant overlap is expected in most cases.

[pnorman]

I've added some ideas from #4346

Also note that the runway width will at low latitudes not drop to less than 21 meters - which is wider than most small informal airstrips you can find in many countries in rural areas. Like for example here:

I didn't find any examples in your link where anything was mapped beside the runway, so nothing looks out of place there. I did look at another small local airport where there was overlap

zoom 18 27WA

I'm okay with there being overlap. The same happens with roads and other features, and it's likely to be less of an issue with runways because there are limited obstacles beside them.

The highly variable width runways can have from less than ten meters to 50 meters or more is the main reason why i had suggested in #1853 this would be a good candidate for introducing ground unit rendering based on tagged or heuristically estimated width. We don't have to do this but it would make it much easier to achieve a decent display of very small and very large runways likewise and at different latitudes.

I considered using width but decided against it, as I didn't want to add too much in one PR, and feel these changes stand alone.

[imagico]

I'm okay with there being overlap. The same happens with roads and other features

No, road width progression typically transits from larger than ground width to less than ground width at z17 or z18, in extreme cases at z19. And we depend on this being the case to reliably provide accurate geometry feedback on all the features we render at least on the highest zoom level. In rare cases, in particular for very narrow tertiary roads (see #3925) we do not accomplish that but this is something we should fix (see #3540) and not extend to other features.

I am not aware of any line features we routinely and deliberately draw wider in their ground width at z19.

I considered using width but decided against it, as I didn't want to add too much in one PR, and feel these changes stand alone.

In that case i suggest to limit the drawing width at z19 to less than the physical width in practically common cases. As i see it that would match our approach with other line features, in particular other road types.

The further design changes seem unclear in motivation to me. For example the chosen line color has less contrast towards the neutral gray fill colors we use for platforms/bridges and it harmonizes less well with the air transport symbol color. I am not aware of any problems with the current color. If you mean to free the current aeroway color for other purposes i could understand but if that makes sense would depend what purpose that might be. If there are other reasons i would like to understand them.

Like in #4346 i would suggest not to mix technical refactoring, design changes and feature additions all in one PR.

[pnorman]

The further design changes seem unclear in motivation to me. For example the chosen line color has less contrast towards the neutral gray fill colors we use for platforms/bridges and it harmonizes less well with the air transport symbol color. I am not aware of any problems with the current color.

There was a transcription error, I got the hue wrong. Fixed. Neither the current colour, incorrect change, nor corrected change bear any particular similarity to @airtransport: #8461C4 with different lightness, chroma, and hues.

[imagico]

Ah, i see. The corrected color is only marginally different from the current one so that is fine with me.

For understanding the concept of harmonizing colors: Originally this style had a distinct violet color scheme for airports composed of the airport terminal building color, the apron color and the runway color. When choosing the air transport symbol and label color in #1033 fitting into that scheme was a major factor:

https://davidjohnstone.net/lch-lab-colour-gradient-picker#cc99ff,e9d1ff,bbbbcc,8461c4

Although we have meanwhile almost completely eliminated that color scheme by changing both the terminal building and apron colors (which introduced problems - see #3891 (comment) and also note the various issues we have with the 'major' building color) the choice and the reasoning behind it still echoes in the combination of runways and the air transport symbols, which practically in particular is visible for helipads. The hues of the air transport symbol color and the runway color are relatively close - close enough to form a harmonic unit. There were and are obviously other constraints.

https://davidjohnstone.net/lch-lab-colour-gradient-picker#bbbbbb,bbbbcc,babacb,8461c4,b1b9c7

The label design as shown would be a major departure from the current labeling paradigm in this style. I am not opposed to that in principle if it makes sense overall and we have agreement that this is a workable direction but i need to study this in more detail and i would also like to understand the reasoning behind the various aspects of this design choice.

One thing in particular to keep in mind here is that the display of runway/taxiway labels and of airport labels and symbols overlaps in zoom levels and having larger and stronger labels for runways than for the airport overall could be highly irritating.

[jdhoek]

I considered using width but decided against it, as I didn't want to add too much in one PR, and feel these changes stand alone.

Understandable. Is it something you would be willing to consider as a follow up? For runways (not for taxiways) it is a marked improvement in rendering due to the large area runways can have in real life.

Thank for picking the label design from my PR. It looks great. I would recommend taking one other feature from my PR though. This is a screenshot using this PR:

Compared with #4346 (different zoom-level):

This runway is mapped in a manner fairly common by now: it splits the runway proper from the displaced threshold and the stopway or blast pad (only runway 05/23, runway 09/27 doesn't have a displaced threshold). Stopways can be ignored here if you are limiting your PR to only the conceptual runway, but for displaced thresholds you might want to consider dropping the label like I did. Runways often are implemented like this in terms of scale and division:

>>>>>>>-------------------------------------------------------<<<<<<<

(>>> being the displaced thresholds)

Not labelling the displaced thresholds fixes runways having multiple unneeded labels, and limits the label to the main runway part. For runways this seems to work quite well.

Displaced runways are tagged like this:

aeroway=runway
runway=displaced_threshold
ref=05/23

[pnorman]

Not labelling the displaced thresholds fixes runways having multiple unneeded labels, and limits the label to the main runway part. For runways this seems to work quite well.

I agree with not labeling displaced thresholds. I'm not sure about using the on-runway marking for them, and would keep that for follow-up work.

The dashed line helps make it clearer what's going on in complex airports with lots of intersecting runways and taxiways. Without it, I find they tend to look like a mess of uninterrupted gray. JFK is one example of it.

[jdhoek]

I'm not sure about using the on-runway marking for them, and would keep that for follow-up work.

Those markings work a lot better when width is used to render the runway line as wide as it is in reality. Leaving out the markings is a good first step.

[crjwalton]

CYPT has a paved runway that is 75 feet wide and a gravel runway that is 15 feet (4.6metres) wide. Painting both runways with the same line thickness is a bit deceiving.
https://www.openstreetmap.org/#map=16/41.7782/-82.6771

[Nic787]

Any update on this project?

I think it should consider width used when tagging, but if it's not tagged, it should have a default width.