"v.in.ogr -i" throws an error when importing a GeoJSON file containing a single point.

[pmav99]

I was trying to use v.import and I think I run into a bug. AFAIK the error is caused by v.in.ogr -i.

In this container I was using [67592] so this should be present in 7.0.3.

These are the steps to reproduce it:

1. Create a file with the following contents and save it e.g. as ~/input.json:

   {
       "type": "MultiPoint",
       "coordinates": [
           [
               -105.01621,
               39.57422
           ],
           [
               -80.6665134,
               35.0539943
           ]
       ]
   }
   

2. Create a new GRASS location:

   grassuser@4b5e00241b91:~$ grass -e -c EPSG:4326 ~/locations/epsg_4326 
   WARNING: Default locale settings are missing. GRASS running with C locale.
   WARNING: Searched for a web browser, but none found
   Cleaning up temporary files...
   Creating new GRASS GIS location/mapset...
   Cleaning up temporary files...
   

3. Start a new GRASS session using the location you just created.

   grassuser@4b5e00241b91:~$ grass --text ~/locations/epsg_4326/PERMANENT/
   WARNING: Default locale settings are missing. GRASS running with C locale.
   WARNING: Searched for a web browser, but none found
   Cleaning up temporary files...
   Starting GRASS GIS...
   GRASS 7.0.3svn (epsg_4326):~ >
   

4. Create a new location using the JSON file you created on step 1:

   GRASS 7.0.3svn (epsg_4326):~ > v.in.ogr input=~/my_input.json -i location=example_multi_point 
   WARNING: All available OGR layers will be imported into vector map
            <OGRGeoJSON>
   Location <example_multi_point> created
   GRASS 7.0.3svn (epsg_4326):~ > 
   

As we can see the location was created without problems.

5. Replace the contents of the file we created on step 1 with the following snippet (in this case we are importing just a single point):

   {
       "type": "Point",
       "coordinates": [0, 0]
   }
   

6. Try to create a location using the new JSON file:

   GRASS 7.0.3svn (epsg_4326):~ > v.in.ogr input=~/my_input.json -i location=example_single_point
   WARNING: All available OGR layers will be imported into vector map
            <OGRGeoJSON>
   Location <example_single_point> created
   ERROR: Syntax error in cell header
   

As you can see, even though the location gets created, we get an ERROR.

[neteler]

Replying to pmav99:

I was trying to use v.import and I think I run into a bug. AFAIK the error is caused by v.in.ogr -i.

In this container I was using [67592] so this should be present in 7.0.3.

These are the steps to reproduce it:

1. Create a file with the following contents and save it e.g. as ~/input.json:

I did that and simply tried with OGR:

ogrinfo -so ~/input.json
ERROR 1: GeoJSON parsing error: quoted object property name expected (at offset 1)
ERROR 4: Failed to read GeoJSON data
ERROR 1: GeoJSON parsing error: quoted object property name expected (at offset 1)
ERROR 4: Failed to read GeoJSON data
FAILURE:
Unable to open datasource `/home/neteler/input.json' with the following drivers.
  -> PCIDSK
  -> JP2OpenJPEG
  -> JPEG2000
  -> PDF
  -> ESRI Shapefile
...
  -> GeoJSON
  -> Interlis 1
...

Are you sure that this is valid syntax? Since OGR cannot read it, also v.in.ogr cannot.

[pmav99]

Even though I cannot really comment whether this is actually valid syntax according to the spec (​| GeoJSON linters accept it though), on my machines ogrinfo opens the file without problems:

On Ubuntu 14.04:

grassuser@c732646a6bda:~/repo$ ogrinfo  --version
GDAL 1.11.3, released 2015/09/16

grassuser@c732646a6bda:~/repo$ ogrinfo -so /tmp/example.json 
ERROR 4: GeoJSON Driver doesn't support update.
Had to open data source read-only.
INFO: Open of `/tmp/example.json'
      using driver `GeoJSON' successful.
1: OGRGeoJSON (Point)

grassuser@c732646a6bda:~/repo$ ogrinfo -al /tmp/example.json 
ERROR 4: GeoJSON Driver doesn't support update.
Had to open data source read-only.
INFO: Open of `/tmp/example.json'
      using driver `GeoJSON' successful.

Layer name: OGRGeoJSON
Geometry: Point
Feature Count: 1
Extent: (0.000000, 0.000000) - (0.000000, 0.000000)
Layer SRS WKT:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0,
        AUTHORITY["EPSG","8901"]],
    UNIT["degree",0.0174532925199433,
        AUTHORITY["EPSG","9122"]],
    AUTHORITY["EPSG","4326"]]
OGRFeature(OGRGeoJSON):0
  POINT (0 0)

On Archlinux using a newer GDAL version:

$ ogrinfo --version
GDAL 2.0.1, released 2015/09/15

$ ogrinfo -so /tmp/example.json
ERROR 4: GeoJSON Driver doesn't support update.
Had to open data source read-only.
INFO: Open of `/tmp/example.json'
      using driver `GeoJSON' successful.
1: OGRGeoJSON (Point)

$ ogrinfo -al /tmp/example.json
ERROR 4: GeoJSON Driver doesn't support update.
Had to open data source read-only.
INFO: Open of `/tmp/example.json'
      using driver `GeoJSON' successful.

Layer name: OGRGeoJSON
Geometry: Point
Feature Count: 1
Extent: (0.000000, 0.000000) - (0.000000, 0.000000)
Layer SRS WKT:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0,
        AUTHORITY["EPSG","8901"]],
    UNIT["degree",0.0174532925199433,
        AUTHORITY["EPSG","9122"]],
    AUTHORITY["EPSG","4326"]]
OGRFeature(OGRGeoJSON):0
  POINT (0 0)

[pmav99]

Some additional info:

1. I create a new vector containing two points and I export it:

   v.out.ogr input=reservoir_point@damflood type=point output=sample.json format=GeoJSON
   Exporting 2 features...
   v.out.ogr complete. 2 features (Point type) written to <sample> (GeoJSON format).
   

2. These are the contents of the file. This is directly created by GRASS/GDAL:

   GRASS 7.0.3svn (damflood):~/repo > cat sample.json
   {
   "type": "FeatureCollection",
   "crs": { "type": "name", "properties": { "name": "urn:ogc:def:crs:OGC:1.3:CRS84" } },
   "features": [
   { "type": "Feature", "properties": { "cat": 1 }, "geometry": { "type": "Point", "coordinates": [ -78.690549087210798, 35.769783222348899 ] } },
   { "type": "Feature", "properties": { "cat": 2 }, "geometry": { "type": "Point", "coordinates": [ -78.687924462941851, 35.769783222348899 ] } }
   ]
   }
   

3. I try to import the new GeoJSON file using v.import, but it is failing:

   v.import input=/home/grassuser/repo/sample.json output=asdf
   ERROR: Syntax error in cell header
   ERROR: Unable to create location from OGR datasource </home/grassuser/repo/sample.json>
   

4. Importing directly using v.in.ogr works without problems:

   v.in.ogr input=/home/grassuser/sample.json output=asdf
   
   Check if OGR layer <OGRGeoJSON> contains polygons...
   Column name <cat> renamed to <cat_>
   Importing 2 features (OGR layer <OGRGeoJSON>)...
   -----------------------------------------------------
   Building topology for vector map <asdf@damflood>...
   Registering primitives...
   2 primitives registered
   2 vertices registered
   Building areas...
   0 areas built
   0 isles built
   Attaching islands...
   Attaching centroids...
   Number of nodes: 0
   Number of primitives: 2
   Number of points: 2
   Number of lines: 0
   Number of boundaries: 0
   Number of centroids: 0
   Number of areas: 0
   Number of isles: 0
   

5. Trying to create a new location using v.in.ogr -i fails. This failure is actually the reason that v.import fails too (step 3):

   v.in.ogr -i --verbose input=/home/grassuser/repo/sample.json output=qwer location=new_location
   Location <new_location> created
   ERROR: Syntax error in cell header
   

[pmav99]

I also created a vector map that contained a single line element. I exported and tried to reimport it using v.import. This is the exported GeoJSON file:

{
"type": "FeatureCollection",
"crs": { "type": "name", "properties": { "name": "urn:ogc:def:crs:OGC:1.3:CRS84" } },
                                                                                
"features": [
{ "type": "Feature", "properties": { "cat": 3 }, "geometry": { "type": "LineString", "coordinates": [ [ -78.691347885901351, 35.767500940375896 ], [ -78.689522060322943, 35.768756195461052 ] ] } }
]
}

And this is the output of v.import (i.e. everything works just fine):

GRASS 7.0.3svn (damflood):~/ > v.import input=sample2.json output=zxcv --verbose
Creating temporary location for <sample2.json>...
WARNING: All available OGR layers will be imported into vector map
         <OGRGeoJSON>
Projection of input dataset and current location appear to match
Check if OGR layer <OGRGeoJSON> contains polygons...
 100%
Using native format
Column name <cat> renamed to <cat_>
Importing 1 features (OGR layer <OGRGeoJSON>)...
 100%
-----------------------------------------------------
Building topology for vector map <zxcv@damflood>...
Registering primitives...
One primitive registered
2 vertices registered
Building areas...
 100%
0 areas built
0 isles built
Attaching islands...
Attaching centroids...
 100%
Topology was built
Number of nodes: 2
Number of primitives: 1
Number of points: 0
Number of lines: 1
Number of boundaries: 0
Number of centroids: 0
Number of areas: 0
Number of isles: 0
Input <sample2.json> successfully imported without reprojection

[wenzeslaus]

Replying to pmav99:

I also created a vector map that contained a single line element. I exported and tried to reimport it using v.import.

This would be a nice test for the the v.import or v.in.org test suite. Let me know if you would like to do it and want some info.

[pmav99]

I just tested this on [67683] (trunk) and it is present there too. ogrinfo can open the file, so I guess that the problem is in v.in.ogr.

$ ogrinfo --version
GDAL 1.11.3, released 2015/09/16

Replying to wenzeslaus:

This would be a nice test for the the v.import or v.in.org test suite. Let me know if you would like to do it and want some info.

Thank you. If it is going to make it easier to solve this bug, I will try to find some time but I can't really say when this is going to happen

[neteler]

Ticket retargeted after milestone closed

[neteler]

Ticket retargeted after 7.0.3 milestone closed

[mlennert]

Replying to pmav99:

2. These are the contents of the file. This is directly created by GRASS/GDAL:

   GRASS 7.0.3svn (damflood):~/repo > cat sample.json
   {
   "type": "FeatureCollection",
   "crs": { "type": "name", "properties": { "name": "urn:ogc:def:crs:OGC:1.3:CRS84" } },
   "features": [
   { "type": "Feature", "properties": { "cat": 1 }, "geometry": { "type": "Point", "coordinates": [ -78.690549087210798, 35.769783222348899 ] } },
   { "type": "Feature", "properties": { "cat": 2 }, "geometry": { "type": "Point", "coordinates": [ -78.687924462941851, 35.769783222348899 ] } }
   ]
   }
   

[...]

5. Trying to create a new location using v.in.ogr -i fails. This failure is actually the reason that v.import fails too (step 3):

   v.in.ogr -i --verbose input=/home/grassuser/repo/sample.json output=qwer location=new_location
   Location <new_location> created
   ERROR: Syntax error in cell header
   

Interestingly, when I convert the json file to shape before import, I get the same error:

v.in.ogr -i in=test.json location=new_location1 --verbose
ATTENTION: All available OGR layers will be imported into vector map
           <OGRGeoJSON>
Location <new_location1> created
ERREUR :Syntax error in cell header

then

ogr2ogr test.shp test.json

and

v.in.ogr -i in=test.shp location=new_location2 --verbose
ATTENTION: All available OGR layers will be imported into vector map <test>
Location <new_location2> created
ERREUR :Syntax error in cell header

I also opened the json file in QGIS, saved as a new shapefile and tried to import that: same error.

IIUC the error comes from the fact that the Y coordinates are strictly identical and that thus N = S in the DEFAULT_WIND & WIND files and GRASS has trouble dealing with a mapset with 0 resolution in any direction...

The following hack let's you import the file, but this is not a complete solution. One question we have to answer is whether GRASS should allow the creation of mapsets with 0 resolution in any direction, and, if not (as I think it should be), then what would be a reasonable default when creating a location from a file containing data with identical coordinates in either of the directions or with just one point.

Index: vector/v.in.ogr/main.c
===================================================================
--- vector/v.in.ogr/main.c	(révision 67579)
+++ vector/v.in.ogr/main.c	(copie de travail)
@@ -535,6 +535,8 @@
     if ((OGR_L_GetExtent(Ogr_layer, &oExt, 1)) == OGRERR_NONE) {
 	cellhd.north = ymax = oExt.MaxY;
 	cellhd.south = ymin = oExt.MinY;
+        if (cellhd.north == cellhd.south)
+		cellhd.north += 0.0001;
 	cellhd.west = xmin = oExt.MinX;
 	cellhd.east = xmax = oExt.MaxX;
 	cellhd.rows = 20;	/* TODO - calculate useful values */

[neteler]

Two comments:

Replying to mlennert:

+ if (cellhd.north == cellhd.south) + cellhd.north += 0.0001;

please see: lib/gis/adj_cellhd.c

• AFAIK such equality comparisons need to be done comparing against an epsilon, not with ==
• if I get it right, in that file 0.000001 is used.

[pmav99]

Replying to mlennert:

One question we have to answer is whether GRASS should allow the creation of mapsets with 0 resolution in any direction, and, if not (as I think it should be), then what would be a reasonable default when creating a location from a file containing data with identical coordinates in either of the directions or with just one point.

I also tried to create a location using the grass binary and a GeoJSON file containing a single Point. The location gets created without any errors/warnings but when you try to open the location you get the following traceback:

grassuser@2b7a187f3320:~$ grass -e -c ~/scenes/foo.json ~/grassdata/qwer/    
WARNING: Default locale settings are missing. GRASS running with C locale.
WARNING: Searched for a web browser, but none found
Creating new GRASS GIS location/mapset...
Cleaning up temporary files...

grassuser@2b7a187f3320:~$ grass ~/grassdata/qwer/

Launching <wxpython> GUI in the background, please wait...
GRASS 7.0.3svn (qwer):~ > Traceback (most recent call last):
  File "/usr/local/src/grass-trunk7/dist.x86_64-pc-linux-gnu/gui/wxpython/wxgui.py", line 141, in <module>
    sys.exit(main())
  File "/usr/local/src/grass-trunk7/dist.x86_64-pc-linux-gnu/gui/wxpython/wxgui.py", line 132, in main
    app = GMApp(workspaceFile)
  File "/usr/local/src/grass-trunk7/dist.x86_64-pc-linux-gnu/gui/wxpython/wxgui.py", line 49, in __init__
    wx.App.__init__(self, False)
  File "/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7981, in __init__
    self._BootstrapApp()
  File "/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7555, in _BootstrapApp
    return _core_.PyApp__BootstrapApp(*args, **kwargs)
  File "/usr/local/src/grass-trunk7/dist.x86_64-pc-linux-gnu/gui/wxpython/wxgui.py", line 83, in OnInit
    workspace=self.workspaceFile)
  File "/usr/local/src/grass-trunk7/dist.x86_64-pc-linux-gnu/gui/wxpython/lmgr/frame.py", line 223, in __init__
    self.NewDisplay(show = False)
  File "/usr/local/src/grass-trunk7/dist.x86_64-pc-linux-gnu/gui/wxpython/lmgr/frame.py", line 1793, in NewDisplay
    showMapDisplay = show)
  File "/usr/local/src/grass-trunk7/dist.x86_64-pc-linux-gnu/gui/wxpython/lmgr/layertree.py", line 181, in __init__
    Map = self.Map)
  File "/usr/local/src/grass-trunk7/dist.x86_64-pc-linux-gnu/gui/wxpython/mapdisp/frame.py", line 188, in __init__
    self.MapWindow2D.InitZoomHistory()
  File "/usr/local/src/grass-trunk7/dist.x86_64-pc-linux-gnu/gui/wxpython/mapwin/buffered.py", line 1743, in InitZoomHistory
    self.zoomhistory.append((self.Map.region['n'],
KeyError: 'n'

and this dialog:

[mlennert]

Replying to pmav99:

Replying to mlennert:

One question we have to answer is whether GRASS should allow the creation of mapsets with 0 resolution in any direction, and, if not (as I think it should be), then what would be a reasonable default when creating a location from a file containing data with identical coordinates in either of the directions or with just one point.

I also tried to create a location using the grass binary and a GeoJSON file containing a single Point. The location gets created without any errors/warnings but when you try to open the location you get the following traceback:

Yes, g.proj should have the same issue, so I think the solution will not be in v.in.ogr, but at library level. Just no time right now to look into it.

[mlennert]

Replying to mlennert:

Replying to pmav99:

Replying to mlennert:

One question we have to answer is whether GRASS should allow the creation of mapsets with 0 resolution in any direction, and, if not (as I think it should be), then what would be a reasonable default when creating a location from a file containing data with identical coordinates in either of the directions or with just one point.

I also tried to create a location using the grass binary and a GeoJSON file containing a single Point. The location gets created without any errors/warnings but when you try to open the location you get the following traceback:

Yes, g.proj should have the same issue, so I think the solution will not be in v.in.ogr, but at library level. Just no time right now to look into it.

Didn't have the time, but took some anyway, but only for coding, not much for testing. Try attached patch against trunk.

[mlennert]

Replying to mlennert:

Replying to mlennert:

Replying to pmav99:

Replying to mlennert:

One question we have to answer is whether GRASS should allow the creation of mapsets with 0 resolution in any direction, and, if not (as I think it should be), then what would be a reasonable default when creating a location from a file containing data with identical coordinates in either of the directions or with just one point.

I also tried to create a location using the grass binary and a GeoJSON file containing a single Point. The location gets created without any errors/warnings but when you try to open the location you get the following traceback:

Yes, g.proj should have the same issue, so I think the solution will not be in v.in.ogr, but at library level. Just no time right now to look into it.

Didn't have the time, but took some anyway, but only for coding, not much for testing. Try attached patch against trunk.

I just slightly modified the patch to create a region just around the point or line with epsilon*2 as distance.

However, a location created via g.proj location= fails, this time apparently because of 3D region parameters. And the grass -c also fails, but the DEFAULT_WIND files are not identical between the two methods. I don't really understand why at first glance as the startup script method seems to just call g.proj...

[mlennert]

See ​diff proposed in #3414.

[neteler]

Update: "no_vector_default_region_2.diff​" in #3414 seems to solve the issue indicated here.

[martinl]

Unable to reproduce with GRASS 7.6.0.