Hi Even,
Please find my response below:
>Interesting, I wouldn't have thought this to change the result of the
>rounding, but who knows... Could you compare the color tables to check that
>the differences are just within a +/- 1 amplitude ?
Yes. The map does not change for +ve slope values. For -ve
Oh.. https://en.wikipedia.org/wiki/C_(programming_language)#Keywords ->
C99 added _Bool. Yuck. I thought that C matched C++ with bool. So never
mind this comment on bool.
> > - Can we get away from 0/FALSE and TRUE/1 for bools in in C++. e.g.
> > psOptions->bQuiet
>
> The API is intended to
>
> Which one should win if -spat and -where @... are both feeding a spatial
> filter? Should it be "either-or", or "both" as a combined filter with AND
> in between?
This is driver specific.
* For MongoDB, the -spat and -where filters are combined with a AND, which is I
guess the more logical b
Even Rouault spatialys.com> writes:
>
> Hi Jukka,
>
> Ah, might be true. The Unix shell allows to paste things like:
>
> What about "ogrinfo ES: the_layer -where filter.json" ?
>
> Iniitally, I though this could be a hack specific to the ES driver. But
there's
> the same thing with the mo
Le jeudi 27 août 2015 14:26:00, Jukka Rahkonen a écrit :
> Hi,
>
> I was trying the new read capabilities of the ElasticSearch driver
> http://www.gdal.org/drv_elasticsearch.html and I found it extraordinary
> hard to use the json filters from the command line on Windows. It is hard
> also with cu
Hi,
I was trying the new read capabilities of the ElasticSearch driver
http://www.gdal.org/drv_elasticsearch.html and I found it extraordinary hard
to use the json filters from the command line on Windows. It is hard also
with curl so I saved the filters on disk and read them as -d @file.json and
Hi Frank,
I was one of the original people who argued against the "array of strings"
approach...
On 27 August 2015 at 02:26, Frank Warmerdam wrote:
> I clearly should have been commenting sooner.
>
Several months ago :p
>
> I am concerned that having messy structures of options for each
> pr
Le jeudi 27 août 2015 12:23:07, Gawade P a écrit :
> Thanks, Even.I have tried this change on ppc and there were some
> differences in the map values resulting in a small deviation in the
> final checksum value compared to the current output on x86
> The output on ppc with this change is:
> bash-4.
Thanks, Even.I have tried this change on ppc and there were some
differences in the map values resulting in a small deviation in the
final checksum value compared to the current output on x86
The output on ppc with this change is:
bash-4.2# gdalchksum.py nwt_grd.grd
28093
33690
20365
25856
The expe
Le jeudi 27 août 2015 06:20:41, Gawade P a écrit :
> Good Morning, Even.
> I debugged this more, focusing, as you suggested, on the computation
> of the colormap and looks like the difference in the value of the
> checksum is due to the difference in calculation of the color map
> values for negat
Hi Frank,
>
> I clearly should have been commenting sooner.
>
> I am concerned that having messy structures of options for each
> program is going to complicate maintaining the actually commandline
> programs, and that it will still be a fragile and complicated point of
> entry as commandline ar
Hi Kurt,
> +1 from a non-voting person. It will definitely make testing a lot cleaner
> / easier without having to run a separate binary to get most of the testing
> done. There is also an enormous amount of python code that runs os.system
> / subprocess. That code is very error prone / a pain
Hi
I'm trying to load a test shapefile into Oracle using this syntax:
ogr2ogr -f "OCI" OCI:user/pwd@service test.shp -lco dim=2 -lco srid=3003
-nln test
Shapefile contains a non-nullable FID field, which I wish to be used as
unique constraint on the oracle table being created.
However, this uniqu
13 matches
Mail list logo
