Talk:Proposed features/Aviation Obstacle Light
"If an official aviation obstacle database is the source, such as the FAA Digital Obstacle File, then it will already have been decided which locations to map." - I am not convinced that mandating copying external database is a good idea Mateusz Konieczny (talk) 12:06, 26 February 2018 (UTC)
- And that was not the intention, so I have rephrased this text now. Thank you. --NKA (talk) 14:00, 26 February 2018 (UTC)
Explain FFA categories
- It can be done by "definition" column in https://wiki.openstreetmap.org/wiki/Proposed_features/Aviation_Obstacle_Light#FAA_obstruction_light_types Mateusz Konieczny (talk) 12:49, 28 February 2018 (UTC)
- Thank you for your input here and in the next sections. I will try to add short comments. The idea here was anyway just to demonstrate that a FAA DOF file can be mapped in OSM using the obstacle_light proposal. --NKA (talk) 20:33, 28 February 2018 (UTC)
Is it really a good idea to tag =no value? From https://taginfo.openstreetmap.org/keys/obstacle_light#values currently 99% of usage is no value and I do not think that it is a good idea Mateusz Konieczny (talk) 12:52, 28 February 2018 (UTC)
- I think you are right. I have changed to airmark=obstacle_light, so the no value is no longer available. --NKA (talk) 08:48, 6 March 2018 (UTC)
"obstacle_light yes There is an obstacle light on the structure, no other information known. Do not use if one of the obstacle_light tags below are used. " Is it really a good idea to omit obstacle_light=yes in that situation? I would rather make it mandatory. Mateusz Konieczny (talk) 12:53, 28 February 2018 (UTC)
- I have changed to airmark=obstacle_light, so the implicit "yes" value is now achieved. --NKA (talk) 08:48, 6 March 2018 (UTC)
"Light intensity levels as defined by ICAO" is not good enough for OSM tagging - it requires at least giving the definition here (and checking is it usable by typical mappers), mappers should not need to check ICAO specifications. Mateusz Konieczny (talk) 13:06, 28 February 2018 (UTC)
- I will add a description. The complete rules for determining the ICAO codes and intensity levels are long and complicated. The idea here was not to require mappers to determine which iCAO code and intensity value to tag, but to provide space for tagging the ICAO code and intensity if you happen to know them, e.g. through an import where the data is already given. For normal mapping it is sufficient to tag colour and fixed/flashing. I will clarify that in the table. --NKA (talk) 20:33, 28 February 2018 (UTC)
obstacle_light or airmark:light
On the tagging mailing list, Warin is proposing to use airmark:light instead of obstacle:light as the key for the details of the lights. Link Example:
- + airmark:light:colour=red
- + airmark:light:character=flashing
On the tagging mailing list, Warin is proposing to use the conditional syntax for dual lights instead of the :night and :day suffixes. Link Example:
- + airmark:light:colour:conditional=white@sunrise-sunset;red@sunset-sunrise
- + airmark:light:character:conditional=flashing@sunrise-sunset;fixed@sunset-sunrise
Beacon with lights
Suppose a tall NDB antenna (airmark=beacon + beacon:type=NDB) which also has obstacle lights on its structure. It won't be possible to also use airmark=obstacle_light on it.
We could use all the other airmark:light:* keys to describe the lights, but the proposal says that airmark=obstacle_light is mandatory.
- A good observation. In this case the NDB antenna (airmark=beacon) is the main object, and the airmark:light tags would further describe the light features on that beacon. The seamarks do this the same way, for example a seamark:type=beacon_lateral + seamark:light:character=red etc. without using seamark:type=light_minor/light_major in those cases.
- I will make a note that the airmark=obstacle_light tag is not needed for other airmark objects.--NKA (talk) 12:23, 19 March 2018 (UTC)