SHP output fails - Error in psSHP->sHooks.FSeek()

[simberaj]

Shapefile output does not work for me when using GDAL 2.1.1 from the QGIS/OSGeo4W bundle on my Windows 7 Enterprise 64bit.

Whenever I try to use ogr2ogr or invoke shapefile output from the QGIS GUI, the following error appears:

Error in psSHP->sHooks.FSeek() while writing object to .shp file.

An empty shapefile containing only the headers is produced.

The error shows irrespective of:

• way of invocation (command line through OSGeo4W shell or directly, QGIS Save As... dialog)

• input format (tried OpenFileGDB, GeoJSON and SpatiaLite) or geometry type (tried Point and LineString)

• the CRS

• 32bit or 64bit installation (tried OSGeo4W 32bit and 64bit bundles and QGIS standalone installer)

• I have plenty of disk space and write access to the target folder.

The GDAL_DATA env variable as it appears from the system is C:\Program Files\PostgreSQL\9.5\gdal-data. There is PostgreSQL installed on the same system with a PostGIS enabled database.

Outputs to other formats, such as GeoJSON, work fine.

I am enclosing a GeoJSON file that is able to trigger the failure.

[simberaj]

A GeoJSON file that triggers the error when saved/converted

[simberaj]

The CRS of the GeoJSON is EPSG:5514 (S-JTSK Krovak East North), a Czech national grid which operates in negative coordinates.

[Jukka Rahkonen]

I downloaded your json file and used GDAL 2.2.0dev, released 2016/99/99 installed from the zipfile of gisinternals.com. I am on 64-bit Windows 7. I had no problems at all. I know this is a poor test (v.2.2 against your v.2.1.1).

ogr2ogr output.shp mypoints.json

ogrinfo output.shp
INFO: Open of `output.shp'
      using driver `ESRI Shapefile' successful.
1: output (Point)

ogrinfo output.shp -al
INFO: Open of `output.shp'
      using driver `ESRI Shapefile' successful.

Layer name: output
Metadata:
  DBF_DATE_LAST_UPDATE=2016-09-20
Geometry: Point
Feature Count: 13
Extent: (-859056.171275, -1164981.950751) - (-476238.421798, -974588.068659)
Layer SRS WKT:
PROJCS["S_JTSK_Krovak_East_North",
    GEOGCS["GCS_S-JTSK",
        DATUM["System_Jednotne_Trigonometricke_Site_Katastralni",
            SPHEROID["Bessel_1841",6377397.155,299.1528128]],
        PRIMEM["Greenwich",0],
        UNIT["Degree",0.017453292519943295]],
    PROJECTION["Krovak"],
    PARAMETER["latitude_of_center",49.5],
    PARAMETER["longitude_of_center",24.83333333333333],
    PARAMETER["azimuth",30.28813972222222],
    PARAMETER["pseudo_standard_parallel_1",78.5],
    PARAMETER["scale_factor",0.9999],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    UNIT["Meter",1]]
nazev: String (80.0)
OGRFeature(output):0
  nazev (String) = Praha
  POINT (-741972.865723233 -1044138.48782736)

OGRFeature(output):1
  nazev (String) = Hradec Kralove
  POINT (-642659.73911514 -1041590.07552195)

OGRFeature(output):2
  nazev (String) = Pardubice
  POINT (-648206.283544573 -1061427.7164092)

OGRFeature(output):3
  nazev (String) = Olomouc
  POINT (-545195.460650192 -1121915.03201126)

OGRFeature(output):4
  nazev (String) = Ostrava
  POINT (-476238.42179778 -1103351.59727672)
....

[Even Rouault]

I'm quite confident that there must be something wrong in the particular setup of this machine rather than a general problem in GDAL itself. A failed seek is something I've never seen. From the mention of GDAL_DATA pointing to a postgres directory, I'd suspect a mix of GDAL versions, although the fact that it results in a failed seek is quite mysterious. You should also check the PATH and check that it points first to a directory where the gdal dll from OSGeo4W is.

I'm not sure what we can do with this ticket.

[simberaj]

I have done some further tests:

• The current GDAL build from gisinternals also fails.

• The issue persists after uninstalling PostGIS, removing the GDAL_PATH environment variable, resetting PATH and completely reinstalling OsGeo4W. Setting the PATH and GDAL_PATH to the /bin and /share/gdal respectively has no effect. This should IMHO rule out the version mix as the source of the problem.

I'm becoming desperate.

[Jukka Rahkonen]

I just downloaded ​http://download.gisinternals.com/sdk/downloads/release-1800-x64-gdal-mapserver.zip, unzipped, and opened the command window by running "sdkshell hideoci". Still no problem for me with converting your geojson sample.

[simberaj]

Did exactly the same thing. Fails with the same error as before:

ERROR 1: Failed to find required field in gdal_datum.csv in InitDatumMappingTable(), using default table setup.
ERROR 1: Error in psSHP->sHooks.FSeek() while writing object to .shp file: No such file or directory
ERROR 1: Unable to write feature 1 from layer hlmesta.
ERROR 1: Terminating translation prematurely after failed translation of layer hlmesta (use -skipfailures to skip errors)
ERROR 1: Failure writing .shp header: No such file or directory

[Jukka Rahkonen]

I see that you are not testing with the same data. Would you mind repeating my command with your test data

ogr2ogr output.shp mypoints.json

And I unzippid the gisinternals zip into c:\gdal\gdal_dev.

[simberaj]

This gives the following message:

FAILURE:
Unable to open datasource `mypoints.json' with the following drivers.
  -> netCDF,   -> AmigoCloud,   -> PCIDSK,   -> JP2OpenJPEG,   -> PDF,   -> DB2ODBC,   -> ESRI Shapefile,   -> MapInfo File,   -> UK .NTF,   -> OGR_SDTS,   -> S57,   -> DGN,   -> OGR_VRT,   -> REC,   -> Memory,   -> BNA,   -> CSV,   -> NAS,   -> GML,   -> GPX,   -> LIBKML,   -> KML,   -> GeoJSON,   -> Interlis 1,   -> Interlis 2,   -> OGR_GMT,   -> GPKG,   -> SQLite,   -> ODBC,   -> WAsP,   -> PGeo,   -> MSSQLSpatial,   -> PostgreSQL,   -> MySQL,   -> OpenFileGDB,   -> XPlane,   -> DXF,   -> Geoconcept,   -> GeoRSS,   -> GPSTrackMaker,   -> VFK,   -> PGDUMP,   -> OSM,   -> GPSBabel,   -> SUA,   -> OpenAir,   -> OGR_PDS,   -> WFS,   -> HTF,   -> AeronavFAA,   -> Geomedia,   -> EDIGEO,   -> GFT,   -> SVG,   -> CouchDB,   -> Cloudant,   -> Idrisi,   -> ARCGEN,   -> SEGUKOOA,   -> SEGY,   -> ODS,   -> XLSX,   -> ElasticSearch,   -> Walk,   -> Carto,   -> SXF,   -> Selafin,   -> JML,   -> PLSCENES,   -> CSW,   -> VDV,   -> TIGER,   -> AVCBin,   -> AVCE00,   -> HTTP

(newlines replaced by commas)

[Jukka Rahkonen]

Do you have file "mypoints.json" in your working directory? Do you see the same as I do with these:

ogrinfo --version
GDAL 2.2.0dev, released 2016/99/99

ogrinfo --formats|find "GeoJSON"
GeoJSON -vector- (rw+v): GeoJSON

[simberaj]

Yes, it is there (verified by type command).

In the command line, I see exactly the same output as you do.

[Jukka Rahkonen]

And the file is exactly this one ​https://trac.osgeo.org/gdal/raw-attachment/ticket/6658/mypoints.json?

You must have something weird in your system but I can't imagine any way to re-produce your issue. Last check, if you run now in the gisinternals shell SET GDAL_DATA, does it point to subdirectory of your gisinternals installation ...\bin\gdal-data?

[simberaj]

It produces the following:

c:\gdal\gdal_dev>set GDAL_DATA
GDAL_DATA=C:\gdal\gdal_dev\bin\gdal-data

which is AFAIK correct.

Are there any known interactions with other programs (drive encryption systems, for example) that might be causing the issue?

[Jukka Rahkonen]

The path seems to be correct. Your problem is very odd and I do not remember reading any similar report ever. I am using Windows 7 enterprise 64-bit myself, with encrypted drives.

Do you have colleagues with identical computers? If you find another user suffering from the same issue than you do would be an evidence that there may be something wrong in GDAL. If it is just you it feels more like an issue in your installation or even in your hardware.

[Even Rouault]

Closing due to lack of feedback from reporter and impossibility to reproduce. Reopen if you can provide more elements