Bug report #377

custom projection of GRASS vectors

Added by lami-faunalia-it - almost 17 years ago. Updated over 14 years ago.

Assignee:Magnus Homann
Affected QGIS version: Regression?:No
Operating System:Unix Easy fix?:No
Pull Request or Patch supplied: Resolution:fixed
Crashes QGIS or corrupts data: Copied to github as #:10436


GRASS vectors with custom projections are not recognized correctly, and are interpreted as the corresponding "normal" projection. Among other things, as a result, when they are exported, .prj file is not correct.
+proj=tmerc +lat_0=0 +lon_0=9 +k=0.999600 +x_0=1500000 +y_0=0 +ellps=intl +units=m +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68
+proj=tmerc +lat_0=0 +lon_0=9 +k=0.999600 +x_0=1500000 +y_0=0 +ellps=intl +units=m +no_defs


#1 Updated by Martin Dobias almost 17 years ago

This seems to be the same problem as discussed in #418. QGIS always needs to know the proj4 string prior to using custom projection, otherwise it won't be recognized (or will be recognized incorrectly).

Try adding this projection to custom projections first. Then using this projection in QGIS should be correct. Please confirm if that helps.


#2 Updated by lami-faunalia-it - almost 17 years ago

This is what I usually do, I setted my custom projection like "Global default projection displayed below will be used" in the Settings->Options window, when I start QGIS I load a GRASS vector from a Location with the same projection but if I look in the Properties->Metadata window I see that the output and the input projection used is " +proj=tmerc +lat_0=0 +lon_0=9 +k=0.999600 +x_0=1500000 +y_0=0 +ellps=intl +units=m +no_defs" different from my custom projection (that is the same of the Location of the vector).

If I esport to .shp the correction factors are not present in the .proj file


#3 Updated by Magnus Homann over 16 years ago

  • Status changed from Open to In Progress

If you could attach the GRASS vectors, I will have a look.

#4 Updated by Magnus Homann over 16 years ago

Need more info to fix this.

#5 Updated by Tim Sutton over 16 years ago

Moved to milestone 0.8.2 since we wont be fixing any further issues before the 0.8.1 release

#6 Updated by Magnus Homann over 16 years ago

Could you please see what projection 'ogrinfo -al <shape_file>.shp' reports?

#7 Updated by leolami - over 15 years ago

More info:
I have a GRASS Location where the proj info file is:

name: Transverse Mercator
proj: tmerc
datum: rome40
towgs84: -104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68
a: 6378388
es: 0.006722670022333322
lat_0: 0
lon_0: 9
k: 0.999600
x_0: 1500000
y_0: 0
no_defs: defined

I save this proj in custum projection of QGIS and I set it like default projection.
The projection string is:
+proj=tmerc +lat_0=0 +lon_0=9 +k=0.999600 +x_0=1500000 +y_0=0 +ellps=intl +units=m +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68

If I load a GRASS vector from a mapset in this Location and I look is properties I see taht its proj is:
+proj=tmerc +lat_0=0 +lon_0=9 +k=0.999600 +x_0=1500000 +y_0=0 +ellps=intl +units=m +no_defs
For me this is an error!

If I try to export it I have a shape where the proj file is:
PROJCSTransverse Mercator"GEOGCS["international"DATUM["D_Monte_Mario"SPHEROID["International_1924"6378388297PRIMEM["Greenwich"0]UNIT["Degree"0017453292519943295]]PROJECTION["Transverse_Mercator"]PARAMETER["latitude_of_origin"0]PARAMETER["central_meridian"9]PARAMETER["scale_factor"09996]PARAMETER["false_easting"1500000]PARAMETER["false_northing"0]UNIT["Meter]]

If I make ogr info -al I have this ouput:

INFO: Open of @/home/leo/prova/prova.shp'
using driver @ESRI Shapefile' successful.

Layer name: prova
Geometry: Point
Feature Count: 8
Extent: (1604054.308109, 4699810.841648) - (1741517.110000, 4858815.4
Layer SRS WKT:
PROJCS["Transverse Mercator",
cat: Real (11.0)
nome: String (80.0)
cat (Real) = 2
nome (String) = Lago di Sibolla
POINT (1636817.088038051035255 4853827.627969310618937)

cat (Real) = 3
nome (String) = Padule di Fucecchio
POINT (1645435.662079841829836 4849941.574495110660791)

cat (Real) = 4
nome (String) = Lame di S. Rossore
POINT (1604054.308109045494348 4838571.107950324192643)

cat (Real) = 5
nome (String) = Laguna di Orbetello
POINT (1680771.290981499478221 4699810.841648220084608)

cat (Real) = 6
nome (String) = Diaccia Botrona
POINT (1657949.371251503005624 4737513.633872816339135)

cat (Real) = 7
nome (String) = Lago di Montepulciano
POINT (1737917.001504842657596 4775048.474618563428521)

cat (Real) = 8

#9 Updated by Maciej Sieczka - about 15 years ago

Leonardo, Markus,

Aren't this ticket and #418 duplicates? Can we close either one?

#10 Updated by Paolo Cavallini over 14 years ago

This is also related to #1079

#11 Updated by Redmine Admin over 14 years ago

  • Status changed from In Progress to Closed
  • Resolution set to fixed

Seems to work correctly in revision #10899 (QGIS 1.2 unstable), PROJ.4 4.6.0, GRASS 7.0 (revision #36903).
I have tested with 2 GRASS locations:

name: Transverse Mercator
datum: rome40
datumparams: towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68
proj: tmerc
ellps: international
a: 6378388.0000000000
es: 0.0067226700
f: 297.0000000000
lat_0: 0.0000000000
lon_0: 9.0
k_0: 0.9996000000
x_0: 1500000.0000000000


name: Lat/Lon
proj: ll
datum: wgs84
ellps: wgs84
no_defs: defined

and vector reprojected with v.proj. There is no shift if the vectors from those 2 locations are displayed in QGIS. To be sure that the datum shift is realy used and I am on the right zoom level I tried to remove 'datumparams' from the first location and a shift appeared.

Important is, that QgsCoordinateReferenceSystem::findMatchingProj correctly does not find srsid now which was the case of previous versions according to comments in [https://trac.osgeo.org/qgis/ticket/418] and thus correct pure PROJ.4 string including +towgs is used. So it seems that OSRIsSame in PROJ.4 was fixed to use also towgs params.


#12 Updated by Redmine Admin over 14 years ago

OSRIsSame is not in PROJ.4, it calls OGRSpatialReference::IsSame from GDAL, but that loops through all params and last important fix I found is quite old This bug was in fact fixed in this revision [https://trac.osgeo.org/qgis/changeset/8263#file1]
(SpatialRefSys::equals changed) where OSRIsSame was introduced.


Also available in: Atom PDF