[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