Ticket #1452 (new defect)

Opened 3 years ago

Last modified 12 months ago

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

Reported by: hamish Owned by: hamish
Priority: major Milestone: 6.4.4
Component: Projections/Datums Version: svn-releasebranch64
Keywords: location wizard, g.proj Cc: warmerdam, grass-dev@…
Platform: All CPU: All

Description

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

Attachments

grass64svn_working_datum_selection.jpg Download (167.3 KB) - added by neteler 19 months ago.

Change History

in reply to: ↑ description ; follow-ups: ↓ 2 ↓ 14   Changed 3 years ago by 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.

in reply to: ↑ 1   Changed 3 years ago by 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

  Changed 3 years ago by hamish

  • summary changed from wingrass wx location wizard doesn't ask for datum transform options to wx location wizard doesn't ask for datum transform options because proj4 4.7.1's epsg file is broken
  • 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

  Changed 3 years ago by 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

follow-up: ↓ 26   Changed 3 years ago by 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

follow-ups: ↓ 7 ↓ 9   Changed 3 years ago by 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

in reply to: ↑ 6   Changed 3 years ago by martinl

  • keywords g.proj added; wingrass, wx removed

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.

  Changed 3 years ago by hamish

  • platform changed from MSWindows XP to All
  • cpu changed from x86-32 to All

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

in reply to: ↑ 6   Changed 3 years ago by 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

  Changed 2 years ago by 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).

  Changed 2 years ago by neteler

  Changed 2 years ago by warmerdam

  • cc warmerdam added

  Changed 2 years ago by 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.

in reply to: ↑ 1   Changed 20 months ago by 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).

follow-up: ↓ 16   Changed 20 months ago by neteler

  • milestone changed from 6.4.2 to 6.4.3

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

in reply to: ↑ 15   Changed 20 months ago by 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

follow-up: ↓ 18   Changed 19 months ago by 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

in reply to: ↑ 17 ; follow-up: ↓ 21   Changed 19 months ago by 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

  Changed 19 months ago by 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

follow-ups: ↓ 22 ↓ 23   Changed 19 months ago by neteler

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

Changed 19 months ago by neteler

in reply to: ↑ 18   Changed 19 months ago by 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

in reply to: ↑ 20   Changed 19 months ago by 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.

in reply to: ↑ 20 ; follow-up: ↓ 24   Changed 19 months ago by 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

in reply to: ↑ 23   Changed 19 months ago by 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...

  Changed 19 months ago by 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

in reply to: ↑ 5   Changed 19 months ago by 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.

follow-up: ↓ 28   Changed 19 months ago by 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?

in reply to: ↑ 27   Changed 19 months ago by 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

  Changed 18 months ago by 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

  Changed 18 months ago by cmbarton

This seems good. Right?

Michael

  Changed 18 months ago by cmbarton

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

Michael

  Changed 18 months ago by 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.

  Changed 18 months ago by neteler

  • status changed from new to closed
  • resolution set to fixed

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.

follow-up: ↓ 35   Changed 18 months ago by pkelly

  • status changed from closed to reopened
  • resolution fixed deleted

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

in reply to: ↑ 34   Changed 18 months ago by 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

follow-up: ↓ 37   Changed 18 months ago by 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.

in reply to: ↑ 36 ; follow-up: ↓ 38   Changed 18 months ago by 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

in reply to: ↑ 37 ; follow-up: ↓ 39   Changed 18 months ago by 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.

in reply to: ↑ 38 ; follow-up: ↓ 40   Changed 18 months ago by 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?

in reply to: ↑ 39   Changed 18 months ago by 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

  Changed 18 months ago by cmbarton

Working on the Mac

Michael

  Changed 14 months ago by mlennert

  • status changed from reopened to closed
  • resolution set to fixed

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

  Changed 12 months ago by hamish

  • priority changed from critical to major
  • status changed from closed to reopened
  • resolution fixed deleted

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

  Changed 12 months ago by hamish

  • cc grass-dev@… added
  • owner changed from grass-dev@… to hamish
  • status changed from reopened to new

  Changed 12 months ago by hamish

  • milestone changed from 6.4.3 to 6.4.4
Note: See TracTickets for help on using tickets.