[GRASS-dev] Re: [GRASS-user] problem with vi.in.ogr

[Paul Kelly]

On Sun, 7 Jan 2007, Maciej Sieczka wrote:

>> No projection name! Projection parameters likely to be meaningless.
>
> That's because GRASS doesn't know about the ESRIS's
> Double_Stereographic - propably because GDAL and PROJ don't know it.
> GDAL calls this projection "Oblique_Stereographic".
>
> I have fed all the EPSG codes that use "+proj=sterea" (including EPSG
> 2174 from your case) into epsg_tr.py -wkt, and all they are parsed as
> PROJECTION["Oblique_Stereographic"].
>
> All the codes using "+proj=stere" are parsed as
> PROJECTION["Polar_Stereographic"].
>
> There are no traces of other Sterographic projections supported by
> PROJ.4 (alsk, gall, gs48, gs50, lee_os, mil_os, ups) in my
> /usr/local/share/proj/epsg.
>
> According to [1] ESRI's Double_Stereographic is the same as GDAL's
> Oblique_Steregraphic.
>
> That would make sense. I have tried looking in the ESRI's resorces [2]
> but haven't found a direct answer though.
>
> Should Double_Stereographic be intepreted as Oblique_Steregraphic by
> GRASS? Or is to be fixed in PROJ.4 or GDAL? Paul?

The relevant place to look is, I think, OSRMorphFromESRI() in 
ogr/ogr_srs_esri.cpp in the GDAL source tree. If you're sure of the 
equivalence (in terms of WKT names) you could file a bug in the GDAL 
bugzilla with some sample ESRI-style WKT and what it should be converted 
to, for Frank to look at.

Or, if Double_Stereographic is a valid WKT projection name and it is just 
the conversion into PROJ.4 format that isn't being done correctly, then 
the function OSRExportToProj4() in ogr/ogr_srs_proj4.cpp is the one you're 
interested in. I see in the comments in the header there are quite a lot 
relating to stereographic already, so it is obviously a problem already.

To summarise, it needs looked into a bit more to see whether it is the 
ESRI projection name that is wrong and non-standard (in which case it can 
be worked around in the OSRMorphFromESRI function) or if OGR's conversion 
from WKT projection names into PROJ equivalents is simply missing this 
case (in which case something should be changed in the OSRExportToProj4 
function).

Paul