[gdal-dev] virtualmem py

[Nikolaos Ves]

Hi All,

I was experimenting with the GetVirtualMemArray python bindings and I am
receiving a 'Received a NULL pointer.' error (windows)

Also, the  tests virtualmem_{1..4} in appveyor are being skipped (and
they're rigged to skip if the platform is not equal to linux)

Are the VirtualMemArrays not working in windows?

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

Re: [gdal-dev] Using /vsicurl and /vsizip with zip files and signed S3 links

[Even Rouault]

> You could try one of the following :
> 
>   /vsizip//vsicurl/
> https://gsfc-ngap-hyp3-product-prod.s3.amazonaws.com/547/S1B_IW_GRDH_1SDV_20
> 170903T223511_20170903T223539_007233_00CC06_E9A8-POEORB-24-RGB.zip?AWSAccess
> KeyId=AKIAIYGQSCGFDA6WYRIQ&Expires=1824498425&Signature=WkQJbs%2FE6vLttvAAYt
> 2fXlKOeKk%3D/S1B_IW_GRDH_1SDV_20170903T223511_20170903T223539_007233_00CC06_
> E9A8-POEORB-24-RGB.tif

The hint did not work here because of the signature stuff after the .zip 
extension. I've fixed it and now it would propose:

/vsizip/{/vsicurl/https://gsfc-ngap-hyp3-product-prod.s3.amazonaws.com/547/S1B_IW_GRDH_1SDV_20170903T223511_20170903T223539_007233_00CC06_E9A8-POEORB-24-RGB.zip?AWSAccessKeyId=AKIAIYGQSCGFDA6WYRIQ&Expires=1824498425&Signature=WkQJbs%2FE6vLttvAAYt2fXlKOeKk%3D}/S1B_IW_GRDH_1SDV_20170903T223511_20170903T223539_007233_00CC06_E9A8-POEORB-24-RGB.tif

which will work

The fix is just for the hint, you can use the above syntax, documented in 
http://gdal.org/gdal_virtual_file_systems.html#gdal_virtual_file_systems_vsizip

"""Starting with GDAL 2.2, an alternate syntax is available so as to enable 
chaining and not being dependent
on .zip extension : /vsizip/{/path/to/the/archive}/path/inside/the/zip/file. 
Note that /path/to/the/archive may also itself use this alternate syntax."""

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] OGC announces a new standard that improves the way information is referenced to the earth

[Stadin, Benjamin]

Sure. But I mean: They should decide about and use S2 or whatever by default as 
part of the new standard and create a reference implementation, if they were 
serious about solving mentioned issues in practice.



Am 31.10.2017 um 19:14 schrieb Kurt Schwehr 
mailto:schw...@gmail.com>>:

See also space filling curves like the hilbert curve and Google's S2...

https://docs.google.com/presentation/d/1Hl4KapfAENAOf4gv-pSngKwvS_jwNVHRPZTTDzXXn6Q/view#slide=id.i0

On Tue, Oct 31, 2017 at 8:09 AM, Stadin, Benjamin 
mailto:benjamin.sta...@heidelberg-mobil.com>>
 wrote:
To me this proposal looks too complicated for practical application in it's 
current form. I think the surface model (or a "default" model) and related 
algorithms should be part of the proposal.

I needed to solve some of the problems they mention for our 3d rendering engine 
(store  vector data of multiple projections in an indexed storage and separate 
vector storage, projection and visible projection when rendering) as well as 
for parallel data processing of large data sets.

I found that systems which use ellipsoidal polygons on the surface model of the 
earth impractical for a variety of reasons: Image data and rendering systems 
mostly deal with rectangular tiles, there are commonly accepted (but not 
standardized) properties like zoom levels and tile sizes which many software 
adheres to, and also algorithm complexity and implementation effort.

I ended up with an adaptation of the MODIS grid for our application 
(https://modis-land.gsfc.nasa.gov/MODLAND_grid.html) so that cells (which are 
equal area in MODIS) are of the same length as OSM / Web Mercator tiles (at the 
equator), also considering zoom levels.

I think there is a real need for such concept, but in my opinion there needs to 
be a default model and algorithms in order to be relevant.

Best
Ben

Von meinem iPad gesendet

Am 31.10.2017 um 13:40 schrieb Roberto Ribeiro 
mailto:robertofi...@gmail.com>>:

I too took that understanding from the text, Ari. I'll read the specs later, 
but since they mention a lot Big Data and the raster <> vector integration, I  
it is akin to a geometry collection, but encompassing a wider range of data 
types, and arranged in a pyramid/r-tree -esque environment for faster 
processing.

If so, it's not an entirely novel idea (Esri's File GDB is mostly that, as well 
as the entire CAD modelling), but one that would be interesting to have an open 
standard for.

2017/10/31 ??4:23 "Ari Jolma" mailto:ari.jo...@gmail.com>>:
That also caught my eye. The text sounds a bit like marketing talk but maybe 
there is something.

>From a quick look my understanding is that the idea is to create a grid that 
>divides the whole earth into cells of similar shape in a sequence of 
>increasing cell size. And that sounds to me like a new idea.

Any other thoughts? Did I get the idea right?

Best,

Ari


Helmut Kudrnovsky kirjoitti 29.10.2017 klo 01:16:
Fyi

http://www.opengeospatial.org/pressroom/pressreleases/2656

"The goal of DGGS is to enable rapid assembly of spatial data without the
difficulties of working with projected coordinate reference systems. The OGC
DGGS Abstract Specification standard defines the conceptual model and a set
of rules for building highly efficient architectures for spatial data
storage, integration and analytics. ."



-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

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

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



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

[gdal-dev] Using /vsicurl and /vsizip with zip files and signed S3 links

[Scott Arko]

Hello GDAL Developers,


I am having trouble using the /vsis3 or /vsicurl driver with S3 signed
links and can't find any details in the archive of this list. I have a
signed S3 link that is a zip file containing a variety of other files,
including a geotiff, which is what I'm really after.   I would like to be
able to access the geotiff file only using a combination of /vsizip and
/vsicurl.   I am using GDAL version 2.2.1 on MacOS.  An example link is
below:

https://gsfc-ngap-hyp3-product-prod.s3.amazonaws.com/547/S1B_IW_GRDH_1SDV_20170903T223511_20170903T223539_007233_00CC06_E9A8-POEORB-24-RGB.zip?AWSAccessKeyId=AKIAIYGQSCGFDA6WYRIQ&Expires=1824498425&Signature=WkQJbs%2FE6vLttvAAYt2fXlKOeKk%3D

If I do a gdalinfo on this file using vsizip and vsicurl it seems to
recognize the file and gives me links to use to access the individual
elements.
gdalinfo /vsizip//vsicurl/"
https://gsfc-ngap-hyp3-product-prod.s3.amazonaws.com/547/S1B_IW_GRDH_1SDV_20170903T223511_20170903T223539_007233_00CC06_E9A8-POEORB-24-RGB.zip?AWSAccessKeyId=AKIAIYGQSCGFDA6WYRIQ&Expires=1824498425&Signature=WkQJbs%2FE6vLttvAAYt2fXlKOeKk%3D
"

ERROR 6: Support only 1 file in archive file /vsicurl/
https://gsfc-ngap-hyp3-product-prod.s3.amazonaws.com/547/S1B_IW_GRDH_1SDV_20170903T223511_20170903T223539_007233_00CC06_E9A8-POEORB-24-RGB.zip?AWSAccessKeyId=AKIAIYGQSCGFDA6WYRIQ&Expires=1824498425&Signature=WkQJbs%2FE6vLttvAAYt2fXlKOeKk%3D
when no explicit in-archive filename is specified

You could try one of the following :

  /vsizip//vsicurl/
https://gsfc-ngap-hyp3-product-prod.s3.amazonaws.com/547/S1B_IW_GRDH_1SDV_20170903T223511_20170903T223539_007233_00CC06_E9A8-POEORB-24-RGB.zip?AWSAccessKeyId=AKIAIYGQSCGFDA6WYRIQ&Expires=1824498425&Signature=WkQJbs%2FE6vLttvAAYt2fXlKOeKk%3D/S1B_IW_GRDH_1SDV_20170903T223511_20170903T223539_007233_00CC06_E9A8-POEORB-24-RGB.tif

  /vsizip//vsicurl/
https://gsfc-ngap-hyp3-product-prod.s3.amazonaws.com/547/S1B_IW_GRDH_1SDV_20170903T223511_20170903T223539_007233_00CC06_E9A8-POEORB-24-RGB.zip?AWSAccessKeyId=AKIAIYGQSCGFDA6WYRIQ&Expires=1824498425&Signature=WkQJbs%2FE6vLttvAAYt2fXlKOeKk%3D/S1B_IW_GRDH_1SDV_20170903T223511_20170903T223539_007233_00CC06_E9A8-POEORB-24-RGB.jpg

  /vsizip//vsicurl/
https://gsfc-ngap-hyp3-product-prod.s3.amazonaws.com/547/S1B_IW_GRDH_1SDV_20170903T223511_20170903T223539_007233_00CC06_E9A8-POEORB-24-RGB.zip?AWSAccessKeyId=AKIAIYGQSCGFDA6WYRIQ&Expires=1824498425&Signature=WkQJbs%2FE6vLttvAAYt2fXlKOeKk%3D/S1B_IW_GRDH_1SDV_20170903T223511_20170903T223539_007233_00CC06_E9A8-POEORB-24-RGB.jpg.aux.xml

  /vsizip//vsicurl/
https://gsfc-ngap-hyp3-product-prod.s3.amazonaws.com/547/S1B_IW_GRDH_1SDV_20170903T223511_20170903T223539_007233_00CC06_E9A8-POEORB-24-RGB.zip?AWSAccessKeyId=AKIAIYGQSCGFDA6WYRIQ&Expires=1824498425&Signature=WkQJbs%2FE6vLttvAAYt2fXlKOeKk%3D/ESA_citation.txt

  /vsizip//vsicurl/
https://gsfc-ngap-hyp3-product-prod.s3.amazonaws.com/547/S1B_IW_GRDH_1SDV_20170903T223511_20170903T223539_007233_00CC06_E9A8-POEORB-24-RGB.zip?AWSAccessKeyId=AKIAIYGQSCGFDA6WYRIQ&Expires=1824498425&Signature=WkQJbs%2FE6vLttvAAYt2fXlKOeKk%3D/S1B_IW_GRDH_1SDV_20170903T223511_20170903T223539_007233_00CC06_E9A8-POEORB-24-RGB.wld


Apologies for the funky formatting on this result.  However, if I try to
run gdalinfo on one of the recommended links (the geotiff), I get the
following (with --debug ON)

gdalinfo --debug ON /vsizip//vsicurl/"
https://gsfc-ngap-hyp3-product-prod.s3.amazonaws.com/547/S1B_IW_GRDH_1SDV_20170903T223511_20170903T223539_007233_00CC06_E9A8-POEORB-24-RGB.zip?AWSAccessKeyId=AKIAIYGQSCGFDA6WYRIQ&Expires=1824498425&Signature=WkQJbs%2FE6vLttvAAYt2fXlKOeKk%3D/S1B_IW_GRDH_1SDV_20170903T223511_20170903T223539_007233_00CC06_E9A8-POEORB-24-RGB.tif
"

GDAL: Auto register /opt/local/lib/gdalplugins/gdal_KEA.dylib using
GDALRegister_KEA.

GDAL: Assuming DCAP_RASTER for driver KEA. Please fix it.

GNM: GNMRegisterAllInternal

GNM: RegisterGNMFile

GNM: RegisterGNMdatabase

VSICURL: GetFileSize(
https://gsfc-ngap-hyp3-product-prod.s3.amazonaws.com/547/S1B_IW_GRDH_1SDV_20170903T223511_20170903T223539_007233_00CC06_E9A8-POEORB-24-RGB.zip?AWSAccessKeyId=AKIAIYGQSCGFDA6WYRIQ&Expires=1824498425&Signature=WkQJbs%2FE6vLttvAAYt2fXlKOeKk%3D/S1B_IW_GRDH_1SDV_20170903T223511_20170903T223539_007233_00CC06_E9A8-POEORB-24-RGB.tif)=0
response_code=403

VSICURL: GetFileSize(
https://gsfc-ngap-hyp3-product-prod.s3.amazonaws.com/547/S1B_IW_GRDH_1SDV_20170903T223511_20170903T223539_007233_00CC06_E9A8-POEORB-24-RGB.zip?AWSAccessKeyId=AKIAIYGQSCGFDA6WYRIQ&Expires=1824498425&Signature=WkQJbs%2FE6vLttvAAYt2fXlKOeKk%3D/S1B_IW_GRDH_1SDV_20170903T223511_20170903T223539_007233_00CC06_E9A8-POEORB-24-RGB.tif.xml)=0
response_code=403

ERROR 4: `/vsizip//vsicurl/
https://gsfc-ngap-hyp3-product-prod.s3.amazonaws.com/547/S1B_IW_GRDH_1SDV_20170903T223511_20170903T223539_007233_00CC06_E9A8-POEORB-24-RGB.zip?AWSAccessKeyId=AKIAIYGQSCGFDA6WYRIQ&Expires=1824498425&Signature=WkQJbs%2FE6vLttvAAYt2fXlKOeKk%3D/S1B_IW_GRDH_1SDV_20170903T22

[gdal-dev] Can't import ptrcreate from _gdal module

[Roberto Ribeiro]

I'm trying to work with a tool that, in one of its functions, uses a set of
_gdal methods regarding pointers (e.g. ptrcreate, ptradd, ptrvalue, etc.),
but when I try to import the function it returns me:

AttributeError: 'module' object has no attribute 'ptrcreate'

Doing a dir(_gdal) returns me a huge list of methods, but none of the
pointer ones. Is this a problem with my python bindings?

(gdal version 2.2.1 64-bits for Windows)
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Open Jpeg 2.3.0 and OPJ_NUM_THREADS

[N. Farah]

Thanks for the quick response. I'm not using latest GDAL and was curious where 
that multi-threading enabling was made ? Was it some where in GDAL code or 
through an option in the openjpeg 2.3.0 API ?


Thanks

Noureddine Farah


From: Even Rouault 
Sent: Tuesday, October 31, 2017 3:47:01 PM
To: gdal-dev@lists.osgeo.org
Cc: N. Farah
Subject: Re: [gdal-dev] Open Jpeg 2.3.0 and OPJ_NUM_THREADS


On mardi 31 octobre 2017 19:39:23 CET N. Farah wrote:

> Hi,

>

>

> In http://gdal.org/frmt_jp2openjpeg.html under 'Thread Support' section

> there is the following:

>

> "Starting with GDAL 2.3, this multi-threading at code-block level is

> automatically enabled by GDAL".

>

>

> Was meant "Starting with OpenJpeg 2.3, ..." ?



No, was meant starting with GDAL 2.3 (the current dev version). And that 
requires openjpeg >= 2.2 as well.



>

> If yes, was that enabling made in the 'OpenJpeg 2.3' library or was made in

> GDAL ?



openjpeg >= 2.2 (actually 2.1.2, but I restricted to 2.2 or later) brings 
multithreading decoding at codeblock level, and GDAL trunk automatically 
enables it.



So the doc is correct I think, but I know that those similar version numbers 
between GDAL and openjpeg can be confusing.



Bottom line: use the latest and greatest of both to get the better performance.



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] Open Jpeg 2.3.0 and OPJ_NUM_THREADS

[Even Rouault]

On mardi 31 octobre 2017 19:39:23 CET N. Farah wrote:
> Hi,
> 
> 
> In http://gdal.org/frmt_jp2openjpeg.html under 'Thread Support' section
> there is the following:
> 
> "Starting with GDAL 2.3, this multi-threading at code-block level is
> automatically enabled by GDAL".
> 
> 
> Was meant "Starting with OpenJpeg 2.3, ..." ?

No, was meant starting with GDAL 2.3 (the current dev version). And that 
requires openjpeg 
>= 2.2 as well.

> 
> If yes, was that enabling made in the 'OpenJpeg 2.3' library or was made in
> GDAL ?

openjpeg >= 2.2 (actually 2.1.2, but I restricted to 2.2 or later) brings 
multithreading decoding 
at codeblock level, and GDAL trunk automatically enables it.

So the doc is correct I think, but I know that those similar version numbers 
between GDAL 
and openjpeg can be confusing.

Bottom line: use the latest and greatest of both to get the better performance.

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] Open Jpeg 2.3.0 and OPJ_NUM_THREADS

[N. Farah]

Hi,


In http://gdal.org/frmt_jp2openjpeg.html under 'Thread Support' section there 
is the following:

"Starting with GDAL 2.3, this multi-threading at code-block level is 
automatically enabled by GDAL".


Was meant "Starting with OpenJpeg 2.3, ..." ?

If yes, was that enabling made in the 'OpenJpeg 2.3' library or was made in 
GDAL ?


Thanks

Noureddine Farah

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

Re: [gdal-dev] mingw64 build error gdal-2.2.2

[Even Rouault]

> 
> building 'osgeo._gdal_array' extension
> C:\msys64\mingw64\bin/x86_64-w64-mingw32-gcc.exe -fno-strict-aliasing
> -march=x86-64 -mtune=generic -O2 -pipe -fwrapv -D__USE_MINGW_ANSI_STDIO=1
> -DNDEBUG -DNDEBUG -I../../port -I../../gcore -I../../alg -I../../ogr/
> -I../../ogr/ogrsf_frmts -I../../gnm -I../../apps
> -IC:/msys64/mingw64/include/python2.7
> -IC:/msys64/mingw64/lib/python2.7/site-packages/numpy/core/include
> -Iinclude -c extensions/gdal_array_wrap.cpp -o
> build/temp.mingw-2.7/extensions/gdal_array_wrap.o In file included from
> ../../gcore/gdal.h:42:0,
>  from extensions/gdal_array_wrap.cpp:3143:
> ../../port/cpl_port.h:1119:5: error: conflicting declaration of 'int
> sprintf(char*, const char*, ...)' with 'C' linkage int sprintf(char *str,
> const char* fmt, ...) CPL_PRINT_FUNC_FORMAT(2, 3) CPL_WARN_DEPRECATED("Use
> snprintf() or CPLsnprintf() instead"); ^~~

What doesn't make sense is that the sprintf() definition at line 1119 of 
cpl_port.h should 
only be enabled if GDAL_COMPILATION is defined, and I don't see it in the above 
build line, 
and it shouldn't be present in a .h file normally. So there's something to 
investigate.

> In file included from C:/msys64/mingw64/include/python2.7/Python.h:33:0,
>  from extensions/gdal_array_wrap.cpp:172:
> C:/msys64/mingw64/x86_64-w64-mingw32/include/stdio.h:316:5: note: previous
> declaration with 'C++' linkage int sprintf (char *__stream, const char
> *__format, ...)
>  ^~~

This one is weird. It would seem that the original sprintf() definition would 
be understood as 
a C++ symbol, and not a C one. I'd hope stdio.h from mingw to have the usual 
extern "C" {} 
protection for that. 

-- 
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] mingw64 build error gdal-2.2.2

[Shawn Gong]

Hi list,



I am using mingw64 GCC to build gdal-2.2.2 and got the following error.

gdal-2.1.4. was built fine. and I couldn't find syntax difference in cpl_port.h 
between gdal 2.2.2 and 2.1.4.


Thanks,
Shawn

building 'osgeo._gdal_array' extension
C:\msys64\mingw64\bin/x86_64-w64-mingw32-gcc.exe -fno-strict-aliasing 
-march=x86-64 -mtune=generic -O2 -pipe -fwrapv -D__USE_MINGW_ANSI_STDIO=1 
-DNDEBUG -DNDEBUG -I../../port -I../../gcore -I../../alg -I../../ogr/ 
-I../../ogr/ogrsf_frmts -I../../gnm -I../../apps 
-IC:/msys64/mingw64/include/python2.7 
-IC:/msys64/mingw64/lib/python2.7/site-packages/numpy/core/include -Iinclude -c 
extensions/gdal_array_wrap.cpp -o 
build/temp.mingw-2.7/extensions/gdal_array_wrap.o
In file included from ../../gcore/gdal.h:42:0,
 from extensions/gdal_array_wrap.cpp:3143:
../../port/cpl_port.h:1119:5: error: conflicting declaration of 'int 
sprintf(char*, const char*, ...)' with 'C' linkage
 int sprintf(char *str, const char* fmt, ...) CPL_PRINT_FUNC_FORMAT(2, 3) 
CPL_WARN_DEPRECATED("Use snprintf() or CPLsnprintf() instead");
 ^~~
In file included from C:/msys64/mingw64/include/python2.7/Python.h:33:0,
 from extensions/gdal_array_wrap.cpp:172:
C:/msys64/mingw64/x86_64-w64-mingw32/include/stdio.h:316:5: note: previous 
declaration with 'C++' linkage
 int sprintf (char *__stream, const char *__format, ...)
 ^~~
In file included from 
C:/msys64/mingw64/include/python2.7/numpy/ndarraytypes.h:1809:0,
 from 
C:/msys64/mingw64/include/python2.7/numpy/ndarrayobject.h:18,
 from C:/msys64/mingw64/include/python2.7/numpy/arrayobject.h:4,
 from extensions/gdal_array_wrap.cpp:3464:
C:/msys64/mingw64/include/python2.7/numpy/npy_1_7_deprecated_api.h:13:79: note: 
#pragma message: 
C:/msys64/mingw64/include/python2.7/numpy/npy_1_7_deprecated_api.h(12) : 
Warning Msg: Using deprecated NumPy API, disable it by #defining 
NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION
  "#defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION")
   ^
error: command 'C:\\msys64\\mingw64\\bin/x86_64-w64-mingw32-gcc.exe' failed 
with exit status 1
make[2]: *** [GNUmakefile:68: build] Error 1
make[2]: Leaving directory '/c/build64/gdal-2.2.2/swig/python'
make[1]: *** [GNUmakefile:30: build] Error 2
make[1]: Leaving directory '/c/build64/gdal-2.2.2/swig'
make: *** [GNUmakefile:103: swig-modules] Error 2
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] OGC announces a new standard that improves the way information is referenced to the earth

[Kurt Schwehr]

See also space filling curves like the hilbert curve and Google's S2...

https://docs.google.com/presentation/d/1Hl4KapfAENAOf4gv-pSngKwvS_jwNVHRPZTTDzXXn6Q/view#slide=id.i0

On Tue, Oct 31, 2017 at 8:09 AM, Stadin, Benjamin <
benjamin.sta...@heidelberg-mobil.com> wrote:

> To me this proposal looks too complicated for practical application in
> it‘s current form. I think the surface model (or a „default“ model) and
> related algorithms should be part of the proposal.
>
> I needed to solve some of the problems they mention for our 3d rendering
> engine (store  vector data of multiple projections in an indexed storage
> and separate vector storage, projection and visible projection when
> rendering) as well as for parallel data processing of large data sets.
>
> I found that systems which use ellipsoidal polygons on the surface model
> of the earth impractical for a variety of reasons: Image data and rendering
> systems mostly deal with rectangular tiles, there are commonly accepted
> (but not standardized) properties like zoom levels and tile sizes which
> many software adheres to, and also algorithm complexity and implementation
> effort.
>
> I ended up with an adaptation of the MODIS grid for our application (
> https://modis-land.gsfc.nasa.gov/MODLAND_grid.html) so that cells (which
> are equal area in MODIS) are of the same length as OSM / Web Mercator tiles
> (at the equator), also considering zoom levels.
>
> I think there is a real need for such concept, but in my opinion there
> needs to be a default model and algorithms in order to be relevant.
>
> Best
> Ben
>
> Von meinem iPad gesendet
>
> Am 31.10.2017 um 13:40 schrieb Roberto Ribeiro :
>
> I too took that understanding from the text, Ari. I'll read the specs
> later, but since they mention a lot Big Data and the raster <> vector
> integration, I  it is akin to a geometry collection, but encompassing a
> wider range of data types, and arranged in a pyramid/r-tree -esque
> environment for faster processing.
>
> If so, it's not an entirely novel idea (Esri's File GDB is mostly that, as
> well as the entire CAD modelling), but one that would be interesting to
> have an open standard for.
>
> 2017/10/31 午前4:23 "Ari Jolma" :
>
>> That also caught my eye. The text sounds a bit like marketing talk but
>> maybe there is something.
>>
>> From a quick look my understanding is that the idea is to create a grid
>> that divides the whole earth into cells of similar shape in a sequence of
>> increasing cell size. And that sounds to me like a new idea.
>>
>> Any other thoughts? Did I get the idea right?
>>
>> Best,
>>
>> Ari
>>
>>
>> Helmut Kudrnovsky kirjoitti 29.10.2017 klo 01:16:
>>
>>> Fyi
>>>
>>> http://www.opengeospatial.org/pressroom/pressreleases/2656
>>>
>>> "The goal of DGGS is to enable rapid assembly of spatial data without the
>>> difficulties of working with projected coordinate reference systems. The
>>> OGC
>>> DGGS Abstract Specification standard defines the conceptual model and a
>>> set
>>> of rules for building highly efficient architectures for spatial data
>>> storage, integration and analytics. ."
>>>
>>>
>>>
>>> -
>>> best regards
>>> Helmut
>>> --
>>> Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
>>> ___
>>> gdal-dev mailing list
>>> gdal-dev@lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>>
>>
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>



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

Re: [gdal-dev] OGC announces a new standard that improves the way information is referenced to the earth

[Stadin, Benjamin]

To me this proposal looks too complicated for practical application in it's 
current form. I think the surface model (or a "default" model) and related 
algorithms should be part of the proposal.

I needed to solve some of the problems they mention for our 3d rendering engine 
(store  vector data of multiple projections in an indexed storage and separate 
vector storage, projection and visible projection when rendering) as well as 
for parallel data processing of large data sets.

I found that systems which use ellipsoidal polygons on the surface model of the 
earth impractical for a variety of reasons: Image data and rendering systems 
mostly deal with rectangular tiles, there are commonly accepted (but not 
standardized) properties like zoom levels and tile sizes which many software 
adheres to, and also algorithm complexity and implementation effort.

I ended up with an adaptation of the MODIS grid for our application 
(https://modis-land.gsfc.nasa.gov/MODLAND_grid.html) so that cells (which are 
equal area in MODIS) are of the same length as OSM / Web Mercator tiles (at the 
equator), also considering zoom levels.

I think there is a real need for such concept, but in my opinion there needs to 
be a default model and algorithms in order to be relevant.

Best
Ben

Von meinem iPad gesendet

Am 31.10.2017 um 13:40 schrieb Roberto Ribeiro 
mailto:robertofi...@gmail.com>>:

I too took that understanding from the text, Ari. I'll read the specs later, 
but since they mention a lot Big Data and the raster <> vector integration, I  
it is akin to a geometry collection, but encompassing a wider range of data 
types, and arranged in a pyramid/r-tree -esque environment for faster 
processing.

If so, it's not an entirely novel idea (Esri's File GDB is mostly that, as well 
as the entire CAD modelling), but one that would be interesting to have an open 
standard for.

2017/10/31 ??4:23 "Ari Jolma" mailto:ari.jo...@gmail.com>>:
That also caught my eye. The text sounds a bit like marketing talk but maybe 
there is something.

>From a quick look my understanding is that the idea is to create a grid that 
>divides the whole earth into cells of similar shape in a sequence of 
>increasing cell size. And that sounds to me like a new idea.

Any other thoughts? Did I get the idea right?

Best,

Ari


Helmut Kudrnovsky kirjoitti 29.10.2017 klo 01:16:
Fyi

http://www.opengeospatial.org/pressroom/pressreleases/2656

"The goal of DGGS is to enable rapid assembly of spatial data without the
difficulties of working with projected coordinate reference systems. The OGC
DGGS Abstract Specification standard defines the conceptual model and a set
of rules for building highly efficient architectures for spatial data
storage, integration and analytics. ."



-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

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

Re: [gdal-dev] OGC announces a new standard that improves the way information is referenced to the earth

[Roberto Ribeiro]

I too took that understanding from the text, Ari. I'll read the specs
later, but since they mention a lot Big Data and the raster <> vector
integration, I imagine it is akin to a geometry collection, but
encompassing a wider range of data types, and arranged in a pyramid/r-tree
-esque environment for faster processing.

If so, it's not an entirely novel idea (Esri's File GDB is mostly that, as
well as the entire CAD modelling), but one that would be interesting to
have an open standard for.

2017/10/31 午前4:23 "Ari Jolma" :

> That also caught my eye. The text sounds a bit like marketing talk but
> maybe there is something.
>
> From a quick look my understanding is that the idea is to create a grid
> that divides the whole earth into cells of similar shape in a sequence of
> increasing cell size. And that sounds to me like a new idea.
>
> Any other thoughts? Did I get the idea right?
>
> Best,
>
> Ari
>
>
> Helmut Kudrnovsky kirjoitti 29.10.2017 klo 01:16:
>
>> Fyi
>>
>> http://www.opengeospatial.org/pressroom/pressreleases/2656
>>
>> "The goal of DGGS is to enable rapid assembly of spatial data without the
>> difficulties of working with projected coordinate reference systems. The
>> OGC
>> DGGS Abstract Specification standard defines the conceptual model and a
>> set
>> of rules for building highly efficient architectures for spatial data
>> storage, integration and analytics. ."
>>
>>
>>
>> -
>> best regards
>> Helmut
>> --
>> Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] About CMake build again

[Mateusz Loskot]

On 30 October 2017 at 23:14, Even Rouault  wrote:
>
> Trying to sum up my thoughts on this topic and answering to various points
> raised in this discussion thread:
>
> - I believe a relevant question to ask to ourselves would be:
> "imagine that GDAL would come without any build system at all, what is the 
> one that we would add" ?

Assuming multi-platform is the critical requirement, there are no real
altenratives that beat CMake.

> Ok, that's a bit silly to turn the question like that, a more
> realistic one would be
> "imagine you're going to create a software that will rule over the world, for 
> the 20 next years
> and beyond, and should run on all reasonable platforms, which build system 
> would we use?

IMHO, answer to that is:
First, write portable code in build system agnostic way:
- Stick to C/C++ standard libraries as much as possible
- Stick to vanila preprocessor magic to handle C/C++ library
differences and incompatibilities.
- Eliminate or platform-specific generated headers (or keep it small,
one for all)
Then, choose multi-platfor build system and keep build configuration
scripts *small*.

That will make it easy to compile the code with any build system
current user wants to use
or any build system the project will switch over to in future, if necessary.

> If the answer is clearly "cmake", then it is worth examining if there is not 
> a path that
> would lead us to that point.

No, the anwer is not "clearly cmake".
CMake is great because it's multi-platform, it is available virtually
everywhere and easy to install.
CMake is terrible because it did not develop any best practices or
conventions regarding how
a perfect build configuration should be developed with CMake. That
historically led to home grown,
overgrown, bloated piles of CMake scripts specific to projects that
require maintenance on its own.
Even worse, many of those badly written scripts made it into CMake
distribution as FindXXX.cmake
modules, and CMake team did not reject or unify them.
The freedom led to ecosystem of numerous distinct build monsters
governed by specific conventions
based on CMake like ECM from KDE, BCM from Boost, and Borsch fall
sinto similar category, I think.
Naturally, GDAL would grown its own, beause CMake is rubbish :-)

An ideal build configuration scripts should be small, even for a large project.
Here is example of such setup proposed for Boost
https://github.com/ned14/boost-bmv-cmake
There is no pile of custom CMake macros or modules provided and that
is an ideal :)

> Similar question: is it an effort that will make GDAL development a bit
> easier for new contributors?

Perhaps, potentially, may be.
Certainly, CMake makes development friendly for use with modern IDEs.

> A nice side effect could also be the opportunity to drop some cruft that has
> accumulated over years in the current build systems (supporting ancient
> library versions that no longer make sense)

Dropping existing cruft is good.
Replacing cruft with new CMake cruft is bad idea.
Unfortunately, in most cases I've seen that is what happens when a
project migrates to CMake.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] [gdal 2.2.2] different result with gdal 2.1.0

[Even Rouault]

On mardi 31 octobre 2017 07:47:50 CET Vincent BERNAT wrote:
> Hello all,
> 
> 
> I was working with gdal 2.1.0 and i decide to update to 2.2.2
> 
> I work on Centos.
> 
> 
> Everything is ok but on one image, i don't get the same result (and the
> result with 2.2.2 seems incorrect).
> 
> 
> One of the most important difference is the result of the call of this
> function :
> 
> GDALSuggestedWarpOutput

You don't give enough information for other people to be able to reproduce. 
Which 
arguments do you pass to GDALSuggestedWarpOutput ?

Can you reproduce with gdalwarp ?

Here's what I've tried:

* generate an image with equivalent size and georeferencing as yours

gdal_translate byte.tif test.tif -a_srs 'PROJCS["ARC_System_Zone_18",
GEOGCS["GCS_Sphere",
DATUM["D_Sphere",
SPHEROID["Sphere",6378137.0,0.0]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433]],
PROJECTION["Azimuthal_Equidistant"],
PARAMETER["latitude_of_center",-90],
PARAMETER["longitude_of_center",0],
PARAMETER["false_easting",0],
PARAMETER["false_northing",0]]' \
   -outsize 1536 1536 -a_ullr 9713.965 556512.681 17400.989 548825.658

* wrap it to WGS84

gdalwarp test.tif out.tif -overwrite -t_srs EPSG:4326


With GDAL trunk or 2.1, I get the exact same result:

$ gdalinfo -checksum out.tif
Driver: GTiff/GeoTIFF
Files: out.tif
Size is 2165, 188
Coordinate System is:
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4326"]]
Origin = (1.2034652,-84.998318292160022)
Pixel Size = (0.000376928999761,-0.000376928999761)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (   1.000, -84.9983183) (  1d 0' 0.00"E, 84d59'53.95"S)
Lower Left  (   1.000, -85.0691809) (  1d 0' 0.00"E, 85d 4' 9.05"S)
Upper Right (   1.8160513, -84.9983183) (  1d48'57.78"E, 84d59'53.95"S)
Lower Right (   1.8160513, -85.0691809) (  1d48'57.78"E, 85d 4' 9.05"S)
Center  (   1.4080256, -85.0337496) (  1d24'28.89"E, 85d 2' 1.50"S)
Band 1 Block=2165x3 Type=Byte, ColorInterp=Gray
  Checksum=51779

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] write nodata value using using creation option

[Rashad Kanavath]

On Tue, Oct 31, 2017 at 12:10 PM, Even Rouault 
wrote:

> On mardi 31 octobre 2017 09:11:14 CET Rashad Kanavath wrote:
>
> > Thanks Jukka and Even for you reply.
>
> >
>
> > I am using otb to write gtiff image and using ExtendedFilename option in
>
> > otb, it allows me to pass creation options to gdal.
>
> > So for now, I write the image in otb without any extended filename stuff
>
> > and then add no_data by using GDALSetNoDataValue() in python.
>
> > In my python code, I can also call gdal_translate to do this via
>
> > subprocess.call()
>
> > but I was wondering if passing nodata value as creation option would be
>
> > possible?
>
>
>
> Almost everything is possible in theory, but I don't feel we need that
> redundancy.
>
> Why couldn't otb extendedFilename mechanisme be extended to support
> setting nodata through GDALSetNoDataValue(),
>
> with a gdal:nodata=value syntax ?
>
Yes.  I will see if can send a patch to otb!

>
>
> You don't need to use subprocess.call() to use gdal_translate
> functionnality.
>

Thanks for the sample code on using gdal_translate as function.

> See
>
> https://trac.osgeo.org/gdal/browser/trunk/autotest/utilities
> /test_gdal_translate_lib.py#L249
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
>



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

Re: [gdal-dev] SRS definition

[Peter Baumann]

FWIW, more about CRS URLs and the CRS resolver:
http://external.opengeospatial.org/twiki_public/CRSdefinitionResolver/

-Peter


On 10/31/2017 12:04 PM, Even Rouault wrote:
>
> On mardi 31 octobre 2017 08:58:24 CET Ari Jolma wrote:
>
> > Rasdaman writes SRS definitions such as
>
> > "http://ows.rasdaman.org/def/crs/EPSG/0/32633"; in WCS coverage
>
> > descriptions. The URL returns a gml:ProjectedCRS XML. GDAL fetches the
>
> > XML but then gives up in SetFromUserInput since it only expects "..that
>
> > this method will be extended in the future to support  XML".
>
> >
>
> > I wonder could the "crs/EPSG/0/32633" part be used as a proof that we
>
> > know what this is?
>
>  
>
> Ideally importFromXML() should better support GML serialized SRS (there's a
> ticket about that: https://trac.osgeo.org/gdal/ticket/6852 ), but I'd agree
> that a URL ending with crs/EPSG/0/32633 could be just redirected to
> importFromEPSGA(32633)
>
>  
>
> 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

-- 
Dr. Peter Baumann
 - Professor of Computer Science, Jacobs University Bremen
   www.faculty.jacobs-university.de/pbaumann
   mail: p.baum...@jacobs-university.de
   tel: +49-421-200-3178, fax: +49-421-200-493178
 - Executive Director, rasdaman GmbH Bremen (HRB 26793)
   www.rasdaman.com, mail: baum...@rasdaman.com
   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis 
dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec 
preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)


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

Re: [gdal-dev] write nodata value using using creation option

[Even Rouault]

On mardi 31 octobre 2017 09:11:14 CET Rashad Kanavath wrote:
> Thanks Jukka and Even for you reply.
> 
> I am using otb to write gtiff image and using ExtendedFilename option in
> otb, it allows me to pass creation options to gdal.
> So for now, I write the image in otb without any extended filename stuff
> and then add no_data by using GDALSetNoDataValue() in python.
> In  my python code, I can also call gdal_translate to do this via
> subprocess.call()
>  but I was wondering if passing nodata value as creation option would be
> possible?

Almost everything is possible in theory, but I don't feel we need that 
redundancy. 
Why couldn't otb extendedFilename mechanisme be extended to support setting 
nodata through GDALSetNoDataValue(),
with a gdal:nodata=value syntax ?

You don't need to use subprocess.call() to use gdal_translate functionnality.
See 
https://trac.osgeo.org/gdal/browser/trunk/autotest/utilities/test_gdal_translate_lib.py#L249

-- 
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] SRS definition

[Even Rouault]

On mardi 31 octobre 2017 08:58:24 CET Ari Jolma wrote:
> Rasdaman writes SRS definitions such as
> "http://ows.rasdaman.org/def/crs/EPSG/0/32633"; in WCS coverage
> descriptions. The URL returns a gml:ProjectedCRS XML. GDAL fetches the
> XML but then gives up in SetFromUserInput since it only expects "..that
> this method will be extended in the future to support  XML".
> 
> I wonder could the "crs/EPSG/0/32633" part be used as a proof that we
> know what this is?

Ideally importFromXML() should better support GML serialized SRS (there's a 
ticket 
about that: https://trac.osgeo.org/gdal/ticket/6852 ), but I'd agree that a URL 
ending 
with crs/EPSG/0/32633 could be just redirected to importFromEPSGA(32633)

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] About CMake build again

[Dmitry Baryshnikov]

Hi Even,

31.10.17 1:14, Even Rouault пишет:

Hi,

Trying to sum up my thoughts on this topic and answering to various points 
raised in this
discussion thread:

- I believe a relevant question to ask to ourselves would be: "imagine that 
GDAL would come
without any build system at all, what is the one that we would add" ? Ok, 
that's a bit silly to
turn the question like that, a more realistic one would be "imagine you're 
going to create a
software that will rule over the world, for the 20 next years and beyond, and 
should run on
all reasonable platforms, which build system would we use? If the answer is clearly 
"cmake",
then it is worth examining if there is not a path that would lead us to that 
point.
Similar question: is it an effort that will make GDAL development a bit easier 
for new
contributors?

This is clearly for me long ago and this is CMake.


- Must be reasonably friendly for GDAL developers, and for GDAL users (users 
here = people
building GDAL, but not actively hacking into its sources). As a user of cmake 
on Linux (and
marginally on Windows), my experiences are rather good.
Again want to point about illogical structure of source codes where we 
have some drivers in root folder (frmts)  and other drivers are deeper 
in the sources tree (ogr/ogrsf_frmts). And also we have raster drivers 
in ogrsf_frmts - like gpkg, cad (yes I know that they are raster-vector 
drivers) and vector drivers are in raster folder frmts, etc.


- the selling points I'd see with cmake would be the possibility of having 
ultimately a single
build system, instead of the 2 ones we have. + solving the current lack of 
dependency
tracking (speaking here about the mecanism that cause a change in a .h file to 
make the
.c/.cpp files that depend on it to be automatically rebuilt). We could add that 
by using
automake instead of our home-made GNUmakefile's, but doesn't feel like that's 
worth the
effort by itself.
A nice side effect could also be the opportunity to drop some cruft that has 
accumulated
over years in the current build systems (supporting ancient library versions 
that no longer
make sense)

+ 1


- If we added cmake support in trunk, I think this would only make sense if 
(all conditions to
be met)
*  we have at least a couple of "champions" to support the effort, and 
with an
agreement on how to use cmake as a in-tree build solution. Regarding Borsch, I 
think Dmitry
and his team did an impressive work, although I think that for GDAL we would 
want a more
"traditional" way of using cmake (in-tree, no particular requirents regarding 
how the
dependencies should be made). I'd hope that part of the work done on Borsch (or 
at the very
least good ideas and the lessons learnt) could be ported back to such a more 
traditional way
(and in a way where that would still be useful for Borsch. Possible win-win ?)
Using the find_anyproject function from Borsch (which is a wrapper 
around find_package) instead of find_package this is the only one 
requirements for successfully used in Borsch without any hacks (can be 
discussed to get win-win). Any others, like conventions about install 
paths, versions, naming etc. are optional and can be discussed too.

* growing it from an experimental status to the recommended build 
system, once
its completely mature. I'd expect that to require a transition over one or two 
release cycles
(one reason for that delay would be that systems ship with a recent enough 
version of cmake
regarding the minimum we would require)
* ultimately removing autoconf + nmake support. Clearly we don't want to
support 3 different build systems for the next 20 years.

- Thinking that if there's an agreement to give it a try, the next OSGeo code 
sprint ( https://
wiki.osgeo.org/wiki/OSGeo_Code_Sprint_2018 ) could be the opportunity to boost 
(no pun
intended) the effort

- I'm puzzled about some of you having apparently completely different feeback 
regarding
CMake on the same platform (MacOS). I don't owe a Mac, so I've no informed 
opinion on this.
But I see that a software, with a complexity similar to GDAL, like QGIS uses 
CMake and it
builds on Linux, Windows and MacOSX

- There wasn't much discussion about support for more exotic targets, like 
cross-compiling
for Windows with mingw compiler hosted on Linux. But openjpeg for example has 
Travis-CI
targets doing that, so this is at least achievable for a simple library.

- I've no fundamental objection to cmake... nor fundamental enthousiasm for it 
or mastering
of it (could say the same about autoconf/automake or nmake. Build systems are 
boring
subjects, aren't they ?)

Even

PS: for Ari, try ./configure --enanble-debug for builds with -g and without -O2 
;-)



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
I working on CMake for GDAL for a long time and ready and willing to 
take part in this work. But it is necessary

[gdal-dev] Dangers or letting a domain name expire

[Ari Jolma]

I had the domain name ajolma.net at some point and I kept there the 
documentation of the Perl bindings. Now they are at arijolma.org. At 
some point I let the name expire but I have not been very good at 
changing it everywhere. It is still for example in


https://trac.osgeo.org/gdal/browser/branches/2.2/gdal/swig/include/perl/gdal_perl.i

Apparently some chinese gambling entrepreneurs noted the expiration and 
now at ajolma.net there is the web page of a chinese casino.


I'll need to fix that file.

Ari


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

Re: [gdal-dev] write nodata value using using creation option

[Rashad Kanavath]

Thanks Jukka and Even for you reply.

I am using otb to write gtiff image and using ExtendedFilename option in
otb, it allows me to pass creation options to gdal.
So for now, I write the image in otb without any extended filename stuff
and then add no_data by using GDALSetNoDataValue() in python.
In  my python code, I can also call gdal_translate to do this via
subprocess.call()
 but I was wondering if passing nodata value as creation option would be
possible?

[1] https://wiki.orfeo-toolbox.org/index.php/ExtendedFileName



On Mon, Oct 30, 2017 at 9:37 PM, Even Rouault 
wrote:

> On lundi 30 octobre 2017 16:16:12 CET Rashad Kanavath wrote:
>
> > Hello,
>
> >
>
> > Is it possible to set nodata using -co option.?
>
> >
>
> > gdal_translate input.tif output.tif -co TIFFTAG_GDAL_NODATA=-3
>
> > Input file size is 500, 500
>
> > Warning 6: driver GTiff does not support creation option
> TIFFTAG_GDAL_NODATA
>
> > 0...10...20...30...40...50...60...70...80...90...100 - done.
>
> >
>
> > According to doc, TIFFTAG_GDAL_NODATA is an tag available if GeoTIFF
>
> > profile is GDALGeoTIFF. and by default the profile is exactly that. I
>
> > cross checked this with sources.
>
> >
>
> > using -a_nodata is working. But I would like to see if I can pass nodata
>
> > value via creation options. This is because in my workflow I am not using
>
> > gdal_translate utility.
>
>
>
> You can use the GDALSetNoDataValue() API, or its declinations in the
> language you use.
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
>



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

[gdal-dev] [gdal 2.2.2] different result with gdal 2.1.0

[Vincent BERNAT]

Hello all,


I was working with gdal 2.1.0 and i decide to update to 2.2.2

I work on Centos.


Everything is ok but on one image, i don't get the same result (and the result 
with 2.2.2 seems incorrect).


One of the most important difference is the result of the call of this function 
:

GDALSuggestedWarpOutput


Here are my image gdalinfo


Size is 1536, 1536
Coordinate System is:
PROJCS["ARC_System_Zone_18",
GEOGCS["GCS_Sphere",
DATUM["D_Sphere",
SPHEROID["Sphere",6378137.0,0.0]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433]],
PROJECTION["Azimuthal_Equidistant"],
PARAMETER["latitude_of_center",-90],
PARAMETER["longitude_of_center",0],
PARAMETER["false_easting",0],
PARAMETER["false_northing",0]]
Origin = (9713.964988580557474,556512.681478320620954)
Pixel Size = (5.004572695909427,-5.004572695909427)
Metadata:
  SRP_CREATIONDATE=20070417
  SRP_EDN=0
  SRP_NAM=APOLES01
  SRP_PRODUCT=ASRP
  SRP_REVISIONDATE=20070417
  SRP_SCA=5
  SRP_ZNA=18
Corner Coordinates:
Upper Left  (9713.965,  556512.681) (  1d 0' 0.00"E, 85d 0' 0.00"S)
Lower Left  (9713.965,  548825.658) (  1d 0'50.41"E, 85d 4' 8.55"S)
Upper Right (   17400.989,  556512.681) (  1d47'27.37"E, 84d59'53.95"S)
Lower Right (   17400.989,  548825.658) (  1d48'57.61"E, 85d 4' 2.42"S)
Center  (   13557.477,  552669.170) (  1d24'18.85"E, 85d 2' 1.66"S)
Band 1 Block=128x128 Type=Byte, ColorInterp=Palette
  NoData Value=0
  Color Table (RGB with 256 entries)
0: 0,0,0,255


Thanks a lot.

Regards,

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