Board index FlightGear Development Canvas

Tilemap support

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

Tilemap support

Postby gral » Thu Jan 17, 2013 12:35 pm

TheTom wrote in Thu Jan 17, 2013 10:41 am:I have no plans of replacing Nasal with anything else. I'm just experimenting with different already available UI designers and file formats so we can maybe reuse them for FlightGear. Instead of QML it maybe better to use Qt UI files which is are stored using xml.

As I've already said I'm just brainstorming. For cockpit instruments using Inkscape with maybe a plugin will probably fit better. I'm always looking for any suggestions and ideas :)


Hi Tom

Yes, I should stop acting as nasal and canvas troll here ;-). For me it's more a question if it will be possible (theoretically) to have dynamical maps like http://test.fgx.ch on the canvas in a instrument once, and how this could be done. So flightgear "only" needs to load the view and does less drawing as possible. There is no interpretation at all needed probably in case canvas could "download" and show pngs and reproject positions to the right coordinate system. The benefit for me would be that fg has not to calculate and draw stable and widely used mapping data in the program itself, it shows precalculated tiles and probably just create an overlay. I need some suggestions if this is a complete overload of the canvas system and I should move into other direction with a built-in map for instruments. (I know there IS a built-in map, but this poor mans mapping system is not what I'm looking for).

Thanks for audience, and maybe someone can answer me some questions and help to get me less confused on canvas :-)

gral
gral
 
Posts: 325
Joined: Mon Nov 16, 2009 1:03 pm
Location: Zurich (Switzerland)
Callsign: HB-GRAL
Version: GIT

Re: Canvas custom GUI

Postby TheTom » Thu Jan 17, 2013 1:19 pm

A tilemap is definitely something I want to implement - not only theoretically ;) Projecting coordinates is already possible (even if we will need some more projections) loading images is also possible. Creating a tilemap shouldn't be too hard.
TheTom
 
Posts: 321
Joined: Sun Oct 09, 2011 10:20 am

Re: Canvas custom GUI

Postby gral » Fri Jan 18, 2013 1:06 am

TheTom wrote in Thu Jan 17, 2013 1:19 pm:A tilemap is definitely something I want to implement - not only theoretically ;) Projecting coordinates is already possible (even if we will need some more projections) loading images is also possible. Creating a tilemap shouldn't be too hard.


Hi Tom

Maybe you are aware of all this stuff, but I try to explain again what I'm doing here recently. When you have a look to http://test.fgx.ch/airports.html you see a transparent overlay of airports. This is in EPSG 3857 projection and the layer has 17 zoom levels. The resolution for this zoom levels you will find in source (see map init function) or trough http://tilecache.fgx.ch:81/tilecache.py/1.0.0/Airport . Tilecache prepares this tiles trough an ogcserver WMS service and creates a folder structure per layer. More information about how this works you can also find here http://tilecache.org/docs/README.html .

This mercator map is a more or less bad example for a map and there is nothing better with this map compared to the standard projection of flightgear. The only reason I took this EPSG is being compatible with OSM and Google this time, but I prepared also tiles in other projections, i.e. EPSG 3112 which is an LCC projection of Australia. The disadvantage of some conformal projections might be that this doesn't cover the whole world in nature of the projection. But the disadvantage of taking 3857 for aeronautical needs is well known too ;-)

So when you or some else wants to perform a test with loading such tiles/images into canvas this will be much appreciated here. You can also order a completely different layer/data/style, I can reconfigure tilecache or the wms service to many neat things, having complete current xplane airport and navaid data in postgres/postgis as a base. btw. the flightgear map server works with the same techology AFAIK at least for caching, so I guess the tilecache system is highly compatible (I see my mapserver as a development and experimental server anyway, and I don't want to replicate things, I'm just using "mapnik" instead of "mapserver" for creating the maps, because of its nice map design features etc.).

gral
gral
 
Posts: 325
Joined: Mon Nov 16, 2009 1:03 pm
Location: Zurich (Switzerland)
Callsign: HB-GRAL
Version: GIT

Re: Tilemap support

Postby Hooray » Fri Jan 18, 2013 2:29 pm

at the moment, FG's HTTP-related fgcommands don't support fetching images (or any binary data at all).
It's all specific to XML data, in fact PropertyList-encoded XML: http://wiki.flightgear.org/Howto:Making ... from_Nasal

And according to the issue tracker, there's some resistance concerning such features, due to the potential security issues: https://code.google.com/p/flightgear-bu ... id=450#c33
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: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: Tilemap support

Postby gral » Fri Jan 18, 2013 9:05 pm

Hooray wrote in Fri Jan 18, 2013 2:29 pm:at the moment, FG's HTTP-related fgcommands don't support fetching images (or any binary data at all).
It's all specific to XML data, in fact PropertyList-encoded XML: http://wiki.flightgear.org/Howto:Making ... from_Nasal

And according to the issue tracker, there's some resistance concerning such features, due to the potential security issues: https://code.google.com/p/flightgear-bu ... id=450#c33


Hi Hooray

I was thinking about drawing the images on canvas with the same tiling structure and seeking the data i.e. with libsvn support already in flightgear. There are other tiling solutions out there of course, i.e. what mapbox/tilemill is using with unbelievable numerous blobs in a sqlite db, but to be compatible with what flightgear mapserver provides I guess it is the best looking to what TileCache can produce probably.

-gral
gral
 
Posts: 325
Joined: Mon Nov 16, 2009 1:03 pm
Location: Zurich (Switzerland)
Callsign: HB-GRAL
Version: GIT

Re: Tilemap support

Postby gral » Sat Jan 19, 2013 10:13 am

Image
Just to make an example from what mapping data I'm speaking of. I.e. when you want to create a MFD like the Aspen ones or whatever moving map/wx radar, you can use such relief as background. It does not have to be in this resolution, but loading this (reprojected) tiles into canvas would be nice.

-gral

btw. I have prepared this kind of reliefs for the whole SRTM coverage. I'm looking for backup places 8)
gral
 
Posts: 325
Joined: Mon Nov 16, 2009 1:03 pm
Location: Zurich (Switzerland)
Callsign: HB-GRAL
Version: GIT

Re: Tilemap support

Postby Hooray » Sat Jan 19, 2013 1:16 pm

think we talked about it when we considered supporting GeoTIFF images (which are supported by OSG already) ...
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: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: Tilemap support

Postby gral » Sat Jan 19, 2013 3:46 pm

Hooray wrote in Sat Jan 19, 2013 1:16 pm:think we talked about it when we considered supporting GeoTIFF images (which are supported by OSG already) ...


Hi Hooray

In my view there is no need for geotiff support. But maybe I do not understand what others achieve with this. There is no further data processing needed, trying to process such image data directly within flightgear will fail for performance reason and is a bare waste of energy on the other hand when every instance is doing this. When the canvas understands the file/directory structure of reprojected and prepared/tiled data it just loads the images at appropriate viewport location. These images are "georeferenced" by tile file structure, no geotiff support needed. Or do I misunderstand?

-gral

Edit: Ou, forgot to mention, in case someone is looking to TileStache or mbtiles/sqlite system ... these are made for smaller shopping maps and support only two projections at the moment AFAIK. Depends on what you want to see with your MFD of course. I made a test with a world coverage of xplane airport points and recent TileMill sqlite/mbtiles tiling once. Unfortunately at a first try I was not able to prepare a cache with this, the mbtiles size exceeded every known file size on my machine with 12 zoomlevels to tile. That's sad, because the approach of preparing only tiles where data is found in case of mbtiles is a nice one (one of the "limits" of TileCache).
gral
 
Posts: 325
Joined: Mon Nov 16, 2009 1:03 pm
Location: Zurich (Switzerland)
Callsign: HB-GRAL
Version: GIT

Re: Tilemap support

Postby TheTom » Sat Jan 19, 2013 4:19 pm

gral wrote in Sat Jan 19, 2013 3:46 pm:When the canvas understands the file/directory structure of reprojected and prepared/tiled data it just loads the images at appropriate viewport location.

This is exactly what I'm currently thinking of.
TheTom
 
Posts: 321
Joined: Sun Oct 09, 2011 10:20 am

Re: Tilemap support

Postby Hooray » Sat Jan 19, 2013 8:14 pm

not at all disagreeing. There are many ways to skin this cat :-)
performance-wise, loading server-side images is obviously superior.
On the other hand, we'll always have the issue that scenery data and will nevertheless use different data sources, and may thus not match exactly ...
but that's also a problem found in RL.
So, let's try to walk before we run :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: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: Tilemap support

Postby gral » Sun Jan 20, 2013 5:55 pm

Hooray wrote in Fri Jan 18, 2013 2:29 pm:at the moment, FG's HTTP-related fgcommands don't support fetching images (or any binary data at all).
It's all specific to XML data, in fact PropertyList-encoded XML: http://wiki.flightgear.org/Howto:Making ... from_Nasal

And according to the issue tracker, there's some resistance concerning such features, due to the potential security issues: https://code.google.com/p/flightgear-bu ... id=450#c33


Hi Hooray
Binaries is one thing ... but after some reading in one of your well edited wikis I see that we're crossing the scene somehow with the crossfeed client for fgms. Because we're a bit fixed on js we use to provide json feed :wink: I see now that with fgcommand it would be easy to provide i.e. multiplayer positions on a instrument/MFD map/radar. The only thing needed is the same represented in fat xml as I see, but that could run on another data proxy without further problems. Is something speaking against a crossfeed extension returning the appropriate xml for a test ? Are there other plans how to deal with representation of mp positions on canvas ? Or are there some longterm plans for a native json support trough nasal at the end ?

-gral
gral
 
Posts: 325
Joined: Mon Nov 16, 2009 1:03 pm
Location: Zurich (Switzerland)
Callsign: HB-GRAL
Version: GIT

Re: Tilemap support

Postby gral » Sun Jan 20, 2013 6:43 pm

TheTom wrote in Sat Jan 19, 2013 4:19 pm:
gral wrote in Sat Jan 19, 2013 3:46 pm:When the canvas understands the file/directory structure of reprojected and prepared/tiled data it just loads the images at appropriate viewport location.

This is exactly what I'm currently thinking of.


Hi Tom
When you're going down this route for some further testing I can try to prepare a new MFD with canvas for such testing purpose, means creating the instrument model and functions (means diving into fg nasal gral, *yuck!*) and preparing i.e. a tiled relief of distinct region. Or someone can point me to a contemporary glass-cockpit-like-MFD-project already here I should take into account and which needs some contribution or pick up or help ? Have no overview in model development.

-gral
gral
 
Posts: 325
Joined: Mon Nov 16, 2009 1:03 pm
Location: Zurich (Switzerland)
Callsign: HB-GRAL
Version: GIT

Re: Tilemap support

Postby Hooray » Sun Jan 20, 2013 9:37 pm

I'd suggest to grep the xml/nasal files in $FG_ROOT/Aircraft for "canvas" and you should be able to find some of the early adopters.
And if you can't find anything, get directly in touch with Tom, who's also started working on a C130J a while ago, including MFDs (not sure if that's available yet)
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: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: Tilemap support

Postby Hooray » Mon Jan 21, 2013 8:01 pm

gral wrote in Sun Jan 20, 2013 5:55 pm:Hi Hooray
Binaries is one thing ... but after some reading in one of your well edited wikis I see that we're crossing the scene somehow with the crossfeed client for fgms.


I'd just suggest to be careful regarding new features and infrastructure built on top of fgms, which hasn't been overly actively developed or maintained during the last years. And Mathias' HLA work is bearing more and more fruits, so that it's becoming increasingly likely that fgms will eventually be phased out by a HLA-based multiplayer component.

Because we're a bit fixed on js we use to provide json feed :wink:

Conceptually JSON is no problem, and very close to Nasal's vector/hash syntax - so it would be relatively easy to also process JSON via Nasal.
On the other hand, supporting socket I/O via Nasal is obviously a potential security issue.

Are there other plans how to deal with representation of mp positions on canvas ? Or are there some longterm plans for a native json support trough nasal at the end ?


MP positions are already written to the property tree (within a range of 100nm ...), so they can be processed by client-side Nasal, which could in turn use the canvas/map to show positions on a map (tcas etc).

Is something speaking against a crossfeed extension returning the appropriate xml for a test ?

Like the tutorial illustrates, you can easily experiment with all types of data, just by setting up a server that returns some arbitrary PropertyList XML.
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: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: Tilemap support

Postby gral » Sun Jan 27, 2013 9:26 pm

Hooray wrote in Mon Jan 21, 2013 8:01 pm:
gral wrote in Sun Jan 20, 2013 5:55 pm:Hi Hooray
Binaries is one thing ... but after some reading in one of your well edited wikis I see that we're crossing the scene somehow with the crossfeed client for fgms.


I'd just suggest to be careful regarding new features and infrastructure built on top of fgms, which hasn't been overly actively developed or maintained during the last years. And Mathias' HLA work is bearing more and more fruits, so that it's becoming increasingly likely that fgms will eventually be phased out by a HLA-based multiplayer component.


Hi Hooray

And me, I would suggest to be a bit careful with promoting HLA/RTI as a quick an ongoing fgms replacement. You will probably succeed with a small and fast local netwotk with HLA/RTI at the moment, but not with what fgms supports these days trough a http/multiplayer network. But maybe I'm out of the loop where HLA/RTI is going right now with current development and I ask for objection of course, immediately ;-)

Because we're a bit fixed on js we use to provide json feed :wink:
Conceptually JSON is no problem, and very close to Nasal's vector/hash syntax - so it would be relatively easy to also process JSON via Nasal.
On the other hand, supporting socket I/O via Nasal is obviously a potential security issue.

Are there other plans how to deal with representation of mp positions on canvas ? Or are there some longterm plans for a native json support trough nasal at the end ?


I do not care about "potential" security issues, that's not obvious. I studied the "vector" and hash syntax ... well ... Having json isn't a security issue at all, or then vector/hash would be one too. Why do we have to draw the security card with fg always when there are some lacks in nasal ?

-gral

Edit: I mean there is no security issue with nasal related to json support. Related to socket I/O there might be one, but that's another scope. The security issue of I/O socket is not a problem of nasal in general, it's more related to the c++ core in my opinion. Oh! Just started to think about serverside nasal like node.js this moment ... oh! 8)
gral
 
Posts: 325
Joined: Mon Nov 16, 2009 1:03 pm
Location: Zurich (Switzerland)
Callsign: HB-GRAL
Version: GIT

Next

Return to Canvas

Who is online

Users browsing this forum: No registered users and 2 guests