QGIS » QGIS Application

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

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).

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.

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

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.

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.

Here is the commit:

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

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.

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).

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... :)

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?

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.

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... :)

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.

responded to the mailing list so things are centralized

see pull request
https://github.com/qgis/Quantum-GIS/pull/147

new pull request
https://github.com/qgis/Quantum-GIS/pull/151

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).