Do we need to consider (real and false) precision when converting between
OGRSpatialReference and string ?
On Tue, 18 Dec 2018, Even Rouault wrote:
Hi,
I call this pre-RFC as I don't have yet any code implementing the following
ideas (so there might be holes in the analysis), but I wanted t
On mardi 18 décembre 2018 14:20:08 CET Scott Henderson wrote:
> There are many environment variables for optimizing access to remote
> geotiffs via GDAL’s /vsicurl/ interface. I’ve noticed that directly
> downloading a file via curl can be much faster (~4x) than pulling the
> entire file via gdal_t
There are many environment variables for optimizing access to remote geotiffs
via GDAL’s /vsicurl/ interface. I’ve noticed that directly downloading a file
via curl can be much faster (~4x) than pulling the entire file via
gdal_translate or gdalmanage, and I think this is due to 1 GET request ve
Ubuntu 18.04.1 LTS
I am doing 'git clone' of master from OSGO/gdal and running the
gdal/ci/travis/ubuntu_1804 scripts. Script.sh is terminating with failures of
four tests from ogr_fgdb.py. There is a summary of those below. In theory these
should all pass, as the GitHub Travis CI was passing a
Alan,
your environment is correct, it is just that there are different versions of
libjson-c where function signatures have changed. We have had similar issues
in the past.
>
> I doing 'git clone' of master from OSGeo/gdal and running the
> gdal/ci/travis/osx scripts. The install.sh script ter
MacOS 10.12, xcode 9.2
I doing 'git clone' of master from OSGeo/gdal and running the
gdal/ci/travis/osx scripts. The install.sh script terminates because of:
plmosaicdataset.cpp::30: error: implicit conversion loses integer
precision: 'size_t' (aka 'unsigned long') to 'const int'
[-Werror,
+1 Frank
I think we are using it at scale and have ironed out our problems.
On Tue, Dec 18, 2018 at 10:16 AM Tamas Szekeres wrote:
> +1
>
> Tamas
>
>
> Even Rouault ezt írta (időpont: 2018. dec.
> 18., K, 12:35):
>
>> Hi,
>>
>> Motion: GDAL/OGR 2.3.3 rc2 is promoted to be the official 2.3.3 fi
+1
Tamas
Even Rouault ezt írta (időpont: 2018. dec.
18., K, 12:35):
> Hi,
>
> Motion: GDAL/OGR 2.3.3 rc2 is promoted to be the official 2.3.3 final
> release.
>
> ---
>
> My vote: +1
>
> ---
>
> Note: https://github.com/OSGeo/gdal/issues/1156 was raised yesterday.
> Would
> have been g
Hi,
I call this pre-RFC as I don't have yet any code implementing the following
ideas (so there might be holes in the analysis), but I wanted to get some
feedback before investing too much time into this substantial work.
Let's start with the easiest topic:
1) Use of OGRSpatialReference in GDA
Hi,
OSGeo projects will be asked (or have been, but can't find the email) for
their budget needs for 2019
Anything to add beyond the 5000 USD to renew the Travis-CI extended jobs ?
(that will benefit also to other projects that are under the OSGeo github
organization)
Even
--
Spatialys - Ge
+1
Daniel
On 2018-12-18 6:35 a.m., Even Rouault wrote:
Hi,
Motion: GDAL/OGR 2.3.3 rc2 is promoted to be the official 2.3.3 final release.
---
My vote: +1
---
Note: https://github.com/OSGeo/gdal/issues/1156 was raised yesterday. Would
have been good if it had been in 2.3.3 but I don
+1
Howard
On 12/18/18 6:15 AM, jratike80 wrote:
> +1
>
> -Jukka Rahkonen-
>
>
> Even Rouault-2 wrote
>> Hi,
>>
>> Motion: GDAL/OGR 2.3.3 rc2 is promoted to be the official 2.3.3 final
>> release.
>>
>> ---
>>
>> My vote: +1
>>
>> ---
>>
>> Note: https://github.com/OSGeo/gdal/issues/1156
+1
-Jukka Rahkonen-
Even Rouault-2 wrote
> Hi,
>
> Motion: GDAL/OGR 2.3.3 rc2 is promoted to be the official 2.3.3 final
> release.
>
> ---
>
> My vote: +1
>
> ---
>
> Note: https://github.com/OSGeo/gdal/issues/1156 was raised yesterday.
> Would
> have been good if it had been in 2
Hi,
Motion: GDAL/OGR 2.3.3 rc2 is promoted to be the official 2.3.3 final release.
---
My vote: +1
---
Note: https://github.com/OSGeo/gdal/issues/1156 was raised yesterday. Would
have been good if it had been in 2.3.3 but I don't really feel like doing
another RC for that, so that wi
Hi,
I m trying to do spatial adjustement of georefrenced shapfile with the help
of GDAL java bindings.
As in ArcMAP, there are many algorithms available for doing this task like
rubbersheeting, Affine, Projective.
While exploring, i didn't found such algorithms in gdal for performing this
task. Gr
Dear devs,
Is it possible to use gdal_calc.py to multiply each band of a
multispectral raster by a factor?
I've tried:
gdal_calc.py -A ReflPCA.tif --allBands=A --outfile=result.tif
--calc="A*[1,2,3,4,5,6]" --overwrite
it works fine with 1 single value,
gdal_calc.py -A ReflPCA.tif --allBands=A --o
Even Rouault-2 wrote
> On lundi 17 décembre 2018 16:00:30 CET umbertofilippo wrote:
>
> No, you can't pipe a shapefile. This is a multi file format, and OGR
> updates
> the files in a non sequential way. You have to create a temporary
> shapefile
> and zip it afterwards.
>
> --
> Spatialys - G
Hey,
It may depend on the input format, but for speed you probably want to read
at least a single block at a time, not a single pixel. The blocksize can be
inspected with "gdalinfo" for example.
Calculating those statistics can be done incrementally in a single pass, so
that's certainly possible
18 matches
Mail list logo
