Re: [gdal-dev] doc bugs about prereqs, surfaced by updating pkgsrc for 3.9
On 6/6/24 8:21 PM, Greg Troxel via gdal-dev wrote: also, I am far from a cmake expert, but I looked in the CMakeFiles and cannot find where they - try to run the compiler with --std=c++17 # check compiler and set preferences. if (NOT CMAKE_CXX_STANDARD) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) endif() https://github.com/OSGeo/gdal/blob/master/CMakeLists.txt#L39-L43 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How do I add a projection to proj 8?
On 4/13/24 10:19 AM, Javier Jimenez Shaw via gdal-dev wrote: Bas, are they really equivalent? As far as I know they are, where one used to use EPSG:900913 they should now be using EPSG:3857, as 900913 is deprecated. https://wiki.openstreetmap.org/wiki/Web_Mercator Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How do I add a projection to proj 8?
On 4/12/24 11:24 PM, Stephen Woodbridge via gdal-dev wrote: and was able to access it in gdal, mapserver, postgis, etc with "EPSG:900914" I used to do that too, but switched to EPSG:3857 its non-deprecated equivalent. I would recommend that instead of trying to keep using a non-standard projection. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Un-vendoring a number of third-party libraries?
On 12/15/23 15:35, Even Rouault via gdal-dev wrote: Thoughts ? (given the length of the email, it should probably be formalized as a RFC. I'll do that, unless there is a massive uprising against the proposal...) LERC doesn't support big endian architectures currently, only using that on little endian architectures using the internal copy currently works as expected. Using the external library would require conditionals in the packaging which I'm not in favor of. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 3.8.1 RC1 is available, and motion to approve it
On 11/24/23 13:22, Hernán De Angelis via gdal-dev wrote: May be this is of help: I have seen the case of the .py utilities not been compiled and installed a couple of times when I mistakenly had two Python versions present and acccessible. There is an issue with setuptools silently failing with python3.12: https://bugs.debian.org/1055682 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 3.8.1 RC1 is available, and motion to approve it
On 11/24/23 13:16, Even Rouault via gdal-dev wrote: The Python utilities are no longer installed with the .py extension, this broke their use in QGIS when we removed this in the Debian package some time ago. Don't know if that's still the case. Either way, this doesn't seem like an appropriate change for a .1 patch release. Are you sure about the .py utilities no longer be installed? Because, I see both /usr/bin/gdal2tiles and /usr/bin/gdal2tiles.py installed on Ubuntu 22.04 (before I reverted the change to add the launcher scripts) Both are installed indeed. I overlooked this when dh_missing failed on the executables without extension. Installing usr/bin/__init__ is still wrong though. Skipping __init__.py when creating the console_scripts list may suffice. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 3.8.1 RC1 is available, and motion to approve it
On 11/23/23 22:56, Even Rouault via gdal-dev wrote: From a packaging point of view, the following change might have impacts on build recipes: The Python utilities are no longer installed with the .py extension, this broke their use in QGIS when we removed this in the Debian package some time ago. Don't know if that's still the case. Either way, this doesn't seem like an appropriate change for a .1 patch release. usr/bin/__init__ is now also installed which not correct. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Is the SOSI Norwegian driver still useful?
On 11/14/23 20:05, Even Rouault via gdal-dev wrote: Le 14/11/2023 à 19:48, Sebastiaan Couwenberg via gdal-dev a écrit : On 11/14/23 19:16, Even Rouault via gdal-dev wrote: ==> Are there users still using the existing OGR SOSI driver ? We don't have metrics for the OGR driver, but libfyba0 still has 513 users in popcon. https://qa.debian.org/popcon.php?package=fyba Looking in the same column in https://qa.debian.org/popcon.php?package=gdal shows that gdal-bin would have only 520 users... which seems highly suspiciously low compared to the super specialized and low level libfyba. I would bet that > 99% of installations of libfyba0 are because libgdal links to it, which doesn't mean that it is used for useful stuff (the other reverse dependency of libfyba in Debian is sosi2osm, which according to https://qa.debian.org/popcon.php?package=sosi2osm, has only 3 users) sosi2osm was removed from Debian during the bookworm development cycle. The only rdep of fyba in Debian is gdal now. Almost all installations of libfyba are due to it being a dependency of gdal, that's why it has 23911 installations but only 513 votes (regular users). What if people build a Docker image of GDAL from source and install its dependencies with apt install libfyba-dev: will that trigger a hit in popcorn? popcon is opt-in, there are only ~23 systems running popcon out of millions of Debian installations. Hence it's mostly usable to provide insight into relative popularity compared to other packages in Debian. Container images are unlikely to enable popcon, the Docker images don't even have it installed. I'm more interested in Norwegian flesh and bones users testifying about their use or non-use of SOSI. Me too, if there are none left we can also remove the fyba package from Debian. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Is the SOSI Norwegian driver still useful?
On 11/14/23 19:16, Even Rouault via gdal-dev wrote: ==> Are there users still using the existing OGR SOSI driver ? We don't have metrics for the OGR driver, but libfyba0 still has 513 users in popcon. https://qa.debian.org/popcon.php?package=fyba Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Adopt GDAL 3.8.0RC1 as 3.8.0 release
On 11/8/23 09:39, Even Rouault via gdal-dev wrote: Adopt GDAL 3.8.0RC1 as 3.8.0 release Can we get this fixed before the release? https://github.com/OSGeo/gdal/pull/8682 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] libgdaljni.so installed in the wrong dir by default?
The Debian package moved the files to their policy compliant paths: https://salsa.debian.org/debian-gis-team/gdal/-/commit/936e50e1a9e5eb3d1bd10147b5d5c25476845b23#8756c63497c8dc39f7773438edf53b220c773f67_198_195 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] building against external tiff/geotiff sources ?
On 3/4/23 11:10, Landry Breuil wrote: what do other packagers of gdal think about it ? Providing an option/flavor for end-users of the packaging system to build against internal copies might also be possible, but that creates havoc in dependency trees.. The Debian package will keep using the external tiff because we don't want to deal with the tiff security updates in the embedded copy. Features that are only available when using the embedded copy won't be enabled in the Debian package. The only sane way forward is to not use private functions of tiff. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Build difficulties (Ubuntu 20.04)
On 1/24/23 06:28, dg...@darc.de wrote: I would suggest to look at the gdal packaging in Ubuntu or Debian. There are "make-depends" in the dsc files or in debian/control. My entry page is https://tracker.debian.org/pkg/gdal dsc file are linked via an icon in the "versioned links" on the left side. debian/control can be reached via "browse source code" on the right side. If you want to install the build dependencies, ensure you have deb-src lines enabled in sources.list and use: apt build-dep gdal Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Advanced 3.6.1 release and retraction of 3.6.0 ?
On 12/15/22 20:35, Even Rouault wrote: The same holds with source tarballs of 3.6.0 available on download.osgeo.org/gdal/3.6.0 or as github release. Digging into history, we retracted 1.7.0 in https://trac.osgeo.org/gdal/wiki/DownloadSource#a1.7.0retracted-January2010 and as far as I can see in http://download.osgeo.org/gdal/old_releases/ , the 1.7.0 tarballs were also removed from download. Why try to scrub buggy releases from the history? They are not infectious diseases that need to be avoided like the plague. The release happened so the artifacts associated with it should remain, because of a significant bug a new release was published sooner than expected to reduce the time the latest release is affected. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Advanced 3.6.1 release and retraction of 3.6.0 ?
On 12/13/22 16:18, Even Rouault via gdal-dev wrote: Given the status of GeoPackage being the default format for QGIS, I believe this is a severe enough issue to warrant an advanced 3.6.1 release, and an official retraction of 3.6.0. Thoughts ? Yes, please. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 3.6.0 release candidate available
On 11/3/22 18:51, Even Rouault wrote: Note the first item about the new CMake build system build the only one now available. BUILDING.md only mentions that autoconf is deprecated. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] About bug fix / patch release policy for older GDAL versions (setuptools >= 58.0 and GDAL <3.3 compatibility issues)
On 3/25/22 12:07, Even Rouault wrote: what you discuss here is all about the patch & backport policy of the Debian GDAL package. You can try to file a bug to Debian and point to the patch you'd want to see backported, but I can't promise if there would be interest in their maintenance team to create an updated package with it (my understanding is that even if we'd release a new 3.2.x patch release, it wouldn't be packaged in LTS distributions. I'm not sure how much of that is linked to Debian policy or availability of people that do the work) Packages in Debian stable releases only get updates to fix bugs of severity important or higher [0]. GDAL patch releases also contain changes for lower severity issues, it's not worth the effort to vet all those changes. Any changes to packages in stable also risk introducing regressions which are highly undesirable in LTS releases known for their stability. People should be maintaining their own packaging repositories where they host packages with changes for their needs that cannot be easily upstreamed to the package in the distribution itself. Scratching your own itch was a corner stone of Open Source that people are seemingly forgetting or never having known about in the first place. [0] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#special-case-uploads-to-the-stable-and-oldstable-distributions Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 3.5.0alpha1 available
How will the gdal-grass tarball be generated?
Will frmts/grass/GNUmakefile remain with only the dist target, e.g. like
attached patch?
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1diff --git a/frmts/grass/GNUmakefile b/frmts/grass/GNUmakefile
index ce4c30a06e..8d35789cde 100644
--- a/frmts/grass/GNUmakefile
+++ b/frmts/grass/GNUmakefile
@@ -1,18 +1,4 @@
-
-
-include ../../GDALmake.opt
-
-OBJ = grass.o
-
-CPPFLAGS := -DGRASS_GISBASE=\"$(GRASS_GISBASE)\" $(GRASS_INCLUDE) $(PROJ_INCLUDE) $(CPPFLAGS)
-
-default: $(OBJ:.o=.$(OBJ_EXT))
-
-clean:
- rm -f *.o $(O_OBJ) $(OBJ)
- rm -f *~
-
-install-obj: $(O_OBJ:.o=.$(OBJ_EXT))
+GDAL_VER=$(strip $(shell grep GDAL_RELEASE_NAME ../../gcore/gdal_version.h.in | awk -F'"' '{print $$2}'))
dist:
cp -r pkg gdal-grass-$(GDAL_VER)
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 3.5.0alpha1 available
On 3/24/22 12:23, Even Rouault wrote: - do like we did in recent versions, ie have no doc/ directory in the tarball, and just generated man pages (will need https://github.com/OSGeo/gdal/issues/5491 to be implemented to automatically have CMake to install the generated man pages) This has my preference, the Debian package strips the doc directory from the upstream tarball (since 3.1.0~rc1) because license & copyright review was a PITA. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 3.5.0alpha1 available
On 3/21/22 19:14, Even Rouault wrote: Other things you spotted ? There doesn't seem to be an equivalent for the install-man target, there is no CMakeLists.txt in man/man1 nor is that directory included in gdal.cmake. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Moving GDAL GRASS driver in a dedicated repository ?
On 3/22/22 19:41, Even Rouault wrote: bumping again this topic, after feedback just received on 3.5.0alpha1. For now, I'm heading to completely disable CMake build support for the GRASS drivers in https://github.com/OSGeo/gdal/pull/5490 . Only the existing autoconf scripts that are provided with the plugin (if they work ?) will be usable. The libgdal-grass Debian package uses the autoconf bits. As noted in my comments, CMake build support could potentially be re-enabled, but just allowed the driver to be built as a plugin, and not built-in in GDAL core lib. However that would still do a full GDAL build, not just the driver, so this is perhaps not so useful (a CMake build for the driver would just use an already built GDAL and use find_package(GDAL) ) It would be good if someone could step up as the maintainer of the driver in-tree, or in an external repository. Otherwise we might just end up giving it the treatment of other drivers that lack attention from a maintainer, ie rm -rf . According to the wiki Markus and Markus are the maintainers of the GRASS driver: https://github.com/OSGeo/gdal/wiki/Maintainers-per-sub-system With GRASS using non-standard library directories it doesn't work that well as recently discussed on grass-dev: https://lists.osgeo.org/pipermail/grass-dev/2022-February/095596.html Removing the driver upstream and the libgdal-grass package from Debian would make my life easier, so no objection from me. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 3.5.0alpha1 available
On 3/21/22 19:14, Even Rouault wrote: Other things you spotted ? A bunch of new data (and one ini) files, and some helper scripts like: frmts/grib/degrib/extract_tables.py frmts/grib/degrib/merge_degrib_and_wmo_tables.py There doesn't seem to be an equivalent for: --with-threads --with-sse --with-ssse3 --with-avx The latter three seem to only be detected whether they're available at build time, this is somewhat problematic for distribution packages where the system building it won't be the same as the ones running it. Also no GDAL_USE_GRASS to disable it explicitly like --with-grass=no. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 3.5.0alpha1 available
On 3/21/22 18:39, Sebastiaan Couwenberg wrote: Quite a lot of new files which suggests that CPACK_SOURCE_IGNORE_FILES needs more work. Also quite a lot of noise in the diff due $Id$ expansion changes like: - * $Id: armadillo_headers.h dd1e0e25c2d41bbb0b63061751483276ab5da090 2019-04-27 15:27:04 +0200 Even Rouault $ + * $Id: armadillo_headers.h $ Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 3.5.0alpha1 available
Quite a lot of new files which suggests that CPACK_SOURCE_IGNORE_FILES needs more work. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ 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]
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 -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 3.0 on Debian 10
On 6/30/21 8:42 PM, Dirk Stenger wrote: > What is the easiest way to install GDAL 3.0 on Debian 10? Are there > binaries available that I can use? Is there a manual describing how to > install GDAL 3.0 on Debian 10? I wouldn't bother with GDAL 3 on buster, consider upgrading to bullseye already its release is due soon. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OSM issue with a relation containing all fields from its children
On 8/10/20 10:36 AM, g.jaegy wrote: > The relation is #8601362, see https://www.openstreetmap.org/relation/8601362. > > This relation has two members, #24338289 which is indeed a lake, and > #532474841 which is not a lake. The relation in OSM is invalid. type=boundary without additional tags is already a sign. Because the outer ways in the relation have descriptive tags themselves, the relation could be considered old-style, but that's only for type=multipolygon. The member relation 5462089 is also invalid, it doesn't have a type and it has touching outer rings. You should probably ignore relations like this in your code, but the data in OSM should also be fixed. I would delete relation 8601362, move the tags from relation 5462089 to way 577387272 and merge this with way 24338289 to become one larger closed way. Then relation 5462089 can also be removed because the close way already represents the lake, no need for a relation with a single outer way (since the lake doesn't appear to have islands nor islets). Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] how to completely remove gdal from Ubuntu 20.04 and install from scratch
On 8/8/20 2:35 AM, Gerald Nelson wrote:
> I can’t find any good directions for how to do a deep clean, or for that
> matter to install gdal on Ubuntu 20.04 so I was hoping to get some directions
> here.
To get rid of the gdal package you can use:
apt purge $(dpkg -l | grep gdal | awk '{print $2}' | xargs)
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] undefined reference to `json_object_new_array linking with libgdal.a
On 7/22/20 8:38 PM, Luí s Moreira de Sousa wrote: > I work with GDAL installed from the Ubuntu GIS repository. There is no gdal for focal in the UbuntuGIS PPA. > I could not verify, but I doubt it is compiled with the > --with-hide-internal-symbols flag. The gdal packages in the UbuntuGIS PPA like those in Ubuntu use the same packaging as in Debian and that uses --with-hide-internal-symbols, see: https://salsa.debian.org/debian-gis-team/gdal/-/blob/master/debian/rules#L117 And: https://launchpadlibrarian.net/471535809/buildlog_ubuntu-focal-amd64.gdal_3.0.4+dfsg-1build3_BUILDING.txt.gz https://launchpadlibrarian.net/468243097/buildlog_ubuntu-bionic-amd64.gdal_3.0.4+dfsg-1~bionic0_BUILDING.txt.gz Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 3.1.0 RC2 available
On 5/3/20 10:05 PM, Even Rouault wrote: >> It's indeed not possible to make everybody happy, so the question is who >> you do mind the least to make unhappy. >> >> If nothing changes packagers like me will be unhappy because they need >> to reintroduce the virtual dependency for the unstable C++ ABI. >> >> C-only users will be unhappy about having to rebuild their code when the >> only C++ ABI breaks. >> >> And you will be unhappy if you have to split the library. > > OK, so here's what I intend to change for RC3: > https://github.com/OSGeo/gdal/pull/2466/files Bumping the SONAME is great, the rest looks good too. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 3.1.0 RC2 available
On 5/3/20 9:15 PM, Even Rouault wrote: > Answering Bas' > >> If you don't want that, then two libraries need to be built with their >> own library versioning. > > and Gregs' > >> This doesn't make sense. The current/revision/age needs to be handled >> differently for the C library and the C++ library, because in feature >> releases one of them does not have an ABI break and the other one does >> have an ABI break. They will then not have the same shlib major >> numbers, which is an obvious consequence of the above versioning policy. > > Separating a C library from a C++ one would represent a big deal of work, as > there are C > symbols called from C++ code, so that means that when currently there's a C > function like > GDALInvGeoTransform(), there should be a C++ one, like > gdal::InvGeoTransform() that does > what GDALInvGeoTransform() does, and GDALInvGeoTransform() would call this > one, and > make sure all code from drivers etc that calls currently > GDALInvGeoTransform() would call > instead gdal::InvGeoTransform(). > Anyway this isn't a discussion for this release, but more for a GDAL 4 or > more. > >>> I'm not sure about the resolution here. Should I do a RC3 that sets >>> CURRENT/REVISION/AGE to 27/0/0 ? Would that help ? >> >> I think it would be really unfortunate to break the C ABI as a side >> effect. That would change your policy above that there is (perhaps) an >> ABI break on feature releases. > > The C ABI of GDAL 3.1 is the same as GDAL 3.0. But if I bump the CURRENT > number, as there's > just one lib, it will apply to the C and C++ side of it obviously. So I can > imagine that's slightly > inconvenient for people that just depend on the C ABI and wouldn't need to > rebuild, but I'm > afraid there's no way to make everybody happy. It's indeed not possible to make everybody happy, so the question is who you do mind the least to make unhappy. If nothing changes packagers like me will be unhappy because they need to reintroduce the virtual dependency for the unstable C++ ABI. C-only users will be unhappy about having to rebuild their code when the only C++ ABI breaks. And you will be unhappy if you have to split the library. Bumping the SONAME for C++-only ABI breaks is the most correct solution as long as its provided by the same library, and splitting the libraries in GDAL 4 seems like the right thing to do. The choice is up to you. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 3.1.0 RC2 available
On 5/3/20 8:10 PM, Even Rouault wrote: >> Why wasn't the SONAME bumped to reflect the ABI breakage? > > For me, SONAME bump was meant for the C ABI. I don't think this was intended > for the C++ > one. They share the same library, so the SONAME covers both. If you don't want that, then two libraries need to be built with their own library versioning. That would allow for more granular rebuilds of rdeps as the C++ using ones will need to be rebuilt for X.(Y+1) versions but the C using ones not. >> We dropped the virtual dependency that required rebuilding for every >> GDAL version change because you claimed that this wasn't required any more. > > There has been obviously a misunderstanding. The rule we follow is that: > - between GDAL X.Y.Z and X.Y.(Z+1), both C and C++ ABI are stable > - between GDAL X.Y and X.(Y+1), the C ABI is stable, but the C++ one not > > And this is what we have in our release procedure: > """ > 4) Update LIBGDAL_CURRENT/REVISION/AGE macros in GDALmake.opt.in. >- For a release with no interface changes just bump REVISION. >- Adding interfaces, bump CURRENT/AGE, set REVISION to 0. >- Deleting interfaces / compatibility issues - bump CURRENT, others to > zero. > """ > > So as interfaces were added, I bumped CURRENT/AGE and set REVISION to 0. > But maybe "compatibility issues" should also be understood to changes that > affect the C++ > ABI ? Yes. If the ABI of the library is not compatibly any more, i.e. rdeps needs to be rebuilt, then the SONAME needs to be bumped. > I'm not sure about the resolution here. Should I do a RC3 that sets > CURRENT/REVISION/AGE to 27/0/0 ? Would that help ? Yes, as that bumps the SONAME to libgdal.so.27, which signals that rdeps need to be rebuilt. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 3.1.0 RC2 available
On 5/3/20 7:47 PM, Even Rouault wrote: > Looking at what is presumably the native side of ogrListLayers(), > https://salsa.debian.org/r-pkg-team/r-cran-rgdal/-/blob/master/src/ogrsource.cpp#L1090 > > I see it use thes GDAL C++ API. Given that the C++ ABI can change between > GDAL feature > releases (and it did change between 3.0 and 3.1 in the GDALDataset class used > here), if rgdal > isn't rebuilt against GDAL 3.1 headers, crashes are expected. Why wasn't the SONAME bumped to reflect the ABI breakage? We dropped the virtual dependency that required rebuilding for every GDAL version change because you claimed that this wasn't required any more. It seems we'll need to reintroduce this because the libgdal ABI is not stable. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 3.1.0 RC2 available
On 5/3/20 7:36 PM, Edzer Pebesma wrote: > In the r-cran-sf logs, I find: > > autopkgtest [09:48:59]: build not needed > > But if a new version of GDAL was just installed, a build would have been > needed (assuming we use dynamic linking). GDAL did not bump the SONAME, so it claims to be ABI compatible with the version the r-cran packages were built with. Rebuilding should not be required. Or is this an R thing I'm not familiar with? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 3.1.0 RC2 available
On 5/3/20 7:09 PM, Even Rouault wrote:
> Looking at
> https://ci.debian.net/data/autopkgtest/unstable/amd64/r/r-cran-rgdal/5203587/log.gz
> ,
> there doesn't seem to be much detail about what fails exactly.
From the log:
autopkgtest [09:49:06]: test run-unit-test: [---
...
BEGIN TEST srs_rendering.R
R version 3.6.3 (2020-02-29) -- "Holding the Windsock"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> suppressPackageStartupMessages(library(rgdal))
> getPROJ4VersionInfo()
[1] "Rel. 7.0.0, March 1st, 2020, [PJ_VERSION: 700]"
> getGDALVersionInfo()
[1] "GDAL 3.1.0, released 2020/04/28"
> d <- system.file("vectors", package="rgdal")
> shps <- ogrListLayers(d)
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Aborted
autopkgtest [09:49:07]: test run-unit-test: ---]
autopkgtest [09:49:07]: test run-unit-test: - - - - - - - - - -
results - - - - - - - - - -
run-unit-testFAIL non-zero exit status 134
> The following message in the log is also a bit strange:
> """
> Loaded GDAL runtime: GDAL 3.1.0, released 2020/04/28
>but rgdal build and GDAL runtime not in sync:
>... consider re-installing rgdal!!
> """
> I'd assume everything to match perfectly in a Debian build env.
Nothing has been (re)built with GDAL 3.1.0 yet.
When packages are uploaded to experimental, autopkgtest is triggered for
the rdeps in unstable to test for any regressions.
The same is done when packages are uploaded to unstable, then the
autopkgtest for the rdeps in testing are triggered. Any regressions
block the migration of package.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 3.1.0 RC2 available
Just for the record and in case the R authors are reading along, the test suite for r-cran-rgdal (1.4-8-1) [0] & r-cran-sf (0.9-2+dfsg-1) [1] fail with gdal (3.1.0~rc2+dfsg-1~exp1) from Debian experimental [2]. [0] https://ci.debian.net/data/autopkgtest/unstable/amd64/r/r-cran-rgdal/5203587/log.gz [1] https://ci.debian.net/data/autopkgtest/unstable/amd64/r/r-cran-sf/5203588/log.gz [2] https://release.debian.org/britney/pseudo-excuses-experimental.html#gdal Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ 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 4/27/20 3:37 PM, Even Rouault wrote: > 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. The embedded RTD theme (especially its fonts) and logo images are a PITA. I'm tempted to just drop the libgdal-doc package are exclude the entire doc/ subdirectory when repacking the tarball to make license & copyright review less of a pain. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] [Geotiff] libgeotiff 1.6.0 release soon
On 4/20/20 12:15 PM, Even Rouault wrote: > In preparation for the upcoming GDAL 3.1.0 release, I intend to prepare a > libgeotiff 1.6.0 release later this week. I believe things are in good shape, > but > if people want to give it a quick try to master, that's welcome. Will there be an RC before the release? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Compiling gdal 2.4.4: "fatal error: mysql.h: No such file or directory"
On 3/19/20 3:51 PM, aborruso wrote: > When I run "./configure --with-mysql=/usr/bin/mysql" I have no error. You need to supply the path to mysql-config: --with-mysql=ARG Include MySQL (ARG=path to mysql_config) [default=no] Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] upgrading to gdal-2.4.2 on debian:buster
On 2/6/20 1:55 AM, Jon Seymour wrote: > What is the best way for me to upgrade gdal from 2.4.0 to 2.4.2 on a debian > buster system? Create a buster-backports branch from the most recent debian/2.4.x tag in the package repository, and follow the procedure for backports: https://debian-gis-team.pages.debian.net/policy/packaging.html#git-backports Add your backported package to your own apt repo and use that to upgrade the installed package, or install it manually. Since the virtual ABI dependency wasn't updated for every patch release in 2.4 you don't need to rebuild any of the reverse dependencies when upgrading to a newer 2.4.x. Alternatively, work with the package maintainer to get the required bugfixes into an official stable update, assuming that the severity is important or higher. https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#upload-stable Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Schedule for next bugfix release
On 10/19/19 8:04 PM, Even Rouault wrote: > Not sure if I'll do > a 2.4.3 for this round or defer that for a next time (are there people still > needing those 2.4.x releases?) Yes, please. It's good to make the fix for CVE-2019-17545 more widely available to those unable to upgrade to 3.x yet. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL linked against CFITSIO on debian/ubuntu
On 7/15/19 11:20 AM, Chiara Marmo wrote: > Do you mind if I open a new issue on the Debian bug tracker (if relevant) > after their answer? No. If there is user demand to support CFITSIO in the gdal package an wishlist bugreport is a good way to express that. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL linked against CFITSIO on debian/ubuntu
On 6/13/19 5:05 PM, Chiara Marmo wrote: > I'm checking different OS and distributions for GDAL link against CFITSIO. I > was pretty sure that Ubuntu and Debian allow the use of CFITSIO but > apparently Ubuntu 18.04 does not... > I've found a "--with-cifitsio=no" in the debian versioning system [1] but > I can't test debian right now. The rules file is pretty clear, I'd say. The feature is not enabled. If you look at the changelog you'll find why it was disabled: gdal (1.4.1-5) unstable; urgency=low * libcfitsio3 library is now GPL on Debian, so disabled due to incompatibility with GDAL copyright. (closes: #422537) The linked bugreport has more backgrounds: https://bugs.debian.org/422537 > On Fedora the gdal package checks for the presence of CFITSIO and links > against it if found. Fedora is not very strict about license & copyright issues. > Is someone in this list close to debian/ubuntu packagers? Doesn't get any closer than this. ;-) > Am I wrong? No. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 2.5.0 beta1 available
On 4/19/19 9:31 PM, Jim Klassen wrote: > Shouldn't they have different .so major versions? They do: * PROJ 4.9.3: SOVERSION 12 5.0.0: SOVERSION 13 5.1.0: SOVERSION 14 6.0.0: SOVERSION 15 * libgeotiff 1.4.3: SOVERSION 2 1.5.0: SOVERSION 5 * libgdal 2.4.0: SOVERSION 20 2.5.0: SOVERSION 26 See also: https://abi-laboratory.pro/index.php?view=timeline&l=proj https://abi-laboratory.pro/index.php?view=timeline&l=gdal https://abi-laboratory.pro/index.php?view=timeline&l=libgeotiff Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 2.5.0 beta1 available
On 4/19/19 4:40 PM, Greg Troxel wrote: > I was just trying to point out that the 6-only status > of 2.5.0 is likely going to lead to quite delayed adoption in packaging > systems. Can you share an overview of the PROJ 6 status in NetBSD? Since NetBSD doesn't have most of the problematic packages or hasn't patched them as heavily as in Debian, I think that you should be able to move to PROJ 6 much sooner than other distributions. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 2.5.0 beta1 available
On 4/19/19 4:08 PM, Greg Troxel wrote: > Even Rouault writes: >> GDAL 2.5.0 *requires* PROJ >= 6.0, and if using external libgeotiff, > > I would expect then that packaging systems will hold off on this, > because I don't think we've reached the point that the collateral damage > of upgrading proj to 6 is ok. > > With any luck I'm wrong and most of the proj-using packages have had a > release that works on 6, but it seems that there are a lot of packages > not yet able to cope. It's not as bad as it seems. If you set the accept deprecation flag, most packages that still use proj_api.h build successfully with PROJ 6. See: https://lists.debian.org/debian-gis/2019/04/msg4.html (and the follow-ups) The ones that still use projects.h are somewhat hopeless, they tend to be dead upstream, so are candidates for removal. The biggest concerns are cartopy, R sf & lwgeom, SAGA, and VTK. I've seen no progress for the R packages, nor anything tangible for VTK (although it can be built with its embedded copy of libproj4 3.2). The cartopy test failures may be (partially) fixed with PROJ 6.1.0 like the test failures with the RDNAP datumgrid, but I expect more changes will be required to get all tests to pass. Once the SAGA changes are available in a future release, it will likely not be compatible with QGIS, but such is the fate of processing modules. I stopped caring about anything other that GRASS when it comes to QGIS, and even for GRASS I'll drop the support when it breaks. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] installing gdal in CentOS
On 3/21/19 11:02 PM, Thomas Gertin wrote: > Does anybody know how to install gdal in CentOS? From EPEL: https://fedoraproject.org/wiki/EPEL Or use the spec as inspiration for building it yourself: https://src.fedoraproject.org/cgit/rpms/gdal.git/tree/ Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal and proj
On 3/8/19 4:30 PM, Greg Troxel wrote: > Sebastiaan Couwenberg writes: > >> On 3/8/19 2:11 PM, Greg Troxel wrote: >>> But, I can't see where proj is actually linked. configure seems to >>> simply declare that it will be dynamic if there is no explicit request >>> to use the version 4 API. I don't see it linked into ligdal.so, or >>> ogr2ogr, or any other file that is produced. I don't find HAVE_PROJ in >>> makefiles to add -lproj. >> >> Looks like you don't use the --with-static-proj4 configure option which >> was renamed to --with-proj in 2.3.0. > > Are you saying that just building gdal without configuring options means > there is no proj support in gdal, and that you have to give an > affirmative --with-proj? I didn't guess that, as usually configure > finds things that are wanted normally. I am not saying that. I just know that the Debian package has explicitly enabled the PROJ support in GDAL with those configure options since before I was involved, and the resulting libgdal.so has libproj.so.13 in its NEEDED section. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal and proj
On 3/8/19 2:11 PM, Greg Troxel wrote: > But, I can't see where proj is actually linked. configure seems to > simply declare that it will be dynamic if there is no explicit request > to use the version 4 API. I don't see it linked into ligdal.so, or > ogr2ogr, or any other file that is produced. I don't find HAVE_PROJ in > makefiles to add -lproj. Looks like you don't use the --with-static-proj4 configure option which was renamed to --with-proj in 2.3.0. Kind regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGDI 4.0.0RC1 ready for testing
On 3/1/19 5:26 PM, Even Rouault wrote: > I can't reproduce this. > I've renamed my pkg-config binary and /usr/include/rpc/rpc.h to trigger the > need of pkg-config and I get a clean error: We use a clean chroot and `autoreconf -fi` before calling configure. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGDI 4.0.0RC1 ready for testing
On 3/1/19 2:33 PM, Even Rouault wrote: > I'll promote this RC to final if there are no serious issues reported. Not having pkg-config installed causes configure to fail with syntax errors instead of failing gracefully about the lack of the pkg-config requirement. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGDI 4.0.0RC1 ready for testing
On 3/1/19 3:36 PM, Even Rouault wrote: > On vendredi 1 mars 2019 15:20:19 CET Sebastiaan Couwenberg wrote: >> On 3/1/19 2:33 PM, Even Rouault wrote: >>> Download links: >>> https://freefr.dl.sourceforge.net/project/ogdi/ogdi/4.0.0RC1/ogdi-4.0.0RC1 >>> .tar.gz >>> https://freefr.dl.sourceforge.net/project/ogdi/ogdi/4.0.0RC1/ogdi-4.0.0RC >>> 1.zip >>> >>> [...] >>> >>> Sourceforge CVS being now read-only, upstream development is now >>> definitely at https://github.com/libogdi/ogdi >> >> The release tag on GitHub is ogdi_4_0_0, shouldn't that reflect the RC >> status too? > > I'll recreate it if a RC2 is needed While I'd rather see the tag renamed as it causes the upstream version detection for the Debian package to see newer release, that situation hopefully won't last long. We also cannot rely on the release tags to know when 4.0.0 final is released. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGDI 4.0.0RC1 ready for testing
On 3/1/19 2:33 PM, Even Rouault wrote: > Download links: > https://freefr.dl.sourceforge.net/project/ogdi/ogdi/4.0.0RC1/ogdi-4.0.0RC1.tar.gz > https://freefr.dl.sourceforge.net/project/ogdi/ogdi/4.0.0RC1/ogdi-4.0.0RC1.zip > > [...] > > Sourceforge CVS being now read-only, upstream development is now definitely at > https://github.com/libogdi/ogdi The release tag on GitHub is ogdi_4_0_0, shouldn't that reflect the RC status too? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 2.3.3 rc1 available
On 12/14/18 1:21 PM, Even Rouault wrote: > I'll call for a vote to promote it to final at the beginning of next week if > nothing serious is reported before. gcore/gdal_version.h.in is still at 2.3.2 instead of 2.3.3. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Issue #2068 on Mint 19
On 9/15/18 2:28 PM, Micha Silver wrote: > AFAIK, you don't necessarily need the ubuntugis repo in bionic distros. > The regular ubuntu repos have pretty recent versions. On my Mint systems > I get GRASS 7.4.0, and gdal 2.2.3. But every invocation of gdal > commands begins with: > micha@TP480:~$ gdalinfo --version > ERROR 1: libgrass_dgl.7.4.0.so: cannot open shared object file: No such > file or directory > ERROR 1: libgrass_dgl.7.4.0.so: cannot open shared object file: No such > file or directory > ERROR 1: libgrass_vector.7.4.0.so: cannot open shared object file: No > such file or directory > ERROR 1: libgrass_vector.7.4.0.so: cannot open shared object file: No > such file or directory > GDAL 2.2.3, released 2017/11/20 That's a known issue on Ubuntu based systems which build with --as-needed by default. A fix was added in libgdal-grass (2.3.0-2) triggered by https://trac.osgeo.org/osgeolive/ticket/2068. This fix is also available in libgdal-grass (2.2.3-3~bionic0) in the OSGeoLive PPA, but not in the ubuntugis-unstable PPA (any more). It's possible that a later rebuild of the libgdal-grass package reverted the fix. > And these errors are appearing also in R with the MODIS package. > > What are the implications of adding the ubuntugis-unstable repo to solve > this? The libgdal-grass package in the UbuntuGIS PPA needs to be fixed. The older package from bionic most likely also doesn't have this fix. Kind Regards, Bas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] deb package for 2.2.3
On 05/04/2018 10:06 AM, Angelos Tzotsos wrote: > Let me check if I can push 2.2.3 to experimental within the weekend. Do you mean 2.2.4? Note that no transition is required from 2.2.3 to 2.2.4, but there is from 2.2.2 and earlier. Kind Regards, Bas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] deb package for 2.2.3
On 05/04/2018 07:11 AM, Grégory Bataille wrote: > I'm running gdal 2.2.2 from ubuntu-gis/experimental .deb package and I just > got stuck by https://trac.osgeo.org/gdal/ticket/7143. > Took me some time to debug because I develop locally on Mac, where the > package is at 2.2.3 and the bug is fixed. Note that you can also upgrade your system to bionic which includes gdal (2.2.3+dfsg-2). Kind Regards, Bas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] deb package for 2.2.3
On 05/04/2018 07:11 AM, Grégory Bataille wrote: > I'm running gdal 2.2.2 from ubuntu-gis/experimental .deb package and I just > got stuck by https://trac.osgeo.org/gdal/ticket/7143. > Took me some time to debug because I develop locally on Mac, where the > package is at 2.2.3 and the bug is fixed. > > What does it take to build the .deb package. Is this something that someone > can do? is this something sufficiently scripted that I can do it and give > you guys the result for publication? In the case of UbuntuGIS, you can rebuild the source package from Debian. The sources are available in git: https://salsa.debian.org/debian-gis-team/gdal https://salsa.debian.org/debian-gis-team/gdal-grass Once you have rebuild the gdal package, you need to rebuild all reverse dependencies (packages that depend on libgdal20) with the new gdal to have them use the new virtual ABI dependency. Because of interdependencies you need to rebuild the packages in the correct order, have a look at: https://trac.osgeo.org/ubuntugis/wiki/BuildOrder Note that this page may have become outdated again. The Debian GIS transition trackers shows all libgdal20 reverse dependencies in Debian unstable: https://linuxminded.nl/debian/gis-transitions/html/gdal.html You will need to host all the rebuild packages in your own PPA to easily install them. If your goal is to update the gdal packages in the UbuntuGIS PPA, you need to coordinate your contributions on the appropriate mailinglist: https://lists.osgeo.org/mailman/listinfo/ubuntu Due to the lack of manpower, pretty much all the packages in the UbuntuGIS PPA get copied from the OSGeoLive PPA where a little more manpower is available to create backports of Debian GIS packages for Ubuntu LTS releases. The next OSGeoLive release will be based on bionic, and will rely for a large part on the packages already available in Ubuntu because they're up-to-date with the latest upstream releases. At least proj & gdal will most likely be updated to 5.0.1 & 2.3.0 for OSGeoLive 12.0. So you can also just wait for those packages to find their way from the OSGeoLive PPA to the UbuntuGIS PPA. Contributing to OSGeoLive is also most welcome. Kind Regards, Bas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] spatialite on Debian: neither lwgeom nor rttopo
On 02/18/2018 11:18 PM, Tobias Wendorff wrote: > Did anyone recognize that stable and unstable Debian neither builds > lwgeom nor rttopo in libspatialite by default? lwgeom support was disabled to untangle the circular dependency as documented in the spatialite changelog: - Drop build dependency on liblwgeom-dev to untangle spatialite->postgis->gdal->spatialite circular dependency. rttopo support will be available in the next spatialite release, but it's taking forever to get past 4.4.0-rc1. There will most likely never be a 4.4.0 final release, and I've also heard talk about skipping 4.5.0 in favor of going for 5.0.0 instead. As long as there is no rttopo support in the released spatialite, the Debian package will not enable the support. The rttopo 1.1.0 final release also hasn't been published yet, this is all still work in process in preparation of proper topo support in spatialite. > This means: no ST-functions using SQLite dialect. > > For lwgeom it might be disabled due to licensing problems. spatialite's > support for rttopo might be unstable, so this is for homebrew only. > But nobody can test it, since it's also disabled by default. There is no license problem, there is a dependency problem. > If you manually enable lwgeom in the Debian sources and rebuild the > package, everything works as expected... Didn't try for rttopo, but > should behave equal. Your system will fail to do distribution upgrades to newer stable releases. Even updating your systems to get the newer postgis or gdal packages will fail (assuming your on testing/unstable). You're very much on your own if you choose to re-instate the circular dependency. As they say: when it breaks you get to keep the pieces. Kind Regards, Bas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 2.2.3 planning
On 11/01/2017 11:32 AM, Even Rouault wrote: > I've add an exchange with Sebastiaan Couwenberg about a schedule that would > give GDAL 2.2.3 a chance to enter the next Ubuntu LTS 18.04. While the date > for the import freeze from Debian to Ubuntu is not know yet, based on the > last > release cycle, it seems that a GDAL 2.2.3 released this month would have a > chance to make it (given other delays in Debian transitionning from > experimental to unstable) The transition to GDAL 2.2.3 in Debian started yesterday, and it looks like Ubuntu has already completed it. gdal (2.2.3+dfsg-1) & libgdal-grass (2.2.3-1) and the rebuild reverse dependencies are available in the release pocket for the upcoming bionic LTS. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 2.2.3 planning
On 11/17/2017 11:58 AM, Martin Landa wrote: > Hi, > > 2017-11-17 9:58 GMT+01:00 Sebastiaan Couwenberg : >> Has the gdal-grass plugin been updated to support 7.4? Or are there no >> new libraries that need to be linked like last time? [0] >> >> [0] https://trac.osgeo.org/gdal/ticket/6785 > > I tried to compile plugin against GRASS 7.4, no problem appeared. Ma Compiling wasn't the issue last time, it only showed at runtime. I just packaged GRASS 7.4.0-RC1, and there are no new libraries like last time, so that won't be an issue. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 2.2.3 planning
On 11/16/2017 10:16 PM, Markus Neteler wrote: > On Wed, Nov 1, 2017 at 7:26 PM, Jeff McKenna > wrote: >> On 2017-11-01 7:32 AM, Even Rouault wrote: >>> I've add an exchange with Sebastiaan Couwenberg about a schedule that >>> would give GDAL 2.2.3 a chance to enter the next Ubuntu LTS 18.04. While the >>> date for the import freeze from Debian to Ubuntu is not know yet, based on >>> the last release cycle, it seems that a GDAL 2.2.3 released this month would >>> have a chance to make it (given other delays in Debian transitionning from >>> experimental to unstable) >>> >>> So I intend cutting a GDAL 2.2.3 release candidate for Nov 20th. >>> >>> Please raise tickets if there are bug fixes that need to be backported and >>> haven't yet been. >>> >>> Even >>> >> >> Hi Even, >> >> Also, it is rarely ever discussed but I find that releases occurring near >> the timing of other projects in the family can be helpful for all (users, >> packagers, developers): MapServer release will be around the week of the >> 15th also, so a Nov 20th GDAL release would be great. This can't always >> happen, but when it does it is sure nice. -jeff > > Hi, > > interestingly we are going to publish GRASS GIS 7.4.0 RC1 also in these days! Has the gdal-grass plugin been updated to support 7.4? Or are there no new libraries that need to be linked like last time? [0] [0] https://trac.osgeo.org/gdal/ticket/6785 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] [Ubuntu] Binary of the latest released GDAL for travis?
On 09/20/2017 10:56 PM, Johan Van de Wauw wrote: > Angelos, Bas, do you have a list of gdal dependencies and the order in > which they need to be built? I'm thinking about uploading my packages > to ubuntugis/unstable. The the transition tracker: http://linuxminded.nl/tmp/pkg-grass-transitions/html/gdal.html The UbuntuGIS specific transition trackers are broken due to some issue in ben that was introduced in the stretch version. It always uses the data for Debian unstable instead of those configured in the config file. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Automating code style enforcement ?
On 05/05/2017 01:11 PM, Even Rouault wrote: > By the way, git cl format doesn't seem available out-of-the-box on my Ubuntu > 16.04. Perhaps > there's an additional package to install ? There is git2cl, but that only supports the GNU ChangeLog format. IIRC git-cl is part of clang-format, but I don't think that's included in the Debian package. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Ubuntu GDAL 1.10.1 support for ECW formats
On 02/16/2017 08:46 PM, Stephen Woodbridge wrote: > Any ideas on this? ECW support is not enabled in the Debian package, that's why your client doesn't have it. You probably have a custom build installed in /usr/local or elsewhere. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] "symbol(s) not found for architecture x86_64" when compiling GDAL 2.1.0 on Mac OS X
On 02/12/2017 07:52 PM, Michal Migurski wrote: > --without-png --without-jpeg Because of that the PNG & JPEG symbols are not found, but they're required for the MRF driver. Add --without-mrf to disable that too. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to install GDAL 2.x on CentOS 7 without being by building from source?
On 02/10/2017 07:35 PM, Leonan Carvalho wrote: > I would love to contribute to update EPEL version. > The last version was updated 1 year ago > http://pkgs.fedoraproject.org/cgit/rpms/gdal.git/commit/?h=epel7 > > But I have no idea how to do it. Follow the instructions linked from: https://fedoraproject.org/wiki/EPEL#How_can_I_contribute.3F Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to install GDAL 2.x on CentOS 7 without being by building from source?
On 02/10/2017 06:51 PM, Leonan Carvalho wrote: > I'm using CentOS and it all working fine because a easy installation with > "yum install gdal gdal-python" but this packages are outdated, the provided > version is 1.11 which isn't quite the latest from 1.x major version. > All repositories (that I know) area out-dated. There is no problem to > install from source, even that you need to make it on several servers. > > Geographic Information Systems Stack Exchange Question : > http://gis.stackexchange.com/q/227929/63611?sem=2 > > Do you have any feedback or comment on this? The packaging maintained by Fedora was recently updated to 2.1.3, you can rebuild this (and all reverse dependencies) for CentOS: http://pkgs.fedoraproject.org/cgit/rpms/gdal.git EPEL has GDAL 1.11.4 for CentOS 7 which is only one release behind the latest 1.11.x. KInd Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] compile gdal 2.1.3 with HDF5 support on Debian Lennie
Please upgrade your system to jessie, Debian lenny is EOL since February 6th 2012. See: https://wiki.debian.org/DebianReleases Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 2.1.3 release candiate
On 01/21/2017 05:31 PM, Greg Troxel wrote: > I couldn't find how to run tests (which I am assuming exist); > there was not a test or check target. I didn't find a README in th > sources, and the wiki info which I did find pointed to by docs doesn't > mention running tests. https://trac.osgeo.org/gdal/wiki/TestingNotes documents: " The primary means of testing is to run the gdalautotest python regression test suite. After building with either the old or new generation python bindings, and installing them (or adding them to your path from the build tree) do the following: % svn checkout https://svn.osgeo.org/gdal/trunk/autotest % cd autotest % ./run_all.py " Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 signature.asc Description: OpenPGP digital signature ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] shapelib 1.4.0RC1 available
On 12/06/2016 06:33 PM, Even Rouault wrote: > Old Makefile build replaced by autoconf/automake (by Sandro Mani) This is a very welcome change, allowing us to drop a bunch of patches from the Debian package. I've forwarded the remaining patches to Bugzilla. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] DODS driver (packagers recommended to disable it)
On 11/09/2016 11:03 AM, Even Rouault wrote: > Le mercredi 09 novembre 2016 08:12:16, Sebastiaan Couwenberg a écrit : >> Via Launchpad issue #1640360 [0] I was informed about a segfault in the >> DODS driver when fed a JSON URL. In the related IRC discussion packagers >> are recommended to disable the DODS driver. [1] >> >> Is the DODS driver so error prone to make this recommendation? > > AFAIR, I hadn't compiled it in years before a few minutes ago (nor can I > remember > any question or bug reports related to it in recent time, except crashes or > annoyances[1] occuring > with non DODS related URL, hence a sign it might be only of marginal use) and > my past memories with it were not so good when it is fed with "random" URLs. > I somehow > remember crashes occuring in libdap itself (perhaps due to how the driver > uses it?), > but perhaps the situation in it has improved with more recent versions of > libdap. > > Here the crash occurred in the GDAL driver code, so I've fixed it per > https://trac.osgeo.org/gdal/ticket/6718 / > https://trac.osgeo.org/gdal/changeset/36175, which you might backport in the > Debian > package. Thanks for the fix, I've included it as a patch in the Debian package. That's a much better option than disabling the DODS driver in my opinion as it avoids an ABI break. I'll first upload a new gdal revision to Debian before including the patch in the UbuntuGIS packages too. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] DODS driver (packagers recommended to disable it)
Via Launchpad issue #1640360 [0] I was informed about a segfault in the DODS driver when fed a JSON URL. In the related IRC discussion packagers are recommended to disable the DODS driver. [1] Is the DODS driver so error prone to make this recommendation? The driver has been enabled for a very long time in the gdal Debian package, so I'm surprised about the recommendation to disable it now. The GDAL_SKIP=DODS env var seems like a fine workaround for this specific issue, since the Launchpad issue is the first to report issues with it. If the OpenEx function handles other JSON data correctly, and only fails for the proprietary arcgis service, that doesn't seem like a good a reason to disable the DODS driver which would disadvantage its users. [0] https://bugs.launchpad.net/ubuntu/+source/gdal/+bug/1640360 [1] http://irclogs.geoapt.com/osgeo/%23osgeo.2016-11-09.log Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Sort files in static library to make the build reproducible
Hi Even, On 05/20/2016 02:05 PM, Even Rouault wrote: >> [I'm sending this to the list because I'm unable to successfully create >> a ticket with description in Trac at the moment. As reported in #6520 >> [0] adding a ticket description causes an internal server errors on >> submit, it looks like the spam filter cannot handle the content.] > > You got -3 points of karma due to: > ExternalLinks (-3): Maximum number of external links per post exceeded > > (so somewhat changing a bit the links so they are no longer valid URL might > potentially work) > > and then : > IPThrottle (-4): Maximum number of posts per hour for this IP exceeded > > Unfortunately it doesn't seem there's a way to whitelist users... > > I've classified your attempts as 'ham' so hopefully the filter will lean from > that... Thanks for troubleshooting. I've reopened the ticket with the links spread over several comments. >> As part of the effort to support Reproducible Builds [1] Alexis >> Bienvenüe submitted two patches in Debian Bug #824808 [2] to sort the >> object files in the static library: sort-files-1 [3] & sort-files-2 [4] >> >> These patches resolve the random_order_in_static_libraries issue [5], >> which is illustrated by the diffoscope output [6]. >> >> The attached patch is modified version of the sort-files-2 patch doing >> do wildcard sorting in the `$(LIBGDAL)` target instead of a separate >> >> `$(LIBGDAL).buildit` target. Alexis chose that approach because: >>> In some situations some of the target dependencies do not exist >>> before the "make target" call. When this arises, as $(wildcard) is >>> expanded before building the dependencies, it can miss some files… >>> I was not sure of the situation here, so I added a transitional >>> target to be safe. >> >> I prefer the single line change in the attached patch, but you may want >> to consider the separate target as done in the sort-files-2 patch too. > > I've not an authoritative opinion on makefile issues. Was just wondering if > one > or another one of the approach might cause issues to "odd" environements, > like > mingw. But I see that we already do the backticks in the gdal.pc target. Both backticks and the Makefile functions should be supported on Windows too, but I haven't tested on Windows. I did opt out of the approach from the sort-files-1 patch because it's unlikely to work on Windows, it uses ls with the C locale to sort the objects instead of the Makefile functions. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Sort files in static library to make the build reproducible
[I'm sending this to the list because I'm unable to successfully create a ticket with description in Trac at the moment. As reported in #6520 [0] adding a ticket description causes an internal server errors on submit, it looks like the spam filter cannot handle the content.] As part of the effort to support Reproducible Builds [1] Alexis Bienvenüe submitted two patches in Debian Bug #824808 [2] to sort the object files in the static library: sort-files-1 [3] & sort-files-2 [4] These patches resolve the random_order_in_static_libraries issue [5], which is illustrated by the diffoscope output [6]. The attached patch is modified version of the sort-files-2 patch doing do wildcard sorting in the `$(LIBGDAL)` target instead of a separate `$(LIBGDAL).buildit` target. Alexis chose that approach because: > In some situations some of the target dependencies do not exist > before the "make target" call. When this arises, as $(wildcard) is > expanded before building the dependencies, it can miss some files… > I was not sure of the situation here, so I added a transitional > target to be safe. I prefer the single line change in the attached patch, but you may want to consider the separate target as done in the sort-files-2 patch too. [0] https://trac.osgeo.org/gdal/ticket/6520 [1] https://wiki.debian.org/ReproducibleBuilds [2] https://bugs.debian.org/824808 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824808;msg=5;att=1;filename=sort-files-1 [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824808;msg=5;att=2;filename=sort-files-2 [5] https://tests.reproducible-builds.org/issues/unstable/random_order_in_static_libraries_issue.html [6] https://tests.reproducible-builds.org/dbd/unstable/amd64/gdal_2.1.0+dfsg-2.diffoscope.html Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 sort-files-in-static-library.patch Description: inode/symlink ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL/OGR 2.0.2 and 1.11.4 released
On 29-01-16 16:28, Bas Couwenberg wrote: > Even Rouault wrote: >> Le vendredi 29 janvier 2016 15:20:07, Bas Couwenberg a écrit : >>> Even Rouault wrote: It is not definite how long the team will still maintain the 1.11 branch, so users are strongly encouraged to migrate to 2.0.2. >>> >>> Because not all reverse dependencies support GDAL 2.0 yet, the next Debian >>> stable release (stretch) will most likely stick to 1.11.x as will the next >>> Ubuntu LTS (xenial). >> >> Are there many (and "important") reverse dependencies not yet ready ? If >> not, >> couldn't they be withdrawn from the main repo and added back via a PPA or >> something like that when ready ? > > The most important missing piece is Fiona, we need the upcoming 1.7 release > for its GDAL 2.0 support. But it's not expected until march. A patch is > available in the BTS, but upstream has changed the GDAL 2.0 support, and those > changes were not easy to backport, so I gave up and chose to wait for the new > upstream release. > > When we have Fiona 1.7 we may not be able to transition before the freeze in > preparation of the release. > > There are no PPAs in Debian so that's not an option. We could abuse backports > for it, but that's not really an option either. > >>> I hope this will not cause too many issues. >> >> It would be annoying for applications that could make use of GDAL 2.0 >> abilities. >> But I can imagine the challenge of managing a collection of applications... > > I've prepared patches for most packages, but these have not seen any real > world testing yet. So I'm not entirely confident we can switch to 2.0 without > issues. The safe choice is to stick to 1.11, but I'll try to transition to > 2.0 before the freeze when the prerequisites are met. I managed to backport the GDAL 2.0 changes to Fiona 1.6.3 after all. So instead of transitioning to 1.11.4, 2.0.2 was used instead. Earlier today GDAL 2.0.2 and most of its reverse dependencies migrated to Debian testing leading in the end of the transition. The remaining reverse dependencies should migrate later this week, except SAGA which is blocked by the libvigraimpex transition. Unfortunately this transition was too late to have GDAL 2.x included in the upcoming Ubuntu LTS release, that will still ship with GDAL 1.11.3. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] epsg code for wgs84
On 23-12-15 14:27, Gane R wrote: > can any one specify the epsg code for wgs 84 EPSG:4326, you can find this on the Spatial Reference website for example: http://spatialreference.org/ref/epsg/wgs-84/ Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Regarding libkml driver
On 20-08-15 13:46, Sebastiaan Couwenberg wrote: > I'm working on a patch to try and support both the old Automake based & > new CMake based libkml by adding support for libkml.pc. I've got a working patch for the Debian package, forwarded in: https://trac.osgeo.org/gdal/ticket/6077 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Regarding libkml driver
On 20-08-15 16:48, Even Rouault wrote: > On Thursday 20 August 2015 13:46:52 Sebastiaan Couwenberg wrote: >> I'm working on a patch to try and support both the old Automake based & >> new CMake based libkml by adding support for libkml.pc. > > Are there differences in the installed files from libkml whether you use > automake or cmake ? Or did you mean that you're attempting to remove those > differences ? Both are significant changes between the old and new libkml upstreams. The old libkml that originated on code.google.com, and is now maintained on github.com/google/libkml, uses Automake to build the libraries and swig bindings. It relies on embedded copies of 3rd party libraries. The new libkml that forked from code.google.com, and is now maintained on github.com/libkml/libkml, uses CMake to build the libraries and swig bindings. It prefers system installed copies of the 3rd party libraries, but can also download the required versions to use during the build. The changes for the third_party code in libkml/libkml fork is one of it strong points. The switch from Automake to CMake also helped get rid of patches required to keep Automake working with recent versions. With the renewed activity around google/libkml with the new engineers joining the project, I'm hopefull we can get the libkml/libkml changes back into google/libkml. If libkml development remains active in google/libkml the libkml/libkml fork won't be required anymore. Until google/libkml becomes a viable alternative to libkml/libkml, I'm using the latter as upstream for the libkml Debian package that is primarily required for gdal. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Regarding libkml driver
On 02-08-15 21:05, Even Rouault wrote: > On 02-08-15 20:45, Rashad M wrote: >> No API changes. it make building and configuring libkml easier! >> >> Correct me If I am wrong, I guess with a pkg-config would be easier to find >> and configure libkml libs. > > Yes, that would probably be better. That said my experience with GDAL > configure > --with-libkml has been good up to now. But having a pkg-config script could > simplify the current detection and configuration logic. The current m4/ax_lib_libkml.m4 doesn't detect the new libkml because it still expects the thirdparty boost headers. We should probably keep this as a fallback for the old libkml, but prefer pkgconfig if that's available as is the case for the new libkml. As part of the ongoing GCC 5 transitions we've switched to the new libkml in Debian, with the geos & gdal transitions soon to follow, and gdal now builds without KML support because it doesn't detect the new libkml properly. I'm working on a patch to try and support both the old Automake based & new CMake based libkml by adding support for libkml.pc. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Regarding libkml driver
On 12-08-15 15:13, Wolf Bergenheim wrote: > I'm beginning to wonder if we should have our own libkml mailinglist, since > all this talk is strictly not GDAL... But as long as no-one objects. But > that's also something to think about for the future. Most of this discussion can be continued in the 'Project status' issue on GitHub: https://github.com/google/libkml/issues/4 A dedicated libkml mailinglist is very welcome too, preferably mailman based, not Google Groups Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Regarding libkml driver
On 12-08-15 00:55, Wolf Bergenheim wrote: > On 11 August 2015 at 18:56, Sebastiaan Couwenberg wrote: >> On 11-08-15 18:37, Kurt Schwehr wrote: >>> Wolf and I have joined in working on libkml. We will be getting more >>> transitioned from the old code.google.com site to >>> https://github.com/google/libkml, will be pushing some general >>> maintanence >>> patches and will be getting the pull request processed. We look forward >>> to >>> collaborating on future development of libkml. >> >> The renewed interest in libkml from Google sounds promising. > > Glad to hear it! I've also commented on the Project status GitHub issue: https://github.com/google/libkml/issues/4 As I wrote in an earlier comment: " I'd love to see all GIS developers rally around the new preferred repository to collaboratively maintain libkml, breathing new life into this useful library because there are no good alternatives. " The community involvement in libkml development is essential in my opinion to prevent the project from dying again when the Google engineers loose interest or otherwise move on. What are your thoughts about that? Maybe it would make sense to form libkml into an OSGeo project? >> What are your views on merging the work in the libkml/libkml fork back >> into google/libkml? >> >> > I'd like to merge back as much of the work that has gone into libkml/libkml > to google/libkml. Especially externalizing libraries. That's great, very much what we need. >> The switch to CMake and removal of the third party dependencies in favor >> of linking to system provided libraries solve the issues that required >> patches in the libkml Debian package in the past. I'd like to see these >> changes merged back into google/libkml to not loose these gains. > > These sound very interesting, and I'll look at them more closely, but on > the surface it looks good. > >> Most importantly the final 1.3.0 libkml release is long overdue, it has >> been required for GDAL for many years now but many distributions still >> ship libkml 1.2 (Fedora removed libkml even because it was abandoned >> upstream). What do you think needs to be done to get the 1.3.0 release out? > > Hmm. I think that we should first get to the point where we can merge the > libkml/libkml stuff back to google/libkml before we push out a new release, > in order to avoid confusion and mess. We definitely need to sort out how to continue libkml development, what to do with the forks (Kitware has many changes in their fork too that should be considered). > Also we might want to call it libkml 2.0.0 so we don't really need to worry > about backwards compatibility. The libkml 1.3.0-rc0 release from libkml/libkml already includes a SONAME bump to account for the minizip changes. Bumping the version to 2.0.0 makes sense if more drastic changes are included, otherwise it seems better to follow the 1.2 release with 1.3.0. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Regarding libkml driver
On 11-08-15 18:37, Kurt Schwehr wrote: > Wolf and I have joined in working on libkml. We will be getting more > transitioned from the old code.google.com site to > https://github.com/google/libkml, will be pushing some general maintanence > patches and will be getting the pull request processed. We look forward to > collaborating on future development of libkml. The renewed interest in libkml from Google sounds promising. What are your views on merging the work in the libkml/libkml fork back into google/libkml? The switch to CMake and removal of the third party dependencies in favor of linking to system provided libraries solve the issues that required patches in the libkml Debian package in the past. I'd like to see these changes merged back into google/libkml to not loose these gains. Most importantly the final 1.3.0 libkml release is long overdue, it has been required for GDAL for many years now but many distributions still ship libkml 1.2 (Fedora removed libkml even because it was abandoned upstream). What do you think needs to be done to get the 1.3.0 release out? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Implementing a streaming version of KML Driver
On 04/28/2015 11:30 PM, Dmitry Baryshnikov wrote: > https://code.google.com/p/libkml/downloads/list?can=1&q=&colspec=Filename+Summary+Uploaded+ReleaseDate+Size+DownloadCount > > > The last release was on Feb 2010 - 5 year ago. Does the libkml still alive? > Also libkml has depending on boost, and kml driver has no external > depending. Google was nagged enough to move libkml to GitHub where it got some updates, but development has stopped there again too. See: https://github.com/google/libkml/ I'm in discussion with some of the libkml fork developers to get the community to take over libkml maintenance. See: https://code.google.com/p/libkml/issues/detail?id=161 https://github.com/google/libkml/issues/4 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
