Bug report #2092

fTools export/add geometry tool should use source dataset CRS as target dataset CRS

Added by marisn - almost 10 years ago. Updated almost 10 years ago.

Status:Closed
Priority:Low
Assignee:cfarmer -
Category:Projection Support
Affected QGIS version: Regression?:No
Operating System:Gentoo Easy fix?:No
Pull Request or Patch supplied: Resolution:worksforme
Crashes QGIS or corrupts data: Copied to github as #:12152

Description

Start new project (project CRS is set to WGS84);

Add some vector data source with different CRS (e.g. EPSG:25884);

Launch Vector (fTools)-> Geometry-> Export/Add geometry colums;

Select added vector as input, specify output and press OK.

Resulting shapefile has correct coordinate data in database columns, still shapefiles CRS is defined as WGS84 but data (vector point coordinates) still have same values as in input data source (i.e. EPSG:25884). Thus anyone who forgets to enable "CRS change on fly" option gets bogous shapefile as result. Using source CRS for destination when "on the fly" reprojection is not enabled is a safe fail-back mechanism in such cases.

Tested on QGIS 1.4.0 r12103M with fTools 0.5.10.

History

#1 Updated by cfarmer - almost 10 years ago

Replying to marisn:

All fTools functions should use the input dataset CRS for all output datasets. However, this means that, for example, shapefiles with no .prj file will automatically default to the project default CRS (often WGS84). In other words, the fTools functions ignore any manually specified CRS info. Is it possible that this is the cause for the misspecified shapefile? 'On the fly' option should not affect any fTools functions...

#2 Updated by marisn - almost 10 years ago

Replying to [comment:2 cfarmer]:

Replying to marisn:

All fTools functions should use the input dataset CRS for all output datasets. However, this means that, for example, shapefiles with no .prj file will automatically default to the project default CRS (often WGS84). In other words, the fTools functions ignore any manually specified CRS info. Is it possible that this is the cause for the misspecified shapefile? 'On the fly' option should not affect any fTools functions...

fTools doesn't use input CRS for output. Target CRS is determined by settings in "Settings" -> "Options" -> "CRS". By default (?) it will use WGS84 as target CRS and there is no such option as "input CRS".

I have created more generic enhancement ticket #2093 about project CRS handling in QGIS might solve also this issue, still if fTools result generation is not affected by OTFR, there still is a room for bogus results as described per this bug. Thus input CRS as target CRS is the safest option.

#3 Updated by cfarmer - almost 10 years ago

fTools doesn't use input CRS for output. Target CRS is determined by settings in "Settings" -> "Options" -> "CRS". By default (?) it will use WGS84 as target CRS and there is no such option as "input CRS".

In actual fact, fTools does indeed use the input CRS for all outputs, so it is possible that the issue reported here is a more generic CRS issue. Perhaps QGIS is not properly recognizing the input CRS, and is therefore unable to output it correctly? Would it be possible to attach the problem shapefile to this ticket (or a more generic CRS ticket)?

Regards,

Carson

#4 Updated by marisn - almost 10 years ago

  • Resolution set to worksforme
  • Status changed from Open to Closed

Hm. I upgraded and recompiled trunk to version r12169M and also can not reproduce problem anymore. Output layers get correct CRS. Seems to be some minor glitch fixed by some commit between 12103 and 12169 (or it's a Heisenbug).

Also available in: Atom PDF