Opened 7 years ago

Closed 7 years ago

#1748 closed defect (fixed)

Location wizard creating incorrect locations for selected projections and datums

Reported by: cmbarton Owned by: grass-dev@…
Priority: blocker Milestone: 6.4.3
Component: wxGUI Version: svn-releasebranch64
Keywords: g.proj Cc:
CPU: All Platform: All

Description

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.

Attachments (2)

g.proj_fixes.diff (41.4 KB) - added by neteler 7 years ago.
Bundle patch for g.proj
location_wiz_datum.diff (6.4 KB) - added by neteler 7 years ago.
Bundle patch for location wizard (needs g.proj patch)

Download all attachments as: .zip

Change History (9)

comment:1 Changed 7 years ago by 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.

comment:2 Changed 7 years ago by martinl

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

comment:3 Changed 7 years ago by neteler

Keywords: g.proj added
Version: unspecifiedsvn-releasebranch64

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

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

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

comment:4 Changed 7 years ago by 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

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

Changed 7 years ago by neteler

Attachment: g.proj_fixes.diff added

Bundle patch for g.proj

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

Changed 7 years ago by neteler

Attachment: location_wiz_datum.diff added

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

comment:7 Changed 7 years ago by neteler

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.