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 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 Thursday 20 August 2015 13:46:52 Sebastiaan Couwenberg wrote: 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. Sounds good to me. 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. 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 ? Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ 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
Sounds good. Let's move this discussion to https://github.com/google/libkml/issues/4 On 12 August 2015 at 15:31, Sebastiaan Couwenberg sebas...@xs4all.nl wrote: 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 ___ 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 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 August 2015 at 13:04, Sebastiaan Couwenberg sebas...@xs4all.nl wrote: 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? I fully agree with mashbridge, that we should welcome non-google Committers to the project. Maybe it would make sense to form libkml into an OSGeo project? That's probably not going to happen, as that would mean giving away libkml, which we don't want to do, at this point in time at least. It is, and will continue to be a Google owned project. 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). Agreed. It's good to see that we seem to be in agreement on how to continue. I'd say that the next steps would be to start getting those 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. Yea, I suppose that would work. Just thinking less technically on this. :) I don't have any strong opinions on the version number. 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. --Wolf ___ 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 August 2015 at 18:56, Sebastiaan Couwenberg sebas...@xs4all.nl 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! 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. 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. Also we might want to call it libkml 2.0.0 so we don't really need to worry about backwards compatibility. --Wolf ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Regarding libkml driver
Hi Rashad and all, 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. -kurt On Tue, Aug 4, 2015 at 9:59 PM, Kurt Schwehr schw...@gmail.com wrote: Hi Rashad, I am starting to look into libkml from the Google side. I will chat with mashbridge in next week and see if we can get some motion on libkml. -kurt Engineer at Google On Sun, Aug 2, 2015 at 12:22 PM, Rashad M mohammedrasha...@gmail.com wrote: On Sun, Aug 2, 2015 at 9:05 PM, Even Rouault even.roua...@spatialys.com 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. Another action would be to change the documentation page of the libkml driver and related Trac wiki pages to point to your fork. By the way, did you try running the ogr_libkml.py tests from GDAL autotest suite with your fork ? What is the Windows status of the fork ? And with a Windows build of GDAL ? I had tested on VS2010 on windows7 and works fine. with a gdal windows built, I haven't tested yet. I will get back to you on that and also on ogr_libkml.py test To answer your initial question, yes, changes should go as a patch to a Trac ticket. -- Spatialys - Geospatial professional services http://www.spatialys.com -- Regards, Rashad ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- -- http://schwehr.org -- -- http://schwehr.org ___ 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] Regarding libkml driver
I've compiled libkml from the libkml/libkml git repo and really like that minizip for example is an external dependency. This makes it so that other applications that require minizip can be compiled easily now. Donovan On 11/08/15 09:56 AM, 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. 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 -- Kind regards, Donovan ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Regarding libkml driver
Hi Rashad, I am starting to look into libkml from the Google side. I will chat with mashbridge in next week and see if we can get some motion on libkml. -kurt Engineer at Google On Sun, Aug 2, 2015 at 12:22 PM, Rashad M mohammedrasha...@gmail.com wrote: On Sun, Aug 2, 2015 at 9:05 PM, Even Rouault even.roua...@spatialys.com 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. Another action would be to change the documentation page of the libkml driver and related Trac wiki pages to point to your fork. By the way, did you try running the ogr_libkml.py tests from GDAL autotest suite with your fork ? What is the Windows status of the fork ? And with a Windows build of GDAL ? I had tested on VS2010 on windows7 and works fine. with a gdal windows built, I haven't tested yet. I will get back to you on that and also on ogr_libkml.py test To answer your initial question, yes, changes should go as a patch to a Trac ticket. -- Spatialys - Geospatial professional services http://www.spatialys.com -- Regards, Rashad ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- -- http://schwehr.org ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Regarding libkml driver
Hello all, We have been working on a new fork of libkml library on github. The primary interest to detach from google/libkml was that various modification in the library are fragmented in the github forks and nothing gets merged. There is no activity or interest by original authors and all efforts to contact them failed. You can find more details on why it forked here - https://github.com/google/libkml/issues/4 . We had clearly explained this also in the readme of the fork. As the library is used in many open source gis tools, we thought it might be worth to unify the efforts in one place. Fix bugs, submit patches, publish new releases and so on. Would it be possible to have gdal kml driver to use this version? If so what will be the preferred way, submit a patch on trac will be sufficient?. There are lot of enhancements and bug fixes in the fork. Most of them are towards build system. https://github.com/libkml/libkml -- Regards, Rashad ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Regarding libkml driver
On Sun, Aug 2, 2015 at 8:12 PM, Even Rouault even.roua...@spatialys.com wrote: Rashad, Hello all, We have been working on a new fork of libkml library on github. The primary interest to detach from google/libkml was that various modification in the library are fragmented in the github forks and nothing gets merged. There is no activity or interest by original authors and all efforts to contact them failed. You can find more details on why it forked here - https://github.com/google/libkml/issues/4 . We had clearly explained this also in the readme of the fork. As the library is used in many open source gis tools, we thought it might be worth to unify the efforts in one place. Fix bugs, submit patches, publish new releases and so on. It would be great to have a lively libkml indeed, especially since the GDAL libkml driver depends on a unreleased version of the libkml code. Any plan/timeline to produce an official release of your fork ? I had tagged 1.3.0-rc0 on github. https://github.com/libkml/libkml/releases Would it be possible to have gdal kml driver to use this version? If so what will be the preferred way, submit a patch on trac will be sufficient?. Does the GDAL libkml driver actually need changes ? Are there been API changes ? 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. There are lot of enhancements and bug fixes in the fork. Most of them are towards build system. https://github.com/libkml/libkml Even -- Spatialys - Geospatial professional services http://www.spatialys.com -- Regards, Rashad ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Regarding libkml driver
Rashad, Hello all, We have been working on a new fork of libkml library on github. The primary interest to detach from google/libkml was that various modification in the library are fragmented in the github forks and nothing gets merged. There is no activity or interest by original authors and all efforts to contact them failed. You can find more details on why it forked here - https://github.com/google/libkml/issues/4 . We had clearly explained this also in the readme of the fork. As the library is used in many open source gis tools, we thought it might be worth to unify the efforts in one place. Fix bugs, submit patches, publish new releases and so on. It would be great to have a lively libkml indeed, especially since the GDAL libkml driver depends on a unreleased version of the libkml code. Any plan/timeline to produce an official release of your fork ? Would it be possible to have gdal kml driver to use this version? If so what will be the preferred way, submit a patch on trac will be sufficient?. Does the GDAL libkml driver actually need changes ? Are there been API changes ? There are lot of enhancements and bug fixes in the fork. Most of them are towards build system. https://github.com/libkml/libkml Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Regarding libkml driver
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. Another action would be to change the documentation page of the libkml driver and related Trac wiki pages to point to your fork. By the way, did you try running the ogr_libkml.py tests from GDAL autotest suite with your fork ? What is the Windows status of the fork ? And with a Windows build of GDAL ? To answer your initial question, yes, changes should go as a patch to a Trac ticket. -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Regarding libkml driver
On Sun, Aug 2, 2015 at 9:05 PM, Even Rouault even.roua...@spatialys.com 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. Another action would be to change the documentation page of the libkml driver and related Trac wiki pages to point to your fork. By the way, did you try running the ogr_libkml.py tests from GDAL autotest suite with your fork ? What is the Windows status of the fork ? And with a Windows build of GDAL ? I had tested on VS2010 on windows7 and works fine. with a gdal windows built, I haven't tested yet. I will get back to you on that and also on ogr_libkml.py test To answer your initial question, yes, changes should go as a patch to a Trac ticket. -- Spatialys - Geospatial professional services http://www.spatialys.com -- Regards, Rashad ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
