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

GRASS GIS GRASS GIS developer
,
1

Jarek Jasiewicz wrote:

Reasons found but problem exist:

34 points has exactly the same coors. So topology cannot be bulid....

Jarek

Duplicate points should not make GRASS modules fail. Try this eg.:

# create 34 (like in your case) duplicate point vector:
i=0; while [ $i -ne 34 ]; do echo "100 100"; let "i++"; done |
v.in.ascii out=pt34 fs=" "

# export to shapefile
v.out.ogr input=pt34 type=point dsn=pt34 olayer=pt34

# import it back:
v.in.ogr dsn=$HOME/pt34/pt34.shp output=pt34_re
[...]
Importing map 34 features...
-----------------------------------------------------
Building topology ...
34 primitives registered
Building areas: 100%
0 areas built
0 isles built
Attaching islands:
Attaching centroids: 100%
Topology was built.
Number of nodes : 1
Number of primitives: 34
Number of points : 34
Number of lines : 0
Number of boundaries: 0
Number of centroids : 0
Number of areas : 0
Number of isles : 0

All works - for me.

Maybe your shapefile is corrupted somehow? Can you send it for testing?

location is set on EPSG 2174 (Polish 1965 zone 4)

when I try import shape with points to location:

v.in.ogr -o dsn=/home/jarekj/shp/PunktyAZP.shp output=azp min_area=0.0001
snap=-1 --overwrite

I recive message:

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 are 18 EPSG codes using sterea. They all might result in same
problems in the GRASS - ESRI data exchange.

[1]
http://udig.refractions.net/docs/api-geotools/org/geotools/ct/proj/Stereographic.html
[2]
http://webhelp.esri.com/arcgisdesktop/9.2/index.cfm?TopicName=Double_Stereographic

Maciek

2

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