Proposal talk:Aviation Obstacle Light

Introduction

The discussion on this page reflects how the proposed tagging has evolved during various stages of this proposal to accommodate the received comments:

• During the first drafting/RFC, obstacle_light=yes was used
• During voting for version 1, airmark=obstacle_light was used
• In the current version, aeroway:light=obstacle is used

External database

"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

Is it possible to document meaning of FFA categories so also normal mappers, not familiar with this classification can use it? Mateusz Konieczny (talk) 12:49, 28 February 2018 (UTC)

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)

no value

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)

yes value

"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)

obstacle_light:intensity

"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=obstacle_light

+ airmark:light:colour=red

+ airmark:light:character=flashing

I have modified the proposal to use the airmark:light: prefix for tagging the details of the lights. --NKA (talk) 12:40, 13 March 2018 (UTC)

Dual lights

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=obstacle_light

+ airmark:light:colour:conditional=white@sunrise-sunset;red@sunset-sunrise

+ airmark:light:character:conditional=flashing@sunrise-sunset;fixed@sunset-sunrise

I have modified the proposal to use conditional tagging for dual lights. --NKA (talk) 12:40, 13 March 2018 (UTC)

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.

Is there a better way to describe a beacon (or any other airmark object) that could also have obstacle lights on it? --naoliv (talk) 11:38, 19 March 2018 (UTC)

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)

aeroway=* vs. airmark=*

I'm not really satisfied with this division between the above mentioned keys. Unfortunately this rift was strengthened via changes to the database and the wiki by a single user about a year ago. At the time I did notice these and challenged them via changeset comments and a post in the german forum. Back then it was my plan to come up with a proposal to unify navigational aids in one scheme, but sadly life got in between and just now I'm getting a little bit back into OSM.
Anyway, as you can see I'm still not quite happy with this situation. For example, currently the description of aeroway=navigationaid states "A facility that supports visual navigation for aircraft" which perfectly fits obstacle lights, or even obstacles in general. But why then airmark=* with one single value. Well ok, let's assume you move through with your proposal. Then you'd have multiple values for that key, but with that you leave behind the approach lights, which, under this terminology, would actually also be "airmarks". In my view, this really is a mess.
By the way, the origin of the key airmark=* is rather interesting. In 2009 there was a worldwide mass-edit (https://www.openstreetmap.org/changeset/2048375) adding seamark=beacon to objects with man_made=beacon. However at that time the latter also covered radio navigational aids like VORs etc. and for those seamark=* would obviously be wrong. The user noticed his mistake, simply replaced "sea" with "air" (https://www.openstreetmap.org/changeset/3089232) and tada airmark=* was born. --TOGA (talk) 23:47, 21 March 2018 (UTC)

Thank you for your comments. As usual there are various opinions and another user proposed to use the airmark tag. I did consider aeroway=navigationaid, but its tagging schema involving navigationaid=als/papi/vasi locks this tag into only one category of navigational aids, namely instrument landing systems. If you want to cover all navaids then the tagging schema would have to cover a range of different categories such as those listed here: AIXM NavaidServiceType. You would then either have to redefine the aeroway=navigationaid tagging or expand the airmark schema. It seems to me that unifying this into a bigger airmark name space would offer the fewest conflicts, and airmark=obstacle_light would then be one of several values.

Anyway, in the AIXM standard, the navaids and the obstacles are in fact defined as two different classes of objects, so there could also be a case for keeping the two apart under different tags.

Let us try to develop this discussion and I will find out how to deal with it regarding my proposal and the voting process. It is of course difficult to judge how the lights would fit into a so far undefined potential proposal that you may want to put forward in the future, so it would be useful to understand how you envisaged to tag the navaids and the lights. --NKA (talk) 14:50, 22 March 2018 (UTC)

Hmm, that seamark suggestion definitely seems strange. I know deep down in that scheme aviation obstacles are mentioned, but using this for all of them, even those far away from any coast or navigable water surface sounds a little bit absurd. As I don't see any mention of it on this page and I'm curious, what was the reasoning behind that?

Sorry, that was a typo. Should read airmark, not seamark. I have corrected it now.--NKA (talk) 06:38, 23 March 2018 (UTC)

Theoretically I wouldn't see a massive problem with incorporating obstacles into aeroway=navigationaid. While it's true that at the moment only those visual landing systems are listed, this wasn't always the case. Before the above mentioned, unilateral, undiscussed edits from last year, that scheme was also used for radio navigational aids. You could add for example navigationaid=obstacle and there wouldn't be that much of a difference. It's just one level deeper in the namespace compared to your proposal. But anyway, after some more thinking today I agree that obstacles should probably be seperate from navaids, although there's another point I forgot to mention yesterday regarding the limitation to lights.
My main problem really is the usage of airmark. In my opinion there's no real benefit to move into a discrete namespace, as aeroway isn't really overcrowded and airmark, again as mentioned above, is the result of a botched mass-edit and more widespread, undiscussed edits last year.--TOGA (talk) 22:43, 22 March 2018 (UTC)

Just a quick comment: I have avoided proposing the obstacle as the new feature because that was rejected in a 2008 proposal (because the obstacles should be tagged as man_made=* etc). So I am just trying to get an approval for how to tag the lights. --NKA (talk) 06:38, 23 March 2018 (UTC)

Firstly, technically speaking that proposal was never rejected as the voting was aborted after the proposer was made aware via 2 negative votes that he didn't stick to the proposal process. That's actually in some way comparable to my vote. The points raised there are, in my opinion, a result of misunderstandings and could have easily been rebutted, but for whatever reason the proposer abandoned his proposal. I simply would define objects tagged with aeroway=obstacle as being explicitly marked as such be it via paint or flags or balls or lighting or a combination of the previously mentioned. While the proposal talks about marking and lighting in the beginning, this important distinction is missing which in the end led to objections stating for example that this information would be readily derivable from the tagged height of an object. --TOGA (talk) 23:16, 24 March 2018 (UTC)

If the obstacle light is on a navaid object, i.e. on an object already tagged with aeroway=navigationaid (or on any other aeroway=* object), how would you then tag the light? --NKA (talk) 07:49, 26 March 2018 (UTC)

Basically the same as you would with your proposal. So for the example from above, a NDB with obstacle lighting, I'll use my listed tags from further down this page:

aeroway=navigational_aid

+navigational_aid=NDB

+frequency=*

+ref=*

(+name=*)

+obstacle:method=lighting

+obstacle:lighting:...=*

So, as you can see, it's a similar concept in this regard. --TOGA (talk) 21:37, 27 March 2018 (UTC)

I am thinking that if the aeroway key should be used, it would be:

aeroway:obstacle=yes - to denote that the object is also an obstacle to aircrafts

+ aeroway:light=yes - to denote that the obstacle is lighted

+ aeroway:light:colour=red + aeroway:light:character=flashing etc - to describe the light

+ aeroway:marking=yes - to denote that the obstacle is marked

+ aeroway:marking:pattern=horizontal + aeroway:marking:colour=red etc - to describe the marking

That way, the obstacle would be an additional feature to other objects, and the light and marking schema could be reused also for other aeroway objects and for other types of lights/marking. --NKA (talk) 16:01, 31 March 2018 (UTC)

Hmm, I'm not sure about that schemes structure as the subkeys give no hint that they are referencing an obstacle. If you're worried that aeroway=obstacle would be missing on other aeroway objects, you might want to take a look at power=transformer where a similar problem exists. In some, probably even many, cases small transformers are mounted on power poles. Here the main tag is omitted and the presence of a transformer is shown by the subkey transformer=yes or detailed value. I guess if you really want to keep aeroway in the key something like aeroway:obstacle:marking:pattern might be an option but as I said, I don't really see the need.

Another issue for me is the singular light. In many cases the system consists of several individual lights, for example to cover all directions. In this regard the more general term lighting would be better in my opinion. This also is the terminology used in the documents from ICAO and FAA. --TOGA (talk) 02:10, 4 April 2018 (UTC)

I think the aeroway:light=obstacle tag in the current proposal clearly denotes that this is an obstacle light. The same method is used for various types of seamark lights.

I understand your comment about light vs lighting, however light is already used in OSM more than 100.000 times so I would not like to introduce a new tag for the same concept. Also I would like the aeroway:light key to be reusable for other types of light on any aeroway object. --NKA (talk) 09:38, 4 April 2018 (UTC)

First of all sorry for the big delay, life sometimes... . Also sorry with regards to aeroway:light=obstacle, I must've had the above scheme in my mind while going through your updated proposal and somehow didn't notice that change. This is definitely better, although if I had the choice I'd probably still prefer a version where the object is first tagged as an obstacle with subtags following whereas yours is kind of reversed.

With that in mind, you're writing in the proposal that you designed the scheme so it could also be used on other aeronautical lights. Could you maybe elaborate a little bit on this? Unless you want to tag every single light (for example of a runway) as a node, which in my opinion would be true overkill, I don't really see that option at the moment, because when used on a way you quickly run into conflicts as there might be multiple light systems and/or markings to describe (see my overview). The only instance where it could also work are ABNs but even there you're potentially running into conflict as these are often mounted on the control tower which itself might also be marked as an obstacle. This of course could be mitigated by putting ABNs into the range of navigational aids which then again would probably mean that your scheme would not be applicable any more.

With regards to light vs. lighting: While I definitely appreciate the concern over "tag fragmentation", I don't really think it applies in this case. As far as I can gather using taginfo current usage of tags containing light are by and large limited to nodes and individual lights. So in those cases the tags absolutely make sense. But as I said with this proposal, I think, there's a clear difference. It becomes even more staggering if you consider your aim of reusing those tags for other aeronautical lighting sytems potentially consisting of hundreds of individual lights. Also lighting is definitely not unheard of in OSM. While the numbers are indeed quite a bit smaller, the usage with tower:type is established.

Maybe I should really start drafting some proposals, so that there would be a better basis for discussion. I'll see what I can do. --TOGA (talk) 23:30, 20 April 2018 (UTC)

Limitation to Lights

This point I forgot to mention yesterday. Your proposal currently is limited to just the lights marking an obstacle, but as you probably know obstacles can also be highlighted with paint or marker balls. I think, it would be great, if the first-level value would not be confined to one type of marking. Although it would certainly be fantastic, you wouldn't even need to incorporate them into this proposal, but in my view there should at least be an option for the future. A possible structure could for example be:

• obstacle:type=light
  • obstacle:light:...=*
• obstacle:type=paint
  • obstacle:paint:colour=*
  • obstacle:paint:pattern=chequered/horizontal/vertical
• obstacle:type=both (obstacle marked with paint and lights)
  • subtags are a combination of the above
• obstacle:type=marker_balls

This is quite likely not complete, just to get an idea. Of course for the marker balls the base tag would have to be allowed on ways as well.--TOGA (talk) 23:16, 22 March 2018 (UTC)

I agree that markers could be added in the future. I have tried to keep to proposal simple by limiting it to the lights. I would avoid obstacle:type=* as that would refer to the obstacle itself, for example a tower. Under the current proposal and based on the reference documents and concepts from the seamarks, markers could be tagged:

airmark:marker:type=paint/flag/sphere

+ airmark:marker:colour=white;red - or orange, yellow etc

+ airmark:marker:pattern=chequered/horizontal/vertical - omit if no/solid pattern

This way the lights and the markers would just be features of any structure they might belong to. --NKA (talk) 06:38, 23 March 2018 (UTC)

Yes, I was already wondering if the combination obstacle:type could be misunderstood and I kind of agree that another tag would be better. How about obstacle:method?

Using "marker" in the key could also be confusing with regards to marker beacons. In this case "marking" could be better.

Further up I wrote about my original plans regarding a proposal or even a series of proposals. To give you an idea what I envisioned, I put together a rough overview. That's just off the top of my head what I remember and definitely far from complete, but the basic intentions should come across. I also included obstacles and tweaked the structure from above a little bit. --TOGA (talk) 02:48, 26 March 2018 (UTC)

Compatibility with Seamarks

I know that it is mostly pointless to add anything to the discussion at this point in time but I don't really like that the proposed scheme will produce yet another mapping layer barely compatible with other kinds of OSM styles. This way shoreside landmarks will have to be described with respect to material, light and daymark characteristics three times - with the general OSM tag set, with the seamark scheme and now with a new aeroway/airmark scheme. Maybe there is a way to produce an OSM-based comprehensive tagging scheme which will simultaneously satisfy the needs of regular users as well as maritime and aviation enthusiasts without spamming redundant tags describing the same charachteristics of a single object two or three times. --VileGecko (talk) 11:30, 18 March 2021 (UTC)

No, the aeroway:light tags should not duplicate the seamark:light tags. No need for that. --NKA (talk) 12:49, 18 March 2021 (UTC)

Comments from voting, version 1

Voting on version 1 took place from 19 March 2018 to 2 April 2018. The proposal was put back into RFC to accommodate comments received during the voting phase. Here is a copy of the voting section:

• I approve this proposal. Fanfouer (talk) 17:03, 19 March 2018 (UTC)

• I approve this proposal. Great idea! User:Fizzie41
• I approve this proposal. --Dr Centerline (talk)
• I approve this proposal. Mateusz Konieczny (talk) 19:00, 21 March 2018 (UTC)
• I oppose this proposal. I only discovered this proposal over the weekend and since my time was limited, assuming the minimum 14-day RFC-period, I planned to think a little more about it and write a comment on Monday evening. So you can imagine my surprise when I came back only to find the proposal already in voting. With this new situation I was a bit puzzled what to do. In the end I have determined that my problem (divide between airmark=* & aeroway=navigationaid) is too big for me to ignore. I'll expand on that on the discussion page.
  Also since the RFC-period was cut short by about 32 hours I'd suggest you to consider stopping the vote for the moment. I know it doesn't seem that much, but the line has to be drawn somewhere. I did take a look at the version history and noticed that you briefly moved the proposal into RFC a day earlier, so maybe you got a little bit confused there with the start of the vote? --TOGA (talk) 21:45, 21 March 2018 (UTC)

Please see the discussion page. I will extend the deadline for voting if needed. User:NKA

Additional reasoning besides shortened RFC-phase and usage of airmark: In addition to lights obstacles are regularly marked with other means like colour patterns as for example red and white stripes or in the case of power lines or other aerial cables with spherical markers. In this case the chosen base value of 'obstacle_light' limits the extension of the tagging scheme in the future. --TOGA (talk) 07:20, 25 March 2018 (UTC)

• I approve this proposal. --Scruss (talk) 16:30, 24 March 2018 (UTC)
• I approve this proposal. --Michi (talk) 00:38, 25 March 2018 (UTC)
• I have comments but abstain from voting on this proposal. Good start but IMHO shouldn't be limited to lights --Nospam2005 (talk) 15:52, 25 March 2018 (UTC)
• I approve this proposal. - I agree there could be overlap with aeroway=navigationaid, but that tag is around for almost 10 years and it hasn't any documentation how to map those lights we're talking about here. This proposal has detailed tagging suggestions. --Dieterdreist (talk) 10:25, 27 March 2018 (UTC)
• I oppose this proposal. I think the theme does not fit with OSM. It should also be added at aeroway=navigationaid --geozeisig (talk) 06:54, 28 March 2018 (UTC)
• I oppose this proposal. --Gosausee Das hat nichts mit OSM zu tun. Schuster bleib bei deinen Leisten

Is there a plan for second vote?

Right now tag is in use, but proposal appears abandoned (it is fine and OK, but in such case page for tag should be created documenting actual use - potentially different from what proposal proposed - and mark proposal as abandoned) Mateusz Konieczny (talk) 08:53, 24 March 2021 (UTC)

The current use is according to this proposal. Some of the feedback is that the tagging scheme is bit elaborate. I am considering if it could be simplified, for example a combination of all elements into one tag, such as light="flashing red medium_intensity icao_b", or any optional subset such as light="flashing red". So currently no plan for a second vote.--NKA (talk) 09:39, 24 March 2021 (UTC)