make browser remove the file extensions when dragging and dropping layers into the canvas

[qgib]

Author Name: Giovanni Manghi (@gioman)
Original Redmine Issue: 5621
Affected QGIS version: master
Redmine category:browser

---

subject says it all

---

• mock1.jpg (Etienne Tourigny)

[qgib]

Author Name: Etienne Tourigny (@etiennesky)

---

I am probably responsible for that... I thought it was more explanatory to know what the source is (i.e. tiff vs. netcdf).

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

Etienne Tourigny wrote:

I am probably responsible for that... I thought it was more explanatory to know what the source is (i.e. tiff vs. netcdf).

Hi Etienne,

it probably doesn't make much difference when adding layers to the canvas (on the contrary as you say it can be useful) but when dragging and dropping layers into DB manager it should be avoided (postgis and spatialite tables names do include ".shp" by default).

[qgib]

Author Name: Giuseppe Sucameli (@brushtyler)

---

Giovanni Manghi wrote:

Etienne Tourigny wrote:

I am probably responsible for that... I thought it was more explanatory to know what the source is (i.e. tiff vs. netcdf).

it probably doesn't make much difference when adding layers to the canvas (on the contrary as you say it can be useful) but when dragging and dropping layers into DB manager it should be avoided (postgis and spatialite tables names do include ".shp" by default).

... not only when dropping it to DBManager, but also dropping it to the Browser itself (e.g. to a PG connection).
Anyway, in this moment that behavior differs from one we have adding a layer by "Add Vector layer" button.

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

what about allowing have the extensions added as an option in qgis general properties?

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

Giovanni Manghi wrote:

what about allowing have the extensions added as an option in qgis general properties?

In general I'm in favour of having something that allows to recognise the type of datasource of the layers in the TOC.

[qgib]

Author Name: Etienne Tourigny (@etiennesky)

---

Giovanni Manghi wrote:

Etienne Tourigny wrote:

I am probably responsible for that... I thought it was more explanatory to know what the source is (i.e. tiff vs. netcdf).

Hi Etienne,

it probably doesn't make much difference when adding layers to the canvas (on the contrary as you say it can be useful) but when dragging and dropping layers into DB manager it should be avoided (postgis and spatialite tables names do include ".shp" by default).

I guess it should be modified for that case.

I had not even imagined that worked, so I didn't think about it. The problem is that a qgsdataitem has a "name" attribute, and that cannot change according to the destination.

A solution would be to filter the name (and remove the extension) at the destination, or perhaps add the extension only in the canvas, instead of in the browser.

[qgib]

Author Name: Etienne Tourigny (@etiennesky)

---

Here is the

https://github.com/qgis/Quantum-GIS/blob/a2b80be89b1d183cfeb69bc019e6fcaddb4bb404/src/providers/gdal/qgsgdaldataitems.cpp

It's probably better not to have an option to add the extension, but have a consistent behaviour.

Which is best?

1. Always adding the extension and stripping it where necessary
2. Never adding the extension and adding it in the legend

[qgib]

Author Name: Etienne Tourigny (@etiennesky)

---

I guess for rasters it's ok to always have the extension, right? Because there are no other D&D operations. Unless I am overlooking something (like other providers such as grass, which I don't use).

Then this discussion only applies to vectors, which can have various layers for a given file.
In this case, it might be easier and more consistent to never add the extension for all vector layers. Does this make sense?

The following change in src/providers/ogr/qgsogrdataitems.cpp would do the trick:

-  QString name = info.fileName();
+  QString name = info.completeBaseName();

However, this brings an inconsistency between raster and vector layer display in the legend (which happens anyway when you add vectors from DBs).

Also, I like to be able to see the file extension in the browser, which this change removes.

It also is not possible for shapes inside zipfiles, because filenames are listed with extension. But this is not really a big deal, more like an exception than the rule.
For reference, try the testzip.zip file in the tests/testdata dir of the source.

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

2. Never adding the extension and adding it in the legend

I like more this because is a feature often requested by users (eventually adding the extension after the layer name as "layername (ext)" and not as "layername.ext" -> just an idea).

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

Etienne Tourigny wrote:

I guess for rasters it's ok to always have the extension, right? Because there are no other D&D operations. Unless I am overlooking something (like other providers such as grass, which I don't use).

actually there is... DB Manager (now part of qgis core) supports D&D for PostGIS rasters... :)

[qgib]

Author Name: Giuseppe Sucameli (@brushtyler)

---

Etienne Tourigny wrote:

have a consistent behaviour. Which is best?

1. Always adding the extension and stripping it where necessary
2. Never adding the extension and adding it in the legend

I fully agree that displaying the extension in the browser is necessary,
but why have the extension displayed in the legend is useful?
Once loaded a vector layer is just a vector layer.

So I'd add a third choice:
3) Never adding the extension

Unfortunately I already know I don't understand what the user needs... :)

Having more opinions would be good but having a look at tickets is not so popular, so
could you ask for it in ML, please?

[qgib]

Author Name: Giuseppe Sucameli (@brushtyler)

---

Giovanni Manghi wrote:

Etienne Tourigny wrote:

I guess for rasters it's ok to always have the extension, right? Because there are no other D&D operations. Unless I am overlooking something (like other providers such as grass, which I don't use).

actually there is... DB Manager (now part of qgis core) supports D&D for PostGIS rasters... :)

But not from the browser... althought I'm working on making possible the
import of rasters by drag'n'drop from Browser to DBManager.

BTW I still think extensions are senseless when a layer is loaded.

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

Giuseppe Sucameli wrote:

Etienne Tourigny wrote:

have a consistent behaviour. Which is best?

1. Always adding the extension and stripping it where necessary
2. Never adding the extension and adding it in the legend

I fully agree that displaying the extension in the browser is necessary,
but why have the extension displayed in the legend is useful?
Once loaded a vector layer is just a vector layer.

So I'd add a third choice:
3) Never adding the extension

Unfortunately I already know I don't understand what the user needs... :)

real life projects tend to be large, with many, many layers.

Usually a project is made of many different datasources and data types, so in a typical project you may find, shapes, gpx, kml, gml, postgis, spatialite, tiffs, ecws. sid, GRASS vectors and rasters, etc...

for example not all the layers are editable, because the provider does not allow it or because the user is missing permissions...

so I guess now is more clear why IS important to have at least an option to allow see what kind of vector/raster is a layer in the TOC... :)

[qgib]

Author Name: Radim Blazek (@blazek)

---

Rasters are also going to support D&D.

Rasters and vectors must be consistent.

File extension must be displayed in the browser because more formats with the same base name may be present (.shp, .gml ...).

I would prefer a base name without an extension in the legend by default. I believe that in most cases a layer of the same base name is added just once. I have also often the same layer in many formats, but most people don't, I think.

Instead of an option for file extension to be part of a layer name in the legend, the legend could have an optional (for experts) additional column with data source format.

[qgib]

Author Name: Etienne Tourigny (@etiennesky)

---

responded to the mailing list so things are centralized

[qgib]

Author Name: Etienne Tourigny (@etiennesky)

---

prototype using 2nd column for file type

---

• 4473 was configured as mock1.jpg

---

• mock1.jpg (Etienne Tourigny)

[qgib]

Author Name: Etienne Tourigny (@etiennesky)

---

see pull request
#147

[qgib]

Author Name: Etienne Tourigny (@etiennesky)

---

new pull request
#151

[qgib]

Author Name: Giuseppe Sucameli (@brushtyler)

---

Etienne,
I've merged your pull request (the newer one, #151) into master.
Thanks.

---

• resolution was changed from to fixed
• status_id was changed from Open to Closed

[qgib]

Author Name: Giuseppe Sucameli (@brushtyler)

---

Summary:
the file extension is still displayed in the browser for GDAL/OGR items, but it was removed from the layer name (e.g. legend).