#785: wx location wizard: doesn't show all datum transform opts
-----------------------+----------------------------------------------------
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | Milestone: 6.4.0
Component: wxGUI | Version: svn-develbranch6
Resolution: | Keywords: location wizard
Platform: Linux | Cpu: x86-64
-----------------------+----------------------------------------------------
Comment (by hamish):
Replying to [comment:20 hamish]:
> > Can it be integrated as a page of the wizard instead of a popup?
> > (radio buttons?)
Replying to [comment:21 cmbarton]:
> Not easily. This is what we had before and it was problematic.
> The most reliable way to get the proper transform options, AFAIK
>, is to run g.proj .... datatrans=-1.
I'm just talking about the parsing and cosmetics of a GUI; the underlying
code would still use datumtrans=-1.
> If transforms are needed, it will return them as a text string
> (i.e., that is parsed to produce the current popup). But if
> transforms are not needed it will not return anything.
right, this returns nothing:
{{{
g.proj proj4='+proj=utm +zone=12 +datum=wgs84' datumtrans=-1
}}}
and yet in g.setproj(.c) it asks you to confirm. Shrug, it's an issue for
g.proj & there are more important priorities right now.
> > Unfortuanetly the terms in the wizard Summary page do not
> > reflect the selection you make, and once the location is
> > created the datum stuff doesn't make it to the PROJ_INFO file
> > again.
>
> This is doable using g.proj but requires some rewiring of how
> the summary page is created.
also note the "datum stuff doesn't make it to the PROJ_INFO file again"
comment. (ie end result does not have datum set)
> > if you look at any of the tmerc projections in the EPSG file
> > you will see some of the terms which are used to define it.
> > The user should be able to recreate anything there via the
> > prompts.
>
> I don't remember seeing these prompts in the old g.setproj.
try setting tmerc as the projection.
> If I create a location with a LCC, an NAD83 datum, and the proper
> transforms is it wrong?
in so far as it is incomplete. it may(?) default to center on 0 lat, 0
lon, but no guarantees and that's probably not what you want anyway.
> Or is it just that you can get somewhat different projections
> that might better meet particular needs by also specifying other
> parameters?
as an analogy the projection class is like a class of lens. For some
"brand name" ones the values are hard coded, but for many others you also
have to define optical parameters of it. It's not enough just to say
"bifocals". And then you also have to specify where on the globe your
magnifying glass will look at/center on.
(the datum is unrelated and says what shape that globe is and where it
floats in space)
> If it creates a geodetically '''incorrect''' location, this is
> very serious.
This is the case, in so far as the defaults have a 99% chance of not being
what the user wants and right now there is no way of changing them.
> If adding more parameters simply adds greater flexibility in
> projection creation, we have a little more breathing room to work
> out a way to incorporate these and present them to the user in a
> reasonable way.
to make a truly awful car analogy: it's like a car without a steering
wheel. You can technically still drive it but it probably won't go where
you want it to.
Hamish
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/785#comment:23>
GRASS GIS <http://grass.osgeo.org>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
