AVIATIONTOOLBOX: How do you like your maps stitched?

[Kyler Laird]

[As I mentioned earlier, I'm going to use this "AVIATIONTOOLBOX" keyword
so that those who'd like to keep up with these projects can do so easily
without the annoyance of using a mailing list and others can easily skip/
killfile them. If you have better suggestions, please feel free to send
them to me directly or hash it out here. I don't plan to always post to
comp.infosystems.gis but I thought this topic would be good to address
there.]

Recently I've been working a lot on manipulating the FAA sectionals I
purchased.
http://aviationtoolbox.org/raw_data/FAA_sectionals/
I've been amazed by the hundreds of people who have downloaded this data.
There's apparently some interest in it so I'd like to solicit input on
some of the projects I'm pursuing with the data.

Right now I'm working on breaking up the maps into easily-used subimages.
I do this (using GDAL) by hacking off all of the stuff around the maps,
converting them to RGB, warping them to match the Wichita sectional, and
then cutting them into chunks.

The tricky part is that the maps overlap. For the North and South sides,
this usually isn't a problem. Different regions however can depict the
same geographic area quite differently. Choosing how to display these
areas of overlap isn't obvious to me.

I've made a couple of example attempts. The first
http://aviationtoolbox.org/tmp/chunk_furthest.jpg
simply chooses whatever pixel was furthest from the nearest edge in the
original map. That does a fairly good job, but there is some information
that is just lost - it's near the edge on both maps, so it isn't shown at
all. (See the "PINONCANYON0 MSL" area on Denver/Wichita border.)

The next
http://aviationtoolbox.org/tmp/chunk-blended.jpg
is a bit more complicated. The weighting of the pixels fades toward the
edges so that the maps blend into each other. Sometimes this looks much
better to me, but sometimes it looks like I'm trying to read in
turbulence. (See the Dalhart airport/VOR.) The big advantage is that no
information is lost.

Another possibility I'm going to pursue is prioritizing the colors so
that some colors (blue, maroon, black, ...) take complete priority over
more "backgroundish" colors. That could make for some strange looking
airports (See Miller dear Dalhart.) but I think it might look "cleaner"
without information loss.

So...anyone have strong feelings about how this should be done?

Thank you.

--kyler

[R. Hubbell]

On Sat, 29 Nov 2003 22:09:24 GMT
Kyler Laird > wrote:

> [As I mentioned earlier, I'm going to use this "AVIATIONTOOLBOX" keyword
> so that those who'd like to keep up with these projects can do so easily
> without the annoyance of using a mailing list and others can easily skip/
> killfile them. If you have better suggestions, please feel free to send
> them to me directly or hash it out here. I don't plan to always post to
> comp.infosystems.gis but I thought this topic would be good to address
> there.]
>
> Recently I've been working a lot on manipulating the FAA sectionals I
> purchased.
> http://aviationtoolbox.org/raw_data/FAA_sectionals/
> I've been amazed by the hundreds of people who have downloaded this data.


How do you and others mean to use these charts? Laptop in the plane?
Just for reference during flight planning? Print them and take them along?



R. Hubbell


> There's apparently some interest in it so I'd like to solicit input on
> some of the projects I'm pursuing with the data.
>
> Right now I'm working on breaking up the maps into easily-used subimages.
> I do this (using GDAL) by hacking off all of the stuff around the maps,
> converting them to RGB, warping them to match the Wichita sectional, and
> then cutting them into chunks.
>
> The tricky part is that the maps overlap. For the North and South sides,
> this usually isn't a problem. Different regions however can depict the
> same geographic area quite differently. Choosing how to display these
> areas of overlap isn't obvious to me.
>
> I've made a couple of example attempts. The first
> http://aviationtoolbox.org/tmp/chunk_furthest.jpg
> simply chooses whatever pixel was furthest from the nearest edge in the
> original map. That does a fairly good job, but there is some information
> that is just lost - it's near the edge on both maps, so it isn't shown at
> all. (See the "PINONCANYON0 MSL" area on Denver/Wichita border.)
>
> The next
> http://aviationtoolbox.org/tmp/chunk-blended.jpg
> is a bit more complicated. The weighting of the pixels fades toward the
> edges so that the maps blend into each other. Sometimes this looks much
> better to me, but sometimes it looks like I'm trying to read in
> turbulence. (See the Dalhart airport/VOR.) The big advantage is that no
> information is lost.
>
> Another possibility I'm going to pursue is prioritizing the colors so
> that some colors (blue, maroon, black, ...) take complete priority over
> more "backgroundish" colors. That could make for some strange looking
> airports (See Miller dear Dalhart.) but I think it might look "cleaner"
> without information loss.
>
> So...anyone have strong feelings about how this should be done?
>
> Thank you.
>
> --kyler

[Kyler Laird]

"R. Hubbell" > writes:

>How do you and others mean to use these charts? Laptop in the plane?
>Just for reference during flight planning? Print them and take them along?

Yes.

I'm mostly trying to make the data easily acessible so that others can
be creative. I think they'll be used in ways I haven't even considered.
Already I know of one person using them for flight planning, in-flight
moving map display, and tracking search and rescue operations.

--kyler

[R. Hubbell]

On Sun, 30 Nov 2003 02:09:26 GMT
Kyler Laird > wrote:

> "R. Hubbell" > writes:
>
> >How do you and others mean to use these charts? Laptop in the plane?
> >Just for reference during flight planning? Print them and take them along?
>
> Yes.
>
> I'm mostly trying to make the data easily acessible so that others can
> be creative. I think they'll be used in ways I haven't even considered.
> Already I know of one person using them for flight planning, in-flight
> moving map display, and tracking search and rescue operations.

Well I have to say I'm not sure how they could be used as a moving map.
Wouldn't they need to be vector graphics with the some reference?
Or is it possible to create geo references and plot courses and
positions?

I guess I'm thinking out loud but if you know it'd be great to hear how
they are being used. i.e. the technical side
It's really amazing how clear the images are

R. Hubbell


>
> --kyler

[Kyler Laird]

"R. Hubbell" > writes:

>Well I have to say I'm not sure how they could be used as a moving map.
>Wouldn't they need to be vector graphics with the some reference?

No, raster graphics are plenty fine for moving maps. Sure, there
are some disadvantages, but since the sectional charts seem to be
maintained in hard copy, I don't expect much beyond raster
graphics soon.

('course if you want to make your own vector graphics, the data is
available.)

>Or is it possible to create geo references and plot courses and
>positions?

They're already GeoTIFFs.

--kyler

[Tom Jackson]

I've downloaded the sectionals, and have brought them into Oziexplorer
moving map program ($75 download.) Also downloaded waypoints from one of
several aviation waypoint generators and imported them into Ozi. After
geo-referencing the map files, the waypoints line-up over the airports/vor's
etc., so one can then create routes.

So far, I haven't used it in the plane, but used it in the car and it seemed
to work fine.

Many thanks to Kyler.

"Kyler Laird" > wrote in message
...
> "R. Hubbell" > writes:
>
> >Well I have to say I'm not sure how they could be used as a moving map.
> >Wouldn't they need to be vector graphics with the some reference?
>
> No, raster graphics are plenty fine for moving maps. Sure, there
> are some disadvantages, but since the sectional charts seem to be
> maintained in hard copy, I don't expect much beyond raster
> graphics soon.
>
> ('course if you want to make your own vector graphics, the data is
> available.)
>
> >Or is it possible to create geo references and plot courses and
> >positions?
>
> They're already GeoTIFFs.
>
> --kyler

[Kyler Laird]

"Tom Jackson" > writes:

>I've downloaded the sectionals, and have brought them into Oziexplorer
>moving map program ($75 download.) Also downloaded waypoints from one of
>several aviation waypoint generators and imported them into Ozi. After
>geo-referencing the map files, the waypoints line-up over the airports/vor's
>etc., so one can then create routes.

What do you mean exactly by "After geo-referencing the map files"? They're
already georeferenced. Is there a format problem/incompatibility?

>So far, I haven't used it in the plane, but used it in the car and it seemed
>to work fine.

Great! I'm looking forward to doing something useful with them personally
so I especially appreciate hearing that they're working for others.

>Many thanks to Kyler.

You're quite welcome.

Thank you for the report.

--kyler

[R. Hubbell]

On Sun, 30 Nov 2003 04:18:49 GMT
Kyler Laird > wrote:

> "R. Hubbell" > writes:
>
> >Well I have to say I'm not sure how they could be used as a moving map.
> >Wouldn't they need to be vector graphics with the some reference?
>
> No, raster graphics are plenty fine for moving maps. Sure, there
> are some disadvantages, but since the sectional charts seem to be
> maintained in hard copy, I don't expect much beyond raster
> graphics soon.


Must be a ton of work to maintain and update them.

>
> ('course if you want to make your own vector graphics, the data is
> available.)
>
> >Or is it possible to create geo references and plot courses and
> >positions?
>
> They're already GeoTIFFs.


There's the magic word. There are plenty of programs and libraries (of
the software kind) for manipulating these files. If you had mentioned
that they were geoTiffs already I must have missed it.


R. Hubbell

>
> --kyler

[R. Hubbell]

On Sun, 30 Nov 2003 02:09:26 GMT
Kyler Laird > wrote:

> "R. Hubbell" > writes:
>
> >How do you and others mean to use these charts? Laptop in the plane?
> >Just for reference during flight planning? Print them and take them along?
>
> Yes.
>
> I'm mostly trying to make the data easily acessible so that others can
> be creative. I think they'll be used in ways I haven't even considered.
> Already I know of one person using them for flight planning, in-flight
> moving map display, and tracking search and rescue operations.


FYI, this site has some good tools for wrangling geoTiff. I saw NT, linux,
solaris and Mac binaries on their ftp site too.

http://remotesensing.org/geotiff/geotiff.html



R. Hubbell


>
> --kyler

[Tom Jackson]

Well, maybe my terminology is inaccurate, but what I meant to say was, I
load, and calibrate the map image. Basically, I load the map projection
information into the program (i.e., Lambert Conformal Conic, with the
appropriate lat/lon info.) I got this information from one of the HTML files
related to the specific map TIFF.

"Kyler Laird" > wrote in message
...
> "Tom Jackson" > writes:
>
> >I've downloaded the sectionals, and have brought them into Oziexplorer
> >moving map program ($75 download.) Also downloaded waypoints from one of
> >several aviation waypoint generators and imported them into Ozi. After
> >geo-referencing the map files, the waypoints line-up over the
airports/vor's
> >etc., so one can then create routes.
>
> What do you mean exactly by "After geo-referencing the map files"?
They're
> already georeferenced. Is there a format problem/incompatibility?
>
> >So far, I haven't used it in the plane, but used it in the car and it
seemed
> >to work fine.
>
> Great! I'm looking forward to doing something useful with them personally
> so I especially appreciate hearing that they're working for others.
>
> >Many thanks to Kyler.
>
> You're quite welcome.
>
> Thank you for the report.
>
> --kyler

[Kyler Laird]

"Tom Jackson" > writes:

>> What do you mean exactly by "After geo-referencing the map files"?

>Well, maybe my terminology is inaccurate, but what I meant to say was, I
>load, and calibrate the map image.

Nope, your terminology is dead on.

>Basically, I load the map projection
>information into the program (i.e., Lambert Conformal Conic, with the
>appropriate lat/lon info.) I got this information from one of the HTML files
>related to the specific map TIFF.

Stop doing that! The sectionals are already GeoTIFFs. The FAA has already
done all of that work for us. (They guarantee 2 pixels RMS error, but I've
found distortions much greater than that.)

I'm also working on making more easily-digested chunks of data. If you're
in the mood to burn some time and bandwidth, you can watch my progress.
http://aviationtoolbox.org/munge/mosaic.cgi
Just change the extension to ".tif" on any of the images if you want a 5000
by 5000 uncompressed GeoTIFF.

(I need to tweak my edge-detection algorithm. When I do, I'll clear those
images and start over but you're welcome to try it anyway.)

--kyler

[Tom Jackson]

Maybe I'm missing something -- I'll quickly walk you through what I do in
Oziexlporer:
After launching Oziexplorer, I go to the "file" menu, and select "load and
calibrate map image"
This loads the image, but requires that I supply additional data in order to
calibrate the image.

There is an additional menu option to "import map", however, GeoTIFF isn't
an option.

The help screens indicate the following:
*******************help text*****************************
Geotiff
OziExplorer can extract the georeference information from Geotiff files but
it only knows how to decode the information if it is from a known source. At
this stage only the georeference information in the USA USGS DRG Geotiffs
can be decoded.

The ability to decode other sources of georeference information in Geotiff
files will be added on an as need basis where it is possible to do so.


Converting Geotiff Image Files

Some Geotiff Image files are in the 24 bit color format. OziExplorer can
read 24 bit color TIFF files but must load them fully into RAM instead of
paging them from disk as it does with 8 bit color TIFF mages. For large
images this requires a lot of RAM.

If you convert these files to 8 bit color the Geotiff georeference
information is lost.

This document describes a technique to save the georeference information and
to then put it back into the file.

You need

Software to convert the Geotiff image from 24 bit to 8 bit color. Paint Shop
Pro (www.jasc.com) works well.

The Tiff Utilities available from the Utilities section of the OziExplorer
web site (www.oziexplorer.com).

**************end of help text********************

Perhaps the developer of Oziexplorer needs to add these types of files to
its list of "known" types. I will e-mail them.


"Kyler Laird" > wrote in message
...
> "Tom Jackson" > writes:
>
> >> What do you mean exactly by "After geo-referencing the map files"?
>
> >Well, maybe my terminology is inaccurate, but what I meant to say was, I
> >load, and calibrate the map image.
>
> Nope, your terminology is dead on.
>
> >Basically, I load the map projection
> >information into the program (i.e., Lambert Conformal Conic, with the
> >appropriate lat/lon info.) I got this information from one of the HTML
files
> >related to the specific map TIFF.
>
> Stop doing that! The sectionals are already GeoTIFFs. The FAA has
already
> done all of that work for us. (They guarantee 2 pixels RMS error, but
I've
> found distortions much greater than that.)
>
> I'm also working on making more easily-digested chunks of data. If you're
> in the mood to burn some time and bandwidth, you can watch my progress.
> http://aviationtoolbox.org/munge/mosaic.cgi
> Just change the extension to ".tif" on any of the images if you want a
5000
> by 5000 uncompressed GeoTIFF.
>
> (I need to tweak my edge-detection algorithm. When I do, I'll clear those
> images and start over but you're welcome to try it anyway.)
>
> --kyler

[Kyler Laird]

"Tom Jackson" > writes:

>Maybe I'm missing something -- I'll quickly walk you through what I do in
>Oziexlporer:
>After launching Oziexplorer, I go to the "file" menu, and select "load and
>calibrate map image"
>This loads the image, but requires that I supply additional data in order to
>calibrate the image.

It doesn't sound like you're using a TIFF.

>There is an additional menu option to "import map", however, GeoTIFF isn't
>an option.

Is "TIFF" an option? A GeoTIFF is just a regular TIFF with some standard
tagged data.

>OziExplorer can extract the georeference information from Geotiff files but
>it only knows how to decode the information if it is from a known source. At
>this stage only the georeference information in the USA USGS DRG Geotiffs
>can be decoded.

Oh...hmmm...that's a strange limitation.

>The ability to decode other sources of georeference information in Geotiff
>files will be added on an as need basis where it is possible to do so.

O.k., so OziExplorer is kinda dumb right now. Looks like you get to do it
manually for awhile.

>Converting Geotiff Image Files

>Some Geotiff Image files are in the 24 bit color format. OziExplorer can
>read 24 bit color TIFF files but must load them fully into RAM instead of
>paging them from disk as it does with 8 bit color TIFF mages. For large
>images this requires a lot of RAM.

The sectional maps from the FAA are 8-bit color (palette). I convert them
to 24-bit (RGB) when I mask them. The chunks I build are 24-bit.

>If you convert these files to 8 bit color the Geotiff georeference
>information is lost.

This is just another limitation of OziExplorer. Changing the pixel
representation has little to do with the ability to hold GeoTIFF data.

I'm planning on making 8-bit versions available but it's easier to
manipulate (warp/scale/blend/...) the data without mangling it in 24-bit
mode. My preference is to wait until the last step to create the 8-bit
images.

>Software to convert the Geotiff image from 24 bit to 8 bit color. Paint Shop
>Pro (www.jasc.com) works well.

Oh, well sure. *That* will destroy the GeoTIFF data.

>Perhaps the developer of Oziexplorer needs to add these types of files to
>its list of "known" types. I will e-mail them.

Good luck. I'm sorry I made comments assuming that OziExplorer would
deal with GeoTIFFs sensibly.

--kyler

[Tom Jackson]

Please see below from the developer of Oziexplorer - they fixed the software
after I pointed them to your data. It now works amazingly well!
**************************************
Hi Tom,

I released a new version of OziExplorer today which should import your FAA
sectional maps without intervention. Use the Import "All DRG maps on a CD or
in a Folder" option.

Regards
**************************************

"Kyler Laird" > wrote in message
...
> "Tom Jackson" > writes:
>
> >Maybe I'm missing something -- I'll quickly walk you through what I do in
> >Oziexlporer:
> >After launching Oziexplorer, I go to the "file" menu, and select "load
and
> >calibrate map image"
> >This loads the image, but requires that I supply additional data in order
to
> >calibrate the image.
>
> It doesn't sound like you're using a TIFF.
>
> >There is an additional menu option to "import map", however, GeoTIFF
isn't
> >an option.
>
> Is "TIFF" an option? A GeoTIFF is just a regular TIFF with some standard
> tagged data.
>
> >OziExplorer can extract the georeference information from Geotiff files
but
> >it only knows how to decode the information if it is from a known source.
At
> >this stage only the georeference information in the USA USGS DRG Geotiffs
> >can be decoded.
>
> Oh...hmmm...that's a strange limitation.
>
> >The ability to decode other sources of georeference information in
Geotiff
> >files will be added on an as need basis where it is possible to do so.
>
> O.k., so OziExplorer is kinda dumb right now. Looks like you get to do it
> manually for awhile.
>
> >Converting Geotiff Image Files
>
> >Some Geotiff Image files are in the 24 bit color format. OziExplorer can
> >read 24 bit color TIFF files but must load them fully into RAM instead of
> >paging them from disk as it does with 8 bit color TIFF mages. For large
> >images this requires a lot of RAM.
>
> The sectional maps from the FAA are 8-bit color (palette). I convert them
> to 24-bit (RGB) when I mask them. The chunks I build are 24-bit.
>
> >If you convert these files to 8 bit color the Geotiff georeference
> >information is lost.
>
> This is just another limitation of OziExplorer. Changing the pixel
> representation has little to do with the ability to hold GeoTIFF data.
>
> I'm planning on making 8-bit versions available but it's easier to
> manipulate (warp/scale/blend/...) the data without mangling it in 24-bit
> mode. My preference is to wait until the last step to create the 8-bit
> images.
>
> >Software to convert the Geotiff image from 24 bit to 8 bit color. Paint
Shop
> >Pro (www.jasc.com) works well.
>
> Oh, well sure. *That* will destroy the GeoTIFF data.
>
> >Perhaps the developer of Oziexplorer needs to add these types of files to
> >its list of "known" types. I will e-mail them.
>
> Good luck. I'm sorry I made comments assuming that OziExplorer would
> deal with GeoTIFFs sensibly.
>
> --kyler

[Kyler Laird]

"Tom Jackson" > writes:

>Please see below from the developer of Oziexplorer - they fixed the software
>after I pointed them to your data. It now works amazingly well!

Impressive! I'm still puzzled about why they couldn't handle the GeoTIFFs
without special intervention, but I like that they fixed it quickly.

BTW, I've finally completed a "chunking" run of all of the sectionals using
the "blend" algorithm. I still don't like the way it looks, but I hope
others will make suggestions.
http://aviationtoolbox.org/munge/mosaic
(Damn! They sure do try to make P-49 obvious, don't they?)

If you select a chunk, you'll get the full-size (5000x5000) version of it as
a JPEG (in another window - always the same one). Change the extension to
".tif" for the GeoTIFF. (Yes, this is just for testing.)

The TIFFs compress about 40%. I should be able to do even better if I
convert them back to 8-bit (palette) images. More later...

It's fun browsing the sectionals. I'd never had one with the note
"APPROXIMATE LIMIT OF PACK ICE THROUGH MARCH".
http://aviationtoolbox.org/munge/chunked/chunk_8_5.jpg

--kyler

[Ben Jackson]

In article >,
Kyler Laird > wrote:
>BTW, I've finally completed a "chunking" run of all of the sectionals using
>the "blend" algorithm. I still don't like the way it looks, but I hope
>others will make suggestions.

Wow, I've always wanted one of those. I want to take all the flights I've
ever made and plot them on top. :)

Shame the colors don't match. Maybe you could use the elevation key that's
on every chart to match between TIFs?

--
Ben Jackson
>
http://www.ben.com/

[[email protected]]

Wow... I was thinking of trying to do this a few weeks ago when you made the
sectionals available. The fact that it's all in GeoTIFF seemed pretty cool, but I didn't
quite get around to trying to code something up. How much of a pain will it be to redo
it when new sectionals come up? Will you have to re-edit out the non-map area?

Thanks again,
-Cory

Kyler Laird > wrote:
: "Tom Jackson" > writes:

:>Please see below from the developer of Oziexplorer - they fixed the software
:>after I pointed them to your data. It now works amazingly well!

: Impressive! I'm still puzzled about why they couldn't handle the GeoTIFFs
: without special intervention, but I like that they fixed it quickly.

: BTW, I've finally completed a "chunking" run of all of the sectionals using
: the "blend" algorithm. I still don't like the way it looks, but I hope
: others will make suggestions.
: http://aviationtoolbox.org/munge/mosaic
: (Damn! They sure do try to make P-49 obvious, don't they?)

: If you select a chunk, you'll get the full-size (5000x5000) version of it as
: a JPEG (in another window - always the same one). Change the extension to
: ".tif" for the GeoTIFF. (Yes, this is just for testing.)

: The TIFFs compress about 40%. I should be able to do even better if I
: convert them back to 8-bit (palette) images. More later...

: It's fun browsing the sectionals. I'd never had one with the note
: "APPROXIMATE LIMIT OF PACK ICE THROUGH MARCH".
: http://aviationtoolbox.org/munge/chunked/chunk_8_5.jpg

: --kyler

--
************************************************** ***********************
* The prime directive of Linux: *
* - learn what you don't know, *
* - teach what you do. *
* (Just my 20 USm$) *
************************************************** ***********************

[Kyler Laird]

writes:

> Wow... I was thinking of trying to do this a few weeks ago when you made the
>sectionals available. The fact that it's all in GeoTIFF seemed pretty cool, but I didn't
>quite get around to trying to code something up.

Have at it. Maybe you'll come up with more creative solutions than mine.
I could really use some different perspectives.

>How much of a pain will it be to redo
>it when new sectionals come up? Will you have to re-edit out the non-map area?

It's automatic. Once I get the FAA images uploaded, I hit "go" and wait
a couple days.

I posted the process in another thread. (Look for the "AVIATIONTOOLBOX"
keyword. I'd give you the URL but I'm offline in a hospital right now.)

--kyler

[[email protected]]

I saw the other thread... that's how I caught up with it again. I was mainly wondering about the
non-map part... if it changes you'll have to change your map-null list.

Good work! Not sure how to do the "fading" any better than what you've got. Of course, the *real* way to
do this would be to try to get ahold of the vector-based info from the FAA directly. That'd be sweet.

-Cory

Kyler Laird > wrote:
: writes:

:> Wow... I was thinking of trying to do this a few weeks ago when you made the
:>sectionals available. The fact that it's all in GeoTIFF seemed pretty cool, but I didn't
:>quite get around to trying to code something up.

: Have at it. Maybe you'll come up with more creative solutions than mine.
: I could really use some different perspectives.

:>How much of a pain will it be to redo
:>it when new sectionals come up? Will you have to re-edit out the non-map area?

: It's automatic. Once I get the FAA images uploaded, I hit "go" and wait
: a couple days.

: I posted the process in another thread. (Look for the "AVIATIONTOOLBOX"
: keyword. I'd give you the URL but I'm offline in a hospital right now.)
:
: --kyler

--
************************************************** ***********************
* The prime directive of Linux: *
* - learn what you don't know, *
* - teach what you do. *
* (Just my 20 USm$) *
************************************************** ***********************

[Kyler Laird]

writes:

> I saw the other thread... that's how I caught up with it again. I was mainly wondering about the
>non-map part... if it changes you'll have to change your map-null list.

What map-null list? Do you mean the lower-left corners? I don't think they
are likely to change. At least I'll be *very* surprised if they do.

I would have had the opportunity to test another set but the FAA apparently
screwed up my order and they don't even have any more of the current set. So
I'm waiting for the December series...

>Good work! Not sure how to do the "fading" any better than what you've got. Of course, the *real* way to
>do this would be to try to get ahold of the vector-based info from the FAA directly. That'd be sweet.

I'm sure they'd like to have it too.

--kyler

[Dean Wilkinson]

Hi Kyler,

I have all of the U.S. sectionals broken up into chunks similar to
what you are describing for my flight planner, AirPlan. My software
then assembles the tiles when rendering the planning map to show the
sectionals seamlessly behind the main map.

I don't give the charts away, but at $2.00 per chart I am pretty much
just covering my subscription costs and covering the cost of
manipulating the images to create the tiles.

Dean Wilkinson
http://www.razorsedgesoft.com/airplan

Kyler Laird > wrote in message >...
> [As I mentioned earlier, I'm going to use this "AVIATIONTOOLBOX" keyword
> so that those who'd like to keep up with these projects can do so easily
> without the annoyance of using a mailing list and others can easily skip/
> killfile them. If you have better suggestions, please feel free to send
> them to me directly or hash it out here. I don't plan to always post to
> comp.infosystems.gis but I thought this topic would be good to address
> there.]
>
> Recently I've been working a lot on manipulating the FAA sectionals I
> purchased.
> http://aviationtoolbox.org/raw_data/FAA_sectionals/
> I've been amazed by the hundreds of people who have downloaded this data.
> There's apparently some interest in it so I'd like to solicit input on
> some of the projects I'm pursuing with the data.
>
> Right now I'm working on breaking up the maps into easily-used subimages.
> I do this (using GDAL) by hacking off all of the stuff around the maps,
> converting them to RGB, warping them to match the Wichita sectional, and
> then cutting them into chunks.
>
> The tricky part is that the maps overlap. For the North and South sides,
> this usually isn't a problem. Different regions however can depict the
> same geographic area quite differently. Choosing how to display these
> areas of overlap isn't obvious to me.
>
> I've made a couple of example attempts. The first
> http://aviationtoolbox.org/tmp/chunk_furthest.jpg
> simply chooses whatever pixel was furthest from the nearest edge in the
> original map. That does a fairly good job, but there is some information
> that is just lost - it's near the edge on both maps, so it isn't shown at
> all. (See the "PINONCANYON0 MSL" area on Denver/Wichita border.)
>
> The next
> http://aviationtoolbox.org/tmp/chunk-blended.jpg
> is a bit more complicated. The weighting of the pixels fades toward the
> edges so that the maps blend into each other. Sometimes this looks much
> better to me, but sometimes it looks like I'm trying to read in
> turbulence. (See the Dalhart airport/VOR.) The big advantage is that no
> information is lost.
>
> Another possibility I'm going to pursue is prioritizing the colors so
> that some colors (blue, maroon, black, ...) take complete priority over
> more "backgroundish" colors. That could make for some strange looking
> airports (See Miller dear Dalhart.) but I think it might look "cleaner"
> without information loss.
>
> So...anyone have strong feelings about how this should be done?
>
> Thank you.
>
> --kyler

[[email protected]]

Kyler Laird > wrote:
:>Good work! Not sure how to do the "fading" any better than what you've got. Of course, the *real* way to
:>do this would be to try to get ahold of the vector-based info from the FAA directly. That'd be sweet.

: I'm sure they'd like to have it too.

So they've only got the bitmaps too? Seems odd... SOMEBODY must have the vector art.
-Cory
--
************************************************** ***********************
* The prime directive of Linux: *
* - learn what you don't know, *
* - teach what you do. *
* (Just my 20 USm$) *
************************************************** ***********************

[Matthew F. G.]

>>Good work! Not sure how to do the "fading" any better than what you've got. Of course, the *real* way to
>>do this would be to try to get ahold of the vector-based info from the FAA directly. That'd be sweet.
>
>
> I'm sure they'd like to have it too.
>
> --kyler


Would you happen to know just what terrain data set they use?

matthew f g

[Kyler Laird]

writes:

>:>Good work! Not sure how to do the "fading" any better than what you've got. Of course, the *real* way to
>:>do this would be to try to get ahold of the vector-based info from the FAA directly. That'd be sweet.

>: I'm sure they'd like to have it too.

> So they've only got the bitmaps too? Seems odd... SOMEBODY must have the vector art.

What makes you think that? (I'd like for you to be correct, but I've been
assuming they don't have it like that.)

--kyler

[Kyler Laird]

"Matthew F. G." > writes:

>Would you happen to know just what terrain data set they use?

No, but I do see on the front of each sectional there's a note (right
under the map) that says "Topographic data corrected to XXXXX".

BTW, the FAA is offering a new set of high-resolution digital elevation
data for right around some airports. It's expensive and doesn't seem
to add a lot of value (for my purposes) for what's out there already so
I'm not planning to get it.

--kyler