Dear list,
I try to import a shape file using v.in.ogr. This used to work fine with this same file but recently I get the following error:
Importing <filename.shp> ...
Check if OGR layer <filename> contains polygons...
Default driver / database set to:
driver: sqlite
database: $GISDBASE/$LOCATION_NAME/$MAPSET/sqlite/sqlite.db
Column name <cat> renamed to <cat_>
Importing 60 features (OGR layer <filename>)...
DBMI-SQLite driver error:
Error in sqlite3_prepare():
near ")": syntax error
DBMI-SQLite driver error:
Error in sqlite3_prepare():
near ")": syntax error
ERROR: Cannot insert new row: insert into filename values ( 1, 1, )
ERROR: Unable to import OGR datasource <filename.shp>
I was able to nail it down to empty cells in the attribute table (NULL). When filling those the error disappears.
Have there been any changes to v.in.ogr that may cause this behaviour? Or could this be related to OGR / GDAL?
Thanks a lot,
Mira
--
Dr. Mira Kattwinkel
Quantitative Landscape Ecology
Institute for Environmental Sciences
University of Koblenz-Landau
Fortstraße 7
76829 Landau
Germany
Phone: + 49 6341 280-31553
Office: Building I, Room 2.02
On Aug 15, 2017, at 10:06 AM, Mira Kattwinkel <kattwinkel-mira@uni-landau.de> wrote:
I was able to nail it down to empty cells in the attribute table (NULL). When filling those the error disappears.
Have there been any changes to v.in.ogr that may cause this behaviour? Or could this be related to OGR / GDAL?
Hi Mira,
I am not sure if it will work for you, but I have found that when I have empty cells, I can get around the issue by converting the file to import to CSV then back using ogr2ogr.
For instance (I have only done this with shape files):
#convert DBF to CSV file to properly handle blank fields
ogr2ogr -f 'CSV' fileName.csv fileName.dbf
#convert back to DBF
ogr2ogr fileName_fixed.dbf fileName.csv
#back up original DBF file before replacing:
mv fileName.dbf fileName_original.dbf
#then move “fixed” DBF file back to original filename:
mv fileName_fixed.dbf fileName.dbf
I hope this helps!
Best,
Jeshua Lacock
Founder/Engineer
<3DTOPO.com>
GlassPrinted.com
On Aug 16, 2017, at 2:36 PM, Jeshua Lacock <jeshua@3DTOPO.com> wrote:
#convert DBF to CSV file to properly handle blank fields
ogr2ogr -f 'CSV' fileName.csv fileName.dbf
Ooops - first line of the example should be this instead:
#convert DBF to CSV file to properly handle blank fields
ogr2ogr -f 'CSV' fileName.csv fileName_fixed.dbf
On Aug 16, 2017, at 2:41 PM, Jeshua Lacock <jeshua@3dtopo.com> wrote:
On Aug 16, 2017, at 2:36 PM, Jeshua Lacock <jeshua@3DTOPO.com> wrote:
#convert DBF to CSV file to properly handle blank fields
ogr2ogr -f 'CSV' fileName.csv fileName.dbf
Ooops - first line of the example should be this instead:
#convert DBF to CSV file to properly handle blank fields
ogr2ogr -f 'CSV' fileName.csv fileName_fixed.dbf
Doh! My mistake, please disregard this “correction”.
Dear Jonas,
thanks for your suggestion.
This looks like a useful workaround but it seems to be a more general issue. Is it a wanted behaviour that it is not possible without tricks to import shapes with empty table cells? As I wrote, it used to work just fine.
All the best,
Mira
Am 16.08.2017 um 22:41 schrieb Jeshua Lacock:
On Aug 16, 2017, at 2:36 PM, Jeshua Lacock <jeshua@3DTOPO.com> wrote:
#convert DBF to CSV file to properly handle blank fields
ogr2ogr -f 'CSV' fileName.csv fileName.dbf
Ooops - first line of the example should be this instead:
#convert DBF to CSV file to properly handle blank fields
ogr2ogr -f 'CSV' fileName.csv fileName_fixed.dbf
Am 16.08.2017 um 22:36 schrieb Jeshua Lacock:
On Aug 15, 2017, at 10:06 AM, Mira Kattwinkel <kattwinkel-mira@uni-landau.de> wrote:
I was able to nail it down to empty cells in the attribute table (NULL). When filling those the error disappears.
Have there been any changes to v.in.ogr that may cause this behaviour? Or could this be related to OGR / GDAL?
Hi Mira,
I am not sure if it will work for you, but I have found that when I have empty cells, I can get around the issue by converting the file to import to CSV then back using ogr2ogr.
For instance (I have only done this with shape files):
#convert DBF to CSV file to properly handle blank fields
ogr2ogr -f 'CSV' fileName.csv fileName.dbf
#convert back to DBF
ogr2ogr fileName_fixed.dbf fileName.csv
#back up original DBF file before replacing:
mv fileName.dbf fileName_original.dbf
#then move “fixed” DBF file back to original filename:
mv fileName_fixed.dbf fileName.dbf
I hope this helps!
Best,
Jeshua Lacock
Founder/Engineer
<3DTOPO.com>
GlassPrinted.com
--
Dr. Mira Kattwinkel
Quantitative Landscape Ecology
Institute for Environmental Sciences
University of Koblenz-Landau
Fortstraße 7
76829 Landau
Germany
Fon: + 49 6341 280-31553
On 17/08/17 09:07, Mira Kattwinkel wrote:
Dear Jonas,
thanks for your suggestion.
This looks like a useful workaround but it seems to be a more general
issue. Is it a wanted behaviour that it is not possible without tricks
to import shapes with empty table cells? As I wrote, it used to work
just fine.
I agree that this should "just work". Could you post a bug report, ideally with a reproducible example / example data ?
Moritz
Hello,
Has a bug been filed for this? I’m having trouble finding it on the Trac site. I’ve just run into this issue also. The homebrew install GRASS lets me import a raster that the MacPorts installation does not. It appears to be this same bug. If there is no bug report, I’ll file one.
-k.
···
On Fri, Aug 18, 2017 at 9:10 AM, Moritz Lennert <mlennert@club.worldonline.be> wrote:
On 17/08/17 09:07, Mira Kattwinkel wrote:
Dear Jonas,
thanks for your suggestion.
This looks like a useful workaround but it seems to be a more general
issue. Is it a wanted behaviour that it is not possible without tricks
to import shapes with empty table cells? As I wrote, it used to work
just fine.
I agree that this should “just work”. Could you post a bug report, ideally with a reproducible example / example data ?
Moritz
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
On Fri, Oct 20, 2017 at 11:33 AM, Ken Mankoff <mankoff@gmail.com> wrote:
Hello,
Has a bug been filed for this? I’m having trouble finding it on the Trac site. I’ve just run into this issue also. The homebrew install GRASS lets me import a raster that the MacPorts installation does not. It appears to be this same bug. If there is no bug report, I’ll file one.
This bug in v.in.ogr has been fixed on Aug 23, 2017 for trunk and relbr72.
Markus M
-k.
On Fri, Aug 18, 2017 at 9:10 AM, Moritz Lennert <mlennert@club.worldonline.be> wrote:
On 17/08/17 09:07, Mira Kattwinkel wrote:
Dear Jonas,
thanks for your suggestion.
This looks like a useful workaround but it seems to be a more general
issue. Is it a wanted behaviour that it is not possible without tricks
to import shapes with empty table cells? As I wrote, it used to work
just fine.
I agree that this should “just work”. Could you post a bug report, ideally with a reproducible example / example data ?
Moritz
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
On Fri, Oct 20, 2017 at 12:14 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:
On Fri, Oct 20, 2017 at 11:33 AM, Ken Mankoff <mankoff@gmail.com> wrote:
Hello,
Has a bug been filed for this? I'm having trouble finding it on the Trac
site. I've just run into this issue also. The homebrew install GRASS lets me
import a raster that the MacPorts installation does not. It appears to be
this same bug. If there is no bug report, I'll file one.
This bug in v.in.ogr has been fixed on Aug 23, 2017 for trunk and relbr72.
... available in GRASS GIS 7.2.2 (released Sep 20, 2017), see also
https://trac.osgeo.org/grass/wiki/Release/7.2.2-News#Minormodulechanges
--> v.in.ogr
HTH,
markusN