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
Thanks Even.
I didn't scroll down far enough in the google results - this blogger had the
same symptoms.
https://dzone.com/articles/azure-blob-storage-specified
> On Apr 5, 2025, at 4:12 AM, Even Rouault wrote:
>
> The error is:
>
> URL_INFO_HEADER_OUT: PUT
> /bcfishpass/crossings.parquet?se
nked below... but this must be an
Azure issue.
https://gist.github.com/smnorris/427ab56914b5bd55ad8f797c107aea73
> On Apr 4, 2025, at 2:52 PM, Even Rouault wrote:
>
>
>
> Le 04/04/2025 à 20:40, Simon Norris via gdal-dev a écrit :
>> Perhaps another hapless user quest
if it was a bug I'd think it would have already have been
found by other users?
thanks
Simon
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
rs afterwards.
Best regards,
Simon
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Thanks Even,
That does the trick :)
Cheers,
Simon
On Wed, Mar 12, 2025 at 9:54 AM Even Rouault wrote:
>
> Simon,
>
> see the ARRAY:IF(DIM=2):BLOCKSIZE=256,256 example of
> GDALGroup::CopyFrom() mentioned at
> https://gdal.org/en/stable/doxygen/c
Hi Daniel
Many thanks for taking a look at my dilemma and providing a solution that works.
Best wishes, Simon.
Simon Wright
GISMO Scrum Master and RML Head of Software
--
e: simon.wri...@jbarisk.com
d:+44 (0)1756 587258
t: +44 (0)1756 799919
www.jbarisk.com
All JBA Risk
m tiles that overlap the mask tiles.
My question is: Do I need to provide mask tiles covering the entire extent of
the raster mosaic, or is there an alternative approach that allows me to use
mask tiles only where I want to mask specific areas (e.g., to reduce
redundancy)?
I’d appreciate any guidanc
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
Open of `transportation.gdb.zip'
> using driver `OpenFileGDB' successful.
>
> Sorry for all the usage questions to the dev list - I'd be happy to take this
> somewhere else.
>
> thanks
>
> Simon
>
>
> On Aug 27, 2024, at 3:33 PM, Even Roua
Sorry for all the usage questions to the dev list - I'd be happy to take this
somewhere else.
thanks
Simon
On Aug 27, 2024, at 3:33 PM, Even Rouault wrote:
Hi,
will be fixed per https://github.com/OSGeo/gdal/pull/10663
Workaround with existing versions:
$ ogrinfo
"/vsizip/{/vsic
rl -o Parks.gdb.zip https://maps.kamloops.ca/OpenData/zipfiles/ParksGDB.zip
$ ogrinfo Parks.gdb.zip
INFO: Open of `Parks.gdb.zip'
using driver `OpenFileGDB' successful.
thanks!
Simon
___
gdal-dev mailing list
gdal-dev@lists.osgeo.
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
many geospatial PNGs... :)
On Fri, Aug 30, 2024 at 1:24 PM Even Rouault
wrote:
> Simon,
>
> One is the declared block size of a simple RGB PNG image, which we use for
> some raster import tests. The image is 320x225 and gdalinfo on x86
> reports that for the block size of the three
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:/
it presumably uses the token without issue because it reports on the correct
attachment:
CURL_INFO_HEADER_IN: Content-Disposition: attachment;
filename="transportation.gdb.zip"; size=307145
I can download without issue using `curl --location-trusted` but would prefer
to use ogr
he element of in a multidimensional
VRT
(https://gdal.org/drivers/raster/vrt_multidimensional.html#vrt-multidimensional).
Am I right in assuming that this is not possible "out of the box"
with the current options provided by VRTDataset, so that I would need
to write some code to cover the use cas
Wow. Can't believe I missed the middle one, at least. Thank you, Even, as
always!
Simon
On Fri, May 3, 2024 at 3:03 PM Even Rouault
wrote:
> ==> GDALCreateApproxTransformer():
> https://gdal.org/api/gdal_alg.html#_CPPv427GDALCreateApproxTransformer19GDALTransformerFuncPvd
>
&g
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
own issues at Github, writing block attributes is not yet supported)
Any ideas why the field BlockAttributes (also BlockScale, BlockOCSNormal,
BlockOCSCoords) is set to "" in the GPKG? BlockName and BlockAngle are set
correctly.
Best regards
Simon
___
Ver
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, F
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
ak something else. I guess you need to do the custom
namespace thing too, though.
I hate computers.
Simon
On Sun, Feb 25, 2024 at 3:43 PM Even Rouault
wrote:
>
>
> Not obvious why that change would have broken anything, and certainly
> still absolutely no idea why it only happens in
on to the *size()* method, although it
only seems to avoid a couple of subtractions. I guess it must get called a
lot.
Not obvious why that change would have broken anything, and certainly still
absolutely no idea why it only happens in a full static build.
Simon
On Sat, Feb 24, 2024 at 5:
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,
>&
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,
>
> did you try to update to the latest
> https://github.com/google/flatbuffers/releases to see if that would solve
>
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
y have would be very
welcome. I am of course happy to describe my debugging findings in more
detail, privately if you wish, rather than spamming the list.
Simon
On Tue, Feb 20, 2024 at 1:49 PM Robert Coup
wrote:
> Hi,
>
> On Tue, 20 Feb 2024 at 21:44, Robert Coup
> wrote:
>
_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
our prompt assistance!
Simon
On Fri, Jul 21, 2023 at 3:35 PM Even Rouault
wrote:
>
>
> This seems like a bug. It should still be able to recognize and open the
> file without the type hint, whether or not you provide a sub-dataset suffix.
>
> This is not a bug. This is intended.
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>
__
ARS
Am I correct in this assumption and, if so, is there a way around it in GDAL?
Otherwise, any clues what could be the problem with this grib?
Thanks,
Simon
--
Dr Simon Proud (he/him)
Senior Remote Sensing Scientist
RAL Space | National Centre for Earth Observation
Science and Tech
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
d as EPSG:31255
Yes, that is the correct code.
> Which version of ArcMap / ArcGIS was used to produce this GDB ?
ArcGIS Desktop 10.8.1
Simon
Von: Even Rouault
Gesendet: Freitag, 27. Jänner 2023 15:23
An: Simon Gröchenig
Cc: gdal-dev@lists.osgeo.org
Betreff: Re: AW: [gdal-dev] Bad GDB perf
Hi Even,
great, thank you!
Is the GDB itself fine? Or is there something I can do to fix the database?
Simon
Von: Even Rouault
Gesendet: Freitag, 27. Jänner 2023 13:38
An: Simon Gröchenig ; gdal-dev@lists.osgeo.org
Betreff: Re: [gdal-dev] Bad GDB performance
Hi Simon,
fix queued in https
QGIS project containing this GDB (layer Kataster/GST) results in a
layer loading time of 5+ seconds according to the QGIS Debugging/Development
Tools. I expect less than 1 second to load this dataset.
I appreciate any help to find if it is a GDAL or a dataset issue?
Simon
is there another reason why the
values differ to those listed at epsg.io.
Many thanks, best wishes, Simon.
Simon Wright
JBA Risk Management Limited
--
e: simon.wri...@jbarisk.com
d:+44 (0)1756 587258
t: +44 (0)1756 799919
www.jbarisk.com
All JBA Risk Management's email messages contai
third category, climatologies
<https://climatedataguide.ucar.edu/climate-data> , when the data represent
averages over multiple years - eg, the January data are not for any
specific January, but for averages of all Januaries between 1960 and 1990.
But this is a fairly niche case.
Best,
Simon
On
to use two different time tags for start and end.
What would be the most standards-compliant way of setting datetimes?
Thanks,
Simon
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
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
Aha! That's the bit I hadn't found. Thank you! :)
On Fri, Dec 10, 2021 at 10:38 AM Yann-Sebastien Tremblay-Johnston <
yanns.tremb...@gmail.com> wrote:
> Simon,
>
> See the Transformer API, in particular
> https://gdal.org/api/gdal_alg.html?highlight=transformer#_CPPv
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.
>
>
Hi Even,
Sorry for the slow response. I was out yesterday and this morning. Testing
your fix now.
Simon
On Mon, Nov 15, 2021 at 4:59 AM Even Rouault
wrote:
> Simon,
>
> unfortunately there are a number of places in the degrib library which
> aren't thread-safe, and you just
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
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 in the default
meta-data?
Is every (vector or raster) driver guaranteed to have one or other of those?
TIA
Simon
--
<http://www.omnisci.
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
ingly) stuck in GDAL calls.
Simon
__
OGRFeature(fl_parcels):0
CNTYNAME (String) = ESCAMBIA
LINK (String) = 27-083S321301060003
PARCELID (String) = 083S321301060003
NPARNO (String) = 12-033-083S321301060003
DORUC (String) = 000
PAUC (String) = 1
PARUSEDESC (S
Agreed. Unfortunately, we're looking for a quick solution to a customer
complaint. I'll ponder it some more.
On Wed, Jul 28, 2021 at 12:28 PM Even Rouault
wrote:
> Simon,
>
> I don't think that killing a thread is a safe practice in general. It
> would likely result i
ssary?
Mainly I would be concerned that killing the thread might trash some global
GDAL state that might then not be recoverable, or that the open relies on
some TLS for the process thread and therefore might not work properly.
We're going to try it anyway, but opinions welcomed, than
e the file.
Thanks for the quick help.
On Thu, Feb 4, 2021 at 4:17 PM Mateusz Loskot wrote:
> On Thu, 4 Feb 2021, 23:02 Simon Shak, wrote:
>
>>
>> If I do it straight via commandline as:
>> for %f in (input\*.ecw) do (gdalbuildvrt output.vrt %f)
>> I wind up with a
I'm working on using the gdal2tiles to convert a mosaic of ECW files into
TMS format.
Since the gdal2tiles command needs a single input file, I'm building VRT's
to use as the input.
I have gotten this to work on ons set of files. When I do the same
commands for the second set of files, gdalbuildvr
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
Hi,
Okay, thank you.
By the way, while making copy of gtiffs, is not it good idea to increase
GDAL_CACHEMAX?
Simon
‐‐‐ Original Message ‐‐‐
On Monday, January 27, 2020 9:04 PM, Rahkonen Jukka (MML)
wrote:
> Hi,
>
> If your source images are 4 GB then their size is at least
; I would suggest to remove --config GDAL_CACHEMAX 8000 first. Then I would
> check if the source images are tiled. If they are not it could be worth an
> extra step to make tiled copies.
>
> -Jukka Rahkonen-
>
> Simon-4 wrote
>
> > Hello everyone,
> > I am stiching ar
Hello everyone,
I am stiching aroung 100 geotiff images each of around 4gb. However,
translating the vrt file into geotiff is going on for days.
gtranslate --config GDAL_CACHEMAX 8000 -co TILED=YES -co COMPRESS=LZW -co
BIGTIFF=YES infile.vrt outfile.tif
How can I speed up it?
Thank you.
Simon__
> Hi gdal-devs,
> I have a question, if there is some way to use gdalwarp in a clustering
> system (e.g., Sparks) or with GPU to speed up the process? My task involves
> re-projection and re-sampling of hundreds of high-resolution images. Any
> ideas to make use of Sparks or GPU is welcomed. Tha
Hi gdal-devs,
I have a question, if there is some way to use gdalwarp in a clustering system
(e.g., Sparks) or with GPU to speed up the process? My task involves
re-projection and re-sampling of hundreds of high-resolution images. Any ideas
to make use of Sparks or GPU is welcomed. Thank you.
Si
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.
>
1 - 100 of 241 matches
Mail list logo