Re: [gdal-dev] ESRI FileGDB driver causing issues with Postgis build due to packaged libstdc++

Thanks, that worked! -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] ESRI FileGDB driver causing issues with Postgis build due to packaged libstdc++

should I delete the libstdc++.so and libstdc++.so.6.0.2.1 files as well? (sorry I'm unfamiliar with with C/C++) -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org

[gdal-dev] ESRI FileGDB driver causing issues with Postgis build due to packaged libstdc++

I'm updating a docker build of gdal/postgis with gdal 3.0.1 and postgis 3.0.0alpha4 on top of a docker image of debian:buster-slim below is my FileGDB build: FGDB_BUILD_DIR=/usr/local/FileGDB_API FGDB_BUNDLE=$BUILD_DIR/fgdb.tar.gz wget -q -O "$FGDB_BUNDLE"

Re: [gdal-dev] Enable --with-static-proj4 by default if ESRI FGDB option is given on Linux

> I've turned that as an error: Thanks, much appreciated -that will probably save at least 10 people from sitting at a coffee shop at 3am, recompiling anxiously for the 100th time, pulling out what is left of their hair, subsisting on stale pizza and wondering why they chose a career in

[gdal-dev] Enable --with-static-proj4 by default if ESRI FGDB option is given on Linux

I ran into an issue a few days ago where an ogr_fdw foreign data wrapper in postgis was throwing [XX000] ERROR: AddToPROJ4SRSCache: could not parse proj4 string '+proj=lcc +lat_1=31.88 +lat_2=30.116667 +lat_0=29.67 +lon_0=-100.3 +x_0=69.9998983998

[gdal-dev] Determining Native Data Field Type Names for a Given Layer or Driver

I'm using the GDAL Java Bindings (most recent dev version 2.3.0) and looking to determine the native datatype of a given layer field -or at least the default mapping of the driver. For example I have manually written code like the following for Postgres/Postgis: private static final

Re: [gdal-dev] Shapefile: automatic retrieval of EPSG code

This is incredibly useful! Hopefully I will get around to recompiling my docker image to test this out soon! On Mon, Sep 25, 2017 at 12:30 PM, Even Rouault wrote: > Hi, > > > > As part of a AWEOC (*), following a recent email thread about year-long > issues when

Re: [gdal-dev] Achieving Better WKT -> EPSG Code Autodetection When Importing Layers to Postgis

Even: > No need for a complicated thing like a JNI bridge, but someone has to code it in GDAL. All the basic functionnality is there. Just needs to be put together. The main reason I suggested geotools is that one only needs to write only a few trivial lines of code to get the correct EPSG

[gdal-dev] Achieving Better WKT -> EPSG Code Autodetection When Importing Layers to Postgis

I am having issues with OGR being unable to autodetect the correct EPSG code for arbitrary .prj files. I haven't dealt with any data I'd consider to have an "exotic" projection -usually just your typical state plane coordinate systems that are typically used for most publicly available GIS

Re: [gdal-dev] Error Compiling GDAL with ESRI FileGeodatabase Support On Ubuntu 16.04

working C++ compiler." (I'm a java developer so not very familiar with c/c++ compilation) On Thu, Aug 4, 2016 at 4:02 PM, Even Rouault <even.roua...@spatialys.com> wrote: > On Thursday 04 August 2016 15:59:22 Andrew Joseph wrote: > > I had originally compiled without any of

[gdal-dev] Error Compiling GDAL with ESRI FileGeodatabase Support On Ubuntu 16.04

I'm not able to compile GDAL with the ESRI FileGeodatabase driver (needed for write support) on Ubuntu 16.04 with Docker (current LTS) I'm using the the travis.yml of the 2.1_gcc5.2_sanitize coverage branch as a guide since that seems to be the closest environment to 16.04. However, during GDAL