Location wizard creating incorrect locations for selected projections and datums

[cmbarton]

Datum transforms are not being presented for selection if a location is created with user selected projection and datum. This results in the possibility of incorrectly created locations and map inaccuracies. I don't know if it is a problem with 1) g.proj, 2) location wizard code, or 3) something else. This could be affecting 6.4.2 also but I have not yet checked.

[neteler]

If it ever worked like this (since it does from EPSG codes), we need to know the last GRASS version where this approach worked for you to be able to compare the code.

[martinl]

What's the status of this blocker? It would be a good idea to release 6.4.3 this month (at least RC1).

[neteler]

The g.proj changes need to be backported: r53297, r53305, unsure: r53310

Location wizard: r53316, r53317

Related ML and offlist comments:

On Wed, Oct 3, 2012 at 7:29 PM, Paul Kelly:

the option is now called datum_trans=. I guess we should be careful to avoid backporting this option name change to 6.x, rather only backporting the addition of the new datum= option? I will leave that decision to someone else anyway.

On Fri, Oct 5, 2012 at 8:32 AM, Michael Barton:

So now the question is how to update GRASS 6.4.3 and 6.5 The location wizard can simply be updated or backported to work like it does in GRASS 7 now. But core.create_location.py and g.proj will need to be updated first. create_location just has to work with g.proj -- though whatever happens, it will work a little differently than it did before with a risk of breaking any script that used it. I doubt there are many if any.
compatibility of the updated g.proj to the old g.proj is probably the main issue, however. Here are the choices
1. Don't updated anything because it may break someone's script. Consequences: the location wizard will create problem locations if projections and datums are picked from a list
2. Update g.proj by adding a new argument "datum". Consequences: This will have no effect on any prior use of g.proj except for scripts that use "datum" as a shortcut to "datumtrans". g.proj for GRASS 6 will be a little different from g.proj for GRASS 7 (argument "datumtrans" in GRASS 6.4.3+ becomes "datum_trans" in GRASS 7). Location wizard can be fixed.
3. Update g.proj to have the same arguments as now in GRASS 7: change "datumtrans" to "datum_trans" and add new "datum" argument. Consequences: Because "datumtrans" is an acceptable abbreviation for "datum_trans", this will not break scripts that use g.proj unless they use the "datum" shortcut for "datumtrans". g.proj will have the same arguments in GRASS 6.4.3+ and GRASS 7. Location wizard can be fixed.
My vote is for # 3. It fixes the datum and location problem, is consistent across GRASS 6.4.3-GRASS 7 and does not break previous use of g.proj any more than # 2.

[cmbarton]

I strongly recommend backporting all of these. There is minimal chance of breaking existing scripts and this eliminates the possibility of a serious problem in location accuracy. I don't *think* that the location wizard has diverged between GRASS 6.4.3 and GRASS 7 to present a backport problem, but we should check.

This should be backported to 6.5 and to 6.4.3. I'm happy to do the backporting on the python stuff if someone else can do and check the relevant back ports for g.proj.

Michael

[neteler]

Replying to neteler:

The g.proj changes need to be backported: r53297, r53305, unsure: r53310

Attached patch contains all above fixes (except for the renaming) of the datumtrans parameter as a bundle for GRASS 6. Please check, e.g.:

g.proj -c loc=spain proj4="+proj=utm +zone=30 +ellps=intl" \
          datum=eur50 datumtrans=-1

which should correctly prompt for all the datum transformation options for eur50. Create the location by selecting the right number for datumtrans=...

Or, to get a list of all supported datums:

g.proj datum=list

Or:

g.proj datumtrans=-1

Please test it rigorously.

TODO:

Location wizard: r53316, r53317

[neteler]

Bundle patch for g.proj

[neteler]

Replying to neteler:

Location wizard: r53316, r53317

Backport patch attached (not renaming datumtrans), now when performing

Locwizard -> Select coord from list -> UTM -> Datum -> Eur50

it pops up the datum selection list, then creates the location.

Please verify along with the g.proj patch.

[neteler]

Bundle patch for location wizard (needs g.proj patch)

[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.