[gdal-dev] ogr2ogr.java s57 conversion

Even Rouault even.rouault at mines-paris.org
Wed Jun 22 13:04:38 EDT 2011


Le mercredi 22 juin 2011 18:48:34, Robert Naugle a écrit :
> Oliver,
> 
> Thanks much for your help, and with the link. I thought I would share my
> progress:
> 
> The first thing I tried was moving the csv files (s57attributes.csv and
> s57objectclasses.csv) into the working directory. Success! (sort of...)
> ogr2ogr.java found all the layers in the s57 chart file. However, the
> layers appeared to be empty :(
> 
> Now I know that your suggestion was to set the environment variables within
> the java environment, and that would probably help, but due to the use of
> JNI in the implementation of ogr2ogr in java, and the desire for a working
> JavaWebStart application later on, that path is beyond my capabilities.
> So...
> 
> I did a little digging to see why the layers were empty. Layer translation
> was failing when creating fields for the attributes in the s57 chart.
> Specifically, the LNAM_REFS and FFPT_RIND fields. I modified ogr2ogr.java
> to just skip these fields and started to find objects in the layers!
> 
> Now I am dealing with 'OGR Error: Unsupported geometry type', when loading
> more than one geometry type into a shapefile, which I know is against the
> rules, but it seems like the cpp ogr2ogr did a better job of handling these
> sorts of errors. I believe this can be helped with some argument
> manipulation...

You just need to add "-skipfailures" as a command line argument, as you'd do 
with the C++ version of ogr2ogr. The LNAM_REFS and FFPT_RIND fields are of type 
StringList and IntegerList, which is not supported by shapefiles. And yes a 
shapefile only supports one geometry type per shapefile. -skipfailures should 
skip geometries that are not of the right type.



More information about the gdal-dev mailing list