Re: [gdal-dev] Installation on Windows
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?
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?
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
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
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
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
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
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
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
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
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
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
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
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?
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 ?
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.
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
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
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?
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
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?
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
+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]
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
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
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
+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
+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
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
+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
+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
+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
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
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
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
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
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
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]
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]
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 !
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
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
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
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
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
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
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
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
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
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
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
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
+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
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
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
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
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
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
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
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
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?
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
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
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)
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)
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
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?
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
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
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
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
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)
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
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
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
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
+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)
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
+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
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?
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
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
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
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
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 ?
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
+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
+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
+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
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 ?
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
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
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
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 ?
+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
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
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
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
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
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
