3

In QGIS, I am getting an error message every time I edit a node. Also, there is a lot of lag in performance. The message is:

"Transform error caught: forward transform of (10990.308086, 100347.255186) PROJ.4: +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs +to +proj=utm +zone=54 +south +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs Error: latitude or longitude exceeded limits"

I hae been very careful to Set Layer CRS on all layers, to GDA94, or, in the case of the two raster layers, GDA94/MGA zone 54 (which is also the project CRS). This should all work. Shouldn't it?

But it is odd, that when I was using my legacy MapInfo TAB layers, they would show up in QGIS with weird projections that were not the projection in the TAB files, like some old Dutch projection and, more usually, NAD projections. I saved those layers as SHP files (resetting the projection to GDA94) to see if QGIS works better with SHP. And it did, for a few hours. Now the error messages are back. What is wrong? Is this a QGIS bug? Or is there a backoffice setting that I've missed?


EDIT: ADDITIONAL INFORMATION.

Below I provide the sequence of steps to create the transform error from a clean start.

  1. Open QGIS
  2. Set these options for Project CRS:
    • "Automatically enable OTF if layers have different CRS"
    • Do not "enable OTF by default"
    • Start new projects with GDA94
    • "When new layer is created, use project CRS."
  3. Add raster layer 76949_zone54_mga.ecw (www.ga.gov.au/cedda/maps/1058)
  4. Look at Project properties, witness that "OTF by default" is disabled, and CRS has changed to greyed-out MGA94 zone 54 (the CRS of the raster file)
  5. Add shapefile layer (graticule from "Hamilton Special" GA 250K topo), downloaded from GA website.
    • Note that its .prj file contents are: GEOGCS["GCS_GDA_1994",DATUM["D_GDA_1994",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]]
    • That is, it has a CRS of GDA94. The file loads and displays correctly. Look at project properties, and witness that it has automatically enabled OTF projection.
  6. Create new shapefile point layer, with CRS selected as GDA94
  7. Edit new shp layer, by making two points.
  8. Exit edit mode and save.
  9. Look at message log: two error messages logged with following info:

Transform error caught: forward transform of (0.000000, 0.000000) PROJ.4: +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs +to +proj=utm +zone=54 +south +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs Error: latitude or longitude exceeded limits

That is a replicable error, and all files used are pristine Geoscience Australia product, unquestionably ok. The fault lies somewhere in QGIS or in the settings used.

Yes I could create the new file in a CRS of MGA_zone54 (to follow the raster projection in this case), and that will work ok. But I would prefer that my vector files that aren't tied to a particular UTM zone. Anyway, GDA and MGA zone 54 are based on the same datum and ellipsoid, they are two sides of the same coin. MGA is just the projection of GDA94 longlat data.

So what is the problem?

  • Which QGIS version? 32bit/64bit? Which Operating System? – AndreJ Jan 30 '14 at 16:33
  • I get this replicable error only in QGIS Lisboa, not in Dufour 32bit or qgis-dev. 64bit does not like ecw files. The reason is simple: You create a new empty shapefile, and QGIS tries to zoom to 0;0, but this point (in degrees it is offshore to Nigeria) can not be displayed in UTM zone 54 because it is on the backside of the globe. But this causes no crash, QGIS simply does nothing. Saving the points works without further complaints. – AndreJ Jan 30 '14 at 17:41
  • QGIS 2.01 64bit, winows 7, installed from QGIS-OSGeo4W-2.0.1-3-Setup-x86_64.exe. The ecw file loads without problem. – IanS Jan 30 '14 at 20:55
  • QGIS 2.01 64bit, Windows 7, installed from QGIS-OSGeo4W-2.0.1-3-Setup-x86_64.exe. The ecw file loads without problem. I just followed again those steps that I posted, and get the same problem. So after specifying all the (apparently correct) parameters, QGIS still can't figure where to draw and wants to draw in Nigeria? That's not good. So what else does one need to do to get QGIS working properly? – IanS Jan 30 '14 at 21:02
  • I don't trust the 64-bit version yet; the 32-bit Dufour has no problems on my side. I had some issues with point shapefiles when saving after each edit (which took longer for each saving until restarting QGIS), but got rid of this after moving the data into a spatialite database. QGIS 2.2 will be around soon, maybe your problem has already a fix. – AndreJ Jan 31 '14 at 5:06
3

You are trying to reproject coordinates of 10990.308086, 100347.255186 from longlat to UTM.

This can not work, because the input of longlat has to be between +/- 180/90° degrees.

I guess you have used Set Layer CRS where you should have used Save As... to reproject the coordinates.

Set Layer CRSonly changes the CRS info, but does not compute any coordinate reprojections. In most cases, it is misused for the later.

Turn On-the-fly reprojection off, investigate the extent of your layers by looking at the metadata tab of the layer properties, and decide which layers have a false CRS assigned.


EDIT

This is what I get with the extents of your shapefile, added to a MGA94zone 54 project, raster and MGA grid:

enter image description here

  • I had already used Save As to reproject coords. That is why I was surprised I had trouble. But still problems had come up. There are too many controls over the coord system in QGIS, and too many ways into it. It is very confusing. Myriad permuations are possible in choosing different layer options and project options. All in all, without devoting oneself entirely to very deep understanding of this tiny facet of the world's knowledge, it just comes down to luck. Maybe it will work today, maybe not. If not, twiddle some settings and see. All I can say is, I never had these problems in MapInfo. – IanS Jan 30 '14 at 9:50
  • Yes, definitely. If background raster is MGA94 z54, then project CRS must be the same, whether On-the-Fly enabled or not. So the prohject has that one layer to begin with, and both layer and project CRS are MGA 54. Then add a vector shap file which has a .prj file saying it is GDA94. On-the-Fly still enabled. Try to edit the vector file. It locks qgis up. It's a transform error. Ok, ctrl-alt-del, satrt over. Same parameters, only the vector .shp file has a .prj file of MGA z54. Try to edit, all ok, no problem. Conclusion: QGIS cannot handle editing of layers that have a different .prj. – IanS Jan 30 '14 at 10:09
  • QGIS can handle layers with different CRS, but it expects the information in the .prj file to be correct. A shapefile with coordinates in meters, but a .prj file telling it is degrees will cause QGIS to throw errors or crash. – AndreJ Jan 30 '14 at 10:44
  • Might be something to what you say. But the file saves-as into a new .shp with a new layer crs defined as GDA94. It should therefore have longlat extents. The layer metadata is: Extents In layer SRS units xMin,yMin 141.369,-38.305 : xMax,yMax 144.623,-36.7527 Layer SRS +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs ; ok, BUT the .prj contents are: GEOGCS["GDA94",DATUM["D_GDA_1994",SPHEROID["GRS_1980",6378137,298.257222101]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]] which looks like metres eastings and northings for somewhere (not my area though). WHY?? Crazy. – IanS Jan 30 '14 at 11:04
  • To clarify, these copypastes are for the file that was set up as a longlat file (GDA94). So I expect it to have longlat extents. This is the file that will not edit in a project that is set as MGA zone 54, even with OTF enabled. – IanS Jan 30 '14 at 11:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.