#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>