Re: [Flightgear-devel] Mapping Airspace
Am 21.09.11 07:59, schrieb Alex Perry: 12. ... who is missing from the list? I just decided to start with russian airspace, because of this one here: http://premier.gov.ru/eng/events/news/9704/ Cheers, Yves -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mapping Airspace
John Denker wrote: And here is a possibly-related question: what colormap are the Sectional Aeronautical Charts using, and how do I specify it? They show up in QGIS in beautiful natural color. In particular, in QGIS, if I change the colormap on one of those charts, there does not appear to be any way to change it back to the beautiful original colormap. The palettes are embedded in the GeoTIFF files, you most certainly want to convert these images into some suitable true colour format before doing any manipulations, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mapping Airspace
John Denker wrote: Here's another fun way of mapping airspace: You can get sectional charts in the form of .tif files from: http://www.aeronav.faa.gov/index.asp?xml=aeronav/applications/VFR/chartlist_sect [...] This is a low priority for me, because I am content to reproject all rasters to a common SRS using gdalwarp. That does everything I need it to do. BTW, as a quick script-fun-project I've reprojected these maps into WGS84, but as you can see from this QGIS screenshot: http://foxtrot.mgras.net/bitmap/Dallas-Ft_Worth_87_WGS84.png there's still a lot of work to be done for clipping off the legends, which, obviously, has to be performed _before_ re-projecting, before you'll be able to create a seamless map of the entire US. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mapping Airspace
Here's another fun way of mapping airspace: You can get sectional charts in the form of .tif files from: http://www.aeronav.faa.gov/index.asp?xml=aeronav/applications/VFR/chartlist_sect You can then read them into QGIS ... and then overlay them with whatever other information you want, perhaps from apt.dat and nav.dat and/or elsewhere. (Reading the same .tif file into GRASS doesn't work. GRASS tries and fails, with no error or warning messages. The resulting map has no pixels at all, according to d.histogram. So this is another reason to use QGIS.) On 09/21/2011 06:10 PM, J. Holden wrote: Admittedly I work with GRASS solely on the text-based side - rarely if ever touching the GUI Roger that. I, too, rely almost exclusively on the command-line interface to GRASS. I occasionally use the GUI to give me hints about what CLI commands I need to use. The stuff I need to do involves so many GRASS commands that I could not possibly remember them all, let alone do them reliably, so I use a script. I hope I didn't misinterpret what you're writing, and hopefully that was of some help. You definitely understood the questions (even though I now realize the questions were not entirely clear) ... and you have been very helpful. 3. You CAN do raster reprojection on the fly. However, your results won't be anywhere near as clean as a vector reprojection as a result of the different format type. Also, there are some rules - I believe the projection has to be in the current region of the location you're reprojecting to, and also the resolution must be sufficient in order to handle the map. Well, YMMV but I can't get the instance I'm running to do raster reprojection. It tries and fails. I have an example where there are two rasters in the same location, with slightly different projections, plus some vector data. If I switch projections in my project workspace, one raster or the other goes to all-white. The zoom to layer button zooms to the right place, but the image is still all-white. The vector data stays where it belongs, so that is working. This is a low priority for me, because I am content to reproject all rasters to a common SRS using gdalwarp. That does everything I need it to do. 1) it's probably easiest to continue to use d.his and then display the resulting map using the GRASS plugin - QGIS doesn't really have many (if any?) raster tools, while GRASS was created primarily to deal with raster features (and added vectors later). That sounds good, but I haven't figured out how to get a map /out/ of d.his. I think of d.his as a display function, not a map-calculation function. I don't know how to find the resulting map produced by d.his, not in any useful form anyway. And here is a possibly-related question: what colormap are the Sectional Aeronautical Charts using, and how do I specify it? They show up in QGIS in beautiful natural color. In particular, in QGIS, if I change the colormap on one of those charts, there does not appear to be any way to change it back to the beautiful original colormap. I assume there is some clever colormap that the QGIS backend knows about but the GUI does not. I mention this because I reckon I could solve several interesting problems by using this colormap, using r.mapcalc if necessary to format the pixels. This includes the drape operation, which produces very nice-looking results by taking the hue from one layer and the intensity from another. Or maybe somebody can write a r.calc.drape module. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mapping Airspace
On Fri, 23 Sep 2011, John Denker wrote: Here's another fun way of mapping airspace: You can get sectional charts in the form of .tif files from: http://www.aeronav.faa.gov/index.asp?xml=aeronav/applications/VFR/chartlist_sect John, do you know if they provide a version of that data that can be zoomed infinitely without pixelating? (ie. a vector based version of the same map) tnx! g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mapping Airspace
This is somewhat off-topic to FlightGear, so I apologize - but I respond to John Denker: Having looked over what you are trying to do, I strongly recommend using QGIS with the GRASS plugin. Very rarely do I use any of GRASS' built-in visualization programs - and very rarely do I use any of QGIS' built-in geospatial functions - but QGIS is the best program I've found to visualize GRASS data at the moment (with the possible, rare, exception of NVIZ). In fact, I believe the whole GRASS d.mon was rewritten as of GRASS 7 and now works differently (and hopefully better). I think most of the GRASS display functions were very, very old. Cheers John -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mapping Airspace
On Tue, 20 Sep 2011 22:59:11 -0700, Alex wrote in message CAEwz7jsynVp9izpjcfFs45Ez3cbTUV1YJnyArUnALaKzEcgG=w...@mail.gmail.com: To agree with Alan, but with some additional generalizations. On Tue, Sep 20, 2011 at 2:25 AM, Alan Teeder ajtee...@v-twin.org.uk wrote: When I ran the research flight simulator for a major aircraft manufacturer in the UK (many moons ago when we still had such an industry), we had a saying:- Ask 10 test pilots for their opinion, and you will get 10 different answers 1. IFR commercial pilot: airspace is completely irrelevant as they fly the clearance from ATC, initially filed by another airline individual who is not a pilot. 2. IFR general aviation pilot: airspace is only of interest on the ground when designing a clearance request that will be typed into the web terminal. 3. VFR commercial pilot: Almost irrelevant as tends to operate in areas without airspace restrictions or with full ATC coordination on an ad-hoc basis. 4. VFR cross country pilot: Interested in airspace, but usually just wanting to know where it is, to fly far around it. 5. VFR visiting pilot: Intensely interested in airspace, wants the simulator to help him learn not to accidentally bump into it. 6. VFR local pilot: Probably has it memorized anyway, owns the chart mostly to be compliant with the rules. 7. Antique / simple homebuilt pilot: Doesn't have radios or the like anyway, simply needs a few circles marked 'mode C veil'. 8. Military pilot: Doesn't use civilian charts. Could be fun to have the MTR details transcribed for simulating those fighters. 9. Shuttle pilot: I could ask if needed, but I suspect they count as [2] since they're in class A airspace until the final brick-like landing. 10. Aerobatic pilot: The boxes. And something on the simulator to be sarcastic when you accidentally leave the box. 11. RC pilot: No idea. Curt? 12. ... who is missing from the list? ..13. FPV pilot 14. Drone pilot (or operator (to open another coupla cans of ...)) From: HB-GRAL To improve our map resources with further data I started an experiment with free available airspace data. Actually this is far from being a good map and finished design, it is just a start to implement (unofficial!) airspace information: http://maptest.fgx.ch/navaid.html Lovely, keep up the good work. The comments above are intended to clarify and not discourage. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mapping Airspace
11: RC Pilot. Stays under 400' AGL and outside a 3 mile radius from any airport. Probably flying at a club site and doesn't care about air spaces. Has no way to estimate if he's over or under 400' AGL and probably is flying a plane that can climb 500' per second and hover at 2 clicks of throttle. Is annoyed when a VIP flies into the big airport 30 miles away and his club field is just barely inside the TFR radius and he can't even go out there and fly a paper airplane for several hours. 14: Drone Pilot. Still waiting for the official regulations in the USA (I think.) Realizing if manned aviation was just invented this week, the FAA would completely disallow it for safety reasons. In the USA you can do whatever you want in military airspace assuming you have proper permission to be there. We've flown at Schofield barracks in HI, in a navy operations area north of Oahu (entirely over water the entire flight including launch and recovery), at camp ripley (MN). Hopefully later this fall up in AK, etc. That seems to be the path of least resistance ... get permission to fly in military airspace and the FAA is entirely out of the picture. Or you can push through paperwork with the FAA to get a COA (certificate of authorization) which is permission to operate in a specific area at specific times with whatever specific other constraints the FAA wants to impose. When we were flying under a COA in the north pacific (1000nm north of Hawaii) we had to put a call out for any local traffic before launch and monitor some random frequency that FAA told us to monitor ... which was kind of dumb because how many Cessna's are going to be flying 1000nm away from the closest land? Of those, how many are going to be flying under 500' altitude? And of those, how many would be chatting on the random frequency the FAA picked for us? We are from the government and we are here to help! :-) Curt. On Wed, Sep 21, 2011 at 9:14 AM, Arnt Karlsen a...@c2i.net wrote: On Tue, 20 Sep 2011 22:59:11 -0700, Alex wrote in message CAEwz7jsynVp9izpjcfFs45Ez3cbTUV1YJnyArUnALaKzEcgG=w...@mail.gmail.com: To agree with Alan, but with some additional generalizations. On Tue, Sep 20, 2011 at 2:25 AM, Alan Teeder ajtee...@v-twin.org.uk wrote: When I ran the research flight simulator for a major aircraft manufacturer in the UK (many moons ago when we still had such an industry), we had a saying:- Ask 10 test pilots for their opinion, and you will get 10 different answers 1. IFR commercial pilot: airspace is completely irrelevant as they fly the clearance from ATC, initially filed by another airline individual who is not a pilot. 2. IFR general aviation pilot: airspace is only of interest on the ground when designing a clearance request that will be typed into the web terminal. 3. VFR commercial pilot: Almost irrelevant as tends to operate in areas without airspace restrictions or with full ATC coordination on an ad-hoc basis. 4. VFR cross country pilot: Interested in airspace, but usually just wanting to know where it is, to fly far around it. 5. VFR visiting pilot: Intensely interested in airspace, wants the simulator to help him learn not to accidentally bump into it. 6. VFR local pilot: Probably has it memorized anyway, owns the chart mostly to be compliant with the rules. 7. Antique / simple homebuilt pilot: Doesn't have radios or the like anyway, simply needs a few circles marked 'mode C veil'. 8. Military pilot: Doesn't use civilian charts. Could be fun to have the MTR details transcribed for simulating those fighters. 9. Shuttle pilot: I could ask if needed, but I suspect they count as [2] since they're in class A airspace until the final brick-like landing. 10. Aerobatic pilot: The boxes. And something on the simulator to be sarcastic when you accidentally leave the box. 11. RC pilot: No idea. Curt? 12. ... who is missing from the list? ..13. FPV pilot 14. Drone pilot (or operator (to open another coupla cans of ...)) From: HB-GRAL To improve our map resources with further data I started an experiment with free available airspace data. Actually this is far from being a good map and finished design, it is just a start to implement (unofficial!) airspace information: http://maptest.fgx.ch/navaid.html Lovely, keep up the good work. The comments above are intended to clarify and not discourage. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net
Re: [Flightgear-devel] Mapping Airspace
On Wed, 21 Sep 2011, Curtis Olson wrote: 11: RC Pilot. Stays under 400' AGL and outside a 3 mile radius from any airport. Probably flying at a club site and doesn't care about air spaces. Has no way to estimate if he's over or under 400' AGL and probably is flying a plane that can climb 500' per second and hover at 2 clicks of throttle. Is annoyed when a VIP flies into the big airport 30 miles away and his club field is just barely inside the TFR radius and he can't even go out there and fly a paper airplane for several hours. 11a: RC Pilot. Flies out of backyard whenever the hell he wants, regularly sees how high he can get using a 2lb electric Slow-Stik and a fancy altimeter downlink. Doesn't worry about how tiny a 40 model is at 2000ft, has FPV goggles for that. *laughs* g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mapping Airspace
On Wed, Sep 21, 2011 at 11:12 AM, Gene Buckle wrote: On Wed, 21 Sep 2011, Curtis Olson wrote: 11: RC Pilot. Stays under 400' AGL and outside a 3 mile radius from any airport. Probably flying at a club site and doesn't care about air spaces. Has no way to estimate if he's over or under 400' AGL and probably is flying a plane that can climb 500' per second and hover at 2 clicks of throttle. Is annoyed when a VIP flies into the big airport 30 miles away and his club field is just barely inside the TFR radius and he can't even go out there and fly a paper airplane for several hours. 11a: RC Pilot. Flies out of backyard whenever the hell he wants, regularly sees how high he can get using a 2lb electric Slow-Stik and a fancy altimeter downlink. Doesn't worry about how tiny a 40 model is at 2000ft, has FPV goggles for that. 11b: Smart RC Pilot: Doesn't post publicly about his misadventures, and has never been above 400' or anywhere close to inside or above the clouds. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mapping Airspace
On Wed, 21 Sep 2011, Curtis Olson wrote: On Wed, Sep 21, 2011 at 11:12 AM, Gene Buckle wrote: On Wed, 21 Sep 2011, Curtis Olson wrote: 11: RC Pilot. Stays under 400' AGL and outside a 3 mile radius from any airport. Probably flying at a club site and doesn't care about air spaces. Has no way to estimate if he's over or under 400' AGL and probably is flying a plane that can climb 500' per second and hover at 2 clicks of throttle. Is annoyed when a VIP flies into the big airport 30 miles away and his club field is just barely inside the TFR radius and he can't even go out there and fly a paper airplane for several hours. 11a: RC Pilot. Flies out of backyard whenever the hell he wants, regularly sees how high he can get using a 2lb electric Slow-Stik and a fancy altimeter downlink. Doesn't worry about how tiny a 40 model is at 2000ft, has FPV goggles for that. 11b: Smart RC Pilot: Doesn't post publicly about his misadventures, and has never been above 400' or anywhere close to inside or above the clouds. *my* misadventures? Oh no sir, not mine. There's this awesome FPV forum that discusses such things(there's a video of a guy doing some _insane_ things with a flying wing in and around Rio) g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mapping Airspace
On 09/20/2011 07:08 PM, J. Holden wrote: This is somewhat off-topic to FlightGear, so I apologize - but I respond to John Denker: Having looked over what you are trying to do, I strongly recommend using QGIS with the GRASS plugin. Very rarely do I use any of GRASS' built-in visualization programs - and very rarely do I use any of QGIS' built-in geospatial functions - but QGIS is the best program I've found to visualize GRASS data at the moment (with the possible, rare, exception of NVIZ). In fact, I believe the whole GRASS d.mon was rewritten as of GRASS 7 and now works differently (and hopefully better). I think most of the GRASS display functions were very, very old. Yes, that helps. Thanks for the clue. One nice thing about GRASS is that it is very modular. In particular its backend computational features are independent of its frontend visualization features. The QGIS frontend graphics are orders of magnitude faster than the GRASS frontend graphics. Also QGIS has a feature called recompute CRS on the fly that simplifies a lot of things. It's nice to see a little bit of sanity in the world. Here are some questions you might be able to help me with, if you would be so kind. Off-list answers would be fine, although I suspect I'm not the only person who is interested: 1) GRASS has a drape feature implemented by d.his that sets the intensity from one raster and the hue from from another, which is a very nice way of combining slope information and elevation information into one image. It's not obvious how to achieve the drape effect in QGIS ... with or without involving GRASS. What's the trick? 2) GRASS has a catlist feature implemented by d.rast that makes it easy to display only a certain range of values, e.g. everything from 3000 feet on up. This is particularly slick in conjunction with item (1) above. I can always do this with r.mapcalc, but I was wondering if there might be a convenient way to do it on-the-fly. 3) I suspect that doing reprojections on the the fly only works for vector data. I tried it with raster data, expecting to see either a resulting image or an error message, but saw neither. Is there something I'm missing? 4) When defining a colormap, there does not appear to be any way of controlling transparency on a level-by-level basis. Am I overlooking something, or is this an actual limitation? -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mapping Airspace
Am 21.09.11 21:43, schrieb John Denker: 3) I suspect that doing reprojections on the the fly only works for vector data. I tried it with raster data, expecting to see either a resulting image or an error message, but saw neither. Is there something I'm missing? It works also for raster on the fly, but you probably have to zoom to the current extension again. Cheers, Yves -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mapping Airspace
Am 21.09.11 21:43, schrieb John Denker: 4) When defining a colormap, there does not appear to be any way of controlling transparency on a level-by-level basis. Am I overlooking something, or is this an actual limitation? Maybe I miss something but you can control transparency for every level in layer properties. Cheers, Yves -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mapping Airspace
John:
Admittedly I work with GRASS solely on the text-based side - rarely if ever
touching the GUI - but hopefully I can help:
1) To be honest, it's probably easiest to continue to use d.his and then
display the resulting map using the GRASS plugin - QGIS doesn't really have
many (if any?) raster tools, while GRASS was created primarily to deal with
raster features (and added vectors later).
2) I believe r.mapcalc is the way to do this on the fly - not sure what you are
asking, because I'm sure d.rast calls this on the fly when you go to display
the image?
You can always do something like
r.mapcalc {$output_map} = if({$input_map[0,0]} = 3000, {$input_map[0,0]},
null())
so it doesn't stop the processing.
3. You CAN do raster reprojection on the fly. However, your results won't be
anywhere near as clean as a vector reprojection as a result of the different
format type. Also, there are some rules - I believe the projection has to be in
the current region of the location you're reprojecting to, and also the
resolution must be sufficient in order to handle the map.
The r.proj part of the manual has two good procedures for doing so:
http://grass.osgeo.org/grass64/manuals/html64_user/r.proj.html
(old version but should still be okay)
4) I think it's an actual limitation - I am assuming, for a categorical map,
you would like say all cats 10 to have a transparency but all cats = 10 to
not have a transparency? I'm not sure how to do this, if this exists - I'd just
use r.mapcalc and display two different layers.
I hope I didn't misinterpret what you're writing, and hopefully that was of
some help.
Cheers
John
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mapping Airspace
On 09/19/2011 04:07 PM, HB-GRAL wrote: To improve our map resources with further data I started an experiment with free available airspace data. Actually this is far from being a good map and finished design, it is just a start to implement (unofficial!) airspace information: http://maptest.fgx.ch/navaid.html I need probably some advice from real pilots around here for what is useful to map for FlightGear airspace, and how this should be displayed. I think I am aware of regular ICAO graphics definitions etc. But I dont want to design well known (and also free available) maps, I just want to develop a design as a overview and some really necessary items i.e. for learning the basics or whatelse. There is no RFC for what I am doing here, I am just playing around with data and an new Mapnik Server and ask for discussion and contribution. (Notice, my new signature since I send this links to the list and elsewhere: Please do not use any of this material for real navigation! NEVER. Do only use this to help developing and improving the design of my maps ;-). A few remarks: 1) Real pilots are concerned about airspace, but they are also concerned about terrain and obstructions. Also weather and winds aloft. You don't want to follow the example of Cory Lidle and his instructor. Their flight path was compressed by airspace and they ended up flying into the side of a high-rise apartment building. Violating the airspace would have been a better choice. 2) It is good to provide disclaimers, and people should take those seriously. However: 2a) Pilots are trained to cross-check everything, and never rely on a single source of information. 2b) People *are* going to use whatever maps they can get their hands on -- in conjunction with other information -- to help with real-world flight planning and training. For example, I commonly use FlightGear to familiarize myself with the IFR approach procedures and other details before flying into an unfamiliar airport. Of course I crosscheck the apt.dat description of the airport against satellite photos et cetera. Discrepancies abound, as previously described. 3) Interactive computerized maps offer some treeemendous advantages. For one thing, the ability to turn layers on and off is very powerful. The total amount of detail that is /sometimes/ useful is more than can be shown on any one map. Here's a rough scenario, aka use case: 1) Turn on airport names (not just 4-letter identifiers) because I have not memorized every identifier in the world. 2) Sketch a rough route. 3) Turn off the names, to declutter the map. 4) Turn on navaids, intersections, and fixes, so as to facilitate defining the route in terms that can be used on an ATC flight plan. 5) Turn off everything but the route and the terrain, to see what sort of obstructions there are. 6) Apply safety margins required by regulations. Apply additional personal margins. 7) Revise the route to get around the worst of the obstructions. 8) Cross-check against the VFR sectional, IFR enroute chart, et cetera. 9) Go back to step 4 and iterate. 10) Turn on weather and winds aloft. *) et cetera. Note that I have a tool that not only highlights the route centerline, but also the /corridor/ extending some distance on either side. For example, a half-width of 4 nm is relevant to FAR 91.177. http://www.av8n.com/fly/grass-intro.htm#fig-colored-fix-pass These tools are painfully difficult to use. The only thing that would be worse would be not having them. Flight planning is relatively easy if you stick to IFR airways, but sometimes in mountainous regions (e.g. Alaska among many others) this can lead to insanely high MEAs (minimum enroute altitudes). As soon as you start planning an off-airways flight, trying to do it just by penciling in lines on a chart is exceedingly laborious and error-prone. So, you have to decide what you want to do. You could go for a map that is merely pretty to look at ... or you could go for a map that is actually useful. One more thing: You don't want to go too far with the disclaimers. Lives are at stake, and /not/ providing information can be just as much of a problem as providing not-quite-perfect information. CFIT i.e. controlled flight into terrain makes a large contribution to the fatal accident rate. Sometimes a contributing factor is compression between airspace or weather above and terrain below ... but sometimes it just comes down to bad planning and really bad luck. Providing something that helps with this would be a Good Thing. Again: It doesn't have to be perfect. Note that the FAA provides (via contractors) a service that will prepare a computerized flight plan for you. There are scenarios where you can file such a flight plan, get cleared As Filed, and fly it as cleared ... and fly right into the side of a mountain. Hence the need for cross-checking. This
Re: [Flightgear-devel] Mapping Airspace
When I ran the research flight simulator for a major aircraft manufacturer in the UK (many moons ago when we still had such an industry), we had a saying:- Ask 10 test pilots for their opinion, and you will get 10 different answers The same will apply here. Someone who is interested in commercial airliners will have a different view from a light aircraft pilot who wishes to hone his IFR techniques, or from another light aircraft pilot who want to know how to fly VFR in a congested area, or from a military pilot. etc. etc. etc. The gamers probably don´t understand what you are asking. They just need a pretty map so that they can find the way back to an airfield. Keep up the work, it looks like a very good start. I would suggest that you keep as close as possible to a common format, either one that is available in printed form, or as represented in a modern glass cockpit. As most users are limited to small PC screens keep it uncluttered, or allow information layers to be turned on and off. Alan -Original Message- From: HB-GRAL Sent: Tuesday, September 20, 2011 12:07 AM To: FlightGear developers discussions Subject: [Flightgear-devel] Mapping Airspace Hi all To improve our map resources with further data I started an experiment with free available airspace data. Actually this is far from being a good map and finished design, it is just a start to implement (unofficial!) airspace information: http://maptest.fgx.ch/navaid.html I need probably some advice from real pilots around here for what is useful to map for FlightGear airspace, and how this should be displayed. I think I am aware of regular ICAO graphics definitions etc. But I dont want to design well known (and also free available) maps, I just want to develop a design as a overview and some really necessary items i.e. for learning the basics or whatelse. There is no RFC for what I am doing here, I am just playing around with data and an new Mapnik Server and ask for discussion and contribution. (Notice, my new signature since I send this links to the list and elsewhere: Please do not use any of this material for real navigation! NEVER. Do only use this to help developing and improving the design of my maps ;-). Cheers, Yves -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mapping Airspace
To agree with Alan, but with some additional generalizations. On Tue, Sep 20, 2011 at 2:25 AM, Alan Teeder ajtee...@v-twin.org.uk wrote: When I ran the research flight simulator for a major aircraft manufacturer in the UK (many moons ago when we still had such an industry), we had a saying:- Ask 10 test pilots for their opinion, and you will get 10 different answers 1. IFR commercial pilot: airspace is completely irrelevant as they fly the clearance from ATC, initially filed by another airline individual who is not a pilot. 2. IFR general aviation pilot: airspace is only of interest on the ground when designing a clearance request that will be typed into the web terminal. 3. VFR commercial pilot: Almost irrelevant as tends to operate in areas without airspace restrictions or with full ATC coordination on an ad-hoc basis. 4. VFR cross country pilot: Interested in airspace, but usually just wanting to know where it is, to fly far around it. 5. VFR visiting pilot: Intensely interested in airspace, wants the simulator to help him learn not to accidentally bump into it. 6. VFR local pilot: Probably has it memorized anyway, owns the chart mostly to be compliant with the rules. 7. Antique / simple homebuilt pilot: Doesn't have radios or the like anyway, simply needs a few circles marked 'mode C veil'. 8. Military pilot: Doesn't use civilian charts. Could be fun to have the MTR details transcribed for simulating those fighters. 9. Shuttle pilot: I could ask if needed, but I suspect they count as [2] since they're in class A airspace until the final brick-like landing. 10. Aerobatic pilot: The boxes. And something on the simulator to be sarcastic when you accidentally leave the box. 11. RC pilot: No idea. Curt? 12. ... who is missing from the list? From: HB-GRAL To improve our map resources with further data I started an experiment with free available airspace data. Actually this is far from being a good map and finished design, it is just a start to implement (unofficial!) airspace information: http://maptest.fgx.ch/navaid.html Lovely, keep up the good work. The comments above are intended to clarify and not discourage. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Mapping Airspace
Hi all To improve our map resources with further data I started an experiment with free available airspace data. Actually this is far from being a good map and finished design, it is just a start to implement (unofficial!) airspace information: http://maptest.fgx.ch/navaid.html I need probably some advice from real pilots around here for what is useful to map for FlightGear airspace, and how this should be displayed. I think I am aware of regular ICAO graphics definitions etc. But I dont want to design well known (and also free available) maps, I just want to develop a design as a overview and some really necessary items i.e. for learning the basics or whatelse. There is no RFC for what I am doing here, I am just playing around with data and an new Mapnik Server and ask for discussion and contribution. (Notice, my new signature since I send this links to the list and elsewhere: Please do not use any of this material for real navigation! NEVER. Do only use this to help developing and improving the design of my maps ;-). Cheers, Yves -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
