Airports 
often have visual approach slope indicators installed next to runways. These usually consist of 2-6 lights that are positioned in a certain pattern to each other:
VASI are usually two separate installations of 2-3 parallel lights parallel which are
PAPI are four lights (in rare cases even just two) in one line perpendicular to the runway next to each other.
The challenge in mapping these in OpenStreetMap is that currently there seem to be two schools of thought as to whether to map them as nodes (aeroway=navigationaid + navigationaid=papi / navigationaid=vasi ) at the individual light locations or one node at the center of the “system”, e.g. for PAPI in the middle of the four lamps. Here are two JOSM screenshots of both ways (the line icons with the white and red dots is the PAPI OSM node objects):
For VASI systems I have only come across mappings of either only the first system or both of them being tagged as nodes (the icons with the 6 white and red dots are VASI OSM node objects):
Now I’m a bit torn 
to follow the OSM premise of “one object - one item” because the question is whether to map lamps or systems. And if we map systems: Where to locate the OSM node for VASI systems when the lamps are a bunch of meters apart?
Would love to get some input from fellow mappers on how they would approach this, particularly if you haven’t been doing aeroway mapping so far 
Example links:
Miami Airport PAPI example in ID Editor
Merced Airport VASI example in ID Editor
1 Like
I consider each bunch of lights to be one node, and place the PAPI indicator in the middle of the 4. I figure a pilot needs to know where to expect different signals, not the precise layout of each bulb. We don’t map each bulb of a traffic signal for example.
1 Like
you could map both, lamps and systems. Generally I would assume the most useful place for adding system information to be the runway? (assuming that an aerodrome could have several runways and each could have a different system). The lamps/lights could be mapped as technical infrastructure, similar to how we map lighting towers or street lamps on their own, and “lit” as an attribute on the feature that is lit.
This seems like something that really needs some sort of relation. Then it could be one node for each light and a relation to group them all together into a functional group. The relation might then also include the runway with a special target role.
I don’t think a relation is really needed, pilots don’t really need to distinguish which is which aside from the fact that they may exist: they’re always associated with the runway they’re physically closest to, and they always point in a focused way towards the approach path for their runway. If there were a hypothetical airplane GPS app using OSM, it’d be real easy to say “are there any navigational lights near this airport/runway” and handle them appropriately. If it became really critical, a ref number on the elements would be the next logical step. (We don’t, for example, group all ways together into a relation called Main Street, we just presume that ways labeled Main Street near/connected to each other are the same street.)
In the most elaborate use case like Microsoft Flight Simulator, the same logic could/should/would apply: find the nearest runway to the navigational aid, and point it in the direction of the approach path. (The lights are often physically arranged perpendicular or parallel to the runway anyway so it’s really just a matter of programming in the appropriate direction and angle for a glide path. A game like Flight Sim will reference government documents and manually program/test/tune that information if they care about quality.)
Actual FAA maps don’t explicitly associate each aid with a certain runway, they just show a little rectangle next to the runway so you have a general idea of what to expect. The “closest runway to X” logic is what pilots use every day.
