Re: [gdal-dev] Installation on Windows

2023-11-29 Thread Jeff McKenna via gdal-dev
You can find the popular Binaries at 
https://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries#Windows (great 
to see so many options listed there)


-jeff





--
Jeff McKenna
GatewayGeo: Developers of MS4W, & offering MapServer Consulting/Dev
co-founder of FOSS4G
http://gatewaygeo.com/




On 2023-11-29 7:18 a.m., Jürgen E. Fischer via gdal-dev wrote:

Hi Clive,

On Wed, 29. Nov 2023 at 10:57:48 +, Clive Swan via gdal-dev wrote:

Is there a detailed guide to installing GDAL on Windows 10?? I have attempted
installation several times, but just get error mesdages.


https://gdal.org/download.html#windows

Which one did you try and which error messages did you get?

I'd go with OSGeo4W[0], but that's not listed anymore and I'm biased.


Jürgen

[0] https://trac.osgeo.org/osgeo4w


=

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


Re: [gdal-dev] ogrinfo Unable to identify source geometry field with GDAL 3.7 but not 3.3?

2023-07-12 Thread Jeff McKenna

oops, the command was:

  ogr2ogr -f PostgreSQL "PG:dbname=nz_address port=xxx user=xxx 
password=xxx" nz-addresses.csv -oo GEOM_POSSIBLE_NAMES=WKT




-jeff



On 2023-07-12 9:19 a.m., Jeff McKenna wrote:
ogr2ogr -f "PG:dbname=nz_address port=xxx user=xxx password=xxx" 
nz-addresses.csv -oo GEOM_POSSIBLE_NAMES=WKT


--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/

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


Re: [gdal-dev] ogrinfo Unable to identify source geometry field with GDAL 3.7 but not 3.3?

2023-07-12 Thread Jeff McKenna

I also confirm the error with today's master (3.8.0dev).

Jukka is correct (same thinking as me), this works directly from CSV 
(into PostgreSQL 15.3) now...


  ogr2ogr -f "PG:dbname=nz_address port=xxx user=xxx password=xxx" 
nz-addresses.csv -oo GEOM_POSSIBLE_NAMES=WKT



-jeff



--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/




On 2023-07-12 8:58 a.m., Rahkonen Jukka wrote:

Hi,

I can confirm the error with GDAL 3.7.0. But because you have both .csv and .csvt it I 
wonder if there is any need to use .vrt. Output from "ogrinfo nz-addresses.csv" 
looks correct to me.

-Jukka Rahkonen-



-Alkuperäinen viesti-
Lähettäjä: gdal-dev  Puolesta Gary Turner
Lähetetty: keskiviikko 12. heinäkuuta 2023 4.36
Vastaanottaja: Even Rouault ; 
gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] ogrinfo Unable to identify source geometry field with GDAL 
3.7 but not 3.3?

As attached. I've removed some bulky documentation from the 
as-downloaded/supplied zip file.

On 11/07/2023 8:20 pm, Even Rouault wrote:

Gary,

please provide a VRT and CSV that can reproduce this

Even

Le 11/07/2023 à 03:55, Gary Turner a écrit :

Hi,
Apologies if this isn't the right place to ask, but I am struggling
to work out what's going on.
I'm setting up a new windows machine to process address data provided
by a local agency. I've downloaded new versions of software.
I use ogr2ogr to load csv files via a vrt file into postgres. This
works fine with my old setup, and has worked with various older
versions as well.
However with the latest ogr2ogr it fails. ogrinfo --version says GDAL
3.7.0, released 2023/05/02

P:\bin\gdal37>.\ogrinfo.exe C:\temp\addresses.vrt
INFO: Open of `C:\temp\addresses.vrt'
   using driver `OGR_VRT' successful.
1: addressesERROR 1: Unable to identify source geometry field 'WKT'
for geometry.
  (None)

but with an older version GDAL 3.3.1, released 2021/06/28
P:\bin\gdal33>.\ogrinfo.exe C:\temp\addresses.vrt
INFO: Open of `C:\temp\addresses.vrt'
   using driver `OGR_VRT' successful.
1: addresses (Point)

I get the same failure with ogr2ogr, but ogrinfo seemed simpler and
there's a much less complicated command-line.
I've cut this down to a one-field, one-line of csv example that does
the same thing, if that's useful.

Is this expected?
Is there an easy work-around, that would work with both versions?
Please let me know if I'm missing something obvious or just being
dumb, or should  ask elsewhere.

Thanks
Gary


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org

___
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] libtiff 4.5.1 is released

2023-06-14 Thread Jeff McKenna
Thanks Even.  One question (for packagers), is if the tools you 
mentioned to be removed are set through -Dtiff-contrib correct?


thanks,

-jeff




--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/



On 2023-06-14 9:45 a.m., Even Rouault wrote:

Hi,

I've promoted rc3 as the final 4.5.1 release.

Read about this release at:
https://libtiff.gitlab.io/libtiff/releases/v4.5.1.html

Note the following warning:
This version will be the last one supporting most TIFF tools (except 
tiffinfo,

tiffdump, tiffcp and tiffset), whose maintenance will be discontinued, due
to the lack of contributors able to address reported security issues.
Starting with libtiff v4.6.0, their source code, at this time ,will 
still be

available in the source distribution, but they will no longer be built by
default, and issues related to them will no longer be accepted in the
libtiff bug tracker.

The release tarball can be downloaded at:

https://download.osgeo.org/libtiff/tiff-4.5.1.tar.gz
https://download.osgeo.org/libtiff/tiff-4.5.1.tar.xz
https://download.osgeo.org/libtiff/tiff-4.5.1.zip

Signatures:
https://download.osgeo.org/libtiff/tiff-4.5.1.tar.gz.sig
https://download.osgeo.org/libtiff/tiff-4.5.1.tar.xz.sig
https://download.osgeo.org/libtiff/tiff-4.5.1.zip.sig

The release is also available at:
https://gitlab.com/libtiff/libtiff/-/releases/v4.5.1

Even



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


Re: [gdal-dev] GDAL 3.4.3 RC1 available

2022-04-29 Thread Jeff McKenna
Sorry for the delay in my usual testing, no issues here on Windows, with 
the MS4W build environment.  -jeff






--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/



On 2022-04-22 6:32 a.m., Even Rouault wrote:

Hi,

I have prepared a GDAL/OGR 3.4.3 release candidate.

Pick up an archive among the following ones (by ascending size):

   https://download.osgeo.org/gdal/3.4.3/gdal-3.4.3rc1.tar.xz
   https://download.osgeo.org/gdal/3.4.3/gdal-3.4.3rc1.tar.gz
   https://download.osgeo.org/gdal/3.4.3/gdal343rc1.zip

A snapshot of the gdalautotest suite is also available :

https://download.osgeo.org/gdal/3.4.3/gdalautotest-3.4.3rc1.tar.gz
   https://download.osgeo.org/gdal/3.4.3/gdalautotest-3.4.3rc1.zip

GDAL-GRASS plugin:

   https://download.osgeo.org/gdal/3.4.3/gdal-grass-3.4.3.tar.gz

The NEWS file is here :

   https://github.com/OSGeo/gdal/blob/v3.4.3RC1/gdal/NEWS.md

I'll call for a vote promoting it to final later next week if no
serious problems are reported before.

Best regards,

Even



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


Re: [gdal-dev] zlib vulnerability CVE-2018-25032 affecting GAL

2022-04-07 Thread Jeff McKenna

On 2022-04-07 11:07 a.m., Andrew C Aitchison wrote:


On Thu, 7 Apr 2022, Greg Troxel wrote:

Even Rouault  writes:


Most GDAL binary distributions don't use that internal copy but the
external zlib library provided by the operating system / distribution
channel.


I realize you are accomodating people who can somehow get and build gdal
sources but can't first install zlib, but from the packaging viewpoint
having included copies is a bad thing.  Yes, it shouldn't get used, but
if a dependency isn't declared it would be hidden or not provided and
then be used anyway.

I therefore think it would be good to consider removing the vendored
copies, or at least requiring explicit config to turn them on.  (I just
looked in the sources for how to build and didn't find it in README.  I
know I have figured out how to build and this isn't a request for help,
but in terms of the cmake migration the instructions are missing.)  It
looks like internal will just be used if zlib is not found.

I wonder if it's still really necessary/helpful to have included libs
like zlib.


I wondered whether it made a difference to driver plugins and "DLL hell"
- the PNG driver uses zlib/libz and libpng -
but it seems that we outlaw building gdriver plugins and internal 
libraries, so that would not be a reason to keep the internal libraries.




I can confirm the 'DLL hell' on Windows builds, with GDAL's internal 
zlib clashing (even with trying to disable all references to the 
internal code).


-jeff


--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] zlib vulnerability CVE-2018-25032 affecting GAL

2022-04-07 Thread Jeff McKenna
Thank-you Greg, this is exactly my earlier comment directly on the 
associated ticket this morning, but you explain it much better: 
https://github.com/OSGeo/gdal/issues/5587


It has caused so much grief downstream (zlib inside GDAL), that I 
believe it is time to remove it.


-jeff





On 2022-04-07 10:08 a.m., Greg Troxel wrote:


Even Rouault  writes:


Most GDAL binary distributions don't use that internal copy but the
external zlib library provided by the operating system / distribution
channel.


I realize you are accomodating people who can somehow get and build gdal
sources but can't first install zlib, but from the packaging viewpoint
having included copies is a bad thing.  Yes, it shouldn't get used, but
if a dependency isn't declared it would be hidden or not provided and
then be used anyway.

I therefore think it would be good to consider removing the vendored
copies, or at least requiring explicit config to turn them on.  (I just
looked in the sources for how to build and didn't find it in README.  I
know I have figured out how to build and this isn't a request for help,
but in terms of the cmake migration the instructions are missing.)  It
looks like internal will just be used if zlib is not found.

I wonder if it's still really necessary/helpful to have included libs
like zlib.


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


Re: [gdal-dev] GDAL 3.4.2 RC2 available

2022-03-09 Thread Jeff McKenna

On 2022-03-09 4:05 p.m., Jeff McKenna wrote:

On 2022-03-09 4:02 p.m., Even Rouault wrote:


Le 09/03/2022 à 20:53, Jeff McKenna a écrit :
Thanks Even.  RC2 works well on Windows in the MS4W build 
environment. The only issue was that I had to re-apply the patch for 
Poppler 22.x (this is the known issue of course, that is well 
discussed 
https://lists.osgeo.org/pipermail/gdal-dev/2022-March/055529.html )


Which patch did you need re-apply ? The ones of master are normally 
included in 3.4.2 : 
https://github.com/OSGeo/gdal/commit/2d5f96f233e6bda613e98e056bb9a39d12409e32 
+ 
https://github.com/OSGeo/gdal/commit/cbcfe2c8c5507ea00ef7371029ff94d0bf6f4a77 
.  But for nmake based builds, you perhaps need to add a /std:c++17 
switch to the POPPLER_CFLAGS variable (PS: the benefit of the CMake 
based builds where a single CMake command can be used to bump to c++17 
for all platforms is obvious here)


My builds are CMake, and that was the exact patch I've been applying to 
the POPPLER_EXTRAFLAGS, you're correct.  After that, CMake runs fine for 
me.


Ah sorry you're 100% correct, this was not with CMake, it was an nmake 
build.  Sorry (I was testing GeoTIFF with CMake minutes before this, 
confusing my brain ha).


-jeff




--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] GDAL 3.4.2 RC2 available

2022-03-09 Thread Jeff McKenna

On 2022-03-09 4:02 p.m., Even Rouault wrote:


Le 09/03/2022 à 20:53, Jeff McKenna a écrit :
Thanks Even.  RC2 works well on Windows in the MS4W build environment. 
The only issue was that I had to re-apply the patch for Poppler 22.x 
(this is the known issue of course, that is well discussed 
https://lists.osgeo.org/pipermail/gdal-dev/2022-March/055529.html )


Which patch did you need re-apply ? The ones of master are normally 
included in 3.4.2 : 
https://github.com/OSGeo/gdal/commit/2d5f96f233e6bda613e98e056bb9a39d12409e32 
+ 
https://github.com/OSGeo/gdal/commit/cbcfe2c8c5507ea00ef7371029ff94d0bf6f4a77 
.  But for nmake based builds, you perhaps need to add a /std:c++17 
switch to the POPPLER_CFLAGS variable (PS: the benefit of the CMake 
based builds where a single CMake command can be used to bump to c++17 
for all platforms is obvious here)


My builds are CMake, and that was the exact patch I've been applying to 
the POPPLER_EXTRAFLAGS, you're correct.  After that, CMake runs fine for me.


-jeff




--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] GDAL 3.4.2 RC2 available

2022-03-09 Thread Jeff McKenna
Thanks Even.  RC2 works well on Windows in the MS4W build environment. 
The only issue was that I had to re-apply the patch for Poppler 22.x 
(this is the known issue of course, that is well discussed 
https://lists.osgeo.org/pipermail/gdal-dev/2022-March/055529.html )


-jeff



--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/


On 2022-03-08 6:59 a.m., Even Rouault wrote:

Hi,

I've issued a RC2 with 2 additional fixes:

- DIMAP driver: register metadata on all 6 PNEO bands (#5420)
- GTIFF driver: remove limitation to 32,000 bytes when writing the GDAL 
metadata tag (#4116)


Pick up an archive among the following ones (by ascending size):

   https://download.osgeo.org/gdal/3.4.2/gdal-3.4.2rc2.tar.xz
   https://download.osgeo.org/gdal/3.4.2/gdal-3.4.2rc2.tar.gz
   https://download.osgeo.org/gdal/3.4.2/gdal342rc2.zip

A snapshot of the gdalautotest suite is also available :

https://download.osgeo.org/gdal/3.4.2/gdalautotest-3.4.2rc2.tar.gz
   https://download.osgeo.org/gdal/3.4.2/gdalautotest-3.4.2rc2.zip

GDAL-GRASS plugin:

   https://download.osgeo.org/gdal/3.4.2/gdal-grass-3.4.2.tar.gz

The NEWS file is here :

   https://github.com/OSGeo/gdal/blob/v3.4.2RC2/gdal/NEWS.md

Even

Le 07/03/2022 à 12:26, Even Rouault a écrit :

Hi,

I have prepared a GDAL/OGR 3.4.2 release candidate.

Pick up an archive among the following ones (by ascending size):

  https://download.osgeo.org/gdal/3.4.2/gdal-3.4.2rc1.tar.xz
  https://download.osgeo.org/gdal/3.4.2/gdal-3.4.2rc1.tar.gz
  https://download.osgeo.org/gdal/3.4.2/gdal342rc1.zip

A snapshot of the gdalautotest suite is also available :

https://download.osgeo.org/gdal/3.4.2/gdalautotest-3.4.2rc1.tar.gz
  https://download.osgeo.org/gdal/3.4.2/gdalautotest-3.4.2rc1.zip

GDAL-GRASS plugin:

  https://download.osgeo.org/gdal/3.4.2/gdal-grass-3.4.2.tar.gz

The NEWS file is here :

  https://github.com/OSGeo/gdal/blob/v3.4.2RC1/gdal/NEWS.md

I'll call for a vote promoting it to final later this week if no
serious problems are reported before.

Best regards,

Even



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


Re: [gdal-dev] CMAKE poppler c++17

2022-03-03 Thread Jeff McKenna

Hi Chris,

I'm not sure if this is exactly related to your issue, but here are my 
thoughts:


I do know that the recent poppler release relies on the C++17 standard, 
and there was a recent change in GDAL to accommodate this (see 
https://github.com/OSGeo/gdal/issues/5071 ).


In my case (for the Windows / MS4W community) I had to patch GDAL 3.4.1 
for this, but in your case you might want to grab GDAL-master from git 
as that will be easier to handle the new poppler.



-jeff



--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/




On 2022-03-03 4:03 p.m., chris english wrote:

Hi,
I am a weak link when it comes to CMAKE. Geos-3.10.2 and PROJ-8.2.1 were 
a breeze nonetheless.  A source build of libpoppler.so.119 via 
./configure went smoothly.


I have consistently failed at ogrpdflayer (well, only four times so far) 
on 'optional', that is a C++17 thing. <-  an example of a feeble 
understanding of build process requirements.


Recklessly editing lines in CMakeLists.txt:
41 # check compiler and set preferences.
42 set(CMAKE_CXX_STANDARD 17)
[ 44%] Built target gdal_STACIT
[ 44%] Building CXX object 
frmts/pdf/CMakeFiles/gdal_PDF.dir/ogrpdflayer.cpp.o


but further along we run across c++17 be contra-indicated as to

[ 49%] Built target gdal_PostGISRaster
[ 49%] Building CXX object 
frmts/dods/CMakeFiles/gdal_DODS.dir/dodsdataset2.cpp.o


from /home/chris/gdal/frmts/dods/dodsdataset2.cpp:38:
/usr/local/include/libdap/RCReader.h:114:16: error: ISO C++17 does not 
allow dynamic exception specifications

   114 |     RCReader() throw(Error);

which leads to a set by individual target approach as is said to be 
available


set_property(TARGETtgtPROPERTYCXX_STANDARD17)
set_property(TARGETtgtPROPERTYCXX_STANDARD11)

and were this the solution, what would it look like and where might it 
reside in say


CMakeCache.txt, or have I just gotten this all wrong, as I expect I have.

Ubuntu 20.04, gcc-9.3.0, and happy to have broken through to 49%, but 
wouldn't


that's 99% good news.

Chris



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


Re: [gdal-dev] GDAL, Proj and cacert

2022-02-11 Thread Jeff McKenna

On 2022-02-11 3:48 p.m., Howard Butler wrote:


On Feb 11, 2022, at 1:41 PM, Jeff McKenna 
mailto:jmcke...@gatewaygeomatics.com>> 
wrote:


Unfortunately this issue comes up very often, as you said, so much of 
our stack relies heavily on environment variables.  My hope is that in 
the long run, the ini-style of settings can help battle this Windows 
Server x64 issue (yes googling this does return many 
unproven/non-reproducible reports for other projects, very disheartening).


The frustrations of how to pass environment variables in different 
computing environments is an issue that's orthogonal to how GDAL 
expresses configuration through environment variables. I get that the 
rules of environment variable resolution can be quite bespoke depending 
on the computing platform and environment you are operating on, but it's 
not legit to say "environment variables don't always work for me, we 
should do config files, but I don't have a reproducible test case to 
show that"



I agree here.  But it's important to share and give thoughts, and by 
having an open discussion I'm sure other packagers will keep an eye open 
for such mysterious issues on Windows Server x64 with cacert environment 
variables.  (I hope to never see the issue reported again to me, ha)


-jeff




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


Re: [gdal-dev] GDAL, Proj and cacert

2022-02-11 Thread Jeff McKenna

On 2022-02-11 3:29 p.m., Howard Butler wrote:



On Feb 11, 2022, at 1:25 PM, Jeff McKenna 
mailto:jmcke...@gatewaygeomatics.com>> 
wrote:


Thanks for this discussion Paul, I can also add into the chaos that 
Windows Server x64 has known issues with reading environment variables 


What does this mean, specifically? Much of GDAL's behavior is controlled 
with environment variables.


Has Windows changed policies on how environment variables are expressed, 
consumed, and provided to processes? Is that simply just the case for 
running in an HTTP server like IIS?


Howard


It's a frustrating situation, where users report that Windows Server x64 
cannot find cacert (and other) environment variables, through both IIS 
and Apache.  This is years old, terribly difficult to reproduce, but I 
did once reproduce on an AWS server.  At the time I was only focused on 
the HTTP server side of things, so I cannot say here confidently how 
commandline processes are affected.


Unfortunately this issue comes up very often, as you said, so much of 
our stack relies heavily on environment variables.  My hope is that in 
the long run, the ini-style of settings can help battle this Windows 
Server x64 issue (yes googling this does return many 
unproven/non-reproducible reports for other projects, very disheartening).


-jeff



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


Re: [gdal-dev] GDAL, Proj and cacert

2022-02-11 Thread Jeff McKenna
Thanks for this discussion Paul, I can also add into the chaos that 
Windows Server x64 has known issues with reading environment variables 
(so in my case, for all MS4W x64 deployments, I have MS4W search known 
locations for the bundle, as a workaround for the code that fails to 
find the environment variables in the GDAL/PROJ/MapServer stack). 
Recently MapServer now has a config file where you can set these 
variables, to avoid that problem.  I believe the GDAL/PROJ stack needs 
something like this as well, to avoid the reliance on these system 
environment variables (full disclosure: I need to test if proj.ini 
accepts the cacert bundle as an environment variable, so my above point 
could be wrong, totally).  But I'm often wrong ha.


-jeff


--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/





On 2022-02-11 1:24 p.m., Paul Harwood wrote:

I have an application that uses GDAL with Proj Networking set on.

This is a cross platform application. It works on some platforms but on 
mac (for instance) I get runtime errors like this


GDAL failure (1) PROJ: Cannot open 
https://cdn.proj.org/us_nga_egm96_15.tif 
<https://cdn.proj.org/us_nga_egm96_15.tif>: error setting certificate 
file: xxx/cacert.pem


Proj is looking in the wrong place for the cacert file - which is in the 
proj search path. I would rather avoid using environment 
variables (complicated). Is there a programmatic way to set the Proj 
cacert location or a default location?


currently - the following are set


Gdal.SetConfigOption("CURL_CA_BUNDLE", Path.Combine(gdalData, 
"cacert.pem"));

Osr.SetPROJSearchPath(projData);
Osr.SetPROJEnableNetwork(true);


___
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] Nodata is None, but still has blanks?

2022-01-18 Thread Jeff McKenna

Hi Matt,

Just for the record, the TIFF tools are also distributed to the MS4W 
users as well, on the web mapping side of things ha (I use them often, 
so when I find something useful I try to distribute them). 
https://ms4w.com   Cheers from the far east side.


-jeff



On 2022-01-18 12:41 p.m., matt.wil...@yukon.ca wrote:
Never mind! Paying attention to the version numbers answers the Q: Conda 
is built from libtiff 4.x while GnuWin32 libtiff is back on version 3.x.


I’ll see if I can find a contact at libtiff.org about adding a line 
about the library and tools being available via Conda as well as the 
other sources.


-Matt//

*From:*gdal-dev  *On Behalf Of 
*matt.wil...@yukon.ca

*Sent:* January 18, 2022 9:34 AM
*To:* gdal-dev@lists.osgeo.org
*Subject:* Re: [gdal-dev] Nodata is None, but still has blanks?

A little off topic for this list but people here might know: I see Tiff 
Tools for Windows binaries[0] haven’t been updated since 2006. Conda has 
Windows libtiff packages which include the tiff tools executables.[1] Is 
the conda variant actually newer than 2006 or is it just current packaging?


[0]: http://www.libtiff.org/index.html <http://www.libtiff.org/index.html>

[1]: 
https://anaconda.org/conda-forge/libtiff/4.3.0/download/win-64/libtiff-4.3.0-h0c97f57_1.tar.bz2 
<https://anaconda.org/conda-forge/libtiff/4.3.0/download/win-64/libtiff-4.3.0-h0c97f57_1.tar.bz2>


-Matt//

*From:*Matt.Wilkie
*Sent:* January 18, 2022 8:35 AM
*To:* gdal-dev@lists.osgeo.org <mailto:gdal-dev@lists.osgeo.org>
*Subject:* RE: [gdal-dev] Nodata is None, but still has blanks?

Thank you Frank and Even.

As is so often the case on this list, I now have answers, and an 
education. I have been peripherally aware of the tiff tools from 
libtiff, but not enough so that they came to mind when seeking to puzzle 
out things. I’m now updated. ;-)


-Matt//


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



--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] Shortening schedule for CMake adoption ?

2022-01-17 Thread Jeff McKenna

On 2022-01-17 9:37 a.m., Even Rouault wrote:



Consequently we could shorten the rather conservative schedule




+1

thanks!

-jeff



--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] Building Gdal with C++ Visual Studio 2019 - Error Linking.

2021-11-12 Thread Jeff McKenna
Please also see the BuildHints wiki, as many of us were contributing 
there steps for Windows and other GDAL drivers over the years: 
https://trac.osgeo.org/gdal/wiki/BuildingOnWindows. Today it's still a 
gold mine of tips and configure steps that are key to making it all work 
together.


-jeff



--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/


On 2021-11-11 6:39 p.m., peter vG via gdal-dev wrote:
I've been trying to build the binaries for Gdal 3.3.3 (and 3.4.0) using 
Visual C++ (via Visual Studio 2019), but I am getting a linking error 
that has me scratching my head: LINK : "fatal error LNK1104: cannot open 
file 'C:\gdal-3.4.0\lib.obj'". What is lib.obj? I am new to Visual C++, 
having come from the CPP Builder world, so I'm still getting my head 
around this product. Any suggestions would be greatly appreciated as I 
am wasting my life trying to hunt down a solution!






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


Re: [gdal-dev] GDAL 3.4.0 is released

2021-11-08 Thread Jeff McKenna
All MapServer demo services (over 10+ OGC services) have been updated to 
GDAL 3.4.0 : https://demo.mapserver.org



-jeff



--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/




On 2021-11-08 9:42 a.m., Even Rouault wrote:

Hi,

On behalf of the GDAL/OGR development team and community, I am pleased to
announce the release of GDAL/OGR 3.4.0. GDAL/OGR is a C++ geospatial data
access library for raster and vector file formats, databases and web 
services.

It includes bindings for several languages, and a variety of command line
tools.

    http://gdal.org/

The 3.4.0 release is a new feature release with the following highlights:

* [RFC 81](https://gdal.org/development/rfc/rfc81_coordinate_epoch.html):
   Support for coordinate epochs in geospatial formats.
   Implemented in FlatGeoBuf, GeoPackage, MEM, VRT
* New GDAL drivers:
   - [Zarr](https://gdal.org/drivers/raster/zarr.html):
     read/write support for ZarrV2 (and experimental V3), using 2D 
classic raster

     API or multidimensional API:
   - [STACIT](https://gdal.org/drivers/raster/stacit.html):
     Spatio-Temporal Asset Catalog Items as virtual mosaics
* Other improvements:
   - number of enhancements in file system operations of /vsigs/
   - NITF: additions to comply with NITF Version 2.1 Commercial Dataset
     Requirements Document (NCDRD)
   - ODBC and PGeo: multiple fixes and improvements
   - SAFE (Sentinel1): multiple improvements related to SLC/calibration 
(change

     subdataset naming)
   - multidimensional API: caching, and other improvements
* Code linting and security fixes
* MDB driver (Java based) mark as deprecated. Planned for removal for 
GDAL 3.5.
   ODBC driver is the preferred solution (with up-to-date MDBTools 
library on

   non-Windows platforms)
* Writing side of Tiger driver deprecated and will be removed in GDAL 3.5
* Remainder: DODS, JPEG2000(Jasper), JPEGLS, MG4LIDAR, FUJIBAS, IDA, 
INGR and
   vector driver ARCGEN, ArcObjects, CLOUDANT, COUCHDB, DB2, DODS, FME, 
GEOMEDIA,
   GTM, INGRES, MONGODB, REC, WALK are planned for removal in GDAL 3.5. 
As well

   as Perl bindings

More complete information on the new features and fixes in the 3.4.0 
release can be found at:


   https://github.com/OSGeo/gdal/blob/v3.4.0/gdal/NEWS.md

The release can be downloaded from:
   * https://download.osgeo.org/gdal/3.4.0/gdal340.zip - source as a zip
   * https://download.osgeo.org/gdal/3.4.0/gdal-3.4.0.tar.gz - source as 
.tar.gz
   * https://download.osgeo.org/gdal/3.4.0/gdal-3.4.0.tar.xz - source as 
.tar.xz
   * https://download.osgeo.org/gdal/3.4.0/gdal-grass-3.4.0.tar.gz - 
GDAL-GRASS plugin
   * https://download.osgeo.org/gdal/3.4.0/gdalautotest-3.4.0.tar.gz - 
test suite
   * https://download.osgeo.org/gdal/3.4.0/gdal340doc.zip - 
documentation / website


Best regards,

Even



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


Re: [gdal-dev] Motion: promote GDAL 3.4.0RC3 as final issue

2021-11-07 Thread Jeff McKenna

RC3 works well in the MS4W/Windows environment.

Thanks!

-jeff



--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/


On 2021-11-04 9:33 a.m., Even Rouault wrote:

Hi,

RC3 should be the last iteration needed to allow 3.4.0 to be released.

Motion:

Adopt GDAL 3.4.0 RC3 as final 3.4.0 release

Starting with my +1

Even



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


Re: [gdal-dev] Gdal-dev mail archive search sites?

2021-11-02 Thread Jeff McKenna

Hi Matt,

mail-archive seems to be working now: 
https://www.mail-archive.com/gdal-dev@lists.osgeo.org/


-jeff



On 2021-11-01 3:31 p.m., matt.wil...@yukon.ca wrote:

 What about starting this archive?



https://marc.info/?q=about#Add


Thanks Markus,  I’ve asked MARC about adding gdal-dev.

I’ve done the same with Mail Archive[1] but the expected subscription 
confirmation doesn’t show up[2], though there is one dating back to 
2008[3]. Maybe the old one is getting in the way?


[1]: https://www.mail-archive.com/faq.html#newlist 
<https://www.mail-archive.com/faq.html#newlist>


[2]: https://www.mail-archive.com/archive@mail-archive.com/maillist.html 
<https://www.mail-archive.com/archive@mail-archive.com/maillist.html>


[3]: https://www.mail-archive.com/archive@mail-archive.com/msg16721.html 
<https://www.mail-archive.com/archive@mail-archive.com/msg16721.html>


I will follow up with gdal-dev-owner.

-Matt//


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




--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] Motion: promote GDAL 3.3.3 RC1

2021-10-27 Thread Jeff McKenna

No issues here with RC1 on Windows in the MS4W environment.

+1 jeff

thanks!






--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/




On 2021-10-27 8:43 a.m., Even Rouault wrote:

Hi,

Having heard no issues being reported regarding RC1

Motion:

Adopt GDAL 3.3.3 RC1 as final 3.3.3 release

Starting with my +1

Even



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


Re: [gdal-dev] Gdal-dev mail archive search sites?

2021-10-14 Thread Jeff McKenna

Hi Matt!

I just use Google search to query the archives:
- goto https://google.ca
- in the search box enter:site:lists.osgeo.org/pipermail/gdal-dev/ 
yoursearchterm


This may not always contain the latest archives (depending on the speed 
of Google-mothership bots), but I find it very helpful.


-jeff




--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/


On 2021-10-14 1:03 p.m., matt.wil...@yukon.ca wrote:

Hi All,

Now that the gdal mail archive on Nabble is gone is what options are 
there for searching through historical threads?


Thanks!

*Matt Wilkie*

Geomatics Developer & Administrator

Environment | Technology, Innovation and Mapping

T 867-667-8133 | _Yukon.ca <http://yukon.ca/>_

/Hours: 08:30-16:30, Mon-Wed: Office, Thu: Remote, Fri: Away./



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


Re: [gdal-dev] Motion: RFC 84: Migrating build systems to CMake

2021-10-11 Thread Jeff McKenna

+1  Will test on Windows systems.

-jeff



On 2021-10-11 11:14 a.m., Howard Butler wrote:

All,

Discussion on this topic has died down, and it appears there are no major 
objections, so I would like to put forward a motion to approve RFC 84. With a 
conservative timeline, the final outcome of this effort is GDAL will be 
CMake-only in May 2023.

You can view the proposal at 
https://github.com/OSGeo/gdal/blob/1d3c283d40f4d2145c11dfca4b537fb357f53600/gdal/doc/source/development/rfc/rfc84_cmake.rst

+1 Howard





--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] GDAL 3.3.2 RC3 is available [was Re: GDAL 3.3.2 RC2 available]

2021-09-01 Thread Jeff McKenna
From the Windows packaging point of view I'm also not a fan of the rc 
subdirectories.  (my 2 cents)


-jeff




--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/



On 2021-09-01 11:20 a.m., Sebastiaan Couwenberg wrote:

On 9/1/21 4:14 PM, Greg Troxel wrote:

Even Rouault  writes:


Updated download links following Sean's proposed directory naming
convention:

   https://download.osgeo.org/gdal/3.3.2rc3/gdal-3.3.2rc3.tar.xz
   https://download.osgeo.org/gdal/3.3.2rc3/gdal-3.3.2rc3.tar.gz
   https://download.osgeo.org/gdal/3.3.2rc3/gdal332rc3.zip


This surprised me - I thought the comment was about the directory name
in the unpacked set of files, not the URL.


 From a Debian packaging point of view I'm also not a fan of the rc
subdirectories, it was much better to have the RCs and final release in
the same directory.

3.3.2rc3 sorts after 3.3.2, 3.3.2~rc3 sorts before 3.3.2 but that
directory has the older rc2 release. If all future releases use the
pre-release suffix for the directory the watch file in the Debian
package can be adapted, otherwise we'll have the change to work with
whatever is use for the most recent release.

Kind Regards,

Bas



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


Re: [gdal-dev] Call for discussion on RFC 83: guidelines for the use of GDAL project sponsorship

2021-05-19 Thread Jeff McKenna

On 2021-05-19 12:19 p.m., Mateusz Loskot wrote:

On Wed, 19 May 2021 at 14:46, Even Rouault  wrote:

[...] Input welcome.
https://github.com/OSGeo/gdal/pull/3855


I left some as the PR comments.



Good document.  My only comment is that this document should also define 
how the PSC decisions mentioned are impacted by the new GDAL Advisory 
Board. (maybe adding a one line summary "note:" to explain this in 
writing here, even if you think 'it is explained in other doc')


Thanks,

-jeff




--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] Motion: promote GDAL 3.2.3 RC1

2021-05-01 Thread Jeff McKenna

On 2021-04-30 6:54 a.m., Even Rouault wrote:

Hi,

Not sure if anyone has given this a try, but anyway:

Motion:

Adopt GDAL 3.2.3 RC1 as final 3.2.3 release

Starting with my +1

Even



+1  (no issues testing 3.2.3-RC1 here on Windows)

-jeff



--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] Motion: adopt RFC80

2021-04-16 Thread Jeff McKenna

+1 jeff

(very minor comment: regarding the NumFocus application, today's count 
on GDAL-users mailing list subscriptions is 2524 and for GDAL-announce 
is 1023, I was just verifying that for you now)







--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/



On 2021-04-16 11:50 a.m., Even Rouault wrote:

Hi,

I hereby motion to adopt RFC 80:

https://github.com/OSGeo/gdal/pull/3682

This also implies adopting the "GDAL Sponsorship Prospectus"  at

https://docs.google.com/document/d/1yhMWeI_LgEXPUkngqOitqcKfp7ov6WsS41v5ulz-kd0/edit?ts=60777468# 
whose a PDF version will be uploaded on the website 
(https://github.com/OSGeo/gdal/pull/3681 to be updated)


and the proposed answers to the NumFOCUS application form are at:
https://docs.google.com/document/d/1bc5jdpCe1axdyBHxbJnun7e0DTyDoZI_eFYgJYnOhB8/edit 



which will be submitted consequently.

Starting with my +1

Even




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


Re: [gdal-dev] Motion: Motion: promote GDAL 3.2.2 RC1

2021-03-08 Thread Jeff McKenna

+1 jeff



On 2021-03-08 9:56 a.m., Even Rouault wrote:

Hi,

Having heard no issues being reported regarding RC1

Motion:

Adopt GDAL 3.2.2 RC1 as final 3.2.2 release

Starting with my +1

Even




--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] GDAL 3.2.2 RC1 available

2021-03-05 Thread Jeff McKenna

Hi Even,

No issues so far here on Windows (with PROJ 8.0).

-jeff






--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/



On 2021-03-05 8:06 a.m., Even Rouault wrote:

Hi,

I have prepared a GDAL/OGR 3.2.2 release candidate.

Pick up an archive among the following ones (by ascending size):

   https://download.osgeo.org/gdal/3.2.2/gdal-3.2.2rc1.tar.xz
   https://download.osgeo.org/gdal/3.2.2/gdal-3.2.2rc1.tar.gz
   https://download.osgeo.org/gdal/3.2.2/gdal322rc1.zip

A snapshot of the gdalautotest suite is also available :

   https://download.osgeo.org/gdal/3.2.2/gdalautotest-3.2.2rc1.tar.gz
   https://download.osgeo.org/gdal/3.2.2/gdalautotest-3.2.2rc1.zip

GDAL-GRASS plugin:

   https://download.osgeo.org/gdal/3.2.2/gdal-grass-3.2.2.tar.gz

The NEWS file is here :

   https://github.com/OSGeo/gdal/blob/v3.2.2RC1/gdal/NEWS

I'll call for a vote promoting it to final around beginning of next week 
if no

serious problems are reported before.

Best regards,

Even



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


Re: [gdal-dev] Motion (V2): remove and deprecate a few drivers

2021-03-04 Thread Jeff McKenna

+1 (wrong thread)


(I think we should also list the 3.5.0 milestone at 
https://github.com/OSGeo/gdal/milestones so packagers/community can make 
adjustments in time for that date)


-jeff



On 2021-03-04 12:32 p.m., Even Rouault wrote:

Hi,

Updating my yesterday motion with the feedback received (only second 
bullet updated with a more restricted set of drivers)


Motion:

- remove the vector drivers BNA, AeronavFAA, HTF, OpenAir, SEGUKOOA, 
SEGY, SUA, XPlane and raster drivers BPG, E00GRID, EPSILON, 
IGNFHeightASCIIGrid, NTv1. They have all been authored by myself and I'm 
not aware of them having been much used or being still in use. 
Implemented in https://github.com/OSGeo/gdal/pull/3373. They (driver 
code, doc and tests) have been moved to the 
https://github.com/OSGeo/gdal-extra-drivers


- deprecate the raster drivers DODS, JPEG2000 (superseded per 
JP2OpenJPEG), JPEGLS, MG4LIDAR, FUJIBAS, IDA, INGR, ZMAP and vector 
driver ARCGEN, ArcObjects, CLOUDANT, COUCHDB, DB2, DODS, FME, GEOMEDIA, 
GTM, INGRES, MONGODB (superserded per MongoDBV3), REC, WALK . They will 
now be disabled at runtime by default, with an explicit error message 
when they are triggered, unless the 
GDAL_ENABLE_DEPRECATED_DRIVER_{drivername}
configuration option is set to YES, and will be removed in GDAL 3.5. 
Implemented in https://github.com/OSGeo/gdal/pull/3505


Starting with my +1

Even




--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] Motion: remove and deprecate a few drivers

2021-03-04 Thread Jeff McKenna

+1

(I think we should also list the 3.5.0 milestone at 
https://github.com/OSGeo/gdal/milestones so packagers/community can make 
adjustments in time for that date)


-jeff



On 2021-03-03 2:48 p.m., Even Rouault wrote:

Hi,

Following the discussions of past weeks, I motion to:

- remove the vector drivers BNA, AeronavFAA, HTF, OpenAir, SEGUKOOA, 
SEGY, SUA, XPlane and raster drivers BPG, E00GRID, EPSILON, 
IGNFHeightASCIIGrid, NTv1. They have all been authored by myself and I'm 
not aware of them having been much used or being still in use. 
Implemented in https://github.com/OSGeo/gdal/pull/3373. They (driver 
code, doc and tests) have been moved to the 
https://github.com/OSGeo/gdal-extra-drivers


- deprecate the raster drivers DODS, FIT, GS7BG, GSAG, GSBG, JDEM, 
JPEG2000, JPEGLS, MG4LIDAR,

GMT, DOQ1, DOQ2, FUJIBAS, IDA, LAN, MFF, NDF, SDTS, SGI, XPM, ZMAP
and vector driver ARCGEN, ArcObjects, CLOUDANT, COUCHDB, DB2, DODS, FME,
GEOMEDIA, GTM, INGRES, MONGODB, REC, SDTDS, TIGER, WALK. They will now 
be disabled
at runtime by default, unless the 
GDAL_ENABLE_DEPRECATED_DRIVER_{drivername}
configuration option is set to YES, and will be removed in GDAL 3.5. 
Implemented in https://github.com/OSGeo/gdal/pull/3505


Starting with my +1

Even




--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] Motion: adopt RFC79: Listing of Service Providers on GDAL website

2021-02-25 Thread Jeff McKenna

+1

-jeff



On 2021-02-25 6:30 a.m., Even Rouault wrote:

Hi,

I motion to adopt RFC79: Listing of Service Providers on GDAL website:
https://github.com/OSGeo/gdal/pull/3473

Starting with my +1

Even




--
Jeff McKenna
GatewayGeo: MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] Fw: Building GDAL with ECW support

2021-02-01 Thread Jeff McKenna

Hi Kevin,

Some quick thoughts for your case:

- you can paste your large commands and code at https://pastebin.com/ 
and then share that link with this mailing list discussion in your 
message (for images, similar with https://pasteboard.co/ )


- the best source of build help is the GDAL "BuildHints" page 
(https://trac.osgeo.org/gdal/wiki/BuildHints) and specifically for ECW: 
https://trac.osgeo.org/gdal/wiki/ECW Although the hints can be old and 
for various versions, I find following those pages a "gold mine" of 
information.


-jeff



--
Jeff McKenna
GatewayGeo: MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/



On 2021-02-01 3:11 p.m., Pteroglossus via gdal-dev wrote:

Dear list,

I'm not a developer, I would just like to use the maps I have on Linux 
and stay away from Windows.


I've been trying to import some raster maps into GRASS. Problem is, they 
are .ecw files.


If I understood well, GDAL does not support this format natively and has 
to be built including specific modules to allow working with these files.


I tried following the instructions here and everything went fine until 
the "make" instruction which gives an endless loop.


I could provide you with the output of the "make" command but the 
resulting file is over 100 Kb.


Could you point me in the right direction please?

Thanks,
Kevin





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


Re: [gdal-dev] GDAL conda build

2020-11-17 Thread Jeff McKenna

Hi Jon,

No approval/funnel through one person for edits, you can just add your 
notes there, so others can follow them someday (and avoid list archive 
searching).  Over time maybe someone updates or enhances your notes, or 
not, that's how the wiki thrives.


Thanks for taking the time to do this, most do not (now I could use the 
exclamation mark here, ha)  :)


-jeff




--
Jeff McKenna
MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/



On 2020-11-17 10:06 a.m., Jon Morris wrote:

Hi Jeff,

No problem, I can do that. Does it need to be approved, or do people just keep 
editing until we're all happy with it?

Thanks,

Jon

-Original Message-
From: gdal-dev  On Behalf Of Jeff McKenna
Sent: 17 November 2020 13:58
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] GDAL conda build

Hi Jon,

You can press edit and add a section with all of your own notes (everything you 
have written here in your emails to the list) to the bottom of that page, so 
that way you avoid the thinking of 'i must update the entire wiki page'.  (no 
exclamation point needed)

thanks,

-jeff


--
Jeff McKenna
MapServer Consulting and Training Services co-founder of FOSS4G 
http://gatewaygeo.com/




On 2020-11-17 7:33 a.m., Jon Morris wrote:

Hi Jeff,

I don't feel I know enough about the process to start to update that page, as 
there is quite a lot of work to do!

In the end the recipe at 
https://github.com/osgeo-forge/libgdal-filegdb-feedstock worked for me, with a 
couple of minor tweaks to remove some warnings from the log. Updating it to 
v3.2.0 was also straightforward, only the version and md5 need to be updated. 
Once this is built, the libgdal-filegdb package can be installed to an 
environment containing conda-forge GDAL and you now have full FileGDB write 
support.

Thanks,

Jon

-Original Message-
From: gdal-dev  On Behalf Of Jeff McKenna
Sent: 16 November 2020 12:54
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] GDAL conda build

On 2020-11-11 9:00 a.m., Jon Morris wrote:

Hi Paul,

Thanks for your reply. The only reason we're trying to build locally
is to add FileGDB support - if there is a better way to add FileGDB
write support to conda-forge GDAL, I'd love to hear it! The GDAL docs
are very out of date when it comes to building on Windows - the "GDAL
Windows Building example for Plugins" links to
https://trac.osgeo.org/gdal/wiki/BuildingOnWindows
<https://trac.osgeo.org/gdal/wiki/BuildingOnWindows>.



Hi Jon,

For 10+ years we maintained the FileGDB build steps for Windows etc at
https://trac.osgeo.org/gdal/wiki/FileGDB

In general, as a person compiling GDAL, you should bookmark the
priceless "BuildHints" wiki page, see the "External Library" section
where various driver compile howtos are listed, at
https://trac.osgeo.org/gdal/wiki/BuildHints

(you can see how for users compiling drivers that a wiki is a lifeline,
recording build steps that may be 5 years old and 'stale', yet
containing valuable information to the user)

Please consider recording your steps as well, for other users, as you
travel down this path.

Thanks!

-jeff


--
Jeff McKenna
MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/






___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
[JBA COVID-19 
statement]<https://www.jbagroup.co.uk/sites/www.jbagroup.co.uk/files/documents/15-030%20JBA%20Business%20Continuity%20Briefing%20-%20Latest.pdf>
T +44 (0) 1756 799919
www.jbarisk.com<http://www.jbarisk.com>

[Visit our website]<http://www.jbarisk.com> 
[http://www.jbagroup.co.uk/imgstore/JBA-Email-Sig-Icons-LINKEDIN.png] 
<https://www.linkedin.com/in/jon-morris-a2897b4/>  [Follow us on Twitter] 
<https://twitter.com/jbarisk>
Find out more about us here: www.jbarisk.com<http://www.jbarisk.com/> and follow us on Twitter 
@JBARisk<http://twitter.com/JBARisk> and 
LinkedIn<https://www.linkedin.com/company/2370847?trk=tyah=clickedVertical%3Acompany%2CclickedEntityId%3A2370847%2Cidx%3A2-1-2%2CtarId%3A1447414259786%2Ctas%3AJBA%20RISK%20MANAGEMENT>

The JBA Group supports the JBA Trust.

All JBA Risk Management's email messages contain confidential information and 
are intended only for the individual(s) named. If you are not the named 
addressee you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by email if you have received this email 
by mistake and delete this email from your system.


JBA Risk Management Limited is registered in England, company number 07732946, 
1 Broughton Park, Old Lane North, Broughton, Skipton, North Yorkshire, BD23 
3FD, Telephone: +441756799919




___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
[JBA COVID-19 
s

Re: [gdal-dev] GDAL conda build

2020-11-17 Thread Jeff McKenna

Hi Jon,

You can press edit and add a section with all of your own notes 
(everything you have written here in your emails to the list) to the 
bottom of that page, so that way you avoid the thinking of 'i must 
update the entire wiki page'.  (no exclamation point needed)


thanks,

-jeff


--
Jeff McKenna
MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/




On 2020-11-17 7:33 a.m., Jon Morris wrote:

Hi Jeff,

I don't feel I know enough about the process to start to update that page, as 
there is quite a lot of work to do!

In the end the recipe at 
https://github.com/osgeo-forge/libgdal-filegdb-feedstock worked for me, with a 
couple of minor tweaks to remove some warnings from the log. Updating it to 
v3.2.0 was also straightforward, only the version and md5 need to be updated. 
Once this is built, the libgdal-filegdb package can be installed to an 
environment containing conda-forge GDAL and you now have full FileGDB write 
support.

Thanks,

Jon

-Original Message-
From: gdal-dev  On Behalf Of Jeff McKenna
Sent: 16 November 2020 12:54
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] GDAL conda build

On 2020-11-11 9:00 a.m., Jon Morris wrote:

Hi Paul,

Thanks for your reply. The only reason we're trying to build locally
is to add FileGDB support - if there is a better way to add FileGDB
write support to conda-forge GDAL, I'd love to hear it! The GDAL docs
are very out of date when it comes to building on Windows - the "GDAL
Windows Building example for Plugins" links to
https://trac.osgeo.org/gdal/wiki/BuildingOnWindows
<https://trac.osgeo.org/gdal/wiki/BuildingOnWindows>.



Hi Jon,

For 10+ years we maintained the FileGDB build steps for Windows etc at
https://trac.osgeo.org/gdal/wiki/FileGDB

In general, as a person compiling GDAL, you should bookmark the
priceless "BuildHints" wiki page, see the "External Library" section
where various driver compile howtos are listed, at
https://trac.osgeo.org/gdal/wiki/BuildHints

(you can see how for users compiling drivers that a wiki is a lifeline,
recording build steps that may be 5 years old and 'stale', yet
containing valuable information to the user)

Please consider recording your steps as well, for other users, as you
travel down this path.

Thanks!

-jeff


--
Jeff McKenna
MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/






___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
[JBA COVID-19 
statement]<https://www.jbagroup.co.uk/sites/www.jbagroup.co.uk/files/documents/15-030%20JBA%20Business%20Continuity%20Briefing%20-%20Latest.pdf>
T +44 (0) 1756 799919
www.jbarisk.com<http://www.jbarisk.com>

[Visit our website]<http://www.jbarisk.com> 
[http://www.jbagroup.co.uk/imgstore/JBA-Email-Sig-Icons-LINKEDIN.png] 
<https://www.linkedin.com/in/jon-morris-a2897b4/>  [Follow us on Twitter] 
<https://twitter.com/jbarisk>
Find out more about us here: www.jbarisk.com<http://www.jbarisk.com/> and follow us on Twitter 
@JBARisk<http://twitter.com/JBARisk> and 
LinkedIn<https://www.linkedin.com/company/2370847?trk=tyah=clickedVertical%3Acompany%2CclickedEntityId%3A2370847%2Cidx%3A2-1-2%2CtarId%3A1447414259786%2Ctas%3AJBA%20RISK%20MANAGEMENT>

The JBA Group supports the JBA Trust.

All JBA Risk Management's email messages contain confidential information and 
are intended only for the individual(s) named. If you are not the named 
addressee you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by email if you have received this email 
by mistake and delete this email from your system.


JBA Risk Management Limited is registered in England, company number 07732946, 
1 Broughton Park, Old Lane North, Broughton, Skipton, North Yorkshire, BD23 
3FD, Telephone: +441756799919




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

Re: [gdal-dev] GDAL conda build

2020-11-16 Thread Jeff McKenna

On 2020-11-11 9:00 a.m., Jon Morris wrote:

Hi Paul,

Thanks for your reply. The only reason we're trying to build locally is 
to add FileGDB support - if there is a better way to add FileGDB write 
support to conda-forge GDAL, I'd love to hear it! The GDAL docs are very 
out of date when it comes to building on Windows - the "GDAL Windows 
Building example for Plugins" links to 
https://trac.osgeo.org/gdal/wiki/BuildingOnWindows 
<https://trac.osgeo.org/gdal/wiki/BuildingOnWindows>.




Hi Jon,

For 10+ years we maintained the FileGDB build steps for Windows etc at 
https://trac.osgeo.org/gdal/wiki/FileGDB


In general, as a person compiling GDAL, you should bookmark the 
priceless "BuildHints" wiki page, see the "External Library" section 
where various driver compile howtos are listed, at

https://trac.osgeo.org/gdal/wiki/BuildHints

(you can see how for users compiling drivers that a wiki is a lifeline, 
recording build steps that may be 5 years old and 'stale', yet 
containing valuable information to the user)


Please consider recording your steps as well, for other users, as you 
travel down this path.


Thanks!

-jeff


--
Jeff McKenna
MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/






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

Re: [gdal-dev] Motion: promote GDAL 3.2.0 RC1

2020-10-29 Thread Jeff McKenna

On 2020-10-29 5:55 a.m., Even Rouault wrote:

Hi,

Having heard about no critical ([1]) issues regarding RC1

Motion:

Adopt GDAL 3.2.0 RC1 as final 3.2.0 release



+1

Works well on Windows.
The documentation build now throws 27 Doxygen warnings (with Doxygen 
1.8.20).


-jeff




--
Jeff McKenna
MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/




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

Re: [gdal-dev] Motion: promote GDAL 3.1.4 RC2

2020-10-21 Thread Jeff McKenna

On 2020-10-21 7:06 a.m., Even Rouault wrote:

Hi,

Motion:

Adopt GDAL 3.1.4 RC2 as final 3.1.4 release

Starting with my +1



+1 jeff





--
Jeff McKenna
MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] 3.1.4 RC2 available [Re: GDAL 3.1.4 RC1 available]

2020-10-20 Thread Jeff McKenna

On 2020-10-20 12:27 p.m., Alan Snow wrote:

Hi Jeff,

Sounds like you found the user writable directory in PROJ 7:

https://proj.org/resource_files.html#where-are-proj-resource-files-looked-for

https://proj.org/development/reference/functions.html#_CPPv440proj_context_get_user_writable_directoryP10PJ_CONTEXTi

Hopefully the links are helpful,
Alan


Thanks for the response Alan, yes that's exactly the documentation that 
I have open here, for the user writeable directory in PROJ7, that I've 
been following since the PROJ7 release.  You can see there the mention 
of the PROJ_LIB setting as well, I thought this was working with the 
earlier PROJ7 release, but will do more testing, it could be that I 
moved them from APPPDATA into PROJ_LIB after-the-fact.  Will do more 
testing...


-jeff



--
Jeff McKenna
MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/





On Tue, Oct 20, 2020, 10:18 AM Jeff McKenna 
mailto:jmcke...@gatewaygeomatics.com>> 
wrote:


Hi Even,

No issues here on Windows with RC2.  More info:

- MS4W build environment
    - VC 2017
    - proj-master, git-master, curl 7.73.0, sqlite 3.33.0, ...
    - no issues building GDAL 3.1.4 documentation with Sphinx 3.1.2
(other than the usual Sphinx/Doxygen 26 warnings)
    - I just noticed that proj-master is no longer using my PROJ_LIB
setting properly (instead with network=on the grids are downloaded into
the obscure Windows user "AppData" directoryI'll definitely have to
examine why...but that's for another list/day ha

Thanks,

-jeff



    -- 
Jeff McKenna

MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/


On 2020-10-20 7:40 a.m., Even Rouault wrote:
 > Hi,
 >
 > I've generated a RC2 that differs from RC1 with a single bug fix
in configure
 > regarding Debian and CharLS 2.1 (see
https://github.com/OSGeo/gdal/pull/3083)
 >
 > https://download.osgeo.org/gdal/3.1.4/gdal-3.1.4rc2.tar.xz
 > https://download.osgeo.org/gdal/3.1.4/gdal-3.1.4rc2.tar.gz
 > https://download.osgeo.org/gdal/3.1.4/gdal314rc2.zip
 >
 > Even
 >
 >> Hi,
 >>
 >> So that we can focus on 3.2.0 and onwards, I have prepared a
GDAL/OGR 3.1.4
 >> release candidate, which should be the final one in the 3.1 series.
 >>
 >> Pick up an archive among the following ones (by ascending size):
 >>
 >> https://download.osgeo.org/gdal/3.1.4/gdal-3.1.4rc1.tar.xz
 >> https://download.osgeo.org/gdal/3.1.4/gdal-3.1.4rc1.tar.gz
 >> https://download.osgeo.org/gdal/3.1.4/gdal314rc1.zip
 >>
 >> A snapshot of the gdalautotest suite is also available :
 >>
 >> https://download.osgeo.org/gdal/3.1.4/gdalautotest-3.1.4rc1.tar.gz
 >> https://download.osgeo.org/gdal/3.1.4/gdalautotest-3.1.4rc1.zip
 >>
 >> GDAL-GRASS plugin:
 >>
 >> https://download.osgeo.org/gdal/3.1.4/gdal-grass-3.1.4.tar.gz
 >>
 >> The NEWS file is here :
 >>
 >> https://github.com/OSGeo/gdal/blob/v3.1.4RC1/gdal/NEWS
 >>
 >> I'll call for a vote promoting it to final soon if no
 >> serious problems are reported before.
 >>
 >> Best regards,
 >>
 >> Even
 >
 >
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org <mailto: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] 3.1.4 RC2 available [Re: GDAL 3.1.4 RC1 available]

2020-10-20 Thread Jeff McKenna

Hi Even,

No issues here on Windows with RC2.  More info:

- MS4W build environment
  - VC 2017
  - proj-master, git-master, curl 7.73.0, sqlite 3.33.0, ...
  - no issues building GDAL 3.1.4 documentation with Sphinx 3.1.2 
(other than the usual Sphinx/Doxygen 26 warnings)
  - I just noticed that proj-master is no longer using my PROJ_LIB 
setting properly (instead with network=on the grids are downloaded into 
the obscure Windows user "AppData" directoryI'll definitely have to 
examine why...but that's for another list/day ha


Thanks,

-jeff



--
Jeff McKenna
MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/


On 2020-10-20 7:40 a.m., Even Rouault wrote:

Hi,

I've generated a RC2 that differs from RC1 with a single bug fix in configure
regarding Debian and CharLS 2.1 (see https://github.com/OSGeo/gdal/pull/3083)
  
https://download.osgeo.org/gdal/3.1.4/gdal-3.1.4rc2.tar.xz

https://download.osgeo.org/gdal/3.1.4/gdal-3.1.4rc2.tar.gz
https://download.osgeo.org/gdal/3.1.4/gdal314rc2.zip
  
Even



Hi,

So that we can focus on 3.2.0 and onwards, I have prepared a GDAL/OGR 3.1.4
release candidate, which should be the final one in the 3.1 series.

Pick up an archive among the following ones (by ascending size):

   https://download.osgeo.org/gdal/3.1.4/gdal-3.1.4rc1.tar.xz
   https://download.osgeo.org/gdal/3.1.4/gdal-3.1.4rc1.tar.gz
   https://download.osgeo.org/gdal/3.1.4/gdal314rc1.zip

A snapshot of the gdalautotest suite is also available :

   https://download.osgeo.org/gdal/3.1.4/gdalautotest-3.1.4rc1.tar.gz
   https://download.osgeo.org/gdal/3.1.4/gdalautotest-3.1.4rc1.zip

GDAL-GRASS plugin:

   https://download.osgeo.org/gdal/3.1.4/gdal-grass-3.1.4.tar.gz

The NEWS file is here :

   https://github.com/OSGeo/gdal/blob/v3.1.4RC1/gdal/NEWS

I'll call for a vote promoting it to final soon if no
serious problems are reported before.

Best regards,

Even




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

[gdal-dev] Happy 22nd birthday to GDAL !

2020-10-17 Thread Jeff McKenna
Happy 22nd birthday to GDAL ! From the first commit on 1998-10-17 from a 
small rural town outside of Ottawa Canada, to a CVS repository, to 
almost every geospatial software installation on the planet (and 
satellites and other planets!) in 22 years. The ultimate example of 
sharing & community.  Please celebrate the wonders of GDAL today, and 
thanks to everyone, who ever used it, contributed code or documentation, 
spoke about it at events, promoted it to their management, distributed 
it, or just plain gave it some love - this couldn't have happened 
without everyone one of you/us.   Thanks and happy birthday GDAL !!!


-jeff




--
Jeff McKenna
MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/



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

Re: [gdal-dev] 3.2.0 planning

2020-10-07 Thread Jeff McKenna
I think that works well, especially as the PROJ 7.2.0 release is planned 
for 1st November.


-jeff



--
Jeff McKenna
MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/



On 2020-10-07 7:05 a.m., Even Rouault wrote:

Hi,

As we've decided to try a 6-month cycle for feature releases, this means 
3.2.0 at beginning of november.


I see the following steps:

- Oct 19th: feature freeze. Creation of a release/3.2.0 branch, master 
opened for 3.3dev


- Oct 26th: cut a 3.2.0 release candidate

Reactions ?

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 mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Problem writing with ODS and XLSX drivers

2020-09-12 Thread Jeff McKenna

Hi Hernán,

Interesting results here with your file test.shp, on Windows, through 
ogr2ogr:


 - GDAL 2.4.4, expat 2.2.9 -> success  (looks good with LibreOffice 
7.0.0.3)
 - GDAL 3.1.3, expat 2.2.9 -> corrupt (LibreOffice says file is 
corrupt, cannot be opened)



-jeff



--
Jeff McKenna
MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/



On 2020-09-12 4:18 p.m., Hernán De Angelis wrote:

Even and all,

Thank you all for your kind help with this. The two test datasets can be 
found here:


https://geonatura.se/test.zip

https://geonatura.se/se_100km.zip

Both files are open data and can be used and shared. "Test.zip" is a 
subset of the Swedish registry of environmental monitoring stations 
(bathing water). It's attribute table contains a lot of Swedish names. 
Encoding is UTF-8. The other is a dataset distributed by the European 
Environmental Agency containing a 100x100 km grid for Sweden. No unusual 
characters there.


For both datasets the ogr command is:

ogr2ogr -f ODS test.ods test.shp test

and

ogr2ogr -f ODS se_100km.ods se_100km.shp se_100km

Note that exporting to CSV using ogr2ogr works like charm.

Thanks again!

/Hernán

On 2020-09-12 20:00, Even Rouault wrote:


On samedi 12 septembre 2020 17:20:29 CEST Hern�n De Angelis wrote:

> Hi everyone

>

> I am experiencing an odd and stubborn problem when trying to export

> attribute tables from both shp and spatialite to ods or xlsx. ogr2ogr

> finishes work silently with no reported errors but the generated output

> files cannot be opened with Libreoffice, which says the file is

> corrupted and is even unable to repair it.

>

> The input files are good from what I can see using QGIS and OGR but it

> is clear that something isn't right in my installation, my procedure or

> somewhere else. I am missing something? Have other users experienced 
this?


Please share minimal ods/xlsx files that can be used to reproduce the 
issue (and possibly source datasets + ogr2ogr invokation used to 
generate the ods/xlsx files)


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 mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Problem writing with ODS and XLSX drivers

2020-09-12 Thread Jeff McKenna

Hi Hernán,

I would also set CPL_DEBUG=ON at the commandline, before executing 
ogr2ogr.  You should see some useful output messages.


-jeff



--
Jeff McKenna
MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/



On 2020-09-12 12:20 p.m., Hernán De Angelis wrote:

Hi everyone

I am experiencing an odd and stubborn problem when trying to export 
attribute tables from both shp and spatialite to ods or xlsx. ogr2ogr 
finishes work silently with no reported errors but the generated output 
files cannot be opened with Libreoffice, which says the file is 
corrupted and is even unable to repair it.


The input files are good from what I can see using QGIS and OGR but it 
is clear that something isn't right in my installation, my procedure or 
somewhere else. I am missing something? Have other users experienced this?


I am using GDAL/OGR 3.1.2 in openSUSE Tumbleweed, compiled against expat 
2.2.9-1.12 (devel packages installed too, of course).


Any hint is appreciated!

Hernán







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

Re: [gdal-dev] Compiling GDAL with Visual Studio 2019

2020-09-08 Thread Jeff McKenna

On 2020-09-08 12:24 p.m., Alexis Vaisse wrote:


   I started from a fresh copy of GDAL 3.1.3, so there should be nothing clean.

   Interestingly, I get the same kind of errors when calling nmake /f 
makefile.vc clean:



Interesting.  I bet you get the same error with the command:  help call



(the response is supposed to be: "Calls one batch program from another")


-jeff




--
Jeff McKenna
MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Compiling GDAL with Visual Studio 2019

2020-09-08 Thread Jeff McKenna

On 2020-09-08 9:50 a.m., Alexis Vaisse wrote:


   Thanks.
   I tried to follow your suggestion, updated nmake.opt, added the PROJ library 
and here is what I get:


D:\Terrain\Extern\gdal-3.1.3>nmake -f makefile.vc MSVC_VER=1927 WIN64=1

Microsoft (R) Program Maintenance Utility Version 14.27.29110.0
Copyright (C) Microsoft Corporation.  All rights reserved.

 cd port
 nmake /nologo /f makefile.vc
 call prev_dllbuild.bat
The system cannot find the path specified.

D:\Terrain\Extern\gdal-3.1.3\port>IF NOT EXIST dllbuild.prev (ECHO 1 ) 
1>dllbuild.prev

D:\Terrain\Extern\gdal-3.1.3\port>SET /P PREV_DLLBUILD= 0IF NOT "1" == "1" (ECHO 1 ) 1>dllbuild.prev
NMAKE : fatal error U1077: 'call' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual 
Studio\2019\Community\VC\Tools\MSVC\14.27.29110\bin\HostX64\x64\nmake.EXE"' : return 
code '0x2'
Stop.


Have you first 'cleaned'?

   nmake /f makefile.vc clean
   nmake /f makefile.vc


-jeff



--
Jeff McKenna
MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/





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

Re: [gdal-dev] gdal 2.4.4 with WMS support

2020-09-06 Thread Jeff McKenna

On 2020-09-06 8:06 a.m., aborruso wrote:

jmckenna wrote

I believe curl is also required.


Thank you jeff. How do I must modify my configure command?




Maybe also try:   --with-curl=/usr/bin/curl-config

(depends on where you installed curl)

Have a nice weekend.

-jeff





--
Jeff McKenna
MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdal 2.4.4 with WMS support

2020-09-06 Thread Jeff McKenna

On 2020-09-06 8:06 a.m., aborruso wrote:

jmckenna wrote

I believe curl is also required.


Thank you jeff. How do I must modify my configure command?



Try:--with-curl=/usr/local/bin/curl-config


-jeff




--
Jeff McKenna
MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdal 2.4.4 with WMS support

2020-09-06 Thread Jeff McKenna

On 2020-09-06 6:35 a.m., aborruso wrote:

Hi all,
I have compiled and installed gdal 2.4.4 in this way:

wget http://download.osgeo.org/gdal/2.4.4/gdal244.zip
unzip gdal244.zip
cd ./gdal-2.4.4
./configure --prefix=/usr/local --with-sqlite3=/usr/local
--with-spatialite=/usr/local --with-static-proj4=/usr/local
--with-geos=/usr/local/bin/geos-config


I believe curl is also required.

-jeff






--
Jeff McKenna
MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: promote GDAL 3.1.3 RC1

2020-09-03 Thread Jeff McKenna

On 2020-09-03 5:45 a.m., Even Rouault wrote:

Hi,

Having heard no issues with RC1,

Motion:

Adopt GDAL 3.1.3 RC1 as final 3.1.3 release

+1 Even



+1  (no issues testing RC1 on Windows)

-jeff




--
Jeff McKenna
MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Compiling GDAL with ArcSDE support

2020-09-02 Thread Jeff McKenna

Hi Marcin,

In the long run, I would go with PostGIS/PostgreSQL, and then display 
directly in MapServer (as 
https://mapserver.org/input/vector/postgis.html )  GDAL's related driver 
page is full of interesting tips as well for PostGIS : 
https://gdal.org/drivers/vector/pg.html


-jeff



--
Jeff McKenna
MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/



On 2020-09-02 12:03 p.m., Marcin Grudzień wrote:

Dear Johan,

Good question.
So let me explain the problem. My organization is using ESRI desktop 
clients (mainly ArcGIS Desktop) to upload the spatial data to the 
databases used across the organization and publish it via network 
services. As DBMSs, we use Oracle and Postgres. We upload the data using 
Esri clients in versions 10.3.1 or 1.6.1.


Now I need GDAL to do two things:
1. Export the data form these databases to other formats.
2.  Use it to connect to MapServer to publish WMS, WFS services straight 
from databases.


So after looking through the documentation available online, I thought 
that using ArcSDE will be the best solution, but maybe there are better 
alternatives.


Best regards,
Marcin

Wiadomość napisana przez Johan Van de Wauw <mailto:johan.vandew...@gmail.com>> w dniu 02.09.2020, o godz. 15:39:


Marcin,

I managed to compile this extension against ubuntu 14.04 with at that 
time gdal 1.10 , while helping a customer migrating away from arcSDE.


https://lists.osgeo.org/pipermail/gdal-dev/2016-November/045445.html

At that time, it was only possible to receive this client sdk on cdrom 
(!). This was version 10.2, which I believe is the last version of 
ArcSDE. I guess it will be much harder to get it now.


Are you sure you are still using arcsde?

Kind Regards,
Johan



___
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] Fwd: NEXTGEN new release: SpatiaLite 5.0.0 RC1

2020-08-03 Thread Jeff McKenna
Forwarding this good news to the GDAL community...   (thank-you Sandro 
Furieri !!)




 Forwarded Message 



Hi list,

I'm glad to announce that after a very long pause of about two years
a new Relase Candidate is finally available.

The wait was not in vain;this is certainly the most advanced and 
sophisticated

SpatiaLite version ever been released and supports many cool new features:
1. full rasterlite2 integration
2. ISO Topology support
3. supporting new PROJ 6/7
4. supporting Stored Procedures
... and many others

please check the documentation about 5.0 from here:
https://www.gaia-gis.it/fossil/libspatialite/wiki?name=5.0.0-doc

full documentation about all SQL functions supported by 5.0 is here:
http://www.gaia-gis.it/gaia-sins/spatialite-sql-5.0.0.html

source tarballs can be downloaded from here:
http://www.gaia-gis.it/gaia-sins/libspatialite-sources/libspatialite-5.0.0-RC1.tar.gz
http://www.gaia-gis.it/gaia-sins/libspatialite-sources/libspatialite-5.0.0-RC1.zip

http://www.gaia-gis.it/gaia-sins/spatialite-tools-5.0.0-RC1.tar.gz
http://www.gaia-gis.it/gaia-sins/spatialite-tools-5.0.0-RC1.zip

pre-built binaries for Windows are here:
http://www.gaia-gis.it/gaia-sins/windows-bin-NEXTGEN-x86
http://www.gaia-gis.it/gaia-sins/windows-bin-NEXTGEN-amd64

I'll give in a following post further detailed infos about the
current state of all other members of the family (freexl,
readosm, rasterlite2, virtualPG and the GUI tool).

Happy testing,
Sandro




___
QGIS-Developer mailing list
qgis-develo...@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: promote GDAL 3.1.1 RC1

2020-06-25 Thread Jeff McKenna

+1 jeff

(howard's email is the first I've seen of this RC, as most would not 
have received the original post because of 
https://trac.osgeo.org/osgeo/ticket/2475 )




On 2020-06-25 10:10 a.m., Howard Butler wrote:



On Thu, Jun 25, 2020 at 5:19 AM Even Rouault <mailto:even.roua...@spatialys.com>> wrote:


__

Hi,

Having heard no issues with RC1,

Motion:

Adopt GDAL 3.1.1 RC1 as final 3.1.1 release

+1 Even


+1 Howard





--
Jeff McKenna
MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Problems loading swedish climate data to PostGIS

2020-06-23 Thread Jeff McKenna

Hi Thiemo,

What if you following my steps and create a new database (sverige2), 
then connect to that empty database with ogrinfo, and then try ogr2ogr 
on that new empty db.


-jeff



--
Jeff McKenna
MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/



On 2020-06-23 5:35 p.m., Thiemo Kellner wrote:

Hi Jeff

Thank you for sharing your steps. I tried to follow them and had an 
insight though I am still stuck. I noticed that I was passing the gdb 
file within the unzipped folder to ogr2ogr whereas you passed the folder 
path. Switching to your pattern it looks as follows.


thiemo @ thiemos-toshi /mnt/schweden % ogrinfo --formats | grep -i postg
   PostgreSQL -vector- (rw+): PostgreSQL/PostGIS
   PGDUMP -vector- (w+v): PostgreSQL SQL dump
# PostGIS capabilities of ogrinfo proven

thiemo @ thiemos-toshi /mnt/schweden % ogrinfo 
PG:"host='/var/run/postgresql' port='6543' dbname='sverige' user='sverige'"
INFO: Open of `PG:host='/var/run/postgresql' port='6543' 
dbname='sverige' user='sverige''

   using driver `PostgreSQL' successful.
1: tiger.county (Multi Polygon)
2: tiger.state (Multi Polygon)
...
# Connection to PostGIS works

thiemo @ thiemos-toshi /mnt/schweden % ogrinfo SCID_v4.0.gdb
INFO: Open of `SCID_v4.0.gdb'
   using driver `OpenFileGDB' successful.
1: HBVSv_intrans_HQloc100_rcp45_ensembleMean_diffPerc (Multi Polygon)
2: HBVSv_intrans_HQloc100_rcp85_ensembleMean_diffPerc (Multi Polygon)
...
# Proven to be able to read the gdb file(s)

thiemo @ thiemos-toshi /mnt/schweden % ogrinfo SCID_v4.0.gdb 
HBVSv_intrans_HQloc100_rcp85_ensembleMean_diffPerc -summary

INFO: Open of `SCID_v4.0.gdb'
   using driver `OpenFileGDB' successful.

Layer name: HBVSv_intrans_HQloc100_rcp85_ensembleMean_diffPerc
Geometry: Multi Polygon
Feature Count: 1103
...
# Proven to be able to access a specific layer in the gdb

thiemo @ thiemos-toshi /mnt/schweden % ogr2ogr –f "PostgreSQL" 
-overwrite –progress --config PG_USE_COPY YES 
PG:"host='/var/run/postgresql' port='5432' dbname='sverige' 
user='sverige'" SCID_v4.0.gdb 
HBVSv_intrans_HQloc100_rcp85_ensembleMean_diffPerc

FAILURE:
Unable to open datasource `PostgreSQL' with the following drivers.
   -> `PCIDSK'
...
# UNABLE TO USE ogr2ogr TO WRITE DATA TO MY PostGIS

thiemo @ thiemos-toshi /mnt/schweden :-( % ogr2ogr –f "ESRI Shapefile" 
test.shp SCID_v4.0.gdb/gdb.shp SCID_v4.0.gdb 
HBVSv_intrans_HQloc100_rcp85_ensembleMean_diffPerc

FAILURE:
Unable to open datasource `ESRI Shapefile' with the following drivers.
   -> `PCIDSK'
...
# To me it seems that I am not able to use ogr2ogr eventhough I can 
ogrinfo shape files

thiemo @ thiemos-toshi /mnt/schweden % ogrinfo --formats | grep -i esri
   ESRI Shapefile -vector- (rw+v): ESRI Shapefile
   ESRIJSON -vector- (rov): ESRIJSON
   PGeo -vector- (ro): ESRI Personal GeoDatabase
   OpenFileGDB -vector- (rov): ESRI FileGDB

I am pritty lost.

Kind regards

Thiemo

Quoting Jeff McKenna :


Hi Thiemo!

I have downloaded your data, to hopefully show you how I would tackle 
this.


First thing is to take this in very small steps, to confirm along the 
way, otherwise you jump to ogr2ogr without confirming that it is even 
possible on your system - in other words, live by *ogrinfo*, ogrinfo 
is your friend, and only move to ogr2ogr once you have ogrinfo happy, 
and then later use ogrinfo again for confirmation.


Here are my notes, I've made comments with the # symbol, and I should 
also mention that I am testing on Windows, with MS4W, so sometimes the 
exact command may slightly change (such as a single quote instead of a 
double quote in a command, on Linux systems) :


create database
---

#must first create an empty db (named 'scid' here), and load the 
PostGIS extension

createdb -U postgres -p 5436 -E UTF8 scid
psql -U postgres -d scid -p 5436 -c "CREATE EXTENSION postgis;"
psql -U postgres -d scid -p 5436 -c "CREATE EXTENSION postgis_topology;"

ogrinfo
---

#verify that your local GDAL/OGR is built with PostGIS and FileGDB 
support

ogrinfo --formats

    PostgreSQL -vector- (rw+): PostgreSQL/PostGIS
    MySQL -vector- (rw+): MySQL
    OpenFileGDB -vector- (rov): ESRI FileGDB
    XPlane -vector- (rov): X-Plane/Flightgear aeronautical data
    DXF -vector- (rw+v): AutoCAD DXF

#connect to your new database (see params for the PG driver at 
https://gdal.org/drivers/vector/pg.html )
ogrinfo PG:"host=localhost user=postgres password=postgres port=5436 
dbname=scid"


  INFO: Open of `PG:host=localhost user=postgres password=postgres 
port=5436 dbname=scid'

  using driver `PostgreSQL' successful.

#we're in business, no errors, yet no spatial tables listed yet, 
because there is none


#examine the file geodatabase
ogrinfo SCID_v4.0.gdb

INFO: Open of `SCID_v4.0.gdb'
  using driver `OpenFileGDB' successful.

#in my case, MS4W uses the 'OpenFileGDB' driver, but the 'FileGDB' 
driver i

Re: [gdal-dev] Problems loading swedish climate data to PostGIS

2020-06-23 Thread Jeff McKenna

Hi Thiemo!

I have downloaded your data, to hopefully show you how I would tackle this.

First thing is to take this in very small steps, to confirm along the 
way, otherwise you jump to ogr2ogr without confirming that it is even 
possible on your system - in other words, live by *ogrinfo*, ogrinfo is 
your friend, and only move to ogr2ogr once you have ogrinfo happy, and 
then later use ogrinfo again for confirmation.


Here are my notes, I've made comments with the # symbol, and I should 
also mention that I am testing on Windows, with MS4W, so sometimes the 
exact command may slightly change (such as a single quote instead of a 
double quote in a command, on Linux systems) :


create database
---

#must first create an empty db (named 'scid' here), and load the PostGIS 
extension

createdb -U postgres -p 5436 -E UTF8 scid
psql -U postgres -d scid -p 5436 -c "CREATE EXTENSION postgis;"
psql -U postgres -d scid -p 5436 -c "CREATE EXTENSION postgis_topology;"

ogrinfo
---

#verify that your local GDAL/OGR is built with PostGIS and FileGDB support
ogrinfo --formats

PostgreSQL -vector- (rw+): PostgreSQL/PostGIS
MySQL -vector- (rw+): MySQL
OpenFileGDB -vector- (rov): ESRI FileGDB
XPlane -vector- (rov): X-Plane/Flightgear aeronautical data
DXF -vector- (rw+v): AutoCAD DXF

#connect to your new database (see params for the PG driver at 
https://gdal.org/drivers/vector/pg.html )
ogrinfo PG:"host=localhost user=postgres password=postgres port=5436 
dbname=scid"


  INFO: Open of `PG:host=localhost user=postgres password=postgres 
port=5436 dbname=scid'

  using driver `PostgreSQL' successful.

#we're in business, no errors, yet no spatial tables listed yet, because 
there is none


#examine the file geodatabase
ogrinfo SCID_v4.0.gdb

INFO: Open of `SCID_v4.0.gdb'
  using driver `OpenFileGDB' successful.

#in my case, MS4W uses the 'OpenFileGDB' driver, but the 'FileGDB' 
driver is also possible


#356 layers should be listed there, with their layer names.  I'll use 
the last layer listed in the long list:


   356: HBVSv_MLSM_rcp85_ensembleMax_abs (Multi Polygon)

#so the layer name is 'HBVSv_MLSM_rcp85_ensembleMax_abs'

#examine the single layer through OGR/GDAL
ogrinfo SCID_v4.0.gdb HBVSv_MLSM_rcp85_ensembleMax_abs -summary

  - lists that there are 1103 features in that layer
  - EPSG (projection): https://epsg.io/3006

ogr2ogr
---

#now you are ready to use ogr2ogr to bring the FileGDB layer into your 
empty PG/PostGIS database
ogr2ogr -f PostgreSQL PG:"host=localhost user=postgres password=postgres 
port=5436 dbname=scid" SCID_v4.0.gdb HBVSv_MLSM_rcp85_ensembleMax_abs


ogrinfo
---

#use ogrinfo to confirm that the new spatial layer exists in your PG 
database
ogrinfo PG:"host=localhost user=postgres password=postgres port=5436 
dbname=scid"


 - should list your new layer 'hbvsv_mlsm_rcp85_ensemblemax_abs'

#examine your new layer
ogrinfo PG:"host=localhost user=postgres password=postgres port=5436 
dbname=scid" hbvsv_mlsm_rcp85_ensemblemax_abs -summary




Hope this helps.  Welcome to the FOSS4G community!

-jeff


--
Jeff McKenna
MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/




On 2020-06-23 4:27 a.m., Thiemo Kellner wrote:

Hi

I am new to spacial data processing. For a project of mine I try to load 
swedish climate data in to my PostGIS installation running/using an 
openSUSE Tumbleweed installation.





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

[gdal-dev] [Docs] Sphinx 3.1.0 + GDAL docs

2020-06-08 Thread Jeff McKenna
Hello fellow GDAL docs contributors, this really isn't worthy for a GDAL 
ticket, so I'm just sharing here on the mailing list: keep an eye open 
for the python 'breathe' package currently not allowing to build with 
Sphinx 3.1.0, which was released today (GDAL docs require breathe + 
sphinx).  You can follow along at 
https://github.com/michaeljones/breathe/issues/541


-jeff



--
Jeff McKenna
MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/





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

Re: [gdal-dev] self-compiled gdal linking to old already-remove proj libs

2020-05-16 Thread Jeff McKenna

Hi Andreas,

I have been in your exact situation before.  What's happening is that a 
GDAL dependency lib is still pointing to the old libproj version. 
Please check:


 ldd /usr/local/lib/libgdal.so | grep geotiff

and then ldd to the exact path of the geotiff lib, and look at 
which libproj is linked to


and do the same for spatialite:

  ldd /usr/local/lib/libgdal.so | grep spatialite

 and then ldd to the exact path of the spatialite lib, and look at 
which libproj is linked to


I bet that is what happening in your case also.  If I am correct, then 
you have to recompile those libraries and point to PROJ in /usr/local/


Cheers from across the ocean.

-jeff


--
Jeff McKenna
MapServer Consulting and Training Services
http://gatewaygeo.com/




On 2020-05-16 9:41 a.m., Andreas Neumann wrote:

Hi,

After my upgrade of Ubuntu 18.04 to 20.04 I am also renewing all my 
self-compiled "geo" libraries, such as proj, geos and gdal.


I removed old proj libs in /usr/local/lib then compiled and installed 
the  newest proj 7.0.1.


But now I am struggling with gdal - it always tries to link to old, 
already removed libproj versions. When I do


ldd /usr/local/lib/libgdal.so | grep proj

I get

     libproj.so.19 => /usr/local/lib/libproj.so.19 (0x7fbaff612000)
     libproj.so.15 => /usr/lib/x86_64-linux-gnu/libproj.so.15 
(0x7fbafd84e000)

     libproj.so.12 => not found

The libproj.so.12 was removed by me, libproj.so.19 and libproj.so.15 
probably came through some Ubuntu dependency.


How I can I tell the gdal configuration not to link to the already 
removed libproj.so.12 ? And maybe also ignore the libproj.so.15 version?


Thanks for any help!

Andreas



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

Re: [gdal-dev] Motion: promote GDAL 3.1.0 RC3

2020-05-05 Thread Jeff McKenna

On 2020-05-05 6:39 a.m., Even Rouault wrote:

Hi,

Motion: promote GDAL 3.1.0 RC3 to final 3.1.0




+1 jeff



--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeo.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: promote GDAL 3.1.0 RC2

2020-04-30 Thread Jeff McKenna

On 2020-04-30 6:34 a.m., Even Rouault wrote:


Motion: promote GDAL 3.1.0 RC2 to final 3.1.0


+1 jeff




--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeo.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.1.0 RC1 available

2020-04-27 Thread Jeff McKenna

On 2020-04-27 3:57 p.m., Even Rouault wrote:

 >

 > Note for packagers: the /doc/build/ output is ~112 MB (GDAL 2.4.4

 > /bin/html output was 1.6 MB)

Actually, "only" 62 MB if you consider only /doc/build/html



True! To clarify: my post of size was not a complaint but was for 
packagers wondering the total size.  (I'm one of those who distributes 
the docs for Windows/MS4W users with GDAL, which is handy for those who 
run workshops without internet)


-jeff




--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeo.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.1.0 RC1 available

2020-04-27 Thread Jeff McKenna
RC1 builds ok on Windows in VC2017, but, there were errors during the 
building of the docs.  I've created a pull request that fixes these 
errors on Windows (running MS4W's Python 3.7.5) : 
https://github.com/OSGeo/gdal/pull/2446


Note for packagers: the /doc/build/ output is ~112 MB  (GDAL 2.4.4 
/bin/html output was 1.6 MB)


-jeff



--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeo.com/




On 2020-04-27 10:37 a.m., Even Rouault wrote:

Hi,

I have prepared a GDAL/OGR 3.1.0 release candidate.

Pick up an archive among the following ones (by ascending size):

https://download.osgeo.org/gdal/3.1.0/gdal-3.1.0rc1.tar.xz

https://download.osgeo.org/gdal/3.1.0/gdal-3.1.0rc1.tar.gz

https://download.osgeo.org/gdal/3.1.0/gdal310rc1.zip

A snapshot of the gdalautotest suite is also available :

https://download.osgeo.org/gdal/3.1.0/gdalautotest-3.1.0rc1.tar.gz

https://download.osgeo.org/gdal/3.1.0/gdalautotest-3.1.0rc1.zip

A snapshot of the documentation is at:

https://download.osgeo.org/gdal/3.1.0/gdal310doc.zip

GDAL-GRASS plugin:

https://download.osgeo.org/gdal/3.1.0/gdal-grass-3.1.0.tar.gz

NEWS at:

https://github.com/OSGeo/gdal/blob/v3.1.0RC1/gdal/NEWS

Packagers: note that the documentation has been revamped to use Sphinx. 
If you want to build html and man pages, in addition to Doxygen, on top 
of my head, you need at least the following Python packages: sphinx, 
breathe, sphinx_rtd_theme (the recipee of the Docker image used to build 
GDAL and PROJ websites is at


https://github.com/OSGeo/PROJ/blob/master/docs/docbuild/Dockerfile , but 
I don't think you need all the packages mentioned)


For man pages, the tarball already includes them, so "make install-man" 
can be enough if you don't feel like regenerating them from .rst.


I'll call for a vote promoting it to final later this week if no

serious problems are reported before.

Best regards,

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] Is there a way to build GDAL without FreeType?

2020-04-27 Thread Jeff McKenna

Hi Craig,

Maybe your GDAL build uses libPoppler, which references the Freetype 
lib; you could disable that from your GDAL build and retry.


-jeff



--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeo.com/




On 2020-04-25 4:40 p.m., Craig Delancy wrote:

(Windows 10, 64-bit)

Is there a way to compile GDAL (3.0.4) without the dependency on FreeType?

I am trying to integrate the GDAL libraries into an existing software, 
which itself already links to FreeType2. This causes a series of 
conflicts such as:


freetype.lib(ftbase.obj) : error LNK2005: FT_DivFix already defined in 
gdal_i.lib(gdal300.dll)


These prevent me from being able to link GDAL and compile the 
executable. Is there a way to remove the dependency, or another way to 
resolve the multiple definitions?


Thanks.



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

Re: [gdal-dev] Windows CI build times

2020-04-17 Thread Jeff McKenna

Hi Even,

I would vote for removing the VS2015 testing.

-jeff



On 2020-04-16 8:16 p.m., Even Rouault wrote:

Hi,

I've been a bit frustrated lately by the time spent on the GDAL AppVeyor 
CI builds: roughly 50 minutes for each of the two configs we test, VS 
2017 x86 and VS 2015 x64, which can cause huge delays in case of busy 
days with many pull requests etc. (those delays also impact PROJ since 
the limitation to one simultaneous build is for the whole OSGeo GitHub 
organization)


The immediate solution would be to just test VS 2017 x64 to cut that 
time down and drop VS2015 and x64 testing. However as strange as it 
sounds, there are still people using x86 builds...


I guess porting to Azure Pipelines (which we already use to refresh 
gdal.org) could be a solution as well, since apparently they have a 10 
concurrent job limit ( according to


https://docs.microsoft.com/en-us/azure/devops/pipelines/licensing/concurrent-jobs?view=azure-devops 
)


A ccache type of builds could also help since we rarely change headers. 
I believe I tried to investigate that in the past but didn't find 
anything really working.


If someone is looking for ideas for contribution...

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] Building on windows

2020-03-24 Thread Jeff McKenna
Regarding your original error, googling it returns this discussion which 
has a GDAL connection, and a solution: 
https://stackoverflow.com/questions/60824242/suddenly-getting-builtin-ia32-sqrtsd-round-is-undefined-with-nvcc-gcc


-jeff



--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeomatics.com/



On 2020-03-24 7:50 a.m., Darrel Maddy wrote:

Not having much luck here.  Anyone got any further suggestions?

I turned to windows because of a problem with my linux build  - this is 
throwing up errors such as


/usr/lib/gcc/x86_64-linux-gnu/7/include/avx512fintrin.h(1761): error: 
identifier "__builtin_ia32_sqrtsd_round" is undefined
/usr/lib/gcc/x86_64-linux-gnu/7/include/avx512fintrin.h(1770): error: 
identifier "__builtin_ia32_sqrtss_round" is undefined


eclipse indicates these errors are being thrown during access to gdal.h 
.  This program compiled and ran without error until last week. I have 
not done anything to the gdal library or updated anything that I am 
aware of. I will move back to linux if I can resolve this issue so any 
suggestions for this would also be welcome.


If I cannot resolve these then I will move away from gdal as a general 
library and write some generic data access tools.


Thanks

Darrel




*From:* Darrel Maddy
*Sent:* 17 March 2020 15:10
*To:* Jerome Siot ; 
'gdal-dev@lists.osgeo.org' 

*Subject:* RE: Building on windows

Dear Jérome

Many thanks for trying to help. Alas it is giving the same errors in the 
Developer Command Prompt window.


Darrel

*From:*Jerome Siot 
*Sent:* 17 March 2020 15:05
*To:* Darrel Maddy ; 
'gdal-dev@lists.osgeo.org' 

*Subject:* RE: Building on windows

Hello,

  * Be sure to launch a terminal by executing : 

C:\Program Files (x86)\Microsoft Visual 
Studio\2019\Enterprise\Common7\Tools\LaunchDevCmd.bat


  * Then , give the VS version in nmake command :

nmake /f makefile.vc MSVC_VER=1900

Hope this helps, Jérome

*De :*gdal-dev <mailto:gdal-dev-boun...@lists.osgeo.org>> *De la part de* Darrel Maddy

*Envoyé :* Sunday, March 15, 2020 1:08 PM
*À :* 'gdal-dev@lists.osgeo.org' <mailto:gdal-dev@lists.osgeo.org>>

*Objet :* [gdal-dev] Building on windows

I have recently switched back to windows for a specific project that 
uses the gdal library.  I am getting the following error on compilation 
of the VS project


NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual 
Studio\2019\Enterprise\VC\Tools\MSVC\14.22.27905\bin\HostX86\x64\cl.EXE"' : 
return code '0x2'


The cl.exe file is present in the directory (there are a number of 
similar messages that follow)  and I am unsure how to proceed. Any 
suggestions?


Thanks

Darrel






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

Re: [gdal-dev] Infinite loop Netcdf/HDF5 -geoloc when warping (version 2.4.4)

2020-03-12 Thread Jeff McKenna

On 2020-03-12 3:16 p.m., Even Rouault wrote:

Jeff,


I have also tested one of your files on Windows here, with MS4W 4.0.3
(GDAL 2.4.4, NetCDF 4.7.3, HDF5 1.10.5), and it also gives me errors:


They look unrelated to Menno's error.


Warning 1: NetCDF driver detected file type=5, but libnetcdf detected type=3


That one is likely related to MS4W nmake.opt lacking NETCDF_HAS_NC4 = yes




Thanks Even, confirmed, will fix this for next release.

-jeff





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

Re: [gdal-dev] Infinite loop Netcdf/HDF5 -geoloc when warping (version 2.4.4)

2020-03-12 Thread Jeff McKenna

Hi Menno,

I have also tested one of your files on Windows here, with MS4W 4.0.3 
(GDAL 2.4.4, NetCDF 4.7.3, HDF5 1.10.5), and it also gives me errors:


gdalinfo


gdalinfo --format netcdf

GDAL_HAS_HDF4=YES
GDAL_HAS_HDF5=YES
NETCDF_CONVENTIONS=CF-1.5
NETCDF_HAS_NC2=YES
NETCDF_VERSION=4.7.3 of Jan 23 2020 15:16:48 $

gdalwarp
---

gdalwarp -geoloc -r cubic -t_srs "+proj=merc +a=6378137 +b=6378137 
+lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null 
+wktext  +no_defs" 
NETCDF:"SEVIR_OPER_R___MSGCPP__L2__20200305T00_20200305T001500_0001.nc":precip 
"output.tiff"


output
--

Warning 1: NetCDF driver detected file type=5, but libnetcdf detected type=3
ERROR 5: OSRCalcInvFlattening(): Wrong input values
Warning 1: NetCDF driver detected file type=5, but libnetcdf detected type=3
ERROR 5: OSRCalcInvFlattening(): Wrong input values
Warning 1: NetCDF driver detected file type=5, but libnetcdf detected type=3
ERROR 5: OSRCalcInvFlattening(): Wrong input values
Creating output file that is 2790P x 4447L.
Processing 
NETCDF:SEVIR_OPER_R___MSGCPP__L2__20200305T00_20200305T001500_0001.nc:precip 
[1/1] : 0Using internal nodata values (e.g. -1) for image 
NETCDF:SEVIR_OPER_R___MSGCPP__L2__20200305T00_20200305T001500_0001.nc:precip.
Copying nodata values from source 
NETCDF:SEVIR_OPER_R___MSGCPP__L2__20200305T00_20200305T001500_0001.nc:precip 
to destination output.tiff.

...10...20...30...40...50...60...70...80...90...100 - done.


thoughts


MS4W does include C Sharp GDAL bindings but I did not test them with 
your data.



-jeff



--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeomatics.com/




On 2020-03-12 9:44 a.m., Menno van Scheers - HUSS wrote:

Dear list,

While in the process of upgrading from 2.2.4 to 2.4.4 we encountered an 
issue with a specific NETCDF file which can no longer be warped.

Sample files can be found at : ftp://msgcpp-ogc-realtime.knmi.nl/

The file is a multiband dataset from which we want to extract the 
*precip* data, it contains 2 bands for georeferencing Lat/Lon.
So in 2.2.4 we used the -geoloc warp parameter to correctly warp it to a 
Webmercator or Mercator projection, this was done with the c-sharp swig 
bindings.


With 2.4.4 the program just halts and does not continue, the same can be 
reproduced with the commandline gdalwarp tool :
gdalwarp -geoloc -r cubic -t_srs "+proj=merc +a=6378137 +b=6378137 
+lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null 
+wktext  +no_defs" NETCDF:"samplefile ":precip "output.tiff"


When interrupting this process  HDF5 gives an error :

HDF5: infinite loop closing library

   
D,T,FD,P,FD,P,FD,P,E,E,SL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL,FL


Unsure if this is the actual problem or a result of the interrupt.

Best Regards,

Menno Van Scheers








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

Re: [gdal-dev] Convert TIF to BIL

2020-03-09 Thread Jeff McKenna

Hi Bret, what is the exact error message?

-jeff


--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeomatics.com/




On 2020-03-06 8:19 p.m., Bret Johnson wrote:

Even:

Thanks.  That worked to create a World file, so I made it past the error 
message.  It's still not importing correctly and the error message is so 
generic that it's useless (basically just says it doesn't like the data).  I'll 
do some more playing.

-Original Message-
From: Even Rouault 
Sent: Friday, March 6, 2020 1:15 PM
To: gdal-dev@lists.osgeo.org
Cc: Bret Johnson 
Subject: Re: [gdal-dev] Convert TIF to BIL

Bret,


I have some GeoTIFF (.TIF) files that a program I'm using won't
accept.  It will accept .BIL files and I'm using GDAL to try and do the 
conversion.
When I do, GDAL_TRANSLATE says it worked and it generates a few files
(including a .BIL), but it doesn't create the .BLW file where all of
the "real" data should be.  Is there some special GDAL_TRANSLATE
option or use or some special format GeoTIFF data needs to be in for
it to work properly and generate a .BLW file?


I don't know which output driver you use (EHdr, ENVI etc.), but they aren't 
likely to produce a .blw worldfile as they will generate a text header file 
specific to the format.

To generate a .blw file you can do:

gdal_translate your_input.tif tmp.tif -co TFW=YES

This will generate a tmp.tfw file. Just rename it to .blw and with the basename 
of your BIL output file.

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 mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] How do I install GDAL on Windows 10?

2020-02-25 Thread Jeff McKenna
If you are looking for a simple zipfile, you can download MS4W 
(https://ms4w.com/) which contains GDAL 2.4.4 and Python 3.7.5 - 
GeoPandas hasn't been added yet to MS4W, but there is already a ticket 
filed so it will be added to a future version soon.


Some steps for you:
- extract MS4W to drive root, so after extraction you have C:/ms4w
- open a command window and cd into /ms4w
- setenv.bat
- gdalinfo --version

You can then get more assistance from the MS4W community at 
https://ms4w.com/forum/



-jeff



--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeomatics.com/


On 2020-02-25 1:59 a.m., /dev /local/ca wrote:

I want to install and use GDAL on Windows 10.

I don't know what 'conda' is, I don't care what it is, and I don't want 
to install it and screw up my machine.


Ultimately I want to install 'geopandas', but it has a requirement of 
'fiona', and 'fiona' requires 'GDAL' so I need to figure that out first,


---
then I need to figure out how to install 'Rtree' which has a dependency 
of 'spatialindex', so after this will figure out how to install 
'spatialindex', then figure out how to install 'Rtree', then try again 
and see if 'fiona' will install and then after that try 'geopandas' again,


but for now, the first step I see is 'GDAL'.





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

Re: [gdal-dev] Refreshing GDAL's logo

2020-02-10 Thread Jeff McKenna

On 2020-02-10 4:56 a.m., Even Rouault wrote:

So looking at https://github.com/OSGeo/gdal/issues/2117, it seems we didn't
get more proposals than the ones from 2 weeks ago. There are 3 proposals in
the initial post of the ticket: nirvn_v1, nirvn_v2 and nirvn_v3
In https://github.com/OSGeo/gdal/issues/2117#issuecomment-570059241 , there's
also a variant of nirvn_v3 with the compas/satellite replacing the A.



Hi Even,

I prefer nirvn_v3 (with the solar panels, which reference the original 
GDAL logo).  I am not a fan of the A in "GDAL" being replaced by that 
symbol.


-jeff


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

Re: [gdal-dev] Motions: approve GDAL 3.0.3 RC1 and 2.4.4 RC1

2020-01-08 Thread Jeff McKenna

Tested 2.4.4 RC1 here with VisualStudio 2017, works well.

+1  jeff




On 2020-01-08 9:07 AM, Even Rouault wrote:

Hi,

Both announcement of availability of release candidates and motions to adopt
them.

MOT1: Adopt GDAL 3.0.3 RC1 as final 3.0.3 release

+1 Even

MOT2: Adopt GDAL 2.4.4 RC1 as final 2.4.4 release

+1 Even

~

3.0.3 RC1:

Peek up an archive among the following ones (by ascending size):
   http://download.osgeo.org/gdal/3.0.3/gdal-3.0.3rc1.tar.xz
   http://download.osgeo.org/gdal/3.0.3/gdal-3.0.3rc1.tar.gz
   http://download.osgeo.org/gdal/3.0.3/gdal303rc1.zip

A snapshot of the gdalautotest suite is also available :

   http://download.osgeo.org/gdal/3.0.3/gdalautotest-3.0.3rc1.tar.gz
   http://download.osgeo.org/gdal/3.0.3/gdalautotest-3.0.3rc1.zip

GDAL-GRASS plugin (unmodified):

   http://download.osgeo.org/gdal/3.0.3/gdal-grass-3.0.3.tar.gz

The NEWS file is here :

   https://github.com/OSGeo/gdal/blob/v3.0.3RC1/gdal/NEWS

~

2.4.4 RC1:

Peek up an archive among the following ones (by ascending size):

   http://download.osgeo.org/gdal/2.4.4/gdal-2.4.4rc1.tar.xz
   http://download.osgeo.org/gdal/2.4.4/gdal-2.4.4rc1.tar.gz
   http://download.osgeo.org/gdal/2.4.4/gdal244rc1.zip

A snapshot of the gdalautotest suite is also available :

   http://download.osgeo.org/gdal/2.4.4/gdalautotest-2.4.4rc1.tar.gz
   http://download.osgeo.org/gdal/2.4.4/gdalautotest-2.4.4rc1.zip

GDAL-GRASS plugin (unmodified):

   http://download.osgeo.org/gdal/2.4.4/gdal-grass-2.4.4.tar.gz

The NEWS file is here :

   https://github.com/OSGeo/gdal/blob/v2.4.4RC1/gdal/NEWS





--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeomatics.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Slow GDALComputeRasterMinMax on nc grids

2020-01-03 Thread Jeff McKenna

On 2020-01-03 3:52 PM, Even Rouault wrote:


Do you build netCDF with a custom value of the CHUNK_CACHE_SIZE / chunk-cache-
size setting ?

With the default (4 MB), runtime on my machine is about 7 minutes. But if I
use --with-chunk-cache-size=67108864 as in
https://trac.osgeo.org/gdal/ticket/5291#comment:26 , then it goes down to
9 sec.

So this is a quite old known issue with the netCDF driver with HDF5 chunking &
compression. Due to the netCDF driver exposing rasters with a north origin,
and netCDF Y origin being at south, there's a mismatch between GDAL blocks and
netCDF chunks. So for the sake of simplicity, the netCDF driver exposes one
single line as the GDAL block size. It could/should be improved to make a
better use of netCDF chunks, so as not being too much dependent of the quite
pessimistic default of the netCDF chunk_cache_size.



Hi Even,

No I don't set CHUNK_CACHE_SIZE during compile at all.  I do however set 
USE_HDF5=OFF


(I believe I set that because of that same chunking issue which we 
discussed here before)


-jeff





--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeomatics.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Slow GDALComputeRasterMinMax on nc grids

2020-01-03 Thread Jeff McKenna

Hi Joaquim,

I have tested your file on Windows 10 here, with the command:

   gdalinfo grav_29_img.nc -mm

which takes about 5 seconds to execute fully.  I am using MS4W 4.0.2 
(GDAL 2.4.3 , NetCDF 4.7.3 )


I haven't tested using your wrappers though, so imagine that my feedback 
is not very useful.


PS. but thanks for sharing the larger grid file, which is useful for 
testing.


Wishing you a prosperous 2020.

-jeff



--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeomatics.com/



On 2020-01-03 1:27 PM, Joaquim Manuel Freire Luís wrote:

Hi Even,

New Year, new mysteries. I’m having quite strange slow times in 
computing the min/max of netCDF files.


In GMT we can read files via GDAL by appending =gd to the file name. So 
both of these do a similar job


grdinfo grav_29_img.nc=gd

and

gdalinfo grav_29_img.nc -mm

and it takes around 28 sec in a new laptop running Windows and master 
GDAL. However in WSL, same laptop but GDAL 2.2.3, they take about 5:30 
MINUTES to run. On a OSX it takes about 3:30 minutes (not me who run 
this, and a GDAL 3.0.3 MacPorts)


On Windows for files of similar size it run faster when data is of type 
float (the grid in this example is a short int).


Now, perhaps the weirdest thing is that if I run the GMT command via our 
Julia wrapper it only takes ~8 sec, whilst the same command via the 
Matlab wrapper took 1:18 min


The ~8 sec time is close to what I get with a pure GMT (i.e. not using 
GDAL to read the nc file  (grdinfo grav_29_img.nc -M))


 From the GMT side all happens in the call

     GDALComputeRasterMinMax(hBand, false, adfMinMax);

And I guess that the same holds from the pure GDAL call.

If you want to test with the grid used in these testings, it’s here

ftp://ftp.soest.hawaii.edu 
<ftp://ftp.soest.hawaii.edu.pwessel>/pwessel/grav_29_img.nc 
<http://grav_29_img.nc>


Happy new year

Joaquim



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

Re: [gdal-dev] .kml to .xlsx or .xls ( with Geometry Column Included)

2019-11-27 Thread Jeff McKenna
Another option is to convert from KML to CSV, which can be opened by 
LibreOffice/Word etc. using the "GEOMETRY=AS_XY" switch, which generates 
your X and Y columns magically:


  ogr2ogr -f CSV -lco GEOMETRY=AS_XY output.csv input.kml


-jeff



--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeomatics.com/


On 2019-11-27 8:45 AM, Wuyyuru Ravi Teja Krishna wrote:

Hello GDAL team,

          We are trying to use ogr2ogr util for conversion of .kml to 
.xlsx. But the converted .xlsx file is missing geometry column. In 
documentation it says of using ogr vrt capabilities for this purpose but 
its not clear on procedure need to be followed. Can someone please 
direct us with solution to our problem?


Thanks in advance





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

Re: [gdal-dev] Export a geotiff to netcdf in lat lon coordinates

2019-11-25 Thread Jeff McKenna

Hi Tony,

Also, if I execute 'ncdump -k N_197901_concentration_v3.0_4326.nc' the 
response is "classic".  (apparently the -k switch shows the 'kind' of 
netCDF file)


Hope that also helps,

-jeff



--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeomatics.com/



On 2019-11-25 4:11 PM, Tony L. wrote:

Hello Jeff!
Thank you so much for your help!!
I tried to follow your steps and works well for the transformation from 
tif to netcdf. I can use ncdump to check info on the file and I can plot 
it normally.


Now, when I reproject the file to lat/lon coord using your command:

gdalwarp -s_srs EPSG:3411 -t_srs EPSG:4326 
N_197901_concentration_v3.0.nc N_197901_concentration_v3.0_4326.nc


and when I try to get info on the file using ncdump -h I get:
ncdump: N_197901_concentration_v3.0_4326.nc: NetCDF: Unknown file format

Any idea as to why that would happen?

Tony

On Friday, November 22, 2019, 01:19:50 PM EST, Jeff McKenna 
 wrote:



Hi Tony,

Here are my steps.

Have a nice weekend.


***

#use gdalinfo to get summary (see https://gdal.org/programs/gdalinfo.html)
gdalinfo -noct N_197901_concentration_v3.0.tif

#review source EPSG projection (found from gdalinfo command above)
in web browser goto: http://epsg.io/3411

#review desired output projection (lat/long)
in web browser goto: http://epsg.io/4326

#transform to NetCDF
gdal_translate -f netCDF N_197901_concentration_v3.0.tif
N_197901_concentration_v3.0.nc

#reproject to lat/long, which is EPSG:4326
(https://gdal.org/programs/gdalwarp.html)
gdalwarp -s_srs EPSG:3411 -t_srs EPSG:4326
N_197901_concentration_v3.0.nc N_197901_concentration_v3.0_4326.nc

#examine reprojected file (verify "corner coordinates" look proper)
gdalinfo -noct N_197901_concentration_v3.0_4326.nc

   * for all commands I used MS4W 4.0.1, on Windows, from https://ms4w.com

**


--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeomatics.com/



On 2019-11-22 1:24 PM, Tony L. wrote:
 > Hello
 > I'm quite new with gdal and would like to use is to rewrite a geotiff of
 > NSIDC sea ice concentration from geotiff in polar stereographic
 > projection into a netcdf in Lon Lat coordinates
 >
 > The file is located here: N_197901_concentration_v3.0.tif
 > 
<https://www.dropbox.com/s/bkqt6qgyhpr7vjk/N_197901_concentration_v3.0.tif?dl=0>

 >
 >
 >
 >
 >
 >
 >    N_197901_concentration_v3.0.tif
 >
 > Shared with Dropbox
 >
 > 
<https://www.dropbox.com/s/bkqt6qgyhpr7vjk/N_197901_concentration_v3.0.tif?dl=0>


 >
 > I was able to transform the file into a netcdf file using gdal_translate:
 >
 > gdal_translate -of netCDF N_197901_concentration_v3.0.tif out.nc
 >
 > But I'm still trying to figure out how to translate this into Lon Lat
 > coordinates (probably using gdalwarp)
 >
 > Any help would be really appreciated!
 >
 > Tony

 >


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

Re: [gdal-dev] Export a geotiff to netcdf in lat lon coordinates

2019-11-25 Thread Jeff McKenna

Hi Tony,

When I execute 'ncdump -h' locally on your generated file I get a proper 
response (see https://pastebin.com/Ki4BTTNS).  Note that MS4W is 
currently built against netCDF-4.7.0 (maybe you have an older netCDF 
library version?)


PS. I'll shortly be upgrading netCDF support to the recent 4.7.3 release 
for Windows users (follow along if you wish at 
https://ms4w.com/trac/ticket/238)


Hope that helps.

-jeff



--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeomatics.com/


On 2019-11-25 4:11 PM, Tony L. wrote:

Hello Jeff!
Thank you so much for your help!!
I tried to follow your steps and works well for the transformation from 
tif to netcdf. I can use ncdump to check info on the file and I can plot 
it normally.


Now, when I reproject the file to lat/lon coord using your command:

gdalwarp -s_srs EPSG:3411 -t_srs EPSG:4326 
N_197901_concentration_v3.0.nc N_197901_concentration_v3.0_4326.nc


and when I try to get info on the file using ncdump -h I get:
ncdump: N_197901_concentration_v3.0_4326.nc: NetCDF: Unknown file format

Any idea as to why that would happen?

Tony

On Friday, November 22, 2019, 01:19:50 PM EST, Jeff McKenna 
 wrote:



Hi Tony,

Here are my steps.

Have a nice weekend.


***

#use gdalinfo to get summary (see https://gdal.org/programs/gdalinfo.html)
gdalinfo -noct N_197901_concentration_v3.0.tif

#review source EPSG projection (found from gdalinfo command above)
in web browser goto: http://epsg.io/3411

#review desired output projection (lat/long)
in web browser goto: http://epsg.io/4326

#transform to NetCDF
gdal_translate -f netCDF N_197901_concentration_v3.0.tif
N_197901_concentration_v3.0.nc

#reproject to lat/long, which is EPSG:4326
(https://gdal.org/programs/gdalwarp.html)
gdalwarp -s_srs EPSG:3411 -t_srs EPSG:4326
N_197901_concentration_v3.0.nc N_197901_concentration_v3.0_4326.nc

#examine reprojected file (verify "corner coordinates" look proper)
gdalinfo -noct N_197901_concentration_v3.0_4326.nc

   * for all commands I used MS4W 4.0.1, on Windows, from https://ms4w.com

**


--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeomatics.com/



On 2019-11-22 1:24 PM, Tony L. wrote:
 > Hello
 > I'm quite new with gdal and would like to use is to rewrite a geotiff of
 > NSIDC sea ice concentration from geotiff in polar stereographic
 > projection into a netcdf in Lon Lat coordinates
 >
 > The file is located here: N_197901_concentration_v3.0.tif
 > 
<https://www.dropbox.com/s/bkqt6qgyhpr7vjk/N_197901_concentration_v3.0.tif?dl=0>

 >
 >
 >
 >
 >
 >
 >    N_197901_concentration_v3.0.tif
 >
 > Shared with Dropbox
 >
 > 
<https://www.dropbox.com/s/bkqt6qgyhpr7vjk/N_197901_concentration_v3.0.tif?dl=0>


 >
 > I was able to transform the file into a netcdf file using gdal_translate:
 >
 > gdal_translate -of netCDF N_197901_concentration_v3.0.tif out.nc
 >
 > But I'm still trying to figure out how to translate this into Lon Lat
 > coordinates (probably using gdalwarp)
 >
 > Any help would be really appreciated!
 >
 > Tony

 >


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

Re: [gdal-dev] Export a geotiff to netcdf in lat lon coordinates

2019-11-22 Thread Jeff McKenna

Hi Tony,

Here are my steps.

Have a nice weekend.


***

#use gdalinfo to get summary (see https://gdal.org/programs/gdalinfo.html)
gdalinfo -noct N_197901_concentration_v3.0.tif

#review source EPSG projection (found from gdalinfo command above)
in web browser goto: http://epsg.io/3411

#review desired output projection (lat/long)
in web browser goto: http://epsg.io/4326

#transform to NetCDF
gdal_translate -f netCDF N_197901_concentration_v3.0.tif 
N_197901_concentration_v3.0.nc


#reproject to lat/long, which is EPSG:4326 
(https://gdal.org/programs/gdalwarp.html)
gdalwarp -s_srs EPSG:3411 -t_srs EPSG:4326 
N_197901_concentration_v3.0.nc N_197901_concentration_v3.0_4326.nc


#examine reprojected file (verify "corner coordinates" look proper)
gdalinfo -noct N_197901_concentration_v3.0_4326.nc

  * for all commands I used MS4W 4.0.1, on Windows, from https://ms4w.com

**


--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeomatics.com/



On 2019-11-22 1:24 PM, Tony L. wrote:

Hello
I'm quite new with gdal and would like to use is to rewrite a geotiff of 
NSIDC sea ice concentration from geotiff in polar stereographic 
projection into a netcdf in Lon Lat coordinates


The file is located here: N_197901_concentration_v3.0.tif 
<https://www.dropbox.com/s/bkqt6qgyhpr7vjk/N_197901_concentration_v3.0.tif?dl=0>







N_197901_concentration_v3.0.tif

Shared with Dropbox

<https://www.dropbox.com/s/bkqt6qgyhpr7vjk/N_197901_concentration_v3.0.tif?dl=0>

I was able to transform the file into a netcdf file using gdal_translate:

gdal_translate -of netCDF N_197901_concentration_v3.0.tif out.nc

But I'm still trying to figure out how to translate this into Lon Lat 
coordinates (probably using gdalwarp)


Any help would be really appreciated!

Tony


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

Re: [gdal-dev] Motion: approve GDAL 2.4.3RC1 and 3.0.2RC1 as final

2019-11-01 Thread Jeff McKenna

+1


-jeff



On 2019-10-31 8:08 AM, Even Rouault wrote:

Hi,

A few issues [1] have been fixed since in those branches since the RCs, but
they predated 2.4.0, so those new releases are not worse than their previous
x.y.0, so I move to

Motion: approve GDAL 2.4.3RC1 and 3.0.2RC1 as final



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

Re: [gdal-dev] Documenting build requirements (e.g. ODBC)

2019-10-20 Thread Jeff McKenna

On lundi 30 septembre 2019 11:21:16 CEST Mateusz Loskot wrote:

Hi,

I'm a bit lost where build requirements are supposed
to be documented now. They used to be described
on the Wiki, e.g. https://trac.osgeo.org/gdal/wiki/BuildingOnUnix
or driver-specific ones https://trac.osgeo.org/gdal/wiki/ECW




(late response, sorry)

The wiki worked really well for that, and over the years we compiled 
quite a list of build steps for drivers and platforms 
(https://trac.osgeo.org/gdal/wiki/BuildHints).  I'd suggest we continue 
to use the wiki method (meaning now we transition to the Github wiki), 
so we don't have any funnels where someone needs to approve or 
disapprove of a change to the official website or repository.


The argument sometimes used against a wiki is that it is not managed, 
but this is exactly why the Buildhints wiki was allowed to thrive.


There of course will still be one hurdle, requiring to have a Github 
account, but besides that the wiki should thrive there for years to come.


-jeff

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

Re: [gdal-dev] Motion: spend 60 USD / year for extended GitHub LFS

2019-10-10 Thread Jeff McKenna

+1 jeff



On 2019-10-08 7:49 AM, Even Rouault wrote:

Hi,

This motion is to spend 5 USD/month * 12 = 60 USD annually to buy one "data
pack" ([1]) to extend the quota of the OSGeo GitHub organization for LFS
(Large File Storage) from
1 GB of storage + 1 GB /month of bandwith
to
50 GB of storage + 50 GB/month of bandwidth

This is within our yearly 5000 USD budget, for which we have already spent
4107.60 USD for Travis-CI

The first & main beneficiary of this GitHub LFS extension will actually be the
proj-datumgrid repository, that has just reached the bandwidth quota:
https://github.com/OSGeo/proj-datumgrid/issues/57

~~

My vote: +1

Even

[1]
https://help.github.com/en/articles/about-billing-for-git-large-file-storage


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

Re: [gdal-dev] Motions: promote GDAL 2.4.2 RC1 and GDAL 3.0.1 RC1 to final

2019-07-03 Thread Jeff McKenna

On 2019-07-03 6:15 AM, Even Rouault wrote:

Hi,

Motion 1: promote GDAL 2.4.2 RC1 to final
Motion 2: promote GDAL 3.0.1 RC1 to final




Motion 1: +1
Motion 2: +1


-jeff



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

Re: [gdal-dev] Connecting to MSSQL from linux using OGR?

2019-07-02 Thread Jeff McKenna
Years ago I used FreeTDS library, but today the recommended way to 
connect is through the Microsoft ODBC library 
(https://docs.microsoft.com/en-us/sql/connect/odbc/linux-mac/installing-the-microsoft-odbc-driver-for-sql-server?view=sql-server-20170). 
 There was a recent discussion here on your same topic 
http://osgeo-org.1560.x6.nabble.com/gdal-dev-connect-mssql-from-linux-td5363547.html


-jeff



--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeomatics.com/



On 2019-07-01 10:54 PM, Wardrop wrote:

Hi All,

I'm trying to connect a MSSQL database using ogrinfo and ogr2ogr, but am not
having any success. Most of the examples I see online assume you're
connecting from a Windows. I'm trying to connect from OpenSUSE. Here's what
I've been trying:

ogrinfo
"MSSQL:server=sql12.msc.local\MSSQLSERVER;database=GIS;UID=sa;PWD=;"

That results in:

FAILURE:
Unable to open datasource
`MSSQL:server=sql12.msc.local\MSSQLSERVER;database=GIS;UID=sa;PWD=;'
with the following drivers.
   -> JP2ECW
   -> OCI
   -> SOSI
   -> ...

I've tried specifying various "drivers" by appending for example
";driver=FreeTDS". The error is always the same, and returns instantly. It's
like the connection string isn't even making it to the MSSQLSpatial OGR
driver. Is this even meant to work on linux? I'm at a complete loss.



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

Re: [gdal-dev] GDAL 2.4.2 RC1 available

2019-06-28 Thread Jeff McKenna

Hi Even,

No problem here on Windows with VisualStudio 2017.

(and thanks for this 2.4.2 release)

-jeff



On 2019-06-28 9:03 AM, Even Rouault wrote:

Hi,

I have prepared a GDAL/OGR 2.4.2 release candidate.

Peek up an archive among the following ones (by ascending size):

   http://download.osgeo.org/gdal/2.4.2/gdal-2.4.2rc1.tar.xz
   http://download.osgeo.org/gdal/2.4.2/gdal-2.4.2rc1.tar.gz
   http://download.osgeo.org/gdal/2.4.2/gdal242rc1.zip

A snapshot of the gdalautotest suite is also available :

   http://download.osgeo.org/gdal/2.4.2/gdalautotest-2.4.2rc1.tar.gz
   http://download.osgeo.org/gdal/2.4.2/gdalautotest-2.4.2rc1.zip

GDAL-GRASS plugin (unmodified):

 http://download.osgeo.org/gdal/2.4.2/gdal-grass-2.4.2.tar.gz

The NEWS file is here :

   http://trac.osgeo.org/gdal/wiki/Release/2.4.2-News

I'll call for a vote promoting it to final in the middle of next week if no
serious problems are reported before.

Best regards,

Even





--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeomatics.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] vsicurl access to a netcdf file does not see the coordinates

2019-06-02 Thread Jeff McKenna

On 2019-06-02 9:35 AM, Andrew C Aitchison wrote:

On Sun, 2 Jun 2019, Jeff McKenna wrote:


On 2019-06-01 6:52 PM, Joaquim Manuel Freire Lu?s wrote:
Is there a way to force reading the grid locally with the HDF5 driver 
instead of the automatically picked netCDF driver?

___


I come across this need often also, as many MS4W users leverage GDAL 
through netCDF, HDF5, HDF4, but I'm not aware of a GDAL commandline 
option to 'skip' raster drivers (OGR has "OGR_SKIP").  I could be 
wrong though.  I have seen other users request this 
(https://trac.osgeo.org/gdal/ticket/5917) which seems to say that 
there is a way through the GDAL API, but, I'm just not sure about the 
commandline.


Rather like OGR_SKIP, the GDAL_SKIP environment variable skips raster 
drivers (tested with gdal 1.11 and 3.0.)




ah yes, you're right, of course it exists. Thanks. 
https://trac.osgeo.org/gdal/wiki/ConfigOptions#GDAL_SKIP


-jeff


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

Re: [gdal-dev] vsicurl access to a netcdf file does not see the coordinates

2019-06-02 Thread Jeff McKenna

On 2019-06-01 6:52 PM, Joaquim Manuel Freire Luís wrote:

|>Ah, there is no chance that /vsicurl/ with netcdf will work on Windows. It 
also
|>requires the "user-fault file descriptor" Linux specific mechanism.

It actually almost works. This command should be equal to just download the file

grdconvert /vsicurl/http://w3.ualg.pt/~jluis/ftp/tmp/idades_v2012.grd -Glixo.grd

and I get the file. Only the coordinates are wrong but for the rest, the grid 
is fine.

Is there a way to force reading the grid locally with the HDF5 driver instead 
of the automatically picked netCDF driver?
___


I come across this need often also, as many MS4W users leverage GDAL 
through netCDF, HDF5, HDF4, but I'm not aware of a GDAL commandline 
option to 'skip' raster drivers (OGR has "OGR_SKIP").  I could be wrong 
though.  I have seen other users request this 
(https://trac.osgeo.org/gdal/ticket/5917) which seems to say that there 
is a way through the GDAL API, but, I'm just not sure about the commandline.


-jeff


--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeomatics.com/




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

Re: [gdal-dev] error in gdal.org certificate

2019-05-24 Thread Jeff McKenna

On 2019-05-24 1:56 PM, Duarte Carreira wrote:
Maybe this is known, but www.gdal.org <http://www.gdal.org> is giving me 
a ERR_CERT_COMMON_NAME_INVALID error on chrome/win.




https://github.com/OSGeo/gdal/issues/1574

-jeff


--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeomatics.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Migration of RFCs to Sphinx ?

2019-05-24 Thread Jeff McKenna

Hi Even,

I agree with emptying the old wiki page and placing a link there, to the 
new site.  Soon we should also disabling editing on that trac instance 
as well (as we discussed here before).


-jeff



On 2019-05-23 7:05 PM, Even Rouault wrote:

Hi,

Other projects like MapServer or PROJ have their RFCs as part of their Sphinx
documentation, so I've prepared the migration of GDAL RFCs as well (*) in
https://github.com/OSGeo/gdal/pull/1567

Questions:
- OK with that ?
- if so, what should we do with https://trac.osgeo.org/gdal/wiki/RfcList. My
thinking would be to empty the content of this page and just put a link into
it to the equivalent https://gdal.org/development/rfc/index.html , and leave
the individual existing rfc documents without any pointer to them.

Even

(*) using the convert() method of
https://github.com/moimael/trac-to-gitlab/blob/master/trac2down/Trac2Down.py
to convert from Trac wiki to github markdown and then pandoc to convert to
ReST + some manual tweaking




--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeomatics.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: adopt RFC 74: Migrate gdal.org to Sphinx

2019-05-21 Thread Jeff McKenna

+1 jeff



On 2019-05-20 6:54 PM, Even Rouault wrote:

Hi,

I believe we are now in a state where the prototype new website is functional
and should have content at least equivalent to the current one, so I motion to
adopt RFC74: Migrate gdal.org to Sphinx:

https://trac.osgeo.org/gdal/wiki/rfc74_sphinx


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

Re: [gdal-dev] Motion: Add Norman Barker to GDAL PSC

2019-05-15 Thread Jeff McKenna

+1 jeff





On 2019-05-15 11:03 AM, Even Rouault wrote:

Hi,

I propose to add Norman Barker to the GDAL project steering committee.

Norman has been active as a contributor to the GDAL project since more than 10
years and has contributed to various areas of the project, in particular the
JPIPKAK driver and the progressive rendering API, the OGR Cloudand driver, the
WEBP codec for GeoTIFF, and recently the TileDB driver. I believe he would be
a good asset for the project.

Motion: To add Norman Barker to the GDAL PSC.

+1 from me.

Even


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

Re: [gdal-dev] Motion: Promote GDAL 3.0.0 rc2 for release

2019-05-07 Thread Jeff McKenna

+1 jeff




On 2019-05-07 6:19 AM, Even Rouault wrote:

Hi,

Motion: GDAL/OGR 3.0.0 rc2 is promoted to be the official 3.0.0 final release.


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

Re: [gdal-dev] Fwd: ogr2ogr

2019-05-02 Thread Jeff McKenna

Hi Mncedi,

Welcome to GDAL !

Here is how I recommend working through that (using a working example) :

Step 1:  ogrinfo


Always always start with an ogrinfo command, to see the available layer 
names:


ogrinfo WFS:https://demo.gatewaygeomatics.com/cgi-bin/wfs_gateway


returns:

using driver `WFS' successful.
1: ms:park

Great! We now know the layer name is called "ms:park"

Step 2: ogrinfo + layername
---

Next, see if ogrinfo can return info about that ms:park layer:

	ogrinfo WFS:https://demo.gatewaygeomatics.com/cgi-bin/wfs_gateway 
ms:park -summary


returns:

using driver `WFS' successful.
Layer name: ms:park
Metadata:
TITLE=Parks
Geometry: Unknown (any)
Feature Count: 46
Extent: (-2346804.00, -67422.421875) - (2840366.00, 
3830124.25)

Layer SRS WKT:
PROJCS["NAD83 / Canada Atlas Lambert"

Great! ogrinfo gave us info about our layer

Step 3: ogr2ogr + layername
---

Notice that the syntax is something like:  ogr2ogr output input layername :

	ogr2ogr -f "ESRI Shapefile" parks.shp 
WFS:https://demo.gatewaygeomatics.com/cgi-bin/wfs_gateway ms:park




Tested using MS4W 4.0 https://ms4w.com

-jeff


--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeomatics.com/

On 2019-05-02 10:11 AM, Mncedi Dlayiya wrote:

Hello everyone,

I am new in GDAL so I'm struggling to convert a wfs to shapefile using 
ogr2ogr.


my command is as follows:

C:\>ogr2ogr -f "ESRI SHAPEFILE" ec_pensioners WFS:" 
http://localhost:8080/geoserver/osw?; pensioners


  * ec_pensioners is the name of the wfs layer
  * pensioners is the output layer
  * " http://localhost:8080/geoserver/osw?; is where the layer is hosted 



The error message I get:

FAILURE:
Unable to open datasource `WFS: http://localhost:8080/geoserver/osw?' 
with the following drivers.

   -> `JP2ECW'
   -> `OCI'
   -> `SOSI'
   -> `PCIDSK'
   -> `netCDF'
   -> `JP2OpenJPEG'
   -> `PDF'
   -> `MBTiles'
   -> `EEDA'
   -> `DB2ODBC'
   -> `ESRI Shapefile'
   -> `MapInfo File'
   -> `UK .NTF'
   -> `OGR_SDTS'
   -> `S57'
   -> `DGN'
   -> `OGR_VRT'
   -> `REC'
   -> `Memory'
   -> `BNA'
   -> `CSV'
   -> `NAS'
   -> `GML'
   -> `GPX'
   -> `LIBKML'
   -> `KML'
   -> `GeoJSON'
   -> `GeoJSONSeq'
   -> `ESRIJSON'
   -> `TopoJSON'
   -> `Interlis 1'
   -> `Interlis 2'
   -> `OGR_GMT'
   -> `GPKG'
   -> `SQLite'
   -> `ODBC'
   -> `WAsP'
   -> `PGeo'
   -> `MSSQLSpatial'
   -> `OGR_OGDI'
   -> `PostgreSQL'
   -> `MySQL'
   -> `OpenFileGDB'
   -> `XPlane'
   -> `DXF'
   -> `CAD'
   -> `Geoconcept'
   -> `GeoRSS'
   -> `GPSTrackMaker'
   -> `VFK'
   -> `PGDUMP'
   -> `OSM'
   -> `GPSBabel'
   -> `SUA'
   -> `OpenAir'
   -> `OGR_PDS'
   -> `WFS'
   -> `WFS3'
   -> `HTF'
   -> `AeronavFAA'
   -> `Geomedia'
   -> `EDIGEO'
   -> `GFT'
   -> `SVG'
   -> `CouchDB'
   -> `Cloudant'
   -> `Idrisi'
   -> `ARCGEN'
   -> `SEGUKOOA'
   -> `SEGY'
   -> `XLS'
   -> `ODS'
   -> `XLSX'
   -> `ElasticSearch'
   -> `Walk'
   -> `Carto'
   -> `AmigoCloud'
   -> `SXF'
   -> `Selafin'
   -> `JML'
   -> `PLSCENES'
   -> `CSW'
   -> `VDV'
   -> `GMLAS'
   -> `MVT'
   -> `TIGER'
   -> `AVCBin'
   -> `AVCE00'
   -> `NGW'
   -> `HTTP'

Thank you in advance

Mncedi

___
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] Should the next version (previously 2.5) be called GDAL 3.0 ?

2019-05-01 Thread Jeff McKenna

I like 3.0 as well.  -jeff



On 2019-05-01 3:56 PM, Even Rouault wrote:

Hi,


As a feedback from the previous motion, it appears that GDAL 3.0 would

probably better reflect the API & behaviour changes that have been done, 
and


be in accordance with our HOWTO-RELEASE procedure and semantic versionning

rules.


I'm OK with that change.


If we decide for that, the plan would probably be:

- change in docs & other materials the references to 2.5 to 3.0

- create a release/3.0 branch from the HEAD of release/2.5

- abandon release/2.5 branch (that is: backports would be done in 
release/3.0,


and for longer support in release/2.4 when appropriate)

- issue a 3.0.0RC1 from that

- call master 3.1dev


Thoughts ?


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




--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeomatics.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: Promote GDAL 2.5.0 rc1 for release

2019-05-01 Thread Jeff McKenna

On 2019-05-01 11:56 AM, Even Rouault wrote:

Hi,

Motion: GDAL/OGR 2.5.0 rc1 is promoted to be the official 2.5.0 final release.



+1  jeff




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

Re: [gdal-dev] GDAL 2.5.0 release planning

2019-04-10 Thread Jeff McKenna

On 2019-04-10 11:11 AM, Even Rouault wrote:

Hi,

I don't think we've discussed about the 2.5.0 release planning. Here's my
suggestion, assuming all things go fine:
- 19 April: beta1
- 26 April: RC1
- 3 May: RC1 promoted to final

Thoughts ?



To confirm: this will be the first release with no support for PROJ < 6, 
correct?


(I know of the wiki status page, but I am asking here for confirmation)

thanks,

-jeff



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

Re: [gdal-dev] Trac Wiki

2019-03-27 Thread Jeff McKenna

On 2019-03-26 8:58 AM, Even Rouault wrote:


The possible scenarios I see:
1) status quo with Trac wiki
2) migrate all or almost all content from Trac wiki to GitHub wiki, and kill
Trac wiki
3) migrate part of Trac wiki to the future official RST doc, abandon
remaining non relevant info, and have no wiki at all. In the final state, the
whole doc is the RST doc (PROJ current situation)
4) migrate part of Trac wiki to the future official RST doc, migrate remaining
doc to gitub wiki, and kill Trac wiki.

3) or 4) would seem the most preferable outcome to me.



My feedback on the #3 option:   wikis allow anyone to share their steps, 
tips, and prevent the 'funnel' happening where 1 or 2 people must 
approve doc changes, to the more official public site.


I prefer #4, but leave the old wiki pages in place & set them to read-only.

-jeff



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

Re: [gdal-dev] Closing remaining open Trac tickets ?

2019-03-21 Thread Jeff McKenna

+1

But note that the Trac wiki pages are still used (and editable).  I 
remember this situation for MapServer, and for that I spent much effort 
to manually create all of the existing Trac wiki pages, onto Github, by 
hand (and then we made the Trac wiki read-only).  This should be done 
also for GDAL (but maybe now there is a more automated way).


-jeff



On Wed, Mar 20, 2019 at 3:28 PM Even Rouault <mailto:even.roua...@spatialys.com>> wrote:


Hi,

As we have already more than 100 tickets open in github, I guess
nobody no
longer looks at old Trac tickets.
I was wondering if we shouldn't mass close the remaining open
tickets in Trac,
with a message indicating that if the issue is still current, it
should be
filed on github, and assigning those tickets to a dedicated
milestone "closed
due to migration to github"

Thoughts ?

Even

-- 
Spatialys - Geospatial professional services

http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org <mailto: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




--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeomatics.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 2.4.1 RC1 available

2019-03-15 Thread Jeff McKenna

On 2019-03-15 9:52 AM, Even Rouault wrote:


I'll call for a vote promoting it to final in the middle of next week if no
serious problems are reported before.



No issues here on Windows with Visual Studio 2017.

-jeff



--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeomatics.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] libgeotiff 1.5.0 release candidate

2019-03-14 Thread Jeff McKenna

On 2019-03-13 7:49 PM, Even Rouault wrote:


The
natural set of compatible versions (and the one actually tested by continuous
integration) will be more GDAL 2.5.0 + libgeotiff 1.5.0 + PROJ 6.0



Thank you for explaining the compatible versions.  (and the many great 
changes)  -jeff



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

Re: [gdal-dev] PHP_OGR

2019-02-26 Thread Jeff McKenna

Hi Edward,

For many years (decade?) I distributed the PHP/OGR extension for Windows 
users, in MS4W.  Since the extension was unmaintained I had removed it, 
but, hearing that you have revived it, I will re-add it back into MS4W 
(version 4, which includes PHP 7.2.x).  If you wish to follow along with 
this, here is the ticket that I will use to track adding it: 
https://ms4w.com/trac/ticket/190  I imagine I may have some 'fun' trying 
to adapt the old makefile.vc for PHP7 ;)


Thanks!

-jeff



On 2019-02-26 1:14 PM, Nash, Edward wrote:

Hi devs,

If there’s anyone out there using or supporting PHP then you may be 
interested that I recently pushed an update to PHP_OGR (yes, forked from 
the original from DM Solutions exhumed from CVS!) to GitHub [1] which 
adds support for PHP7, a bunch of functions for coordinate systems (OSR 
API) and some reworked and extended PHPUnit tests.


It’s not necessarily pretty or modern, and doesn’t cover everything in 
the current API, but it is still very functional and allows access to at 
least some of the main OGR functions directly from PHP.


If there’s anyone out there who would like to take it for a spin on 
different systems (tested so far only on Debian Jessie and Stretch), 
then I’d be very happy to accept any resulting pull requests.


Cheers,

Edward

[1] https://github.com/dvzgeo/php_ogr

--

Edward Nash

Sachgebiet Geoinformation

E-Mail e.n...@dvz-mv.de <mailto:e.n...@dvz-mv.de>

Telefon: +49 385 4800 527

Telefax: +49 385 4800 98 527

Mobilfunk: +49 170 454 7434

Internet: www.dvz-mv.de <http://www.dvz-mv.de/>

_

DVZ Datenverarbeitungszentrum

Mecklenburg-Vorpommern GmbH

Lübecker Str. 283 - 19059 Schwerin

Sitz der Gesellschaft: Schwerin | Eintrag im Handelsregister: HRB 187/ 
Amtsgericht Schwerin


Geschäftsführer:  Hubert Ludwig | Aufsichtsratsvorsitzender: 
Staatssekretärin Ina-Maria Ulbrich


_

Allgemeine Datenschutzinformation: Der telefonische, schriftliche oder 
elektronische Kontakt ist ggf. mit der Speicherung und Verarbeitung der 
von Ihnen mitgeteilten persönlichen Daten verbunden. Sollte die DVZ M-V 
GmbH Daten von Ihnen erhalten, dann werden diese zweckbezogen erhoben 
und verarbeitet. Eine Datenverarbeitung zu anderen Zwecken kommt nur 
dann in Betracht, wenn die insoweit erforderlichen rechtlichen Vorgaben 
gemäß Art. 6 Abs. 4 DSGVO vorliegen. Die DVZ M-V GmbH beachtet etwaige 
Informationspflichten nach Art. 13 Abs. 3 DSGVO und Art. 14 Abs. 4 DSGVO 
sowie das Widerspruchsrecht nach Art. 21 DSGVO. Weitere Informationen 
erhalten Sie auf https://www.dvz-mv.de/Datenschutz/



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




--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeomatics.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Can't compile GDAL 2.4.0 with Visual 2017 - 32 bits

2019-02-25 Thread Jeff McKenna

On 2019-02-25 10:44 AM, PROVIN wrote:

Hello Jeff,

Thank you for your answer, I had tried that already (I usually compile 
GDAL this way with NMAKE),


but I had the exact same error.

Maybe this has to do with my installation of Visual Studio ?



Possibly yes.  If you google "stdio.h visual studio 2017" you will see 
many people with instructions on how to make sure the proper Windows SDK 
version is used.


-jeff




--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeomatics.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Can't compile GDAL 2.4.0 with Visual 2017 - 32 bits

2019-02-22 Thread Jeff McKenna

Hi Remi,

Personally I'd recommend using the provided nmake.opt inside GDAL's root 
directory, and modifying that for your own local libraries.  (note that 
the cleanest way to do this is to create a new file 'nmake.local' and 
put your settings in there, leaving the distributed nmake.opt as 
reference only, and then execute that with the command:


nmake /f makefile.vc

(others may recommend using the *.bat magic, but sometimes the raw 
commandline is more fun ha)


Have a nice weekend,

-jeff




On 2019-02-21 9:18 AM, PROVIN wrote:

Hello,

I am trying to compile GDAL (version 2.40, but I also tried 2.3.1) with 
Visual 2017 in 32 bits.


I used the generate_vcxproj.bat to generate my Visual project / 
solution, this way (as indicated) :


generate_vcxproj.bat   15.0 32 gdal_vs2017

The compilation gives the following error :

fatal error C1083: Impossible d'ouvrir le fichier include : 'stdio.h' : 
No such file or directory (compilation du fichier source cpl_list.cpp)


I have this error for all the files cpl_.cpp  of "port" folder.

It is strange because these files are accessible when I right click on 
the line


#include 

and open the file.

I tried to retarget the project, tried to reinstall Visual 2017.

I would be glad if anyone had any advice !

Thank you,

REMI



--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeomatics.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

  1   2   3   >