WIP: Feature/aeroways

[jdhoek]

This is an experimental PR. In addition to the proposed width=*-based rendering and centreline for runways, it also shows how these would work with the proposed aeroway=stopway and runway=displaced_threshold additions that are already in active use. Support for these tags is placed in separate commits to enable maintainers to cherry-pick only what is relevant at the moment. The rest can be considered in due time as those proposals mature.

---

This PR introduces some thoughts on #4340. It is split up in several commits, because some features rendered here are still in the process of being finalized as proposals.

Features in this PR

Below the potential issues for each commit are listed.

Use the width of a runway for rendering, if set

Uses SQL function suggest by @imagico for converting metres to pixels.

• Rendering based on width is new, may have unforeseen consequences
• Impact on performance unknown (outside of my area of expertise)

Add support for runway=displaced_threshold

Looking ahead to this feature which is already seeing use and how it combines with the above.

• Tagging is still a proposal (seems to be progressing well though)

Add rendering for aeroway=stopway

Same as above. Not quite as important though.

• Tagging is still a proposal

Different runway rendering for paved/unpaved, etc.

With width taken into consideration, unpaved runways with a good width look a bit off. Rendering 'unpaved' runways differently makes sense, as they tell the map user a lot about the airfield.

• Could introduce confusion in the design language of airfield features (looks good though)

Render grass runways more grassy

Grass runways are pretty common. Even larger airfields can have these in addition to wide paved runways for gliders and such. Having them rendered in green tints is a visual improvement.

• Could introduce confusion in the design language of airfield features (as above, and makes sense for runways at gliderports etc.)

Render area:aeroway and taxiway with width

Airfields have a huge amount of area devoted to runways and taxiways. The nominal width of these does not cover everything. Mappers have used area:aeroway to map the areas as well. Rendering them looks good, and helps pull the airfield features together.

• Using width based rendering for aeroway=taxiway goes a bit beyond runways
• Again, impact on performance unclear
• May need tweaking to work well alongside aeroway=apron

Render aeroway=parking_position and aeroway=taxilane

• Needs resolution on taxilane proposal

---

Before

After

[jdhoek]

Reference photo of the same military base:

[jdhoek]

This was tested with this input:

Valid:

50
50 m
0.05 km
.05 km
0.03 mi
0.03 nmi
164'1"
50.0
164'
1969"

Broken (returns NULL)

AA"
AA
AA.A
.A
.A m
A m
A.A m

[jdhoek]

Example of BER (Berlin Brandenburg) with aeroway=stopway:

[jeisenbe]

The rendering examples look great.

However, I'm a little skeptical about adjusting the width based on non-standard units like feet, km, inchs, miles etc - But I believe we only need to support meters: "Runway widths are usually standardized, typical values are 60 m, 45 m, 30 m, 23 m or 18 m." - per wiki page.

I also would prefer if there were a different rendering for unpaved runways, since they will not have the center line markings, but that does not necessarily need to be addressed right now.

[jdhoek]

The units can probably be safely cut down. I found:

width=Villa Angela Airport
width=Approx. 20 m

I also would prefer if there were a different rendering for unpaved runways, since they will not have the center line markings, but that does not necessarily need to be addressed right now.

Yeah I figured that would be desirable. For now I've just stayed with the same fill colour it already had. I can add that if you have an example airfield on OSM somewhere I can reference and an idea which tags to filter on.

[jdhoek]

Overpass: https://overpass-turbo.eu/s/14YG

Any width on a runway that doesn't look like 50 or 50 m.

[imagico]

I have not looked at this change in more detail yet but you should probably take into account that intermixing a change for ground unit width rendering with feature additions, in particular of fairly exotic and undocumented tags, would make it much less likely for the whole change to be accepted. As a proof of concept demonstration this is fine and it does not hurt to explore the options here. But you will need to expect that only parts of that likely have a chance at the moment to be included in this style.

Also don't forget to test your change also at lower zoom levels. At the moment your change removes all existing zoom level logic which is not going to work.

[jdhoek]

[…] in particular of fairly exotic and undocumented tags […]

Which tags do you mean? Both runway=displaced_threshold and runway=stopway have decent proposals, adequate documentation, and broad adoption despite still being in the proposal stage. These are not exotic or undocumented by any reasonable standard.

But you will need to expect that only parts of that likely have a chance at the moment to be included in this style/

Obviously, which is why this PR holds three separate commits. The second and third deal with these two proposed tags. I'm not suggesting proposals still in the process of gaining acceptance be rendered. You probably missed my comment in #4340:

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.

---

Also don't forget to test your change also at lower zoom levels. At the moment your change removes all existing zoom level logic which is not going to work.

I'm not seeing much of a regression at lower zoom-levels with these larger airports. Do contribute some examples where you think it might break, because you obviously know something I don't.

---

Also:

This PR misses this function @imagico supplied, because I don't know where to put it.

Can you answer this question, or is this the domain of expertise of someone else?

[jdhoek]

@jeisenbe In project.mml this query part is used in several places to determine 'pavedness':

CASE WHEN surface IN ('unpaved', 'compacted', 'dirt', 'earth', 'fine_gravel', 'grass', 'grass_paver', 'gravel', 'ground',
                      'mud', 'pebblestone', 'salt', 'sand', 'woodchips', 'clay', 'ice', 'snow') THEN 'unpaved'
  WHEN surface IN ('paved', 'asphalt', 'cobblestone', 'cobblestone:flattened', 'sett', 'concrete', 'concrete:lanes',
                      'concrete:plates', 'paving_stones', 'metal', 'wood', 'unhewn_cobblestone') THEN 'paved'
END AS int_surface

Is that something to repeat here, or would it be better to limit it to just those values that make sense for runways?

My first instinct would be something like this:

CASE
    WHEN surface IN ('paved', 'asphalt', 'concrete', 'concrete:lanes', 'concrete:plates', 'metal') THEN 'paved'
    ELSE 'unpaved'
END AS int_surface

[jdhoek]

From @jeisenbe 's example of Edwards Airforce Base:

And after dropping area rendering of aeroway=runway:

You can see that without width the default of 20 m is used. Those huge unpaved strips in the desert look exactly 300' (94.44 m) wide! This could stimulate mappers to enter the actual width.

@jeisenbe That might actually be an edge case where the width could be in feet.

The default of 20 m sounds sensible to me because I suspect the majority of runways belong to some small airport with a minimal unpaved runway. Looking at the documentation I suspect either 18 m or 23 m might be more conventional values? What do you think?

[jdhoek]

Another concern about pavedness: should unpaved be the default if no surface is set? This would mean lots of paved taxiways and some runways would suddenly get rendered as unpaved.

The alternative is to accept a lack of surface tag as paved for rendering purposes.

[mboeringa]

You can see that without width the default of 20 m is used. Those huge unpaved strips in the desert look exactly 300' (94.44 m) wide! This could stimulate mappers to enter the actual width.

Another concern about pavedness: should unpaved be the default if no surface is set? This would mean lots of paved taxiways and some runways would suddenly get rendered as unpaved.

As you suggested with the 'width' tag, defaulting to 'unpaved' if no 'surface' is set, might actually help in stimulating users to enter this useful information. I know from my own renderings of airports, where I make these distinctions as well, that many airports, even large ones, lack this information.

Treating it like this, would also be more consistent with how you suggest to treat the width. I also think that even though major airports are important infrastructure, the majority of runways world wide is likely unpaved as being part of some primitive outback or private single runway airport.

[jdhoek]

I'm inclined to agree. It's a change that will garner a lot of feedback though.

[imagico]

Regarding test areas - one with good visibility at low zoom levels would be https://www.openstreetmap.org/#map=11/29.7313/34.8126.

Regarding the scale_factor() function and how to create it - we have no precedent for this. However we meanwhile have indices that are not optional (#4292) so this could serve as a reference point. Obviously documentation would have to be adjusted to inform users of the need to create the function. Keep in mind however so far there is not a clear consensus that using such a function is desirable in the first place. You could alternatively also inline the logic used or use a different method overall like in #1853.

[jeisenbe]

You also need to test narrow runways at low latittudes, e.g. : https://www.openstreetmap.org/way/511570216#map=19/-4.71362/140.73965 - narrow paved runway
Also see: https://www.openstreetmap.org/way/68425968 - located right next to the center of the city

And at high lattitudes, e.g.: https://www.openstreetmap.org/way/7997364 - paved
https://www.openstreetmap.org/way/124722772 - paved
https://www.openstreetmap.org/way/335104289 - gravel

[jdhoek]

A minimum width of 2 (same as it was for this zoom-level) means no regressions here:

Zooming in, the default width seems too small for such runways, but that should be fixed by tagging them with width. This just helpfully points out the missing tag.

---

This one is interesting. Glider airfields seem to have irregular areas for their runways. These are all mapped neatly with area:aeroway=runway plus surface=grass, which isn't rendered. If someone would give these runways a width, you would have to estimate it, but it should fall a bit within the outer limits of the actual field. This may be one area where rendering area:aeroway would have a beneficial effect.

---

Wamena looks good:

---

Kiwirok renders fine, but how does that runway even work?

---

Oppdal seems to match satellite imagery.

---

Note the aeroway=apron there on the far-left used to tag what is probably a stopway. Could be tagging for the renderer. Might be another wish for area:aeroway to be rendered.

---

Kärsämäen seems good:

[jdhoek]

functions.sql file added. Documented in INSTALL.md and added to Docker import task. This works.

[jdhoek]

I like how the unpaved runways look now. There is a risk that we are mixing appearance and function too much, but from a functional standpoint it makes sense to me to distinguish runways that are paved and unpaved. In any case, most professional runways have their ref properly set, which helps to mark them as runways too.

Grass runways still bother me a bit. These are generally speaking even lighter in use than unpaved (which acts as a catch-all, but includes mud flats and compacted ground). A little experimenting:

It's an improvement over this. There is some weird mapping going on there with the unconnected stopways though. And again taxiways lacking surface. This seems common.

[mboeringa]

This one is interesting. Glider airfields seem to have irregular areas for their runways. These are all mapped neatly with area:aeroway=runway plus surface=grass, which isn't rendered. If someone would give these runways a width, you would have to estimate it, but it should fall a bit within the outer limits of the actual field.

Note that in the Netherlands (where this image is from and where I live), it is quite common to see people blindly re-tag an existing landuse polygon from the big "AND" landuse import of years ago, without bothering to adjust it to (current) reality. This is the quickest way to get something visualized, but leads to sub-optimal final results as seen here. As such, I wouldn't pay to much attention to that glider field's rendering result, as it isn't representitive.

[jdhoek]

@mboeringa I checked that area myself with satellite and aerial imagery because it had some tagging errors in it. It is currently mapped fairly accurately. Those area:aeroway parts still have some of the 3DShapes source tags on them, but that was an oversight by whoever split those areas. I often remove these when I edit an entity myself and change the outline, but some always slip through.

[jdhoek]

With the first commit of this PR, the linear feature of runways is rendered with a centreline and the width is taken into account, stimulating mappers to prioritize correctly mapping and tagging it.

For taxiways, using the width parameter seems unlikely to be useful. These act much more like higway=* features on the map. There surface area is still quite large though, and on OSM they are often already quite visible due to the features surrounding them being drawn in — usually grass.

Focusing on aeroway=taxiway I take a look at BER again. This is the current rendering:

Now from this PR the aeroway=runway improvements:

Now introducing a centreline on aeroway=taxiway:

Here the absence of area rendering is being felt though. The mappers who mapped in BER used area:aeroway though, so some further experimenting:

You'll note that the runway area is wider than aeroway=runway, and you can see why here:

I've deliberately used a lighter tone for the area and taxiway fill, to give centre stage to the aeroway=runway. This seems to work. The colours may need to be tweaked a bit.

[mboeringa]

For taxiways, using the width parameter seems unlikely to be useful. These act much more like higway=* features on the map. There surface area is still quite large though, and on OSM they are often already quite visible due to the features surrounding them being drawn in — usually grass.

Taxiways do have standardized internationally recognized widths as well. So to be consistent, I would really suggest to take the same approach and render them based on width and surface tags, instead of falling back to area rendering.

I have added quite a bunch of these tags to Schiphol airport runways and part of the taxiways (mostly in the eastern part), but got distracted and didn't finish the work. However, Schiphol could serve as a testing ground for your rendering.

You can see a couple of them in this rendering, some of the taxiways have a different width in this part. The taxiways in the top left of this image, did not yet get width tagged.

[jdhoek]

Darkening the fill colours slightly seems to improve it:

[jdhoek]

Taxiways do have standardized internationally recognized widths as well. So to be consistent, I would really suggest to take the same approach and render them based on width and surface tags, instead of falling back to area rendering.

Oh absolutely! These are obviously standardized, and tagging them is proper, but unlike runways, taxiways have bends and lots of junctions. It does work though:

But, I think it looks even better with area:aeroway rendering:

This is interesting too, with aeroway=taxiway rendered in the same colour as the runway, but with the surrounding area:aeroway lighter:

Or:

(I've looked at using Schiphol for sampling, but it needs a bit more mapper love in terms of accuracy of grass patches and feature tagging.)

[jdhoek]

In terms of shades of grey the current rendering of aeroway=apron should be taken into account as well of course.

[Nic787]

Are you supporting the threshold node and holding points on taxiways (if render taxiways width)?

Do you plan of supporting stopway?

Your project is very interesting since it would allow a better representation of airfield without the need of area:aeroway=*

I also know there is a dispute about rendering taxilane or not. As I was working on an airfield yesterday in OSM, I found out that it’s a nice feature to use to taxi to gates or parking spots without using the full taxiway. Maybe render that as small line?

[jdhoek]

Are you supporting the threshold node and holding points on taxiways (if render taxiways width)?

I haven't looked at rendering those yet, but it could be interesting to experiment with.

Do you plan of supporting stopway?

I am (already in the screenshots in this thread), but before that can get into Carto the proposal needs to be finished at least. At over 1300 uses it might stand a good chance of getting rendered after that, but that is up the Carto maintainers.

Your project is very interesting since it would allow a better representation of airfield without the need of area:aeroway=*

Thanks, although I personally think area:aeroway can have added value (see the gliderport and the BER screenshots above).

I also know there is a dispute about rendering taxilane or not. As I was working on an airfield yesterday in OSM, I found out that it’s a nice feature to use to taxi to gates or parking spots without using the full taxiway. Maybe render that as small line?

I have looked at aeroway=taxilane and I think it makes sense to have something between aeroway=parking_position and aeroway=taxiway. Officially a proposal, but at almost 4,000 uses it is getting to de facto use levels though.

Keep in mind that this PR is a test-bed — it makes sense to test the various related features in one place. There is no guarantee anything will end up in Carto (although that would be rather nice).

[Nic787]

Thanks, although I personally think area:aeroway can have added value (see the gliderport and the BER screenshots above).

You are right, I actually use it for some parts I'm not sure what to do.

I also know there is a dispute about rendering taxilane or not. As I was working on an airfield yesterday in OSM, I found out that it’s a nice feature to use to taxi to gates or parking spots without using the full taxiway. Maybe render that as small line?

I have looked at aeroway=taxilane and I think it makes sense to have something between aeroway=parking_position and aeroway=taxiway. Officially a proposal, but at almost 4,000 uses it is getting to de facto use levels though.

For taxilane, here is an example of what I did :

Here is a part where it's not really an apron and it doesn't feature taxiway. At first, the person working on the airport used area:aeroway=taxiway, but it just wrong since it's not a taxiway. It's good with rendering, but it's not correct. So I used taxilane to show that planes can move there into the private hangar. But it just doesn't render, so it's just showing hangar floating in nothing. Not sure if I should use area:aeroway=yes as well for this place, but even that is not rendered at the moment.

I was following this chart here.
Maybe you know airport better than me, but is the displaced threshold included in the runway lenght?
For example, following the chart, I included the length to the runway, but not for the displaced threshold. I also added elevation to the first node. I don't know if it's right.

[pnorman]

I haven't looked in detail, but I like the overall direction and cartography I'm seeing. I converted the PR to a draft since it's still a WIP.

[jdhoek]

I converted the PR to a draft since it's still a WIP.

Thanks. Didn't even know that was a possibility.

I'll be adding some examples for aeroway=parking_position and aeroway=taxilane this week. Those, together with adjusting aeroway=apron to match, form the rest of the airfield picture.

[jdhoek]

Also missing: abandoned: and disused: runways. Rendering these is desirable for places like this, but care has to be taken not to get in the way of current use on top of it. This looks like we are missing a part of the map though.

I'll ignore this problem in this branch though. but mention it for the record.

[HolgerJeromin]

A disused runway is still a runway. But this perhaps opens the box of pandora.
ref #2030

[jdhoek]

Some images are scaled down, click for larger.

After some testing with aeroway=apron, aeroway=parking_position, and aeroway=taxilane I've found that using the tagged width for taxiways is probably too tricky to get right at this point. This is mainly due to its broadness overlapping service ways it crosses. It needs some really clever handling of layers to get that right. It's a shame, but for now I've turned it off (aeroway=runway keeps it of course):

(OSM)

You can see the ends of aeroway=parking_position marked by a cross-bar (its ref is rendered only at z18). This is possible because the tag is strictly defined as having the end of the way as the position of the nose wheel. A benefit of rendering this is that it makes it easy to spot mistakes:

Here two ways join to end up on one parking position. The correct way of tagging is to use something else for the forked part — which brings me to the following: aeroway=taxilane should really be rendered as well when aeroway=parking_position is. aeroway=taxilane sits between aeroway=taxiway and aeroway=parking_position in terms of hierarchy. For rendering purposes I am treating the similarly, and I am pleased with how this looks. By keeping these two subtle (just the yellow centreline) they add information, but don't drown out anything else. A benefit of working on these tags of course is that you generally do have some space available on the map because aeroplanes need space in real life.

z16

(OSM)

z17

z18

---

aeroway=taxilane is of course a proposal, but it just crossed 4,000 uses. Its status needs resolving before Carto can start using it, but it's too common to ignore in this draft.

[jdhoek]

@Nic787

Maybe you know airport better than me, but is the displaced threshold included in the runway lenght?

It seems to be commonly considered part of the runway length. That is why it is was eventually made a sub-tag in that proposal (but aeroway=stopway isn't).

Here is a part where it's not really an apron and it doesn't feature taxiway. At first, the person working on the airport used area:aeroway=taxiway, but it just wrong since it's not a taxiway. It's good with rendering, but it's not correct. So I used taxilane to show that planes can move there into the private hangar. But it just doesn't render, so it's just showing hangar floating in nothing. Not sure if I should use area:aeroway=yes as well for this place, but even that is not rendered at the moment.

I'm not sure myself how broad aeroway=apron can be applied, but I am leaning towards all areas where aeroplanes can be parked, demarcated by the typical red responsibility border. From the airfields I am testing I can usually manage with just area:aeroway=runway, area:aeroway=taxiway, and aeroway=apron, and get a fully mapped whole.

Judging from the wiki-page I would say you could map that area you showed as an apron. If you can see the red line you could follow that. Kind of hard to see there though!

If I would have to guess I'd say that the apron is currently drawn too large, and it probably shouldn't overlap with taxiway A.

I think you are using aeroway=taxilane correct there, although there is still some vagueness in documentation and actual use over where it should end (i.e., exactly on the responsibility border line, or at the junction with the first 'full' taxiway — I am looking into this).

[mboeringa]

After some testing with aeroway=apron, aeroway=parking_position, and aeroway=taxilane I've found that using the tagged width for taxiways is probably too tricky to get right at this point. This is mainly due to its broadness overlapping service ways it crosses.

Why do you consider that a problem? Runways and taxiways, as being dangerous areas, should always have priority over the service ways in rendering. In reality, the sections of the service way that crosses a runway or taxiway, is also not marked on the runway or taxiway, so not visible as well, so it only seems just to break up the line and cover the service way in rendering with a taxi- or runway.

E.g., see these service ways at Schiphol crossing a runway and taxiway:

[jdhoek]

The runway blotting out the service way is fine, and I think expected. Service ways really don't run across runways in any distinguishable sense: they mostly just end at the edge and start again at the other edge of the runway.

But with taxiways there service ways that have their own markings are more common:

This is at BER, between aprons. These are taxiways (not taxilanes at this point) near the terminal side of the airport, where service ways are not just there for emergency access but are part of the day to day operation of the airport. I fear that there may be too much collateral damage by rendering the taxiway width.

There are more problems that popped when I put in the width, in particular where a taxiway ends at the edge of an apron. It looks really good in some places, but I found the results not as coherent near aprons and service ways. It's worth experimenting with I guess, but I couldn't get it right.

Agreed on your two screenshots though, there is not much lost there by covering those service ways.

[mboeringa]

I fear that there may be too much collateral damage by rendering the taxiway width.

Well, in terms of "damage", by rendering the tagged width, it would become more clear what is the actual immediate danger area when crossing this junction of taxiways. By rendering it in a less conspicuous default width, the area of conflict is not becoming clear.

Do you possibly have an example image of how it works out here?

[mboeringa]

@jdhoek , I just finished some work on Schiphol airport, if you need another reference.

I added width to all taxiways and other features missing it, and fixed a number of really problematic digitization choices, see the attached images where taxiways junctions are drawn as a single way, where they clearly should be split. This would inevitably cause weird rendering artefacts. I think I fixed about 15 or so of these cases at Schiphol airport.

[jdhoek]

@mboeringa I'll make some more reference renderings in a bit.

[jdhoek]

Just a heads up: there are a few things that need to be done to get this PR to a state where it can be considered for inclusion in its entirety, but some of these are outside of my control:

• The runway=displaced_threshold proposal needs finalizing (seems to be used in a lot of places with almost 500 instances, considering runways have at most two of these sections).
• The aeroway=stopway proposal needs finalizing (seem as above, but usage exceeds 1,300; that's over 650 runways).
• The aeroway=taxilane proposal is abandoned (I have contacted the author) and needs championing to formalize it (at over 4,000 uses, it is hard to ignore). I do have some ideas on how to move this forward, but that will take some time.

Some things I wish to tweak further:

• Experiment more with rendering of aeroway=taxiway width, as indicated above.
• Finalize experiments with aeroway=parking_position (these sit right next to aeroway=taxilane in the hierarchy, hence the need for that tag to get formalized).

However, some parts of this PR might be presented in a separate non-draft PR if there is call for that. I can open a PR with the parts of this PR that do not depend on the three proposal mentioned above for review, but waiting to resolve the issues mentioned above and seeing the proposals get finalized is also an option.

The benefit of having a part of this PR presented for inclusion may be that it is easier to review, and the benefit of keeping this all in one PR is that all these related parts will work well together. Do the maintainers have a preference one way or the other?

[imagico]

You will need to decide if and when you want to work on proposing concrete changes for inclusion in this style. If you do so i would - as mentioned already above in #4346 (comment) - suggest to not mix several relatively independent changes in the same pull request. What you show combines at least three fairly separate classes of changes (ground unit rendering, feature additions and design changes of existing features).

For rendering of paved/unpaved you should keep in mind that we have a long standing issue of rendering that for roads in general (#110) and a proposal how to do so that includes aeroways (#3399/#4137). An alternative proposal for that will therefore be looked at w.r.t. if it can be extended to roads in general.

Personally i would like to see a transit to ground unit rendering for runways and taxiways based on tagged width for the high zoom levels being added to this style (obviously - i made the first proposal to do that). I have not formed an opinion on most of the other changes (though i can see some design ideas that will quite definitely not work in your examples).

[jdhoek]

If you do so i would - as mentioned already above in #4346 (comment) - suggest to not mix several relatively independent changes in the same pull request. What you show combines at least three fairly separate classes of changes (ground unit rendering, feature additions and design changes of existing features).

The reasoning behind this is that these are all aerodrome features that work together. Not looking at the interplay between these related features and the way mappers tag them would seem like a waste and lead to a cartographic style that lacks coherence.

For rendering of paved/unpaved you should keep in mind that we have a long standing issue of rendering that for roads in general (#110) and a proposal how to do so that includes aeroways (#3399/#4137). An alternative proposal for that will therefore be looked at w.r.t. if it can be extended to roads in general.

I have looked at those, and while the goal of rendering their paved/unpaved status is similar, there are some differences. I don't think the approach in terms of the SQL queries proposed here clashes with those proposals, but runways do have slightly different semantics because values like surface=cobble_stones makes no sense here, and grass runways are a common feature for glideports and such.

Is there anything in particular I should adapt from #4137? Airport runways have slightly different needs compared to highways, so treating them exactly the same is probably not the best approach. Matching the rendering styles to somewhat match may be, but I don't get the impression that the currently proposed rendering there is acceptable at the moment.

However the experiments above show that rendering the unpaved and grass runways differently is beneficial both for mapper feedback of the surface tag, and with the use of width for preventing small but wide runways (or those with no width tag) from showing up way too prominently and 'asphalty'.

(though i can see some design ideas that will quite definitely not work in your examples).

Anything in particular?

[LaoshuBaby]

Will this feature continue to be updated and added? Because it looks really well

[jdhoek]

@LaoshuBaby Thank you. Yes, I will update it with a few further refinements; see my comment from April 15 for a list of items.

In the mean time I am willing to make a PR containing only rendering for features using tags currently approved; I have asked a few questions regarding this above, but @imagico hasn't responded yet.

[imagico]

Regarding:

Is there anything in particular I should adapt from #4137?

No, but as said if you want to propose distinct rendering for paved and unpaved runways you should consider if and how your suggestion can be also used for roads - i.e. in terms of a solution for #110: An alternative proposal for that will therefore be looked at w.r.t. if it can be extended to roads in general.

(though i can see some design ideas that will quite definitely not work in your examples).
Anything in particular?

If i look at the changes you show as a concrete proposal for changes to this style there would be several. But i think it is important to give room to developers to explore and discuss design ideas even if they don't work together with the design paradigms of this style. Only if you have that freedom you will be able to develop new ideas that work here.

If and when you decide to make concrete suggestion for changes you should - as pointed out - consider separating such changes into distinct groups of changes (ground unit rendering, feature additions and design changes of existing features), consider the cartographic design rules and also take into account the non-codified paradigms this style typically follows, in particular that we don't aim to create a simulated aerial imagery type map style and that our rendering is primarily aimed at representing the meaning and purpose features have for the target map user and that we want to avoid design elements to be mistaken as mapped geometries. This and some further helpful practical rules can be found on #2462.