[OSM-dev] aviation maps?

Ákos Maróy akos at maroy.hu
Wed Aug 11 18:05:31 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).

oh my :) well, let's leave the security skeptics for themselves. in
general, aviation maps are as basic a necessity for safe transportation
as road maps and road signs are. and they are freely available to
anyone, who is willing to buy such maps - similarly to road maps.

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

sounds interesting. how would one then make this information visible on
the generated map? is there a way to describe the rendering process so
that such points are rendered in something what is 'usual' on an
aviation map?

> My opinion is that air routes are as compatible with OSM as sea routes
> are. I agree that final approach charts (For example:
> http://www.aipchile.cl/dasa/aip_chile_con_contenido/aipmap/SCVM/SCVM%20IAC1.pdf)
> 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.

I totally agree. for one thing, these do change, but the changes are
published well in advance for everyone to prepare.

OTOH, approach charts will be trick to handle, as there are several
charts for the same area, depending on VFR or IFR approaches, or even
depending on which approach one uses. thus this has to be handled a bit
specially, as sort of 'a number of charts for the same, reasonably small
area', of which only one should be shown at a time. moreover a
'recommended' zoom level and clipping / orientation is also desirable here.

> 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.

thank you - most probably this would be a good way to go.

what I still don't understand is, and sorry for being so
un-knowledgable, is how the rendering process is handled - from
vector-based OSM map definitions to map tiles.


More information about the dev mailing list