Thanks Even for the response and clarifications on /vsistdin/. Our reasons
for attempting to use /vsistdin/ is to avoid having to read a file from the
local file system (which we would have to write to first by other means) on
our remote server. We've been using this in conjunction with
Hi,
I tried if someone who don't know Python could do about the same with
gdal_rasterize https://gdal.org/programs/gdal_rasterize.html and I had some
success.
gdal_rasterize -dialect sqlite -sql "select st_buffer(geometry,0.01) from
states" -burn 100 -of GTIFF -ot byte -tr 0.1 0.1 -add
Miguel,
I can't seem to find this in the docs, but I think what you want is
"MERGE_ALG" set to ADD instead of the default REPLACE.
https://github.com/OSGeo/gdal/blob/master/gdal/alg/gdalrasterize.cpp#L1165
This doesn't address the buffering (I guess you might still want to buffer
the whole
Hi Gulnihal,
Something like this should work:
pushd C:\Users\HP\Desktop\modis
for /r %F in (*.hdf) do @echo gdal_translate -sds %F %~dpnF.tif
popd
This is a dry run to show what it will attempt, it won't actually do anything.
Remove the "@echo" part to make it active. Double the %
Dear all
I have a multiline layer type (tracking) and I want to make a heat map
(densities) on a buffer of them, so that in those places where several
buffers overlap the density is added as many times as lines overlap.
Now I'm doing it with a python script that reads from a shp the lines,
Hi,
On behalf of the GDAL/OGR development team, I am pleased to announce the
release of the GDAL/OGR 3.2.3 bug fix version, the last one in the 3.2
series, and
just for those who can't yet update to the yesterday 3.3.0 release.
Consult the release notes for the list of issues addressed :
Motion:
Adopt GDAL 3.2.3 RC1 as final 3.2.3 release
Passed with +1 from JukkaR and myself
--
http://www.spatialys.com
My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
Hi,
gdal_translate -of gtiff -co compress=jpeg p4433h.tif -co
NUM_THREADS=ALL_CPUS comp.tif
Time: 4.7 seconds (with GDAL 3.3.0 gisinternals build)
Time: 11.5 seconds (with GDAL 3.1.4 OSGeo4W build)
-Jukka-
--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
gdal_translate -of gtiff -co compress=jpeg p4433h.tif comp.tif
for the gdal_translate to JPEG compressed TIFF, adding -co
NUM_THREADS=ALL_CPUS should help to keep the comparison fair, and if you
use gisinternal builds, I'm not completely sure they use libjpeg-turbo,
which would bring
Hi Even,
You are right, Kakadu 8.x supports HTJ2K. I just had a try with the
kdu_compress demo utility from KDU805 demo apps. The speed was good,
actually amazing. As a test image I used a 12000x12000 RGB image. The
kdu_compress command I took from this high qualite white-paper
>
>
> did you bench timings using GDAL API & utilities (typically with
> gdal_translate) ? The ones indicated in the PR use the utilities that come
> which each library, but the integration within a GDAL driver might have
> some influence on the timings.
>
Yes, the timings will definitely be
Hi Andrew,
I recently updated my local GDAL tree from github and it apparently
forced the need to regenerate some Python bindings with SWIG. This
modified the local files:
Yeah, I also noticed that a few times lately. This is a side effect of
https://github.com/OSGeo/gdal/pull/3697 . I'm
Hi,
I recently updated my local GDAL tree from github and it apparently forced
the need to regenerate some Python bindings with SWIG. This modified the
local files:
swig/python/extensions/gdal_array_wrap.cpp
swig/python/osgeo/gdal_array.py
Are these files supposed to be committed to the source
Aaron,
did you bench timings using GDAL API & utilities (typically with
gdal_translate) ? The ones indicated in the PR use the utilities that
come which each library, but the integration within a GDAL driver might
have some influence on the timings.
What about single threaded usage ?
Even
/vsistdin/ is only meant for format whose reading is compatible of a
streamed reading, that is you read bytes as they come from stdin. Which
is only a subset of formats, and PDF is not in that subset (typically
the cross reference table to objects is always put at the end of the
file, hence
It's known regression, see https://github.com/OSGeo/gdal/issues/3782
--
thomas
On Tue, May 4, 2021 at 10:42 AM Javier Jimenez Shaw
wrote:
> Hi
>
> I am trying to compile the new release 3.3.0 in Ubuntu 18.04 with the
> option "--without-geos".
>
> The message is this:
>
> GEOS support disabled
Hi
I am trying to compile the new release 3.3.0 in Ubuntu 18.04 with the
option "--without-geos".
The message is this:
GEOS support disabled
configure: error: GEOS support explicitly enabled, but geos-config could
not be found
I tried also changing to "--with-geo=no", with the same result.
17 matches
Mail list logo
