Proposal talk:Aeroway obstacle

From OpenStreetMap Wiki
Jump to navigation Jump to search

Please discuss this proposal here.

General comments

It would be good to define enough tags related to aeroway=obstacle for users to import bulk data like the FAA DOF. Here are some things defined by the DOF:

The total set of obstacles listed is: 

    59-67        Obstacle Type            1. Arch      15. Plant 
                                          2. Balloon   16. Pole 
                                          3. Bridge    17. Rig 
                                          4. Bldg      18. Refinery 
                                          5. Bldg-Twr  19. Sign 
                                          6. Catenary  20. Spire 
                                          7. Cool TWR  21. Stack 
                                          8. Crane     22. Stacks 
                                          9. Crane T   23. Tank 
                                         10. Ctrl Twr  24. T-L Twr 
                                         11. Dam       25. Tower  
                                         12. Dome      26. Towers 
                                         13. Elevator  27. Tramway 
                                         14. Monument  28. Windmill

The DOF allows for a multiple factor, e.g. STACKS can have a number of stacks, e.g. "3". In this case, the stacks are more or less colocated with one representative point. The DOF does not contain any additional information on the meaning of the above definitions. (Fore example, what is a Bldg-Twr?)

Per alpilotx's proposal, we would need to have or define matching man-made=XXXX tags for any unknown types.

Note that "bridge" might be a way and not a node in OSM, so perhaps aeroway=obstacle could be defined on ways. On the other hand, databases like the DOF give one representative point for the bridge.

The DOF provides frequency and call sign for radio station towers, but this is already covered in the proposed antenna/communications tower RFC.

Vertical tolerance - should we define a height_error=XXX tag to preserve error-bar information from source data?

The DOF also has:

  • Painted/Marked (yes or no)
  • Strobe lighting type:
* S = high intensity white strobe lighting
* M = medium intensity white strobe lighting
* R = red lighting
* H = Dual red with high intensity white strobe
* D = dual red, with medium intensity white strobe
* F = flood lights
* N = no lights
* L = other lighting, none of the above

The DOF readme can be found here.

--Bsupnik 23:44, 31 October 2008 (UTC)

OK, I think there is room, to extend the proposal, but I would also try to not bloat it (as the "normal" user might get confused about a too complex attribute schema).

For the quantity tag I'm a bit unsure. Yes, I have seen this in the obstacle lists of other countries too, but I think, they would make life complicated when it comes to map making or flight simulator scenery creation. For example, I have seen "wind turbine" definitions, where the databases only say, that there is a row of 12 turbines, starting from location X, going via location Y, and ending at location .Of course, this is nice for a textual description which is normally only read by a human, but it is hard to interpret by software. The same holds true, for informations like "3 stacks" or "3 chimneys". How does one know, how those 3 objects are located (in a flight simulator scenery this has to be specified)? OK, on a map one could still use a symbol for "more than 1 obstacles close to each other". Even the FAA mentions this possibility in their EXPLANATION OF VFR TERMS AND SYMBOLS: 

Obstacles are portrayed wherever possible. But since legibility would be impaired 
if all obstacles within city complexes or within high density groups of obstacles were 
portrayed, only the highest obstacle in an area is shown using , the group obstacle symbol.

So, in the end, I think we can add this optional attribute, but only for very specific situation. I would always encourage people, to make one node for each real life object. And in the case of "wind turbines in a row", I would even ask people to preprocess this import and and manually spread out this one row to N objects.

For the obstacle type man_made, I would let it a bit open. But in the first place I would only encourage people to enter the currently mentioned types as obstacle (but which I will extend by some of the above mentioned ones - which seem to make sense to me :-). I thin things like dams, tramways, bridges are really a complicated issue here ... exactly because they are rather line features instead of nodes.

For the lighting I think the currently proposed system is complex enough to cover the above mentioned FAA lighting types. I would only add two additional value DUAL and FLOOD. Then the FAA lighting types could be translated like: 

* S = LIH FLG W
* M = LIM FLG W
* R = F R
* H = DUAL F R + LIH FLG W
* D = DUAL F R + LIM FLG W
* F = FLOOD
* N = No

About marking I'm not so sure. The FAA document mentions some marking types, but I'm afraid that they are too few, to represent all cases - around the world(!) . And if we would try to cover all cases / combinations, the resulting schema might turn out "chaotic" at best. So, I would recommend to omit this.

--Alpilotx 22:10, 1 November 2008 (UTC)

It probably makes sense to NOT put the entire DOF spec into aeroway=obstacle. Consider it to be more of an example input data source. I think the key points that must be decided are:

  • Can we have aeroway=obstacle on a way, like a bridge? (I believe this could be useful.)
  • Do we want a "number of obstacles" key on an obstacle (e.g. "3 stacks") with one node.

On this second point, I think it might not be a good idea to create multiple artificial nodes when importing a data base...those "fake" coordinates (generated by algorithm) would have a legitimacy that is inappropriate - it's a data quality issue.

I am not sure what I think about lighting and markings - if we need the original DOF values, best to put DOF properties into some kind of private tags, similar to how the TIGER import was done. --Bsupnik 23:26, 1 November 2008 (UTC)

Lighting

Perhaps it's better to have a more specific key than lighting=* for which lights there are on the structure (like aeroway:lighting=*) as it could probably interfere with other tags if someone introduces another kind of lighting to be tagged. --Eimai 21:11, 3 November 2008 (UTC)

regarding light patterns, are they similar to those used by lighthouses? there was some discussion there on things like lighting:sequence= (including a few perl scripts to interpret the codes). Ojw 21:37, 5 November 2008 (UTC)

Related key building

We already have the building=* key (see Proposed_features/Building). I think key=man_made in this proposal should be replaced by key=building! Together with Proposed_features/Building_attributes most of this proposal can be covered. The votes on the building-proposals seems to approve both of them, though they never have been marked as approved. This proposal should be about adding more values to building like building=windmill

For further needs we should add sub-keys like building:lighting=*

IMHO the quantity tag should be avoided and be replaced by one node per building. --Phobie 00:10, 6 November 2008 (UTC)

Related to buildings: many buildings have more than one light on top. Should these be entered as separate nodes? --Eimai 13:24, 1 December 2008 (UTC)
Regarding quantity...here is the issue with quantity vs. multiple nodes: an obstacle with a quantity > 1 would happen when the source input data simply indicates one node for a collection, e.g. a factory with two smoke stacks would be represented as one lat/lon and quantity=2. In this situation, we have three choices: (1) preserve this as is (the RFC), (2) build two nodes with lat/lons that we create programatically/randomly and drop quantity or (3) simply drop quantity and not create more nodes.
My argument has been against choices 2 and 3 on the grounds that they both represent loss of data quality from the original data source. Choice (2) loses data quality by creating lat/lon points with known spatial error, while (#) represents loss of data quality by simply dropping information.
One of the values of having POIs in OSM is topological correctness, meaning an obstacle is in the right place relative to other vector land marks (e.g. if a radio antenna is on the right side of "Dobbin Rd." then this can be preserved in OSM). A lot of my concerns with generating extra nodes involves the question of how you would make sane extra nodes, and where you would put them, and how you would preserve topological correctness. --Bsupnik 13:27, 1 December 2008 (UTC)
Well, I mean that some buildings are large enough that they've put a red light on either side of that building. So you have the building polygon, and two lights to attach to that building. Being topographically correct means two nodes somewhere at both sides inside that polygon.
I've also seen buildings that just have a red light on one side of it, and not in the middle. Same question there: if you just add some tag to the building you lose the location of that light.
Now, how to attach that node to the building somehow, that's another matter :-) --Eimai 15:58, 1 December 2008 (UTC)

Related proposal Communications tower

You should also have a look at the Proposed_features/Communications_tower draft! --Phobie 00:12, 6 November 2008 (UTC)

Safety-critical?

While this looks like a really good idea, I'm concerned that it is only really useful in safety-critical applications which we can't support. It's not as if you can exactly stop and ask for alternative directions 500 feet up. Chriscf 10:10, 11 November 2008 (UTC)

To "not support" is not equal to "mustn't collect". Alv 13:11, 1 December 2008 (UTC)
Yes, but for one time, I agree with Chriscf. Don't write "This would enable map makers in the air navigation sector, to enrich their air navigational charts" on top of the rational since OSM will never be used as a source for real flight navigation systems (but simulators, yes). But these data can be usefull for other purposes. -- Pieren 13:24, 1 December 2008 (UTC)
Agreed that wording is misleading but I don't have a better one to suggest. Maybe the originator will, in time. Alv 14:15, 1 December 2008 (UTC)
To "not support" approximates to "shouldn't collect", mainly because collecting and recording data with little other application amounts to implicitly supporting it. I see potential for height information in 3D applications in general, and the presence of an obstacle could be derived from this, which is already done in height=*. I'm generally opposed to tagging derived and aggregate data - so (for now) leaning against the explicit tagging of an obstacle, given that interested parties can pull the data they need right now (without additional tags) and produce maps showing obstacles. Chriscf 17:29, 1 December 2008 (UTC)

I will look for answers

I will try to find answers to you objections ... especially the last one, about safety issues might be a valid one. Flying for sure is a bit more dangerous and demanding than driving ... --Alpilotx 13:55, 1 December 2008 (UTC)

This might be coming in a distant future

At the current level OSM simply has not enough data to be useful for any attempt to do airway navigation. All of our map is flat 2D, although there is effort to connect with NASA elevation data, which is unsatisfyingly low-resoluted or incorrect for significant parts of the world. I just cannot think of any sane pilot to use OSM for navigation at this time. I doubt OSM will be the source of security-related, highly reliable air navigation data ever. It might be used some day for decorative purposes on air maps. Until then I'd rather stick with mapping things which are relevant for ground-traffic. SvenR 19:57, 1 December 2008 (UTC)

Hopefully the flying users are legally bound to use some sort of official and vouched-for accurate maps (except maybe for ultra light planes - that aren't, mostly if at all, allowed to fly in poor visual conditions). I think it's still good to gather the information in one go, where and if known. Alv 21:11, 1 December 2008 (UTC)
OSM could not be used for IFR flight - the FAA makes that illegal. (I cannot speak for other countries, but flight data is very tightly controlled.) Simply replace all references to "sectional map" with "simulated sectional map for a flight simulation game". :-) --Bsupnik 15:06, 3 December 2008 (UTC)

Improve / Rewrite the proposal

aeroway=obstacle is not needed since it is a result out of hight and dimensions of other objects. It does not need to be tagged separately.
man_made, height and name already exists and are only here as advice on how to tag
What is left?
lighting and quantity!
quantity should be replaced by one node per light
This proposal should better be a proposal for:

Optional:

Sticking to SI seems to be impractical for angle (rad), flux (use intensity instead) and wavelength (use meters instead of nanometers).
All other luminous units can be calculated from the distance, receipting area, angle_width and flux.
See wikipedia:Luminous flux!
Did I missed something?
--Phobie 06:33, 2 December 2008 (UTC)

Please change the lighting tag to something that let's you know that it's only about lighting used for aircraft obstacles. --Eimai 12:41, 2 December 2008 (UTC)
lighting:usage=aerial --Phobie 08:46, 3 December 2008 (UTC)
But what if someone wants to tag lighting=pretty blue lights that light up the entire front of a touristic building? --Eimai 13:29, 3 December 2008 (UTC)
He could do that with lighting:info=*. See above! I doubt that your example-text would be useful for OSM... --Phobie 14:01, 3 December 2008 (UTC)

Please have a look at Talk:Tag:man_made=lighthouse! --Phobie 06:14, 15 January 2009 (UTC)

Obstacles are NOT only lighting

I think it is an important information - to Phobie - that aeroway obstacles are NOT only lighting. A lot of those obstacles are non lit - though, most of them should be lit. What I want to say is, that making a feature man_made=lighting INSTEAD of aeroway=obstacle doesn't makes a lot of sense (at least not in this context - there might be others where it is OK). Lighting is - at least from my viewpoint (and from that of the FAA) - an attribute of an obstacle. And the choice of lighting information is not my idea, but it is taken from a schema already used (for many years) by official aeronautic navigational charts (like those from the FAA in the USA etc.)! So, at least for obstacles, there is no need for a super detailed (light recommended by Phobie) lighting specification.

Now back to the aeroway=obstacle. I would see this as an additional attribute. Of course, the height and type of a object makes it already an obstacle implicitly, but giving it the extra attribute would make it possible to explicitly see it as an obstacle. I would again like to refer to official aeronautic navigational charts. They give this attribute only to selected set of object. To those, which are of specific interest or pose a really heightened danger ... (thy don't attribute every higher building in a city as an obstacle for example).

So, I repeat: the main reason for aeroway=obstacle would be, to have a way to distinguish those - aeronautically - relevant physical objects in the OSM database. To be able to further easily use them in other applications, like for example - and mostly - in flight simulators (there a scenery developer might want to extract all objects with a height, but only those attributed as an obstacle).

of course, I see a relevant point in the above comments: how to avoid, that people use this data in really critical situations? Well, I can only hope, they are not allowed to (as Alv said). BUT in a simulation environment - which usually is not seen as life threatening - it could still be of really good use (to learn to navigate with and around such obstacles). --Alpilotx 16:15, 2 December 2008 (UTC)

Hypothetical scenario: you want to create a simulation of a given area. Other than "black holes" in the data, is there anything preventing you from identifying obstacles using the existing data? Chriscf 16:40, 2 December 2008 (UTC)
One thing I'm wondering about: when to decide whether a building is an aeroway obstacle? If there's a light on top it's quite easy to see, but without a light? One could tag every building in a city then as obstacle, or every mountain top and every tree... --Eimai 17:30, 2 December 2008 (UTC)
What are the criteria for a aerial obstacle? From you words it sound like it is only the height and therefore a flight simulator developer can simply parse for height>30 meters! If you think the height depends on the height of other buildings around, simple calculate the average height and extract everything with is 20 meters above average! I really don't see a reason why we should use a extra tag beside of lighting. We should not tag stuff which can be calculated by software! --Phobie 09:00, 3 December 2008 (UTC)
It seems unrealistic at this stage to expect all or even many building to have a measured/approximated/guessed heights, but having some people add one extra tag to the most prominent, i.e. obstacles, seems to me less unlikely. Alv 09:25, 3 December 2008 (UTC)
If there is a hole in the data, a sticking plaster won't fix it. Chriscf 09:43, 3 December 2008 (UTC)
But even some duct tape might keep the snow out until someone with the proper filling gets there. Alv 10:10, 3 December 2008 (UTC)
Temporary fixes generally aren't. This also introduces the problem where someone has to check two tags for what are essentially the same thing, and violates the once-and-only-once principle - one concept, one tag. Chriscf 10:46, 3 December 2008 (UTC)
It was you who first made the irrelevant analogy to construction repairs... Should we then remove all gasometers, dams and such as they're just big buildings, just a wall thickness and height tags + pipelines leading in/out; from that someone could derive what they are used for. Landuse could also be derived from residential buildings and fences if it's no good to temporarily "fix" it with a subjective area enclosing multiple houses.
My point: only those interested in aerial obstacles will look for two tags (they already need multiple: building, power, man_made, bridge,...) and having that information present on some objects does not hinder others' use of the height tag - only someone systematically adding heights might review the tagged obstacle in comparison to surrounding objects, if they found a higher object close by. Alv 12:27, 3 December 2008 (UTC)
Your analogy doesn't hold any water whatsoever. Gasometers and dams are specific concepts. Being an obstacle to air traffic is inextricably linked with great height. Chriscf 12:48, 3 December 2008 (UTC)
Had you read the linked documents you'd seen that also tiny objects on airports but in the area used for airplane ground traffic are obstacles. Alv 12:57, 3 December 2008 (UTC)
Had you been paying any attention whatsoever to this page, you'd understand why that's irrelevant. Chriscf 13:42, 3 December 2008 (UTC)
So you moved to talking air traffic obstacles (vs. aeroway obstacles of the proposal) - for the latter your emphasized word inextricably is false. Alv 13:54, 3 December 2008 (UTC)
ChrisCF - let me try to answer "is there anything preventing you from identifying obstacles using the existing data", because that's where this proposal was born. Assume that we do two things: use existing OSM, and import additional free govt. data into OSM to fill in some black holes. The issue is that we would lose fidelity of data by "going through" OSM unless we maintain aspects of the data via tags. This proposal started as a way to uniformly extend OSM so that all of the imports could be done consistently.
Certainly most aspects of obstacles could and should be orthogonal. And I'm not sure whether semantic rules have any place on OSM. (For example, can we say "every node tagged as aeroway=obstacle SHOULD/MUST have height=XXX"? And it doesn't matter to us what part of OSM "height=XXX" belongs to as long as we have our height data.) But I can say (see my comments below too) that "aeroway obstacle-ness", that is, tagging specific tall things as aeroway obstacles, is useful and non-derivable data...it is preserving the judgement by human flight experts that not all buildings are equal, and some matter a lot more than others. When building a pilot's map, these are the buildings that must be preserved in the map.)
So from our app's perspective, the IDEAL schema would be one where: in NYC every single building has a node or polygon, every single one has a height tag, and the ones that are referenced in the FAA obstacle database are all tagged as aeroway=obstacle. This would let virtual city apps model Manhattan perfectly, and a virtual sectional map of NYC for a flight simulator would look good. --Bsupnik 15:05, 3 December 2008 (UTC)
I'm wondering whether having the real thing might be better, but you've reminded me of something I've missed - groups of obstacles. A pilot over London would probably be not be too concerned about the Canary Wharf Tower, which is the tallest building in Britain but also surrounded by other tall buildings. These other buildings would probably not be identified as specific obstacles, while the rather shorter Tower 42 and Gherkin probably would be, since they are fairly isolated. Not sure about how much detail to go into, but if specific obstacles are defined as such, then perhaps it could be worth recording them after all. I suppose that if the simulation is used for training, then it probably makes sense that a printed map is consistent with the scenery, and by tagging them here you know that if our data is wrong, any extract from it will be consistent with itself.
I will consider my last objections addressed if you can provide a real scenario known to fit this problem (the example above is pure guesswork on my part): two buildings, both tall, in similar environments, one significantly taller than the other, the shorter of the two is desginated as an obstacle and the taller is not. I say "in similar environments", since understandably a 300ft tower in the middle of nowhere may be an obstacle, while in a high-rise city it may not. Chriscf 16:39, 3 December 2008 (UTC)

Some background about obstacle definitions

I have now done a more in depth search on Google about the obstacle issue (it was not trivial to find these documents). Now, I have found some definitions in the "Aeronautical Information Exchange Model" (AIXM) about this issue. There are two interesting docs (one powepoint and one PDF) which detail the issue. And after all, yes, maybe we could live without an extra "obstacle" tag (but it would still make life easier for the flight simulator developers).

So, here are the docs. Maybe they help to clarify some aspects - they might also make clear, that the idea of obstacles is not only from my imagination but a common term in air navigation:

http://www.aixm.aero/gallery/content/public/user_meeting_1/presentations/training/Training%2009%20Obstacle.ppt

http://www.aixm.aero/gallery/content/public/design_review/08_obstacles.pdf

—Preceding unsigned comment added by Alpilotx (talk • contribs) 21:02, 2 December 2008

Not to dismiss anything that you've done, but we are generally opposed to "making anyone's life easier". Tony Hoare's axiom that "premature optimisation is the root of all evil" very much applies, and we may find ourselves actually making things more difficult than they need be, e.g. as has happened with the turn restrictions where people start adding "no_right_turn". Chriscf 09:33, 3 December 2008 (UTC)
ChrisCF -- ignoring the questions of safety (no IFR data provider will use OSM - legally they can't...we make a simulator which is often used for non-training use...so we could clear that whole issue by replacing "airway map" with "simulated airway map for a game" and go home happy) there is the question "what do these tags add"? In this case, I would say that having some (but not all) buildings tagged as aeroway obstacles allows for the preservation of obstacles that have been deemed "relevant to pilots" by external authorities like the FAA. This data is not necessarily derivable by algorithm - a bunch of safety inspectors do surveys when they specify an instrument approach to an airport, and they will flag out the buildings that they think matter. Theoretically you could attempt to simulate this process of "finding the important obstacles", but having the "important obstacles" exactly match the real-world chart is desirable for client apps. In terms of data modeling, this is preserving information that would be lost. (As the data comes in, some are known to be "of interest to the FAA, etc." whereas some are tall buildings flagged by users. aeroway=XXX helps preserve that. --Bsupnik 15:01, 3 December 2008 (UTC)

Collecting data

I have just realized that in amongst all the discussion of whether or not the data should be collected, nobody stopped to suggest how the data would be collected in the first place. The overwhelming majority of this sort of data is going to lie with the various agencies that oversee civil aviation, in copyright-encumbered databases. Sadly, not every country renders its national government ineligible to hold copyright. Certainly in the UK every agency, including the CAA, takes full advantage of Crown copyright, and through most of western Europe policies tend to vary.

So, what sources do you propose people use to identify obstacles outside of the US (for which FAA data will of course be public domain)? Chriscf 13:45, 4 December 2008 (UTC)

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Aeroway_obstacle&oldid=2511723"