New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Variable width rendering of aeroway=runway and aeroway=taxiway at high zooms #1853

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
@imagico
Collaborator

imagico commented Sep 19, 2015

This implements what i suggested in #1290 for aeroway=runway and aeroway=taxiway.

Reasoning as outlined there is that current rendering of these features is using line widths larger than real width at lower zooms (which makes sense for map readability) and line widths smaller than in reality at the high zooms (which does not make much sense). This change keeps the current line width at the low zooms but renders these ways in real width in addition to ensure they are never drawn thinner than in reality.

Width is taken from the width tag, if width is not tagged it is estimated for runways based on the runway length. For taxiways the default width used is 6 meters which is much too low for any but the smallest airfields - making a better estimate based on nearby runway length for example would be possible but might be confusing for the mapper.

Previous rendering of runways mapped as polygons has been removed since a runway is always perfectly described by a two node way and a width so there is no good reason to map a runway with a polygon. Taxiways continue to be rendered based on mapped polygon data as well (any complex geometry structure is technically a taxiway and not a runway).

The change requires the EPSG:4326 SRS to be available in the database (which IIRC is currently not required). OTOH it should be generic and also work in other projections than web mercator. I think this is the most elegant way to do this with the current constraints but if there is a better way i would be open to suggestions.

Examples from Frankfurt airport:

z15 before:
z15
z15 after:
z15

z16 before:
z16
z16 after:
z16

z17 before:
z17
z17 after:
z17

Width tagging of runways and taxiways is currently fairly incomplete and sometimes with too large values (probably indicating clearance instead of physical width on the ground). But this will probably be sorted out quickly once it is rendered in the map.

The zoom level where this change has a visible effect depends on latitude, the higher the latitude the earlier it happens, here for Tromsø -with no width tag so width is estimated:

z15 before:
z15
z15 after:
z15

@matkoniecz

This comment has been minimized.

Show comment
Hide comment
@matkoniecz

matkoniecz Sep 20, 2015

Collaborator

Width tagging is mentioned on http://wiki.openstreetmap.org/wiki/Tag:aeroway%3Drunway but not on http://wiki.openstreetmap.org/wiki/Tag:aeroway%3Dtaxiway

Also, according to wiki mapping runways as areas is OK (both http://wiki.openstreetmap.org/wiki/Tag:aeroway%3Drunway and http://wiki.openstreetmap.org/wiki/Aeroways).

Taxiway page on the other hand has "Mapping aeroway=taxiway as areas is disputed. You can join the discussion." and http://wiki.openstreetmap.org/wiki/Aeroways has "drawing taxiways as areas is disputed."


In that case I have no idea whatever wiki or PR should be changed and is there consensus or controversy about how these features should be tagged.

I think that it would be better to have consistent wiki and rendering (but I have no idea what and how should be changed).

Collaborator

matkoniecz commented Sep 20, 2015

Width tagging is mentioned on http://wiki.openstreetmap.org/wiki/Tag:aeroway%3Drunway but not on http://wiki.openstreetmap.org/wiki/Tag:aeroway%3Dtaxiway

Also, according to wiki mapping runways as areas is OK (both http://wiki.openstreetmap.org/wiki/Tag:aeroway%3Drunway and http://wiki.openstreetmap.org/wiki/Aeroways).

Taxiway page on the other hand has "Mapping aeroway=taxiway as areas is disputed. You can join the discussion." and http://wiki.openstreetmap.org/wiki/Aeroways has "drawing taxiways as areas is disputed."


In that case I have no idea whatever wiki or PR should be changed and is there consensus or controversy about how these features should be tagged.

I think that it would be better to have consistent wiki and rendering (but I have no idea what and how should be changed).

Show outdated Hide outdated project.yaml
Show outdated Hide outdated project.yaml
@imagico

This comment has been minimized.

Show comment
Hide comment
@imagico

imagico Sep 20, 2015

Collaborator

I agree the wiki is not very clear here.

  • runway as area was originally marked not correct but was changed some time ago without discussion and with no real reason so it should probably be considered disputed as well. I would estimate there are maybe 2-5 percent of the runways mapped as both area and linear way and <1 percent as area only. From what i saw this is always purely done to get real width rendering at the high zooms.
  • taxiway as area makes some sense for some features like turning areas, see here and here but is rarely used this way.
  • there are about a thousand aeroway=taxiway with a width tag, for runway it is much more common. I included it for taxiway here primarily because it is much more needed here for rendering. For runway the estimate based on length is very reliable but for taxiway this obviously does not work likewise.

On a whole my primary motivation for this change is to improve what the style communicates to mappers regarding how to map airport features and to improve rendering quality across latitudes. Right now it essentially communicates that the mappers should map aeroways as lines for the low zooms and as areas for the high zooms by deliberately rendering lines in a fairly ugly way at the higher zoom levels. This is neither what is desirable from a data user perspective nor what is efficient to map nor what is documented in the wiki.

Collaborator

imagico commented Sep 20, 2015

I agree the wiki is not very clear here.

  • runway as area was originally marked not correct but was changed some time ago without discussion and with no real reason so it should probably be considered disputed as well. I would estimate there are maybe 2-5 percent of the runways mapped as both area and linear way and <1 percent as area only. From what i saw this is always purely done to get real width rendering at the high zooms.
  • taxiway as area makes some sense for some features like turning areas, see here and here but is rarely used this way.
  • there are about a thousand aeroway=taxiway with a width tag, for runway it is much more common. I included it for taxiway here primarily because it is much more needed here for rendering. For runway the estimate based on length is very reliable but for taxiway this obviously does not work likewise.

On a whole my primary motivation for this change is to improve what the style communicates to mappers regarding how to map airport features and to improve rendering quality across latitudes. Right now it essentially communicates that the mappers should map aeroways as lines for the low zooms and as areas for the high zooms by deliberately rendering lines in a fairly ugly way at the higher zoom levels. This is neither what is desirable from a data user perspective nor what is efficient to map nor what is documented in the wiki.

@matkoniecz

This comment has been minimized.

Show comment
Hide comment
@matkoniecz

matkoniecz Sep 20, 2015

Collaborator

but was changed some time ago without discussion

In cases like this it is also OK to revert and start a discussion ( https://en.wikipedia.org/wiki/Wikipedia:BOLD,_revert,_discuss_cycle usually works ).

Overall I strongly suggest to change wiki if it is wrong.

Collaborator

matkoniecz commented Sep 20, 2015

but was changed some time ago without discussion

In cases like this it is also OK to revert and start a discussion ( https://en.wikipedia.org/wiki/Wikipedia:BOLD,_revert,_discuss_cycle usually works ).

Overall I strongly suggest to change wiki if it is wrong.

@imagico

This comment has been minimized.

Show comment
Hide comment
@imagico

imagico Sep 20, 2015

Collaborator

Changed SQL as per suggestions by @pnorman.

I realized that although this would constitute the first real dependency on web mercator projection this style is implicitly already strictly limited to mercator since styling is directly tied to zoom levels and the zoom level to scale relation is strictly specific to the projection. I would love to see this change (i.e. make styling normally depend on !scale_denominator! rather than zoom level) but this is a larger and separate project.

I kept the more generic formula as comment for reference.

BTW why the heck does postgis not offer a cosh() function?

Collaborator

imagico commented Sep 20, 2015

Changed SQL as per suggestions by @pnorman.

I realized that although this would constitute the first real dependency on web mercator projection this style is implicitly already strictly limited to mercator since styling is directly tied to zoom levels and the zoom level to scale relation is strictly specific to the projection. I would love to see this change (i.e. make styling normally depend on !scale_denominator! rather than zoom level) but this is a larger and separate project.

I kept the more generic formula as comment for reference.

BTW why the heck does postgis not offer a cosh() function?

@kocio-pl

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Sep 20, 2015

Collaborator

I guess the ultimate solution - not tied to any projection - is drawing it as area (with area=yes or probably with area:aeroway=*, if we need more complexity than that, as it would be reasonable analogy for already spreading area:highway=*).

Collaborator

kocio-pl commented Sep 20, 2015

I guess the ultimate solution - not tied to any projection - is drawing it as area (with area=yes or probably with area:aeroway=*, if we need more complexity than that, as it would be reasonable analogy for already spreading area:highway=*).

@HolgerJeromin

This comment has been minimized.

Show comment
Hide comment
@HolgerJeromin

HolgerJeromin Sep 20, 2015

Contributor

Computing the width does not work for all values with a unit. Would adding "m" be a tagging error? At least josm complains.
But a width with "foot" would probably be correct tagging.

Contributor

HolgerJeromin commented Sep 20, 2015

Computing the width does not work for all values with a unit. Would adding "m" be a tagging error? At least josm complains.
But a width with "foot" would probably be correct tagging.

@imagico

This comment has been minimized.

Show comment
Hide comment
@imagico

imagico Sep 20, 2015

Collaborator

Note there are currently 236 runways with a width value including 'ft' 102 including 'm' - this is negligible compared to the total number of width values tagged for runways. Cases with such values would fail gracefully - they would just use the estimation formula instead of the tagged width.

Please keep tagging discussion out of here - i explained why mapping a runway as an area is fairly pointless from the rendering perspective.

Collaborator

imagico commented Sep 20, 2015

Note there are currently 236 runways with a width value including 'ft' 102 including 'm' - this is negligible compared to the total number of width values tagged for runways. Cases with such values would fail gracefully - they would just use the estimation formula instead of the tagged width.

Please keep tagging discussion out of here - i explained why mapping a runway as an area is fairly pointless from the rendering perspective.

@kocio-pl

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Sep 20, 2015

Collaborator

Sorry, I have not read your full description of this PR! However I think the need for the projection-specific solutions may be (or may not be) the reason to reconsider it one day - for now I feel hacks like this are in fact less elegant, because they are less universal.

Collaborator

kocio-pl commented Sep 20, 2015

Sorry, I have not read your full description of this PR! However I think the need for the projection-specific solutions may be (or may not be) the reason to reconsider it one day - for now I feel hacks like this are in fact less elegant, because they are less universal.

@imagico

This comment has been minimized.

Show comment
Hide comment
@imagico

imagico Sep 20, 2015

Collaborator

There are no projection specific hacks needed, you just have to draw the lines in their real width. This is no rocket science, the technical difficulties only arise from the limitations of the software used (postgis and mapnik) not supporting this natively. Telling mappers to spent time painstakingly drawing outlines without any factual gain and later spending even more time maintaining this data just to spare the style and software developers the need to deal with some projection math would be the real hack IMO.

Collaborator

imagico commented Sep 20, 2015

There are no projection specific hacks needed, you just have to draw the lines in their real width. This is no rocket science, the technical difficulties only arise from the limitations of the software used (postgis and mapnik) not supporting this natively. Telling mappers to spent time painstakingly drawing outlines without any factual gain and later spending even more time maintaining this data just to spare the style and software developers the need to deal with some projection math would be the real hack IMO.

@kocio-pl

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Sep 20, 2015

Collaborator

I'm not into this subject enough to judge myself, but your explanation sounds reasonable to me.

Collaborator

kocio-pl commented Sep 20, 2015

I'm not into this subject enough to judge myself, but your explanation sounds reasonable to me.

@dieterdreist

This comment has been minimized.

Show comment
Hide comment
@dieterdreist

dieterdreist Sep 20, 2015

sent from a phone

Am 20.09.2015 um 11:30 schrieb Mateusz Konieczny notifications@github.com:

but was changed some time ago without discussion

In cases like this it is also OK to revert and start a discussion

Actually when this was changed in 2012 the editor added a hint that by that time, the mapfeatures page already allowed for mapping runways as areas (and this is still so today: http://wiki.openstreetmap.org/wiki/Map_Features#Aeroway
)

In some cases (unpaved airfields without markings), you can't survey other than an area, sometimes not even rectangular.

dieterdreist commented Sep 20, 2015

sent from a phone

Am 20.09.2015 um 11:30 schrieb Mateusz Konieczny notifications@github.com:

but was changed some time ago without discussion

In cases like this it is also OK to revert and start a discussion

Actually when this was changed in 2012 the editor added a hint that by that time, the mapfeatures page already allowed for mapping runways as areas (and this is still so today: http://wiki.openstreetmap.org/wiki/Map_Features#Aeroway
)

In some cases (unpaved airfields without markings), you can't survey other than an area, sometimes not even rectangular.

@dieterdreist

This comment has been minimized.

Show comment
Hide comment
@dieterdreist

dieterdreist Sep 20, 2015

sent from a phone

Am 20.09.2015 um 13:53 schrieb Holger Jeromin notifications@github.com:

Would adding "m" be a tagging error?

IMHO it's correct tagging, but not very common (I don't do it myself either)

dieterdreist commented Sep 20, 2015

sent from a phone

Am 20.09.2015 um 13:53 schrieb Holger Jeromin notifications@github.com:

Would adding "m" be a tagging error?

IMHO it's correct tagging, but not very common (I don't do it myself either)

@dieterdreist

This comment has been minimized.

Show comment
Hide comment
@dieterdreist

dieterdreist Sep 20, 2015

sent from a phone

Am 20.09.2015 um 14:43 schrieb Christoph Hormann notifications@github.com:

Telling mappers to spent time painstakingly drawing outlines without any factual gain

having to guess a best fit center line seems more complicated and error prone to me, e.g. here https://www.google.it/maps/place/00052+Furbara+RM/@41.9949863,12.0141113,18z/data=!3m1!1e3!4m2!3m1!1s0x1328ac78d2712b3d:0x7f4f6743d1b68dca?hl=de-it

dieterdreist commented Sep 20, 2015

sent from a phone

Am 20.09.2015 um 14:43 schrieb Christoph Hormann notifications@github.com:

Telling mappers to spent time painstakingly drawing outlines without any factual gain

having to guess a best fit center line seems more complicated and error prone to me, e.g. here https://www.google.it/maps/place/00052+Furbara+RM/@41.9949863,12.0141113,18z/data=!3m1!1e3!4m2!3m1!1s0x1328ac78d2712b3d:0x7f4f6743d1b68dca?hl=de-it

@kocio-pl

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Sep 20, 2015

Collaborator

In some cases (unpaved airfields without markings), you can't survey other than an area, sometimes not even rectangular.

In area:highway=* scheme we try to have best of both worlds: currently we draw the highway areas by hand, because these shapes can be really convoluted (especially on junctions), but it's expected that for the long segments of regular highways we would extract width from the tagged line.

I guess speaking of aeroways automatic width rendering (as proposed in this PR) could be sufficient in most of the cases probably, and area definition would take care of the rest.

Collaborator

kocio-pl commented Sep 20, 2015

In some cases (unpaved airfields without markings), you can't survey other than an area, sometimes not even rectangular.

In area:highway=* scheme we try to have best of both worlds: currently we draw the highway areas by hand, because these shapes can be really convoluted (especially on junctions), but it's expected that for the long segments of regular highways we would extract width from the tagged line.

I guess speaking of aeroways automatic width rendering (as proposed in this PR) could be sufficient in most of the cases probably, and area definition would take care of the rest.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Sep 20, 2015

Collaborator

I'm not sure about removing area rendering.

Collaborator

pnorman commented Sep 20, 2015

I'm not sure about removing area rendering.

Show outdated Hide outdated project.yaml
Show outdated Hide outdated project.yaml
Show outdated Hide outdated project.yaml
@imagico

This comment has been minimized.

Show comment
Hide comment
@imagico

imagico Sep 21, 2015

Collaborator

I'm not sure about removing area rendering.

If anyone could show a case where something is correctly mapped as a runway area that can not be equally represented by a simple linear way with width tag that would go a long way towards convincing me.

From what i saw runway areas are currently either hand drawn versions of the buffering i try to do here or abuses of the runway tag to map taxi areas or whole airfields.

Collaborator

imagico commented Sep 21, 2015

I'm not sure about removing area rendering.

If anyone could show a case where something is correctly mapped as a runway area that can not be equally represented by a simple linear way with width tag that would go a long way towards convincing me.

From what i saw runway areas are currently either hand drawn versions of the buffering i try to do here or abuses of the runway tag to map taxi areas or whole airfields.

@jojo4u

This comment has been minimized.

Show comment
Hide comment
@jojo4u

jojo4u Sep 21, 2015

Runway and taxiway should be threated like most of highway=, allowing only the linear represenation. Area tagging should be done by area:aeroway=.

jojo4u commented Sep 21, 2015

Runway and taxiway should be threated like most of highway=, allowing only the linear represenation. Area tagging should be done by area:aeroway=.

@dieterdreist

This comment has been minimized.

Show comment
Hide comment
@dieterdreist

dieterdreist Sep 21, 2015

sent from a phone

Am 21.09.2015 um 10:56 schrieb Christoph Hormann notifications@github.com:

From what i saw runway areas are currently either hand drawn versions of the buffering i try to do here or abuses of the runway tag to map taxi areas or whole airfields.

did you have a look at my example (Furbara)? the runway doesn't look to be a perfect rectangle.

dieterdreist commented Sep 21, 2015

sent from a phone

Am 21.09.2015 um 10:56 schrieb Christoph Hormann notifications@github.com:

From what i saw runway areas are currently either hand drawn versions of the buffering i try to do here or abuses of the runway tag to map taxi areas or whole airfields.

did you have a look at my example (Furbara)? the runway doesn't look to be a perfect rectangle.

@imagico

This comment has been minimized.

Show comment
Hide comment
@imagico

imagico Sep 21, 2015

Collaborator

Yes, from the imagery (see here) i cannot reliably identify a runway here. There is some structure visible on the grass but it is unclear to what extent this is a mowing pattern or an actual runway delineation.

Barring a locally clearly visible outline i would say this is equally non-verifiable to map with a runway as a linear way and as a polygon.

In general this does not look unlike a typical glider airfield which is often not more than a large, flat and maintained grass area where position and direction of the winch and landing area often varies depending on wind directions. Tagging the whole grass area as aeroway=runway seems inappropriate here in any case.

Collaborator

imagico commented Sep 21, 2015

Yes, from the imagery (see here) i cannot reliably identify a runway here. There is some structure visible on the grass but it is unclear to what extent this is a mowing pattern or an actual runway delineation.

Barring a locally clearly visible outline i would say this is equally non-verifiable to map with a runway as a linear way and as a polygon.

In general this does not look unlike a typical glider airfield which is often not more than a large, flat and maintained grass area where position and direction of the winch and landing area often varies depending on wind directions. Tagging the whole grass area as aeroway=runway seems inappropriate here in any case.

@dieterdreist

This comment has been minimized.

Show comment
Hide comment
@dieterdreist

dieterdreist Sep 21, 2015

2015-09-21 18:47 GMT+02:00 Christoph Hormann notifications@github.com:

Yes, from the imagery (see here
http://mc.bbbike.org/mc/?lon=12.013198&lat=41.99466&zoom=16&num=3&mt0=bing-satellite&mt1=mapnik&mt2=google-satellite&marker=)
i cannot reliably identify a runway here. There is some structure visible
on the grass but it is unclear to what extent this is a mowing pattern or
an actual runway delineation.

Barring a locally clearly visible outline i would say this is equally
non-verifiable to map with a runway as a linear way and as a polygon.

In general this does not look unlike a typical glider airfield which is
often not more than a large, flat and maintained grass area where position
and direction of the winch and landing area often varies depending on wind
directions. Tagging the whole grass area as aeroway=runway seems
inappropriate here in any case.

Actually this is a military airport and is unlike the glider airfields you
describe above. From google maps I believe to be able to see some kind of
runway lights or other kind of delimitation, where the ends appear not to
be 90 degree corners but bent (it is a bit unsure because of the bad
visibility in the aerials), e.g. here:
https://www.google.it/maps/place/00052+Furbara+RM/@41.9984177,12.0144625,288m/data=!3m1!1e3!4m2!3m1!1s0x1328ac78d2712b3d:0x7f4f6743d1b68dca!6m1!1e1?hl=en-IT

dieterdreist commented Sep 21, 2015

2015-09-21 18:47 GMT+02:00 Christoph Hormann notifications@github.com:

Yes, from the imagery (see here
http://mc.bbbike.org/mc/?lon=12.013198&lat=41.99466&zoom=16&num=3&mt0=bing-satellite&mt1=mapnik&mt2=google-satellite&marker=)
i cannot reliably identify a runway here. There is some structure visible
on the grass but it is unclear to what extent this is a mowing pattern or
an actual runway delineation.

Barring a locally clearly visible outline i would say this is equally
non-verifiable to map with a runway as a linear way and as a polygon.

In general this does not look unlike a typical glider airfield which is
often not more than a large, flat and maintained grass area where position
and direction of the winch and landing area often varies depending on wind
directions. Tagging the whole grass area as aeroway=runway seems
inappropriate here in any case.

Actually this is a military airport and is unlike the glider airfields you
describe above. From google maps I believe to be able to see some kind of
runway lights or other kind of delimitation, where the ends appear not to
be 90 degree corners but bent (it is a bit unsure because of the bad
visibility in the aerials), e.g. here:
https://www.google.it/maps/place/00052+Furbara+RM/@41.9984177,12.0144625,288m/data=!3m1!1e3!4m2!3m1!1s0x1328ac78d2712b3d:0x7f4f6743d1b68dca!6m1!1e1?hl=en-IT

@imagico

This comment has been minimized.

Show comment
Hide comment
@imagico

imagico Sep 21, 2015

Collaborator

OK - i put in the new approach suggested by @pnorman. Some thorough review is probably in order since this is somewhat complicated. One small problem occured with the bounding box expansion since tilemill seems to always call the query with some strange large bounding box that causes a postgis error. So i added an additional check for that.

Collaborator

imagico commented Sep 21, 2015

OK - i put in the new approach suggested by @pnorman. Some thorough review is probably in order since this is somewhat complicated. One small problem occured with the bounding box expansion since tilemill seems to always call the query with some strange large bounding box that causes a postgis error. So i added an additional check for that.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Sep 21, 2015

Collaborator

tilemill seems to always call the query with some strange large bounding box that causes a postgis error

and only once, possibly corresponding to an initial check?

I recall something similar happening once and ended up doing st_intersection(bounds of the world, something calculated from !bbox!), and wasn't very happy with it.

Collaborator

pnorman commented Sep 21, 2015

tilemill seems to always call the query with some strange large bounding box that causes a postgis error

and only once, possibly corresponding to an initial check?

I recall something similar happening once and ended up doing st_intersection(bounds of the world, something calculated from !bbox!), and wasn't very happy with it.

@gravitystorm

This comment has been minimized.

Show comment
Hide comment
@gravitystorm

gravitystorm Sep 22, 2015

Owner

If anyone could show a case where something is correctly mapped as a runway area that can not be equally represented by a simple linear way with width tag that would go a long way towards convincing me.

I don't see that tagging runways as an area is inherently a bad idea. It's easy for mappers to do (I have no idea how many metres wide 09R is at LHR, but I could draw an outline in iD or JOSM). It fits with the mapping of similar-scaled features. It's common practice among mappers. And it certainly makes the use of the data easier for polygon fills, as per the (somewhat complex) SQL discussions in this thread already.

So I'm happy to see the width tag used to improve the rendering for when areas are missing, but I think throwing out the area rendering is likely going to far.

current rendering of these features is using line widths larger than real width at lower zooms (which makes sense[...]

I'd suggest caution about over-analysing the current behaviour. It's not clear that there was any degree of deliberation about the particular widths used, and whether they are deliberately wider than real width or not. For zooms where the lines are currently wider than would be expected, I would suggest the airport icon is more important for legibility than an extra few pixels.

Owner

gravitystorm commented Sep 22, 2015

If anyone could show a case where something is correctly mapped as a runway area that can not be equally represented by a simple linear way with width tag that would go a long way towards convincing me.

I don't see that tagging runways as an area is inherently a bad idea. It's easy for mappers to do (I have no idea how many metres wide 09R is at LHR, but I could draw an outline in iD or JOSM). It fits with the mapping of similar-scaled features. It's common practice among mappers. And it certainly makes the use of the data easier for polygon fills, as per the (somewhat complex) SQL discussions in this thread already.

So I'm happy to see the width tag used to improve the rendering for when areas are missing, but I think throwing out the area rendering is likely going to far.

current rendering of these features is using line widths larger than real width at lower zooms (which makes sense[...]

I'd suggest caution about over-analysing the current behaviour. It's not clear that there was any degree of deliberation about the particular widths used, and whether they are deliberately wider than real width or not. For zooms where the lines are currently wider than would be expected, I would suggest the airport icon is more important for legibility than an extra few pixels.

@imagico

This comment has been minimized.

Show comment
Hide comment
@imagico

imagico Sep 22, 2015

Collaborator

I'd suggest caution about over-analysing the current behaviour.

I did not mean to - i just meant to point out the current low zoom rendering is consistent and meaningful but less so at high zooms and this change hopefully improves the latter.

I don't see that tagging runways as an area is inherently a bad idea. It's easy for mappers to do (I have no idea how many metres wide 09R is at LHR, but I could draw an outline in iD or JOSM).

I understand that but consider this primarily a limitation of the current editors which do not visualize the width tag or allow interactive manipulation of the width value.

Note while this might seem a very specific subject and not really worth an elaborate argument it touches a fairly fundamental question regarding the data model, namely if geometry and tags are strictly separate and geometry information should be modeled using the geometric elements currently available (nodes, ways and areas) or if tags can define aspects of the geometry of features in OSM. This does not only affect dimensional tags like width but also tags like direction. In 3d mapping it is common practice to encode geometric information in tags - simply because they cannot be represented in geometry data in the current data model. The question is if this is also desirable for aspects of 2d geometry where it makes sense. Should something like amenity=bench be preferably mapped as a node with tags like width, direction etc. or should it be promoted to a way or area geometry as soon as more specific geometric information is recorded.

(sorry for straying off-topic - this is certainly not something that should be discussed here but i wanted to point out the broader context of this question).

So I'm happy to see the width tag used to improve the rendering for when areas are missing, but I think throwing out the area rendering is likely going to far.

Currently this PR renders the line with real width regardless of the presence of a polygon representation of the same runway. While it would be possible to detect this and not render the line when a polygon exists i do not consider this desirable because it would communicate the polygon mapping has preference over the line mapping with width tag. Always rendering both when present would of course be possible (as for taxiway) but this might be confusing.

Collaborator

imagico commented Sep 22, 2015

I'd suggest caution about over-analysing the current behaviour.

I did not mean to - i just meant to point out the current low zoom rendering is consistent and meaningful but less so at high zooms and this change hopefully improves the latter.

I don't see that tagging runways as an area is inherently a bad idea. It's easy for mappers to do (I have no idea how many metres wide 09R is at LHR, but I could draw an outline in iD or JOSM).

I understand that but consider this primarily a limitation of the current editors which do not visualize the width tag or allow interactive manipulation of the width value.

Note while this might seem a very specific subject and not really worth an elaborate argument it touches a fairly fundamental question regarding the data model, namely if geometry and tags are strictly separate and geometry information should be modeled using the geometric elements currently available (nodes, ways and areas) or if tags can define aspects of the geometry of features in OSM. This does not only affect dimensional tags like width but also tags like direction. In 3d mapping it is common practice to encode geometric information in tags - simply because they cannot be represented in geometry data in the current data model. The question is if this is also desirable for aspects of 2d geometry where it makes sense. Should something like amenity=bench be preferably mapped as a node with tags like width, direction etc. or should it be promoted to a way or area geometry as soon as more specific geometric information is recorded.

(sorry for straying off-topic - this is certainly not something that should be discussed here but i wanted to point out the broader context of this question).

So I'm happy to see the width tag used to improve the rendering for when areas are missing, but I think throwing out the area rendering is likely going to far.

Currently this PR renders the line with real width regardless of the presence of a polygon representation of the same runway. While it would be possible to detect this and not render the line when a polygon exists i do not consider this desirable because it would communicate the polygon mapping has preference over the line mapping with width tag. Always rendering both when present would of course be possible (as for taxiway) but this might be confusing.

@jojo4u

This comment has been minimized.

Show comment
Hide comment
@jojo4u

jojo4u Sep 22, 2015

Mapping a runway as area might bring the problem which direction the runway is. Some program (flight simulator?) which wants to know how to land has to calculate the longer sides of the area and imply the the runway direction. Or it must take clue from the ref=* oder heading=*.

jojo4u commented Sep 22, 2015

Mapping a runway as area might bring the problem which direction the runway is. Some program (flight simulator?) which wants to know how to land has to calculate the longer sides of the area and imply the the runway direction. Or it must take clue from the ref=* oder heading=*.

Show outdated Hide outdated project.yaml
@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Sep 23, 2015

Collaborator

When a layer is loaded up by Mapnik, it finds out the column names and types by running the query with LIMIT 0 and a !bbox! of ST_SetSRID('BOX3D(-1.797693134862316e+308 -1.797693134862316e+308,1.797693134862316e+308 1.797693134862316e+308)'::box3d, 900913), which is the whole plane, from -infinity to +infinity in both directions. This bounding box cannot be transformed into EPSG 4326.

The best I can think of to handle it is

CASE
  WHEN ST_Area(!bbox!) = 'NaN' THEN !bbox!
  ELSE ST_Transform(
    ST_Expand(
      ST_Transform(
        !bbox!,
        _ST_BestSRID(ST_Transform(!bbox!,4326)::geography)),
      150),
    ST_SRID(!bbox!))
END
Collaborator

pnorman commented Sep 23, 2015

When a layer is loaded up by Mapnik, it finds out the column names and types by running the query with LIMIT 0 and a !bbox! of ST_SetSRID('BOX3D(-1.797693134862316e+308 -1.797693134862316e+308,1.797693134862316e+308 1.797693134862316e+308)'::box3d, 900913), which is the whole plane, from -infinity to +infinity in both directions. This bounding box cannot be transformed into EPSG 4326.

The best I can think of to handle it is

CASE
  WHEN ST_Area(!bbox!) = 'NaN' THEN !bbox!
  ELSE ST_Transform(
    ST_Expand(
      ST_Transform(
        !bbox!,
        _ST_BestSRID(ST_Transform(!bbox!,4326)::geography)),
      150),
    ST_SRID(!bbox!))
END
),
0.5 * CASE -- Buffer by the half-width
WHEN width ~ '^\d{1,3}(\.\d+)?$' -- Validate the width tag
THEN LEAST(width::real, 150) -- Place a maximum on the width

This comment has been minimized.

@pnorman

pnorman Sep 23, 2015

Collaborator

Is the maximum of 150 reasonable? I didn't have a look at the data to see what a good number would be, just that we didn't want to let through a 1km runway width tag.

@pnorman

pnorman Sep 23, 2015

Collaborator

Is the maximum of 150 reasonable? I didn't have a look at the data to see what a good number would be, just that we didn't want to let through a 1km runway width tag.

This comment has been minimized.

@matkoniecz

matkoniecz Sep 23, 2015

Collaborator

I think that rendering it would be OK as it makes clear that tagging is wrong.

Accepting 100km wide runway would be too much as it makes nearly impossible to find what went wrong but width=1000 should not have this problem.

@matkoniecz

matkoniecz Sep 23, 2015

Collaborator

I think that rendering it would be OK as it makes clear that tagging is wrong.

Accepting 100km wide runway would be too much as it makes nearly impossible to find what went wrong but width=1000 should not have this problem.

This comment has been minimized.

@pnorman

pnorman Sep 23, 2015

Collaborator

YVR is a fairly busy international airport taking big jets, and has a width of 60m on the three land runways. We want a value that's clearly larger than reasonable runways, but not so large that it screws up the rendering for too big an area, or that causes the buffer to be too big.

@pnorman

pnorman Sep 23, 2015

Collaborator

YVR is a fairly busy international airport taking big jets, and has a width of 60m on the three land runways. We want a value that's clearly larger than reasonable runways, but not so large that it screws up the rendering for too big an area, or that causes the buffer to be too big.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Sep 23, 2015

Collaborator

I have a few concerns

  • Making use of width in a projection-independent manner is annoyingly difficult and leads to unavoidable SQL complexity. Are we forcing this complexity on everyone?
  • I can't see dropping taxiway area rendering. Will this cause problems where runways and taxiways meet if runway areas aren't rendered?
  • I'm not particularly in favour of dropping runway area rendering, but not so much as taxiways.
Collaborator

pnorman commented Sep 23, 2015

I have a few concerns

  • Making use of width in a projection-independent manner is annoyingly difficult and leads to unavoidable SQL complexity. Are we forcing this complexity on everyone?
  • I can't see dropping taxiway area rendering. Will this cause problems where runways and taxiways meet if runway areas aren't rendered?
  • I'm not particularly in favour of dropping runway area rendering, but not so much as taxiways.
@imagico

This comment has been minimized.

Show comment
Hide comment
@imagico

imagico Sep 23, 2015

Collaborator

Regarding the code:

  • ST_Area(!bbox!) = 'NaN' does not catch the tilemill case so we need both
  • 150m is a reasonable limit. The estimation formula is capped at 75m which is likely about the maximum for normal airports (60m seems to be fairly standard for larger commercial airports). It is doubtful that any real runway exists wider than 100m but allowing up to 150m in principle is fine.
  • and i suppose i should change that to ST_Expand(..., 0.5*150) by the way.

Regarding ground unit processing in general:

i think that is to some extent inevitable when rendering large area maps in mercator projection. It is attractive to pretend this is not an issue and the earth is a flat square but ultimately you'd be fooling yourself. The technique demonstrated here is surely not a cure for all problems resulting from the varying map scale but it is an essential component to get good quality rendering across a wide range of latitudes. So if this change encourages others to equally use scale factor compensation in map rendering where useful this is a welcome side effect and not a disadvantage IMO. Ultimately it is the shape of the earth and the nature of the mercator projection that forces complexity on people, not us who simply take this into account when rendering a map.

Regarding area rendering:

Currently this style renders both line and polygon features tagged aeroway=runway and aeroway=taxiway. This PR currently changes rendering of line features of both to a variable width and removes rendering of polygons with aeroway=runway. This will lead to artefacts where runways are currently mapped as both polygons and lines and taxiways as polygons and runways have no width tagged and the estimation formula used returns a width smaller than the width mapped via polygon. Of course it will also lead to missing features where runways are mapped as area only.

As previously discussed the wiki is currently fairly vague in this matter - it is completely unclear if mapping as areas - if allowed - is supposed to be instead or in addition to line mapping. Even among mappers generally in favor of area mapping of runways it seems to be a widespread opinion that area mapping should be done in addition to line mapping and use a different tag.

There are a number of things that could be changed in that regard

  • we could keep the mapped area rendering for runways
  • we could remove the mapped area rendering for taxiways as well
  • we could limit the rendering of runway lines to cases where a runway is not mapped as a polygon. This would add significant complexity to the code and it would communicate to the mapper that polygon mapping has priority over line mapping. And it would in principle give mappers control over if and how some features are rendered by mapping or not mapping others - something i consider highly problematic in principle.

I would be fine with the first two changes (though not in favor of them) but i would be against the third.

Collaborator

imagico commented Sep 23, 2015

Regarding the code:

  • ST_Area(!bbox!) = 'NaN' does not catch the tilemill case so we need both
  • 150m is a reasonable limit. The estimation formula is capped at 75m which is likely about the maximum for normal airports (60m seems to be fairly standard for larger commercial airports). It is doubtful that any real runway exists wider than 100m but allowing up to 150m in principle is fine.
  • and i suppose i should change that to ST_Expand(..., 0.5*150) by the way.

Regarding ground unit processing in general:

i think that is to some extent inevitable when rendering large area maps in mercator projection. It is attractive to pretend this is not an issue and the earth is a flat square but ultimately you'd be fooling yourself. The technique demonstrated here is surely not a cure for all problems resulting from the varying map scale but it is an essential component to get good quality rendering across a wide range of latitudes. So if this change encourages others to equally use scale factor compensation in map rendering where useful this is a welcome side effect and not a disadvantage IMO. Ultimately it is the shape of the earth and the nature of the mercator projection that forces complexity on people, not us who simply take this into account when rendering a map.

Regarding area rendering:

Currently this style renders both line and polygon features tagged aeroway=runway and aeroway=taxiway. This PR currently changes rendering of line features of both to a variable width and removes rendering of polygons with aeroway=runway. This will lead to artefacts where runways are currently mapped as both polygons and lines and taxiways as polygons and runways have no width tagged and the estimation formula used returns a width smaller than the width mapped via polygon. Of course it will also lead to missing features where runways are mapped as area only.

As previously discussed the wiki is currently fairly vague in this matter - it is completely unclear if mapping as areas - if allowed - is supposed to be instead or in addition to line mapping. Even among mappers generally in favor of area mapping of runways it seems to be a widespread opinion that area mapping should be done in addition to line mapping and use a different tag.

There are a number of things that could be changed in that regard

  • we could keep the mapped area rendering for runways
  • we could remove the mapped area rendering for taxiways as well
  • we could limit the rendering of runway lines to cases where a runway is not mapped as a polygon. This would add significant complexity to the code and it would communicate to the mapper that polygon mapping has priority over line mapping. And it would in principle give mappers control over if and how some features are rendered by mapping or not mapping others - something i consider highly problematic in principle.

I would be fine with the first two changes (though not in favor of them) but i would be against the third.

@jojo4u

This comment has been minimized.

Show comment
Hide comment
@jojo4u

jojo4u Sep 23, 2015

I edited the wiki pages to only allow area mapping in addition to the way with label "disputed". Thus the navigation is possible and area mapping only an extra. runway/taxiway + area=yes can be converted to area:aeroway=* or another following area tagging scheme.

jojo4u commented Sep 23, 2015

I edited the wiki pages to only allow area mapping in addition to the way with label "disputed". Thus the navigation is possible and area mapping only an extra. runway/taxiway + area=yes can be converted to area:aeroway=* or another following area tagging scheme.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Sep 24, 2015

Collaborator

ST_Area(!bbox!) = 'NaN' does not catch the tilemill case so we need both

What's the query that Tilemill is generating which has problems?

Collaborator

pnorman commented Sep 24, 2015

ST_Area(!bbox!) = 'NaN' does not catch the tilemill case so we need both

What's the query that Tilemill is generating which has problems?

@imagico

This comment has been minimized.

Show comment
Hide comment
@imagico

imagico Sep 24, 2015

Collaborator

What's the query that Tilemill is generating which has problems?

Tilemill calls it with ST_SetSRID('BOX3D(-3.402823466385289e+38 -3.402823466385289e+38,3.402823466385289e+38 3.402823466385289e+38)'::box3d, 900913) which looks like an attempt to call it with an infinite bounding box (in single precision) and which ultimately leads to ERROR: Antipodal (180 degrees long) edge detected!. Since St_Area() on that returns a finite value it passes your test.

Collaborator

imagico commented Sep 24, 2015

What's the query that Tilemill is generating which has problems?

Tilemill calls it with ST_SetSRID('BOX3D(-3.402823466385289e+38 -3.402823466385289e+38,3.402823466385289e+38 3.402823466385289e+38)'::box3d, 900913) which looks like an attempt to call it with an infinite bounding box (in single precision) and which ultimately leads to ERROR: Antipodal (180 degrees long) edge detected!. Since St_Area() on that returns a finite value it passes your test.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Sep 24, 2015

Collaborator

in single precision

Ah, this is the difference. My version of Mapnik is giving it in double precision, and PostGIS is working in double precision, so it ends up as NaN.

CASE WHEN ST_Perimeter(ST_Transform(!bbox!,4326)) >= 360 THEN !bbox! is still a problem, since it tries to transform a bbox which may fail. The test cannot involve ST_Transform.

ST_Perimeter(!bbox!) > 3e+38 might work for a test. Where it overflows, it's Nan > 3e+38, which is true.


@springmeyer, we're spending a lot of effort to avoid the error on ST_Transform(!bbox!,) because !bbox! is far outside the extents of any projection when Mapnik does a query with LIMIT 0. Is there any way to avoid this problem?

Collaborator

pnorman commented Sep 24, 2015

in single precision

Ah, this is the difference. My version of Mapnik is giving it in double precision, and PostGIS is working in double precision, so it ends up as NaN.

CASE WHEN ST_Perimeter(ST_Transform(!bbox!,4326)) >= 360 THEN !bbox! is still a problem, since it tries to transform a bbox which may fail. The test cannot involve ST_Transform.

ST_Perimeter(!bbox!) > 3e+38 might work for a test. Where it overflows, it's Nan > 3e+38, which is true.


@springmeyer, we're spending a lot of effort to avoid the error on ST_Transform(!bbox!,) because !bbox! is far outside the extents of any projection when Mapnik does a query with LIMIT 0. Is there any way to avoid this problem?

@imagico

This comment has been minimized.

Show comment
Hide comment
@imagico

imagico Sep 24, 2015

Collaborator

ST_Perimeter(!bbox!) > 3e+38

Probably that will work.

Collaborator

imagico commented Sep 24, 2015

ST_Perimeter(!bbox!) > 3e+38

Probably that will work.

@daganzdaanda

This comment has been minimized.

Show comment
Hide comment
@daganzdaanda

daganzdaanda Sep 29, 2015

FWIW: The widest and longest runway might be at https://en.wikipedia.org/wiki/Edwards_Air_Force_Base

17/35 is 39,097 ft × 900 ft (11,917 m × 274 m)

The runway seems to be missing in OSM, it's hardly visible anymore on the aerial images:
https://www.google.com/maps/place/34%C2%B049'31.2%22N+117%C2%B051'40.2%22W/@34.825329,-117.86118,894m/data=!3m2!1e3!4b1!4m2!3m1!1s0x0:0x0?hl=en

daganzdaanda commented Sep 29, 2015

FWIW: The widest and longest runway might be at https://en.wikipedia.org/wiki/Edwards_Air_Force_Base

17/35 is 39,097 ft × 900 ft (11,917 m × 274 m)

The runway seems to be missing in OSM, it's hardly visible anymore on the aerial images:
https://www.google.com/maps/place/34%C2%B049'31.2%22N+117%C2%B051'40.2%22W/@34.825329,-117.86118,894m/data=!3m2!1e3!4b1!4m2!3m1!1s0x0:0x0?hl=en

@imagico

This comment has been minimized.

Show comment
Hide comment
@imagico

imagico Oct 2, 2015

Collaborator

Rebased and added new bounding box test.

I did not change the general principle since there has been no comment regarding #1853 (comment)

Regarding Edwards Base runways - the larger ones on the dry lake are all marked as separate parallel runways individually no more than a hundred meters wide. So they should be fine with this change (as long as correctly tagged).

Collaborator

imagico commented Oct 2, 2015

Rebased and added new bounding box test.

I did not change the general principle since there has been no comment regarding #1853 (comment)

Regarding Edwards Base runways - the larger ones on the dry lake are all marked as separate parallel runways individually no more than a hundred meters wide. So they should be fine with this change (as long as correctly tagged).

@imagico

This comment has been minimized.

Show comment
Hide comment
@imagico

imagico Oct 12, 2015

Collaborator

Still waiting for opinions regarding area rendering - those who voiced concerns about this: please comment on the options outlined in #1853 (comment).

Collaborator

imagico commented Oct 12, 2015

Still waiting for opinions regarding area rendering - those who voiced concerns about this: please comment on the options outlined in #1853 (comment).

@matthijsmelissen

This comment has been minimized.

Show comment
Hide comment
@matthijsmelissen

matthijsmelissen Oct 12, 2015

Collaborator

Sorry, I haven't had time to look at thjs (reading a discussion of this length does take quite some time).

Collaborator

matthijsmelissen commented Oct 12, 2015

Sorry, I haven't had time to look at thjs (reading a discussion of this length does take quite some time).

@matthijsmelissen

This comment has been minimized.

Show comment
Hide comment
@matthijsmelissen

matthijsmelissen Feb 9, 2016

Collaborator

I think we should try to keep the complexity of the stylesheet down. Therefore I'm not in favour of variable width rendering. It adds relatively a lot of complexity for a small gain. Perhaps something that supports this in Mapnik would be useful? In any case I'm going to close this PR. Thank you for the effort though @imagico! And sorry for long time to review.

Collaborator

matthijsmelissen commented Feb 9, 2016

I think we should try to keep the complexity of the stylesheet down. Therefore I'm not in favour of variable width rendering. It adds relatively a lot of complexity for a small gain. Perhaps something that supports this in Mapnik would be useful? In any case I'm going to close this PR. Thank you for the effort though @imagico! And sorry for long time to review.

@imagico

This comment has been minimized.

Show comment
Hide comment
@imagico

imagico Feb 9, 2016

Collaborator

To avoid unnecessary work in the future: I suppose this means that ground unit rendering of non-explicit geometries is generally not considered desirable and #1290 is to be closed as wontfix - because any such thing would mean a similar level of code complexity.

Regarding the vague hope for future native support in Mapnik see also #1975 (comment)

Anyway thanks for considering and thanks to @pnorman for the help with the code details.

Collaborator

imagico commented Feb 9, 2016

To avoid unnecessary work in the future: I suppose this means that ground unit rendering of non-explicit geometries is generally not considered desirable and #1290 is to be closed as wontfix - because any such thing would mean a similar level of code complexity.

Regarding the vague hope for future native support in Mapnik see also #1975 (comment)

Anyway thanks for considering and thanks to @pnorman for the help with the code details.

@matthijsmelissen

This comment has been minimized.

Show comment
Hide comment
@matthijsmelissen

matthijsmelissen Feb 9, 2016

Collaborator

Thanks for pointing out, I closed the issue too. Sorry, sometimes tough choises need to be made!

Collaborator

matthijsmelissen commented Feb 9, 2016

Thanks for pointing out, I closed the issue too. Sorry, sometimes tough choises need to be made!

@imagico

This comment has been minimized.

Show comment
Hide comment
@imagico

imagico Feb 9, 2016

Collaborator

I can accept the choice although i strongly disagree with it. This poses a hard limit on improvements of the rendering quality and makes a truly latitude-agnostic rendering impossible.

#1126 would then probably need to be closed as well - requires the same techniques although in a slightly different context.

Collaborator

imagico commented Feb 9, 2016

I can accept the choice although i strongly disagree with it. This poses a hard limit on improvements of the rendering quality and makes a truly latitude-agnostic rendering impossible.

#1126 would then probably need to be closed as well - requires the same techniques although in a slightly different context.

@mboeringa

This comment has been minimized.

Show comment
Hide comment
@mboeringa

mboeringa Feb 9, 2016

I can accept the choice although i strongly disagree with it. This poses a hard limit on improvements of the rendering quality and makes a truly latitude-agnostic rendering impossible.

I think latitude issues ultimately need to be solved by rendering data in local projections that minimize distortions. This is one of the things that will be a breeze with my ArcGIS Renderer, as ArcGIS handles on-the-fly re-projection of data really nicely. In fact, I started out rendering data in the "default" "Web Mercator" projection to compare the rendering results with carto, but have switched to local country specific projections for test renderings for its nicer more consistent and less distorted look of the rendered maps.

mboeringa commented Feb 9, 2016

I can accept the choice although i strongly disagree with it. This poses a hard limit on improvements of the rendering quality and makes a truly latitude-agnostic rendering impossible.

I think latitude issues ultimately need to be solved by rendering data in local projections that minimize distortions. This is one of the things that will be a breeze with my ArcGIS Renderer, as ArcGIS handles on-the-fly re-projection of data really nicely. In fact, I started out rendering data in the "default" "Web Mercator" projection to compare the rendering results with carto, but have switched to local country specific projections for test renderings for its nicer more consistent and less distorted look of the rendered maps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment