Hamish: > grass/trunk/demolocation/PERMANENT/PROJ_INFO > > Log: > > "no defaults" not needed here. (see /usr/share/proj/proj_def.dat)
MarkusN: > ... then our mechanism to generate EPSG 4326 is suboptimal yes, that is known since 'g.proj -c' first arrived; grass's datum and projection support is better developed than proj4's (at least from the POV of grass's libs). By making grass's support = proj4's (e.g. assuming 'g.proj -c' results are the acme) we limit ourselves and make our own support worse. So we take advantage of what proj4 offers, but we are not limited by it, and do not become it. Responding to an earlier email by Nikos, it is also known that the location wizard is not as exact as the text based g.setproj. e.g. the location wizard does not support extra known-to-grass datums and US FIPS county codes, and all the g.proj conversions to and from WKT and +proj4 strings are many and not perfect. It's also known that g.setproj can't take EPSG and georef'd files as input, so less convenient. > and needs to be fixed. in the case of the demolocation PROJ_INFO file I think it's enough to just craft it by hand to make it as it should be. For locations created by 'g.proj -c' it's always going to be laundered through proj4 (actually it's OGR lib code) and that incurs some proj4-related cruft. shrug, that's the cost of using proj4 to create locations I guess. regards, Hamish _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev