#785: wx location wizard: doesn't show all datum transform opts -----------------------+---------------------------------------------------- Reporter: hamish | Owner: [email protected] 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>
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
