[OSM-dev] aviation maps?

Julio Costa Zambelli julio.costa at openstreetmap.cl
Wed Aug 11 17:25:39 BST 2010


We talked about an OpenAeroMap with Ivan Sanchez back in Amsterdam
(SoTM2009), but when Ivan told the crowd about the idea, the reception
went from simple skepticism to total disagreement (security issues
being one of the main reasons).

Anyway, I started using man_made=beacon tags long before that to mark
the VOR/DME, NDB, etc. stations/antennas in the ground. Now I see that
the user cbm probably runned an automatic process adding a
seamark=beacon tag to this nodes
(http://www.openstreetmap.org/browse/node/444066894/history), and
added a seamark=beacon, airmark=beacon distinction tags to the wiki
article (quite reasonable IMHO).

My opinion is that air routes are as compatible with OSM as sea routes
are. I agree that final approach charts (For example:
may be too complex (specially for big airports with dozens of
approaches) and sometimes fast changing, but the general airways (For
example: http://www.aipchile.cl/dasa/aip_chile_con_contenido/aipmap/Cartas%20Aeronauticas/SUPERIOR%204.pdf)
are perfectly usable. They may seem overcrowded, but it is just the
effect of huge areas being covered in just one chart.

If the consensus is to keep this data out of OSM I hope you are able
to organize it somewhere else and do some OpenCycleMaps style mashup
with OSM.

My non-poisoning two cents.


On Wed, Aug 11, 2010 at 10:00 AM, Ákos Maróy <akos at maroy.hu> wrote:
> Dear Frederik, OJ, Pieren & Tom,
> Thank you for your quick responses in the subject.
> Maybe I'm using bad terminology, as I'm new to OSM in general, so let me
> try to line out what I was thinking about, before trying to react to
> what you write specifically. Please correct my terminology if I'm
> misusing / incorrectly using terms.
> What I had in mind is to use tools made for OSM to manage aviation maps.
> by tools I mean map editors, map rendering tools (that turn vector maps
> into bitmap tiles), map viewers (that show tiles).
> I wouldn't intend to push aviation maps inside the 'offical' OSM
> database - as pointed out, this would be confusing for the generic OSM user.
> why I though that some 'extension' is needed into OSM, as aviation map
> artifacts (airspace areas, navigation points, etc.) are unlike existing
> OSM concepts (roads, rivers, streets, etc.). they are different both
> semantically, and also from a visualization / rendering perspective.
> thus I wonder, how such extensions can be made, that take the
> appropriate metadata into account, and that would result in a proper
> rendering of these artifacts.
> as an example, the notion of 'airpsace' is usually a spacial area
> bounded by a polygon, which also might have a low or high altitude
> boundary. there are also several kinds of airspaces, which are visually
> rendered differently (different color and decoration for the bounding
> polygon). also, the metadata (name of the airspace, low or high altitude
> boundary) should also be rendered as text.
> how I imagined all this is that somehow I'd define these concepts
> (airspaces, nav points, VOR/DME points, etc.), similarly to how roads,
> streets, etc. are defined for OSM. then I'd enter this data either
> manually, or by converting available electronic data sources into an OSM
> map - but of course not into the 'official' OSM map, but another one.
> then I'd render the map into bitmaps, and would use it either 'as is',
> or as an overlay on top of a regular OSM street map.
> maybe later, I'd also draw airport approach maps, and airport taxi maps,
> which also require some special concepts, metadata & rendering.
> as you see, basically my concept is to utilize the wide array of tools &
> methods already available in relation to OSM - but I wouldn't want to
> 'litter' the 'offical' OSM database with aviation data.
> please let me know if this is in alignment with OSM, or if this is
> against OSM in general.
> as for the specific remarks - thank you very much again, please see my
> comments below.
> On 11/08/10 14:33, Frederik Ramm wrote:
>> The general answer is you need someone to record the data (using
>> appropriate tagging - no need to record that anywhere) and then someone
>> else to make a map from that. OpenStreetMap will not magically make
>> airspace maps but it will accept airspace data and others who want to
>> make airspace maps can then use that data.
> yes, I'm aware of that - and already working on getting data sources.
>> You are not creating new data types, just new tags. You can add new
>> presets to these editors but you don't need to.
> this is what I'm not sure about, if I can make all this happen without
> creating new data types - see above.
>> There are many techniques. Most people render map tiles with Mapnik and
>> a combination of mod_tile and renderd or tirex. Read more on the wiki.
> thank you - I'll ready up on these.
>> Sure, you can create transparent tiles if you want.
> this is helpful - thank you!
>> In general, OSM tries to follow the "on the ground rule", i.e. we want
>> to record stuff that can be easily seen and cross-checked by other
>> mappers. Airspace tends to not fall in this category so it will be
>> difficult. Also there is no compelling reason to have it in OSM as it
>> will only rarely be related to other features (editing the airspace in
>> your editor will usually not become easier because you already have the
>> road grid or so).
> I agree. as I tried to point out earlier, I wouldn't want to put
> airspace data into the 'official' OSM map / data set. I'd store this
> information independently.
>> All this really, in my opinion, speaks for a *separate* database that
>> contains airspace. Do not stuff that into OSM; record it in an extra
>> system, from which you can then create airspace tiles and overlay them
>> over OSM maps.
> totally agree - as said, I'd plan to use the great tools available
> around OSM, but in a different database.
> On 11/08/10 15:18, OJ W wrote:
>> If you have a source of data that can be used, then entering that into
>> openstreetmap is usually trivial.  Getting the data tends to be the
>> problem.
> but, as said earlier - how would I deal with the special nature of this
> data?
>> For example I have a converter for [some elements of] ARINC424 data,
>> although it's not legally possible to upload the results.
> I'm working on the legalities already.
> On 11/08/10 15:23, Pieren wrote:
>> I fully agree on that. I mapped a small village near an airport and I
>> was happy to not edit under/between dozen aerial ways (even if it can be
>> filtered on JOSM now, it's not possible on all editors and you would
>> download the data anyway and all attached relations from the API - and
>> long distance ways are sometimes a problem).
>> Note that the same arguments could apply for underground or inhouse maps.
> totally agree - I would put all this into a separate database. BTW, how
> would one set up his own OSM online database for such a purpose?
> Akos
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev

More information about the dev mailing list