[GRASS-dev] Projection-problem

[Stephan Holl]

Hello Paul,

On Wed, 10 May 2006 16:12:30 +0100 (BST) Paul Kelly
<paul-grass at stjohnspoint.co.uk> wrote:

> Hello Stephan
> 
> On Wed, 10 May 2006, Stephan Holl wrote:
> 
> > Hello Paul,
> >
> > thanks for replying! I really appreaciate your comments (and
> > sollutions).
> 
> Apologies for not really keeping up with the list at all recently;
> this message just happened to catch my eye!
> 
> >> Hello Stephan
> >> What is GK Zone 4 (DHDN)?
> >
> > This is similar to EPSG:31468, from Oracle Spatial Datasets.
> 
> OK sorry I was confused asking that---that field isn't used for 
> determining the projection; it is just meant to be human readable
> AFAIK and it wasn't the problem.

OK.

> 
> >> It seems that the GDAL function
> >> OSRExportToProj4() is returning a PROJ.4 string with a missing
> >> "proj=" parameter, because it can't convert "GK Zone 4 (DHDN)"
> >> into a projection.
> >
> > OK, thanks for clarifying this. But apparently ogrinfo returns at
> > least correct projections parameters like
> > PRIMEM["Greenwich",0.000000], UNIT["Decimal
> > Degree",0.01745329251994330]], PROJECTION["Transverse Mercator"],
> >    PARAMETER["Scale_Factor",1.000000],
> >    PARAMETER["Central_Meridian",12.000000],
> >    PARAMETER["False_Easting",4500000.000000],
> >    UNIT["Meter",1.000000000000],
> >
> > Could that be a problem with the different strings from Oracle here?
> 
> Yes. I think the problem is the missing underscore _ between
> Transverse and Mercator. Seems simple but confuses the OGR function
> and I'm really not sure how best to handle it.

I see.

> 
> >> GRASS is crashing because it assumes that there will
> >> always be a proj= value, not unreasonable I don't think! I could
> >> change it so it won't segfault but I think it would be better if
> >> the OSRExportToProj4() function returned an error code when it
> >> can't determine the projection.
> >
> > Yes, the latter would be the better choice afaik. Non-segfaults are
> > always appreciated :-) Would this be a big task and is it worth to
> > have such a short-term solution?
> 
> OK I've changed it now to print a warning if the projection name is 
> missing rather than giving a segfault (however the resulting
> projection parameters will not be much use!).

After updating from CVS today I recompiled and tested your changes.
However, the program is not segfaulting anymore.

But, it does not import any other projected dataset anymore unless I
specify -o which mostly is unintended for projected data.

Spearfish.dataset:
# exporting roads in tmp-dir
v.out.ogr in=roads type=line dsn=/tmp olayer=spear_roads

# verifying exported dataset
ogrinfo -al -so /tmp/spear_roads.shp
INFO: Open of `/tmp/spear_roads.shp'
using driver `ESRI Shapefile' successful.

Layer name: spear_roads
Geometry: Line String
Feature Count: 825
Extent: (589434.856469, 4914006.337837) - (609527.210215,
4928063.398015) Layer SRS WKT:
PROJCS["UTM Zone 13, Northern Hemisphere",
    GEOGCS["clark66",
        DATUM["North_American_Datum_1927",
            SPHEROID["clark66",6378206.4,294.9786982]],
        PRIMEM["Greenwich",0],
        UNIT["Degree",0.017453292519943295]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",-105],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",500000],
    PARAMETER["false_northing",0],
    UNIT["Meter",1]]
cat: Real (11.0)
label: String (80.0)

Seems OK so far.

# Reimporting
v.in.ogr dsn=/tmp layer=spear_roads out=test2222
ERROR: Projection of dataset does not appear to match current location.

       LOCATION PROJ_INFO is:
       name: UTM
       datum: nad27
       nadgrids: conus
       proj: utm
       ellps: clark66
       a: 6378206.4000000004
       es: 0.0067686580
       f: 294.9786982000
       zone: 13

       cellhd.proj = 0 (unreferenced/unknown)
                   ^^^^^^^^^ Wrong!

?! 

I am using proj-4.5b2 with nadgrids compiled in
grass61-cvs from today
gdal-1.3.2

So the latest EPSG-changes committed to proj, gdal and grass should be
there.

Can you reproduce this?

Anyway, thanks for helping so fast.

Best
	
	Stephan

-- 
GDF Hannover - Solutions for spatial data analysis and remote sensing
Hannover Office      -     Mengendamm 16d      -     D-30177 Hannover
Internet: www.gdf-hannover.de      -      Email: holl at gdf-hannover.de
Phone : ++49-(0)511.39088507       -        Fax: ++49-(0)511.39088508