On airports there are so called PAPI which consist of four lights next to each other. They help the pilots to find out whether they are currently too high or too low.
Should these four lights making up the PAPI be mapped as four separates nodes? Or does this qualify more like “One feature, one OSM Element”?
I’ve seen both versions mapped in OSM und want to document a canonical version in the Wiki (Tag:navigationaid=papi) (it currently says: Set a node in the middle of the system but it doesn’t advice not to set four separate nodes explicitly).
It’s 4552 nodes to 69 ways in taginfo, seems it’s currently clearly a node in practice. As to what it “should” be, I’d be happy with making it a line just for simplicity in rendering and obviousness in which runway it’s for, but I don’t think it’s necessary at all. navigationaid=papi | Tags | OpenStreetMap Taginfo
Unfortunately taginfo shows only nodes and ways. But there are cases where there are four nodes to map a papi and we cannot decide how many of the exist with taginfo.
openairportmap.org displays them for example. Also, comparing the number of runways to the number of PAPI gives you an indication whether all or just some runways are equipped with the system.
Ok thanks. So if you want to map them with this level of detail I guess you need either to tell what runway they are attached to, or what direction they are oriented towards, or where the individual lights are? or can it be left to apps to deduce that?
I’m also wondering: is it important to tell that PAPI lights are “left to right” or “right to left”, or can it be left to apps?
Maybe a solution would be to map a PAPI as an area (rectangle) covering all lights and mapping the lights inside as lamps?
Regarding your suggestions: The runway can probably automatically deduced by proximity and the lights are – as far as I know – in the order that the white lights are far from the runway and the red lights are visible close to the runway.
Given the situation where people might map all four lights individually I agree that a line is probably the best representation. I think an area is too much detail: that’d be like mapping the area a street light takes up or the area a stop sign sits on. No matter what size or shape you give it, it’s not going to be useful or accurate.
A line is better than a point and doesn’t need to convey direction information: a PAPI is a set of four lights, two angled up and two angled down, such that if you’re too high you see one pattern and if you’re too low you see another. The most important information about papi is where to expect to see it and which runway it’s associated with. That way you can plan your approach and know what navigation aids you’ll be referencing.
We’ll just have an uphill battle replacing all PAPI points with lines.
If considering all the approach lights, to me it would make sense to map each light as individual node and group then in a relation to it’s function. Like PAPI, VASI, … In the relation I would expect as well a indication, which runway they belong to as well as the direction. Means like the runway itself should also be part of that relation. That comes with the benefit, that also the runway would contain the information, which lights are available while approaching it.
Please, don’t overuse them. Consider the necessity, if not maintainability. Spatially, they can found easily with a buffer, or by proximity around the =runway they are indicating. Data-wise, the =runway might have an attribute eg navigationaid:papi=yes added.
As aeroway= is a function, and all 4 lights are needed to form the =navigationaid facility, the lights shouldn’t be added individually using it. A line is the best, with eg side= showing what it faces.
Instead, they might be added with Proposal:Key:light source - OpenStreetMap Wiki generically, especially as they are static.
While light_source=aviation may not be the best, it doesn’t differentiate obstacle warning lights either. For that, the separate competing “standard” aeroway:light= is too specific with only =obstacle defined. Unclear whether it is a feature (which aeroway:light= is unsuitable for; still have to ask whether it may be a double feature otherwise), or attribute on the building= and man_made= structure. There is no areoway=light in the first place either, if the pattern refers to eg railway:signal:*= somehow. The syntax for the light is totally redundant, and incompatible (eg light:flash= vs aeroway:light:character= ; maybe it’s emulating seamark:light:character= , but the meaning is different) , with that already defined in light:*= generically. Almost all of it are used in Norway. The 14 aeroway:light==PAPI and =navigation_aid are unsuitable, as this dominant use is as an attribute on the building= and man_made= structure.
The 5k https://taginfo.openstreetmap.org/tags/light_source=aviation should be clarified, or some new light_source= should be invented. The 51 https://taginfo.openstreetmap.org/tags/light_source=warning is unclear what it is for, despite being listed in Key:light_source - OpenStreetMap Wiki prominently with others lacking context and stats. Is an aviation obstacle warning ligh considered “aviation”?
The 2 https://taginfo.openstreetmap.org/tags/light_source=PAPI may be too specific, yet not showing it’s for aviation at top level. It’s not immediately obvious how to integrate light_source= and aeroway= . A light:source=navigationaid doesn’t show what navigation it is for, when compared to eg the dozens man_made=traffic_signals for road traffic signal lights or poles.
Plenty of them are not really mappable by a way. I think it would be better having one schema, fitting to all the lights than having a schema just suitable for PAPI and later on another one and another one… It will in the end be a mess and every kind of approach light need to be mapped in a different way.
Not saying, my idea above is the one and only idea. Just thinking, there should be a scheme, fitting to all the lights.
VASI-lights would be already two lines and additional tags need to explain the position of the two lines.
I totally agree all indicator lights, and even all aviation-related lights, should be considered holistically. But it is still prudent to minimize the amount of rel for simplicity. Lines work for the question of PAPI here.
Ok, I didn’t read Key:navigationaid - OpenStreetMap Wiki completely. =txe , =txc , =rwe already exists with light:aviation= . Then light:aviation=PAPI could be used.
However, as I argued above, I suggest to use aeroway=navigationaid for the line of lights functionally, and light_source=aviation for each individual lamp physically. The abbreviations in navigationaid= should be avoided. Reusing the same light:aviation= in navigationaid= is more consistent, if not directly using navigationaid= instead of light:aviation= on the light_source=aviation . Then navigationaid=PAPI can be reused, without needing to add to light:aviation at all.
Furthermore eg =runway_edge can be separated to some =runway + =edge . This allows querying for all lights of a a taxiway or runway, and centerline or edge lights more easily. They are not specific systems as other abbreviated examples.
