Proposal:Aeroway obstacle
|
|||||||||||||||||||||||||||
Proposal
An Air traffic obstacle is a tall structure (a node, or linear feature) which can endanger air traffic. Air traffic obstacles have to be marked in most cases with red and white colored markings and with aircraft warning lights at night. On larger structures blinking lights are required. This definition was taken from Wikipedia, see: Air traffic obstacle
OSM already has the category aeroway for marking and categorising anything to do with where (mainly civilian) aircraft, helicopters take off and land. Obstacles are an important part of air navigation - especially in in low visibility conditions - as they need to be avoided at any cost. OSM also already has most of the potential obstacles as features - like the man_made structures lighthouse, tower, beacon - but lacks any kind of tagging, which explicitly and additionally categorizes them as being air traffic obstacles.
Rationale
This new feature would make it possible, to additionally mark physical features as being hazardous obstacles in the aeroway category. This would enable map makers in the air navigation sector, to enrich their air navigational charts with this relevant information.
Additionally these large obstacles are most of the time seen from far away and can thus help navigating on a map even on the ground.
A secondary - and also very important to the proposing party - application would be to use this information in flight simulation and thus in flight training. One specific case on hand is the X-Plane flight simulator which is lacking this data outside the United States. This data is seldom available freely to the public, and even in those cases is not of the best quality (the above mentioned wiki links lists three such examples). As a result of this the feature, the scenery developer of X-Plane flight simulator could much more easily include this data into their system. But of course, it would be open to every other simulator too.
Tagging
Air traffic obstacles do also have additional properties, which are needed for their identification and for their correct representation in simulator environments. The most important is their type, which would be already defined by the existing tags like man_made. It would be possible - and encouraged - that users declare already existing man_made OSM features as being obstacles. Additionally, the two most important attributes are:
- height
- lighting (the warning lights use to make them visible at low lighting conditions)
Tagging specification
- key=man_made value=<one from the list>. All obstacles need to be already marked as an existing man_made feature. The following subset of features would be of relevance :
lighthouse tower beacon chimney power (wind) windmill crane antenna pilon flare_stack (see Gas Flare in Wikipedia)
other types would be allowed too, as there is some room to decide what is an obstacle and what not. Even linear features - like bridges and dams - could be defined as obstacles (which they can definitely be in reality). There are some suggestions from the FAA like (but I wouldn't encourage to incorporate them in the first place):
arch building dome monument spire pole tank dam bridge
- key=aeroway value=obstacle. All obstacles need to have this new feature assigned
- key=height value=<meters>. All obstacles need - this would be mandatory - their height defined. (the height would be needed in meters, without the trailing SI unit m )
- key=lighting value=<description>. All obstacles can have an optionally assigned lighting tag. The lighting description would be in a more or less standardized fashion, which is already used in existing, official documents (see the Wikipedia link above). Allowed description elements would be official aeronautic abbreviation (combinations of):
"F" - Fixed "FLG" - Flashing "LIL" - LLight Intensity Low "LIM" - Light Intensity Medium "LIH" - Light Intensity High "DUAL" - dual light / two adjacent lights "FLOOD" - flood light "R" - Red "W" - White "G" - Green "Y" - Yellow "No" - No Lighting
Examples: "F R" "FLG W" "F R/FLG W" "LIH FLG W" "LIL F R" "LIL F R + LIL F W" "DUAL F W" "DUAL LIL F W" "DUAL F R + LIH FLG W" "FLOOD"
- key=quantity value=<number>. All obstacles can have a quantity attribute, to define, that there are more than one of them located very closely (like "2 chimneys", "3 stacks"). This possibility is proposed by the FAA too, 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.
quantity=N is meant to be used only when the actual location of the actual obstacles is NOT known. If source data provides separate locations for 3 obstacles, map editors should create one node for each obstacle. It is the job of map rendering software to consolidate obstacles for the purpose of legibility; the design goal of quantity=N is to avoid creating "false confidence" in coordinate data when an original source provides only one location for a cluster.
- key=name value=<name>. All obstacle can have optionally a name - optionally, because names are not common for these often unspecific features of the landscape.
Symbols
I would recommended to use the symbols of the FAA from their EXPLANATION OF VFR TERMS AND SYMBOLS, as they are already "kind of a standard" and would be easily recognized by most airmen.
 |
Obstacles less than 1000 feet AGL (300m) |
| Obstacles less than 1000 feet AGL (300m) AND high intensity strobe light system. | |
 |
Obstacles higher than 1000 feet AGL (300m) |
 |
Obstacles higher than 1000 feet AGL (300m) AND high intensity strobe light system. |
 |
The group obstacle symbol, where more than one objects are close to each other. |
Voting
I oppose this proposal. Several uncovered objections. See talk-page! --Phobie 12:14, 1 December 2008 (UTC)- I oppose this proposal. Indeed, there are too many issues on the talk page that haven't been resolved yet. --Eimai 12:20, 1 December 2008 (UTC)
Voting stopped by alpilotx ... Sorry guys. I have completely forgotten to check the Talk page. In the first days I didn't get responses and then I was believing, I would get automatic notification if I set the page on watch (which was obviously not the case). And I got only one response via the mailing list ... Sorry for the inconvenience and I will now go back to the RFC state. I will see if I can clean up the - partially - valid objections from the Talk.