[GRASS-dev] Re: [GRASS GIS] #785: wx location wizard: doesn't show
all datum transform opts
GRASS GIS
trac at osgeo.org
Mon Oct 12 10:58:56 EDT 2009
#785: wx location wizard: doesn't show all datum transform opts
-----------------------+----------------------------------------------------
Reporter: hamish | Owner: grass-dev at 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 cmbarton):
Replying to [comment:20 hamish]:
Thanks very much for the quick testing and reply.
> The new datum transform GUI is a solid step forward. Can it be
integrated as a page of the wizard instead of a popup? (radio buttons?)
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. 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.
>
> 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.
>
> For datum -> WGS84 there is no popup. Even though there is only one
choice, in an old discussion we decided to show the list anyway so the
user knew what was going on. It's just an [Ok] confirmation, so no big
hassle for the user to step past.
See above. Because of g.proj behavior, this is not possible without going
back to parsing the transform tables--that got us into trouble in the
first place.
>
> .
>
> The proj_desc.table will have to be manually dealt with, but let's get
the datum stuff sorted out first. (lessons learned, etc)
> In effect we (well, for now you anyway) are rewriting g.setproj using
Python instead of C.
> Glynn(?) did a nice job extracting those tables which should make things
much easier.
>
> 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. But maybe I
just never tried to create projections that were sufficiently exotic. I'll
run g.setproj with some different projections and see what happens.
If I create a location with a LCC, an NAD83 datum, and the proper
transforms is it wrong? Or is it just that you can get somewhat different
projections that might better meet particular needs by also specifying
other parameters?
If it creates a geodetically '''incorrect''' location, this is very
serious. 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.
Michael
>
>
> thanks & sorry I can't give you more coding help right now,
> Hamish
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/785#comment:21>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list