| |
ZL3AI > APRDIG 10.05.04 19:40l 229 Lines 9209 Bytes #999 (0) @ WW
BID : 3202-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 21, 6/10
Path: DB0FHN<DB0RGB<DB0AAB<F6KFT<LX0PAC<LX0HST<HA3PG<LZ3NP<WB0TAX<ZL2TZE<
ZL3VML
Sent: 040510/1814Z @:ZL3VML.#80.NZL.OC #:23732 [Chch-NZ] FBB7.00i $:3202-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: APRS greater precision
From: Dale Blanchard <wa7ixk@earthlink.net>
Date: Wed, 21 Apr 2004 13:30:57 -0700
X-Message-Number: 23
If the Earth spun faster it would be like a donut., That could change
things a bit..
Gerry Creager N5JXS wrote:
><Sigh!>
>
>We've been through that all before. George Washington and Thomas
>Jefferson decreed the Prime Meridian for the United States would pass
>through Washington DC. The Capitol Dome was supposed to be the anchor
>and reference point.
>
>The Brits think it belongs in Greenwich. The French think it belongs
>in Paris.
>
>The Russians felt Moscow or Petersburg had promise.
>
>Then we sorta standardized on a worldwide system. Which certainly
>makes teaching this stuff a lot easier!
>
>gerry
>
>Curt, WE7U wrote:
>
>>On Mon, 19 Apr 2004, Scott Miller wrote:
>>
>>>Next time, we need to make sure we get a spherical planet. This
>>>irregular
>>>oblate spheroid thing just isn't cutting it.
>>
>>Yea, but then people would argue over where the prime meridian is...
>>
>>--
>>Curt, WE7U archer at eskimo dot com
>>Arlington, WA, USA http://www.eskimo.com/~archer
>>"Lotto: A tax on people who are bad at math." -- unknown
>>"Windows: Microsoft's tax on computer illiterates." -- WE7U
>>"The world DOES revolve around me: I picked the coordinate system!"
----------------------------------------------------------------------
Subject: Re: APRS greater precision
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Wed, 21 Apr 2004 22:25:16 +0200
X-Message-Number: 24
At 00:06 21-4-2004 +0100, Laurie - g6isy wrote:
>Henk de Groot wrote:
>>The client software receives WGS84 data it so it has to convert it to
>>OSGB36 to be able to display it on the OSGB36 map.
>
>No. If accuracy is required, as the available maps are to OSGB36 then the
>GPS is
>also set to OSGB36, not WGS84. Thus no conversion is required
Note that any NMEA complient GPS shall always output WGS84 (since that is
what the NMEA specification requires). If the NMEA output sends something
else then the NMEA output is broken. Do you realy want to rely on such a
buggy NMEA implementation? What if the vendor fixes his mistake in the
future or if you use a device from a vendor that did a better job of
adhering to the official NMEA protocol specification?
What's wrong with setting your favourit client application to OSGB36 so it
will plot the WGS94 data on the correct position on the OSGB36 map. What's
the problem? Oh, your client doesn't have this setting... then *that* is
the thing that needs to be fixed (complain to the author).
Look at the GPS, it receives a WGS84 position from the sattelites and if
you chose a particular datum then the received data is converted to that
datum setting before it is shown to you on screen. DOD does not change the
configuration of the GPS satellites when fly over Brittan to OSGB36 to get
this result, the receiver does it. Likewise should APRS, receive in WGS84
and display in your favourit datum.
>In the real world it is not possible to perform a WGS84 - OSGB36
>transformation
>in your head and many end users need to be able to plot positions on
>OSGB36 maps
No, the client software should realise that it gets WGS84 off air (because
that's what is specified) and the user wants to have it displayed in OSGB36
format (or any other format for that matter). It should not be done in your
head and not by sending non-complient APRS positions since that creates a mess.
>without having the ability to perform the required transformation. Adding a
>datum identifier (as Bob has suggested) allows the data to be sent (and
>identified as such) in the required format for the end user.
Which means that the client software still has to convert the datum if the
datum in the identifier does not match the currently loaded map datum.
Thats what I meant when I said that it only complicated things. Without
this identfier the client only needs to have a WGS84->IYRFD (=Insert Your
Receivers Favourit Datum) conversion. With this identifier you need a
IYSFD->IYRFD (IYSFD = Insert Your Senders Favourit Datum), which in most
implementations lead to IYSFD->WGS84->IYRFD, so the software has a stable
internal WGS84 representation in whatever form to work with...
>There is no guarantee but at least if you transmit a datum you will know if it
>is the same as your map. If it does match then no conversion is reqired.
>If the
So only the lucky few which happen to use the right datum get the correct
view. If different senders use different datums, nobodies screen will look
correctly. Sounds like a great solution to me :-(. If everybody sends in
WGS84 datum you also know exactly what you get.
>datum does not match then you will know that you do not have the accuracy that
>you might think. At present you have no way of knowing.
You have to check every station to find that out since correct placing of
one will tell you nothing about another, unless you make the dangerous
assumption that they all use the same datum.
>This is difficult when your 'client' is a paper map or a scan of one and there
>are no WGS84 maps available. Unfortunately some of us live in places where
>WGS84
>maps are simply not available.
Sorry, but how do you read the positions? Directly off-air using an AX.25
protocol analyser? Otherwise there is a client, that's the device that
grabs the AX.25 off air and displays it to you.
Switching to OSGB36 format will not solve your problem either, a complient
NMEA device will always output WGS84 data and TH-D7's and TinyTraks do not
convert that to any other datum, so some transmitters will not be able to
change to anything else than WGS84.
If your client does not do datum conversions then you never get it plotted
with a high precision on an OSBG36 map. Adding a datum indicator is not
going to increase the precision either.
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: APRS greater precision
From: "Curt, WE7U" <archer@eskimo.com>
Date: Wed, 21 Apr 2004 13:37:14 -0700 (PDT)
X-Message-Number: 25
On Wed, 21 Apr 2004, Dale Blanchard wrote:
>If the Earth spun faster it would be like a donut., That could change
>things a bit..
Toroidal Coordinate System, used by tire manufacturers... Really!
----------------------------------------------------------------------
Subject: Re: UI-View Questions
From: "Keith - VE7GDH" <ve7gdh@rac.ca>
Date: Wed, 21 Apr 2004 14:09:17 -0700
X-Message-Number: 26
Rick W2RDS asked April 21, 2004 5:58 AM
>I am trying to find a map of the New Jersey area to use with UI-View (the
>fee version) in order to evaluate it. All of the maps I have found so far
>are either of the entire US or of the East coast - and I can find no way to
>zoom in (is there a way). Can anyone point me to, or provide a map of NJ
>that I can use? I am considering getting the 32 bit version, but would
>like to be able to play with the freebie for a while first.
Once you decide to move up to UI-View32, a natural progression would to
purchase Precision Mapping 6 from Undertow Software. It integrates very
nicely with UI-View32 with street level scrollable zoomable maps for all
of the US. Hope someone can help you out with a New Jersey map in the
meantime, but let me know if you don't find anything elsewhere. I could
save a map from Streets and Trips and send it to you.
73 es cul - Keith VE7GDH
--
"I may be lost, but I know exactly where I am."
----------------------------------------------------------------------
Subject: Re: APRS greater precision
From: "Laurie - g6isy" <g6isy@dsl.pipex.com>
Date: Wed, 21 Apr 2004 22:29:14 +0100
X-Message-Number: 27
Henk de Groot wrote:
>Note that any NMEA complient GPS shall always output WGS84 (since
>that is what the NMEA specification requires). If the NMEA output
>sends something else then the NMEA output is broken.
This is not true. The NMEA spec does not define WGS84 as the datum. In fact
it documents the proprietary Garmin sentence $PGRMM to be able to define a
datum. Eg. $PGRMM,NAD27
>Sorry, but how do you read the positions? Directly off-air using an
>AX.25 protocol analyser? Otherwise there is a client, that's the
>device that grabs the AX.25 off air and displays it to you.
In the simplest case a suitable client could be just a TNC into a terminal
program. If the coordinates transmitted are to the same datum as your map
you can just read them from the screen.
>Switching to OSGB36 format will not solve your problem either, a
>complient NMEA device will always output WGS84 data
Sorry, see above. All the GPS units I have used will output NMEA data to a
datum other than WGS84. For example the datum list (219 of them) supported
by the Evermore chipset, widely used in GPS mice can be seen here:
http://www-ri.hive.no/nmea/GM-X205_UG_revB.pdf
>If your client does not do datum conversions then you never get it
>plotted with a high precision on an OSBG36 map.
You will if there is nothing to convert to start with.
--
73 Laurie - G6ISY
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
