Darren, reading Inland ENC is well supported. In GDAL_DATA folder you should find s57*_iw.csv files. "iw" means Inland Waterways.
In order to use these you can set S57_PROFILE to "iw". The csv might be outdated, depending on you IENC data version. Holger -----Ursprüngliche Nachricht----- Von: gdal-dev [mailto:[email protected]] Im Auftrag von [email protected] Gesendet: Mittwoch, 15. Juni 2016 20:07 An: [email protected] Betreff: gdal-dev Digest, Vol 145, Issue 25 Send gdal-dev mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://lists.osgeo.org/mailman/listinfo/gdal-dev or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of gdal-dev digest..." Today's Topics: 1. Is option --utility_version documented? (Jukka Rahkonen) 2. Re: Is option --utility_version documented? (Even Rouault) 3. OGR s57 reader possible expansion to read Inland ENCs (Darren Ives) 4. supportive data files for re-projection (Trajce Nikolov NICK) 5. Re: supportive data files for re-projection (Even Rouault) 6. Re: supportive data files for re-projection (Kurt Schwehr) ---------------------------------------------------------------------- Message: 1 Date: Wed, 15 Jun 2016 10:40:57 +0000 (UTC) From: Jukka Rahkonen <[email protected]> To: [email protected] Subject: [gdal-dev] Is option --utility_version documented? Message-ID: <[email protected]> Content-Type: text/plain; charset=us-ascii Hi, I noticed an utility program option --utility_version from https://trac.osgeo.org/gdal/changeset/34340. Am I right that this option does not appear in any user documentation? If not I would like to add it into http://gdal.org/ogr_utilities.html and http://gdal.org/gdal_utilities.html Option returns for example "gdalinfo was compiled against GDAL 2.1.0dev and is running against GDAL 2.1.0dev" Is it possible the compile and runtime versions are different? What can lead to such situation, and what trouble it makes? -Jukka Rahkonen- ------------------------------ Message: 2 Date: Wed, 15 Jun 2016 12:53:26 +0200 From: Even Rouault <[email protected]> To: [email protected] Cc: Jukka Rahkonen <[email protected]> Subject: Re: [gdal-dev] Is option --utility_version documented? Message-ID: <[email protected]> Content-Type: Text/Plain; charset="utf-8" Hi Jukka, > > I noticed an utility program option --utility_version from > https://trac.osgeo.org/gdal/changeset/34340. > > Am I right that this option does not appear in any user documentation? > If not I would like to add it into http://gdal.org/ogr_utilities.html > and http://gdal.org/gdal_utilities.html I'm not completely sure it is really needed to document it, at least not in a prominent way. This is mostly an advanced option to help diagnosing issues. > > Option returns for example > "gdalinfo was compiled against GDAL 2.1.0dev and is running against > GDAL 2.1.0dev" > > Is it possible the compile and runtime versions are different? Yes, that could potentially happen. If you look at the "About" dialog of QGIS, you will see similar things. > What can > lead to such situation, PATH / LD_LIBRARY_PATH issues > and what trouble it makes? It depends on the utility. If it uses the C API and it has been compiled against version X and is running against libgdal Y > X, then it is likely to work. Otherwise there's a high chance it results in crashing. Even -- Spatialys - Geospatial professional services http://www.spatialys.com ------------------------------ Message: 3 Date: Wed, 15 Jun 2016 14:51:30 +0000 From: Darren Ives <[email protected]> To: "[email protected]" <[email protected]> Subject: [gdal-dev] OGR s57 reader possible expansion to read Inland ENCs Message-ID: <dfd2005f4462499890d471e8a42fd...@exchmbnodat10.kongsberg.master.int> Content-Type: text/plain; charset="utf-8" Hello, Currently we are using the s57 reader from OGR in a project, it is used to import s57 files and for that it works perfectly. We would like to import Inland ENC files (http://ienc.openecdis.org/ Wikipedia: Inland_Electronic_Navigational_Charts<https://en.wikipedia.org/wiki/Inland_Electronic_Navigational_Charts>), which is essentially an extended s57 format (more detailed, extra objects and their attributes etc). I have searched through the gdal-dev archives, looking for any previous reference to Inland ENCs but have found none. Has anyone looked at this before? I am guessing that it hasn't be implemented and, as such, I would like to give it a try. Our theory is that by expanding the csv files (s57attritubes s57objectclasses whatever) to add the Inland ENC attributes etc it would be enough to read the Inland ENC files. Does anyone know if this could be the solution? Any further information would be gratefully received. Thanks, Darren Ives -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160615/36929f56/attachment-0001.html> ------------------------------ Message: 4 Date: Wed, 15 Jun 2016 18:27:33 +0200 From: Trajce Nikolov NICK <[email protected]> To: [email protected] Subject: [gdal-dev] supportive data files for re-projection Message-ID: <CAO-+zi=0p+DDZ94pcnR4tEBGa7msAmc=3kbxlv89qefvhfj...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi Community, I am new in town ;-). But using gdal for a decade or so. Never been in situation as now, when I have to filter the data/files that come with gdal for the installer of the software from our company. There are bunch of files located in the gdal/data folder and I need to know which are the ones that are needed for re-projecting of source files (elevation, vector files) Thanks a bunch for any hint! Cheers, Nick -- trajce nikolov nick -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160615/03f013f9/attachment-0001.html> ------------------------------ Message: 5 Date: Wed, 15 Jun 2016 19:13:51 +0200 From: Even Rouault <[email protected]> To: [email protected] Subject: Re: [gdal-dev] supportive data files for re-projection Message-ID: <[email protected]> Content-Type: Text/Plain; charset="utf-8" Le mercredi 15 juin 2016 18:27:33, Trajce Nikolov NICK a écrit : > Hi Community, > > I am new in town ;-). But using gdal for a decade or so. Never been in > situation as now, when I have to filter the data/files that come with gdal > for the installer of the software from our company. > > There are bunch of files located in the gdal/data folder and I need to know > which are the ones that are needed for re-projecting of source files > (elevation, vector files) Foreword notice: you break the warranty by cherry picking some of the data files Foreword notice 2: GDAL comes without any warranty (unless you pay a service provider) That said, those ones should be sufficient : $ grep CSVFilename ogr/ogr_fromepsg.cpp const char *pszFilename = CSVFilename( "unit_of_measure.csv" ); const char *uom_filename = CSVFilename( "unit_of_measure.csv" ); const char *pszFilename = CSVFilename("gcs.override.csv"); pszFilename = CSVFilename("gcs.csv"); const char *PM_FILENAME = CSVFilename("prime_meridian.csv"); const char *pszFilename = CSVFilename("gcs.override.csv"); pszFilename = CSVFilename("gcs.csv"); CPLAtof(CSVGetField( CSVFilename("ellipsoid.csv" ), const int nUOMLength = atoi(CSVGetField( CSVFilename("ellipsoid.csv" ), CPLAtof(CSVGetField( CSVFilename("ellipsoid.csv" ), CPLAtof(CSVGetField( CSVFilename("ellipsoid.csv" ), CPLStrdup(CSVGetField( CSVFilename("ellipsoid.csv" ), CPLString osFilename = CSVFilename( "pcs.override.csv" ); osFilename = CSVFilename( "pcs.csv" ); const char *pszFilename = CSVFilename( "pcs.override.csv" ); pszFilename = CSVFilename( "pcs.csv" ); const char *pszFilename = CSVFilename( "coordinate_axis.csv" ); const char *pszFilename = CSVFilename( "vertcs.override.csv" ); pszFilename = CSVFilename( "vertcs.csv" ); // pszFilename = CSVFilename( "compdcs.override.csv" ); const char *pszFilename = CSVFilename( "compdcs.csv" ); // pszFilename = CSVFilename( "compdcs.override.csv" ); const char *pszFilename = CSVFilename( "geoccs.csv" ); if( CSVScanFileByName( CSVFilename( "gcs.csv" ), CSVFilename( "gcs.csv" ) ); atoi( CSVGetField( CSVFilename( "stateplane.csv" ), gdal_datum.csv might also be needed for shapefiles If you just need to handle a few projections, you could strip much of the information from the above files, but that requires some knowledge... ( you may also need the grids from proj.4 data files ) Even -- Spatialys - Geospatial professional services http://www.spatialys.com ------------------------------ Message: 6 Date: Wed, 15 Jun 2016 11:06:40 -0700 From: Kurt Schwehr <[email protected]> To: Even Rouault <[email protected]> Cc: gdal dev <[email protected]> Subject: Re: [gdal-dev] supportive data files for re-projection Message-ID: <CACmBxysFOmLyNcBdCBTzMECuuxBTOsK2KqirUBhG=gsn_nh...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Nick, What Even said and here is the list of files I use for a very restricted build of GDAL with just a minimum of drivers. e.g. I don't build support for S57, so I don't include the S57 only data files. But if you include GML, you might need gml_registry.xml and the files that the xml references. -kurt Not used only applies to my very funky build env. "compdcs.csv", // Used by ogr_fromepsg.cpp. "coordinate_axis.csv", // Used by ogr_fromepsg.cpp, gt_wkt_srs.cpp. "cubewerx_extra.wkt", // Used by epsg.wkt. // "datum_shift.csv", // Not used. "ecw_cs.wkt", // Used by ogr_srs_erm.cpp, ecwdataset.cpp. "ellipsoid.csv", // Used by geo_normalize.c, ogr_fromepsg.cpp. "epsg.wkt", // Used by ogr_fromepsg.cpp. "esri_extra.wkt", // Used by epsg.wkt. "esri_StatePlane_extra.wkt", // Used by ogr_srs_esri.cpp. "esri_Wisconsin_extra.wkt", // Used by ogr_srs_esri.cpp. "gcs.csv", // Used by geo_normalize.c, ogr_fromepsg.cpp, // ogr_srs_esri.cpp, sqlite. "gcs.override.csv", // Used by geo_normalize.c, ogr_fromepsg.cpp. "gdal_datum.csv", // Used by geo_normalize.c, ogr_srs_esri.cpp, // gt_wkt_srs.cpp. "geoccs.csv", // Used by ogr_fromepsg.cpp. "gml_registry.xml", // Used by gmlregistry.cpp, ogrgmldatasource.cpp. "gt_datum.csv", // Used by nitfdataset.cpp. "gt_ellips.csv", // Used by nitfdataset.cpp. // "header.dxf", // Used by ogrdxfwriterds.cpp, which is not used. "inspire_cp_BasicPropertyUnit.gfs", // Used by gml_registry.xml. "inspire_cp_CadastralBoundary.gfs", // Used by gml_registry.xml. "inspire_cp_CadastralParcel.gfs", // Used by gml_registry.xml. "inspire_cp_CadastralZoning.gfs", // Used by gml_registry.xml. "nitf_spec.xml", // Used by nitffile.c. // "nitf_spec.xsd", // Used by nitf_spec.xml, which is not used. // "osmconf.ini", // Used by ogrosmdatasource.cpp, which is not used. "ogrvrt.xsd", // Used by ogrvrtdriver.cpp. "ozi_datum.csv", // Used by ogr_srs_ozi.cpp. "ozi_ellips.csv", // Used by ogr_srs_ozi.cpp. "pci_datum.txt", // Used by ogr_srs_pci.cpp. "pci_ellips.txt", // Used by ogr_srs_pci.cpp. "pcs.csv", // Used by geo_normalize.c, ogr_fromepsg.cpp. "pcs.override.csv", // Used by geo_normalize.c, ogr_fromepsg.cpp. "prime_meridian.csv", // Used by geo_normalize.c, ogr_fromepsg.cpp, rgdal. "projop_wparm.csv", // Used by geo_normalize.c. "ruian_vf_ob_v1.gfs", // Used by gml_registry.xml. "ruian_vf_st_uvoh_v1.gfs", // Used by gml_registry.xml. "ruian_vf_st_v1.gfs", // Used by gml_registry.xml. "ruian_vf_v1.gfs", // Used by gml_registry.xml. // S57 driver. // "s57agencies.csv", // Not used. // "s57attributes_aml.csv", // Not used. // "s57attributes.csv", // Not used. // "s57attributes_iw.csv", // Not used. // "s57expectedinput.csv", // Not used. // "s57objectclasses_aml.csv", // Not used. // "s57objectclasses.csv", // Not used. // "s57objectclasses_iw.csv", // Not used. // "seed_2d.dgn", // DGN driver, not used. // "seed_3d.dgn", // DGN driver, not used. "stateplane.csv", // Used by ogr_fromepsg.cpp and IDRISI driver. // "trailer.dxf", // DXF driver, not used. "unit_of_measure.csv", // Used by geo_normalize.c, ogr_fromepsg.cpp, etc. "vertcs.csv", // Used by gt_wkt_srs.cpp and ogr_fromepsg.cpp. "vertcs.override.csv", // Used by ogr_fromepsg.cpp. On Wed, Jun 15, 2016 at 10:13 AM, Even Rouault <[email protected]> wrote: > Le mercredi 15 juin 2016 18:27:33, Trajce Nikolov NICK a écrit : > > Hi Community, > > > > I am new in town ;-). But using gdal for a decade or so. Never been in > > situation as now, when I have to filter the data/files that come with > gdal > > for the installer of the software from our company. > > > > There are bunch of files located in the gdal/data folder and I need to > know > > which are the ones that are needed for re-projecting of source files > > (elevation, vector files) > > Foreword notice: you break the warranty by cherry picking some of the data > files > Foreword notice 2: GDAL comes without any warranty (unless you pay a > service > provider) > > That said, those ones should be sufficient : > > $ grep CSVFilename ogr/ogr_fromepsg.cpp > const char *pszFilename = CSVFilename( "unit_of_measure.csv" ); > const char *uom_filename = CSVFilename( "unit_of_measure.csv" ); > const char *pszFilename = CSVFilename("gcs.override.csv"); > pszFilename = CSVFilename("gcs.csv"); > const char *PM_FILENAME = CSVFilename("prime_meridian.csv"); > const char *pszFilename = CSVFilename("gcs.override.csv"); > pszFilename = CSVFilename("gcs.csv"); > CPLAtof(CSVGetField( CSVFilename("ellipsoid.csv" ), > const int nUOMLength = atoi(CSVGetField( CSVFilename("ellipsoid.csv" ), > CPLAtof(CSVGetField( CSVFilename("ellipsoid.csv" ), > CPLAtof(CSVGetField( CSVFilename("ellipsoid.csv" ), > CPLStrdup(CSVGetField( CSVFilename("ellipsoid.csv" ), > CPLString osFilename = CSVFilename( "pcs.override.csv" ); > osFilename = CSVFilename( "pcs.csv" ); > const char *pszFilename = CSVFilename( "pcs.override.csv" ); > pszFilename = CSVFilename( "pcs.csv" ); > const char *pszFilename = CSVFilename( "coordinate_axis.csv" ); > const char *pszFilename = CSVFilename( "vertcs.override.csv" ); > pszFilename = CSVFilename( "vertcs.csv" ); > // pszFilename = CSVFilename( "compdcs.override.csv" ); > const char *pszFilename = CSVFilename( "compdcs.csv" ); > // pszFilename = CSVFilename( "compdcs.override.csv" ); > const char *pszFilename = CSVFilename( "geoccs.csv" ); > if( CSVScanFileByName( CSVFilename( "gcs.csv" ), > CSVFilename( "gcs.csv" ) ); > atoi( CSVGetField( CSVFilename( "stateplane.csv" ), > > gdal_datum.csv might also be needed for shapefiles > > If you just need to handle a few projections, you could strip much of the > information from the above files, but that requires some knowledge... > > ( you may also need the grids from proj.4 data files ) > > Even > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com > _______________________________________________ > gdal-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev -- -- http://schwehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160615/fd4a5b72/attachment.html> ------------------------------ Subject: Digest Footer _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev ------------------------------ End of gdal-dev Digest, Vol 145, Issue 25 ***************************************** _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
