[GRASS-user] Grass7 - Inconsistencies with v.out.ogr and v.out.postgis

[Hamish]

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