(moved to GRASS-dev)
Topic: v.rast.stats error message
On Fri, Oct 14, 2016 at 8:35 PM, Helmut Kudrnovsky <hellik@web.de> wrote:
ERROR: Unable to add column <1_average DOUBLE PRECISION>.
ERROR: Adding columns failed. Exiting.AFAIR in SQL column names starting with a number isn't allowed.
Is there any Python wrapper around Vect_legal_filename() which could
be used here to generate a better error message?
Markus
On Thu, Oct 20, 2016 at 4:11 PM, Markus Neteler <neteler@osgeo.org> wrote:
(moved to GRASS-dev)
Topic: v.rast.stats error message
On Fri, Oct 14, 2016 at 8:35 PM, Helmut Kudrnovsky <hellik@web.de> wrote:
ERROR: Unable to add column <1_average DOUBLE PRECISION>.
ERROR: Adding columns failed. Exiting.AFAIR in SQL column names starting with a number isn't allowed.
Is there any Python wrapper around Vect_legal_filename() which could
be used here to generate a better error message?
There is only wrapper for G_legal_filename I know of. It would have to
be added. Maybe worth a ticket?
Anna
Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On 20/10/16 22:11, Markus Neteler wrote:
(moved to GRASS-dev)
Topic: v.rast.stats error message
On Fri, Oct 14, 2016 at 8:35 PM, Helmut Kudrnovsky <hellik@web.de> wrote:
ERROR: Unable to add column <1_average DOUBLE PRECISION>.
ERROR: Adding columns failed. Exiting.AFAIR in SQL column names starting with a number isn't allowed.
Is there any Python wrapper around Vect_legal_filename() which could
be used here to generate a better error message?
Even though a Python wrapper for Vect_legal_filename would be useful, it wouldn't help here as the problem is the attribute column name, not the filename.
Moritz
Yes, but in vector maps starting with a number or having a "." in the name is not allowed. Also SQL keywords are excluded...
See: https://grass.osgeo.org/programming7/legal__vname_8c_source.html
So, the same logic may be used to check column names (I guess that is what Markus intended).
However, it seems that for raster maps more special characters are legal and also v.in.ogr uses layer names from the original data source which can cause conflicts in SQL DB backends...
Maybe legal file names, column and table handling is something to re-consider for GRASS 8?
Cheers
Stefan
-----Original Message-----
From: grass-dev [mailto:grass-dev-bounces@lists.osgeo.org] On Behalf Of Moritz Lennert
Sent: 21. oktober 2016 09:34
To: Markus Neteler <neteler@osgeo.org>; GRASS developers list <grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] [GRASS-user] v.rast.stats ERROR
On 20/10/16 22:11, Markus Neteler wrote:
(moved to GRASS-dev)
Topic: v.rast.stats error message
On Fri, Oct 14, 2016 at 8:35 PM, Helmut Kudrnovsky <hellik@web.de> wrote:
ERROR: Unable to add column <1_average DOUBLE PRECISION>.
ERROR: Adding columns failed. Exiting.AFAIR in SQL column names starting with a number isn't allowed.
Is there any Python wrapper around Vect_legal_filename() which could
be used here to generate a better error message?
Even though a Python wrapper for Vect_legal_filename would be useful, it wouldn't help here as the problem is the attribute column name, not the filename.
Moritz
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On 21/10/16 10:11, Blumentrath, Stefan wrote:
Yes, but in vector maps starting with a number or having a "." in the
name is not allowed. Also SQL keywords are excluded... See:
https://grass.osgeo.org/programming7/legal__vname_8c_source.html
Yes, I know. This is because by default attribute tables will have the same name as the vector map and so the map name is checked for that. Another option would be to alter the table name, while keeping the map name...
So, the same logic may be used to check column names (I guess that is
what Markus intended).
Yes, a Vect_legal_columnname() would probably be quite similar.
However, it seems that for raster maps more special characters are
legal and also v.in.ogr uses layer names from the original data
source which can cause conflicts in SQL DB backends...
That's why the option of not having table names identical to map names might be more flexible, but it creates a bit of confusion when people assume that identity of names.
Maybe legal file names, column and table handling is something to
re-consider for GRASS 8?
Sure.
How much of a problem is there really, though ? What do you propose needs changing ?
Moritz
-----Original Message-----
From: Moritz Lennert [mailto:mlennert@club.worldonline.be]
Sent: 21. oktober 2016 11:30
However, it seems that for raster maps more special characters are
legal and also v.in.ogr uses layer names from the original data
source which can cause conflicts in SQL DB backends...That's why the option of not having table names identical to map names
might be more flexible, but it creates a bit of confusion when people
assume that identity of names.
Having map names and table names - as far as possible - identical is very convenient. I would not change that.
Maybe legal file names, column and table handling is something to
re-consider for GRASS 8?Sure.
How much of a problem is there really, though ? What do you propose
needs changing ?Moritz
No idea how much of a problem that is in praxis. Table or column name issues pop up here and there and are usually fixed with a simple workaround. Users can always cause trouble for themselves when managing attribute data through db.execute and the SQL which is supported by their backend. The latter often allows for things which can cause problems for GRASS modules.
Furthermore, one can of course also get data where column names are not compliant with GRASS standards....
The current handling of column and table names regarding special characters, upper/lower case is not really consistent, which is untypical for GRASS (at least from my experience).
However, e.g. quoting all SQL identifiers would require significant changes (as quoting is also backend depending) and involves likely quite some work. So, it is probably not worth changing anything. I shall have a look at the documentation, if limitations of SQL in GRASS should be made more explicit there...
Kind regards,
Stefan