Bug report #4549

Spatialite and Shapefile new layer dialog: CRS selection non standard (also elsewhere)

Added by Paolo Cavallini almost 8 years ago. Updated almost 8 years ago.

Status:Closed
Priority:Normal
Assignee:-
Category:GUI
Affected QGIS version:master Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:fixed
Crashes QGIS or corrupts data:No Copied to github as #:14463

Description

The dialog for creating a new SpatiaLite layer is quite different from the standard QGIS stuff: selecting a CRS does not open the projection widget, and wrong labels are used.
Shapefile new layer shows the proj4 syntax instead of the authority, code and name, as it happens in the layer properties.
Easy to fix, and nice for the user.

Associated revisions

Revision 270655dc
Added by Alexander Bruy almost 8 years ago

[BACKPORT] use native projection selector in New SpatiaLite layer
dialog (completely fix #4549)

Revision c1eea906
Added by Alexander Bruy almost 8 years ago

[BACKPORT] use native projection selector in New SpatiaLite layer
dialog (completely fix #4549)

History

#1 Updated by Alexander Bruy almost 8 years ago

See also #4584

#2 Updated by Alexander Bruy almost 8 years ago

Maybe, I'm wrong. I think New SpatiaLite layer dialog uses non-standard CRS selector because each SpatiaLite db has it's own spatial-ref-sys table with all available CRSes. And some CRS available in QGIS can be missed in this table.

#3 Updated by Paolo Cavallini almost 8 years ago

NOt that I know of:it should be the standard EPSG db; oh, well, in QGIS we also have IGN: so better asking SL devs to add 'our' proj; it is straightforward

#4 Updated by Giovanni Manghi almost 8 years ago

  • Target version set to Version 1.7.4

#5 Updated by Alexander Bruy almost 8 years ago

I asked Sandro about used crs'es used in SpatiaLite. Here is his answer

>2. is it safe (and possible) to use native QGIS crs database for SpatiaLite layers?
I suppose that generally speaking both crs datasets are one and the same, because both them are mainly PROJ.4 derivatives. Anyway, some small difference may exist here and there. BTW I suppose that the same identical problem will affect PostGIS, and possibly any other Spatial DBMS. All them internally use their own spatial_ref_sys table; and this one could be not exactly conformat to QGIS own expectations. Which solution QGIS adopts for PostGIS ? I suppose that the same should be applied for SpatiaLite as well, thus implementing a consistent user interface for both DBMSes.

From programmatic point of view it is possible to replace custom dialog with QGIS projection selector. But what about possible differences in CRS definitions? We can't guarantee that they are the same. If this is acceptable I can try to implement projection selector in New SL Layer dialog.

Also I look at the SPIT plugin and found that it uses another (third) approach ­— EPSG code selected with spinbox.

#6 Updated by Paolo Cavallini almost 8 years ago

Why can't we share all the same list? Having multiple, slightly different, lists seems an unnecessary complication. I think Sandro Furieri (esseffe) should be added to this discussion, but I can't find him on the list. As for SPIT, I think it should be deprecated as soon as DB Manager reaches master.

#7 Updated by Giovanni Manghi almost 8 years ago

Paolo Cavallini wrote:

Why can't we share all the same list? Having multiple, slightly different, lists seems an unnecessary complication. I think Sandro Furieri (esseffe) should be added to this discussion, but I can't find him on the list. As for SPIT, I think it should be deprecated as soon as DB Manager reaches master.

There are users that are registered in this very same Redmine instance (you can see them in the admin panel), but do not show when filing tickets: example sandro furieri (esseffe) and Marco Bernasocchi. I believe I already wrote something about this issue.

#8 Updated by Alexander Bruy almost 8 years ago

Inconsistency in New Shapefile dialog already fixed in bde042705a

#9 Updated by Sandro Santilli almost 8 years ago

Backport in 1.7 branch is 8b77d31df77db7ff69dc7b4fde0f3375b0dbf4ca, anything left to do here ?

#10 Updated by Alexander Bruy almost 8 years ago

  • Status changed from Open to Closed
  • Affected QGIS version set to master
  • % Done changed from 0 to 100

#11 Updated by Alexander Bruy almost 8 years ago

  • Crashes QGIS or corrupts data set to No

Also backported to 1.7 and 1.8

#12 Updated by Paolo Cavallini almost 8 years ago

  • Subject changed from Spatialite and Shapefile new layer dialog: CRS selection non standard to Spatialite and Shapefile new layer dialog: CRS selection non standard (also elsewhere)
  • Status changed from Closed to Open

Same also in other dialogs, e.g. Vector>Define current projection>Input spatial reference system and below

#13 Updated by Alexander Bruy almost 8 years ago

  • % Done changed from 100 to 50

fTools part fixed in 8936f4cb3f and 42a09af84b and backported

#14 Updated by Sandro Santilli almost 8 years ago

Alex: which commit belongs to which branch ? I dont' think it is possible to tell a backported commit from an original commit by only looking at the repository (I'll be happy to be contraddicted)

#15 Updated by Alexander Bruy almost 8 years ago

For 1.7 commits are 818ba26f72, fd2a80db33.
For 1.8 commits are commit:43f6651b6b, commit:8f97a2864a.

I think we can close this tickets because there is also almost the same #4584.

#16 Updated by Paolo Cavallini almost 8 years ago

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

Also available in: Atom PDF