[GRASS-dev] [GRASS GIS] #1748: Location wizard creating incorrect locations for selected projections and datums
GRASS GIS
trac at osgeo.org
Sun Oct 7 04:33:26 PDT 2012
#1748: Location wizard creating incorrect locations for selected projections and
datums
----------------------+-----------------------------------------------------
Reporter: cmbarton | Owner: grass-dev@…
Type: defect | Status: new
Priority: blocker | Milestone: 6.4.3
Component: wxGUI | Version: svn-releasebranch64
Keywords: g.proj | Platform: All
Cpu: All |
----------------------+-----------------------------------------------------
Changes (by neteler):
* keywords: => g.proj
* version: unspecified => svn-releasebranch64
Comment:
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.[[BR]]
>
> compatibility of the updated g.proj to the old g.proj is probably the
main
> issue, however. Here are the choices [[BR]]
>
> 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 [[BR]]
>
> 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.[[BR]]
>
> 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.[[BR]]
>
> 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.
>
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1748#comment:3>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list