> That worked for me (although I would have never found it, so I appreciate
> your help). I've put these two lines in gdal/swig/makefile.vc, e.g.
>
> --- a/gdal/swig/makefile.vc
> +++ b/gdal/swig/makefile.vc
> @@ -20,6 +20,8 @@ python: gdalvars
> $(SWIG) -c++ -python -modern -new_repr -I
Dear gdal community,
I'm a new user of gdal and I recently had a problem with precision. I tried
to translate a big GeoTIFF to a smaller one, specifying the extent of the
window in this way:
gdal_translate -projwin_srs EPSG:4326 -epo -strict -a_nodata 0 -projwin
9.50 46.00 10.00 45.500
Thanks Even,
Even Rouault wrote:
> Define
> SET DISTUTILS_USE_SDK=1
> SET MSSdk=1
>
> so that the active MSVC version is used when building the Python
> bindings. This is what is used in gisinternals builds & appveyor builds
That worked for me (although I would have never found it, so I appreci
> Also do you think
> https://trac.osgeo.org/gdal/browser/branches/2.2/autotest/gdrivers/ecw.py
> is setup to test the 3.3 SDK nicely? If so I can verify the patch on LINUX
> and MacOSX with that.
The tests pass fine (*) for me on Linux with ECW SDK 3.3 + libecwj2-3.3.patch.
No idea on Mac
(*) s
On 5 January 2018 at 21:43, Kurt Schwehr wrote:
> My preference (and not speaking for the gdal community) for C++ classes
> would be:
>
> 1. replace const char * -> const std::string &
> 2. replace CPLString -> std::string
+1
> Then in about 2022, we can see about std::string_view :(
+1
Best r
My preference (and not speaking for the gdal community) for C++ classes
would be:
1. replace const char * -> const std::string &
2. replace CPLString -> std::string
std::string GetString(const std::string &soName, const std::string
&soDefault = "") const;
This is where it would be good to get in
Hi Kurt,
Can you explain what should be done in PR?
Do you mean to replace all const char* to?
1. const char* -> const CPLString &
const char *GetString(const char *pszName, const char *pszDefault =
"") const; ->
CPLString GetString(const CPLString &soName, const CPLString
&soDefa
Hi Sean,
First of all I agreed with Kurt. Json-c is GDAL internal library and had
inspected by fuzzer.
Also json-c widely used in GDAL:
gdal/gcore
gdal/ogr/ogrsf_frmts/carto
gdal/ogr/ogrsf_frmts/amigocloud
gdal/ogr/ogrsf_frmts/cloudant
gdal/ogr/ogrsf_frmts/plscenes
gdal/ogr/ogrsf_frmts/geojso
Hi Even,
Happy New Year :)
On Sat, Jan 6, 2018 at 2:12 AM, Even Rouault
wrote:
> Hi Jeremy,
>
>
>
> I see that your gist has some of the fixes of libecwj2-3.3.patch, and a
> lot more (but some are not so obvious without digging more in the code)
>
I now have an internal git repo with both the
As I explained to Jeremy in an e-mail, I made those changes years ago. I don’t
remember the exact details. I do know that those are all specific to OS X, and
specifically to OS X and the Xcode toolchain circa 2011 (maybe?). Things are
much different today. I must have needed those changes to mak
On vendredi 5 janvier 2018 17:51:26 CET Gregory, Matthew wrote:
> Hi all,
>
> I'm sure to show my ignorance here, but I've been periodically building both
> the 2.2 and trunk branches on Windows using MSVC for Python 2.7 (as I think
> the compiler version needs to match how Python itself was built
Hi all,
I'm sure to show my ignorance here, but I've been periodically building both
the 2.2 and trunk branches on Windows using MSVC for Python 2.7 (as I think the
compiler version needs to match how Python itself was built [MSC v.1500 32 bit
(Intel)]). With the recent update in trunk requiri
I think the more important factors than speed for a C++ lib are: security,
stability, maintainability, and memory usage (low stack usage and
constrainable heap).
I really don't want to have us go through yet more piles of fuzzer bugs for
a library we depend on. It would be nice to have that alrea
+1 for wrapping the old C code in some cleaner abstractions!
But +10 for switching to a from the ground up C++ JSON library unless there
are clear reasons for a core C library (I don't think there are)
If we are talking about this kind of code, there are several things that
have bugged me in gene
Hi Dmitry,
I scanned the PR and it seems reasonable to me. I'm barely a C++ programmer
at all and it's clear to me, more clear than before. That said, I'm not a
fan of wrapping things that could be replaced. Have you looked into whether
a more performant C++ JSON library could be used? I haven't r
Dmitry,
> Is this ready to merge into the trunk? Any objections?
I did some review of your code. If nobody has extra remarks in the
next days, just merge it.
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev
Rutger,
ReadAsArray() / IRasterIO() with non-nearest resampling use the interpolation
code of
overview building (except for Lanczos where it uses the warping code), which
was of course
targetted at downsampling rather than upsampling. Nodata is taken into account
when
mixing together source
Hi Jeremy,
> https://gist.github.com/palmerj/54fa389c4e60fa7b9f1d5ceea7ac3359
Note that https://trac.osgeo.org/gdal/wiki/ECW references
https://trac.osgeo.org/gdal/attachment/wiki/ECW/libecwj2-3.3.patch which is the
cumlated patch of a number of patches that have been collected over the years
(
> OK, I understand now the VSICachedFile lifecycle and it makes sense. But
> then the disk cache should not be used at all for files in
> the CPL_VSIL_CURL_NON_CACHED variable.
Indeed. The cache disk code hasn't been touched/tested in years, and
CPL_VSIL_CURL_NON_CACHED was added afterwards.
>
Hi Even,
Long time no see!
On Fri, Jan 5, 2018 at 12:21 PM, Even Rouault
wrote:
> > 8) In the case discussed in 7), CPL_VSIL_CURL_NON_CACHED will just purge
>
> > the data from 1 the 3 caches: papsRegions. The vsil_cache and the disk
> will
>
> > still cache the content.
>
>
>
> CPL_VSIL_CURL_N
Hi,
> 1) There are a lot of knobs that can be used to tune the thing that are not
> documented. For example CPL_VSIL_CURL_USE_CACHE. Is it on purpose?
Yes, the disk cache is an experiment that isn't used anywhere (from what I
know) and likely
not in a finished state as you noticed in your below
21 matches
Mail list logo
