[gdal-dev] Speeding up gdalwarp process

2020-01-22 Thread 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. Thank you.
Simon___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL and proj dll name.

2020-01-22 Thread Joaquim Manuel Freire Luís
FYI, this is what I do with my build. Since I want to control the DLL name I’ve 
added  this lines to  src\ lib_proj.cmake

# If a renaming of the proj dll has been set in ConfigUser.cmake
if (WIN32 AND PROJ4_DLL_RENAME)
set_target_properties(${PROJ_CORE_TARGET} PROPERTIES RUNTIME_OUTPUT_NAME 
${PROJ4_DLL_RENAME})
endif (WIN32 AND PROJ4_DLL_RENAME)

and in a ConfigUser.cmake file (included in the main CMakeLists.txt file) I have

set (PROJ4_DLL_RENAME proj_w${BITAGE})

where BITAGE is either 32 or 64.

If there is interest for such a solution I could make a PR for it


Joaquim


From: gdal-dev  On Behalf Of Tamas Szekeres
Sent: Wednesday, January 22, 2020 3:49 PM
To: Even Rouault 
Cc: gdal-dev 
Subject: Re: [gdal-dev] GDAL and proj dll name.

Hi Even,

Thank you, I've not considered to modify the linking behavior of proj.dll at 
this stage, but as far as it solves the problem I'm fine with it.

Best regards,

Tamas


Even Rouault mailto:even.roua...@spatialys.com>> 
ezt írta (időpont: 2020. jan. 22., Sze, 15:01):
Hi Tamas,

> However the GDAL build (like for
> https://github.com/OSGeo/gdal/blob/v2.4.4/gdal/ogr/ogrct.cpp) still using
> the default proj.dll name which cannot be configured in the opt file.

It can. You need to define -DPROJ_STATIC for that. -DPROJ_STATIC is a bit
confusing. It didn't mean a static build, but something that was linked at
build time (either a static or dynamic lib), to be opposed at being loaded at
runtime with LoadLibrary(). That's what you want to use.

# PROJ stuff
# Uncomment the following lines to link PROJ library statically. Otherwise
# it will be linked dynamically during runtime.
# To use the new API of proj5 or later, use
#PROJ_FLAGS = -DPROJ_STATIC -DPROJ_VERSION=5
# for proj 4.x:
#PROJ_FLAGS = -DPROJ_STATIC -DPROJ_VERSION=4

#PROJ_INCLUDE = -Id:\projects\proj.4\src
#PROJ_LIBRARY = d:\projects\proj.4\src\proj_i.lib

Even


--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL and proj dll name.

2020-01-22 Thread Tamas Szekeres
Hi Even,

Thank you, I've not considered to modify the linking behavior of proj.dll
at this stage, but as far as it solves the problem I'm fine with it.

Best regards,

Tamas


Even Rouault  ezt írta (időpont: 2020. jan.
22., Sze, 15:01):

> Hi Tamas,
>
> > However the GDAL build (like for
> > https://github.com/OSGeo/gdal/blob/v2.4.4/gdal/ogr/ogrct.cpp) still
> using
> > the default proj.dll name which cannot be configured in the opt file.
>
> It can. You need to define -DPROJ_STATIC for that. -DPROJ_STATIC is a bit
> confusing. It didn't mean a static build, but something that was linked at
> build time (either a static or dynamic lib), to be opposed at being loaded
> at
> runtime with LoadLibrary(). That's what you want to use.
>
> # PROJ stuff
> # Uncomment the following lines to link PROJ library statically. Otherwise
> # it will be linked dynamically during runtime.
> # To use the new API of proj5 or later, use
> #PROJ_FLAGS = -DPROJ_STATIC -DPROJ_VERSION=5
> # for proj 4.x:
> #PROJ_FLAGS = -DPROJ_STATIC -DPROJ_VERSION=4
>
> #PROJ_INCLUDE = -Id:\projects\proj.4\src
> #PROJ_LIBRARY = d:\projects\proj.4\src\proj_i.lib
>
> Even
>
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] How to indicate different location for specific libs ? RGDAL

2020-01-22 Thread Eduardo Almeida Costa
How to indicate different location for specific libs for rgdal?
I have libgif.so.4 in a different location.

/usr/bin/ld: warning: libgif.so.4, needed by
/home/helder.almeida/local/gnu/gdal/3.0.3/lib/libgdal.so, not found (try
using -rpath or -rpath-link)

I tried:
PKG_CPPFLAGS="-I/home/helder.almeida/local/gnu/giflib/5.2.1/include
-DACCEPT_USE_OF_DEPRECATED_PROJ_API_H"
PKG_LIBS="-L/home/helder.almeida/local/gnu/giflib/5.2.1/lib -lgdal"
./configure

and I tried the LD_LIBRARY_PATH variable, but with no success.

Thanks.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL and proj dll name.

2020-01-22 Thread Even Rouault
Hi Tamas,

> However the GDAL build (like for
> https://github.com/OSGeo/gdal/blob/v2.4.4/gdal/ogr/ogrct.cpp) still using
> the default proj.dll name which cannot be configured in the opt file.

It can. You need to define -DPROJ_STATIC for that. -DPROJ_STATIC is a bit 
confusing. It didn't mean a static build, but something that was linked at 
build time (either a static or dynamic lib), to be opposed at being loaded at 
runtime with LoadLibrary(). That's what you want to use.

# PROJ stuff
# Uncomment the following lines to link PROJ library statically. Otherwise
# it will be linked dynamically during runtime.
# To use the new API of proj5 or later, use
#PROJ_FLAGS = -DPROJ_STATIC -DPROJ_VERSION=5
# for proj 4.x:
#PROJ_FLAGS = -DPROJ_STATIC -DPROJ_VERSION=4

#PROJ_INCLUDE = -Id:\projects\proj.4\src
#PROJ_LIBRARY = d:\projects\proj.4\src\proj_i.lib

Even


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GDAL and proj dll name.

2020-01-22 Thread Tamas Szekeres
Hi,

As far as I see the current cmake builds of proj4/proj6 includes the proj
version number into the dll names like *proj_4_9.dll* for a Windows build.

However the GDAL build (like for
https://github.com/OSGeo/gdal/blob/v2.4.4/gdal/ogr/ogrct.cpp) still using
the default proj.dll name which cannot be configured in the opt file.

It is true that if we set the PROJSO config option properly the problem
disappears, something like:

Gdal.SetConfigOption("PROJSO", "proj_4_9.dll");

But that could also be avoided if there was a compile time setting to
specify the proj dll name. Does it make sense to establish a compile time
option for this purpose?

Thanks,

Tamas
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev