There could be a vsipreload script that sets the environment variable
and then execs its parameters similar to how eatmydata [1] works.
[1] https://manpages.debian.org/testing/eatmydata/eatmydata.1.en.html
On 8/7/19 4:10 PM, Even Rouault wrote:
On mercredi 7 août 2019 20:58:54 CEST Joe Lee wro
Did you set ./configure --with-proj=${INSTALL_DIR}?
Where INSTALL_DIR is the install directory (prefix) of proj/gdal.
I also had to set:
export LDFLAGS="-L${INSTALL_DIR}/lib -Wl,-rpath,${INSTALL_DIR}/lib"
to get gdal to actually link against the new proj (vs the system
installed one).
On 5
I know I am late to the party, but I ran into the same thing today
(Building Proj 6, GDAL 3 on Debian Stretch). I got around it by setting
LDFLAGS before running ./configure so the linker finds the proj 6
install first. Without setting LDFLAGS, ./configure would find the new
proj, but libtool
On 4/19/19 9:52 AM, Even Rouault wrote:
On vendredi 19 avril 2019 07:42:31 CEST Simon Eves wrote:
Does this mean there won’t be a 2.4.2?
I'll issuing a few extra 2.4.x maintenance bugfix releases this year, but this
is a courtesy that will eventually stop.
People needing longer support, and p
On Mon, Jun 25, 2018 at 4:14 PM, Even Rouault
mailto:even.roua...@spatialys.com>> wrote:
> > If my memories are right, you only need to set it for write
support. So
> > shouldn't be needed there.
>
> All I know is that without it set, the curved geometries were
linearized
On 06/22/2018 02:51 PM, Even Rouault wrote:
> On vendredi 22 juin 2018 14:38:15 CEST James Klassen wrote:
>> I finally got around to doing a rough implementation of parsing ESRIJSON
>> with curved geometries. The code is very rough yet, but works enough to
>> import a polygon layer from an ESRI
I have updated the Ruby bindings so that they will build against Ruby 1.9 and
the changes are in trunk. I am looking for people to test and give me
feedback. If it works well for people, the changes may make it into a 1.8.x
release.
Details are available at the following URLs:
http://trac.o
rmation having to be mathematically rigorous?
Jim Klassen
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
I have used OGR with oracle views regularly for a few years now. I agree that
it works better when the view is registered in with *_sdo_geom_metadata
(otherwise you have to mess around with the -sql option). Also, I do recall
getting an error message like yours, however, I never paid much attent