Martin wrote: > the source of problem is missing EPSG in your location. I'd suggest the problem is rather in the programming assumptions.
> There was discussion about that in ML AFAIR some months ago, > but with no result. sure, the result was if a location is created with an EPSG code, the EPSG code is recorded into a PERMANENT/PROJ_EPSG file. That file is not, and should not, be used for anything other than historical purposes. (it's a one way street, grass defines the projection terms with more precision than the EPSG codes does [e.g. transform terms used]) That file should only be used for historical metadata /user interest pruposes. All projection code should go through the pj_*() functions. > `v.out.ogr` knows which projection you are using, but doesn't know > which EPSG it could be. So when exporting data to PostGIS using > `v.out.ogr` the tries to find matching projection in > `spatial_ref_sys`. that is a flawed approach, it's a near impossible task both in process and in result. See the fun that happened some years ago when Frank changed the precision of the proj4 epsg file by a significant digit or two, everyone who did string matching broke, those which tested abs(dx)<epsilon or some sort (if there were any) found out if their epsilon was set right etc. You'd have to know about the full datum -> ellipsoid+transform terms, and back (but you can't go back because the transform terms are local and not formally defined). And even then, order of the terms matter, so you can't just sort them and test term by term. While not impossible, it is just such an ugly road to go down the best thing is to not try rather than set ourselves up to fail and end up with almost certainly bug riddled software. > If no matching projection is found, then the new projection is > added to `spatial_ref_sys`. eek! that's an even worse idea. Those are definitive codes, nobody but the EPSG people should be assigning them. We are dealing with formal definitions and we are not a granting body. AFAIK PostGIS can take a full proj4 string to define the SRS, so why start making up EPSG codes? Just figure out the way to use the full string. (which isn't perfect either, as GRASS's projection def'ns can contain more detail than +proj terms know how to express) Defining new SRS codes as anything more than a quick hack is simply wrong. trying to save some later grief, Hamish _______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user