Opened 3 years ago

Closed 3 years ago

#6658 closed defect (worksforme)

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

Reported by: simberaj Owned by: warmerdam
Priority: high Milestone:
Component: default Version: 2.1.1
Severity: major Keywords: shp output ogr
Cc:

Description

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)
  • 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.

Attachments (1)

mypoints.json (2.1 KB) - added by simberaj 3 years ago.
A GeoJSON file that triggers the error when saved/converted

Download all attachments as: .zip

Change History (15)

Changed 3 years ago by simberaj

Attachment: mypoints.json added

A GeoJSON file that triggers the error when saved/converted

comment:1 Changed 3 years ago by simberaj

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

comment:2 Changed 3 years ago by 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)
....
Last edited 3 years ago by Jukka Rahkonen (previous) (diff)

comment:3 Changed 3 years ago by 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.

comment:4 Changed 3 years ago by 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.

comment:5 Changed 3 years ago by 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.

comment:6 Changed 3 years ago by 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

comment:7 Changed 3 years ago by 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.

Last edited 3 years ago by Jukka Rahkonen (previous) (diff)

comment:8 Changed 3 years ago by 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)

comment:9 Changed 3 years ago by 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

Last edited 3 years ago by Jukka Rahkonen (previous) (diff)

comment:10 Changed 3 years ago by simberaj

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

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

Last edited 3 years ago by simberaj (previous) (diff)

comment:11 Changed 3 years ago by 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?

comment:12 Changed 3 years ago by 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?

comment:13 Changed 3 years ago by 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.

comment:14 Changed 3 years ago by Even Rouault

Resolution: worksforme
Status: newclosed

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

Note: See TracTickets for help on using tickets.