From: BARANGER E. <emb...@fr...> - 2011-10-30 16:03:39
|
About maps ZKV1000, I sincerely believe that the use of osgearth solve many problems. Unfortunately, for a long time when I suggest something, no one is listening. And I'm tired of fighting. With osgearth we could even create a specific server complete with cards containing information navigation (NAV, VOR, ILS etc. ..) Regards. Emmanuel -- BARANGER Emmanuel http://helijah.free.fr |
From: Martin S. <Mar...@mg...> - 2011-10-30 17:30:34
|
BARANGER Emmanuel wrote: > With osgearth we could even create a specific server complete with cards > containing information navigation (NAV, VOR, ILS etc. ..) osgEarth is not the first choice of a tool for this sort of work. In order to feed tools like Atlas or moving maps in general from a network server, you'd want to look at protocols like WMS and the servers which already have been developed for this purpose. As an offer in order to get the ball rolling: If anyone bothers to implement the WMS client side into Atlas (either EPSG:4326 or, maybe preferred, EPSG:900913, tile size 256x256), then I'll promise to serve the tiles. We'd start with the known Atlas map style and once the system works, we're open for any other WMS service on the world. The app doesn't necessarily have to be based on Atlas, I just chose that once because it's well known in FlightGear-world. If anyone's interested, start reading here: http://wiki.osgeo.org/wiki/WMS_Tiling_Client_Recommendation Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
From: Geoff M. <ub...@ge...> - 2011-10-30 18:42:54
|
On Sun, 2011-10-30 at 17:30 +0000, Martin Spott wrote: > BARANGER Emmanuel wrote: > > > With osgearth we could even create a specific server complete with cards > > containing information navigation (NAV, VOR, ILS etc. ..) > > osgEarth is not the first choice of a tool for this sort of work. In > order to feed tools like Atlas or moving maps in general from a network > server, you'd want to look at protocols like WMS and the servers which > already have been developed for this purpose. > > As an offer in order to get the ball rolling: If anyone bothers to > implement the WMS client side into Atlas (either EPSG:4326 or, maybe > preferred, EPSG:900913, tile size 256x256), then I'll promise to serve > the tiles. We'd start with the known Atlas map style and once the > system works, we're open for any other WMS service on the world. > The app doesn't necessarily have to be based on Atlas, I just chose > that once because it's well known in FlightGear-world. > > If anyone's interested, start reading here: > > http://wiki.osgeo.org/wiki/WMS_Tiling_Client_Recommendation > > Cheers, > Martin. Hi Martin, Wow, just what the doctor ordered ;=)) As you may know the Atlas project already has a GetMap application, linked with CURL to to do the http requests... written by Fred back in 2004, I think... GetMap was to provide an alternative method of generating tiles for use with Atlas... and which can also be used for ZKV1000 maps... The ONLY 'sample' WMS server written into it was wms.jpl.nasa.gov, which, as you may know, no longer offers full public WMS services... About a week or so ago I searched around hard to find some other available public WMS servers, but after trying quite a number, found none ;=(( So yes, I have read the reference you pointed to, and lots of other WMS stuff, and would be prepared to modify GetMap to use your server, but maybe it does not even need modification... The user supplies a base_url, size, min_lat, min_lon, max_lat, max_lon, and an output directory, and the request is presently presented in the form - // the default size is 256 if none given... // some range checking to make sure it is in the world // then for (y = min_lat; y < max_lat; y += 1) { for (x = min_lon; x < max_lon; x += 1) { rx = x; if (rx >= 180) rx -= 360; outfile << out_dir << "/[w|e]???[s|n]??.jpg"; surl << base_url << "REQUEST=GetMap&VERSION=1.1.1" << "&WIDTH=" << size << "&HEIGHT=" << size << "&BOX=" << rx << "," << y << "," << rx+1 << "," << y+1 << "&FORMAT=image/jpeg&SRS=EPSG:4326" // and curl is used to fetch and write this tile... } } It could be easily modified to use "EPSG:900913" if that is preferred... It does seem a default size of 256x256 is perhaps a little small for 1x1 degrees, but anyway other methods could be used to combine images into say 1024x1024... And as indicated, I hope later airport and navaid overlays could be added via say &LAYERS=... or something, to the relief and/or landuse image... and maybe format alternatives like png or gif... lot of possibilities... What is the GetCapabilities URL? Or is it not set up yet? Regards, Geoff. |
From: HB-GRAL <fli...@sa...> - 2011-10-31 17:35:02
|
Am 30.10.11 19:42, schrieb Geoff McLane: > "&FORMAT=image/jpeg&SRS=EPSG:4326" > Hi Geoff Just one little thing here, in case someone is working on this: I suggest not to use image/jpeg for rendering, I guess it is better to use image/png for quality maps. Cheers, Yves |
From: James T. <zak...@ma...> - 2011-10-30 19:32:47
|
On 30 Oct 2011, at 16:07, BARANGER Emmanuel wrote: > About maps ZKV1000, I sincerely believe that the use of osgearth solve > many problems. Unfortunately, for a long time when I suggest something, > no one is listening. And I'm tired of fighting. I don't know about your other suggestions, but 'using osgEarth' isn't exactly straightforward - unless you can get someone skilled in osgEarth interested. So it's not a case of 'not listening', more of not being able to do anything constructive with your suggestion, unfortunately. James |
From: Martin S. <Mar...@mg...> - 2011-10-30 19:38:55
|
Geoff McLane wrote: > As you may know the Atlas project already has > a GetMap application, linked with CURL to > to do the http requests... written by Fred back in 2004, No, I didn't know. When I talked to Brian Schack about this topic, the conversation somehow got lost (and I do feel guilty in some way ....). As far as I can remember the biggest obstacle was set by Atlas's tile schema being organized alongside FlightGear's Scenery tiling schema, being slightly different from what WMS tile servers typically provide. Actually I'm unable to afford the time for providing the introduction into the logic behind WMS(-C) and related protocols, but there's plenty to read at OSGeo and related projects (start at TileCache for example). BUT I'd be willing to set the tile server up - simply because I'm convinced that this is "the right thing to do" about serving map imagery from a server .... well, actually the entire infrastructure is already in place, because I've been doing this sort of stuff for years, I'd just have to compile the Atlas imagery into a suitable format. Actually there are many functional OpenSource WMS clients available, you don't necessarily have to write one from scratch. KDE Marble has one, QGIS has one, even GDAL includes a WMS client implementation: http://gdal.osgeo.org/frmt_wms.html > The ONLY 'sample' WMS server written into it was > wms.jpl.nasa.gov, which, as you may know, no longer > offers full public WMS services... Oh yes, NASA OnEarth service had been pretty flaky - until they finally switched it off :-) > So yes, I have read the reference you pointed to, and > lots of other WMS stuff, and would be prepared to modify > GetMap to use your server, but maybe it does not even need > modification... Please negotiate with Brian - I think he's still the Atlas maintainer - in order to prevent forking and/or duplicate work and keep me posted, if required. > It could be easily modified to use "EPSG:900913" if > that is preferred... I'll leave this to you. The benefit of EPSG:900913 is to be conformant with many well-known public tile services. If you manage to automatically create requests like this one (_very_ long line): http://mapserver.flightgear.org/tc/?LAYERS=tarmac&TRANSPARENT=true&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&SRS=EPSG:900913&BBOX=714227.59136875,6653078.93995,724011.5309875,6662862.8795688&WIDTH=256&HEIGHT=256 .... then you've probably overcome most of the trouble. > And as indicated, I hope later airport and navaid > overlays could be added via say &LAYERS=... or something, Sure, various solutions are already in place, they're just waiting for being used :-) > What is the GetCapabilities URL? Or is it not set up > yet? GetCapabilities returns the catalogue and technical specifics. Find one on our MapServer main page: http://mapserver.flightgear.org/ Cheerio, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
From: Alex P. <ale...@ie...> - 2011-10-30 22:04:36
|
On Sun, Oct 30, 2011 at 12:38 PM, Martin Spott <Mar...@mg...> wrote: > Geoff McLane wrote: >> As you may know the Atlas project already has >> a GetMap application, linked with CURL to >> to do the http requests... written by Fred back in 2004, > > No, I didn't know. When I talked to Brian Schack about this topic, the > conversation somehow got lost (and I do feel guilty in some way ....). > As far as I can remember the biggest obstacle was set by Atlas's tile > schema being organized alongside FlightGear's Scenery tiling schema, > being slightly different from what WMS tile servers typically provide. > Actually I'm unable to afford the time for providing the introduction > into the logic behind WMS(-C) and related protocols, but there's plenty > to read at OSGeo and related projects (start at TileCache for example). > > BUT I'd be willing to set the tile server up - simply because I'm > convinced that this is "the right thing to do" about serving map > imagery from a server .... well, actually the entire infrastructure is > already in place, because I've been doing this sort of stuff for years, > I'd just have to compile the Atlas imagery into a suitable format. I looked into doing this a couple of years ago and got bogged down in the FGFS-specific assumptions throughout the Atlas pipeline. I came to the conclusion that the integration I had in mind would be ugly, but wasn't willing to take on the burden of forking. What is preventing us from converting the whole Atlas project to WMS, and dropping the old nomenclature? |
From: Geoff M. <ub...@ge...> - 2011-10-31 19:24:47
|
On Sun, 2011-10-30 at 19:38 +0000, Martin Spott wrote: > Geoff McLane wrote: > > > As you may know the Atlas project already has > > a GetMap application, linked with CURL to > > to do the http requests... written by Fred back in 2004, [snip] > http://mapserver.flightgear.org/ > > Cheerio, > Martin. Hi Martin, and others... I guess I was a little unclear about other WMS servers... What I wanted to say was nothing I found offered any particular advantages over what the current Map application produces using current fgdata BTG files, and OpenGL rendering... I was hoping your mapserver could eventually produce something more, like the airport and navaid overlays I mentioned... images with lots of 'features'... And thank you to all the others, who responded with ideas. Some of these were great, like Alex's idea of Atlas getting its map image directly from a WMS server... And the idea that terrasync could be used to download any missing fgdata areas... And reminders about other WMS servers like mapnik2, kde marble, QGIS, GDAL, etc, et al... Well, you are all welcome to negotiate with the Atlas maintainers (Brian), and produce and offer what ever code you are interested in ;=)) The ONLY thing I am interested in at this time is to use the presently moribund GetMap application, either as part of the Atlas suite, or separately, to produce other, different maps for use with Atlas, and the ZKV1000... And yes Martin, I had missed those bottom entries on mapserver giving the GetCapabilities URL... will check that out... And there is no problem using EPSG:900913, in that it is quite simple to add a bit of code to GetMap allowing the user to still input WSG84 (EPSG:4326), and present EPSG:900913 to mapserver... So, I had already previous adjust my WIN32 GetMap to accept a single (long) URL, as is, like what you gave, and use only that to get the image... But all I got was a mostly gray and white checkered tile, which I assume is the transparent color, with a small artifact on the top right... is that it? See - http://geoffair.org/tmp/tempfile.png The lat,lon you used 51.18,6.42 - 51.23,6.50 seems to be a 'residential' area, on Hutterbaum St, or have I really screwed up this Mercator to wsg84 conversion, or something... Look forward to your advice what I am doing wrong... remember I used the URL exactly as per your email - http://mapserver.flightgear.org/tc/?LAYERS=tarmac&TRANSPARENT=true&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&SRS=EPSG:900913&BBOX=714227.59136875,6653078.93995,724011.5309875,6662862.8795688&WIDTH=256&HEIGHT=256 And yes, while more and other ideas are always welcome, understand I am only trying to get maps, from a WMS, written to disk... a limited engagement at this time ;=(( Regards, Geoff. |
From: Martin S. <Mar...@mg...> - 2011-10-30 22:20:48
|
Hi Alex, Alex Perry wrote: > [...] What is > preventing us from converting the whole Atlas project to WMS, and > dropping the old nomenclature? I'm just guessing: Backwards compatibility with those users who'd like to use Atlas without being required to have a functional internet uplink ? The FSweekend show next month is typically one of those cases where this schema applies. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
From: Alex P. <ale...@ie...> - 2011-10-31 05:35:35
|
On Sun, Oct 30, 2011 at 3:20 PM, Martin Spott <Mar...@mg...> wrote: > Alex Perry wrote: >> [...] What is >> preventing us from converting the whole Atlas project to WMS, and >> dropping the old nomenclature? > > I'm just guessing: Backwards compatibility with those users who'd like > to use Atlas without being required to have a functional internet > uplink ? The FSweekend show next month is typically one of those cases > where this schema applies. I don't know what you're getting at. If Atlas knows how to get map tiles from a URL family in addition to the usual disk file name family, that doesn't affect offline use. Having said that, I wouldn't object to Atlas becoming a URL-only utility providing it still knows about file:// to avoid depending on a local webserver! If you're suggesting that the revised Map couldn't write to files any more, I think you're assuming a larger change to it than I had in mind. It might be nice to have a third utility AtlasTileServer which does provide a caching WMS webserver for Atlas and knows how to invoke Map to draw missing tiles at need. It could (1) keep a local Map instance busy between interactive requests, (2) recurse to a remote AtlasTileServer with its correspondingly better cache and higher throughput, and (3) kick TerraSync into fetching any missing Terrain tiles first. Ideally, Atlas and AtlasTileServer are happy keeping the GET request alive (and idle) while a tile is generated on the fly, and Atlas knows how to add the late-arriving tile into the framebuffer once it actually turns up. |
From: HB-GRAL <fli...@sa...> - 2011-10-31 12:04:48
|
Hi maybe it is also worth to have a look to (local) capabilities of - mapnik2 - kde marble Cheers, Yves Am 31.10.11 06:35, schrieb Alex Perry: > On Sun, Oct 30, 2011 at 3:20 PM, Martin Spott<Mar...@mg...> wrote: >> Alex Perry wrote: >>> [...] What is >>> preventing us from converting the whole Atlas project to WMS, and >>> dropping the old nomenclature? >> >> I'm just guessing: Backwards compatibility with those users who'd like >> to use Atlas without being required to have a functional internet >> uplink ? The FSweekend show next month is typically one of those cases >> where this schema applies. > > I don't know what you're getting at. If Atlas knows how to get map > tiles from a URL family in addition to the usual disk file name > family, that doesn't affect offline use. Having said that, I wouldn't > object to Atlas becoming a URL-only utility providing it still knows > about file:// to avoid depending on a local webserver! If you're > suggesting that the revised Map couldn't write to files any more, I > think you're assuming a larger change to it than I had in mind. > > It might be nice to have a third utility AtlasTileServer which does > provide a caching WMS webserver for Atlas and knows how to invoke Map > to draw missing tiles at need. It could (1) keep a local Map instance > busy between interactive requests, (2) recurse to a remote > AtlasTileServer with its correspondingly better cache and higher > throughput, and (3) kick TerraSync into fetching any missing Terrain > tiles first. Ideally, Atlas and AtlasTileServer are happy keeping the > GET request alive (and idle) while a tile is generated on the fly, and > Atlas knows how to add the late-arriving tile into the framebuffer > once it actually turns up. > > ------------------------------------------------------------------------------ > Get your Android app more play: Bring it to the BlackBerry PlayBook > in minutes. BlackBerry App World™ now supports Android™ Apps > for the BlackBerry® PlayBook™. Discover just how easy and simple > it is! http://p.sf.net/sfu/android-dev2dev > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > |
From: Martin S. <Mar...@mg...> - 2011-10-31 07:52:19
|
Hi Alex, Alex Perry wrote: > I don't know what you're getting at. If Atlas knows how to get map > tiles from a URL family in addition to the usual disk file name > family, that doesn't affect offline use. Indeed. I was just thinking out loudly about how Joe Average might recieve the requirement to run a local webserver/engine for use with Atlas if they don't want to pull the tiles from The Net. Anyhow, I confirm my offer to provide an "AtlasTileServer" - WMS/WMS-C, a TileCache, to be precise - at "sufficient" bandwidth and leave the rest to those who are familiar with the details of the Atlas application ;-) Best regards, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
From: Martin S. <Mar...@mg...> - 2011-10-31 14:06:57
|
Martin Spott wrote: > I'd just have to compile the Atlas imagery into a suitable format. Just as a side note: I'll issue a virtual bonus for removal of the requirement to have an (OpenGL-capable) $DISPLAY from Atlas' "Map" utility ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
From: Martin S. <Mar...@mg...> - 2011-10-31 21:15:35
|
Geoff McLane wrote: > I guess I was a little unclear about other > WMS servers... What I wanted to say was nothing > I found offered any particular advantages over > what the current Map application produces using > current fgdata BTG files, and OpenGL rendering... Well, the cause is pretty simple: As far as I was told there was no plan to support WMS in Atlas, therefore I didn't spend any time on this. Today I got my feet wet by building a set of Atlas map imagery, just in order to see if and how it works. Actually it worked better than expected, but there's still some work left - most notably to get the various tiles geo-referenced. > I was hoping your mapserver could eventually > produce something more, like the airport and > navaid overlays I mentioned... images with lots > of 'features'... As far as I understood Yves, he/we will be able to provide such feature quite soon. > But all I got was a mostly gray and white checkered > tile, which I assume is the transparent color, > with a small artifact on the top right... is > that it? See - > http://geoffair.org/tmp/tempfile.png > > The lat,lon you used 51.18,6.42 - 51.23,6.50 > seems to be a 'residential' area, on Hutterbaum St, > or have I really screwed up this Mercator to wsg84 > conversion, or something... This image shows a transparent map tile containing the tarmac at EDLN in its upper right corner, thus your assumption about lon/lat seems to be within range. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
From: Geoff M. <ub...@ge...> - 2011-11-02 18:20:10
|
Hi Martin, Thanks for the reply... Sorry to disturb you again. I know you are probably quite busy, some of which may be getting ready for FSWeekEnd - I will not be able to attend this year ;=(( - but I do not quite understand mapserver's WMS response... I send a URL with say a BBOX - &SRS=EPSG:900913 &BBOX=755972.40132839,6797404.6358777,\ 765756.34094714,6807188.5754964 That is exactly at a Resolution of 9783.93961875... and get a reply - [An error occurred: Current x value 755972.401328 is too far from tile corner x 753363.347055] It seems as if I MUST know the exact boundaries, the precise corners of an 'existing' tile, or something... Earlier I was getting an error like can not match resolution, until I started using exact resolution values from the capabilities xml... Maybe, as usual, I am doing something really stupid ;=(( The full text of this last run is here, with the URLS used, and various other 'debug' information, like the equivalent WSG84 values - http://geoffair.org/tmp/templog.txt This run was using LAYERS=customscene, but I have tried various layers listed in the capabilities xml, but always with the same result... x value too far... even though in some case also 'quite' close... Hope you can help... Regards, Geoff. PS: OT: Just discovered Evolution WILL fill in the dev list email address if I use [Reply All] instead of just [Reply]. One mystery solved ;=)) |