Paul wrote: > Are you perhaps thinking of g.setproj? It does something > fairly similar to what you describe, whereas g.proj has > never had a very extensive interactive mode. That might > explain a lot of the confusion. g.setproj is a completely > different beast, one that I was never really able to tame.
I dunno, AFAIK g.setproj in G6 works extremely well. Extraordinarily well even. Despite its complications if in doubt it's the guaranteed to work fallback method. Michael wrote: > > If all the data tables in ../etc/proj are wrong and are > > not used for anything anymore, we need to get rid of them > > and replace them with something that works. they are not wrong; they are still used; and they should stay (for now). Certainly the old method is more robust than the new one is. When the new one gets to a better state than the old, then let's talk about replacement. But we're not there yet.. not even close IMO. Note in GRASS 7 there is a bug in the location wizard. I need the help of a wxPy expert to fix it.. http://trac.osgeo.org/grass/ticket/1513#comment:3 this is known to break the ellipsoid (maybe datum too?) setting, so a good thing to fix before digging too deep. > A nice, clean set of 4 csv files that includes all relevant data it ain't broke. please don't try to fix it. If you are not being prompted for datum transform opts, my first question is --> are you running PROJ4 version 4.7.0 <-- ? (not a svn dev checkout) If not, rebuild against that version and try again. (see original report in ongoing http://trac.osgeo.org/grass/ticket/1452) > (projections, datums, datum transforms, ellipsoids) would be > much easier to parse. The stuff currently in ../etc/proj is > currently a real mishmash and difficult to parse. it's all cleanly formated, just that the logic of how it all works is perhaps a bit convoluted. I'm pretty sure that between Paul and me we know how it all fits together though so could add any missing documentation. see `proj -ld` for a list of datums known to PROJ.4. If trying to convert non-epsg coded manually specified strings to +proj4 format, then back to grass is failing, it seems to me the obvious solution is to only use the +proj4 parsing for epsg codes, and use the decades worth of field tested grass tables directly. (~recreate what g.setproj does in python, or port a non-interactive g.setproj to a new lib fn for 'g.proj -c' to use, if needed [I'm not sure it is; just don't try to pass GRASS datum names to +proj=, as PROJ4 only knows its internal offerings]) thanks, Hamish (sorry if this is a bit off-base, I haven't seen the full thread yet; I'll be playing catchup when I can, but I'll still be mostly offline for a wee while yet/ for anything really important try my personal email address which I'll check in on more often) _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
