[GRASS-dev] [GRASS GIS] #1849: Cannot create a new GRASS Location using a custom proj4 string

[GRASS GIS]

#1849: Cannot create a new GRASS Location using a custom proj4 string
---------------------------------+------------------------------------------
  Reporter:  voncasec            |       Owner:  grass-dev@…                  
      Type:  defect              |      Status:  closed                       
  Priority:  critical            |   Milestone:  6.4.3                        
 Component:  Projections/Datums  |     Version:  unspecified                  
Resolution:  fixed               |    Keywords:  proj4, location wizard, wxgui
  Platform:  Linux               |         Cpu:  x86-64                       
---------------------------------+------------------------------------------
Changes (by hamish):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 Helmut wrote:
 > some teste here
 > http://lists.osgeo.org/pipermail/grass-user/2013-May/068240.html
 > http://lists.osgeo.org/pipermail/grass-user/2013-May/068241.html
 > http://lists.osgeo.org/pipermail/grass-user/2013-May/068242.html
 ...
 > EPSG 3416 ETRS89 / Austria Lambert

 can you comment on if the results are as you expect?
 the PROJ_INFO file (g.proj -p) is the main result to be concerned with.

 Moritz added:
  http://lists.osgeo.org/pipermail/grass-user/2013-May/068239.html

 Helmut noticed the same:
 > it seems "0 Do not apply any datum transformation" isn't applied?

 the PROJ.4 function called by 'g.proj -c' sees there is missing
 datum transform opts and decides that it should add one. Which one
 it decides to add depends on your version of PROJ.4.

 filed as a new bug for 6.4.4 (#1995).

 The old text based g.setproj location creation tool doesn't have
 this problem since it creates the PROJ_INFO from terms directly.
 The wxGUI location wizard during location creation goes something
 like grass terms -> +proj terms (summary page) -> WKT -> grass terms.
 ... much more opportunity for something to happen, but fortunately
 the coefficients are pretty well defined. Also it is different if
 you define by terms (parsed via g.proj), or set +proj terms directly
 (not parsed until the last step, so no defaults added). e.g. if you
 define the location by +proj4 terms, and enter "+proj=nzmg
 +datum=nzgd49" and select "0: do not apply transform" the summary
 page (parsed by g.proj) shows added default transform terms, but
 the actual PROJ_INFO in the location (correctly) doesn't have them.

 without abandoning the 'g.proj -c' method, I'm not sure of the
 best way to solve the problem of avoiding PROJ.4 being helpful
 when you want it to be dumb. maybe the best thing to do is to tell
 people to look at 'g.proj -p' just to verify it's what you wanted
 in a final pop up after the location is created (so we can just
 display the PROJ_INFO file as-is), but before it asks about setting
 default bounds and creating a new mapset.

 (actually it may be OGR channeling PROJ 4.8.0 via GPJ_wkt_to_grass()
 and GPJ_osr_to_grass(), and the 4.8.0 thing mostly when starting
 with EPSG codes w/o specified transform terms)


 > Select WKT or PRJ file
 ...
 > no asking which transformation should be used.

 ok, filed that as a new bug for 6.4.4 (#1994).

 > "Used in whole hermannskogel region: towwgs84=653.000,-212.000,449.000"
 > is preselected, but not the best e.g. if location used for Austria.

 that gets back to the whole mess of trying to decide which is the
 best to choose. proj 4.8.0 likes 7-terms (may be more "correct"
 in smaller areas) over 3-terms (may be less accuracy at focus but
 covers a much wider area). And sometimes the 7-term for a place is
 great and the 3-term was poorly derived. It's hard to say.
 Generally if using the old-ways GRASS's internal will suggest
 the 3-term as the default.  See text comments at the start of
 $GISBASE/etc/datum.table.
 There is no real right or wrong answer, the user will have to do
 their homework and make an informed decision for themselves.


 (it's all a bit complicated, the above is my best guess and probably not
 100% accurate)


 The original `+proj=utm +zone=10 +datum=nad83` problem in this ticket is
 now fixed in all versions, and besides for the two new tickets most things
 seem to be working as expected, so closing the ticket.

 Perhaps it would still be good to pop up a window as soon as the location
 is created displaying what is in the final PROJ_INFO file, just to be
 sure. it wouln't have to say that we somewhat doubt our code, just be
 informative saying this is what it ended up with, "ok, continue".


 Hamish

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/1849#comment:14>
GRASS GIS <http://grass.osgeo.org>