What's the idea? Only hungary?

[Axel Müller]

If I enter "http://www.openaviationmap.org/" into the browser I'm led to a page only displaying hungarian airspace. Is that the idea of OpenAviationMap?

"Open" does not suggest this limitation to hungary.

Opposite of what I'm used to at OpenStreetMap there is no way to login or an explanation of how am I supposed to work with OAM or to contribute.

If followed the link to https://code.google.com/p/openaviationmap/ which contains the software stack. However I don't want to set up another clone of OSM - I would like to contribute data but of course I want to make sure that the data isn't gone two weeks later.

So what is the current status of this project?

Best regards,

Axel

[Ákos Maróy]

Dear Axel,

Thank you for your interest in Open Aviation Maps.

the project is in a state of transition at the moment. you can also get
an overview here: https://code.google.com/p/openaviationmap/wiki/Roadmap

the current status is: the Open Aviation Map stack renders data based on
the OSM PostGIS database model, using GeoTools / GeoServer. the
rendering is two-fold: 'ground data' is rendered from the 'usual' OSM
database. aviation data is rendered from another PostGIS database that
contains aviation data. rendering is done using Styled Layed Descriptor
(SLD) files which are specially pre-processed (for a number of reasons).
this process results in two layers of tile sets that are superimposed on
each other. these tiles are used both in the web view and in the android
app. print (paper) rendering is done from the same datasources, but not
on a tileset basis.

the Hungarian data is imported from the XML representation of the
Hungarian eAIP publications.

currently indeed we only have Hungarian aviation data, and we have the
code to import all airport data from OurAirports.

currrently I'm rendering the ground maps for the whole of Europe, and
then maybe more European data can be added.



the future goals of the project is to work of aviation data from an AIXM
format, see http://aixm.aero/ , and also to work with in true 3D, in a
sort of augmented reality fashion.

for this I'm currently investigating a web-based viewer, cesium, that
could be a first step in this direction: http://cesium.agi.com/ . but of
course the idea would be to have a full software stack around on mobile
devices, desktops, etc.

for storing AIXM-based data, it would may be simple a file-based
repository like github, or geo-git: https://github.com/opengeo/GeoGit


most of the work on the project is done by me personally, and in my free
time (I have other projects going on in parallel as well). naturally,
all helping hands are welcome.


can you share with us what your interest is / would be in Open Aviation
Maps?


Akos

[Axel Müller]

Hi Akos,

the project is in a state of transition at the moment. you can also get
an overview here: https://code.google.com/p/openaviationmap/wiki/Roadmap

This roadmap is focused only on technical issues. While the technical issues have to be solved there also needs to be a vision, what part the "community" should play. Look at the OpenStreetMap project: It has a rather small number of people developing the tools, core users participating in discussions about conventions, tags etc. and a lot of users doing mapping around the world.

 

most of the work on the project is done by me personally

That's the point: If OAM should be more than your personal aviation map of Hungary you have to think it from the community perspective. In my opinion Morton already has done a very good job in taking the OSM tool chain and applying it to aviation. This means that there are established processes and known tools.

can you share with us what your interest is / would be in Open Aviation Maps?

First: I used to map for OSM using JOSM and also did rendering using Osmarender. 

I have developed an Android Application for paragliders/paramotors. I would like to display aerodromes and related traffic circuits. Unfortunately there is no public database available with this kind of information.There are websites where aerodrome details including maps showing traffic circuits but I'm interested in raw data (the points that make up the traffic circuit). Yesterday I checked some OSM discussions again - bottom line is, that they only want "visible" things to be mapped in their database: a taxiway of an aerodrome is ok, but a the traffic circuit is not. OAM would be the perfect platform but without a community it is dead. Only a community can provide the data for all kind of purposes and will also keep the data up-to-date. For instance, I would like to add details of aerodromes within a radius of 100 km around my living location. I would like to modify my app to retrieve aerodrome details and I would tell the users of my app to add details of aerodromes in their region too. But all this cannot be done if there is no vision about the community.

Best regards,

Axel

[Ákos Maróy]

Axel,

This roadmap is focused only on technical issues. While the technical issues have to be solved there also needs to be a vision, what part the "community" should play.

IMHO the vision is descirbed in the first sentence on the project home page:

This project aims to create Open Aviation Maps to be used by general aviation enthusiasts - similarly to the Open Street Maps project. The goal is to allow usage of these maps on handheld devices (smart phones, tablets) during flight.

Look at the OpenStreetMap project: It has a rather small number of people developing the tools, core users participating in discussions about conventions, tags etc. and a lot of users doing mapping around the world.

I totally agree

unfortunately it's kind of a catch-22 situations - few toolsets mean the data cannot be used in a sensible way, and also no editing tools mean data contribution is difficult. but because if this, few people would contribute

 

most of the work on the project is done by me personally

That's the point: If OAM should be more than your personal aviation map of Hungary you have to think it from the community perspective.

it never meant to be 'my personal aviation map for Hungary'

In my opinion Morton already has done a very good job in taking the OSM tool chain and applying it to aviation. This means that there are established processes and known tools.

yes, Morton added very useful contributions as well, as you also point out, he's set up the OSM toolchain, etc. the current site is also running on his server.

can you share with us what your interest is / would be in Open Aviation Maps?

First: I used to map for OSM using JOSM and also did rendering using Osmarender.

great! what styling did you use? are the results available somewhere?

I have developed an Android Application for paragliders/paramotors.

sounds excellent! I'd really like to see your results? is it available somewhere?

I would like to display aerodromes and related traffic circuits. Unfortunately there is no public database available with this kind of information.There are websites where aerodrome details including maps showing traffic circuits but I'm interested in raw data (the points that make up the traffic circuit).

then we really share the same need & vision.

as you see, OAM aims to become such a database.

Yesterday I checked some OSM discussions again - bottom line is, that they only want "visible" things to be mapped in their database: a taxiway of an aerodrome is ok, but a the traffic circuit is not.

yes, I had the same discussion with them years ago

OAM would be the perfect platform but without a community it is dead. Only a community can provide the data for all kind of purposes and will also keep the data up-to-date. For instance, I would like to add details of aerodromes within a radius of 100 km around my living location. I would like to modify my app to retrieve aerodrome details and I would tell the users of my app to add details of aerodromes in their region too. But all this cannot be done if there is no vision about the community.

IMHO the vision is all there - all community contributions are welcome. on top of that, each region should be proof-read or verified in a manner, so as to be able to say that the data is 'current' (as in 'current according to the current AIP or other official data sources)

where we're in a limbo now is the toolchain: we don't like the 'old' (OSM/PostGIS-based) toolchain, and the new, AIXM-based toolchain is not yet ready. where of course I would have though that we'd have the new toolchain ready by now.

thus, maybe it would make sense to use the old toolchain until we have the new one ready. I see you're familiar with OSM, JOSM, etc. you could contribute to the OAM database via this stack.

for this, we'd have to talk to Morten about the current state of the OAM - OSM server that he has set up a while ago.


Akos

[Morten Olsen Lysgaard]

Hi Axel. Nice to see you have interest in the project. I understand that you want to contribute to the OAM system.
First things first, there's is a OSM stack running on http://openaviationmap.org:3000/ This is where we currently save
our airspace and navaid data.
We want to migrate to another stack using AIXML because all countries is the EU are obliged to switch to AIXML as
transfer format for aviation data in the future. Thus we will get all our data for free from the special goverment agencies
when this happens.
I understand that you would like this project to be just in the spirit of OSM but there are some things that make aviation data
a bit harder to map. First, there is zero tolerance for error. We can't have the wrong attributes on our airspaces or something like
that if people are gonna rely on this. Second, it's really hard to manually map airspaces and not a lot of peoples are up to it.
It takes a certain technical skill to read AIPs and understand their meaning and after this translate it to an airspace in JOSM.
Untill now I haven't meet people that are dedicated and skilled enogh to do this. I don't have the time to do this myself as I would
rather focus on the technical stack, since this lets us do things like for Hungary: map a whole country in some seconds using goverment
given data. What we need are people pushing their goverments to release their airspace data in an open format. If this happens it would be a
no brainer to import them into our database, enshure they are correct and create styles for them.

So as things are now we are a bit focused on getting data from goverments, where we can trust the quality and do batch processing.
There is though a other aspect to the project; we could need a pure community driven feature store too. This would be a place to but
unofficial airstrips, hang-gliding spots you name it. It would be much less locked down that the master OAM map and would let anyone
edit just like OSM. What do you think?

--
You received this message because you are subscribed to the Google Groups "openaviationmap" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openaviationm...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Axel Müller]

Hi Akos,

can you share with us what your interest is / would be in Open Aviation Maps?

First: I used to map for OSM using JOSM and also did rendering using Osmarender.

great! what styling did you use? are the results available somewhere?

I simply downloaded the OSM data of a bounding box, rendered a vector image of it and converted that to a bitmap. I did it only to verify the modifications I had done on the mapping data. Using this approach I was able to correct things before the weekly rendering of OSM took place.

 

I have developed an Android Application for paragliders/paramotors.

sounds excellent! I'd really like to see your results? is it available somewhere?

Look for "AndroFlight" in Google Playstore or at www.androflight.com.

 

I would like to display aerodromes and related traffic circuits. Unfortunately there is no public database available with this kind of information.There are websites where aerodrome details including maps showing traffic circuits but I'm interested in raw data (the points that make up the traffic circuit).

then we really share the same need & vision.
as you see, OAM aims to become such a database.

Glad to head that :-) 

IMHO the vision is all there - all community contributions are welcome. on top of that, each region should be proof-read or verified in a manner, so as to be able to say that the data is 'current' (as in 'current according to the current AIP or other official data sources)

I have to stress again the fact that http://www.openaviationmap.org does nothing say about contribution and how to do that. The is a button leading to the mailing list - that's all. Compare this to http://www.openstreetmap.de/ - it is german but it says "How can I contribute?" or "How can I use the data?".

 

thus, maybe it would make sense to use the old toolchain until we have the new one ready. I see you're familiar with OSM, JOSM, etc. you could contribute to the OAM database via this stack.

Where are the tags documented that can be used? Is there a "tag watch" running to monitor the tags being used?

Best regards,

Axel

[Axel Müller]

Hi Morton,

First things first, there's is a OSM stack running on http://openaviationmap.org:3000/ This is where we currently save
our airspace and navaid data.

Using JOSM I'm not able to connect to this URL. I tried File->Open Location. Again - this should be documented somewhere in the Wiki. BTW - all links to the Wiki are dead!

 

We want to migrate to another stack using AIXML because all countries is the EU are obliged to switch to AIXML as
transfer format for aviation data in the future.

That's probably a good idea but what happens meanwhile? I'm working in the area of enterprise software development, where the rule is: You don't shut down the production system until the new system is available and was fully tested. And even then you operate both systems in parallel for risk reasons.

 

Thus we will get all our data for free from the special goverment agencies when this happens.

I don't believe that until it happens. Maybe some countries do it but others will not. It is the same with OSM: Some cities provide data, some do not. You have to deal with both situations. OSM does it and is successful in doing so.

 

I understand that you would like this project to be just in the spirit of OSM but there are some things that make aviation data
a bit harder to map. First, there is zero tolerance for error. We can't have the wrong attributes on our airspaces or something like
that if people are gonna rely on this.

OAM is (and won't be) an official publication channel. At least in Germany a valid flight preparation may only be based on official publications. Of course people are relying on other sources as well but that's not the official way. OAM should be relyable, but no necessarily offical. If offical data is available - used it. But OAM should provide means to enrich this data. Remember: official things are often slow ... BTW: For Germany, AndroFlight uses OpenAir data files which released by the official air control authority in co-operation with one of the aero clubs. 

In my opinion the OSM approach has proven that the mapping data won't be messed up by the community. If enough people participate changes on mapping data will be monitored by other community members.

 

Second, it's really hard to manually map airspaces and not a lot of peoples are up to it.

Again - I don't want to map airspaces - for most countries they are available for free. My interest are traffic circuits, reporting points, radio frequencies, ...

 

What we need are people pushing their goverments to release their airspace data in an open format. If this happens it would be a
no brainer to import them into our database, enshure they are correct and create styles for them.

If it is that easy I don't understand why OSM data had to be contributed mostly by community members. All the data is available at local authorities - they need it themselves if you ask to build a house of if they plan a new pipeline. But they don't provide the data for free! The world isn't just black and white ...

So as things are now we are a bit focused on getting data from goverments, where we can trust the quality and do batch processing.

Good luck then ;-) I doubt that this will be a successful approach ( the data gathering, not the batch processing ...)

 

There is though a other aspect to the project; we could need a pure community driven feature store too. This would be a place to but
unofficial airstrips, hang-gliding spots you name it. It would be much less locked down that the master OAM map and would let anyone
edit just like OSM. What do you think?

It depends on how this "feature store" should work. I wouldn't try to split OAM into an official OAM and a community OAM. By default, community should be able to contribute. If official data becomes available for an OAM entity (airspace, traffic circuit, runway, ...) it can replace the exact counterpart of the community provided data. You can even lock the official data to avoid changes by the community. But first of all OAM have to become usable. I bookmarked OAM about a year ago right after you started it. I posted some messages on your blog at this time. One year later there are a lot of ideas but outside Hungary OAM does not have any value at all currently. We will see, if this changes ...

Best regards,

Axel

[Ákos Maróy]

Axel,

Hi Akos,

can you share with us what your interest is / would be in Open Aviation Maps?

First: I used to map for OSM using JOSM and also did rendering using Osmarender.

great! what styling did you use? are the results available somewhere?

I simply downloaded the OSM data of a bounding box, rendered a vector image of it and converted that to a bitmap. I did it only to verify the modifications I had done on the mapping data. Using this approach I was able to correct things before the weekly rendering of OSM took place.

I see!

 

I have developed an Android Application for paragliders/paramotors.

sounds excellent! I'd really like to see your results? is it available somewhere?

Look for "AndroFlight" in Google Playstore or at www.androflight.com.

looks great! congratulations for your app!

 

I would like to display aerodromes and related traffic circuits. Unfortunately there is no public database available with this kind of information.There are websites where aerodrome details including maps showing traffic circuits but I'm interested in raw data (the points that make up the traffic circuit).

then we really share the same need & vision.
as you see, OAM aims to become such a database.

Glad to head that :-)

:)

IMHO the vision is all there - all community contributions are welcome. on top of that, each region should be proof-read or verified in a manner, so as to be able to say that the data is 'current' (as in 'current according to the current AIP or other official data sources)

I have to stress again the fact that http://www.openaviationmap.org does nothing say about contribution and how to do that. The is a button leading to the mailing list - that's all. Compare this to http://www.openstreetmap.de/ - it is german but it says "How can I contribute?" or "How can I use the data?".

valid point indeed.

as said, currently there is no 'easy way' to contribute, and this is the main reason :(

 

thus, maybe it would make sense to use the old toolchain until we have the new one ready. I see you're familiar with OSM, JOSM, etc. you could contribute to the OAM database via this stack.

Where are the tags documented that can be used? Is there a "tag watch" running to monitor the tags being used?

Morten used to have a description about the tags - Morten, do we still have this?

but the easiest is to download say the dump of Hungary (via JOSM for example, the server allows you do download the whole area of Hungary from the server), and look at features there.

I'm really sorry not to have good documentation around. as said earlier, we really wanted to migrate to using AIXM, which is quite well documented in itself.

another source of info is to look at this class: https://code.google.com/p/openaviationmap/source/browse/trunk/oam-java-tools/src/main/java/org/openaviationmap/converter/OamConverter.java

which basically includes all the tags we use for the moment when generating an OAM file from aviation data.

again, I'm sorry not to be able to offer better documentation.


Akos

[Ákos Maróy]

Axel,

Hi Morton,

First things first, there's is a OSM stack running on http://openaviationmap.org:3000/ This is where we currently save
our airspace and navaid data.

Using JOSM I'm not able to connect to this URL. I tried File->Open Location.

go to Edit -> Preferences, there the second tab (looks like the globe), there OSM Server URL: http://openaviationmap.org:3000/api , click Validate - this should work fine

after this, you can say select File -> Download from OSM, select the area around Hungary, and it should download the whole of Hungary into JOSM.

Again - this should be documented somewhere in the Wiki. BTW - all links to the Wiki are dead!

the reason for this is that the old instance of this OSM stack dies when Morten's server crashed - and it wasn't restored properly since then.

we're sorry for that

 

We want to migrate to another stack using AIXML because all countries is the EU are obliged to switch to AIXML as
transfer format for aviation data in the future.

That's probably a good idea but what happens meanwhile? I'm working in the area of enterprise software development, where the rule is: You don't shut down the production system until the new system is available and was fully tested. And even then you operate both systems in parallel for risk reasons.

yes, you're totally right. we just thought the migration would have already taken place by now, and then we'd add additional data in AIXM.

as you also point out, this is not the case.

 

Thus we will get all our data for free from the special goverment agencies when this happens.

I don't believe that until it happens. Maybe some countries do it but others will not. It is the same with OSM: Some cities provide data, some do not. You have to deal with both situations. OSM does it and is successful in doing so.

I agree with Axel on this, unfortunately

 

I understand that you would like this project to be just in the spirit of OSM but there are some things that make aviation data
a bit harder to map. First, there is zero tolerance for error. We can't have the wrong attributes on our airspaces or something like
that if people are gonna rely on this.

OAM is (and won't be) an official publication channel. At least in Germany a valid flight preparation may only be based on official publications. Of course people are relying on other sources as well but that's not the official way. OAM should be relyable, but no necessarily offical. If offical data is available - used it. But OAM should provide means to enrich this data. Remember: official things are often slow ... BTW: For Germany, AndroFlight uses OpenAir data files which released by the official air control authority in co-operation with one of the aero clubs. 

In my opinion the OSM approach has proven that the mapping data won't be messed up by the community. If enough people participate changes on mapping data will be monitored by other community members.

I beg to differ, but my approach is: we should have both :)

IMHO there should be an 'official' / 'certified' / 'hardened' / etc. version of the data, that actually can be used for navigation, and would pass a 'ramp check'

OTOH, there should be 'extended' data as well, that includes additional stuff

but, let's have this discussion when we have enough data :)

 

Second, it's really hard to manually map airspaces and not a lot of peoples are up to it.

Again - I don't want to map airspaces - for most countries they are available for free. My interest are traffic circuits, reporting points, radio frequencies, ...

as for reporting points & frequencies: currently we do handle designated navaids (that is, GPS locations with names) and radio-based navaids - but not communication frequences. (well, we have comm frequencies for airports in the OSM data, but they are not visualized on rendering)

for traffic circiuits: we don't have anything of that sort at the moment, but rendering wouldn't be difficult with SLD

 

What we need are people pushing their goverments to release their airspace data in an open format. If this happens it would be a
no brainer to import them into our database, enshure they are correct and create styles for them.

If it is that easy I don't understand why OSM data had to be contributed mostly by community members. All the data is available at local authorities - they need it themselves if you ask to build a house of if they plan a new pipeline. But they don't provide the data for free! The world isn't just black and white ...

yes, unfortunately you're right

So as things are now we are a bit focused on getting data from goverments, where we can trust the quality and do batch processing.

Good luck then ;-) I doubt that this will be a successful approach ( the data gathering, not the batch processing ...)

actually I did manage to get the XML version of the eAIP publication from HungaroControl. you also mention that for Germany the OpenAir publication is somehow related to the authority.

but you're right, this is never going to happen universally

OTOH, government agencies do publish this data, albeit not in machine-readable form - so we always have access to the base data itself.

 

There is though a other aspect to the project; we could need a pure community driven feature store too. This would be a place to but
unofficial airstrips, hang-gliding spots you name it. It would be much less locked down that the master OAM map and would let anyone
edit just like OSM. What do you think?

It depends on how this "feature store" should work. I wouldn't try to split OAM into an official OAM and a community OAM. By default, community should be able to contribute. If official data becomes available for an OAM entity (airspace, traffic circuit, runway, ...) it can replace the exact counterpart of the community provided data. You can even lock the official data to avoid changes by the community.

yes, I have the same thinking (see above)

But first of all OAM have to become usable. I bookmarked OAM about a year ago right after you started it. I posted some messages on your blog at this time. One year later there are a lot of ideas but outside Hungary OAM does not have any value at all currently. We will see, if this changes ...

yes, you're pointing out the shortcomings quite well :)


as for my roadmap: I want to create proper 3D representation of the data, both on the web, on tables and on the desktop/laptop. this would include AR-like representation as well. and then I'd add the data that's available, and enrich / expand the area coverage, etc.

but this can / could / should happen in parallel actually.


Akos

[Morten Olsen Lysgaard]

On Tue, Apr 30, 2013 at 7:55 AM, Axel Müller <camue...@googlemail.com> wrote:
> I don't believe that until it happens. Maybe some countries do it but others
> will not. It is the same with OSM: Some cities provide data, some do not.
> You have to deal with both situations. OSM does it and is successful in
> doing so.

Well, it's happened both for Hungary and Germany, in the form op e-api
and openair
data files.

> OAM is (and won't be) an official publication channel. At least in Germany a
> valid flight preparation may only be based on official publications. Of
> course people are relying on other sources as well but that's not the
> official way. OAM should be relyable, but no necessarily offical. If offical
> data is available - used it. But OAM should provide means to enrich this
> data. Remember: official things are often slow ... BTW: For Germany,
> AndroFlight uses OpenAir data files which released by the official air
> control authority in co-operation with one of the aero clubs.
> In my opinion the OSM approach has proven that the mapping data won't be
> messed up by the community. If enough people participate changes on mapping
> data will be monitored by other community members.

OAM will never be a official publication but even a unofficial
aviation data publication needs
some security checks. I realy want to utilize a bigger community but
I've not yet come up with
a colaboration model that has worked.

I'd be very happy for some advice on this. Do you have ideas how we
could create a colaboration
model for the OAM project?

>> Second, it's really hard to manually map airspaces and not a lot of
>> peoples are up to it.
> Again - I don't want to map airspaces - for most countries they are
> available for free. My interest are traffic circuits, reporting points,
> radio frequencies, ...

I don't see that this invalidates my argument. I haven't found anyone
willing to read APIs and recreate them in JOSM, be it airspaces, circuits or
reporting points.

> If it is that easy I don't understand why OSM data had to be contributed
> mostly by community members. All the data is available at local authorities
> - they need it themselves if you ask to build a house of if they plan a new
> pipeline. But they don't provide the data for free! The world isn't just
> black and white ...

Yes, all data exists, but i would hardly call it available. It's lying
in the dark dwelling
databases of grumpy old aviation authorities, neither open nor free.
This is one of the hardest tasks we meet, politics.

> It depends on how this "feature store" should work. I wouldn't try to split
> OAM into an official OAM and a community OAM. By default, community should
> be able to contribute. If official data becomes available for an OAM entity
> (airspace, traffic circuit, runway, ...) it can replace the exact
> counterpart of the community provided data.

> You can even lock the official data to avoid changes by the community.

Is this possible in the OSM stack? To lock a feature for further edits?

> But first of all OAM have to become
> usable. I bookmarked OAM about a year ago right after you started it. I
> posted some messages on your blog at this time. One year later there are a
> lot of ideas but outside Hungary OAM does not have any value at all
> currently. We will see, if this changes ...

I see it more like this: In one year we've successfully made a VFR map
for a whole country, that's no
small feat for two people :)

[Ákos Maróy]

Morten,

OAM will never be a official publication but even a unofficial
aviation data publication needs
some security checks.

I don't see this as a problem - one can / should go through this process.

 I realy want to utilize a bigger community but
I've not yet come up with
a colaboration model that has worked.

I'd be very happy for some advice on this. Do you have ideas how we
could create a colaboration
model for the OAM project?

yeah, good question :)

Second, it's really hard to manually map airspaces and not a lot of
peoples are up to it.

Again - I don't want to map airspaces - for most countries they are
available for free. My interest are traffic circuits, reporting points,
radio frequencies, ...

I don't see that this invalidates my argument. I haven't found anyone
willing to read APIs and recreate them in JOSM, be it airspaces, circuits or
reporting points.

yes, this is the central issue indeed. data entry is cumbersome, thus not too many people would be willing to do it.

If it is that easy I don't understand why OSM data had to be contributed
mostly by community members. All the data is available at local authorities
- they need it themselves if you ask to build a house of if they plan a new
pipeline. But they don't provide the data for free! The world isn't just
black and white ...

Yes, all data exists, but i would hardly call it available. It's lying
in the dark dwelling
databases of grumpy old aviation authorities, neither open nor free.
This is one of the hardest tasks we meet, politics.

I disagree with this point. the AIP publications are public, and they are all published by local authorities, and collected together by EuroControl as well, here: http://www.ead.eurocontrol.int/publicuser/protect/pu/main.jsp

yes, free registration required, etc. but the information is there in a human-readable form

You can even lock the official data to avoid changes by the community.

Is this possible in the OSM stack? To lock a feature for further edits?

I'm not sure about that, OTOH I'm not thinking about the OSM stack in the medium / long term

But first of all OAM have to become
usable. I bookmarked OAM about a year ago right after you started it. I
posted some messages on your blog at this time. One year later there are a
lot of ideas but outside Hungary OAM does not have any value at all
currently. We will see, if this changes ...

I see it more like this: In one year we've successfully made a VFR map
for a whole country, that's no
small feat for two people :)

:)))


Akos

[Antonio Locandro]

can we have something similar to this? http://ideditor.com/

I know how to read the AIP data, to start I would say add
1. Navaids
2. Designated Points
3. ARP

DAFIF files used to be maintained.

I say get a person from each country comit to enter this info each time new updates are available, For instance UK AIP publishes 56 days in advance, that could work to make edits before hand and have them available on effective date

[Antonio Locandro]

[Ákos Maróy]

On 01/05/13 07:43, Antonio Locandro wrote:
> can we have something similar to this? http://ideditor.com/

in theory - yes :)

in practice - well, someone would have to implement it, because the
regular OSM schema is not enough to describe aviation data

>
> I know how to read the AIP data, to start I would say add
> 1. Navaids
> 2. Designated Points
> 3. ARP

excellent!

currently we've used JOSM to this actually (and automated parsing, but
that's difficult from an AIP)

>
> DAFIF files used to be maintained.

I'm not familiar about DAFIF, can you provide more details?

>
> I say get a person from each country comit to enter this info each time new updates are available, For instance UK AIP publishes 56 days in advance, that could work to make edits before hand and have them available on effective date
>

yes, this is my idea as well

[Antonio Locandro]

http://www.ourairports.com/data/ maybe talk to this project and unite or agree on something?

http://www.navaid.com/dafif.html

[Antonio Locandro]

[Axel Müller]

Hi Akos,

First things first, there's is a OSM stack running on http://openaviationmap.org:3000/ This is where we currently save
our airspace and navaid data.

Using JOSM I'm not able to connect to this URL. I tried File->Open Location.

go to Edit -> Preferences, there the second tab (looks like the globe), there OSM Server URL: http://openaviationmap.org:3000/api , click Validate - this should work fine

after this, you can say select File -> Download from OSM, select the area around Hungary, and it should download the whole of Hungary into JOSM.

I'm getting "Failed to connect to http://openaviationmap.org:3000/api" during validation. Id did not enter an OSM username / OSM password. Do I need one? How to get that?

Second, it's really hard to manually map airspaces and not a lot of peoples are up to it.

Again - I don't want to map airspaces - for most countries they are available for free. My interest are traffic circuits, reporting points, radio frequencies, ...

as for reporting points & frequencies: currently we do handle designated navaids (that is, GPS locations with names) and radio-based navaids - but not communication frequences. (well, we have comm frequencies for airports in the OSM data, but they are not visualized on rendering)

I was talking about the comm frequencies of airports which are printed in the official ICAO map as well: http://www.vfr-bulletin.de/web20/index.htm (select ICAO layer).

for traffic circiuits: we don't have anything of that sort at the moment, but rendering wouldn't be difficult with SLD

My primary interest is to add traffic circuits to database and be able to retrieve this data via bounding box. Traffic circuits are not printed in ICAO map but in VFR approach map (at least in Germany).

 

But first of all OAM have to become usable. I bookmarked OAM about a year ago right after you started it. I posted some messages on your blog at this time. One year later there are a lot of ideas but outside Hungary OAM does not have any value at all currently. We will see, if this changes ...

yes, you're pointing out the shortcomings quite well :)

It wasn't my intention to blame anyone. Consider my statements as a push to broaden OAM :-)

as for my roadmap: I want to create proper 3D representation of the data, both on the web, on tables and on the desktop/laptop. this would include AR-like representation as well. and then I'd add the data that's available, and enrich / expand the area coverage, etc.

3D representation is nice, but first of all we need data. Do we have any data right now except for Hungary? Since I cannot connect with JOSM I can't answer than myself ...

but this can / could / should happen in parallel actually.

That's the point.

Best regards,

Axel

[Antonio Locandro]

this ourairports project has 6300 members if we can attract 10 % we could make things progress faster

[Ákos Maróy]

On 01/05/13 08:14, Antonio Locandro wrote:
> http://www.ourairports.com/data/ maybe talk to this project and unite or agree on something?

actually, Raymond Raw already implemented an import code for ourairports
data - we just have to import it :) it's checked in into our code
repository :)
>
> http://www.navaid.com/dafif.html
>
>
>
I see. is this data still available?

[Ákos Maróy]

Axel,

I'm getting "Failed to connect to http://openaviationmap.org:3000/api" during validation. Id did not enter an OSM username / OSM password. Do I need one? How to get that?

interesting, it fails to connect for me as well now.

Morten, do you have any idea why this doesn't work at the moment?

I was talking about the comm frequencies of airports which are printed in the official ICAO map as well: http://www.vfr-bulletin.de/web20/index.htm (select ICAO layer).

yes, now we have this in the data model, but it is not rendered when generating tiles at the moment. of course rendering can be changed.

but, as tileset rendering gives really limited capabilities, basically this is what I want to move forward for better rendering approaches. OTOH, as pointed our earlier, we should collect & display as much data as possible using our current approach.

for traffic circiuits: we don't have anything of that sort at the moment, but rendering wouldn't be difficult with SLD

My primary interest is to add traffic circuits to database and be able to retrieve this data via bounding box. Traffic circuits are not printed in ICAO map but in VFR approach map (at least in Germany).

yes, same here. if you look at the roadmap / open tickets, I already have a ticket for this - which means I have the same goals as well :)

  It wasn't my intention to blame anyone. Consider my statements as a push to broaden OAM :-)

:))

as for my roadmap: I want to create proper 3D representation of the data, both on the web, on tables and on the desktop/laptop. this would include AR-like representation as well. and then I'd add the data that's available, and enrich / expand the area coverage, etc.

3D representation is nice, but first of all we need data. Do we have any data right now except for Hungary? Since I cannot connect with JOSM I can't answer than myself ...

in the OSM dataset, we have some data for Norway, and maybe some for Germany?

we also have a full OurAirports data import facility written by Raymond Raw, but we didn't actually import the data.

Raymond is also working now on an OpenAir import facility.

these could bootstrap some of the data importing. for anything else, we'd need to either manually enter data, or write additional eAIP import code, which is quite tedious.

but this can / could / should happen in parallel actually.

That's the point.

totally agree..


Akos

[Ákos Maróy]

On 01/05/13 08:18, Antonio Locandro wrote:
> this ourairports project has 6300 members if we can attract 10 % we could make things progress faster
>

agreed

[Axel Müller]

Akos,

but the easiest is to download say the dump of Hungary (via JOSM for example, the server allows you do download the whole area of Hungary from the server), and look at features there.

another source of info is to look at this class: https://code.google.com/p/openaviationmap/source/browse/trunk/oam-java-tools/src/main/java/org/openaviationmap/converter/OamConverter.java

which basically includes all the tags we use for the moment when generating an OAM file from aviation data.

We have to extract the tag usage from them and add it to the Wiki once the Wiki structure is there.

Axel

[Ákos Maróy]

On 01/05/13 09:21, Axel Müller wrote:

We have to extract the tag usage from them and add it to the Wiki once the Wiki structure is there.

totally agree

as said earlies, we used to have this, but was wiped out by Morten's machines crash last summer :(

[Axel Müller]

Morton,

>
>> I don't believe that until it happens. Maybe some countries do it but others
>> will not. It is the same with OSM: Some cities provide data, some do not.
>> You have to deal with both situations. OSM does it and is successful in
>> doing so.
> Well, it's happened both for Hungary and Germany, in the form op e-api
> and openair
> data files.

I never heard of e-api. What exactly does this file contain?
In the Wiki the data source types (e-api, openair, ...) should also be
documented along with the type of information extracted from them.

>
> OAM will never be a official publication but even a unofficial
> aviation data publication needs
> some security checks. I realy want to utilize a bigger community but
> I've not yet come up with
> a colaboration model that has worked.
>
> I'd be very happy for some advice on this. Do you have ideas how we
> could create a colaboration model for the OAM project?

"Collaboration model" sounds complicate. One never knows everything in
advance (models often suggests this) and therefore I rather like to
handle change properly.
I prefer a "hands on" approach and don't like to reinvent the wheel.
Let's handle things similar to OSM until there is a real reason to
handle some aspects in a different way. But this has to be decided later
since I'm not aware of reasons why things should be different right now.
BTW: I don't/did not play any "important" role in OSM - I'm just one of
many thousand contributors, but I identify myself with the vision of OSM
and spent time contributing.

>>> Second, it's really hard to manually map airspaces and not a lot of
>>> peoples are up to it.
>> Again - I don't want to map airspaces - for most countries they are
>> available for free. My interest are traffic circuits, reporting points,
>> radio frequencies, ...
> I don't see that this invalidates my argument. I haven't found anyone
> willing to read APIs and recreate them in JOSM, be it airspaces, circuits or
> reporting points.

Assumed that OAM doesn't have traffic circuits of Germany right now in
the database I would like to do (I already tried this some time ago with
OSM but did not upload):

Using JSOM I want to download the area the traffic circuit(s) will be
placed. Then get an VFR map image from www.airports.de and place it on a
image layer.
Afterwards scale the OAM layer to fit the scale of the image. Then
create the nodes, paths and tags.
With OSM data I found landmarks of the image in OSM data to be used for
matching - I don't know yet, how to accomplish this with OAM. Maybe I
create the nodes in OSM and apply the changes to OAM!?!?

>> You can even lock the official data to avoid changes by the community.
> Is this possible in the OSM stack? To lock a feature for further edits?

I don't know the internals of OSM database structure. Perhaps we should
not focus on (pessimistic) locks until we have real reason to put them
in place.
Some years ago somebody deleted almost all OSM data for Russia. Those
changes were rolled back. The same kind of rollback we have to be able
to do as well. A backup strategy have to be in place anyway! I wouldn't
want to contribute (spend my rare time) if all is gone if a hard disk
crash occurs.

>> But first of all OAM have to become
>> usable. I bookmarked OAM about a year ago right after you started it. I
>> posted some messages on your blog at this time. One year later there are a
>> lot of ideas but outside Hungary OAM does not have any value at all
>> currently. We will see, if this changes ...
> I see it more like this: In one year we've successfully made a VFR map
> for a whole country, that's no
> small feat for two people :)

Don't get me wrong - from the inside perspective you have accomplished a
lot! But you need the outside perspective as well if you really want OAM
to become sucessful :-)

Axel

[Axel Müller]

Assumed that OAM doesn't have traffic circuits of Germany right now in the database I would like to do (I already tried this some time ago with OSM but did not upload):

Using JSOM I want to download the area the traffic circuit(s) will be placed. Then get an VFR map image from www.airports.de and place it on a image layer.
Afterwards scale the OAM layer to fit the scale of the image. Then create the nodes, paths and tags.
With OSM data I found landmarks of the image in OSM data to be used for matching - I don't know yet, how to accomplish this with OAM. Maybe I create the nodes in OSM and apply the changes to OAM!?!?

This is labour day - why not doing something useful ;-)

I'm using the latest JOSM with PicLayer plugin. I written earlier I downloaded the area around the airfield so that the traffic circuits (there are 3 of them) are covered. Then I downloaded the picture from http://www.airports.de/component/option,com_mtree/task,viewlink/link_id,349/lang,de/ and loaded it in the picture layer. I reduced opacity of the picture layer to be able to view details of the data layer and the picture layer at the same time. I scaled the picture layer until it matched the scale of the data layer. For this matching I used the river and the roads which are shown on the map picture as well as on OSM data. Since there is probably nothing in OAM of this airfield right now and I selected and copied the complete aerodrom and inserted those nodes into a new data layer. In this new data layer I draw a path from the end of the runway, following the traffic circuit until I reached the oder end of this runway. And there it is - my first traffic circuit :-) I did not add any tag for now. Using menu "File -> Save as" I saved this data layer, opened another JOSM and loaded the file using "File -> Open". I guess that I would be able to upload this data into OAM once I can connect.

I have to admit that all this is a rather manual process and I would prefer to have an automatic data import of some kind. But if I have to choose between manual work and no data at all I would opt for the manual work. Besides: When I worked with JOSM some minutes ago I felt the same kind of pleasure like at times when I was mapping for OSM :-)

Axel

[Ákos Maróy]

great :)

Morten, would we want to give Axel upload rights to the OAM / OSM stack?

[Morten Olsen Lysgaard]

On Wed, May 1, 2013 at 4:20 PM, Ákos Maróy <ak...@maroy.hu> wrote:
> Morten, would we want to give Axel upload rights to the OAM / OSM stack?

Yes, ofcourse.
Axel:
The new url for the osm server instance is
http://osm.openaviationmap.org/api , put that in the configuration of
your JOSM.

If you already have a OAM user, configure JOSM with that user.
If not go to http://osm.openaviationmap.org/user/new and create one.
Then use JOSM to upload your data :)

--
Morten

[Axel Müller]

I'm using the latest JOSM with PicLayer plugin. I written earlier I downloaded the area around the airfield so that the traffic circuits (there are 3 of them) are covered. Then I downloaded the picture from http://www.airports.de/component/option,com_mtree/task,viewlink/link_id,349/lang,de/ and loaded it in the picture layer. I reduced opacity of the picture layer to be able to view details of the data layer and the picture layer at the same time. I scaled the picture layer until it matched the scale of the data layer. For this matching I used the river and the roads which are shown on the map picture as well as on OSM data. Since there is probably nothing in OAM of this airfield right now and I selected and copied the complete aerodrom and inserted those nodes into a new data layer. In this new data layer I draw a path from the end of the runway, following the traffic circuit until I reached the oder end of this runway. And there it is - my first traffic circuit :-) I did not add any tag for now. Using menu "File -> Save as" I saved this data layer, opened another JOSM and loaded the file using "File -> Open". I guess that I would be able to upload this data into OAM once I can connect.

I have to admit that all this is a rather manual process and I would prefer to have an automatic data import of some kind. But if I have to choose between manual work and no data at all I would opt for the manual work. Besides: When I worked with JOSM some minutes ago I felt the same kind of pleasure like at times when I was mapping for OSM :-)

I just returned from flying (paragliding - the wind was good today but no really enough thermals). But, there I met a guy responsible for ICAO charts at German Air Control (Deutsche Flugsicherung). I asked him if traffic circuits are available electronically somehow. He told me that (not only in Germany) traffic circuits are not made up by coordinates but simply drawn on a map, e.g. "right to that tower, south of this village, ...". There is no exact description of a traffic circuit! This means, that our approach to redraw the image is completely valid even if there is a small tolerance to the image since there is no exact data.
So we can go ahead ...

Axel

[Morten Olsen Lysgaard]

On Wed, May 1, 2013 at 6:25 PM, Axel Müller <ax...@mueller-family.de> wrote:
> I just returned from flying (paragliding - the wind was good today but no
> really enough thermals). But, there I met a guy responsible for ICAO charts
> at German Air Control (Deutsche Flugsicherung). I asked him if traffic
> circuits are available electronically somehow. He told me that (not only in
> Germany) traffic circuits are not made up by coordinates but simply drawn on
> a map, e.g. "right to that tower, south of this village, ...". There is no
> exact description of a traffic circuit! This means, that our approach to
> redraw the image is completely valid even if there is a small tolerance to
> the image since there is no exact data.
> So we can go ahead ...

Interesting! This is tottaly new for me. Well, you are right, traffic
circuts are probably
just best mapping directly in JOSM :)

[Axel Müller]

I'm using the latest JOSM with PicLayer plugin. I written earlier I downloaded the area around the airfield so that the traffic circuits (there are 3 of them) are covered. Then I downloaded the picture from http://www.airports.de/component/option,com_mtree/task,viewlink/link_id,349/lang,de/ and loaded it in the picture layer. I reduced opacity of the picture layer to be able to view details of the data layer and the picture layer at the same time. I scaled the picture layer until it matched the scale of the data layer. For this matching I used the river and the roads which are shown on the map picture as well as on OSM data. Since there is probably nothing in OAM of this airfield right now and I selected and copied the complete aerodrom and inserted those nodes into a new data layer. In this new data layer I draw a path from the end of the runway, following the traffic circuit until I reached the oder end of this runway. And there it is - my first traffic circuit :-) I did not add any tag for now. Using menu "File -> Save as" I saved this data layer, opened another JOSM and loaded the file using "File -> Open". I guess that I would be able to upload this data into OAM once I can connect.

I created my OAM user and the connection with JOSM was validated ok. Before I try to upload this traffic circuit I created there is a question: As desribed above I copied als OSM nodes and ways that make up that aerodrome: border, buildings, taxiways, runways. So we will duplicate aerodroms from OSM to OAM.
The aerodrome has the tag "aeroways=aerodrome". Morton - don't you think we could run a batch for this? Copy all ways with this tag including all child nodes/ways from OSM to OAM? This would make it easier since only the traffic circuits and tags would have to be added. Besides if no properly selected it easily happens that other nodes/ways not realy being children of the aerodrom are copied as well.

I will add a detailed description including screenshots to the Wiki once i have completed the whole process a couple of times. I assume that my OAM user is valid for the Wiki as well?

I'm feeling that we're making progress ...

Axel

[Morten Olsen Lysgaard]

On Wed, May 1, 2013 at 7:07 PM, Axel Müller <ax...@mueller-family.de> wrote:
> I created my OAM user and the connection with JOSM was validated ok. Before
> I try to upload this traffic circuit I created there is a question: As
> desribed above I copied als OSM nodes and ways that make up that aerodrome:
> border, buildings, taxiways, runways. So we will duplicate aerodroms from
> OSM to OAM.
> The aerodrome has the tag "aeroways=aerodrome". Morton - don't you think we
> could run a batch for this? Copy all ways with this tag including all child
> nodes/ways from OSM to OAM? This would make it easier since only the traffic
> circuits and tags would have to be added. Besides if no properly selected it
> easily happens that other nodes/ways not realy being children of the
> aerodrom are copied as well.

As Ákos said in another mail, maybe we should use the OurAirports data first?
It is a global database of airports and i almost think it's better than OSM.
Then you would only have to create the traffic circuits ;)

> I will add a detailed description including screenshots to the Wiki once i
> have completed the whole process a couple of times.

That would be great. I can help with hosting the screenshots if you'd
like. I don't think
the wiki has support for that right now.

> I assume that my OAM user is valid for the Wiki as well?

Alas, you will have to create a separate user for the wiki. It is
_really_ easy though.
It uses OAUTH so you can use your gmail and any other OAUTH provider as account.
Thus you don't have to create a new username or password, just use the
one you already have.

> I'm feeling that we're making progress ...

Me to! :D

--
Morten

[Axel Müller]

> As �kos said in another mail, maybe we should use the OurAirports data

> first? It is a global database of airports and i almost think it's
> better than OSM. Then you would only have to create the traffic
> circuits ;)

I downloaded airports.csv from them. It contains only a single
coordinate for each aerodrome (BTW: Whats the difference between an
aerodrome and an airfield, or should we call the airports regardless of
size? In German there is one word for smaller ones ("Flugplatz") and one
for the commercial ones ("Flughafen"). Once we start the Wiki we should
be consistent with wording ...
The line for the aerodrome I created the traffic circuit for looks like
this:

28700,"EDFB","small_airport","Reichelsheim
Airport",50.3358345031738,8.87805557250977,397,"EU","DE","DE-HE","Reichelsheim","no","EDFB",,,,,

I think that we should copy OSM data for all the ground facilities of
aerodromes. We can use data from ourairports.com to add airport
frequencies and navaids.
This would pose again the question about a batch import from OSM? Who
could/should handle this?

Axel

[Axel Müller]

> I created my OAM user and the connection with JOSM was validated ok.
> Before I try to upload this traffic circuit I created there is a
> question: As desribed above I copied als OSM nodes and ways that make
> up that aerodrome: border, buildings, taxiways, runways. So we will
> duplicate aerodroms from OSM to OAM.
> The aerodrome has the tag "aeroways=aerodrome". Morton - don't you
> think we could run a batch for this? Copy all ways with this tag
> including all child nodes/ways from OSM to OAM? This would make it
> easier since only the traffic circuits and tags would have to be
> added. Besides if no properly selected it easily happens that other
> nodes/ways not realy being children of the aerodrom are copied as well.
>

I forgot to mention: Besides importing the aerodromes we have to import
legal entities as well (if not already done): country, federal states.
Otherwise we won't be able to select aerodromes of a particular federal
state. I guess that the airspaces should have a relation to the country
too, so most likely you already created the Germany when you inserted
the airspaces yesterday?

Axel

[Ákos Maróy]

On 01/05/13 18:25, Axel Müller wrote:

I just returned from flying (paragliding - the wind was good today but no really enough thermals). But, there I met a guy responsible for ICAO charts at German Air Control (Deutsche Flugsicherung). I asked him if traffic circuits are available electronically somehow. He told me that (not only in Germany) traffic circuits are not made up by coordinates but simply drawn on a map, e.g. "right to that tower, south of this village, ...". There is no exact description of a traffic circuit! This means, that our approach to redraw the image is completely valid even if there is a small tolerance to the image since there is no exact data.
So we can go ahead ...

sort of. it is true that traffic circuits are not part of any AIP publication

in Hungary, there is definitive but not official registry of airports: http://www.hungaryairport.hu/airport.php

here they have plates for each airport, say this one: http://www.hungaryairport.hu/airport_data.php?id=41

which is done in cooperation with the airport, thus it includes the airports local preference for traffic circuits (elevation, corners, etc). maybe ultimately this is the best, if people at that particular airport can verify / confirm that this is how they fly there locally

[Ákos Maróy]

On 01/05/13 19:30, Axel M�ller wrote:
>> As �kos said in another mail, maybe we should use the OurAirports
>> data first? It is a global database of airports and i almost think
>> it's better than OSM. Then you would only have to create the traffic
>> circuits ;)
> I downloaded airports.csv from them. It contains only a single
> coordinate for each aerodrome

yes, that would only contain the ARP for the airport, and some metadata
- but not runway, taxiway, etc.

> (BTW: Whats the difference between an aerodrome and an airfield, or
> should we call the airports regardless of size? In German there is one
> word for smaller ones ("Flugplatz") and one for the commercial ones
> ("Flughafen"). Once we start the Wiki we should be consistent with
> wording ...

it seems aerodrome is the official ICAO term, which covers every kind of
laning opportunity. AIXM also uses aerodrome, as do the AIP publicationes

> The line for the aerodrome I created the traffic circuit for looks
> like this:
>
> 28700,"EDFB","small_airport","Reichelsheim
> Airport",50.3358345031738,8.87805557250977,397,"EU","DE","DE-HE","Reichelsheim","no","EDFB",,,,,
>
> I think that we should copy OSM data for all the ground facilities of
> aerodromes. We can use data from ourairports.com to add airport
> frequencies and navaids.
> This would pose again the question about a batch import from OSM? Who
> could/should handle this?

we could / should, and AIXM also has provisions for specifically mapping
taxiways, etc.

[Ákos Maróy]

yes, although this is where the OSM database schema tends to get
insufficient

you can go for OSM relations, but you actually can't query for relations
from GeoServer's rendering description language, SLD

maybe the easiest is to query by ICAO code prefix for airports, as they
are definitive of a region (say, Hungarian airports start with LH,
Germans with ED, etc.)

[Axel Müller]

>> I forgot to mention: Besides importing the aerodromes we have to
>> import legal entities as well (if not already done): country, federal
>> states. Otherwise we won't be able to select aerodromes of a
>> particular federal state. I guess that the airspaces should have a
>> relation to the country too, so most likely you already created the
>> Germany when you inserted the airspaces yesterday?
> yes, although this is where the OSM database schema tends to get
> insufficient
>
> you can go for OSM relations, but you actually can't query for relations
> from GeoServer's rendering description language, SLD
>
> maybe the easiest is to query by ICAO code prefix for airports, as they
> are definitive of a region (say, Hungarian airports start with LH,
> Germans with ED, etc.)

But you cannot query for federal state then. I can't believe that the
query language is not sufficient for this. Maybe I will ask in the the
OSM forum ...

I uploaded Reichelsheim aerodrome including 3 traffic circuits to OAM -
basically for testing. Console says:

loading plugin 'PicLayer' (version 29435)
Open file:
/data/projects/avanux/androflight/platzrunden/reichelsheim.xml (10699 bytes)
PUT http://osm.openaviationmap.org/api/0.6/changeset/create... OK
POST http://osm.openaviationmap.org/api/0.6/changeset/260/upload... OK
PUT http://osm.openaviationmap.org/api/0.6/changeset/260/close... OK

If I download the area I get everything I uploaded - seems to work well.
No tags added yet. Also the runway belongs to the way of one of the
traffic circuits which is probably not good. I have to split it.
The aerodrome tags used by OSM we should use in the same way also having
the same name. Both - OAM and OSM tags used will have to go to the Wiki.
Hopefully I'll find some time at the weekend.

Do we have some statistic page where we can monitor the change sets
committed?

Axel

[Morten Olsen Lysgaard]

On Thu, May 2, 2013 at 9:39 PM, Axel Müller <ax...@mueller-family.de> wrote:
> If I download the area I get everything I uploaded - seems to work well.
> No tags added yet. Also the runway belongs to the way of one of the traffic circuits which is probably not good. I have to split it.
> The aerodrome tags used by OSM we should use in the same way also having the same name. Both - OAM and OSM tags used will have
> to go to the Wiki. Hopefully I'll find some time at the weekend.

Sounds good.

> Do we have some statistic page where we can monitor the change sets
> committed?

You can go to http://osm.openaviationmap.org/
Zoom into the area you're interested in and press the
"history" tab ;)

[Axel Müller]

Hi Morton,

>> I assume that my OAM user is valid for the Wiki as well?
> Alas, you will have to create a separate user for the wiki. It is
> _really_ easy though.
> It uses OAUTH so you can use your gmail and any other OAUTH provider as account.
> Thus you don't have to create a new username or password, just use the
> one you already have.
>

Yes, login was no problem. However, it looks like a very "basic" wiki.
Do you have a particular reason for choosing ikiwiki? I would prefer to
use MediaWiki like OSM does because we can use their syntax/styles and
people (inlcuding myself :-) ) rather know MediaWiki than ikiwiki.
OSM also stores their images inside the Wiki which I would prefer as
well rather than having them hosted somewhere.
One more thing I'm missing in both wikis: I'm running Redmine which
includes a wiki as well. There I can resize the editing window by mouse.
I kind of hate small editor windows because you don't have an overview
of the document structure ;-)

Axel

[Axel Müller]

Yes, login was no problem. However, it looks like a very "basic" wiki. Do you have a particular reason for choosing ikiwiki? I would prefer to use MediaWiki like OSM does because we can use their syntax/styles and people (inlcuding myself :-) ) rather know MediaWiki than ikiwiki.
OSM also stores their images inside the Wiki which I would prefer as well rather than having them hosted somewhere.
One more thing I'm missing in both wikis: I'm running Redmine which includes a wiki as well. There I can resize the editing window by mouse. I kind of hate small editor windows because you don't have an overview of the document structure ;-)

I started converting part of the OSM wiki structure to OAM wiki. I don't know yet whether you agree with me that we should use MediaWiki but nevertheless create a temporary Wiki page on a free Mediawiki:

http://wikieducator.org/User:Openaviationmap

I'm testing things there until we hopefully have a Mediawiki as well :-) It will save us a lot of work if we can copy+adapt things from OSM.

BTW: We really need a logo whose layout should express relation to OSM but of course should indicate the focus on aviation! Anyone feeling creative today? I'm not the right one for this kind of job ...

Axel

[Axel Müller]

 

I started converting part of the OSM wiki structure to OAM wiki. I don't know yet whether you agree with me that we should use MediaWiki but nevertheless create a temporary Wiki page on a free Mediawiki:

http://wikieducator.org/User:Openaviationmap

I'm testing things there until we hopefully have a Mediawiki as well :-) It will save us a lot of work if we can copy+adapt things from OSM.

I have to save my work locally as well - there is a bot cleaning up content containing external links, but it would be too much work to remove external links and re-add them later on.
If you don't see anything there then this is the reason. Perhaps the bot runs only once a day but I don't know ...

Axel

[Morten Olsen Lysgaard]

If you could use a full MediaWiki I will set up that. It will take
some days maybe before it's opperational.
MediaWiki has a big problem of being used by spam bots. Thus good
protection is very important,
or else we'll just have a wiki of spam.

> --
> You received this message because you are subscribed to the Google Groups
> "openaviationmap" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to openaviationm...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Axel Müller]

Hi Morton,

> If you could use a full MediaWiki I will set up that.

That would be great :-)

> It will take some days maybe before it's opperational.

No problem.

> MediaWiki has a big problem of being used by spam bots. Thus good protection is very important, or else we'll just have a wiki of spam.

There are many "famous" sites using Mediawiki - most of all Wikipedia
itself. I'm sure there are means to prevent spam. For some time we could
also disallow self-registration if required.

Axel

[Ákos Maróy]

On 04/05/13 08:01, Axel Müller wrote:

Yes, login was no problem. However, it looks like a very "basic" wiki. Do you have a particular reason for choosing ikiwiki? I would prefer to use MediaWiki like OSM does because we can use their syntax/styles and people (inlcuding myself :-) ) rather know MediaWiki than ikiwiki.
OSM also stores their images inside the Wiki which I would prefer as well rather than having them hosted somewhere.
One more thing I'm missing in both wikis: I'm running Redmine which includes a wiki as well. There I can resize the editing window by mouse. I kind of hate small editor windows because you don't have an overview of the document structure ;-)

I started converting part of the OSM wiki structure to OAM wiki. I don't know yet whether you agree with me that we should use MediaWiki but nevertheless create a temporary Wiki page on a free Mediawiki:

http://wikieducator.org/User:Openaviationmap

great!

I'm testing things there until we hopefully have a Mediawiki as well :-) It will save us a lot of work if we can copy+adapt things from OSM.

BTW: We really need a logo whose layout should express relation to OSM but of course should indicate the focus on aviation! Anyone feeling creative today? I'm not the right one for this kind of job ...

me neither :( for the android app, I simply used the map sign of a VOR: https://play.google.com/store/apps/details?id=com.euedge.openaviationmap.android

[Ákos Maróy]

shouldn't we relocate this wiki into a local instance on our own server?

[Ákos Maróy]

On 04/05/13 10:43, Morten Olsen Lysgaard wrote:
> If you could use a full MediaWiki I will set up that. It will take
> some days maybe before it's opperational.
> MediaWiki has a big problem of being used by spam bots. Thus good
> protection is very important,
> or else we'll just have a wiki of spam.
>

yes, acutally whenever I ran MedaWiki, it was always overrun by spam :(

[Axel Müller]

> shouldn't we relocate this wiki into a local instance on our own server?

As soon as Morten has MediaWiki ready :-) Until now I have only two
pages and I save them locally as well. But the switch to MediaWiki will
be worth the hassle since there are already a lot of templates (news,
calender, tags, ...) we can almost copy, adapt content a little and
that's it.

Axel

[Ákos Maróy]

cool :)

[Axel Müller]

Yes, login was no problem. However, it looks like a very "basic" wiki. Do you have a particular reason for choosing ikiwiki? I would prefer to use MediaWiki like OSM does because we can use their syntax/styles and people (inlcuding myself :-) ) rather know MediaWiki than ikiwiki.
OSM also stores their images inside the Wiki which I would prefer as well rather than having them hosted somewhere.
One more thing I'm missing in both wikis: I'm running Redmine which includes a wiki as well. There I can resize the editing window by mouse. I kind of hate small editor windows because you don't have an overview of the document structure ;-)

I started converting part of the OSM wiki structure to OAM wiki. I don't know yet whether you agree with me that we should use MediaWiki but nevertheless create a temporary Wiki page on a free Mediawiki:

http://wikieducator.org/User:Openaviationmap

I have created 4 pages so far: the main page, the map features page which uses the templates Map_Features:aeroway (copied from OSM) and Map_Features:traffic-circuit created by myself.
I added some graphics extracted from VFR maps and beautified little. Traffic circuit tag name schema was inspired by the way airspace tag names are used. If you approve the tag names I will apply them to the data I already uploaded.

BTW: I was surprised that you used "height" instead of "altitude" for airspace tags. AFAIK hight is used to express distance to surface whereas altitude references MSL (and the difference is elevation). Am I wrong? Are you sure that "height" is the correct term with respect to airspaces? Using the correct terms from the beginning is very important :-)

Axel

[Ákos Maróy]

On 04/05/13 15:28, Axel Müller wrote:

I have created 4 pages so far: the main page, the map features page which uses the templates Map_Features:aeroway (copied from OSM) and Map_Features:traffic-circuit created by myself.
I added some graphics extracted from VFR maps and beautified little. Traffic circuit tag name schema was inspired by the way airspace tag names are used. If you approve the tag names I will apply them to the data I already uploaded.

great!

BTW: I was surprised that you used "height" instead of "altitude" for airspace tags. AFAIK hight is used to express distance to surface whereas altitude references MSL (and the difference is elevation). Am I wrong? Are you sure that "height" is the correct term with respect to airspaces? Using the correct terms from the beginning is very important :-)

good point

I guess we took over height from OSM, and just stuck with it...

it's a good idea to change it eventually

[Ákos Maróy]

On 04/05/13 15:28, Axel Müller wrote:

BTW: I was surprised that you used "height" instead of "altitude" for airspace tags. AFAIK hight is used to express distance to surface whereas altitude references MSL (and the difference is elevation). Am I wrong? Are you sure that "height" is the correct term with respect to airspaces? Using the correct terms from the beginning is very important :-)

but, actually, we're using an point of reference part as well, as elevation / height (vertical positions) is sometimes referenced from AMSL, sometimes from AGL / sufrace

[Axel Müller]

Akos,

BTW: I was surprised that you used "height" instead of "altitude" for airspace tags. AFAIK hight is used to express distance to surface whereas altitude references MSL (and the difference is elevation). Am I wrong? Are you sure that "height" is the correct term with respect to airspaces? Using the correct terms from the beginning is very important :-)

but, actually, we're using an point of reference part as well, as elevation / height (vertical positions) is sometimes referenced from AMSL, sometimes from AGL / sufrace

I know that airspaces can be AGL and MSL. I had a look at the official ICAO map of Frankfurt area published 8 weeks ago: It mentions: "Altitude and position of traffic pattern".

1. We should use "altitude" rather than "height". This means you should adapt the import tools (e.g. replace "height:lower" with "altitude:lower") for airspaces and re-import data.
2. They call "traffic pattern" (Google results: 959.000) what I called "traffic circuit" (Google results: 47.000). Although I prefer the latter it looks like we should go for the first.

BTW: The map heading is "aerodromes" - so you were right about this term.

Axel

[Ákos Maróy]

On 04/05/13 17:59, Axel Müller wrote:

I know that airspaces can be AGL and MSL. I had a look at the official ICAO map of Frankfurt area published 8 weeks ago: It mentions: "Altitude and position of traffic pattern".

1. We should use "altitude" rather than "height". This means you should adapt the import tools (e.g. replace "height:lower" with "altitude:lower") for airspaces and re-import data.

fair enough. most probably it's simplest to actually do a mass update / replace. but before doing this, the rendering rules have to be updated in the same go

2. They call "traffic pattern" (Google results: 959.000) what I called "traffic circuit" (Google results: 47.000). Although I prefer the latter it looks like we should go for the first.

yes, it's 'traffic pattern' in English, altough in a lot of languages it's called a 'circuit'. in Hungarian they actually call it the 'school circuit' ("iskolakör"), as this is what you learn first when you're training in flight school

BTW: The map heading is "aerodromes" - so you were right about this term.

:)

[Axel Müller]

> BTW: We really need a logo whose layout should express relation to OSM
> but of course should indicate the focus on aviation! Anyone feeling
> creative today? I'm not the right one for this kind of job ...

This morning somehow I had an idea of how the logo could look like.
While I was waiting for my application server to start up I search for
some kind of clipart. Not much else had to be done. What do you think
about this logo?

Axel

[Ákos Maróy]

I'd say heavily influenced by OSM :)

[Ákos Maróy]

On 02/05/13 21:39, Axel M�ller wrote:
>
>>> I forgot to mention: Besides importing the aerodromes we have to
>>> import legal entities as well (if not already done): country, federal
>>> states. Otherwise we won't be able to select aerodromes of a
>>> particular federal state. I guess that the airspaces should have a
>>> relation to the country too, so most likely you already created the
>>> Germany when you inserted the airspaces yesterday?
>> yes, although this is where the OSM database schema tends to get
>> insufficient
>>
>> you can go for OSM relations, but you actually can't query for relations
>> from GeoServer's rendering description language, SLD
>>
>> maybe the easiest is to query by ICAO code prefix for airports, as they
>> are definitive of a region (say, Hungarian airports start with LH,
>> Germans with ED, etc.)
> But you cannot query for federal state then. I can't believe that the
> query language is not sufficient for this. Maybe I will ask in the the
> OSM forum ...

please do

from what I saw in SLD, the only way to work with OSM 'relations' is to
create a view on the tables which join the osm_node / osm_polygon style
tables to osm_relation.

another way to do this is to add an attribute to each feature denoting
the federal state.

but this is why I got to the conclusion that the OSM data schema is
insufficient for us.

>
> I uploaded Reichelsheim aerodrome including 3 traffic circuits to OAM
> - basically for testing. Console says:
>
> loading plugin 'PicLayer' (version 29435)
> Open file:
> /data/projects/avanux/androflight/platzrunden/reichelsheim.xml (10699
> bytes)
> PUT http://osm.openaviationmap.org/api/0.6/changeset/create... OK
> POST http://osm.openaviationmap.org/api/0.6/changeset/260/upload... OK
> PUT http://osm.openaviationmap.org/api/0.6/changeset/260/close... OK
>
> If I download the area I get everything I uploaded - seems to work well.
> No tags added yet. Also the runway belongs to the way of one of the
> traffic circuits which is probably not good. I have to split it.
> The aerodrome tags used by OSM we should use in the same way also
> having the same name. Both - OAM and OSM tags used will have to go to
> the Wiki. Hopefully I'll find some time at the weekend.
>
> Do we have some statistic page where we can monitor the change sets
> committed?

I'm not sure.

also, maybe we should have an automated mechanism to update the database
on the production rendering server with this one? than you could see the
results rendered.

what I did was I had a local instance of GeoTools running, and was
double-checking with that.

[Axel Müller]

That was my intention: If people know OSM they won't be afraid of OAM.
Whenever I talk to people about OSM I find that it has a good
reputation. We could benefit from that reputation. Once we have Homepage
and Wiki up-to-date we can also get listed at OSM as "sister project" -
they have a section in their wiki for them.

Axel

[Ákos Maróy]

yes, that's true.

OTOH, I think inevitably we'll deviate from the OSM software stack and
then 'usual' OSM people might be bewildered that this is a somewhat
different world.

well of course until this happens, I agree we could use the likelyness
to our benefit.

[Morten Olsen Lysgaard]

I actually have some quite defined opinions on a logo. First, I think
it should contain a minimal amount of detail, because
we want to scale the logo from 16x16 favicons to 200x200 main logos in
headers. I think it should contain
a minimal colour palette. This is because we want it to appear good in
both black and white and color.
I'd would like some sort of vector graphics, that symbolizes
navigation and aviation. Not necessarily
maps specifically but the more general term navigation.
If you take a look at how big and well known brands do their logos
you'll see that they all are very simple.

My brother is an artist. I could as him for some suggestions. He's
done several jobs when it comes to branding.

I have to say that although I like your preposition Alex I think it has
to many details, to many colors
and to little contrast to work at small scales.

[Axel Müller]

> I actually have some quite defined opinions on a logo. First, I think
> it should contain a minimal amount of detail, because
> we want to scale the logo from 16x16 favicons to 200x200 main logos in
> headers. I think it should contain
> a minimal colour palette. This is because we want it to appear good in
> both black and white and color.
> I'd would like some sort of vector graphics, that symbolizes
> navigation and aviation. Not necessarily
> maps specifically but the more general term navigation.
> If you take a look at how big and well known brands do their logos
> you'll see that they all are very simple.

Navigation and aviation - that's what I tried to express with my
proposal :-)

> My brother is an artist. I could as him for some suggestions. He's
> done several jobs when it comes to branding.

Great - I'm curious what he will come up with ...

> I have to say that although I like your preposition Alex I think it has
> to many details, to many colors
> and to little contrast to work at small scales.

No problem - it was just a quick thing. I did not change a single color
- just two graphics overlayed.
Although I have to admit that I like the perspective of the aircraft
coming out of the magnifying glass :-)

Axel

[Ákos Maróy]

On 07/05/13 20:42, Axel M�ller wrote:
>
>> My brother is an artist. I could as him for some suggestions. He's
>> done several jobs when it comes to branding.
> Great - I'm curious what he will come up with ...

me too.

lets see multiple options, and then chose with an open mind

[Axel Müller]

I forgot to mention: Besides importing the aerodromes we have to
import legal entities as well (if not already done): country, federal
states. Otherwise we won't be able to select aerodromes of a
particular federal state. I guess that the airspaces should have a
relation to the country too, so most likely you already created the
Germany when you inserted the airspaces yesterday?

yes, although this is where the OSM database schema tends to get
insufficient

you can go for OSM relations, but you actually can't query for relations
from GeoServer's rendering description language, SLD

maybe the easiest is to query by ICAO code prefix for airports, as they
are definitive of a region (say, Hungarian airports start with LH,
Germans with ED, etc.)

But you cannot query for federal state then. I can't believe that the
query language is not sufficient for this. Maybe I will ask in the the
OSM forum ...

please do

from what I saw in SLD, the only way to work with OSM 'relations' is to
create a view on the tables which join the osm_node / osm_polygon style
tables to osm_relation.

Looks like the Overpass API is exactly what I'm looking for:
http://wiki.openstreetmap.org/wiki/Overpass_API

Maybe I have a look at this over the weekend in order to import aerodromes from OSM.
I didn't have a detailed look at the code you used to import data for Hungary but I assume that you extracted the data somewhere and sent it to the OAM API for insertion, right?

Axel

[Ákos Maróy]

On 10/05/13 08:41, Axel Müller wrote:

Looks like the Overpass API is exactly what I'm looking for:
http://wiki.openstreetmap.org/wiki/Overpass_API

I don't immediately see how this would help - but I hope you do :)

for all ends and purposes, I'd suggest going through the whole rendering chain, including rendering from a PostGIS database with GeoServer. this might bring more insight into what the rendering process is capable (and incapable) of. for details, see here: https://code.google.com/p/openaviationmap/wiki/HowToInstallServer

as said, although I see your experience & enthusiasm with the OSM toolchain, having worked through this I'm quite convinced that it is not sufficient for us.

Maybe I have a look at this over the weekend in order to import aerodromes from OSM.
I didn't have a detailed look at the code you used to import data for Hungary but I assume that you extracted the data somewhere and sent it to the OAM API for insertion, right?

for Hungary: I used the XML version of the Hungarian eAIP to parse & import the data. look here: https://code.google.com/p/openaviationmap/wiki/CompileJavaTools
and here: https://code.google.com/p/openaviationmap/wiki/OamConverter

the same OamConverter can be used to import OurAirports data and convert it to OSM-based OAM data.

it can also produce KML to be viewed in Google Earth - which would be a nice generic export format too.

[Axel Müller]

Looks like the Overpass API is exactly what I'm looking for:
http://wiki.openstreetmap.org/wiki/Overpass_API

Maybe I have a look at this over the weekend in order to import aerodromes from OSM.

The "reference" aerodrome EDFB for which I already added the traffic pattern into OAM had an ARP node containing tags like icao, comm, height. Within the last 5 days this node is gone in OSM :-(
I had to give up to find out the reason because the area of this little aerodrome was affected by 140 (!) change sets within these 5 days. Some of those changes sets affected huge areas like whole of Europe or even bigger.

In my opinion the bottom line is: We cannot rely on OSM for "invisible" things (e.g. icao, comm, height) - those things which OSM doesn't want to have in its database anyway.
This would leave the possibility to copy from OSM:

- the closed way representing the area of the aerodrome (identified by aeroway=aerodrome)
- the buildings (identified by aeroway=terminal or aeroway=hangar)
- the taxi ways (identified by aeroway=taxiway)
- the runways (identified by aeroway=runway)

The ARP along with things like icao, comm, height has to come from a different source. For Hungary you have solved this. For Germany this will probably be "airports.de".
However I currently don't see a possibility to link the ARP to the data imported from OSM since the we cannot rely on the existence of an icao tag in OSM data. We would have to need to find out, if the ARP is located within a bounding box covering an aerodrome. In this case we could add the aerodrome facilities imported from OSM into the relationship of the aerodrome.

Why do I take care about runways etc? Traffic patterns form a box out of a runway. No runwar - no traffic pattern ...


BTW: Here is the area of EDFB selected by Overpass API (press "Data" tab on the top right of the browser window):

http://overpass-turbo.eu/s/9d


Axel

[Ákos Maróy]

On 11/05/13 08:40, Axel Müller wrote:

Looks like the Overpass API is exactly what I'm looking for:
http://wiki.openstreetmap.org/wiki/Overpass_API

Maybe I have a look at this over the weekend in order to import aerodromes from OSM.

The "reference" aerodrome EDFB for which I already added the traffic pattern into OAM had an ARP node containing tags like icao, comm, height. Within the last 5 days this node is gone in OSM :-(
I had to give up to find out the reason because the area of this little aerodrome was affected by 140 (!) change sets within these 5 days. Some of those changes sets affected huge areas like whole of Europe or even bigger.

In my opinion the bottom line is: We cannot rely on OSM for "invisible" things (e.g. icao, comm, height) - those things which OSM doesn't want to have in its database anyway.

yes, this is why we have to maintain our own database

This would leave the possibility to copy from OSM:

- the closed way representing the area of the aerodrome (identified by aeroway=aerodrome)
- the buildings (identified by aeroway=terminal or aeroway=hangar)
- the taxi ways (identified by aeroway=taxiway)
- the runways (identified by aeroway=runway)

The ARP along with things like icao, comm, height has to come from a different source. For Hungary you have solved this. For Germany this will probably be "airports.de".
However I currently don't see a possibility to link the ARP to the data imported from OSM since the we cannot rely on the existence of an icao tag in OSM data. We would have to need to find out, if the ARP is located within a bounding box covering an aerodrome. In this case we could add the aerodrome facilities imported from OSM into the relationship of the aerodrome.

I don't think this process can be automated

Why do I take care about runways etc? Traffic patterns form a box out of a runway. No runwar - no traffic pattern ...


BTW: Here is the area of EDFB selected by Overpass API (press "Data" tab on the top right of the browser window):

http://overpass-turbo.eu/s/9d

hm, what's the use of the wheelchair flag? :)

[Axel Müller]

>> The ARP along with things like icao, comm, height has to come from a
>> different source. For Hungary you have solved this. For Germany this
>> will probably be "airports.de".
>> However I currently don't see a possibility to link the ARP to the
>> data imported from OSM since the we cannot rely on the existence of
>> an icao tag in OSM data. We would have to need to find out, if the
>> ARP is located within a bounding box covering an aerodrome. In this
>> case we could add the aerodrome facilities imported from OSM into the
>> relationship of the aerodrome.
> I don't think this process can be automated

Why not? I'm doing the same in my app in order to render only airspaces
depending on the map shown. During import of OpenAir files I wrap every
airspace by a bounding box which is imported in the database as well.
The SQL selecting the airspaces to be rendered only operates on the
bounding box coordinates.

Axel

[Ákos Maróy]

cool - it's great if it works :)

[Axel Müller]

> The ARP along with things like icao, comm, height has to come from a
> different source. For Hungary you have solved this. For Germany this
> will probably be "airports.de". However I currently don't see a
> possibility to link the ARP to the data imported from OSM since the we
> cannot rely on the existence of an icao tag in OSM data. We would have
> to need to find out, if the ARP is located within a bounding box
> covering an aerodrome. In this case we could add the aerodrome
> facilities imported from OSM into the relationship of the aerodrome.

As I already wrote I intend to import aerodrome boundaries and runways
from OSM to OAM for Germany (at first).
Yesterday I realized that aerodromes like EDFB are not part of any
relation. This means I cannot restrict the result set to aerodromes of a
country via relationship of a superior node/way with tag admin_level=2.
I don't know why but I had the wrong assumption that every node/way
belongs to a superior entity and in the end also to a country. I should
have known that this is not the case since I did not add this kind of
relationship when I used to map for OSM.

Query aerodromes via bounding box is not an options since this would
include aerodromes of neighboring countries as well if they are close to
the border. However, the Overpass API also supports the use of a polygon
rather than a bounding box for selection. I retrieved the way and all of
its nodes representing the border of Germany (relation id is 51477 I
looked up in JOSM):

wget -O de_rel.osm
"http://api.openstreetmap.org/api/0.6/relation/51477/full"

I used rel2poly.pl to create a polygone from this relation. To request
all ways representing aerodromes the Overpass QL looks like:

(way
["aeroway"="aerodrome"]
(poly:"5.002473E+01 1.236233E+01 5.002473E+01 1.236233E+01 5.002482E+01
1.236209E+01 5.002485E+01 1.236199E+01 ...);
);
(._;>;);
out;

The request is almost 3 MB in size. I run it like this:

wget -O de_aerodrome.osm --post-file=de_aerodrome.ql
http://overpass-api.de/api/interpreter

The resulting file is about 1 MB and contains the ways/nodes
representing the boundaries of 470 aerodromes.
I did the same request with ["aeroway"="runway"] to retrieve the runways
of the aerodromes (the resulting file is about 500K).

What's is the easiest way to get this data into OAM database? I cannot
load the files into JOSM ...
The aerodrome file begins like this:

<?xml version="1.0" encoding="UTF-8"?>
<osm version="0.6" generator="Overpass API">
<note>The data included in this document is from www.openstreetmap.org.
The data is made available under ODbL.</note>
<meta osm_base="2013-05-12T08:06:04Z"/>

<node id="192162" lat="49.8521663" lon="8.5857806">
<tag k="barrier" v="gate"/>
</node>
<node id="438515" lat="49.8566951" lon="8.5912821"/>
<node id="20979353" lat="49.4716383" lon="8.5212935"/>
<node id="20979354" lat="49.4719739" lon="8.5074859"/>
<node id="24965967" lat="53.9121336" lon="10.0402750"/>


Axel

[Axel Müller]

>
> What's is the easiest way to get this data into OAM database? I cannot
> load the files into JOSM ...
> The aerodrome file begins like this:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <osm version="0.6" generator="Overpass API">
> <note>The data included in this document is from
> www.openstreetmap.org. The data is made available under ODbL.</note>
> <meta osm_base="2013-05-12T08:06:04Z"/>
>
> <node id="192162" lat="49.8521663" lon="8.5857806">
> <tag k="barrier" v="gate"/>
> </node>
> <node id="438515" lat="49.8566951" lon="8.5912821"/>
> <node id="20979353" lat="49.4716383" lon="8.5212935"/>
> <node id="20979354" lat="49.4719739" lon="8.5074859"/>
> <node id="24965967" lat="53.9121336" lon="10.0402750"/>
>

JOSM was complaining about the "version" attribute missing on nodes and
ways. I will add this attribute to all nodes/ways. A little test showed,
that I can load the file into JOSM once the attribute is there ...

Axel

[Axel Müller]

After this XSL transformation I was able to load all aerodromes of
Germany into JOSM. Looks nice at the attached screenshot.

I guess I could upload this to OAM, right? This import would include all
tags currently existing on aerodrome boundaries and runways. We won't
probably use these tags since we have tags of better quality at the ARP
nodes which we don't import from OSM. What is your opinion - should I
import the data described?

I would do the same with all runways afterwards.

Next step would be to have a look at the import tools created by you and
find out how to retrieve data from airports.de in order to add ARPs with
proper tags to OAM.

Axel

[Ákos Maróy]

On 12/05/13 12:10, Axel M�ller wrote:
> After this XSL transformation I was able to load all aerodromes of
> Germany into JOSM. Looks nice at the attached screenshot.

great - congrats!

>
> I guess I could upload this to OAM, right? This import would include
> all tags currently existing on aerodrome boundaries and runways. We
> won't probably use these tags since we have tags of better quality at
> the ARP nodes which we don't import from OSM. What is your opinion -
> should I import the data described?

yes, you should!

>
> I would do the same with all runways afterwards.
>
> Next step would be to have a look at the import tools created by you
> and find out how to retrieve data from airports.de in order to add
> ARPs with proper tags to OAM.

yes, and also we should import data from OurAirports as well...

[Axel Müller]

Looks like I'm learning a bit more about the OSM toolchain:

I wasn't able to upload the OSM file using JOSM since it always complained "no changes to upload".
Somehow I realized that I need a changeset and found osmconvert ( http://wiki.openstreetmap.org/wiki/Osmconvert) which can convert between various OSM formats including OSM->OSC:

osmconvert32 de_aerodrome_version.osm -o=de_aerodrome_version.osc

The file created starts with:

<?xml version='1.0' encoding='UTF-8'?>

<osmChange version="0.6" generator="osmconvert 0.7Q">
<create>
        <node id="192162" lat="49.8521663" lon="8.5857806" version="1">

                <tag k="barrier" v="gate"/>
        </node>

        <node id="438515" lat="49.8566951" lon="8.5912821" version="1"/>
        <node id="20979353" lat="49.4716383" lon="8.5212935" version="1"/>
[...]

Although JOSM is able to load the OSC file it still complains about "no changes to upload".

In OSM wiki I found http://wiki.openstreetmap.org/wiki/Upload.py which can upload OSC files. I modified the script to use the OAM url rather than OSM url.

axel@miraculix:/data/projects/avanux/openaviationmap/overpass/bulkupload$ python upload-python2.py -u <myuser> -p <mypassword> -c yes -m "import of ways having aeroway=aerodrome for Germany" ../de_aerodrome_version.osc
     File: '../de_aerodrome_version.osc'
  Comment: import of ways having aeroway=aerodrome for Germany

I'm creating the changeset… done. Id: 266         
Now I'm sending changes… waiting for status    
412: Precondition Failed (Precondition failed: Way  requires the nodes with id in (25413640,25413641,25413642,25413643,25413644,25413645,25413646,25413648,25413649,25413653,25413654,25413655,25413656,25413658,25413659,25413660,25413661,25413662,25413663,25413664,25413665,25413666,25413668,25413669,25413670,25413671,25413672,25413673,25413674,25413675,25413676,25413677,25413678,25413679,25413680,25413681,25413682,25413684,25413685,25413687,25413688,25413689,25413690,25413691,25413692,25413693,25413694,25413695,25413696,25413697,25413698,25413699,25413700,91891183,91891187,91891191,91891195,91891206,91891211,91891225,91891229,91891288,91891294,91891298,91891305,91891312,272720485,272720486,272722923,276861389,415006930,416116513,416116518,428559856,658612083,664902127,1308270656,1308270687,1425782363,1425782365,1425782394,1426032195,1426032214,1426032216,1426032219,1426032224,1440288197,1440288224,1440288226,1440288233,1440288237,1440288242,1440288244,1440288246,1440329918,1440330018,1440330021,1440330041,1440330058,1440330064,1440330079,1440330089,1 440330090 ,1440330092,1440330093,1440330166,1440330170,1440330194,1440330222,1440330226,1440330234,1593186445,1593232496,1593326663,1593326665,1593353993,1593354016), which either do not exist, or are not visible.)
Closing… done, too.            
axel@miraculix:/data/projects/avanux/openaviationmap/overpass/bulkupload

After doing some testing I located the source of trouble: The IDs (of nodes and ways) change during creation. First the nodes are created. When ways are created IDs referenced are no longer existing. I found some posting indicating the (ugly) solution: IDs should be prefixed by "-" (make the number negative) in order to force generation of new IDs during upload.
In order to do the prefixing I run an XSL transformation:

axel@miraculix:~/projects/avanux/openaviationmap/overpass$ cat de_runway.osc | xalan -xsl make_negative_ids.xsl > de_runway_negative.osc

It also replaces the root element "modify" by "create" since osmconvert sometimes created "modify" (I don't know the reason ...).
Finally I was able to upload the aerodromes and runways:

axel@miraculix:/data/projects/avanux/openaviationmap/overpass/bulkupload$ python upload-python2.py -u <myuser> -p <mypassword> -c yes -m "import of ways having aeroway=aerodrome for Germany" ../de_aerodrome_negative.osc
     File: '../de_aerodrome_negative.osc'
  Comment: import of ways having aeroway=aerodrome for Germany

I'm creating the changeset… done. Id: 291         
Now I'm sending changes… done.                 
Closing… done, too.            
axel@miraculix:/data/projects/avanux/openaviationmap/overpass/bulkupload$ python upload-python2.py -u <myuser> -p <mypassword> -c yes -m "import of ways having aeroway=aerodrome for Germany" ../de_runway_negative.osc
     File: '../de_runway_negative.osc'
  Comment: import of ways having aeroway=aerodrome for Germany

I'm creating the changeset… done. Id: 292         
Now I'm sending changes… done.                 
Closing… done, too.

I will add documentation about import to the Wiki ...

I noted that at least 18 model aerodromes were also selected. It identified them by looking for "model". I thought about filtering but while it may work for those german oder english values containing "model" it won't work for other languages or if the value simply contains the name of their club. Do you see a way to filter them?

Almost the whole day spent on this stuff, but it was raining anyway.
Current status for Germany is: All airports, all runways, all airspaces (done by you) and traffic pattern for 2 aerodromes (not tagged yet) have been imported.

Axel

[Ákos Maróy]

On 12/05/13 19:33, Axel Müller wrote:

Almost the whole day spent on this stuff, but it was raining anyway.
Current status for Germany is: All airports, all runways, all airspaces (done by you) and traffic pattern for 2 aerodromes (not tagged yet) have been imported.

great - congratulations!

Morten, would you want to replicate the database so that we'd see the results of this?

[Morten Olsen Lysgaard]

I've created a script to do the update of the geoserver rendering database.
I ran it and everything seemed to work. I even could watch new airspaces in
geoserver, but they don't seem to pop up on the full map that we use on the
index page. Maybe I've done something wrong. I remembered to delete the
tile cache, is there something else I also have to do?

[Ákos Maróy]

On 13/05/13 12:37, Morten Olsen Lysgaard wrote:
> I've created a script to do the update of the geoserver rendering database.
> I ran it and everything seemed to work. I even could watch new airspaces in
> geoserver, but they don't seem to pop up on the full map that we use on the
> index page. Maybe I've done something wrong. I remembered to delete the
> tile cache, is there something else I also have to do?
>

depends - which tiled cache did you delete?

there are tile layers, in particular the OAM:oam layer, that is the one
you should delete...

[Morten Olsen Lysgaard]

I deleted that layer and there's still nothing showing up. None of the
german airspaces show.
I can find them in the database so it looks like the SLDs don't trigger on them?

[Ákos Maróy]

On 13/05/13 14:06, Morten Olsen Lysgaard wrote:
> I deleted that layer and there's still nothing showing up. None of the
> german airspaces show.
> I can find them in the database so it looks like the SLDs don't trigger on them?
>

that might be the case

for best results, try to access the layers directly (not through the
cache), maybe through the preview option (or directly with an
alternative JavaScript setting for leaflet)

can you show a sample airspace db entry, to see what tags it is using?

[Morten Olsen Lysgaard]

Is airspace:type required for an airspace to render par example?

[Ákos Maróy]

On 13/05/13 14:11, Morten Olsen Lysgaard wrote:

Is airspace:type required for an airspace to render par example?

look here:

https://code.google.com/p/openaviationmap/source/browse/trunk/rendering/oam_airspaces.sldt

for example for prohibited airspaces:

<ogc:Filter>

<ogc:And>

<ogc:PropertyIsEqualTo>

<ogc:PropertyName>airspace</ogc:PropertyName>

<ogc:Literal>yes</ogc:Literal>

</ogc:PropertyIsEqualTo>

<ogc:Or>

<ogc:PropertyIsEqualTo>

<ogc:Function name="isNull">

<ogc:PropertyName>compound</ogc:PropertyName>

</ogc:Function>

<ogc:Literal>true</ogc:Literal>

</ogc:PropertyIsEqualTo>

<ogc:PropertyIsNotEqualTo>

<ogc:PropertyName>compound</ogc:PropertyName>

<ogc:Literal>original</ogc:Literal>

</ogc:PropertyIsNotEqualTo>

</ogc:Or>

<ogc:PropertyIsEqualTo>

<ogc:PropertyName>airspace_type</ogc:PropertyName>

<ogc:Literal>P</ogc:Literal>

</ogc:PropertyIsEqualTo>

</ogc:And>

</ogc:Filter>

thus you need

airspace='yes' && (compound is null || compound='original') && airspace_type='P'

and so forth

[Morten Olsen Lysgaard]

Do you have a list of the different types that the SLD support?
I'm used to TMA, CTR etc. What else exists?

--

[Morten Olsen Lysgaard]

Also, how did you generate these SLDs? Not by hand I guess?

[Ákos Maróy]

On 13/05/13 15:43, Morten Olsen Lysgaard wrote:
> Do you have a list of the different types that the SLD support?
> I'm used to TMA, CTR etc. What else exists?

you can scan through the SLD file and look for the airspace_type filters

[Ákos Maróy]

On 13/05/13 15:55, Morten Olsen Lysgaard wrote:
> Also, how did you generate these SLDs? Not by hand I guess?

they are generated from the SLDt files using the
org.openaviationmap.rendering.ScaleSLD class

but this is a topic we could go through again.

basically my goal was to have rendering sizes in target-device-sizes -
that is, say have a 0.5mm thick line with a 2mm wide striped inside
buffer for restricted airspaces, etc.

it seems that none of the OSM rendering tools, like GeoTools or mapnik
support this. they all think of 'pixel' sizes only, or in the case of
GeoTools, 'real-world sizes' (say, draw a line that would be 100m thick
in reality, and scale it accordingly). thus for lack of a better option,
I came up with a pre-processing solution instead.

things that are even more tricky are geometric tricks used during
rendering, like the inner buffer that is filled with stripes or
semi-transparent color for a lot of airspaces. the scaling of this in
GeoTools is done in CRS coordinate space, which can be anything :)

so even though the requirements seem simple, the tools just don't seem
to fit the purpose

[Ákos Maróy]

On 13/05/13 14:06, Morten Olsen Lysgaard wrote:
> I deleted that layer and there's still nothing showing up. None of the
> german airspaces show.
> I can find them in the database so it looks like the SLDs don't trigger on them?
>

oh, and I think you have to restart geoserver, as it would be caching DB
info?

also, the layer / layet group definitions have a geographical bound,
which is calculated when it was added to geoserver. maybe having it
re-calculate the geographical bounds is needed, as more area is covered?

[Morten Olsen Lysgaard]

On Tue, May 14, 2013 at 8:00 AM, Ákos Maróy <ak...@maroy.hu> wrote:
> oh, and I think you have to restart geoserver, as it would be caching DB
> info?
>
> also, the layer / layet group definitions have a geographical bound,
> which is calculated when it was added to geoserver. maybe having it
> re-calculate the geographical bounds is needed, as more area is covered?

Both are good ideas. I've recalculated the bounds and restarted
geoserver, I just
forgot to mention. The reason the airspaces don't show are that they don't have
all the required tags, mainly the combination of type and class.

--
Morten

[Ákos Maróy]

On 14/05/13 08:10, Morten Olsen Lysgaard wrote:

that might be a valid cause ;)

[Milosz Klosowicz]

Hi.

I have found openaviationmap page/group today.

As an osm contributor and paraglider pilot as well,  i'm glad to see this initiative to extend OSM project with aviation data.

But after a little investigation i am confused with some details.

I see the approach  to separate data ( from main OSM db ) keeping  the whole OSM toolchain. 

Because OSM database contains already several kind of navigation data, and is not restricted to only physical, ground, existing entities ( see f.e. nautical routes  tagging )

i really wonder what is the reason to make such fork.

Loading data from http://osm.openaviationmap.org/api site give  only few megabytes,  that is nothing comparing to ground OSM data ( counting for the same area where OVM data exist ).

So probably there is no performance reasons too to separate data.

The next question is what  licencing model in AVM data is ? Is is compatible with OSM open database licence ?

All links from http://osm.openaviationmap.org/api  have OSM pages as destination. Does it mean the OVM data can be imported into OSM main database (some day) ?

For  possible contributors (assuming you are looking for )  it  should be clear if this is a kind of OSM "subproject" ( with all benefits like big community, stable hardware backend etc ) or  not.

With common database , adding aviation data rendering  to several exisiting software could be like change few stylesheet files.

With separate database there is quite big problem.   

[Akos Maroy]

Milosz,

> I have found openaviationmap page/group today.
> As an osm contributor and paraglider pilot as well, i'm glad to see
> this initiative to extend OSM project with aviation data.
> But after a little investigation i am confused with some details.
> I see the approach to separate data ( from main OSM db ) keeping the
> whole OSM toolchain.
> Because OSM database contains already several kind of navigation data,
> and is not restricted to only physical, ground, existing entities (
> see f.e. nautical routes tagging )
> i really wonder what is the reason to make such fork.

the reason is that OSM people don't want aviation data in the 'main' OSM
database. we've spoken to them several times on this issue.

> Loading data from http://osm.openaviationmap.org/api site give only
> few megabytes, that is nothing comparing to ground OSM data (
> counting for the same area where OVM data exist ).

no, OSM ground data is not replicated in the OAM database.

> So probably there is no performance reasons too to separate data.

no, indeed

> The next question is what licencing model in AVM data is ? Is is
> compatible with OSM open database licence ?

mainly yes, we don't yet have a 'real' licensing policy

> All links from http://osm.openaviationmap.org/api have OSM pages as
> destination. Does it mean the OVM data can be imported into OSM main
> database (some day) ?
> For possible contributors (assuming you are looking for ) it should
> be clear if this is a kind of OSM "subproject" ( with all benefits
> like big community, stable hardware backend etc ) or not.
> With common database , adding aviation data rendering to several
> exisiting software could be like change few stylesheet files.
> With separate database there is quite big problem.

as you see, OSM people don't want to have aviation data in their
database. if you can convince them otherwise, I'm more then happy to
provide input directory into the main OSM dataset.

moreover, the OSM data representation might not be sufficient for
aviation needs.


Akos

[Milosz Klosowicz]

Browsing main OSM forum i have found only two threads related to mapping aviation data into OSM database :

http://forum.openstreetmap.org/viewtopic.php?id=722

http://forum.openstreetmap.org/viewtopic.php?id=16989

As i  see there is no general opposition to the introduction of aviation data into OSM  ( except few voices  "no because no" ).

The main concerns are focused on two things"

1. The virtual entities ( like flight zones, flight paths ) SHOULD NOT be visible / renderable,  by existing renders with default stylesheets provided for ground data.

2. There is not tagging schema discussed for such a data, and there is a need to design such by people having professional knowledge about.   

3. The aviation data are "fixed" so there is no need to crowdsourcing this data  (as it will not change often ). The example of evelation data is invoked ( DEM data are not intended to be inside OSM db and are combined with OSM in render engine ).

Ad 1. and 2. is in fact the same:   people with seroius ( possible professional ) interest in OVM mapping should try to work together on tagging proposal on OSM wiki 

  ( i see some  try do make such 5 year ago " http://wiki.openstreetmap.org/wiki/DE:Luftraum ) 

 and then to run voting procedure about it.

I hope the already used tagging in OVM database is best starting point to create proposal.

Ad 3. The example  ( in my opinion ) is not appropriate because aviation data are spread into several sources ( national, governement etc) and there is no single dataset available ( as for DEM ).

The OSM is community driven so i believe the main reason for mapping things should be enough people interest ( that is ) to use the data.  

[Akos Maroy]

Milosz,

I see your point. I really think it's not us who has to be persuaded in
this regard, as I myself wanted to input aviation data into OSM
originally. It's the OSM people that have to accept this.

If you can convince them - great!

If not, we can still have our dataset, I don't see big issues with this
setup either.


Akos

[Glen Wilson]

I've been following OAM for a little while.  Here are some of my thoughts

Seperate space: I generally agree with those few that aviation doesn't really belong in the same space as regular OSM data.  It goes against the concept of OSM being an on-the-ground project (I can go and touch the tree somebody just added; I can't do the same for my local TMA boundary, even if I could fly there).  (Sea mapping projects within OSM get away with shipping lanes etc. because they don't conflict with any inland mapping).

Aviation is a complicated business.  We've got things like Flight Levels which are a way to express altitude, but FL070 isn't the same as 7000' (unless you descended below the transition level, but then you shouldn't be on flight levels anymore).  Complexity alone doesn't qualify aviation to be separated from something like OpenStreetMap, but it's probably easier to work in a space where the majority of contributers actually understand the difference between an NDB and a VOR.  Separate aviation data also makes it easier to publish an airspace map over a different (non-OSM) topographical dataset (like if I thought my local mapping agency had better information than OSM, or if I like the topo-data already on my GPS display; oh, and let me put my own DEM on that too)

What about a different editor concept?  Airspace is not really something that should be edited in JOSM (that circle 10NM around the airport needs to be accurate).  I like the import idea (with OpenAir and eAIP files).  I propose a seperate aeronautical information database.

• This would be a separate database containing things like airspace, airways, navaids, waypoints, obstacles, etc.
  
• The database would then be edited manually (for locations without good electronic data available)...
• ...or automatically during import of OpenAir files etc (but what if the import file conflicts with something already in the database?  I don't have that answer).
• The database could then output this data in OSM format (or whatever else people find useful - like Garmin format, or the format my flight simulator uses).
  

OSM has a lot of good aviation-related ground-based data.    This could easily be incorporated into OAM by means of planet extracts.

We can talk all day...but doing is better. I know what want out of OAM, but I can't have what I want until somebody makes a tool for that purpose.  I guess I better start making tools!

-- Glen

[Antonio Locandro]

I just found this http://data.x-plane.com/

 

 

Terms of use

The X-Plane data is published under the terms of the Free Software Foundation General Public License (GPL).  In summary, my interpretation of this license is that "works" published under the protection of its terms may be redistributed and modified, provided that this GPL remains a part of that redistribution.  Nothing prevents you charging for any redistributed or derivative work based upon this data ... but the terms of the GPL do not prevent (and are designed to encourage) someone else from later amending and then redistributing your work (or a derivative), either as free-ware or as pay-ware, under the same GPL terms.

This data is provided as a free service for X-Plane users. But if you appreciate what we offer here, please make a donation to your your favourite animal shelter (or another charitable organization of your choice).  "Kipper" (the dozy kitten on the image to the right) was rescued from an animal shelter in Austin, Texas in 1996, but sadly she died in June of 2010.  If you make a contribution, please let me know - I like to keep a log!

 

http://data.x-plane.com/designers.html

Can you please look at this

http://www.x-plane.com/support/manuals/wed/

 

We should rather be teaming up with similar projects like this ones that need an aviation database. As I see it they already maintain a database with a airac kind of release. Would anyone care to contact them as they already have a list of monthly contributors http://data.x-plane.com/log.html we should see how we can integrate OAM with their database so only one input is done and that data can be shared amongst different applications

 

Regards

 

On Sunday, April 28, 2013 11:26:33 PM UTC-6, Axel Müller wrote:

If I enter "http://www.openaviationmap.org/" into the browser I'm led to a page only displaying hungarian airspace. Is that the idea of OpenAviationMap?

"Open" does not suggest this limitation to hungary.

Opposite of what I'm used to at OpenStreetMap there is no way to login or an explanation of how am I supposed to work with OAM or to contribute.

If followed the link to https://code.google.com/p/openaviationmap/ which contains the software stack. However I don't want to set up another clone of OSM - I would like to contribute data but of course I want to make sure that the data isn't gone two weeks later.

So what is the current status of this project?

Best regards,

Axel