Board index FlightGear Support Tools Atlas

Atlas still in use ?

Atlas is an addon that lets FlightGear users display a real-time "moving-map" of their flight.

Re: Atlas still in use ?

Postby kuifje09 » Mon Mar 03, 2014 12:08 am

Hi Wonko,

I will try your patches this week. But atlas works rather well now already.
But I will mis some details now I guess.

b.t.w. It is great to have atlas back. I use it almost always beside fg.
Multilpayer map is also needed for quick updates on metar ( i.e. ) and look for fellow players.., Not jumping on an active runway with an active traffic leader.
But atlas is more like a real map you would carry in the plane ( apart from "follow plane" which can be switched off. Wich you should do, when you don't want to play it false. )
kuifje09
 
Posts: 579
Joined: Tue May 17, 2011 8:51 pm

Re: Atlas still in use ?

Postby Torsten » Mon Mar 17, 2014 8:56 pm

Hi,

for those using bleeding edge versions from git: you may now want to try the brand new built-in moving-map-in-a-browser.
Start FlightGear with --httpd=8080 and point your favorite web browser at http://localhost:8080/gui/map/ to get your position on an openstreetmap map.

I'd really like to use the Atlas generated maps as a layer in the browser map. Is anybody out there looking for an adventure and is able to modify the Atlas map generator to generate maps on-the-fly? Input would be three parameters: z/x/y where z is the zoom level and x/y are numeric parameters describing latitude and longitude (based on image size). Output should be a generated tile of 256x256 and format png in a memory buffer.

This could be compiled as a Apache httpd module (like osm's "renderd") or linked against a standalone webserver to akt as a tileserver for any openlayers compatible map.

Torsten
flightgear.org - where development happens.
User avatar
Torsten
 
Posts: 632
Joined: Fri Feb 01, 2008 9:22 pm
Location: near Hamburg, Germany
Callsign: offline
Version: next
OS: Linux

Re: Atlas still in use ?

Postby Hooray » Tue Mar 18, 2014 1:33 am

Torsten wrote in Mon Mar 17, 2014 8:56 pm:I'd really like to use the Atlas generated maps as a layer in the browser map. Is anybody out there looking for an adventure and is able to modify the Atlas map generator to generate maps on-the-fly? Input would be three parameters: z/x/y where z is the zoom level and x/y are numeric parameters describing latitude and longitude (based on image size). Output should be a generated tile of 256x256 and format png in a memory buffer.


We've been contemplating doing that sooner or later for the Canvas system: viewtopic.php?f=31&t=21972#p201955
you can already get an osg::Image for any Canvas, so it would seem straightforward to also serialize the image via osgDB and send it to the browser via mongoose.
Speaking in general, this should really not be made accessible to just a single subsystem like the httpd, but rather made available as a set of APIs, so that things are reusable in other places - for example, Zakalawe's Map dialog, and or any G1000-style displays. Being able to serialize such maps to a MIME-encoded stream would then just be one use-case.

Note that exposing hooks to serialize a canvas and send it out via your httpd would also mean that other Canvas/map-based imagery would be reusable, such as any MapStructure-based layers, including Gijs' NavDisplay work:
http://wiki.flightgear.org/MapStructure
Image

The code for this has been sufficiently generalized, so that this is extremely straightforward to do now, and basically any Canvas-based image could be sent to a browser, which essentialls means that even 2D panels would become available there, i.e. all the building blocks for a full instructor console would be in place, while also ensuring that things would be reusable - for example, the following screen shot renders an existing instrument/layer while also animating it, using just 20 lines of Nasal code:

http://wiki.flightgear.org/Howto:Parsin ... the_Canvas
Image

PS: you may want to update the newsletter/wiki accordingly
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: 11311
Joined: Tue Mar 25, 2008 8:40 am

Re: Atlas still in use ?

Postby Torsten » Tue Mar 18, 2014 10:35 am

Sorry, if my post was not clear. No, I am not looking for a way to generate images or map tiles from a fg canvas with nasal and display that in a web browser. I don't even think this is one of the smartest ideas to burn CPU cycles in the main loop that way.

What I have in mind for the map is to render the map tiles (small 256x256px fragments of a map) from flightgear scenery data on the fly when the user requests them from within the map application. Thats how openstreetmaps works and I like the idea of reusing proven concepts. There is no need at all - in fact, it's not even desireable - to do that in the main loop. Running a standalone application (or call it process if you like) creating and serving the tiles will add no load to the FlightGear process, no matter how complex the map is.

Torsten
flightgear.org - where development happens.
User avatar
Torsten
 
Posts: 632
Joined: Fri Feb 01, 2008 9:22 pm
Location: near Hamburg, Germany
Callsign: offline
Version: next
OS: Linux

Re: Atlas still in use ?

Postby Hooray » Tue Mar 18, 2014 12:14 pm

While it is true that a Canvas::Element is currently updated/rendered within the main loop, there's no reason why certain elements could not be run/updated in a worker thread and only synchronized at frame rate with the main process/loop - in fact this sort of thing is directly supported by OSG by using the corresponding OSG data structures and setting some traits, so far we just haven't had any need to actually do this, because Canvas stuff is usually fast enough.

Besides, you could simply use the existing Canvas::Image element for this and sub-class it - it only really deals with raster images, so you could simply compute/update the raster image asynchronously, outside the main loop and serialize things then.
In fact, having worked with the HLA and OpenRTI bindings, those could even be used to prepare the whole thing to be done in a different process, while still supporting distributed setups.

By the way, I am not at all opposed to the idea or features, but it would obviously be a good idea to come up with an approach that actually scales, and doesn't lock out certain use-cases.

PS: regarding "smart ideas" the two of us could probably have a really interesting discussion (as technical as you want it to be by the way), but please: before we use words like "smartest idea", we should probably make sure that we're all on the same page and actually understand the issue at hand sufficiently, or things are unlikely to remain/become constructive. Then again, in its current form, FlightGear is exhibiting more threading related issues than ever before, we've been seeing dozens of race conditions and segfaults related to those - so maybe adding more "threading" isn't exactly the best idea either, which is something that Curt has been suggesting for almost two decades by the way ? :D
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: 11311
Joined: Tue Mar 25, 2008 8:40 am

Re: Atlas still in use ?

Postby Torsten » Tue Mar 18, 2014 1:28 pm

My apologies if my post was offensive. That was not my intention.
I am not discussing the pros and cons of either Nasal or Canvas. Both are in FlightGear for a good reason and both have taken the simulator up to a new level.
I have no idea what the threading argument has to do here. Httpd runs on the main thread and the Tile renderer will run in its own process. Completely separated from FlightGear, on a remote machine if one wants to.

OK - I'll get back to coding.
Thanks for answering.

Torsten
flightgear.org - where development happens.
User avatar
Torsten
 
Posts: 632
Joined: Fri Feb 01, 2008 9:22 pm
Location: near Hamburg, Germany
Callsign: offline
Version: next
OS: Linux

Re: Atlas still in use ?

Postby [Lemmy] » Tue Mar 18, 2014 5:40 pm

wonko wrote in Sun Mar 02, 2014 8:36 am:For the impatient ones who have managed to compile Atlas from CVS:

I have made a quick adaption of the apt.dat reading routines in Atlas such that they can cope with the new format apt.dat. You have to replace NavData.cxx and NavData.hxx in the Atlas/src directory with the modified versions:

NavData.cxx

NavData.hxx

And here the patch files showing the differences:

NavData.cxx.patch

NavData.hxx.patch

Note that these 'quick-fix' patches will eventually be superseded by a proper fix in the CVS. They have not been tested extensively but appear to give reasonable results.




Trying to build that on openSUSE 12.3 results in this:
[ 165s] NavData.cxx: In member function 'void NavData::_loadAirports1000(gzFile_s* const&)':
[ 165s] NavData.cxx:1548:13: error: 'ap->ARP::bounds' does not have class type
[ 165s] NavData.cxx:1548:28: error: 'struct RWY' has no member named 'bounds'
[Lemmy]
 
Posts: 44
Joined: Mon Jun 18, 2012 7:58 pm

Re: Atlas still in use ?

Postby [Lemmy] » Tue Mar 18, 2014 9:13 pm

got it to build, turns out that some more recent changes in the Atlas sources renamed one variable... and guess what, murphy being an asshole, that was what broke the build.
To whom it may concern (opensuse users), Atlas is on OBS in home:lemmy04.
Have a lot of fun!
[Lemmy]
 
Posts: 44
Joined: Mon Jun 18, 2012 7:58 pm

Previous

Return to Atlas

Who is online

Users browsing this forum: No registered users and 1 guest