[GRASS5] Re: proj bugs

[Paul Kelly]

Hello Hamish

On Thu, 3 Jul 2003, H Bowman wrote:

> I just downloaded and compiled the 5.0 CVS snapshot of June 28 and
> PROJ.4 from remotesensing.org's CVS.
>
>
> troubles:  (all with a lat-lon location)
>
>
> d.where:
>
> * program goes into interactive mode automatically

Looks like that was a change by Markus:
http://grass.itc.it/pipermail/grass-commit/2003-April/008573.html
The comment doesn't make it clear why it was done?

>    - should it use the current ellipsoid by default and ask no
>      questions? What is output if neither -l or -w are used??

By default it outputs eastings and northings (or lat/long if in a lat/long
location). No projection is involved and no need to know which ellipsoid
the projection is based on.

> * if you choose to display WGS84 as well, the column headings
>      need to be identified.

Yes that would be a pretty specific situation where your location already
was in lat/long and you wanted to view WGS84 lat/long values alongside
local ellipsoid values. With this new feature I was thinking more of
people with a projected location wanting to compare co-ordinates with
values from a GPS receiver.
But good point; I have now updated the CVS version to print 'WGS
Co-ordinates' above the second column.

>
> -=-=-
>
> Testing out the new New Zealand transforms:
>
> g.setproj Segfaults if a datum is already set. If you say "n" to the
> "specify a map datum for this location?" question it works, and you can
> run it again to set a new datum, but if you try and just change the
> transform params it segfaults.
> [see output #1 below]
>

As far as I understand it g.setproj didn't used to let you change an
existing location to lat/long (even if it was lat/long originally). I
removed some of the restrictions on this in the code but looks like maybe
that was a bad idea as it is causing problems elsewhere. Do you get the
same error, say if it is a nzmg projected location instead of lat/long.

I really don't know what to do about g.setproj. You are far better off just
editing PROJ_INFO files manually if you want to change things; g.setproj is
only anywhere near reliable when setting up a brand new location. Even its
man page says it is just a productivity tool to help in setting up
projections, implying it is fine to edit the files by hand. What it does
(prompting for parameters for each projection) is really something that
should be built into PROJ.4.

I'll get back to you on some of the other things. Some ideas:
is your whole map inside the area covered by the grid-shift file?
Does s.proj still give you no shift when doing datum shifts between two
projected locations ( or projected and lat/long), rather than between two
lat/long locations?

Paul