
Any suggestions on how to handle lots of tiny private airports? It doesn't look like there is a way to differentiate between tags but perhaps only airports with an ICAO or IATA ref should appear at the z10ish.
Perhaps only areas or relations with the aeroway=aerodrome could be shown. Any way to handle this programmatically?
I think it would be best to have a tag like regular_commercial_traffic=yes or something like that. That would probably be best discussed on the tagging mailing list.
The best we can do with the data we have is check for the presence of an IATA ref. That would not exclude any important airports, but as mentioned here, it might include some tiny airports.
2014-12-01 19:22 GMT+01:00 math1985 [email protected]:
I think it would be best to have a tag like commercial=yes or something
like that. That would probably be best discussed on the tagging mailing
list.
yes, something along these lines. There could be several airport classes.
In the past these ideas have always been rejected (there have been lots of
discussions about this) and it was argued we could use detail data like the
amount of passengers per year and the length of the railway, etc., but for
practical reasons this is still not possible because of a lack of data
(might change and people would probably add these details if the carto team
declared publicly which tags/features would put the airport in say zoom
level 9 ;-)
(might change and people would probably add these details if the carto team declared publicly which tags/features would put the airport in say zoom level 9 ;-)
We could do that, but I think we should be humble and realize we are only one of the data consumers. I think it would be much better if the taggers decided to come up with a scheme and we follow it, rather than the other way around.
Is there a strong correlation between importance of airport and its size? Maybe using way_area would be a good idea (it would be necessary to improve tagging, as most people tag airports as node, but it would require no new tags or changing guidelines).
Yes, I think size is an important factor. You could argue that military air fields are less important than civil airports, and military air fields can be quite big, but in general I think most important airports are big and most unimportant ones are small.
Most airports are mapped as nodes and not every airport has a clear boundary making mapping as polygons difficult - where would you for example draw the boundary of http://www.openstreetmap.org/node/276384892. A good criterion for the importance of an airport would be the runway length. This is of course difficult to determine since the runway is a separate object - you would need some kind of proximity query for that.
The shown example is by the way not even a very extreme case - there are areas much worse like http://www.openstreetmap.org/#map=10/5.5846/-71.3885 - on the other hand there are also areas where airports could well be displayed earlier than z=10 - in particular in high latitude areas where air transport is often the primary mode of transport.
Interesting, I shall ponder a tagging listserv message. To that end, looking at the tagging scheme for airports, the ICAO code does seem to differentiate the big from the little airport. Here's a list of all the ICAO codes in the USA on Wikipedia, and not any of these tiny airports are on there. There is a tagging preset for ICAO codes on iD and from what I've seen, they're fairly commonly populated. The FAA ref on the other hand applies to all airports, big and small. Similarly, the IATA Code is only applicable to "big" airports.
:airplane: :airplane: :airplane: :airplane: :airplane: :airplane: :airplane:
So, could the logic for the tag be like:
# at zoom >- 10
if attrs['icao']:
# show on the map
elif attrs['iata']:
# show on the map
:question:
@talllguy
Some minor airports also have IATA code. For example https://www.openstreetmap.org/way/218821049 1048 m of grassy runway, has its own IATA code
Overpass turbo: http://overpass-turbo.eu/s/5oQ
EDIT: Originally a different airport was an example, but in that case IATA code tag was a mistake.
In Europe, there are many tiny airports with ICAO code, such as Ameland or Kitzebourg Ultralight Airfield.
Not so much tiny airports with IATA code, but still some.
@math1985 @mkoniecz Ah, darn, ok thanks for the insight on that idea. I suppose it'd be better to develop a field for airport importance, if this is even an issue. I do think it'd be nice for other cartographic renderings of OSM data to have a better way to differentiate large and small airports.
@talllguy For Mapbox Streets we look for a number of things to get a rough idea of rendering importance:
type tag, which is sometimes used with a similar scheme to aerodrome)name or name:en tags contain clue words such as "international" or "heliport"I noticed that some time ago when I was looking at the airport rendering that way_area would be a good indicator however as has been pointed out not all airports have ways some are just areas.So I tweaked a few areas in the UK and looked at the top 20 busiest airports in the world, etc but I think Tokyo, etc had nodes. And I paused changing them all.
Personally I think that we should be encouraging tagging for ways rather than the old school and primitive system of using nodes. It is 2014 folks!
I think we should just use way_area and that would encourage better tagging practices. It is a simple solution/method. No need to over-engineer this.
@ajashton Thanks so much for the input, and for citing that aerodrome type tag. I clicked through to the wiki and found there is a _proposed aerodrome type tag_. I will weigh in on the discussion there, and I think some of the other commenters might want to as well. Perhaps if that is formally adopted we could add that to the mix here.
also to @Rovastar
I think we should just use way_area and that would encourage better tagging practices. It is a simple solution/method. No need to over-engineer this.
That is not a bad idea, though in the short term the map might suffer.
Airports are way too prominent now that they're purple and solid color. Link

@purpleplanes People proposed checking area of airport, checking presence of icao and iata tags, whether the name or name:en tags contain clue words such as "international" or "heliport".
What would work in this case?
The root of the problem is really that anything a plane lands at is tagged with aeroway=aerodrome. iata is the best I've seen proposed, but I really think we're trying to work around bad tagging.
I really think we're trying to work around bad tagging.
Yes, I will post about it on a tagging mailing list.
Yikes that purple is pretty bold. I'll look for the discussion on tagging
So there is no good way to check whatever airport is tiny. Is there some tag that would allow to check whatever it is private? And is it a good indicator of importance?
A quick comment: this is a long term historic tagging problem: at one stage we had at least 3 tags for aeroway: airport, aerodrome & airstrip which were used in decreasing order of importance. There was an undiscussed mechanical edit which changed them all to aerodrome. I cant locate it quickly, but IIRC it was around mid-2009. It has just got worse because many more minor to extremely minor places have been added (for instance locations where it is possible to land a plane on glaciers in the alps, which are not aerodromes in any sense at all).
@matkoniecz Did anything come out of the discussion on the mailing list?
Just use way_area.
@math1985
Did anything come out of the discussion on the mailing list?
Using way_area is not bad, rendering depending on feature density would be cool.
way_area is not perfect, but better than alternatives including current state.
I know it is not perfect but other solutions seem to be over-engineering and need other or new subjective tags in the carto database.
way_area is simple if it is big then it is rendered on lower zoom level/rendered big.
Sure there will always be edge cases but they will be rare and no solution is perfect.
A quick comment: this is a long term historic tagging problem: at one stage we had at least 3 tags for aeroway: airport, aerodrome & airstrip which were used in decreasing order of importance. There was an undiscussed mechanical edit which changed them all to aerodrome. I cant locate it quickly, but IIRC it was around mid-2009. It has just got worse because many more minor to extremely minor places have been added (for instance locations where it is possible to land a plane on glaciers in the alps, which are not aerodromes in any sense at all).
Ugh. So we used to have sane tagging, then someone got rid of it?
@math1985 @Rovastar: way_area does look like it will resolve most issues and is about the best proxy likely to occur. Most smaller places are just drawn as nodes or as a single way for the runway. Anything would be a dramatic improvement over cases like this:

@pnorman: yup
FYI: OurAirports has a public domain CSV with their own classification of global airports as small, medium, or large.
:thought_balloon: FYI: This issue has resurfaced on the talk-us mailing list, as there is an active MapRoulette campaign to address aerodrome nodes that haven't been updated in the past three years. Read on: https://lists.openstreetmap.org/pipermail/talk-us/2016-April/016143.html
I don't see that anything has changed. Cleaning up bad imported data is good and will help slightly, but there are lots of small rural aerodromes for agricultural purposes. Until tags are consistently used which allow differentiation between aerodrome types, there's nothing we can do with the style.
Is a review of the mechanical edit warranted given tags were once split across 3 types? Airport + IATA, for example, might give a good visual indication of commercial (domestic/international) premises. It might not as well but the simplification of 3 types into 1 hasn't helped this issue at all.
Am 13.04.2016 um 00:22 schrieb Paul Norman [email protected]:
Until tags are consistently used which allow differentiation between aerodrome types, there's nothing we can do with the style.
years ago it was argued that rather than specifying more detailed
aerodrome subclasses renderers should look at the features offered
(surface, amount and length of runway/s, availability of customs,
etc). Some discussion about this can be found here:
https://www.mail-archive.com/[email protected]/msg17947.html
https://lists.openstreetmap.org/pipermail/talk/2009-June/037823.html
https://lists.openstreetmap.org/pipermail/tagging/2011-February/006815.html
https://lists.openstreetmap.org/pipermail/tagging/2010-December/006144.html
https://lists.openstreetmap.org/pipermail/tagging/2011-January/006240.html
https://lists.openstreetmap.org/pipermail/tagging/2010-June/002563.html
Is a review of the mechanical edit warranted given tags were once split across 3 types? Airport + IATA, for example, might give a good visual indication of commercial (domestic/international) premises. It might not as well but the simplification of 3 types into 1 hasn't helped this issue at all.
No, it hasn't helped, but after 6 years, it'd be a question of a new edit, not undoing a previous one.
years ago it was argued that rather than specifying more detailed
aerodrome subclasses renderers should look at the features offered
(surface, amount and length of runway/s, availability of customs,
etc).
Time and what renderers have ended up doing have shown that argument was wrong.
I was considering airport rendering in a stylesheet which doesn't have osm-carto's design constraint of using just OSM data, and concluded that the easiest way to get sensible rendering would be to either use another data source for airports, or match OSM airport data against another data source. That is not an option for osm-carto.
I was considering airport rendering in a stylesheet which doesn't have osm-carto's design constraint of using just OSM data, and concluded that the easiest way to get sensible rendering would be to either use another data source for airports, or match OSM airport data against another data source. That is not an option for osm-carto.
Have you tried matching airports with their runways and rating them based on runway properties? I am not sure this is feasible here performance wise and i am not sure this leads to good results without relative rating (treating a large airport different when close to an even larger one) but it would definitely be worth trying. And it would also be good for mapper feedback since it would encourage proper runway mapping.
In Europe, there are many tiny airports with ICAO code, such as Ameland or Kitzebourg Ultralight Airfield.
Not so much tiny airports with IATA code, but still some.
...
was considering airport rendering in a stylesheet which doesn't have osm-carto's design constraint of using just OSM data, and concluded that the easiest way to get sensible rendering would be to either use another data source for airports, or match OSM airport data against another data source.
To be honest, and it has been suggested before like by the quote from @math1985 and others, using the IATA code seems the most reasonable and easy fix.
I have implemented this in my ArcGIS Renderer, and at least for the render results I've done so far in Europe, things are looking pretty good.
It is just very simple, three types of aerodromes. Major airports are rendered at scales >=1:250k, minor and heliport >=1:50k (may need adjustment down to >1:25k if I encounter more dense regions than I have seen up to now, but it is unlikely since airports needs space around them for safety).
Major airports:
_aeroway IN ('aerodrome') AND (iata IS NOT NULL AND iata NOT IN ('','no'))_
Minor airports:
_aeroway IN ('aerodrome') AND (iata IS NULL OR iata IN ('','no'))_
Heliports, using the latest tagging scheme
_aeroway IN ('heliport')_
@mboeringa I like that approach, especially if in your testing it seems to work out. In the original comment, I hypothesized that:
perhaps only airports with an ICAO or IATA ref
should appear at certain scales. We keep coming back to this, and I think it is a great indicator of relative importance, especially with all the tiny ones, such as what @purpleplanes pointed out.
Can you update your script to include icao=* as an OR to the iata=* logic?
According to the wiki, ICAO is more widespread. Also of interest:
The ICAO code is hierarchically organized in regions of the globe, and it changes it's prefix accordingly. This kind of information can be used when doing automated quality assurance checks.
Looking at Indianapolis example (https://github.com/gravitystorm/openstreetmap-carto/issues/1143#issuecomment-68576491) even iata=* filter may be still too weak:
http://overpass-turbo.eu/s/fDH
Have you tried matching airports with their runways and rating them based on runway properties? I am not sure this is feasible here performance wise and i am not sure this leads to good results without relative rating (treating a large airport different when close to an even larger one) but it would definitely be worth trying. And it would also be good for mapper feedback since it would encourage proper runway mapping
Yes. I don't want to go that route for OSM Carto with the non-obvious SQL. For my own work I'm still considering it, but I'm reluctant for similar reasons as here, as well as being not an option for another part of the toolchain I'm working on.
Looking at Indianapolis example (https://github.com/gravitystorm/openstreetmap-carto/issues/1143#issuecomment-68576491) even iata=* filter may be still too weak:
http://overpass-turbo.eu/s/fDH
Yes, that's what I'm finding locally too. There might also be a data quality issue. It still might be the best we can do.
Looking at Indianapolis example (#1143 (comment)) even iata=* filter may be still too weak:
http://overpass-turbo.eu/s/fDH
Part of this problem is that airports are rendered to early. I only render them from >=1:250k. That is roughly equivalent to the Z12 viewport in this image:
http://www.openstreetmap.org/node/153353016#map=12/39.7385/-86.3711
While the view you showed is something like 1:1M (Z10).
Indianapolis is a huge city, it seems to cover an area roughly equivalent to something like 30x30 km, which is almost the size of an entire province here in the Netherlands...
Anyway, it seems most of these small airports with IATA code also have an access=private tag, so an adjustment like this might work if you want to maintain the Z10 rendering:
Major airports:
_aeroway IN ('aerodrome') AND (iata IS NOT NULL AND iata NOT IN ('','no')) AND (access IS NULL OR access NOT IN ('private'))_
Minor airports:
_aeroway IN ('aerodrome') AND ((iata IS NULL OR iata IN ('','no')) OR ((iata IS NOT NULL AND iata NOT IN ('','no')) AND access IN ('private')))_
Heliports, using the latest tagging scheme
_aeroway IN ('heliport')_
This must be combined with dedicated starting zoom scales for the display.
Unfortunately at most 2,7% of all aerodromes have access=*, it's not even on the list of taginfo combinations: https://taginfo.openstreetmap.org/tags/aeroway=aerodrome#combinations
Unfortunately at most 2,7% of all aerodromes have access=*, it's not even on the list of taginfo combinations: https://taginfo.openstreetmap.org/tags/aeroway=aerodrome#combinations
Even so, with the queries I suggested, including checking the IATA tag, you will probably weed out quite a lot of the clutter. And it is likely that more aerodromes will get the access tag, once it makes a difference in the rendering...
Revisiting the issue after reading this entry.
We still don't have any good measure for recognizing important airports, but for Indianapolis area multiple simple conditions filtering would be quite effective:
So about 95% current airports there would be hidden on z10, even if it's still quite loose condition set. Even small airports could have all these properties too, but at least it shouldn't filter out any important airport and it gives us wide margin to think about something more strict (which probably means collecting the data for all the most important airports in the world and finding the common thread). Maybe just pushing the rest to z11 would be enough.
[EDIT:] of course it's rather z10/z11 than z16/z17, as I wrote previously, these errors are now corrected.
Sounds good for now.
Maybe another source of data:
https://query.wikidata.org/#SELECT%20%3FplaceLabel%20%3FplaceAltLabel%20%3Fiata%20%3Ficao%20%3Fcoords%20WHERE%20%7B%0A%20%20%23%20Is%20an%20airport%0A%20%20%3Fplace%20wdt%3AP31%2Fwdt%3AP279%2a%20wd%3AQ1248784%20.%0A%20%20%3Fplace%20wdt%3AP238%20%3Fiata%20.%0A%20%20%3Fplace%20wdt%3AP239%20%3Ficao%20.%0A%20%20%3Fplace%20wdt%3AP625%20%3Fcoords%20.%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%0A%20%20%20%20bd%3AserviceParam%20wikibase%3Alanguage%20%22en%22%20.%20%0A%20%20%7D%0A%7D
WikiData is really powerful, once you get the hang of it :)
FYI: I Implemented the suggestion from mboeringa in german style fork.
https://github.com/giggls/openstreetmap-carto-de/commit/fa181b13795c0d3921ecd95e8a8710a17ce8c182
@giggls any screenshots of how it looks around one of the areas in this thread?
Is this really deployed already? I don't see the difference in the number of airport icons:
https://www.openstreetmap.de/karte.html?zoom=10&lat=39.80332&lon=-86.33519&layers=B000TF
Is this really deployed already?
+1.
I think it is not yet deployed, it was only committed to master yesterday.
Clearly, a private airport like this one, should no longer display once implemented based on its tagging:
http://www.openstreetmap.org/way/409314905
https://www.openstreetmap.de/karte.html?zoom=10&lat=39.75167&lon=-86.14035 shows the current version now.
Re-Rendering is not done that often on this server as you are used to from tile.osm.org
If you like to have a tile re-rendered faster just use the /dirty trick on the particular tile:
https://help.openstreetmap.org/questions/1049/how-to-trigger-a-repaint-for-a-specific-osm-map-tile
The version (git hash) currently active on or tiles-erver is available at http://tile.openstreetmap.de/
For me making minor airports to show from z13 is too far. After all this distinction is rather subtle - we don't have clear definition of major and minor airports. I guess z11 would be enough, even in such extreme case as Indianapolis.
Still I find my query to be better, even including nodes (major airports are probably easy to draw):
http://overpass-turbo.eu/s/j9N (German style)
http://overpass-turbo.eu/s/j9H (my take)
You have an "acces" in your query, german style is a lot stricter actually
http://overpass-turbo.eu/s/j9J
Am 07.10.2016 um 13:05 schrieb kocio-pl:
For me making minor airports to show from z13
https://github.com/giggls/openstreetmap-carto-de/commit/fa181b13795c0d3921ecd95e8a8710a17ce8c182#diff-5d9237083037cf1d6d91c329a0ff61adR1027
is too far. After all this distinction is rather subtle - we don't
have clear definition of major and minor airports. I guess z11 would
be enough, even in such extreme case as Indianapolis.Still I find my query to be better, even including nodes (major
airports are probably easy to draw):
http://overpass-turbo.eu/s/j9G (German style)
http://overpass-turbo.eu/s/j9H (my take)—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/gravitystorm/openstreetmap-carto/issues/1143#issuecomment-252219276,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIJ7QlbGK_v3FnIluxNlDZn04Q9Ek1K8ks5qxidmgaJpZM4DCcbw.
Thanks! I've pasted a link to the corrected query. But it's still weaker than mine because of ICAO.
@utak: I render all airports with IATA tag and access != private in z10-z12 and all airports in z13. I did not consider ICAO because all airports with IATA code also seem to have an ICAO code.
I can issue a pull request on https://github.com/giggls/openstreetmap-carto-de/commit/396da79b5ac96bf6afd6e94b0f705de6bd8a1bc7 if desired.
So ICAO can just promote more careful tagging (just like excluding nodes), but is not necessary.
I like your code (type labels make it clear), but I think z11 (or z12) for small would be better for any other place, which is not that loaded with small airports. Tuning for extreme case (z13) will be too strict everywhere else.
What do you think?
Note there are already 36 cases with iata=none or iata=N/A - using this as a rating criterion could encourage such tagging.
I would still think using runway length as a rating criterion is probably the most universal approach. Would be great to see if that is practically feasible in live rendering.
@imagico I'm sure you are right about runway length, but one counter-example comes to mind: Machrihanish (Campbeltown) Airport has the longest runway in Scotland (was US AFB with Galaxy G5, SR-71 etc. visiting). With under 10k passengers it is one of the smaller ones, but still 14th overall in Scotland.
Yes, military airports often follow different rules regarding runway length and this often continues if an airport is re-purposed for civilian use. The idea here is however not to have a fixed threshold like _only show airports with a runway of more than 2000m at z12_ but to have a rating criterion that allows prioritization and this way makes sure important airports are shown while less important ones are dropped where things are dense. To do this really well will require preprocessing but it would be interesting to see to what extent this also works ad hoc.
@imagico I consider IATA tagged on airports where there is no such code a bug.
If it helps, here's what I'm currently doing in a different style:
https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua#L2303
That suppresses disused ones, includes only non-military ones with an IATA code and renders grass strips less prominently. That works for the UK, but "non-military with an IATA code" may need expanding elsewhere (e.g. the US). I take the points above about use and misuse of IATA codes, but it works well enough to be useful.
Edit: See https://map.atownsend.org.uk/maps/map/map.html#zoom=12&lat=52.3575&lon=-0.16 as an example (note the difference between Alconbury and Wyton - one is tagged as military and one (incorrectly) isn't.