the failure until we are past the
GDAL update.
--
Simon Eves
Senior Rendering Engineer
+1 (415) 902-1996
simon.e...@heavy.ai
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
tput.zip'
>
> using driver `GeoJSON' successful.
>
> 1: test (3D Multi Polygon)
>
>
>
> -Jukka Rahkonen-
>
>
>
> *Lähettäjä:* gdal-dev *Puolesta *Simon
> Eves via gdal-dev
> *Lähetetty:* lauantai 22. helmikuuta 2025 3.31
> *Vastaanottaja:*
Same with 3.10.1.
On Fri, Feb 21, 2025 at 3:12 PM Simon Eves wrote:
> Revisiting our geo export options after several years and hit something
> weird.
>
> Testing with the command-line tools, this works...
>
> ogr2ogr -f "geojson" /vsigzip//path/to/output.g
pits a ton of errors (attached) and while the zip file is created, it
has no files in it.
Am I doing something silly, or is this a bug?
Does anyone really use or expect individually-zipped GeoJSON files anyway?
This is with GDAL 3.7.3. We are updating to 3.11 so I'll try that too.
--
Simon Eves
Even Rouault wrote:
> @SimonEves I was confused by your mention of autogen.sh and stuff. I
> presume you're still using google/libkml. You'd probably have a slightly
> better experience with libkml/libkml which has only a CMake build system.
>
Thanks. I'll pass that on.
>
___
We include *libkml* in our GDAL build. We are still using v1.3.0 from
August 12, 2015. It still works fine for our requirements with GDAL 3.7.3
(current production) and 3.9.2 (imminent deps bump).
The build script for it predates me, but it appears we also had issues with
*uriparser*. We build tha
+100
On Thu, Sep 12, 2024 at 6:15 AM Sean Gillies via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
> Absolutely yes +1
>
> On Wed, Sep 11, 2024, 8:24 PM Howard Butler via gdal-dev <
> gdal-dev@lists.osgeo.org> wrote:
>
>> PSC,
>>
>> I am motioning to renew Even's maintainer contract through the GD
where heuristics to
> determine which block size to expose may be tuned, although this hasn't
> changed much recently.
> Le 30/08/2024 à 23:43, Simon Eves a écrit :
>
> Thank you, Even.
>
> Does that whole-image optimization only apply to PNG? I mean, obviously
> that
Thank you, Even.
Does that whole-image optimization only apply to PNG? I mean, obviously
that particular build option is PNG-specific, but are there other formats
which might exhibit similar differences in presented block size? If it's
just PNG, I'm not worried, as there aren't many geospatial PNG
xt release.
(repost after canceling original post held for moderation due to attachment
size)
--
Simon Eves
Senior Rendering Engineer
+1 (415) 902-1996
simon.e...@heavy.ai
<http://www.heavy.ai>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https:/
ResampleAlgdPK15GDALWarpOptions)
> to EPSG:4326 and just take the extent of the warped VRT.
> Le 03/05/2024 à 23:25, Simon Eves via gdal-dev a écrit :
>
> I like it.
>
> On Fri, May 3, 2024 at 2:24 PM Javier Jimenez Shaw
> wrote:
>
>> Now I think I understand what you m
nding box.
> The idea is not mine. Even Rouault mentioned it last year in FOSS4G. IIRC,
> it is used by gdalwarp to not reproject every single point; once the
> subdivision is enough, then it does linear interpolation.
>
> On Fri, 3 May 2024 at 22:18, Simon Eves wrote:
>
>>
wrote:
> The bbox is created using the xmin,ymin,xmax,ymax found in the geometry.
> Assuming every pixel can be represented as a geometry, that's your bbox.
>
> On 5/3/24 13:18, Simon Eves via gdal-dev wrote:
> > Yes, but that's just the corners.
> >
> >
Javier Jimenez Shaw
wrote:
> Maybe I don't understand your question, but in gdalinfo you have the four
> corners as lat-lon
>
> On Fri, 3 May 2024, 21:46 Simon Eves via gdal-dev, <
> gdal-dev@lists.osgeo.org> wrote:
>
>> So we are trying to optimize our raste
cient.
Thanks in advance,
Simon
--
Simon Eves
Senior Rendering Engineer
+1 (415) 902-1996
simon.e...@heavy.ai
<http://www.heavy.ai>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
As we're not ready to upgrade Arrow just yet, I also did the namespace
change as a pre-build code patch on the regular 3.7.3 bundle.
Apologies to Bjorn and anyone else on that team for any inference that this
was a flatbuffers bug. Not my intention. Glad we worked it out.
Simon
On Sun, Feb 25, 2
Arrow moved to using a custom namespace in v10.0.0
On Sun, Feb 25, 2024 at 5:26 PM Simon Eves wrote:
> Ooh, good call!
>
> That also corresponds with what I just tried, which was to leave the
> change in, but have the *size()* method return a value derived the old
> way
of members of vector_downward.
>
> Or try replacing the "flatbuffers" namespace by something like
> "gdal_flatbuffers"
>
> Simon
>
>
>
> On Sat, Feb 24, 2024 at 5:27 PM Simon Eves wrote:
>
>> OK, so I tried a custom build of 3.7.3 with the latest
27 PM Simon Eves wrote:
> OK, so I tried a custom build of 3.7.3 with the latest *flatbuffers*
> (23.5.26), which was a drop-in replacement for 2.0.6 other than the version
> asserts.
>
> This does not exhibit the original problem either.
>
> However, while it produces files wh
get any longer! :)
Simon
On Fri, Feb 23, 2024 at 3:46 PM Simon Eves wrote:
> Our emails crossed. I am indeed testing with the latest flatbuffers now
> too.
>
> Agreed on the rest.
>
> On Fri, Feb 23, 2024 at 3:42 PM Even Rouault
> wrote:
>
>> Simon,
>&
t; cause might be obvious if a single culptrit commit can be exhibited
> (perhaps some subtle C++ undefined behaviour triggered? also it is a bit
> mysterious that it hits only for static builds), or otherwise raise to the
> upstream flatbuffers project to ask for their expertise
>
>
I'm also testing a build that uses the latest *flatbuffers* 23.5.26, which
is a drop-in replacement and does not require the *VerifyField* change,
just in case the issue has been fixed since 2.0.6.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https:
fully come up with a better solution.
Yours hopefully,
Simon
On Thu, Feb 22, 2024 at 10:22 PM Simon Eves wrote:
> Thank you, Robert, for the RR tip. I shall try it.
>
> I have new findings to report, however.
>
> First of all, I confirmed that a build against GDAL 3.4.1 (the
>> Hi Simon,
>>
>> On Tue, 20 Feb 2024 at 21:11, Simon Eves wrote:
>>
>>> Here's the stack trace for the original assert. Something is stepping on
>>> scratch_ to make it 0x10 instead of null, which it starts out as
>>> when the flatb
_loc = 8, max_voffset_ = 0, nested = false,
finished = false, minalign_ = 8, force_defaults_ = false, dedup_vtables_ =
true, string_pool = 0x0}
On Tue, Feb 20, 2024 at 1:10 PM Simon Eves wrote:
> Here's the stack trace for the original assert. Something is stepping on
> scratch_ to make
Here's the stack trace for the original assert. Something is stepping on
scratch_ to make it 0x10 instead of null, which it starts out as
when the flatbuffer object is created, but by the time it gets to
allocating memory, it's broken.
On Tue, Feb 20, 2024 at 1:05 PM Simon E
ild
that doesn't fail.
Like I said, the frustrating part is that a simple test program (attached)
compiled against the same set of static libs works fine.
S
On Tue, Feb 20, 2024 at 12:33 PM Robert Coup
wrote:
> Hi Simon,
>
> On Tue, 20 Feb 2024 at 18:58, Simon Eves via gdal-dev <
&
One of our build variants is a fully-static (or as-static-as-possible) done
on CentOS 7 for old-Linux compatibility.
In reverse-dependency order we have static builds of
SQLite 3450100
Expat 2.5.0
KML 1.2.0
HDF5 1.12.1
NetCDF 4.8.1
TIFF 4.5.1
Proj 9.3.0
GeoTIFF 1.7.1
LittleCMS 2.15
WebP 1.3.2
Zst
the output is empty.
Our geo import code supports multi-layer files (e.g. FileGDB) but we don't
get as far as being able to call *GetLayers()* on the DS. If they do
require specific opening with the full SDS name (like with raster) then I
would expect *ogrinfo* to at least dump the SDS names.
Ple
gt; provide that as well will be undesirable.
>
> This is generally true for the first level of access to a file, but once
> you want a specific part (name it "variable", etc), you have to comply with
> the nomenclature of each driver.
>
>
> --
> Simon Eves
> S
GDAL's usually-reliable ability to
recognize file types and load anything without such hints, so having to
provide that as well will be undesirable.
--
Simon Eves
Senior Rendering Engineer
+1 (415) 902-1996
simon.e...@heavy.ai
<http://www.heavy.ai>
__
I've also been looking at this, because we were previously using internal
TIFF and GeoTIFF but also other libraries with their own TIFF, plus another
one that needed TIFF, so we presumably ended up with four linked versions!
I have reworked everything so that we use one external TiFF and GeoTIFF f
Thanks, everyone.
On Wed, Feb 15, 2023 at 10:44 AM Even Rouault
wrote:
>
> > In theory, BUILD_SHARED_LIBS=ON could/should cascade to all dependencies
> > - you want static GDAL, good, we will assume you link it against
> > static OpenJPEG, etc.
>
> That's indeed just theory. No such thing is imp
that's not
an option for now on 3.4.1.
On Tue, Feb 14, 2023 at 10:25 PM Mateusz Loskot wrote:
> On Wed, 15 Feb 2023 at 01:34, Simon Eves wrote:
> >
> > I tried adding -DCMAKE_CPP_FLAGS="-fPIC" -DCMAKE_CXX_FLAGS="-fPIC" to
> the OpenJPEG build CMake
OK, I'm an idiot. It's *CMAKE_C_FLAGS* not *CMAKE_CPP_FLAGS*. It works now.
However, I am still surprised at the need to hack the *configure* script to
make the test work.
On Tue, Feb 14, 2023 at 4:33 PM Simon Eves wrote:
> I recreated the compile/link test that *configure* is
t;-fPIC"* to
the OpenJPEG build CMake invocation, but that made no difference.
Any help with this would be greatly appreciated, as we're code-freezing end
of this week and I'd really like to get this in.
On Sun, Feb 12, 2023 at 6:44 PM Simon Eves wrote:
> Is there some trick to
rather not bump the GDAL & PROJ and data files versions at this time
anyway, as we're very close to a release.
I just wanna minimally add JPEG2000 to what we have...
TIA
--
Simon Eves
Senior Rendering Engineer
+1 (415) 902-1996
simon.e...@heavy.ai
<ht
lenced in https://github.com/OSGeo/gdal/pull/4975
> Le 11/12/2021 à 00:05, Simon Eves a écrit :
>
> After also finding this thread...
>
> https://github.com/OSGeo/gdal/issues/2321
>
> ...I installed geotiff-bin and ran listgeo on the file.
>
> It also spits the same message
After also finding this thread...
https://github.com/OSGeo/gdal/issues/2321
...I installed geotiff-bin and ran listgeo on the file.
It also spits the same message (three times).
The output is attached.
S
On Fri, Dec 10, 2021 at 2:56 PM Simon Eves wrote:
> Further to my earlier post ab
d even mentions a patch to libGeoTIFF by
Even. I checked, and that patch IS in the (internal, as configured in the
build) GeoTIFF in our GDAL.
This is with GDAL 3.4.0 and Proj 7.2.1.
Thanks in advance,
Simon
--
<http://www.omnisci.com/>
Simon Eves
Senior Graphics Engineer,
Thanks. The code to which I was referring in my original mail was that used
by gdaltransform. I just hadn't found the API part.
On Fri, Dec 10, 2021 at 12:45 PM wrote:
> and https://gdal.org/programs/gdaltransform.html
>
>
>
> -Matt
>
>
>
> *From:* gdal-dev *On
419GDALTransformerFunc
> (or gdal.Transformer in Python).
>
> Sebastien
>
> On Fri, Dec 10, 2021 at 10:24 AM Simon Eves
> wrote:
>
>> So we have a GeoTiFF of Sentinel-1 imagery which `gdalinfo` reports as
>> having a GCP projection with 210 points, which we'
le so we can just import it with no transformation required, but that
seems ugly unless it's gonna be WAY more efficient?
Thanks,
Simon
--
<http://www.omnisci.com/>
Simon Eves
Senior Graphics Engineer, Rendering Group
100 Montgomery St (5th Floor), San Francisco, CA 94104, USA
Email
dependencies and correct options here, as I
will need to get this working in our production dependencies bundle build
too.
Thanks!
Simon
On Thu, Dec 9, 2021 at 11:32 AM Simon Eves wrote:
> I am trying to build GDAL 3.4.0 with "full" netCDF support, but getting
> different results on
her not send it to you at this time. I can find out, if that would help,
although I doubt the file itself is the issue.
Please advise. Thanks! :)
Simon
--
<http://www.omnisci.com/>
Simon Eves
Senior Graphics Engineer, Rendering Group
100 Montgomery St (5th Floor), San Francisco, CA 941
OK, thanks for confirming.
On Sat, Dec 4, 2021 at 3:59 PM Even Rouault
wrote:
> You shouldn't throw C++ exceptions, as this is a callback of the C API.
> This will cause all sort of issues, most of the time memory leaks, etc.
> Le 05/12/2021 à 00:49, Simon Eves a écrit :
>
&
s for CPLSetErrorHandler() don't explicitly say anything about not
throwing in the callback.
Please advise.
SE
--
<http://www.omnisci.com/>
Simon Eves
Senior Graphics Engineer, Rendering Group
100 Montgomery St (5th Floor), San Francisco, CA 94104, USA
Email: simon.e...@omnisci.com | Cel
orts due to the duplicate name.
Below is the link to a TGZ with the JSON file and the output of "ogrinfo"
for 3.2.2 and 3.4.0.
The extra line in the field list at the top is obvious.
https://drive.google.com/file/d/1ImBAmXz6XLW6NXheE2lKQTWpcFDKiQUZ/view?usp=sharing
SE
--
<http://
ranch. Can we assume, therefore, that it will be in 3.4.1, which
appears to be scheduled for the end of December?
Simon
On Tue, Nov 16, 2021 at 12:57 PM Simon Eves wrote:
> Hi Even,
>
> Sorry for the slow response. I was out yesterday and this morning. Testing
> your fix now.
>
>
t much better
> performance if you add -co INTERLEAVE=BAND, so that the output GeoTIFF is
> written band after band, to match the most performant access pattern for
> reading GRIB files.
>
> Even
> Le 15/11/2021 à 01:32, Simon Eves a écrit :
>
> We have recently implemented
with GDAL 3.2.2 on Ubuntu 20.04 LTS with GCC 9.
--
<http://www.omnisci.com/>
Simon Eves
Senior Graphics Engineer, Rendering Group
100 Montgomery St (5th Floor), San Francisco, CA 94104, USA
Email: simon.e...@omnisci.com | Cell: +1 (415) 902-1996
libc.so.6!raise (Unknown Source:0)
libc.so.6!abort
dalinfo makes GDAL to try XYZ
> https://gdal.org/drivers/raster/xyz.html?highlight=xyz. It is not a bad
> guess at all. Ogrinfo tries CSV and finds the x, y, and val fields. I can’t
> say anything about the second part.
>
>
>
> -Jukka Rahkonen-
>
>
>
> *Lähettäjä:* gd
Heh. Right.
On Mon, Nov 8, 2021 at 2:24 PM Even Rouault
wrote:
>
> Le 08/11/2021 à 21:44, Simon Eves a écrit :
>
> Quick question...
>
> Is it a definitive check for whether a GDALDriver is a Vector or Raster
> driver to look for either DCAP_VECTOR=YES or DCAP_RASTER=YES
to.
I can reproduce the first part with gdalinfo.
This is with GDAL 3.2.2 on Ubuntu 20.04 with GCC 9.
I'll poke at the GDAL code myself when I have a bit more time.
--
<http://www.omnisci.com/>
Simon Eves
Senior Graphics Engineer, Rendering Group
100 Montgomery St (5th Floor), San F
com/>
Simon Eves
Senior Graphics Engineer, Rendering Group
100 Montgomery St (5th Floor), San Francisco, CA 94104, USA
Email: simon.e...@omnisci.com | Cell: +1 (415) 902-1996
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/m
More specifically, I'm guessing the MOST efficient is to read whole blocks
from one band, which presumably avoids crossing compression boundaries etc.
A block may be a scanline, or it may be a tile, depending on the format.
On Mon, Nov 1, 2021 at 2:29 PM Simon Eves wrote:
> Band by ba
ll-bands-of-a-line
> Le 01/11/2021 à 21:58, Simon Eves a écrit :
>
> You can ignore this.
>
> I have rather belatedly found the documentation that says that one must
> open a GDALDataset per thread, even if it's on the same file.
>
> The multi-threading now works just fine
ss it's OK because we're pulling the OGRFeatures out with
the process thread, and only converting and loading them with the child
threads. I guess I really ought to rewrite that code too now. Sigh.
As you were...
Simon
On Sun, Oct 31, 2021 at 4:27 PM Simon Eves wrote:
> We are writing
th a local static build of GDAL 3.2.2 on Ubuntu 20.04 with
GCC 9.
Yours,
Simon Eves
--
<http://www.omnisci.com/>
Simon Eves
Senior Graphics Engineer, Rendering Group
100 Montgomery St (5th Floor), San Francisco, CA 94104, USA
Email: simon.e...@omnisci.com | Cell: +
> Not exactly what you asked, but can you simply avoid opening the file at
> all if it's too large rather than start the process and then abort?
>
> On Wed, Jul 28, 2021 at 7:10 PM Simon Eves wrote:
>
>> Agreed. Unfortunately, we're looking for a quick solution to a c
n 2 years ago because I used to have problems
> with SHP linear files.
>
> I use QGIS 3.16.8 on Linux Mint.
>
>
> Mike
>
>
> On 7/28/21 2:36 PM, gdal-dev-requ...@lists.osgeo.org wrote:
> > Date: Wed, 28 Jul 2021 12:22:12 -0700
> > From: Simon Eves
> > To
n memory leaks and maybe in some other inconsistent
> state that could crash the whole process. An interesting enhancement for
> such cases would be to be able to provide a progress / abort callback.
>
> Even
> Le 28/07/2021 à 21:22, Simon Eves a écrit :
>
> Dear All,
>
&
ks!
Simon
--
<http://www.omnisci.com/>
Simon Eves
Senior Graphics Engineer, Rendering Group
100 Montgomery St (5th Floor), San Francisco, CA 94104, USA
Email: simon.e...@omnisci.com | Cell: +1 (415) 902-1996
___
gdal-dev mailing list
gdal-dev@lists
t (in
region us-west-1) if you want to try it yourself:
s3://omnisci-import-test/example.geojson.tar.gz with subpath
/example/example.geojson
Thanks in advance!
--
<http://www.omnisci.com/>
Simon Eves
Senior Graphics Engineer, Rendering Group
100 Montgomery St (5th Floor), San Francisco, C
Oh, OK. Not sure where I got the idea it was imminent. We'll go with 3.0.1.
Thank you!
On Wed, Oct 16, 2019 at 2:45 PM Even Rouault
wrote:
> On mercredi 16 octobre 2019 13:26:20 CEST Simon Eves wrote:
> > Just wondering about the timescale of this, please?
>
> pr
Just wondering about the timescale of this, please?
We want to move to 3.x, but if 3.1 is imminent, we will wait for it.
--
<http://www.omnisci.com/>
Simon Eves
Senior Graphics Engineer, Rendering Group
100 Montgomery St (5th Floor), San Francisco, CA 94104, USA
Email: simon.e...@omnis
best way for getting fast and usable help.
> >
> > -Jukka Rahkonen-
>
>
>
>
>
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
> ___
> gdal-dev mailing list
> gdal-dev@lists.
e have the magic incantation, please?
Simon
--
<http://www.omnisci.com/>
Simon Eves
Senior Graphics Engineer, Rendering Group
100 Montgomery St (5th Floor), San Francisco, CA 94104, USA
Email: simon.e...@omnisci.com | Cell: 415.902.1996
___
To wrap this up, I got in touch with HighCharts, and they confirmed that
this file is from them, but not a real GeoJSON, and not expected to be
usable outside their software ecosystem.
Thanks again.
SE
On Wed, Sep 25, 2019 at 8:47 AM Simon Eves wrote:
> I concur.
>
> That said, I
ault
wrote:
> On mercredi 25 septembre 2019 08:27:56 CEST Simon Eves wrote:
> > OK, so it's a weird file.
> >
> > I'll leave it to you to decide whether it's worth making GDAL/Proj deal
> > with it. I suspect not, and that's fine with us.
>
> Would onl
OK, so it's a weird file.
I'll leave it to you to decide whether it's worth making GDAL/Proj deal
with it. I suspect not, and that's fine with us.
Thanks!
Simon
On Tue, Sep 24, 2019 at 12:22 PM Even Rouault
wrote:
> On mardi 24 septembre 2019 11:52:22 CEST Simon Eves
inate
system correctly?
This is all using GDAL 2.4.2, btw. We haven't made the leap to 3.x yet.
Sorry.
--
<http://www.omnisci.com/>
Simon Eves
Senior Graphics Engineer, Rendering Group
OmniSci, 1 Front St. #2650, San Francisco, CA 94111, USA
Email: simon.e...@omnisci.com | Cell: 4
NSTALL_DIR}/lib -Wl,-rpath,${INSTALL_DIR}/lib"
> ./configure \
> --prefix="${INSTALL_DIR}" \
> --with-proj="${INSTALL_DIR}"
>
> I'm not sure if it matters, but I also set
> CMAKE_INSTALL_RPATH=$INSTALL_DIR when I build proj.
>
That would explain it.
I just found RFC 73 and some other stuff in the docs, but perhaps you could
put it in the main 3.0 Release Notes? :)
Thank you.
Simon
On Fri, May 24, 2019 at 1:50 PM Even Rouault
wrote:
> On vendredi 24 mai 2019 13:35:40 CEST Simon Eves wrote:
> > I feel
= dynamic_cast(g);
mp->getNumGeometries();
mpg = mp->getGeometryRef(0);
er = mpg->getExteriorRing();
OGRPoint p;
er->getPoint(0, &p);
x = p.getX();
y = p.getY();
and 'x' and 'y' are transposed!
An ogrinfo dump on the command-line displays the correct values.
What did
tml )
> using -DCMAKE_CXX_FLAGS=-DPROJ_RENAME_SYMBOLS in the ccmake of QGIS
>
> ( but as said, maybe your setup is more complex, and I understand just
> half what I'm doing :-) )
>
> Regards,
>
> Richard Duivenvoorde
> ___
>
I removed the system libgdal-dev and proj-bin, and then this sequence
worked, with ldd showing the local proj, and the apps all compile.
Still convinced I'm doing something stupid and n00b, but what? Why didn't
the local proj DSO take priority before?
On Wed, May 8, 2019 at 9:29 AM
ves mapd 17 May 8 09:06 libproj.so.15 ->
libproj.so.15.0.0
-rwxr-xr-x 1 simon.eves mapd 30610584 May 8 09:06 libproj.so.15.0.0
drwxr-xr-x 2 simon.eves mapd 4096 May 8 09:06 pkgconfig
On Wed, May 8, 2019 at 9:25 AM Simon Eves wrote:
> No, it shows /usr/lib/x86_64-linux-gnu/libpr
.so.12
(0x7f3d98cb3000)
What am I doing wrong, such that the combination of $LD_LIBRARY_PATH
priority and --with-proj still isn't making GDAL see the local Proj before
the system one?
Simon
On Wed, May 8, 2019 at 12:41 AM Even Rouault
wrote:
> On mardi 7 mai 2019 16:42:41 CEST Si
n
On Wed, May 8, 2019 at 12:41 AM Even Rouault
wrote:
> On mardi 7 mai 2019 16:42:41 CEST Simon Eves wrote:
> > That's what I have, even if that's not what I wrote.
> >
> > simon.eves@football:~/scratch/gdal3/gdal-3.0.0$ echo $LD_LIBRARY_PATH
> >
> /home/si
Rouault
wrote:
> > The path is in $LD_LIBRARY_PATH
>
> For $LD_LIBRARY_PATH, this should be /lib
>
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>
--
<http://www.omnisci.com/>
Simon Eves
Senior Graphics Engineer, Rendering G
nk it applies any more.
The path is in $LD_LIBRARY_PATH
--
<http://www.omnisci.com/>
Simon Eves
Senior Graphics Engineer, Rendering Group
OmniSci, 1 Front St. #2650, San Francisco, CA 94111, USA
Email: simon.e...@omnisci.com | Cell: 415.902.1996
config.log.gz
Description: application/gz
Even Rouault wrote:
>
> You can list the kml files with VSIReadDir("/vsizip/your.kmz"), and open
> each
> of them individually.
>
Makes sense. Thanks!
--
<http://www.omnisci.com/>
Simon Eves
Senior Graphics Engineer, Rendering Group
OmniSci, formerly named MapD
this common?
Thanks in advance!
--
<http://www.omnisci.com/>
Simon Eves
Senior Graphics Engineer, Rendering Group
OmniSci, formerly named MapD
e: simon.e...@omnisci.com | c: 415.902.1996
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
84 matches
Mail list logo
