[OSM-dev] aviation maps?

Ákos Maróy akos at maroy.hu
Wed Aug 11 15:00:51 BST 2010


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



More information about the dev mailing list