Board index FlightGear Development New features

A project to create a source of free geo-referenced instrume

Discussion and requests for new features. Please note that FlightGear developers are volunteers and may or may not be able to consider these requests.

A project to create a source of free geo-referenced instrume

Postby jlmcgraw » Mon Apr 21, 2014 12:59 am

All,
If you've ever used geo-referenced instrument approach plates in any of the modern EFB programs you know that they can be a great aid to situational awareness. Unfortunately they're usually a relatively expensive add-on, often costing as much as the base program itself.

In the hopes of fostering some cheaper alternatives, and as a spur to all of the programmers out there, here is a link to a spreadsheet containing geo-referencing information for approximately 11,000 FAA/Aeronav instrument approach plates from the most recent 56-day cycle (1404)

https://docs.google.com/spreadsheets/d/ ... sp=sharing

This data was generated using an open source perl program I wrote which is hosted on Github (https://github.com/jlmcgraw/GeoReferencePlates)

My intent is to make this information freely available in order to increase general flying safety, so please do NOT charge for it in any way should you choose to redistribute it or use it in a program. Please provide some attribution for the source of the data as well.

Some notes about the data:

- It isn't perfect and comes with no warranties about accuracy whatsoever. Don't bet your health or your property on this data!

- That being said, it is pretty good. Here are some numbers from a recent run:

18358 Total plates (doesn't include minimums etc)
- 5975 Plates that aren't to scale or currently in scope (SIDs/STARs, LAHSO, HOTSPOT, Airport Diagrams)
-------
12383 Potentially possible to georeference
- 1093 Military plates (these have no actual text in them and are rendered differently so they don't work with my program)
-------
11290 Currently possible with this program (basically all Civilian charts using any type of approach)
- 161 That simply don't georeference (don't pass basic sanity checks due to mismatched ground control points or the program was currently unable to find enough ground control points)
------
11129 Plates that get georeferenced (a small percentage of these are definitely inaccurate even though they pass the basic sanity checks I've devised so far)

- Note that the PDFs have been renamed to a STATE-AIRPORT-PROCEDURE format from their original names. The program depends on this format, hopefully it won't confuse anyone too badly

- Cells highlighted in red indicate that the process definitely didn't work for this particular plate (no actual text in PDF, bad longitude/latitude ratio, not enough valid ground control points)

- The PNGs I've been using were rasterized from the PDFs at 300 DPI. If you use some other DPI then you'll need to adjust the X and Y pixel scales accordingly. The longitude/latitude extents of the raster won't change


Other tidbits
- The military plates are sourced from a different environment than the civilian ones even though they're both downloadable from the same site. This isn't particularly useful information but it is interesting.

- The published obstacle database heights are not what is always depicted in these plates, perhaps they're occasionally rounded up via some formula. I haven't seen a case yet where an obstacle on a plate is marked as being lower than one in the published obstacle file but it wouldn't surprise me if there was one.


I've only tested this with Ubuntu Linux, so it is probably easiest to use it or one of its variants (xubuntu, lubuntu etc.) in a virtual machine. Virtualbox works great for this.

First steps to get this running in your Linux environment (no testing was done with Mac or Windows, please feel free to contribute patches)
- Install git (sudo apt-get install git)
- Clone the repository (git clone https://github.com/jlmcgraw/GeoReferencePlates.git)
- Follow the rest of the instructions in the readme


I think a good next step would be to crowd-source verifying the accuracy of these georeferences and creating ones for those plates that this program didn't work with. This would probably be reasonably straightforward via a web site or an add-in to existing EFB programs on Android or IOS that have a large existing user base but it isn't something I can work on currently.

If you'd like to see how these look on a map and are familiar with the free GIS program called QGIS, check out my aviation map project here: https://github.com/jlmcgraw/aviationMap.git
Load the example Virtual Raster files (*.vrt) to see how the plates match up with the airspace, runway, obstacle, fix, and navaid data from the FAA.

If you have any ideas about how to make this program or data better please let me know via email or contribute patches at github. It is still a work in progress and I am definitely not a professional programmer so I'll take all the input I can get.

I look forward to your feedback and fly safe!

-Jesse McGraw
jlmcgraw@gmail.com
jlmcgraw
 
Posts: 6
Joined: Sun Dec 22, 2013 5:40 pm

Re: A project to create a source of free geo-referenced inst

Postby Hooray » Mon Apr 21, 2014 2:40 am

Hi & welcome!

That's definitely interesting - indeed, we may not even need to run external EFB software, because our integrated scripting system in combination with the Canvas 2D rendering system may provide all the hooks required to render such geo-referenced imagery directly inside FlightGear with very little work needed - we even have http bindings to load images on the fly. I'd suggest to add a paragraph about your work to the upcoming newsletter (see my signature), or even add a dedicated article to the wiki.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11340
Joined: Tue Mar 25, 2008 8:40 am

Re: A project to create a source of free geo-referenced inst

Postby Johan G » Mon Apr 21, 2014 1:06 pm

This will probably come in handy for more than a few of us, :D even though it is not compatible with FlightGear's license (GNU GPL v.2).
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5527
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: A project to create a source of free geo-referenced inst

Postby jlmcgraw » Mon Apr 21, 2014 1:54 pm

I am not a lawyer or licensing expert, why is this incompatible with Flightgear's licensing?

I want the program and it's output to be available to free and open source software like Flightgear, what do I need to change to make that work?
jlmcgraw
 
Posts: 6
Joined: Sun Dec 22, 2013 5:40 pm

Re: A project to create a source of free geo-referenced inst

Postby Philosopher » Mon Apr 21, 2014 1:57 pm

See here: https://www.gnu.org/licenses/gpl-faq.ht ... AllowMoney

You could only suggest that it not be sold for money, not actually require that it be the case, if you want to be compatible with the GPL.

Two examples of where FlightGear is sold for money is the online CDs available for purchase from the main site (to cover expenses related to making those), and by the unfortunate scammers who sell it for their own profit, when it's freely available already :(. But the scammers don't seem to keep up with releases/new features, if you know what I mean ;).
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: A project to create a source of free geo-referenced inst

Postby Johan G » Mon Apr 21, 2014 2:23 pm

jlmcgraw wrote in Mon Apr 21, 2014 12:59 am:My intent is to make this information freely available in order to increase general flying safety, so please do NOT charge for it in any way should you choose to redistribute it or use it in a program.

jlmcgraw wrote in Mon Apr 21, 2014 1:54 pm:...I want the program and it's output to be available to free and open source software like Flightgear...

It will still be possible to use with FlightGear of course, so no problems there. :D

In practical terms it only means that the software and output can not be distributed together with the FlightGear software itself, but we could still link to it, recommend it, have "helpers" making it simple to use etc... :wink: :D For example there are quite some aircraft out there that are not compatible with the license, but of course still usable with FlightGear.


P.S. The GNU GPL v.2 (General Public License version 2) make software "free as in speech", but not necessarily "free as in beer". In essence one can without problem sell FlightGear for example on USB sticks, as long as the license and copyright notices are still there. :wink:
Last edited by Johan G on Mon Apr 21, 2014 2:30 pm, edited 2 times in total.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5527
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: A project to create a source of free geo-referenced inst

Postby jlmcgraw » Mon Apr 21, 2014 2:26 pm

Fair enough, I'll remove that language from the program and just hope for the best
jlmcgraw
 
Posts: 6
Joined: Sun Dec 22, 2013 5:40 pm

Re: A project to create a source of free geo-referenced inst

Postby Hooray » Mon Apr 21, 2014 3:13 pm

I haven't yet looked at the Perl program, but could you briefly sketch out what is required API wise to do this ?
I suppose some way of 1) HTTP fetching/downloading, 2) URL parsing, 3) image processing, 4) disk I/O ?

I am just asking to see how difficult it would be to port your work to use FlightGear's integrated scripting language and 2D rendering system directly, we should have most building blocks required for this in place, maybe some things are not yet exposed to scripting space currently (but still available in C++) - but being able to run this directly inside FG would be kinda useful obviously, especially because of recent work in this area, especially the tiled map support, HTTP bindings, SGPath exposure (disk access). And being able to directly geo-align raster images has been previously discussed, too:

Subject: BROWSER MP-MAP plotted on a MFD somebody?


Subject: Instruments with height maps ?
Hooray wrote:While the canvas system doesn't currently have support for rendering "moving maps" (i.e. terrain layers), that's one of the most-frequently requested features obviously - and there are several options, one of the simpler ones being reusing code from atlas to create the required "maps" dynamically in a background thread and making the texture then available as a geo-referenced "layer", i.e. via a new canvas element implemented in C++ space.

Brian (the atlas developer) just said this a couple of days ago:
bschack wrote:The code that comes closest to what you immediately need (creating map textures) is in TileMapper.cxx and the classes that it depends on, like Bucket.cxx and Subbucket.cxx (where the real drawing takes place).


The portion of the atlas code would obviously need to be converted to OSG to be reusable and it would need to use the FG tile manager, but that would probably be simpler than implementing CompositeViewer support.

Subject: DDS for textures Rotterdam
Hooray wrote:Meanwhile, what we could do is identify which hooks are needed to make this work and provide those via the Canvas system: Canvas textures can already be placed in the scenery, so there should be very little needed in terms of placement-specific attributes, and the corresponding code should be available in SimGear/FlightGear already.

Tom also mentioned a while ago that he made a few experiments related to this. And being able to use arbitrary canvas textures as orthographic overlays would be kinda useful for many things. Even Tim and Curt talked about how cool having such a feature in FlightGear would be:

http://wiki.flightgear.org/Canvas_Devel ... te_note-21
Curt wrote:Given an image and the location and orientation of the camera, it would be possible to locate world coordinates across a grid on that image. That would allow a quick/crude orthorectification where the image could be rubber sheeted onto the terrain. This would take some offline processing, but you could end up building up a near real time 3d view of the world than could then be viewed from a variety of perspectives. The offline tools could update the master images based on resolution or currency ... that's probably a phd project for someone, but many of the pieces are already in place and the results could be extremely nice and extremely useful (think managing the effort to fight a dynamic forest fire, or other emergency/disaster management, traffic monitoring, construction sites, city/county management & planning, etc.) I could even imagine some distrubuted use of this so that if you have several uav's out flying over an area, they could send their imagery back to a central location to update a master database ... then the individual operators could see near real time 3d views of places that another uav has already overflown.
If we started building up more functionality in this area, there are a lot of different directions we could take it, all of which could be extremely cool.


So this should have a pretty good chance of getting accepted upstream ...

If anybody is interested in working on this, just get in touch - given that there is already a patch doing this sort of thing, it should be straightforward to generalize things a bit to ensure that this becomes a feature in FG 3.2, without requiring any patching.



So this could turn out to be less than 200-300 lines of scripted FlightGear/Nasal code using existing bindings and a few more additional hooks for the Canvas system, while being 100% native to FlightGear.

The other option would be using the existing Perl script and hosting it as a CGI and using it via the http/tilemap code
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11340
Joined: Tue Mar 25, 2008 8:40 am

Re: A project to create a source of free geo-referenced inst

Postby jlmcgraw » Mon Apr 21, 2014 4:31 pm

Right now the script basically just a creates .PNG and a .VRT for a given plate, suitable for loading directly into something like QGIS

If you run the script for the entire set of plates (eg. "multithread.sh .") using the -s option you'll get a statistics file which has all of the lon/lat extents for each plate in it (which is how I made the spreadsheet I linked here)

There's no server component or API whatsoever, I'm imagining the data would be placed into a local database and looked up whenever a given plate is loaded.


Hooray wrote in Mon Apr 21, 2014 3:13 pm:I haven't yet looked at the Perl program, but could you briefly sketch out what is required API wise to do this ?
I suppose some way of 1) HTTP fetching/downloading, 2) URL parsing, 3) image processing, 4) disk I/O ?

I am just asking to see how difficult it would be to port your work to use FlightGear's integrated scripting language and 2D rendering system directly, we should have most building blocks required for this in place, maybe some things are not yet exposed to scripting space currently (but still available in C++) - but being able to run this directly inside FG would be kinda useful obviously, especially because of recent work in this area, especially the tiled map support, HTTP bindings, SGPath exposure (disk access). And being able to directly geo-align raster images has been previously discussed, too:
jlmcgraw
 
Posts: 6
Joined: Sun Dec 22, 2013 5:40 pm

Re: A project to create a source of free geo-referenced inst

Postby Hooray » Mon Apr 21, 2014 4:37 pm

There's no server component or API whatsoever, I'm imagining the data would be placed into a local database and looked up whenever a given plate is loaded.

I am still waiting for other opinions to see if we should port this to become a FlightGear script - but if the feedback is such that this is not required as a native feature, we would probably want to explore hosting it somewhere as a flightgear web service, so that fgfs can access the whole thing via a central server like http://charts.flightgear.org

Then again, extending our 2D rendering API (Canvas) to provide a mechanism to geo-align such images would be kinda useful for a variety of purposes, we already have a "map" element that can automatically geo-reference lat/lon pairs without any manual work involved - and we also have support for a raster image element.

And the FlightGear scenery folks have been working on supporting photoscenery through geo-referenced textures - given that our canvas system provides support for scenery placements, we could also overlay scenery textures via canvas that way, while also supporting charts to be aligned properly.

This is definitely something that will be of interest to our glass cockpit folks, especially the EFB guys (because they're doing all this manually at the moment):

http://wiki.flightgear.org/Canvas_EFB_Framework
http://wiki.flightgear.org/Boeing_787-8_Dreamliner
Image

VRT (Virtual Raster Tile) files being plain XML should be fairly straightforward to process purely with FlightGear/Nasal scripting.

PS: You may also want to add your work to the upcoming newsletter, see my signature for details (you only need to register a wiki account to add things to the newsletter)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11340
Joined: Tue Mar 25, 2008 8:40 am

Re: A project to create a source of free geo-referenced inst

Postby jlmcgraw » Mon Apr 21, 2014 5:07 pm

You can just have the script spit out the extents (upper left lon/lat, lower right lon/lat) directly since that's what it's feeding to GDAL to create the .vrt's

Fortunately all of the plates are aligned to true north so there' s no rotation involved like there is with some airport diagrams.

This script is at heart very dumb, there's no fancy OCR or image recognition going on, it's all done via REGEXes. It is very fragile in the sense that if the plates are ever convertd to PDF from their original CAD format (*.dgn) any differently than they are now it will probably stop working (this is why the miltary plates don't work, the text is all drawn and all of the features are drawn differently)

A much more robust (and complicated) solution would be to use image recognition. But this way mostly works for now :)

For the plates that either completely don't work or are inaccurately positioned, is there a way for users to geocode within Flightgear and send that data back to the central server?
jlmcgraw
 
Posts: 6
Joined: Sun Dec 22, 2013 5:40 pm

Re: A project to create a source of free geo-referenced inst

Postby Hooray » Mon Apr 21, 2014 5:19 pm

jlmcgraw wrote in Mon Apr 21, 2014 5:07 pm:For the plates that either completely don't work or are inaccurately positioned, is there a way for users to geocode within Flightgear and send that data back to the central server?


just to be clear, we do not currently have any "central server" for such charts - but we've had people volunteering hosting for such purposes in the past.
custom HTTP requests can be made via two main ways: fgcommands (less flexible, output must be a PropertyList XML file, a bit outdated but well-documented): http://wiki.flightgear.org/Howto:Making ... from_Nasal

And the more recent, but less documented, option is using Nasal http bindings: http://wiki.flightgear.org/List_of_Nasa ... 2.99.2B.29

So "geo-coding" (as in manually aligning an image) could be done via FlightGear's Canvas system which allows GUI events (e.g. mouse events) to be captured and processed: http://wiki.flightgear.org/Canvas_-_Event_Handling

For instance, FlightGear has fairly basic support for geographic referencing via its scripted "geo.nas" module, which is for example used by an aircraft/ufo-based scenery editor, that basically captures the current position (lat/lon/alt) and allows scenery models to be placed there: http://wiki.flightgear.org/Ufo

The geo.nas module is located in $FG_ROOT/Nasal/geo.nas

But there's currently no dedicated interface to directly talk to the GIS DB used for creating scenery, that's all done separately (and often manually)

The main scenery/TerraGear devs (namely psadro_gm) have been contemplating to factor out TerraGear into separate QGIS/GRASS plugins for a while

Looking at TheTom's code, we would probably want to support transformations based on lat/lon/range attributes as part of the canvas system
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11340
Joined: Tue Mar 25, 2008 8:40 am

Re: A project to create a source of free geo-referenced inst

Postby TheTom » Wed Apr 23, 2014 9:19 am

I'm not sure if there is a bit of a misunderstanding here. I don't think it makes sense (and is easily possible) to include the script somehow in FlightGear. It "just" creates a matrix for a given plate containing it's scale and position, so all we have to do to display such charts within FlightGear is to load the chart image and apply the matrix created by the script. In the case of VRT files, it should be enough to just read the GeoTransform tag and set it as matrix on the Image element inside the canvas (with the parent element set up to have a coordinate system matching the current position and range).

Some central server for collecting such free and geo-referenced charts would surely be useful and probably does not require too much space and bandwith. These charts would not only be useful for FlightGear, but also for real aviation applications, like EFBs. I think I saw this or a similar script somewhere inside the sources of Avare?
TheTom
 
Posts: 321
Joined: Sun Oct 09, 2011 10:20 am

Re: A project to create a source of free geo-referenced inst

Postby Hooray » Wed Apr 23, 2014 10:14 am

right, having just a web service that maintains and provides those charts would be straightforward and should not require any work on the Canvas side of things, also it avoids redundant work, because charts would remain identical normally, i.e. would only need to be created once. Not sure what the geo-coding question was all about ..
It might be a good idea to come up with some caching/lookup scheme to save such charts next to airports in $FG_ROOT so that at least the default scenery (KSFO, KOAK, KHAF) comes with those charts included - analogous to the way XML files are kept next to each airport /K/S/F/O
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11340
Joined: Tue Mar 25, 2008 8:40 am

Re: A project to create a source of free geo-referenced inst

Postby jlmcgraw » Wed Apr 23, 2014 6:09 pm

Hooray wrote in Wed Apr 23, 2014 10:14 am:Not sure what the geo-coding question was all about ..


If you're referring to my comment I should have said "georeference" instead.

My thought was that the output of my program is not perfect by any means and that if there was a way for a user or developer to do some quick graphical re-adjustment of the reference and submit that back to a centralized source then before long we'd end up with a better and more complete georeference database.
jlmcgraw
 
Posts: 6
Joined: Sun Dec 22, 2013 5:40 pm

Next

Return to New features

Who is online

Users browsing this forum: No registered users and 0 guests