Bug report #14429
Processing toolbox: GRASS GIS 7 issues
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: | - | ||
| Category: | Processing/GRASS | ||
| Affected QGIS version: | 2.14.0 | Regression?: | No |
| Operating System: | Easy fix?: | No | |
| Pull Request or Patch supplied: | No | Resolution: | worksforme |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 22408 |
Description
When using a GRASS GIS 7 command all columns having names longer than ten characters get lost.
In my case the output layer always has a generated CRS (+proj=tmerc +lat_0=0 +lon_0=16.33333333333333 +k=1 +x_0=0 +y_0=-5000000 +ellps=bessel +units=m +no_defs). The CRS of the project and the input layers is MGI / Austria GK East (+proj=tmerc +lat_0=0 +lon_0=16.33333333333333 +k=1 +x_0=0 +y_0=-5000000 +ellps=bessel +towgs84=577.326,90.129,463.919,5.137,1.474,5.297,2.4232 +units=m +no_defs).
History
#1
Updated by Anita Graser about 8 years ago
- Category changed from GRASS to Processing/GRASS
#2
Updated by Médéric RIBREUX about 8 years ago
- Status changed from Open to Feedback
Hello, bug triage...
could you provide more details about this:
- which GRASS7 algorithm(s) failed ?
- some sample data to reproduce the bug ?
Some algorithms don't export attributes but some others need to export fields.
The 10 characters limit is the limit of the Esri Shapefile for field names and GRASS algorithms use this file format by default for results exports.
It is perfectly normal (well on a file format side) to have the attributes names truncated to 10 characters. But if the attributes are not exported, this seems to be a real bug.
If your problem is related to the file format, we need to open a feature request to make Processing GRASS algorithms allowing different file formats for output (like other Processing algorithms).
I think that the CRS problem is not related to the attributes problem so it would be better to open a second bug with much more details on this:
- which Processing GRASS7 algorithms have been used or seems to be affected (not an exhaustive list but what you've already found) ?
- Could you also provide some sample data to reproduce the bug ?
Thanks for your feedback on this...
#3
Updated by R. R. about 8 years ago
- File 05_overlay_crs.png added
- File 04_overlay_attribute_table.png added
- File v_overlay_log__error_6_ added
- File 03_grass_gis_7_v_overlay.png added
- File 02_layer02_attribute_table.png added
- File 01_layer01_attribute_table.png added
I've only tested the v.overlay tool. The input layers are PostGIS tables, the output layer is a temporary file. Please check the attached screenshots for more details.
I've also noticed that 'SHP file (*.shp)' is the only v.overlay 'Save to file...' option that's working. Well, the bugs are not related. I'll open separate bug reports.
#4
Updated by Médéric RIBREUX about 8 years ago
- Resolution set to worksforme
- Status changed from Feedback to Closed
Hello,
I have tried to reproduce the bug.
I have found that the main problem comes from v.out.ogr (a GRASS module for exporting to OGR format).
When you export to Shapefile format and you have attributes with more than 10 characters, those attributes are not exported and GRASS reports an error:
ERROR 6: Failed to add field named 'the_name_of_the_too_long_attribute'
I have opened a ticket into GRASS bugtracker for this.
On the QGIS side, GRASS Processing use only shapefile format for exports and this is a problem. Other Processing parts (QGIS algorithms for example) allow you to choose in much more formats.
I have opened the feature request #14475 for this probem.
Ok, I am now closing this bug because this is now an upstream reported GRASS problem and because we have a feature request for QGIS side.
Feel free to open a new bug for the CRS problem (same category: Processing (SEXTANTE)/GRASS).
#5
Updated by R. R. about 8 years ago
Thanks for your efforts!
Bug report #14499: GRASS GIS 7 CRS issue