| |
ZL3AI > APRDIG 04.04.03 10:59l 262 Lines 10817 Bytes #999 (0) @ WW
BID : 1114-ZL3AI
Read: GUEST
Subj: TAPR Digest, Mar 31, 3/6
Path: DB0FHN<DB0ZWI<DB0HST<ON0DXC<WA7V<W7NTF<VK3AVE<WB0TAX<SP7MGD<VK7AX<
ZL2BAU<ZL3VML
Sent: 030403/0952Z @:ZL3VML.#80.NZL.OC #:63199 [Chch-NZ] FBB7.00i $:1114-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: XASTIR help needed
From: "Curt Mills, WE7U" <hacker@tc.fluke.com>
Date: Mon, 31 Mar 2003 09:33:40 -0800 (PST)
X-Message-Number: 12
On Mon, 31 Mar 2003, Spider wrote:
>However, understanding how it is displayed in a program is important. One
>of the first things a new user has to do to make UI-View work is input their
>coordinates. And, if they did not follow the instructions, they will hose
>up their coordinates.....not the fault of the program.
Well... If it's not perfectly clear and per the roughly-known
standards, it's more likely that the user will screw it up than that
they will get it right. In Xastir and I think APRS+, you can put in
coordinates in a variety of well-known formats, and it converts it
to what the program wants to see. The programs try hard to help you
to do it right.
>Now if you want to discuss standards, I see mapping programs taking USGS
>maps or other maps, that could be NAD27, NAD83 or some other datum certainly
>not known to the user (because it's seldom given by any program author),
>trying to apply them to a WGS84 mapping system! The difference here where
>Iam is about 71 meters! Does it matter? Yes it does indeed!
Agreed. Hidden inside Xastir are functions that will allow us to do
this sort of thing in the future. We currently convert NAD27 to
WGS84/NAD83 when we display USGS geoTIFF topo maps, and the routines
in there can do a whole lot more. We'll either convert them
on-the-fly when we display each map (as we do now), or later we
might do a conversion on each map as we import it into Xastir, which
will save us time when displaying it. Anyway, we're planning for
that capability, because we feel it is extremely useful.
>Get a
>coordinate off your favorite APRS program, then radio it to someone who just
>happens to have a GPS. Don't give him the datum. If he is good, his reply
>to you will be asking for the datum!
If they're trained for SAR in our county, they're _supposed_ to
send/receive everything in WGS84 UTM. Of course we still get the
occasional lat/long across the radio with it's associated problems of
format and datum. More training!
We've added a "Coordinate Calculator" to Xastir for just such occurrences
so that we could quickly convert between UTM, lat/long (multiple formats),
and maidenhead grid. Type in one coordinate, hit the button, and it shows
you all of the representations at once. It's been useful. That particular
dialog doesn't have datum translation added to it yet, but that would be a
worthwhile addition.
--
Curt Mills, WE7U hacker_NO_SPAM_@tc.fluke.com
Senior Methods Engineer/SysAdmin
"Lotto: A tax on people who are bad at math!"
"Windows: Microsoft's tax on computer illiterates!" -- WE7U
"The world DOES revolve around me: I picked the coordinate system!"
----------------------------------------------------------------------
Subject: E-Mail Address Change:
From: "Justin B. French" <judlynn@pilot.infi.net>
Date: Mon, 31 Mar 2003 12:35:44 -0500
X-Message-Number: 13
My new E-Mail address is: judlynn@infionline.net
Thanks, Jud and Lynn
----------------------------------------------------------------------
Subject: Re: XASTIR help needed
From: "Spider" <spider@rivcom.net>
Date: Mon, 31 Mar 2003 10:59:01 -0700
X-Message-Number: 14
----- Original Message -----
From: "Curt Mills, WE7U" <hacker@tc.fluke.com>
To: "Spider" <spider@rivcom.net>
Cc: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Monday, March 31, 2003 10:33 AM
Subject: Re: [aprssig] Re: XASTIR help needed
>Agreed. Hidden inside Xastir are functions that will allow us to do
>this sort of thing in the future. We currently convert NAD27 to
>WGS84/NAD83 when we display USGS geoTIFF topo maps, and the routines
>in there can do a whole lot more. We'll either convert them
>on-the-fly when we display each map (as we do now), or later we
>might do a conversion on each map as we import it into Xastir, which
>will save us time when displaying it. Anyway, we're planning for
>that capability, because we feel it is extremely useful.
>
>
>>Get a
>>coordinate off your favorite APRS program, then radio it to someone who
just
>>happens to have a GPS. Don't give him the datum. If he is good, his
reply
>>to you will be asking for the datum!
>
>If they're trained for SAR in our county, they're _supposed_ to
>send/receive everything in WGS84 UTM. Of course we still get the
>occasional lat/long across the radio with it's associated problems
>of format and datum. More training!
Yes,,,more training is obviously needed in this area. Question Curt......
How does Xastir know of the USGS map or tile it's downloading is NAD27 or
83? I see they some conversion is taking place at Terra-server and some
not....it's possibly a mess! Is there something I am missing that tells
your program what datum the map is?
>We've added a "Coordinate Calculator" to Xastir for just such
>occurrences so that we could quickly convert between UTM, lat/long
>(multiple formats), and maidenhead grid. Type in one coordinate,
>hit the button, and it shows you all of the representations at once.
>It's been useful. That particular dialog doesn't have datum
>translation added to it yet, but that would be a worthwhile
>addition.
In SAR, it's a VERY IMPORTANT and useful tool and certainly needed in the CP
to help make it easier on the searchers. It certainly easier for field
users to plot using grids and UTM. However, in Arizona, the powers that be
chose Lat/Long.
Jim
----------------------------------------------------------------------
Subject: New Zealand APRSers needed
From: "Alan Heaberlin" <w6amh@dslextreme.com>
Date: Mon, 31 Mar 2003 07:03:37 -0800
X-Message-Number: 15
I'm presently working with Steve Fossett's Perlan project to fly a glider to
62,000 feet this summer http://www.weatherextreme.com/perlan/.
Last year on their unsuccessful attempts it was decided that the ground crew
needed some way to track the real-time position of the aircraft in case of
an emergency landing. I have proposed using an APRS tracker but I need to
know if the New Zealand APRS network is robust enough to provide Igate and
digipeating capabilities. It would be helpful if someone in New Zealand
could contact me off-list for some discussion along these lines. Our base of
operations is in Omarama but during absolute record attempts in the Polar
Wave, our crew could be a couple of hundred miles from the team on the
ground.
Alan Heaberlin W6AMH
California City
w6amh@dslextreme.com
----------------------------------------------------------------------
Subject: Re: XASTIR help needed
From: Bob Bruninga <bruninga@usna.edu>
Date: Mon, 31 Mar 2003 13:10:55 -0500 (EST)
X-Message-Number: 16
On Mon, 31 Mar 2003, Curt Mills, WE7U wrote about LAT/LONG standards:
>
>Well... If it's not perfectly clear and per the roughly-known
>standards, it's more likely that the user will screw it up than that
>they will get it right. In Xastir and I think APRS+, you can put in
>coordinates in a variety of well-known formats, and it converts it
>to what the program wants to see. The programs try hard to help you
>to do it right.
But if I can go one step further, conversions are OK, but I feel that all
displays should also always display all LAT/LONGS in the APRS standard
format so that the USERS can effectively "talk" about LAT/LONGS without
confusion on the air or on paper or anywhere else that they use them.
I have asked authors to always display in DD MM.HH and if the user
asks for a conversion, then the conversion can be shown in Parenthesis
but that the official standard DD MM.HH format is still displayed.. THis
way, the users can always see what is the correct "standard" way...
Bob
----------------------------------------------------------------------
Subject: PCSAT Daytime only ops
From: Bob Bruninga <bruninga@usna.edu>
Date: Mon, 31 Mar 2003 13:28:53 -0500 (EST)
X-Message-Number: 17
PCSAT Daylight Ops only...
Over the weekend, PCsat's power system went in to negative power budget
and so she is only operational now in the sunshine during passes after
about 9 AM until just after local sunset.
This condition will remain until PCSAT again enters full sun about 9
April. But again, she lasted 47 days, showing that the diligent command
stations around the world have done a good job of keeping her 72 hour
fail-safe timer properly toggled...
Thanks to all of them!
Bob
----------------------------------------------------------------------
Subject: Re: XASTIR help needed
From: "Curt Mills, WE7U" <hacker@tc.fluke.com>
Date: Mon, 31 Mar 2003 10:49:14 -0800 (PST)
X-Message-Number: 18
On Mon, 31 Mar 2003, Spider wrote:
>How does Xastir know of the USGS map or tile it's downloading is NAD27 or
>83? I see they some conversion is taking place at Terra-server and some
>not....it's possibly a mess! Is there something I am missing that tells
>your program what datum the map is?
Some USGS geoTIFF maps are now NAD83 (close enough to WGS84 as to be
a wash for APRS purposes). When the Xastir geoTIFF code was written,
all of the available topo maps were NAD27. Xastir does a conversion
from NAD27 -> NAD83 if the map datum is not NAD83/WGS84. This means
we handle NAD27/NAD83/NAD84, but if it's not one of those three, we
assume it's NAD27.
A couple of interesting comments from the code:
/*
* What we NEED to do (implemented a bit later in this function
* in order to support geotiff files created with other map
* datums, is to open up the geotiff file and get the map datum
* used for the data. Then convert the corner points to WGS84
* and check to see whether the image is inside our viewport.
* Some USGS geotiff maps have map data in NAD83 datum and the
* .fgd file incorrectly specifying NAD27 datum. There are also
* some USGS geotiff maps created with WGS84 datum.
*/
The latter part of the note mentions that some USGS .fgd files are
screwed up.
/*
* Perform a datum shift on the bounding coordinates before we
* check whether the map is inside our viewport. At the moment
* this is still hard-coded to NAD27 datum. If the map is
* already
* in WGS84 or NAD83 datum, skip the datum conversion code.
*/
So it looks like we correctly handle NAD83/WGS84 and NAD27 USGS
geoTIFF files in terms of datum translation.
--
Curt Mills, WE7U hacker_NO_SPAM_@tc.fluke.com
Senior Methods Engineer/SysAdmin
"Lotto: A tax on people who are bad at math!"
"Windows: Microsoft's tax on computer illiterates!" -- WE7U
"The world DOES revolve around me: I picked the coordinate system!"
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
