[gdal-dev] OGR s57 reader possible expansion to read Inland
Läbe, Holger
laebe at geomapping.de
Wed Jun 15 22:57:58 PDT 2016
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:gdal-dev-bounces at lists.osgeo.org] Im Auftrag von gdal-dev-request at lists.osgeo.org
Gesendet: Mittwoch, 15. Juni 2016 20:07
An: gdal-dev at lists.osgeo.org
Betreff: gdal-dev Digest, Vol 145, Issue 25
Send gdal-dev mailing list submissions to
gdal-dev at lists.osgeo.org
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
gdal-dev-request at lists.osgeo.org
You can reach the person managing the list at
gdal-dev-owner at lists.osgeo.org
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 <jukka.rahkonen at maanmittauslaitos.fi>
To: gdal-dev at lists.osgeo.org
Subject: [gdal-dev] Is option --utility_version documented?
Message-ID: <loom.20160615T123446-51 at post.gmane.org>
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 <even.rouault at spatialys.com>
To: gdal-dev at lists.osgeo.org
Cc: Jukka Rahkonen <jukka.rahkonen at maanmittauslaitos.fi>
Subject: Re: [gdal-dev] Is option --utility_version documented?
Message-ID: <201606151253.26747.even.rouault at spatialys.com>
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 <darren.ives at km.kongsberg.com>
To: "gdal-dev at lists.osgeo.org" <gdal-dev at lists.osgeo.org>
Subject: [gdal-dev] OGR s57 reader possible expansion to read Inland
ENCs
Message-ID:
<dfd2005f4462499890d471e8a42fd0a7 at 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 <trajce.nikolov.nick at gmail.com>
To: gdal-dev at lists.osgeo.org
Subject: [gdal-dev] supportive data files for re-projection
Message-ID:
<CAO-+zi=0p+DDZ94pcnR4tEBGa7msAmc=3kbXLv89QefVhFjtUg at 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 <even.rouault at spatialys.com>
To: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] supportive data files for re-projection
Message-ID: <201606151913.52098.even.rouault at spatialys.com>
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 <schwehr at gmail.com>
To: Even Rouault <even.rouault at spatialys.com>
Cc: gdal dev <gdal-dev at lists.osgeo.org>
Subject: Re: [gdal-dev] supportive data files for re-projection
Message-ID:
<CACmBxysFOmLyNcBdCBTzMECuuxBTOsK2KqirUBhG=gsN_NhGkw at 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 <even.rouault at spatialys.com>
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
> gdal-dev at lists.osgeo.org
> 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
gdal-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
------------------------------
End of gdal-dev Digest, Vol 145, Issue 25
*****************************************
More information about the gdal-dev
mailing list