I've looked at that, but it doesn't seem to do everything that I need as far as I can tell.
Street Atlas does a lot of what I need, but it's just not quite there... It's been "not quite there" for about 10 years now, I guess... In the best of worlds, I would like to see them create something for aviation use... Let's call it "Air Atlas" for now... It would not take up anywhere close to as much space as Street Atlas since there is definitely not as much airspace information as there is road information out there. I've suggested this numerous times to them, but I guess they just aren't interested in it. Too bad... There's a lot of pilots out there who would like to see better aviation moving maps than what is currently provided, especially if Delorme could stay reasonably priced like they are with Street Atlas. For IFR flights, they would have pilots who were willing to subscribe to an update service and be able to get continued income from it. The thing is, they would have to make it a reasonable subscription price. I can get the every 28-day subscription of the raw FAA data for around $180 per year, so it would need to be quite a bit cheaper than that just to be an acceptable alternative.
When you export a drawn object to a text file, it does not put the color all of the information that it knows in the .an1 file into the exported text file. If it was to put all of this information there (and it was to support the import of this same text file while restoring all the data) then it would be easy enough to look at the text files and get an idea of what options were available and as such write my code to generate that type of file. It doesn't seem that this is an option that anyone considered at Delorme. Is it really all that unreasonable to expect that when you "export" something, all of that 'something' gets exported AND you can subsequently "import" this and get back exactly what you started with? Seems reasonable to me, but oh well, what do I know, I'm only a software engineer who has been realtime and embedded software for NASA, the Navy, and others for the last 21 years after getting out of grad school with a MS in CS and a minor in EE. Obviously I know nothing about this sort of thing that would give me the rights to critique their design. [snicker]
Basically, I'm saying that the import text file should allow something like the following:
FILLCOLOR=#rrggbb /* Hexadecimal colors would be *great*, but even predefined color names would be nice */
LINE=solid|dash|dot|dash-dot|dash-dot-dot|#abcdef /* Where #abcdef would be a hexadecimal bit pattern where you could define your own line pattern */
LAT, LONG, RADIUS (e.g. "29.0, -95.0, 8 nm")
... repeated for every segment ...
Same thing with all the other objects that you can draw. If you can draw the object in Street Atlas, there should be a way to input a text file with the required information in it in order to draw the *exact* same thing. I'm not asking for anything really extensive here since most of this code is already in Street Atlas. All they need to do is make their import routine work like it should have been working for the last 10 years.