wx location wizard doesn't ask for datum transform options because proj4 4.7.1's epsg file is broken

[hamish]

Hi,

with latest 6.4.svn wingrass, if I create a new location with the wx location wizard, it never asks me for which datum transform parms I want to use, and applies one choice on my behalf. :-(

Using g.setproj from the Msys rxvt prompt doesn't work well (you need to know what the next prompt is going to ask as you don't see the prompt -- perhaps a missing fflush()?) so it is very hard to select to use a grid file, and in some parts of the world it is rather critical that you do that.

example: proj=nzmg datum=nzgd49 should give you 3 choices. same trouble if you go by epsg code <27200>.

on linux it works. related to #1189?

thanks, Hamish

[martinl]

Replying to hamish:

example: proj=nzmg datum=nzgd49 should give you 3 choices. same trouble if you go by epsg code <27200>.

on linux it works. related to #1189?

are you sure that it works on GNU/Linux, testing G65

g.proj epsg=27200 datumtrans=-1

gives no output.

[hamish]

Replying to martinl:

are you sure that it works on GNU/Linux, testing G65

g.proj epsg=27200 datumtrans=-1

gives no output.

odd.

for me, in latest 6.4svn and recent 6.5svn on multiple Debian/stable + Ubuntu 10.04 machines it works as expected: 3 choices shown. (3-term, 7-term +towgs84 from grass tables, and the grid file) The proj-data package containing the grid files is installed.

Hamish

[hamish]

• It seems that upstream epsg file is broken. (!)

on Wingrass 6.4svn nightly build:

in the projection wizard, proj=ll datum=nad27 does give the datum transform table menu

in the projection wizard, proj=ll datum=nad83 does not give the datum transfotm menu.

for one NAD83 datum found in the epsg file:

g.proj epsg=4152 datumtransform=-1

gives this error:

WARNING: Datum <NAD83_High_Accuracy_Regional_Network> not recognised by
	GRASS and no parameters found

however another datum=nad83 (epsg:4269) does show table.

?!

at this point I went poking around and noticed that the $PROJ_LIB/epsg file on wingrass is missing a lot of datum= and instead had expanded +towgs84= terms. If datum= had remained you might be able to work around it, but that has not been preserved.

locally I have proj 4.7.0 installed: epsg file is ok.

wingrass ships proj 4.7.1: epsg file includes lots of +towgs84 terms that are not part of the formal epsg definition! they've just been irreversibly expanded on a random assumption.

crap.

fwiw proj 4.7.1 has not been formally released AFAIK (so why the @#$!! heck is osgeo4w shipping it??)

Hamish

[hamish]

This is where/when it broke:

​http://trac.osgeo.org/proj/changeset/1874

filed as proj4 bug # 122.

​http://trac.osgeo.org/proj/ticket/122

Hamish

[hamish]

It seems to go beyond just EPSG codes, e.g. on the msys command line selecting the nad83 datum also returns no options, although etc/datumtransform.table indicates that 5 (+ the 1 default) should be available.

g.proj proj4='+proj=longlat +datum=nad83' datumtrans=-1
g.proj proj4='+proj=longlat +datum=nzgd49' datumtrans=-1

both give no output.

I have added a few debug messages to g.proj in trunk to try and figure out what the blazes is going on inside GPJ_get_default_datum_params_by_name() & co.

(I've never been exactly sure what G_*() fns we're allowed to use inside modules that begin with G_no_gisinit(). g.proj uses G_warning(), G_fatal_error(), and G_message(), so I hope G_debug() is ok too)

Hamish

[hamish]

wingrass 6.5svn r48515 nightly build on XP w/MSys:

GRASS 6.5> g.gisenv set="DEBUG=3"
GRASS 6.5> g.proj proj4='+proj=longlat +datum=nad83' datumtrans=-1
D3/3: set_datumtrans(): datum transform terms found with 6 options
GRASS 6.5>

but no results printed!

also

#spearfish
g.region -d
g.region -n
WARNING: pj_transform() failed: failed to load datum shift file
ERROR: Error in pj_do_proj (projection of input coordinate pair)

g.region -l gives the same error.

Hamish

[martinl]

Replying to hamish:

wingrass 6.5svn r48515 nightly build on XP w/MSys:

> GRASS 6.5> g.gisenv set="DEBUG=3"
> GRASS 6.5> g.proj proj4='+proj=longlat +datum=nad83' datumtrans=-1
> D3/3: set_datumtrans(): datum transform terms found with 6 options
> GRASS 6.5>

but no results printed!

Same on GNU/Linux, doesn't seems to be wingrass-related bug.

[hamish]

wingrass nightly build:

g.proj proj4='+proj=longlat +datum=nad83' datumtrans=-1 but no results printed!

ok, I think I understand the problem. It's the same broken proj 4.7.1svn EPSG file:

source:grass/trunk/general/g.proj/datumtrans.c#L48​ source:grass/trunk/lib/proj/datum.c#L111​

-> g.proj checks for the datum using GPJ__get_datum_params() which returns 1 for datum name found, and 2 for datum name found with datum transform options already specified.

since the current PROJ.4 svn copy of the epsg file has had +towgs84 terms added in bulk, and +datum names removed, I suspect the result is coming back as "2", but the if(force){print the available options} in g.proj's datumtrans.c is only being run if the result is == "1" (ie datum name found, but no info about which of the available transforms to use). That behavior seems reasonable enough.

I've added another debug message in svn to check the result of the datum query and confirm the above theory.

if so, the fix remains to be repairing the epsg file in proj4 svn, and/or sticking with released proj 4.7.0.

(noticed on wingrass because that's built with development proj 4.7.1svn)

Hamish

[hamish]

Replying to hamish:

wingrass 6.5svn r48515 nightly build on XP w/MSys:

#spearfish
g.region -d
g.region -n
WARNING: pj_transform() failed: failed to load datum shift file
ERROR: Error in pj_do_proj (projection of input coordinate pair)

g.region -l gives the same error.

this bug is likely to be wingrass related though. (perhaps libproj + spaces in pathname problem?) if so it could go into a new ticket.

Hamish

[neteler]

Since proj4 bug # 122 (​http://trac.osgeo.org/proj/ticket/122) remains open, I would suggest to add a proj version test in wxGUI or GRASS itself and pop up a warning for the user if proj is = 4.7.1 (which has not been released btw).

[neteler]

See also ​http://trac.osgeo.org/osgeo4w/ticket/217

[rouault]

I've discussed this issue with FrankW recently, and our conclusion was that, ideally, GRASS shouldn't rely on proj4 to determine whether it should offer a choice of alternative datum shift transforms to the user.

Some historical background : the choice of including or not +datum in the proj4 string when TOWGS84 is available in EPSG database was last changed in ​http://trac.osgeo.org/gdal/ticket/3450. The idea was that the hard-coded transform in proj4' pj_datums.c could lag behind the suggested/preferred +towgs84 of EPSG, hence using +towgs84 from latest EPSG update was preferable.

But, even if that changeset never existed and +datum was still there, I'd note that proj4 only knows just a handful of datum names, which is far from being comprehensive.

A better starting point for GRASS would be to start with the EPSG code itself and then examine the gcs.csv and datum_shift.csv files you can find in gdal/data (and libgeotiff AFAIR).

Practical case : let's take the case of EPSG:4617.

"gdalsrsinfo EPSG:4617" output (as of GDAL 1.9.0) is :

PROJ.4 : '+proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs '

OGC WKT :
GEOGCS["NAD83(CSRS)",
    DATUM["NAD83_Canadian_Spatial_Reference_System",
        SPHEROID["GRS 1980",6378137,298.257222101,
            AUTHORITY["EPSG","7019"]],
        TOWGS84[0,0,0,0,0,0,0],
        AUTHORITY["EPSG","6140"]],
    PRIMEM["Greenwich",0,
        AUTHORITY["EPSG","8901"]],
    UNIT["degree",0.0174532925199433,
        AUTHORITY["EPSG","9122"]],
    AUTHORITY["EPSG","4617"]]

The 'NAD83_Canadian_Spatial_Reference_System' datum isn't know by GDAL/proj4, so I'm pretty sure than even in old versions of the proj4 'epsg' file, you have never had any +datum in the expansion of EPSG:4617

But now let's have a look at datum_shift.csv (from GDAL 1.9.0) :

"SEQ_KEY","COORD_OP_CODE","SOURCE_CRS_CODE","TARGET_CRS_CODE","REMARKS","COORD_OP_SCOPE","AREA_OF_USE_CODE","AREA_SOUTH_BOUND_LAT","AREA_NORTH_BOUND_LAT","AREA_WEST_BOUND_LON","AREA_EAST_BOUND_LON","SHOW_OPERATION","DEPRECATED","COORD_OP_METHOD_CODE","DX","DY","DZ","RX","RY","RZ","DS","PREFERRED"
11,1842,4617,4326,"For many purposes NAD83(CSRS) can be considered to be coincident with WGS 84.","Approximation at the +/- 1m level assuming that NAD83(CSRS) is equivalent to WGS 84.",1061,40.04,86.45,-141,-47.74,1,0,9603,0,0,0,,,,,1
12,1946,4617,4326,"Jointly derived by US NGS and Geodetic Survey of Canada - see also code 1901. Strictly between NAD83(CSRS) and ITRF96(1997.0).",Geodesy.,1061,40.04,86.45,-141,-47.74,1,0,9607,-0.991,1.9072,0.5129,-0.0257899075194932,-0.0096500989602704,-0.0116599432323421,0,0

Bingo, we can see that there are 2 possible transformations. The scripts regenerating GDAL/libgeotiff data files picked up the first one ( the line such that PREFERRED = 1), but there's another one available...

(I'd note that in the case of EPSG:4230 (ED50), there seems to have no advertized preferred shift. And apparently the script pick up the one of the first line with SOURCE_CRS_CODE=4230)

Ideally, there should be an API (in GDAL's OSR probably ?) to suggest alternative towgs84 transforms given a GCS code. But that's perhaps something that could also be done by GRASS itself by parsing datum_shift.csv ?

My summary of this whole issue could be : proj4 strings don't contain as much information as in a EPSG code and/or its WKT expansion, and should not be used for any other purpose than using proj4 to do coordinate transforms.

[neteler]

Replying to martinl:

Replying to hamish:

example: proj=nzmg datum=nzgd49 should give you 3 choices. same trouble if you go by epsg code <27200>. on linux it works. related to #1189?

are you sure that it works on GNU/Linux, testing G65

g.proj epsg=27200 datumtrans=-1

gives no output.

No result either in GRASS 6.4.svn (if there should be any).

[neteler]

Is this still a problem? I have tested EPSG 3003 (an Italy code) with 6.4.2 and proj-4.7.0-5.fc17.x86_64, it properly suggest the available datums in the location wizard.

Also on command line it works:

GRASS 6.4.3svn (newLocation):~ > g.proj epsg=3003 datumtrans=-1  
---
1
Used in whole rome40 region
towgs84=-225.000,-65.000,9.000
...
4
Used in Italy (Sicily)
towgs84=-50.2,-50.4,84.8,-0.690,-2.012,0.459,-28.08
Accuracy 3-4m

[hamish]

Replying to neteler:

Is this still a problem?

An exhaustive test of grass/qgis/cs2cs/postgis against 4.8.0-final re. proj4 bug # 122 has been on my too list since way too long ago. I'll try to get to that this week.

From what I understand, QGIS is still broken, although they use a different path than grass and their solution involved patching particular CRSs as people complained, each time the CRS files were updated. :-/ But Frank did clean up the situation a bit before the 4.8.0 release, so I'm hoping for success.

best, Hamish

[cmbarton]

This is still broken and is producing incorrect projections. So it looks like GRASS does not project maps correctly. This is quite serious given GRASS's claim of high quality geospatial data.

Michael

[neteler]

Replying to cmbarton:

This is still broken and is producing incorrect projections.

This statement is a bit generic :) I can successfully reproject data for the projections in use here.

Please indicate the EPSG codes of failing reprojections.

Markus

[cmbarton]

I have not gone through the many many projections available, but the datum transform choice dialog does not appear at all. If you have one where it does show up for you in the location wizard, let me know and I will test it on the Mac.

Michael

[neteler]

For example, the Italian EPSG code 3003 works nicely, see attached screenshot.

[mlennert]

Replying to neteler:

Replying to cmbarton:

This is still broken and is producing incorrect projections.

This statement is a bit generic :) I can successfully reproject data for the projections in use here.

In comment:15 you say that you are using proj-4.7.0-5.fc17.x86_64. The problem appears with 4.7.1, no ?

Moritz

[neteler]

Replying to neteler:

For example, the Italian EPSG code 3003 works nicely, see attached screenshot.

For the record, I am using proj-4.7.0-5.fc17.x86_64 which works fine.

Current version is ​http://download.osgeo.org/proj/proj-4.8.0.tar.gz

The bugs were closed: ​http://trac.osgeo.org/proj/query?status=closed&group=resolution&milestone=4.8.0

See in particular ​http://trac.osgeo.org/proj/ticket/122

To me the PROJ 4.7.1 looks as being broken. So either use PROJ 4.7.0 or 4.8.0.

[cmbarton]

Replying to neteler:

For example, the Italian EPSG code 3003 works nicely, see attached screenshot.

OK. I did a couple tests and see better where my problem lies.

Datum transforms DO work OK for EPSG codes but do NOT work for selecting the same parameters from a list. For example, if you select ED50, UTM Zone 29 from the EPSG list (23029) you get a datum transform list. But if you pick UTM, Zone 29, ED50 from the list of projections and datums you do NOT get a list of datum transforms.

Is this the same bug or a different one?

Michael

[neteler]

Replying to cmbarton:

Replying to neteler:

For example, the Italian EPSG code 3003 works nicely, see attached screenshot.

OK. I did a couple tests and see better where my problem lies.

Datum transforms DO work OK for EPSG codes but do NOT work for selecting the same parameters from a list. For example, if you select ED50, UTM Zone 29 from the EPSG list (23029) you get a datum transform list.

(​http://spatialreference.org/ref/epsg/23029/)

So no issue here... (except for the fact that the PROJ4 4.7.1 release is broken, so either downgrade or upgrade).

But if you pick UTM, Zone 29, ED50 from the list of projections and datums you do NOT get a list of datum transforms.

This looks like unrelated to this bug (to me). And I don't think that this behaviour can be changed, how should PROJ4/GRASS GIS know from the literal description (rather than formal EPSG code) which datums to suggest? See for example the list of projections: ​http://spatialreference.org/ref/?search=UTM+zone+29N

All come with different ellipsoids, datums and so on...

[cmbarton]

The location wizard is a fancy wrapper for g.proj. It creates a proj4 string and send it to g.proj.

g.proj is supposed to return a datum transfer list when relevant for the proj4 string. This *USED* to happen with any relevant proj4 string. It seems now that it is ONLY happening when g.proj gets an EPSG code. The code to return the datum transfer seems to be working properly, since it works for EPSG. So my guess is that g.proj is no longer returning a datum transform list for proj4 strings.

Michael

[neteler]

Replying to hamish:

It seems to go beyond just EPSG codes, e.g. on the msys command line selecting the nad83 datum also returns no options, although etc/datumtransform.table indicates that 5 (+ the 1 default) should be available.

g.proj proj4='+proj=longlat +datum=nad83' datumtrans=-1
g.proj proj4='+proj=longlat +datum=nzgd49' datumtrans=-1

both give no output.

When adding "-d", it does give output:

GRASS 6.4.3svn (nc_spm_08):~ > g.proj proj4='+proj=longlat +datum=nad83' datumtrans=-1
GRASS 6.4.3svn (nc_spm_08):~ > g.proj proj4='+proj=longlat +datum=nad83' datumtrans=-1 -d
GRASS datum code: nad83
WKT Name: North_American_Datum_1983
Datum transformation parameters (PROJ.4 format):
        towgs84=0,0,0,0,0,0,0
GRASS 6.4.3svn (nc_spm_08):~ > g.proj proj4='+proj=longlat +datum=nad83' datumtrans=-1
GRASS 6.4.3svn (nc_spm_08):~ > g.proj proj4='+proj=longlat +datum=nad83' datumtrans=-1 -d
GRASS datum code: nad83
WKT Name: North_American_Datum_1983
Datum transformation parameters (PROJ.4 format):
        towgs84=0,0,0,0,0,0,0
GRASS 6.4.3svn (nc_spm_08):~ > g.proj proj4='+proj=longlat +datum=nzgd49' datumtrans=-1
GRASS 6.4.3svn (nc_spm_08):~ > g.proj proj4='+proj=longlat +datum=nzgd49' datumtrans=-1 -d
GRASS datum code: nzgd49
WKT Name: New_Zealand_Geodetic_Datum_1949
Datum transformation parameters (PROJ.4 format):
        towgs84=59.47,-5.04,187.44,0.47,-0.1,1.024,-4.5993

No idea about datum "eur50", though.

[cmbarton]

In fact eur50 is not recognized. Same is true for at least several other datums. Since they are not recognized, they do now spawn datum transforms.

For example, wgs84 is recognized by g.proj

GRASS 7.0.svn (newLocation):~ > g.proj -d proj4='+proj=utm +datum=wgs84'
GRASS datum code: wgs84
WKT Name: WGS_1984
Datum transformation parameters (PROJ.4 format):
	towgs84=0,0,0,0,0,0,0

but European Datum 1995 (eur50) is not recognized.

GRASS 7.0.svn (newLocation):~ > g.proj -d proj4='+proj=utm +datum=eur50'
WARNING: Datum <unknown> not recognised by GRASS and no parameters found
Datum name not present
Datum parameters not present

All unrecognized datums that I tested are listed in ../etc/proj/datums.table

Could this be a problem more with g.proj than with proj4?

[mmetz]

Replying to cmbarton:

All unrecognized datums that I tested are listed in ../etc/proj/datums.table

Datums listed in etc/proj/datums.table but unknown to OGR/proj4 will not be recognised if passed to g.proj within a proj4 string. In this case the datum option must be added:

GRASS 7.0.svn (nc_spm_08):~ > g.proj -d proj4='+proj=utm +datum=eur50' datum=eur50
WARNING: Datum <unknown> not recognised by GRASS and no parameters found
Datum set to <eur50>
GRASS datum code: eur50
WKT Name: European_Datum_1950
Datum parameters not present; default for eur50 is:
	towgs84=-87.000,-98.000,-121.000

Could this be a problem more with g.proj than with proj4?

g.proj creates an OGR spatial reference system from the proj4 string which is then used by libproj to figure out the parameters. If the datum name is not recognized by OGR it gets lost and never makes it to libproj, in which case the datum name needs to be supplied separately with the datum option.

HTH,

Markus M

[neteler]

Ticket #1748 contains a patch for g.proj with various backports of fixes by Paul Kelly which lead to these results:

GRASS 6.4.3svn (nc_spm_08):~ > g.proj proj4='+proj=longlat +datum=nzgd49' datumtrans=-1 -d
GRASS datum code: nzgd49
WKT Name: New_Zealand_Geodetic_Datum_1949
Datum transformation parameters (PROJ.4 format):
        towgs84=59.47,-5.04,187.44,0.47,-0.1,1.024,-4.5993

GRASS 6.4.3svn (nc_spm_08):~ > g.proj epsg=27200 datumtrans=-1 -d
GRASS datum code: nzgd49
WKT Name: New_Zealand_Geodetic_Datum_1949
Datum transformation parameters (PROJ.4 format):
        towgs84=59.47,-5.04,187.44,0.47,-0.1,1.024,-4.5993

GRASS 6.4.3svn (nc_spm_08):~ > g.proj -d proj4='+proj=utm +datum=eur50' datum=eur50
WARNING: Datum <unknown> not recognised by GRASS and no parameters found
Datum set to <eur50>
Ellipsoid set to <international>
GRASS datum code: eur50
WKT Name: European_Datum_1950
Datum parameters not present; default for eur50 is:
        towgs84=-87.000,-98.000,-121.000

[cmbarton]

This seems good. Right?

Michael

[cmbarton]

If this includes a backport of wizard.py then it will need to be modified to replace "datum_trans =" with "datumtrans ="

Michael

[neteler]

Ticket #1748 contains a patch for the location wizard in GRASS 6 making use of the g.proj fixes suggested in that ticket. See there.

[neteler]

g.proj fixes backported in r53452 + r53454 for GRASS 6.4 and r53453 for GRASS 6.5

Location wizard fixes backported in r53455 for GRASS 6.4 and r53456 for GRASS 6.5

This issue should be solved now. Feel free to reopen if not.

[pkelly]

As far as I can see this problem still exists; the long-standing bug in the location wizard was completely separate from this more recently-arising issue which was due to changes in the way GDAL processes EPSG projection definitions.

As I see it, working around this is a more long-term project; if nothing changes in GDAL and it continues to force its own choice of datum transform parameters, then we will have to see about changing the way g.proj treats co-ordinate systems generated by GDAL. Possibly by adding yet another flag, to ignore any datum transformation parameters in the input co-ordinate system.

But I think we should leave things to settle down a bit before looking at that.

Paul

[mlennert]

Replying to pkelly:

As far as I can see this problem still exists; the long-standing bug in the location wizard was completely separate from this more recently-arising issue which was due to changes in the way GDAL processes EPSG projection definitions.

But wasn't this just an issue with proj 4.7.1, which was solved in 4.8.0 ?

So, AFAIU, the bug is resolved by the changes in proj.

Moritz

[pkelly]

Hmmm, I have just read through the bug thread and am confused by all the discussion about PROJ. g.proj does not use PROJ at all (nor any files from the PROJ distribution) and strings passed with the proj4= option are interpreted by GDAL/OGR functions, so I don't see how changes to PROJ can fix the original problem in this report.

I seem to remember there was an issue with the .csv files distributed by GDAL, which we include a copy of in lib/proj. We needed to avoid updating these to the latest version, because it included forced datum transformation parameters for many co-ordinate systems and datums, which meant that g.proj took these as given and no longer prompted for a user to choose their own parameters.

Could the WinGRASS-specific issue perhaps be that the OSGeo4W version of GRASS is using a different version of the GDAL .csv files?

Unfortunately I really don't have much time to look at this at present. But I don't think the bug should be closed, and the recent changes to g.proj were to fix a bug in the location wizard and were completely separate from this bug, as far as I can see.

[mlennert]

Replying to pkelly:

Hmmm, I have just read through the bug thread and am confused by all the discussion about PROJ. g.proj does not use PROJ at all (nor any files from the PROJ distribution) and strings passed with the proj4= option are interpreted by GDAL/OGR functions, so I don't see how changes to PROJ can fix the original problem in this report.

Most of us do use the epsg file that come from proj. And that file, in the 4.7.1 version of proj did not contain datum names, but precise transformation parameters for one of the available transformations. Thus, the location wizard suddenly did not ask for a choice between datum transformations.

This issue was actually fixed by the changes in proj, and, as you say, have nothing to do with the patches. But AFAIU the issue can still be considered as solved.

AFAIU (again), your patches fixed another bug, and both were mixed up in this ticket. But both seem to be solved now.

Moritz

[martinl]

Replying to mlennert:

AFAIU (again), your patches fixed another bug, and both were mixed up in this ticket. But both seem to be solved now.

I am not following this bug report so closely. Anyway when testing Krovak projection (EPSG:2065) with the latest 6.4.3svn the location wizard works OK and shows dialog for choosing datum transformation parameters. Using Proj4 4.8.0.

[martinl]

Replying to martinl:

Replying to mlennert:

AFAIU (again), your patches fixed another bug, and both were mixed up in this ticket. But both seem to be solved now.

I am not following this bug report so closely. Anyway when testing Krovak projection (EPSG:2065) with the latest 6.4.3svn the location wizard works OK and shows dialog for choosing datum transformation parameters. Using Proj4 4.8.0.

Time to close the ticket?

[hellik]

Replying to martinl:

for choosing datum transformation parameters. Using Proj4 4.8.0.

Time to close the ticket?

tested here with grass6.4.3RC1 on windows and example above

proj=nzmg datum=nzgd49

3 options are offered.

Helmut

[cmbarton]

Working on the Mac

Michael

[mlennert]

As there have been no complaints about this for the last 4 months, I'm taking the initiative of closing this ticket as solved.

Moritz

[hamish]

Hi,

Reopening, lowering priority, & taking ownership of the ticket until I've had a chance to thoroughly test it. It all seems to be working now, but I don't think I'll be comfortable with it until I've audited the entire (new bits of the) code chain, and it's an important enough thing that I'd like to spend a little bit of my "copious free time" doing that.

pkelly wrote:

Hmmm, I have just read through the bug thread and am confused by all the discussion about PROJ. g.proj does not use PROJ at all (nor any files from the PROJ distribution) and strings passed with the proj4= option are interpreted by GDAL/OGR functions, so I don't see how changes to PROJ an fix the original problem in this report.

What you are missing is that the wxPy location wizard takes the parameters it is told and converts/expands them to a proj4 string, and runs g.proj using that string. That process can be lossy, and/or not work for things which grass's projection engine supports(knows about) but the installed version of proj4/gdal does not. g.setproj is just fine, the problem was if you started with an epsg code with the epsg file from proj 4.7.1svn, but Frank cleared that up before releasing 4.8.0. I'll have to dig through grass's datum table (for example) to demonstrate the corner cases which I'm thinking about.

~unrelated to the main set of cases I'm thinking of, the google spherical-merc epsg:900913 and other oddballs in the extra-epsg files are good test cases to make sure everything that needs to be is being picked up.

thanks, Hamish

[mlennert]

Replying to hamish:

Hi,

Reopening, lowering priority, & taking ownership of the ticket until I've had a chance to thoroughly test it. It all seems to be working now, but I don't think I'll be comfortable with it until I've audited the entire (new bits of the) code chain, and it's an important enough thing that I'd like to spend a little bit of my "copious free time" doing that.

Have you had the opportunity to test this any more ? I haven't seen any complaints since the fix.

Moritz

[hamish]

hopefully it's all ok now. fwiw this was around for a while without a lot of complaints, since it was failing silently unless you were an expert in knowing what the projection settings output should be, and checked them.