[GRASS5] Re: proj bugs

On Tue, 22 Jul 2003, H Bowman wrote:

> > > I think the changes I made in the last few days may have fixed the
> > > biggest bugs in g.setproj. But you also need to check the
> > > generated DEFAULT_WIND file. It should have proj: 3 for lat/long
> > > and proj: 99 for nzmg or most projected systems (this determines
> > > the return value from G_projection() ).
> >
> > [running 5.0 CVS from 2 weeks ago]
>
> It might have been less than 2 weeks ago that I fixed this....

Ok, I'm trying with a freshly checked out 5.0 CVS tree now.
Still, DEFAULT_WIND doesn't want to update.
(ll -> nzmg projection, same datum)

I have added a check for a return value so it will stop if it cannot write
the DEFAULT_WIND file. But it works fine for me and I really don't know
what is wrong here. Maybe someone else could test:
When changing projection to or from lat/long, UTM or state plane, the
DEFAULT_WIND file should always be updated as well as PROJ_INFO and
PROJ_UNITS.

> On completion of g.setproj if the projection type has been changed,
> you should see a message asking you to run 'g.region -d' to update the
> current region from the default region.

Yes, I see that. Would it be better to ask (y/n) [y] to run that automatically?
Unfortunately as DEFAULT_WIND isn't changing, the new WIND is just updated to
the old values. (see below)

Possibly but I feel if I make a lot of small cosmetic changes to g.setproj
people will start expecting the rest of the program to be perfect, when
really it needs to be totally re-written both to be GUI-friendly and
internally consistent. But we can wait until the future direction of the
PROJ library is clearer before making a start on this.

Can the following line be shortened or split so it is shorter than 80
characters? I think putting the (y/n) on the next line would do it.
Would you want to change the datum (or the datum transformation parameters)?(y/n) [n] y

Done.

Paul

Hi again --

I've got some new data in yet another new projection, which uses its own
new datum.

The datum is New Zealand Geodetic Datum 2000 (NZGD2000), which is based
on the International Terrestrial Reference Frame 1996 (ITRF96). This is
pretty much the same as WGS84 but uses the GRS80 ellipsoid (slightly
different flattening parameter).

So as far as I understand: NZGD2k (==ITRF96) is the WGS84 datum combined
with the GRS80 ellipsoid.

Except g.setproj won't let me do that, either with a new location or
retroactively. The old 5.0.2 version asks for ellipsoid first, then
datum, but complains when you try to mix wgs84 and grs80 and quits
without writing anything. The latest g.setproj never gives you a chance
to set the ellipsoid, it is chosen from your datum.

I'm not sure if I get the correct result if I just change the ellps:
line to grs80 in the PROJ_INFO file?

Is anything else based on ITRF96? Would it be worth adding that as a
common denominator datum? I think the Map Grid of Australia might be in
a similar situation (??).

see: (102k)
http://www.linz.govt.nz/rcs/linz/17880/difference_wgs84_nzgd2000.pdf

As for the new projection, it is New Zealand Transverse Mercator (NZTM),
which is in terms of that new NZGD2k datum.
Details:
Datum: NZGD2k
Origin Latitude: 0° South
Origin Longitude: 173° East
False Northing: 10 000 000m N
False Easting: 1 600 000m E
Scale Factor: 0.9996

Setting projection as tmerc and entering those terms goes smoothly.
Should NZTM get its own projection entry or is entering by hand with the
tmerc projection every time the way to go?

for more details see: (44k)
http://www.linz.govt.nz/rcs/linz/5684/nztransverse_mercator.pdf

That PDF also has a page of useful ellipsoid to grid formulae which
might be useful to someone.

It doesn't help much that half the country is moving 5cm/year in the
opposite direction to the other half..

thanks for any insight,
Hamish

Hello

On Wed, 23 Jul 2003, H Bowman wrote:

Hi again --

I've got some new data in yet another new projection, which uses its own
new datum.

The datum is New Zealand Geodetic Datum 2000 (NZGD2000), which is based
on the International Terrestrial Reference Frame 1996 (ITRF96). This is
pretty much the same as WGS84 but uses the GRS80 ellipsoid (slightly
different flattening parameter).

So as far as I understand: NZGD2k (==ITRF96) is the WGS84 datum combined
with the GRS80 ellipsoid.

We are pushing at the limits of the accuracy of the current GRASS/PROJ
system here. I looked at the document and to me it seems that NZGD2000 is
based on the ITRS datum. It is 'realised' (which I think means a
description of the current location of the earth's plates based on
measurements from a number of stations around the world) by several ITRF
defintions, and each can be realised at any epoch (point in time).

For high accuracy you would define a shift that related each epoch to WGS84
(would change because of plate tectonics) and each would have a separate
datum entry in GRASS. It would get out of hand very quickly if these were
all included but it may be possible to use GRASS in this way if you could
get figures for the shift (for New Zealand you need ITRF96 at 2000.0
epoch). http://www.iers.org/iers/products/itrf/ looks relevant but I don't
really know.

Except g.setproj won't let me do that, either with a new location or
retroactively. The old 5.0.2 version asks for ellipsoid first, then
datum, but complains when you try to mix wgs84 and grs80 and quits
without writing anything. The latest g.setproj never gives you a chance
to set the ellipsoid, it is chosen from your datum.

No it doesn't seem logical to do that. GRASS uses a very limited definition
of a datum which really just comes down to the ellipsoid used, so by
changing the ellipsoid you are really taking away everything the datum
stands for.

I'm not sure if I get the correct result if I just change the ellps:
line to grs80 in the PROJ_INFO file?

ellps: grs80
towgs84: 0,0,0

and make sure there is no 'datum' line.

Is anything else based on ITRF96? Would it be worth adding that as a
common denominator datum? I think the Map Grid of Australia might be in
a similar situation (??).

It might be worth adding ITRS (International Terrestrial Reference
*System*), but to be compatible with other GIS we should probably
explicitly add New_Zealand_Geodetic_Datum_2000 and the others. But as
they are the same as far as the level of accuracy GRASS/PROJ currently
provides goes, it seems like we could end up with a lot of clutter.
However I have already done that for several countries in Europe which use
the international ellipsoid but have different datum names, so there is no
point in discriminating....

see: (102k)
http://www.linz.govt.nz/rcs/linz/17880/difference_wgs84_nzgd2000.pdf

As for the new projection, it is New Zealand Transverse Mercator (NZTM),
which is in terms of that new NZGD2k datum.
Details:
Datum: NZGD2k
Origin Latitude: 0° South
Origin Longitude: 173° East
False Northing: 10 000 000m N
False Easting: 1 600 000m E
Scale Factor: 0.9996

Setting projection as tmerc and entering those terms goes smoothly.
Should NZTM get its own projection entry or is entering by hand with the
tmerc projection every time the way to go?

Yes that is the way to do it until GRASS has co-ordinate system support,
which I don't see happening any time soon.. you have it very easy with
New Zealand Map Grid which puts in all the parameters for you.

for more details see: (44k)
http://www.linz.govt.nz/rcs/linz/5684/nztransverse_mercator.pdf

That PDF also has a page of useful ellipsoid to grid formulae which
might be useful to someone.

It doesn't help much that half the country is moving 5cm/year in the
opposite direction to the other half..

It would be useful to keep an eye out for any Free Software that handles
that level of accuracy
http://www-gpsg.mit.edu/~simon/gtgk/ has some interesting links

thanks for any insight,

Well hopefully someone will correct the inevitable errors and
misunderstandings in what I've written above

Paul

In regard to New Zealand, I have not researched their implementation in
detail, but from the little that I know; the ITRF is probably NOT the
way to go for "datum shifts" in New Zealand. The original datum was not
recognized or utilized throughout both North Island and South Island,
and local property was referenced to local "meridional circuits" that
were perimeter surveys forming local coordinate systems and cast on
individual aphylactic Cassini-Soldner Grids. Each county was an
"island" unto itself. Topographic mapping at inch to the mile was on
the NZ Transverse Mercator before WWII, and the system remained that way
for decades.

They had a datum readjustment (I think) in the 70s and Lee came up with
the "NZ Map Grid" that covered both islands.

I do know that they have supposedly dropped Lee's projection for both
islands and may have gone back to Transverse Mercator. However, NZ2000
Datum is actually changing monthly if not daily because of the enormous
speed the islands are moving towards Hawaii. (I think maybe a
centimeter a week, not sure!)

Anyway, GIS coordinates need to be "islands" unto themselves (like the
old "meridional circuits"), and I don't think that geodetic "solutions"
are appropriate in this case. I believe that the subject is so complex
for New Zealand, that the transformation from the ITRF_XX to a local
reference frame should be done by geodesists and maybe Land Surveyors,
but certainly not implemented into GIS software.

I may be incorrect in my assessment, but at present I believe that
"PROJ" should certainly NOT implement the current geodetic system (in an
international sense of the ITRF_XX) for New Zealand. Leave it to the
geodesists for now.

Clifford J. Mugnier (cjmce@LSU.edu)
Chief of Geodesy and
Associate Director
Center for GeoInformatics
Department of Civil Engineering
LOUISIANA STATE UNIVERSITY
Baton Rouge, LA 70803
Voice: (225) 578-8536
Facsimile: (225) 578-8652
Pager: 1-(888) 365-5180

http://www.ASPRS.org/resources.html
http://www.cee.lsu.edu/facultyStaff/mugnier/index.html

-----Original Message-----
From: owner-osrs-proj@remotesensing.org
[mailto:owner-osrs-proj@remotesensing.org] On Behalf Of Paul Kelly
Sent: Wednesday, July 23, 2003 6:09 AM
To: H Bowman
Cc: grass5@grass.itc.it; osrs-proj@remotesensing.org
Subject: [OSRS-PROJ] Re: [GRASS5] adding a new datum/projection?

From:Clifford J Mugnier/cjmce/LSU@stjohnspoint.co.uk on 07/23/2003
12:09
PM CET

Hello
                                                                      
On Wed, 23 Jul 2003, H Bowman wrote:
                                                                      
> Hi again --
>
>
> I've got some new data in yet another new projection, which uses
its own
> new datum.
>
>
> The datum is New Zealand Geodetic Datum 2000 (NZGD2000), which is
based
> on the International Terrestrial Reference Frame 1996 (ITRF96).
This is
> pretty much the same as WGS84 but uses the GRS80 ellipsoid
(slightly
> different flattening parameter).
>
> So as far as I understand: NZGD2k (==ITRF96) is the WGS84 datum
combined
> with the GRS80 ellipsoid.
                                                                      
We are pushing at the limits of the accuracy of the current
GRASS/PROJ
system here. I looked at the document and to me it seems that
NZGD2000 is
based on the ITRS datum. It is 'realised' (which I think means a
description of the current location of the earth's plates based on
measurements from a number of stations around the world) by several
ITRF
defintions, and each can be realised at any epoch (point in time).
                                                                      
For high accuracy you would define a shift that related each epoch
to WGS84
(would change because of plate tectonics) and each would have a
separate
datum entry in GRASS. It would get out of hand very quickly if these
were
all included but it may be possible to use GRASS in this way if you
could
get figures for the shift (for New Zealand you need ITRF96 at 2000.0
epoch). http://www.iers.org/iers/products/itrf/ looks relevant but I
don't
really know.
                                                                      
> Except g.setproj won't let me do that, either with a new location
or
> retroactively. The old 5.0.2 version asks for ellipsoid first,
then
> datum, but complains when you try to mix wgs84 and grs80 and quits
> without writing anything. The latest g.setproj never gives you a
chance
> to set the ellipsoid, it is chosen from your datum.
                                                                      
No it doesn't seem logical to do that. GRASS uses a very limited
definition
of a datum which really just comes down to the ellipsoid used, so by
changing the ellipsoid you are really taking away everything the
datum
stands for.
                                                                      
> I'm not sure if I get the correct result if I just change the
ellps:
> line to grs80 in the PROJ_INFO file?
                                                                      
ellps: grs80
towgs84: 0,0,0
                                                                      
and make sure there is no 'datum' line.
                                                                      
> Is anything else based on ITRF96? Would it be worth adding that as
a
> common denominator datum? I think the Map Grid of Australia might
be in
> a similar situation (??).
                                                                      
It might be worth adding ITRS (International Terrestrial Reference
*System*), but to be compatible with other GIS we should probably
explicitly add New_Zealand_Geodetic_Datum_2000 and the others. But
as
they are the same as far as the level of accuracy GRASS/PROJ
currently
provides goes, it seems like we could end up with a lot of clutter.
However I have already done that for several countries in Europe
which use
the international ellipsoid but have different datum names, so there
is no
point in discriminating....
                                                                      
>
> see: (102k)
>
http://www.linz.govt.nz/rcs/linz/17880/difference_wgs84_nzgd2000.pdf
>
>
>
> As for the new projection, it is New Zealand Transverse Mercator
(NZTM),
> which is in terms of that new NZGD2k datum.
> Details:
> Datum: NZGD2k
> Origin Latitude: 0° South
> Origin Longitude: 173° East
> False Northing: 10 000 000m N
> False Easting: 1 600 000m E
> Scale Factor: 0.9996
>
> Setting projection as tmerc and entering those terms goes
smoothly.
> Should NZTM get its own projection entry or is entering by hand
with the
> tmerc projection every time the way to go?
                                                                      
Yes that is the way to do it until GRASS has co-ordinate system
support,
which I don't see happening any time soon.. you have it very easy
with
New Zealand Map Grid which puts in all the parameters for you.
                                                                      
>
> for more details see: (44k)
> http://www.linz.govt.nz/rcs/linz/5684/nztransverse_mercator.pdf
>
> That PDF also has a page of useful ellipsoid to grid formulae
which
> might be useful to someone.
>
>
> It doesn't help much that half the country is moving 5cm/year in
the
> opposite direction to the other half..
                                                                      
It would be useful to keep an eye out for any Free Software that
handles
that level of accuracy
http://www-gpsg.mit.edu/~simon/gtgk/ has some interesting links
                                                                      
>
>
> thanks for any insight,
                                                                      
Well hopefully someone will correct the inevitable errors and
misunderstandings in what I've written above
                                                                      
Paul
----------------------------------------
PROJ.4 Discussion List
See http://www.remotesensing.org/proj for subscription,
unsubscription
  and other information.
                                                                      

On Wed, 23 Jul 2003, H Bowman wrote:

...

The datum is New Zealand Geodetic Datum 2000 (NZGD2000), which is based
on the International Terrestrial Reference Frame 1996 (ITRF96). This is
pretty much the same as WGS84 but uses the GRS80 ellipsoid (slightly
different flattening parameter).

...

Is anything else based on ITRF96? Would it be worth adding that as a
common denominator datum? I think the Map Grid of Australia might be in
a similar situation (??).

For consistency with other GIS and because the International Terrestrial
Reference System datum does not exist in the EPSG datum list, I added
nzgd2k to the GRASS list. We might add ITRS in the future.

For now the transformations nzgd49 --> nzgd2k are still very accurate
because we assume the gridshift file gives a transformation to wgs84, and
then specify nzgd2k as having a zero shift relative to wgs84 (dx=dy=dz=0).
It looks like transforming wgs84-->nzgd2k at high accuracy levels cannot
really be done in the current GRASS/PROJ system because the relationship
between nzgd2k and wgs84 is dynamic; assuming no difference between them
should give acceptable results at small scales.

Paul