Re: [gdal-dev] Motion: OSGeo Community Sprint Financial Support
+1 Daniel On 2023-10-31 12:59, Howard Butler via gdal-dev wrote: Dear PSC, Sorry for the short notice, but I would like to motion that the GDAL Sponsorship Program financially support GDAL PSC members who wish to attend the OSGeo Community Sprint in Vienna [1] next week. Support level is capped at 1000€ for European attendees and 1500€ for others. Howard [1] https://wiki.osgeo.org/wiki/OSGeo_Community_Sprint_2023 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Annual Contracts for Maintainers
For the record: Norman and Daniel also +1'd on October 11. On 2023-10-16 15:59, Howard Butler via gdal-dev wrote: On Oct 11, 2023, at 11:13 AM, Howard Butler wrote: PSC, I'm a little late but I would like to make the following motions in regards to GDAL maintainers: * Authorize Alessandro Pasotti for up to 30 hrs/month with a rate increase of 10 euros/hr until 30 NOV 2024. * Authorize Even Rouault for up to 90 hrs/month with a rate increase of 10 $/hr until 30 JUL 2024 Howard Declaring this passed with +1s from Jukka, Frank, Kurt, Sean, and Javier. Howard ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Annual Contracts for Maintainers
+1 Daniel On 2023-10-11 12:13, Howard Butler via gdal-dev wrote: PSC, I'm a little late but I would like to make the following motions in regards to GDAL maintainers: * Authorize Alessandro Pasotti for up to 30 hrs/month with a rate increase of 10 euros/hr until 30 NOV 2024. * Authorize Even Rouault for up to 90 hrs/month with a rate increase of 10 $/hr until 30 JUL 2024 Howard ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: add Javier Jiménez Shaw to GDAL PSC
+1 Daniel On 2023-09-16 07:31, Even Rouault wrote: Hi, I would like to nominate Javier Jiménez Shaw for GDAL PSC membership. Javier has been involved with GDAL for quite a time now, as a responsive user & ticket reporter, and has occasionally contributed fixes. Javier is well anchored in our ecosystem, with deep knowledge of CRS topics and PROJ (I've also nominated him for PROJ membership), contributing to PDAL as well. As part of his job, he's involved in orthomosaic/raster generation out of images and photogrammetry pipelines. His perspective would be most welcome. Starting with my +1 Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Grant Dan Baston Merge Rights
Obviously +1 Daniel On 2023-09-12 15:21, Howard Butler wrote: Dear PSC, Dan Baston is an active GDAL maintainer who does not currently have merge rights. Let's fix that so he can get more work done without waiting on someone to merge things up :) /me starts with +1 Howard ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Adopt GDAL 3.7.0RC1 as 3.7.0 release
+1 Daniel On 2023-05-08 09:02, Even Rouault wrote: Hi, Motion: Adopt GDAL 3.7.0RC1 as 3.7.0 release Starting with my +1 Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ 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 ?
+1 for 3.6.1 with this fix. Daniel On 2022-12-13 10:18, Even Rouault via gdal-dev wrote: Hi, https://github.com/qgis/QGIS/issues/51188 has been brought to my attention. The issue is that the new background building of the RTree of GeoPackage files introduced in 3.6.0 didn't work well with committing transactions in between, which is easily triggered by ogr2ogr. All features were inserted but with default settings ~ 10% of them lacked an entry in the spatial index, which can be enough to break interactive display and workflows relying on spatial filtering. When using ogr2ogr, I believe the issue can only be seen when creating layers with more than 100 000 features, since that's the default value for the interval at which transactions are committed. I've a fix ready in https://github.com/OSGeo/gdal/pull/6911. The fix itself is a simple two-liner: https://github.com/OSGeo/gdal/pull/6911/commits/3f5f6225fe82e0c2e0241e4f66bfb861cdf4fe9d 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 ? Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: adopt RFC88: Use GoogleTest framework for C/C++ unit tests
+1 Daniel On 2022-11-21 06:40, Even Rouault wrote: Hi, Motion: Adopt RFC88: Use GoogleTest framework for C/C++ unit tests(https://github.com/OSGeo/gdal/pull/6720) Starting with my +1, Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Add Alessandro Pasotti as GDAL maintainer
+1 Daniel On 2022-11-14 10:45, Howard Butler wrote: Dear PSC, As a result of our fundraising activity and development of NumFOCUS as a financial conduit, it is my pleasure to put forward a motion to approve Alessandro Pasotti as a contracted GDAL maintainer for the period beginning on November 21st, 2022 and ending November 21st, 2023. Details of the maintenance tasking and duties can be found at the previously approved RFC 83 https://gdal.org/development/rfc/rfc83_use_of_project_sponsorship.html The terms of the contract are for a maximum of 250 hours at 110 €/hr. Alessandro will plan to focus on GDAL tasks that make it easier to developer GUI applications like QGIS (of which he is also a very active contributor). This includes testing, APIs, and driver hardening. Howard PS I will coordinating the contracting activity in my role as the GDAL NumFOCUS contracting liaison, with Frank Warmerdam acting as the secondary. Please contact us directly with any comments or concerns. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Approve Even Rouault as a contracted GDAL maintainer for 2022-2023
+1 Daniel On 2022-08-27 08:42, Howard Butler wrote: Dear PSC, It has come to my attention that Even's term as a GDAL Maintainer officially ended 31 JUL 2022. I propose that we extend him for another year from 01 AUG 2022 to 31 JUL 2023 under the previous terms and conditions. Although a small formality, we should make sure to keep a small bit of process around these things. /me starts with +1 Howard PS, expect a GDAL Sponsorship Annual Report next week. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Ogr2ogr taking too much time to process a MapInfo TAB file
I confirm that the structure of the TAB dataset uses 512 bytes data blocks organized in a tree structure, so reading from the file implies lots of random access over the whole file even if you read the features sequentially since a single feature is stored in multiple data blocks of various types (feature header blocks, feature coordinate blocks, etc.). It would be interesting to know if VSI_CACHE as suggested by Even will help. Daniel On 2022-07-27 11:55, Even Rouault wrote: Moises, I've not reviewed in depth the MITAB driver, but reading from a .tab file may require random access, and it is thus not surprising that reading from a compressed file may exhibit poor performance. You might try to set the VSI_CACHE config option / env variable to YES, but no guarantee this will help for your use case. Even Le 27/07/2022 à 11:39, Moises Calzado via gdal-dev a écrit : Hi everyone! We're using ogr2ogr to convert MapInfo TAB files into CSV format using the following command: ogr2ogr -f CSV -skipfailures -makevalid /vsistdout/ /vsizip/onLDU.zip -oo AUTODETECT_TYPE=YES -lco CREATE_CSVT=YES > test_2.csv The file weights ≈200 MB and the process is taking too much time to finish (almost 20 min), so we don't know if we're doing something wrong regarding the command that we launch. Screenshot 2022-07-20 at 12.55.14.png However, if we launch the same command against the .tab file instead of using the vsizip virtual file system, it takes less than 30 seconds to complete. Have you ever seen something like this? Do you know if it's expected that it takes too much time to process this kind of files, or we're doing something wrong? Thanks so much for your help in advance, Regards! -- *Moises Calzado* Support Engineer (US) +1 917 463 3232 | (ES) +34 911 165 823 | mcalz...@carto.com <https://spatial-data-science-conference.com/2022/newyork/> ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- http://www.spatialys.com My software is free, but my time generally not. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GEOS Maintenance Grant
+1 Daniel On 2022-02-15 10:37, Howard Butler wrote: GDAL PSC, When we wrote the GDAL RFCs on sponsorship, we provided an escape clause to allow us to direct resources to other projects upon which GDAL depends. Our sponsorship numbers are still increasing, which provides us an opportunity to directly support some of those projects, and one of them is obviously GEOS. GEOS provides all of the geometry algebra support for GDAL/OGR and many other open source geospatial softwares including Shapely, PostGIS, GeoPandas, MapServer, and more. Dan Baston of the GEOS PSC has been identified as the developer with capacity and interest in the next year to take on GEOS development on APIs and performance, which he has a long history of doing for the project. This support should allow him to work longer, multi-release upgrades that will provide strong performance and convenience benefits for the project. I motion to provide the GEOS PSC with a $50,000 USD grant to address performance, API, and other work that does not attract directed funding in GEOS. The GEOS PSC will be responsible for coordinating work tasks, rates, and development timelines. Howard Butler or Even Rouault of the GDAL NumFocus liaison team will coordinate dispersement as directed by the GEOS PSC and NumFocus rules. Thank you again to the GDAL Sponsors https://gdal.org/sponsors/index.html who have made this kind of grant possible. A better GEOS makes for a better GDAL. Howard ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: grant github commit rights to Nyall Dawson
+1 Daniel On 2022-01-25 18:34, Even Rouault wrote: Hi, I'd like to motion to grant github commit rights to Nyall. We don't have much people currently doing reviews of pull requests and pressing the "Merge" button, and Nyall is definitely in a capacity of fulfilling this responsibility, at least in the areas where he fills comfortable. His own pull requests are of excellent quality and he's one of the few to review my work. Starting with my +1 Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Shortening schedule for CMake adoption ?
FWIW, I'll cast my +0.5 (not a full +1 because I didn't get to test myself, but I'm supportive because the feedback I've read so far sounds great) On 2022-01-17 08:37, Even Rouault wrote: Hi, The new CMake build system (https://gdal.org/development/rfc/rfc84_cmake.html) has made excellent progress, and I believe that it should be in a production ready state on time for GDAL 3.5.0 (~ May). It is already very close to it according to a checklist I had created (https://docs.google.com/spreadsheets/d/1SsUXiZxKim6jhLjlJFCRs1zwMvNpbJbBMB6yl0ms01c). Consequently we could shorten the rather conservative schedule presented in RFC 84 to : - Formally deprecate GNUmakefile and NMake base file systems. Users and packagers are encouraged to switch to CMake and actively report (and help fixing) issues the find in the process. ==> Target: GDAL 3.5 / May 2022. GDAL 3.5.x point releases will be used to address reported issues. - Completely remove GNUmakefile and NMake base file systems, and make CMake the only build system in GDAL source tree. ==> Target: GDAL 3.6 / November 2022 I can't see real advantages in keeping the 3 build systems longer than strictly needed: - it requires more maintenance effort and makes new contributions more complicated - we won't probably get significant feedback regarding the CMake build system until people have to adopt it because they have no other alternative. We already greatly welcome feedback from people trying with master. To facilitate this, I believe we could cut a GDAL 3.5 alpha in early March so that people who wait for "official" packages have a chance to give it a try too. Thoughts ? Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: promote GDAL 3.4.0RC3 as final issue
+1 Daniel On 2021-11-04 11:23, Howard Butler wrote: +1 Howard On Nov 4, 2021, at 10:02 AM, Mateusz Loskot wrote: +1 Mateusz On Thu, 4 Nov 2021 at 15:23, Rahkonen Jukka (MML) wrote: +1 -Jukka Rahkonen- -Alkuperäinen viesti- Lähettäjä: gdal-dev Puolesta Even Rouault Lähetetty: torstai 4. marraskuuta 2021 14.33 Vastaanottaja: gdal-dev@lists.osgeo.org Aihe: [gdal-dev] Motion: promote GDAL 3.4.0RC3 as final issue Hi, RC3 should be the last iteration needed to allow 3.4.0 to be released. Motion: Adopt GDAL 3.4.0 RC3 as final 3.4.0 release Starting with my +1 Even -- http://www.spatialys.com My software is free, but my time generally not. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Mateusz Loskot, http://mateusz.loskot.net ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: promote GDAL 3.3.3 RC1
+1 Daniel On 2021-10-27 14:23, Mateusz Loskot wrote: +1 Mateusz On Wed, 27 Oct 2021 at 14:45, Howard Butler wrote: +1 Howard On Oct 27, 2021, at 6:44 AM, Rahkonen Jukka (MML) wrote: +1 -Jukka Rahkonen- -Alkuperäinen viesti- Lähettäjä: gdal-dev Puolesta Even Rouault Lähetetty: keskiviikko 27. lokakuuta 2021 14.43 Vastaanottaja: gdal-dev@lists.osgeo.org Aihe: [gdal-dev] Motion: promote GDAL 3.3.3 RC1 Hi, Having heard no issues being reported regarding RC1 Motion: Adopt GDAL 3.3.3 RC1 as final 3.3.3 release Starting with my +1 Even -- http://www.spatialys.com My software is free, but my time generally not. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: RFC 84: Migrating build systems to CMake
+1 Daniel On 2021-10-11 10:14, Howard Butler wrote: All, Discussion on this topic has died down, and it appears there are no major objections, so I would like to put forward a motion to approve RFC 84. With a conservative timeline, the final outcome of this effort is GDAL will be CMake-only in May 2023. You can view the proposal at https://github.com/OSGeo/gdal/blob/1d3c283d40f4d2145c11dfca4b537fb357f53600/gdal/doc/source/development/rfc/rfc84_cmake.rst +1 Howard ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Approve Nyall Dawson as a contracted GDAL maintainer
+1 Daniel On 2021-09-14 10:59, Howard Butler wrote: Dear PSC, As a result of our fundraising activity and development of NumFOCUS as a financial conduit, it is my pleasure to put forward a motion to approve Nyall Dawson as a contracted GDAL maintainer for the year 2021-2022 beginning on October 1st, 2021 and ending September 30th, 2022. Details of the maintenance tasking and duties can be found at the previously approved RFC 83 https://gdal.org/development/rfc/rfc83_use_of_project_sponsorship.html The terms of the contract are for a maximum of 500 hours at 90 €/hr. Howard PS I will coordinating the contracting activity in my role as the GDAL NumFOCUS contracting liaison, with Frank Warmerdam acting as the secondary. Please contact us directly with any comments or concerns. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: promote GDAL 3.3.2 RC3
+1 Daniel On 2021-09-02 02:54, Even Rouault wrote: Hi, Having heard no issues being reported regarding RC3 Motion: Adopt GDAL 3.3.2 RC3 as final 3.3.2 release Starting with my +1 Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Approve Even Rouault as a contracted GDAL maintainer
+1! Daniel On 2021-08-17 11:33, Howard Butler wrote: Dear PSC, As a result of our fundraising activity and development of NumFOCUS as a financial conduit, it is my pleasure to put forward a motion to approve Even Rouault as a contracted GDAL maintainer for the year 2021-2022 beginning on August 1st, 2021 and ending July 31st, 2022. Details of the maintenance tasking and duties can be found at the previously approved RFC 83 https://gdal.org/development/rfc/rfc83_use_of_project_sponsorship.html The terms of the contract are for 833 hours at $120/hr USD. Howard PS I will coordinating the contracting activity in my role as the GDAL NumFOCUS contracting liaison, with Frank Warmerdam acting as the secondary. Please contact us directly with any comments or concerns. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: adopt RFC 83: guidelines for the use of GDAL project sponsorship
+1 Daniel On 2021-06-08 06:50, Even Rouault wrote: Hi, Motion: adopt RFC 83: guidelines for the use of GDAL project sponsorship ( https://github.com/OSGeo/gdal/pull/3855 ) Starting with my +1 Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Renaming Sponsorships tiers to align with NumFOCUS ones
Belated +1 Daniel On 2021-06-09 10:45, Even Rouault wrote: Ok, so our documentation has been updated to reflect the renaming of the sponsorship tiers. The advisory council mailing list has been renamed to gdal-advisory-coun...@lists.osgeo.org (there's a remaining issue with the archives not appearing after the renaming. ticketed at https://trac.osgeo.org/osgeo/ticket/2611#comment:2) Even Le 08/06/2021 à 22:08, Even Rouault a écrit : PSC, We've had a request from NumFOCUS to align the titles of the GDAL sponsorship tiers with the ones of NumFOCUS, to limit the risk of confusion, which was one topic discussed during last meeting. For reference, the ones of NumFOCUS are at https://numfocus.org/sponsors/become-a-sponsor, so to get consistent, our new levels would renamed as: - Gold (previously Platinum): 50k - Silver (previously Gold): 25k - Bronze (previously Silver): 10k This will help especially for actors that already have a relationship with NumFOCUS and can be confused by the current non-alignment. NumFOCUS confirmed that companies that offer a sponsorship designated to GDAL will receive both GDAL's benefits and NumFOCUS ones under that tier (if they don't already benefit from NumFOCUS sponsorship at a higher level because already sponsoring other NumFOCUS projects) I'm +1 for that change. I don't anticipate sponsors to mind about that change. The different tiers and relative positioning with other actors is probably what matters to them, more than the absolute title of the tier. Anyway, we'll communicate that change to the current sponsors, and adapt our own documentation. Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Renaming of GDAL Advisory Board
+1 Daniel On 2021-06-04 12:24, Even Rouault wrote: Hi, We just had a meeting with NumFOCUS staff, and they suggested we should rename the GDAL Advisory Board to something else. The issue is with the Board term which is a legal term and may implicate that it is a deciding body, which it is not. They suggested Council, Committee, as potential alternatives. As committee is already used for the PSC, I think "GDAL Advisory Council" could be a good fit. If there's no opposition to this, I'll change all references to it on the GDAL website (RFC 80, sponsorship prospectus), and ask for the related mailing list to be renamed/recreated. Other news: the Fiscal Sponsorship Agreement document, which will make us officialy a NumFOCUS sponsored project, is now in the signing loop. Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: promote GDAL 3.3.0 RC1
+1 Daniel On 2021-04-29 05:56, Even Rouault wrote: Hi, Having heard no issues being reported regarding RC1 Motion: Adopt GDAL 3.3.0 RC1 as final 3.3.0 release Starting with my +1 Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: adopt RFC80
+1 Daniel On 2021-04-16 10:50, Even Rouault wrote: Hi, I hereby motion to adopt RFC 80: https://github.com/OSGeo/gdal/pull/3682 This also implies adopting the "GDAL Sponsorship Prospectus" at https://docs.google.com/document/d/1yhMWeI_LgEXPUkngqOitqcKfp7ov6WsS41v5ulz-kd0/edit?ts=60777468# whose a PDF version will be uploaded on the website (https://github.com/OSGeo/gdal/pull/3681 to be updated) and the proposed answers to the NumFOCUS application form are at: https://docs.google.com/document/d/1bc5jdpCe1axdyBHxbJnun7e0DTyDoZI_eFYgJYnOhB8/edit which will be submitted consequently. Starting with my +1 Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion (V2): remove and deprecate a few drivers
+1
Daniel
On 2021-03-04 11:32, Even Rouault wrote:
Hi,
Updating my yesterday motion with the feedback received (only second
bullet updated with a more restricted set of drivers)
Motion:
- remove the vector drivers BNA, AeronavFAA, HTF, OpenAir, SEGUKOOA,
SEGY, SUA, XPlane and raster drivers BPG, E00GRID, EPSILON,
IGNFHeightASCIIGrid, NTv1. They have all been authored by myself and I'm
not aware of them having been much used or being still in use.
Implemented in https://github.com/OSGeo/gdal/pull/3373. They (driver
code, doc and tests) have been moved to the
https://github.com/OSGeo/gdal-extra-drivers
- deprecate the raster drivers DODS, JPEG2000 (superseded per
JP2OpenJPEG), JPEGLS, MG4LIDAR, FUJIBAS, IDA, INGR, ZMAP and vector
driver ARCGEN, ArcObjects, CLOUDANT, COUCHDB, DB2, DODS, FME, GEOMEDIA,
GTM, INGRES, MONGODB (superserded per MongoDBV3), REC, WALK . They will
now be disabled at runtime by default, with an explicit error message
when they are triggered, unless the
GDAL_ENABLE_DEPRECATED_DRIVER_{drivername}
configuration option is set to YES, and will be removed in GDAL 3.5.
Implemented in https://github.com/OSGeo/gdal/pull/3505
Starting with my +1
Even
--
Daniel Morissette
Mapgears Inc
T: +1 418-696-5056 #201
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: adopt RFC79: Listing of Service Providers on GDAL website
+1 Daniel On 2021-02-25 05:30, Even Rouault wrote: Hi, I motion to adopt RFC79: Listing of Service Providers on GDAL website: https://github.com/OSGeo/gdal/pull/3473 Starting with my +1 Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Driver maintenance - long-term solution ?
Thank you Howard for a great analysis and for pointing out the key problems. Personally I think the top two problems are: 1- Bus number: we need to find a way to increase the number of active maintainers to ensure the viability and velocity of the project 2- Sustainable revenue stream for maintenance activities: as you explained, it is relatively easy to fund features, but profitable companies selling software or services that use GDAL need to realize that it would be an investment for them to contribute even just a fraction of 1% of their sales in "non-string-attached funding" to support non-sexy stuff such as release management, bug fixes, security fixes, dependency upgrades, packaging, docs, etc... not only in GDAL, but in the top-5 open source components that they rely on. The QGIS approach to managing funding is an option, but it's not the only one. I would tend to go for a more decentralized approach to reduce the risk for the project with a single entity supporting it. I step up to work with you Howard toward improving the situation. (Actually I had already written personally to Even to discuss some options before seeing your reply) Daniel On 2021-01-13 12:33, Howard Butler wrote: Is there something fundamentally wrong with the current GDAL? The project's history is one person doing most of the work. This person eventually burns out. Here's a table of the top five lifetime commits to the repository as of December 2020. Even Rouault – 19,838 Frank Warmerdam – 11,503 Kurt Schwehr – 3,403 Andrey Kiselev – 1,320 Howard Butler – 768 The reason why this person burns out is they are actually doing *three* jobs, not one. Three, you say? First is the actual maintainer job. You're the clearinghouse for bugs, the primary authority on the mailing list, the first respondent in the bug tracker, and the one that organizes and cuts the software release. When we think of the maintainer for the GDAL project, this is what we think of. No one organization will pay for just this job. This means you need a revenue stream to make it maintenance your full time gig. That's easy enough, just get paid for working on GDAL, right? Well sure, but people don't want to pay for you to fix bugs that users vaguely provide in the mailing list. They want to pay for functionality they need to add to their software. So you are in a spot – you have to *add* more to the software to earn revenue. For GDAL, adding more means more drivers and more capabilities for those drivers (CPL, VSICloud, etc). This creates more bugs and maintenance load that the original directed funder supports for only a little while. This second job is in conflict with the first and the dissonance amplifies as time goes one. The third job is you have to solicit work through the contacts you've built up to keep the revenue hopper full. Invoicing, statements of work, negotiation, telecons, and the usual business stuff. People see you as cheap because you're "open source", and pressure you on price, scope, and completion time. You eventually orient about a small cadre of repeat clients with strong trust relationships. How can this be fixed? 1) Burn through the current maintainer and hope another one comes along. The users of the GDAL project simply got lucky that Even picked up the torch after Frank moved on. Maybe that happens again on the next iteration. 2) Refactor the software so that more maintainers can participate. That's been our current discussion, which doesn't seem to be converging on any solutions. 3) Provide a revenue stream so the maintainer only has to do the maintenance job, and not the other two jobs that are in conflict with the project's maintenance. This person should be paid like the FAANG senior engineer that's currently taking GDAL and using it to add some geo widget to their software. OSGeo was supposed to be the answer to #3, but in 15 years of existence it has shown it is not and never will be. Maybe it is time to start a GDAL foundation ala QGIS and others and direct corporate benefactors to fund it directly. Those benefactors would have to pledge significant resources to at least get to the level of a FAANG senior engineer as a start. Howard ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: promote GDAL 3.2.1 RC1
+1 Daniel On 2020-12-31 03:58, Even Rouault wrote: Hi, Having heard no issues being reported regarding RC1 Motion: Adopt GDAL 3.2.1 RC1 as final 3.2.1 release Starting with my +1 Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: adopt RFC 77 Drop Python 2 support in favor of Python 3.6
And I add my belated +1. Daniel On 2020-11-25 03:28, Even Rouault wrote: Hi, RFC 77: Drop Python 2 support in favor of Python 3.6 https://github.com/OSGeo/gdal/pull/3142 Starting with my +1 This motion is passed with +1 from PSC members HowardB, KurtS, JukkaR and myself Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: promote GDAL 3.2.0 RC1
+1 Daniel On 2020-10-29 04:55, Even Rouault wrote: Hi, Having heard about no critical ([1]) issues regarding RC1 Motion: Adopt GDAL 3.2.0 RC1 as final 3.2.0 release Starting with my +1 Even [1] The only regression I'm aware of currently is regarding the possibility to open raw LERC1 files in the MRF driver that is broken. See https://github.com/OSGeo/gdal/pull/3109 . A possibility I was hardly aware of. Can likely wait for 3.2.1 IMHO -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: promote GDAL 3.1.4 RC2
+1 Daniel On 2020-10-21 06:06, Even Rouault wrote: Hi, Motion: Adopt GDAL 3.1.4 RC2 as final 3.1.4 release Starting with my +1 Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: promote GDAL 3.1.3 RC1
+1 Daniel On 2020-09-03 04:45, Even Rouault wrote: Hi, Having heard no issues with RC1, Motion: Adopt GDAL 3.1.3 RC1 as final 3.1.3 release +1 Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: promote GDAL 3.1.1 RC1
+1 Daniel On 2020-06-25 06:18, Even Rouault wrote: Hi, Having heard no issues with RC1, Motion: Adopt GDAL 3.1.1 RC1 as final 3.1.1 release +1 Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: promote GDAL 3.1.0 RC3
+1 Daniel On 2020-05-05 05:39, Even Rouault wrote: Hi, Motion: promote GDAL 3.1.0 RC3 to final 3.1.0 Starting with my +1 Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: promote GDAL 3.1.0 RC2
On 2020-04-30 05:34, Even Rouault wrote: Hi, Having adressed the few issues raised about RC1, I believe RC2 is good to go. Motion: promote GDAL 3.1.0 RC2 to final 3.1.0 +1 Daniel -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: approve GDAL 3.0.4 RC1
+1 Daniel On 2020-01-28 05:48, Even Rouault wrote: Hi, The bug raised yesterday regarding the odd formulation of EPSG:3857 exported GeoTIFF files is quite annoying regarding interoperability, and we'd better stop generation of such odd files ASAP. Hence this release without prior notice. Both announcement of availability of release candidate and motion to adopt it Adopt GDAL 3.0.4 RC1 as final 3.0.4 release +1 Even ~ 3.0.4 RC1: Peek up an archive among the following ones (by ascending size): http://download.osgeo.org/gdal/3.0.4/gdal-3.0.4rc1.tar.xz http://download.osgeo.org/gdal/3.0.4/gdal-3.0.4rc1.tar.gz http://download.osgeo.org/gdal/3.0.4/gdal304rc1.zip A snapshot of the gdalautotest suite is also available : http://download.osgeo.org/gdal/3.0.4/gdalautotest-3.0.4rc1.tar.gz http://download.osgeo.org/gdal/3.0.4/gdalautotest-3.0.4rc1.zip GDAL-GRASS plugin (unmodified): http://download.osgeo.org/gdal/3.0.4/gdal-grass-3.0.4.tar.gz The NEWS file is here : https://github.com/OSGeo/gdal/blob/v3.0.4RC1/gdal/NEWS Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: request 2000 USD from OSGeo for GDAL
+1 Daniel On 2020-01-10 12:43, Kurt Schwehr wrote: +1 KurtS On Fri, Jan 10, 2020 at 9:43 AM Even Rouault <mailto:even.roua...@spatialys.com>> wrote: Hi, Motion: the GDAL project requests to OSGeo a 2000 USD budget for 2020 ~ +1 Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org <mailto:gdal-dev@lists.osgeo.org> https://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: adopt RFC 76 OGR Python drivers
+1 Daniel On 2019-11-13 09:22, Even Rouault wrote: Hi, I've updated both the RFC text and candidate implementation with the provided comments, so I think we are now good to vote on it. ~~ Motion: adopt RFC 76 OGR Python drivers: https://github.com/OSGeo/gdal/blob/7b7ecbab1e2b10ecab24e5126d94469d2d4efdc9/gdal/doc/source/development/rfc/rfc76_ogrpythondrivers.rst ~~ Starting with my +1, Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: approve GDAL 2.4.3RC1 and 3.0.2RC1 as final
+1 Daniel On 2019-10-31 07:08, Even Rouault wrote: Hi, A few issues [1] have been fixed since in those branches since the RCs, but they predated 2.4.0, so those new releases are not worse than their previous x.y.0, so I move to Motion: approve GDAL 2.4.3RC1 and 3.0.2RC1 as final +1 Even [1] - PDS: fix opening of datasets with BSQ organization (or single band), where one band is larger than 2 GB (2.3 regression) - IRIS: make identification more restrictive to avoid false-positive identification of raw binary formats such as ENVI (fixes #1961) - OGRLinearRing::isPointOnRingBoundary(): fix incomplete test that could falsely return true if the point was aligned with a segment, but not between the nodes. Impact correct reconstruction of holes in shapefile driver -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: spend 60 USD / year for extended GitHub LFS
+1 Daniel On 2019-10-08 06:49, Even Rouault wrote: Hi, This motion is to spend 5 USD/month * 12 = 60 USD annually to buy one "data pack" ([1]) to extend the quota of the OSGeo GitHub organization for LFS (Large File Storage) from 1 GB of storage + 1 GB /month of bandwith to 50 GB of storage + 50 GB/month of bandwidth This is within our yearly 5000 USD budget, for which we have already spent 4107.60 USD for Travis-CI The first & main beneficiary of this GitHub LFS extension will actually be the proj-datumgrid repository, that has just reached the bandwidth quota: https://github.com/OSGeo/proj-datumgrid/issues/57 ~~ My vote: +1 Even [1] https://help.github.com/en/articles/about-billing-for-git-large-file-storage -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Nomination of Mateusz Łoskot for the GDAL PSC
+1 Daniel On 2019-09-17 09:21, Howard Butler wrote: All, I would like to nominate Mateusz Łoskot to the GDAL PSC. Mateusz has been an active contributor to the GDAL project for nearly fifteen years. He was the very first paid maintainer for the project, closing bugs and running down issues, and his C/C++ expertise has helped the project evolve as it has moved to C++11. He is also very helpful with mailing list questions, and his experience and history with the project make him an excellent candidate for participating in the GDAL PSC. I'll start with a +1. Howard ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Nomination of Sean Gillies for the GDAL PSC
+1 Daniel On 2019-09-17 09:21, Howard Butler wrote: All, I would like to nominate Sean Gillies to the GDAL PSC. Sean leads the development of two important Python geospatial projects based on GDAL/OGR – rasterio and Fiona. He has contributed many bug reports and design ideas to GDAL while developing those libraries, and he brings nearly twenty years of active open source geospatial software contribution experience with him. His API sensibilities will continue provide invaluable direction and perspective going forward as GDAL continues to (slowly) evolve. I'll start with a +1. Howard ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motions: promote GDAL 2.4.2 RC1 and GDAL 3.0.1 RC1 to final
+1 to both. Daniel On 2019-07-03 05:15, Even Rouault wrote: Hi, Motion 1: promote GDAL 2.4.2 RC1 to final Motion 2: promote GDAL 3.0.1 RC1 to final ~ My votes: Motion 1: +1 Motion 2: +1 Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: adopt RFC 74: Migrate gdal.org to Sphinx
+1 Daniel On 2019-05-20 16:54, Even Rouault wrote: Hi, I believe we are now in a state where the prototype new website is functional and should have content at least equivalent to the current one, so I motion to adopt RFC74: Migrate gdal.org to Sphinx: https://trac.osgeo.org/gdal/wiki/rfc74_sphinx --- Starting with my +1 Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Add Norman Barker to GDAL PSC
+1 Daniel On 2019-05-15 09:03, Even Rouault wrote: Hi, I propose to add Norman Barker to the GDAL project steering committee. Norman has been active as a contributor to the GDAL project since more than 10 years and has contributed to various areas of the project, in particular the JPIPKAK driver and the progressive rendering API, the OGR Cloudand driver, the WEBP codec for GeoTIFF, and recently the TileDB driver. I believe he would be a good asset for the project. Motion: To add Norman Barker to the GDAL PSC. +1 from me. Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Promote GDAL 3.0.0 rc2 for release
+1 Daniel On 2019-05-07 05:19, Even Rouault wrote: Hi, Motion: GDAL/OGR 3.0.0 rc2 is promoted to be the official 3.0.0 final release. --- My vote: +1 Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Should the next version (previously 2.5) be called GDAL 3.0 ?
+1 to calling it 3.0 and to your proposed plan. Thank you Even. Daniel On 2019-05-01 14:56, Even Rouault wrote: Hi, As a feedback from the previous motion, it appears that GDAL 3.0 would probably better reflect the API & behaviour changes that have been done, and be in accordance with our HOWTO-RELEASE procedure and semantic versionning rules. I'm OK with that change. If we decide for that, the plan would probably be: - change in docs & other materials the references to 2.5 to 3.0 - create a release/3.0 branch from the HEAD of release/2.5 - abandon release/2.5 branch (that is: backports would be done in release/3.0, and for longer support in release/2.4 when appropriate) - issue a 3.0.0RC1 from that - call master 3.1dev Thoughts ? Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Promote GDAL 2.5.0 rc1 for release
I have been wondering about calling it 3.0 as well. How much communication about 2.5 are you alluding to? Is it more work to relay that 2.5 had a very short lifespan (i.e. never released) and then we went straight to 3.0, or to spend the next few years explaining why 2.4 and 2.5 are not compatible? On 2019-05-01 13:09, Even Rouault wrote: Sean, Did you give any more thought to calling this release 3.0 because of the breaking changes? Too late for that? Yes, that would be a bit annoying to rename it now, at least in terms of communication since GDAL 2.5 is already known to be the version with the SRS revamp. Would have been more appropriate to raise this at the time RFC 73 was discussed. Re-reading our HOWTO-RELEASE, we should indeed probably have named it GDAL 3.0. But even if we add kept the few functions that have been removed, the change of behaviour of a few ones is an interesting case of what is considered part of the API or not... Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Promote GDAL 2.4.1 rc1 for release
+1 Daniel On 2019-03-20 6:40 a.m., Even Rouault wrote: Hi, No issues were raised about this release candidate, so --- Motion: GDAL/OGR 2.4.1 rc1 is promoted to be the official 2.4.1 final release. --- My vote: +1 Best regards, Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Nearblack Eating Image Border
That's a great point. So it's not a bug, it is a feature in some cases. :) Maybe what we need is an option to switch between the two behaviors then. On 2019-02-20 8:23 a.m., Darafei "Komяpa" Praliaskouski wrote: I believe this behavior is great for over-compressed imagery JPEGs where you have corrupted border of several "black-poisoned" non-black pixels that you'd better remove and take from some other image in the mosaic, since in this scenario you usually have an overlap. On Wed, Feb 20, 2019 at 4:16 PM Daniel Morissette mailto:dmorisse...@mapgears.com>> wrote: I noticed this behavior as well and I think it's a bug. I think it would make more sense to keep the last "-nb" pixels that are not nearblack instead of dropping them. The effect is especially annoying when you have image tiles and you end up with a 1-2 pixels gap between them. I didn't test what happens if we change the behavior. So maybe there is a reason why it was implemented this way? Daniel On 2019-02-19 6:13 p.m., Christopher Mitchell wrote: > I've encountered an error in an image processing pipeline I've built > where nearblack is removing pixels at the border of images, even if > they don't fit the is-"black" criterion. Specifically, I'm using > nearblack to remove nearly-black areas touching the edges of lossy > image tiles that should be fully black. Those images are later > combined into VRT files and warped; where we have multiple tiles > overlapping an area, some of which are missing data, we therefore can > get complete coverage. > > Unfortunately, for tiles that have no black areas, nearblack is still > eating the -nb argument's number of pixels at the edges, turning them > into black (0, 0, 0, 0, where we're using 4-channel images), even if > those pixels are nowhere near the color criterion to be recognized as > black. My understanding was that nearblack should only be proceeding > into the interior of the non-black area and then setting pixels to > black if those pixels are /actually/ nearly black. > > Am I encountering a bug with nearblack? Do I misunderstand how the -nb > argument works? Happy to provide a MWE if any of the above is unclear, > and thanks in advance. > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org <mailto:gdal-dev@lists.osgeo.org> > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org <mailto:gdal-dev@lists.osgeo.org> https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Darafei Praliaskouski Support me: http://patreon.com/komzpa ___________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Nearblack Eating Image Border
I noticed this behavior as well and I think it's a bug. I think it would make more sense to keep the last "-nb" pixels that are not nearblack instead of dropping them. The effect is especially annoying when you have image tiles and you end up with a 1-2 pixels gap between them. I didn't test what happens if we change the behavior. So maybe there is a reason why it was implemented this way? Daniel On 2019-02-19 6:13 p.m., Christopher Mitchell wrote: I've encountered an error in an image processing pipeline I've built where nearblack is removing pixels at the border of images, even if they don't fit the is-"black" criterion. Specifically, I'm using nearblack to remove nearly-black areas touching the edges of lossy image tiles that should be fully black. Those images are later combined into VRT files and warped; where we have multiple tiles overlapping an area, some of which are missing data, we therefore can get complete coverage. Unfortunately, for tiles that have no black areas, nearblack is still eating the -nb argument's number of pixels at the edges, turning them into black (0, 0, 0, 0, where we're using 4-channel images), even if those pixels are nowhere near the color criterion to be recognized as black. My understanding was that nearblack should only be proceeding into the interior of the non-black area and then setting pixels to black if those pixels are /actually/ nearly black. Am I encountering a bug with nearblack? Do I misunderstand how the -nb argument works? Happy to provide a MWE if any of the above is unclear, and thanks in advance. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: adopt RFC 73: Integration of PROJ6 for WKT2, late binding capabilities, time-support and unified CRS database
+1 Daniel On 2019-01-26 6:46 a.m., Even Rouault wrote: Hi, I move to adopt RFC 73: Integration of PROJ6 for WKT2, late binding capabilities, time-support and unified CRS database https://trac.osgeo.org/gdal/wiki/rfc73_proj6_wkt2_srsbarn It has been minorly edited since the first version to reflect the evolutions on the default WKT version: - exportToWKT() without options, exporting to WKT1 by default (except for Geographic3D CRS where WKT2:2018 will be used). Can be overriden by the OSR_WKT_FORMAT configuration option - gdalinfo, ogrinfo, gdalsrsinfo reporting SRS as WKT2:2018 by default Starting with my +1 Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Promote GDAL 2.4.0 rc1 for release
+1 Daniel On 2018-12-19 8:11 a.m., Even Rouault wrote: Hi, Motion: GDAL/OGR 2.4.0 rc1 is promoted to be the official 2.4.0 final release. --- My vote: +1 --- I didn't have any feedback on this one, so I assume things go well. Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Promote GDAL 2.3.3 rc2 for release
+1 Daniel On 2018-12-18 6:35 a.m., Even Rouault wrote: Hi, Motion: GDAL/OGR 2.3.3 rc2 is promoted to be the official 2.3.3 final release. --- My vote: +1 --- Note: https://github.com/OSGeo/gdal/issues/1156 was raised yesterday. Would have been good if it had been in 2.3.3 but I don't really feel like doing another RC for that, so that will be for 2.4.1 Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: adopt RFC 72: Run tests with pytest
+1 Daniel On 2018-12-07 6:15 a.m., Even Rouault wrote: PSC members, gentle reminder to cast your vote on this. Thanks, Even Hi I appreciate your comments on the pytest proposal and all the support to help get it this far. Given no actionable improvements have been suggested, and the feedback thus far seems encouraging... I move to adopt RFC 72: Run tests with pytest. https://trac.osgeo.org/gdal/wiki/rfc72_pytest Cheers Craig de Stigter -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Early GDAL 2.4.0 release ?
+1 for me. I like your plan. Daniel On 2018-11-27 11:59 a.m., Even Rouault wrote: Hi, I've been considering an early GDAL 2.4.0 release for the end of this year instead of the traditionnal mid-April / May target. The rationale is that the work related to the GDAL/PROJ SRS revamp effort (aka "GDAL barn": https://gdalbarn.com/) will probably require non-null integration work from GDAL users, which will unnecessarily delay the "time-to-market" of features currently in GDAL master. I've just began integrating the PROJ changes in a GDAL branch of mine and the current and future changes can be classified in the following categories: - for sure: behaviour changes. exportToWKT() / exportToProj4() will for example return different strings. Most of the time equivalent, but nonetheless different, which can break other software unit tests - probable: some OGRSpatialReference methods / OSR functions might be removed, or become no-operation - uncertain at this point: impact of being axis order and unit compliant with the CRS definition from the authority. I'd like the GDAL 2.5.0 release that will integrate the GDAL barn work to still be scheduled for mid-April / May date, and with my branch being hopefully ready for being merged into master in January. A temptative schedule for 2.4.0 might be: - December 14th: GDAL 2.4.0RC1 (I believe master is mature enough to go to RC stage directly, with no/very few changes affecting backward compatibility, but this is just from memory. The updated NEWS would help to confirm, but creating it is the bulk of the release work), likely coupled with a GDAL 2.3.3RC1 that would be the final point release for the GDAL 2.3 series - December 21th: GDAL 2.4.0final Thoughts ? Ah, and the release manager role is still open for volunteers (or any help, particularly updating NEWS, would be appreciated) Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Promote GDAL 2.3.2 rc1 for release
+1 Daniel On 2018-09-26 3:13 AM, Even Rouault wrote: Hi, Motion: GDAL/OGR 2.3.2 rc1 is promoted to be the official 2.3.2 final release. --- My vote: +1 Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Promote GDAL 2.3.1 rc2 for release
+1 Daniel On 2018-06-25 9:18 AM, Even Rouault wrote: Hi, Motion: GDAL/OGR 2.3.1 rc2 is promoted to be the official 2.3.1 final release. --- My vote: +1 Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Promote GDAL 2.3.0 RC1 for release
+1 Daniel On 2018-05-09 2:58 AM, Even Rouault wrote: Hi, No critical issues have been raised on RC1, so --- Motion: GDAL/OGR 2.3.0 RC1 is promoted to be the official 2.3.0 final release. --- My vote: +1 -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: promote GDAL 2.2.4 RC1 for release
+1 Daniel On 2018-03-21 6:28 AM, Even Rouault wrote: Motion: promote GDAL 2.2.4 RC1 for release Friendly nudge to PSC members to please cast their votes. Even -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Adopt RFC 70: Guessing output format from output file name extension
+1 Daniel On 2017-11-15 10:07 AM, Even Rouault wrote: Hi, I move to adopt RFC 70: Guessing output format from output file name extension https://trac.osgeo.org/gdal/wiki/rfc70_output_format_guess Starting with my +1, Best regards, Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: grant commit rights to Alan Thomas
+1. Great to have someone around to look after DXF stuff. Daniel On 2017-11-01 5:48 AM, Even Rouault wrote: Hi PSC, Alan has done in the last months a lot of great work (fixes and improvements) in the DXF driver, including adding new test cases and updating documentation when needed: https://trac.osgeo.org/gdal/ticket/7111 https://trac.osgeo.org/gdal/ticket/7106 https://trac.osgeo.org/gdal/ticket/7098 https://trac.osgeo.org/gdal/ticket/7105 https://trac.osgeo.org/gdal/ticket/7099 https://trac.osgeo.org/gdal/ticket/7089 https://trac.osgeo.org/gdal/ticket/7038 https://trac.osgeo.org/gdal/ticket/7006 https://trac.osgeo.org/gdal/ticket/6971 And there are more to come: https://trac.osgeo.org/gdal/ticket/7120 https://trac.osgeo.org/gdal/ticket/7121 https://trac.osgeo.org/gdal/ticket/7122 So it would be more convenient to grant him direct commit rights. Motion: grant commit rights to Alan Thomas +1 Even ~ Alan, could you reply to the list confirming that you agree on https://trac.osgeo.org/gdal/wiki/rfc3_commiters Best regards, Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: promote GDAL 2.2.2 RC1 for release
On 2017-09-20 7:01 AM, Even Rouault wrote: Hi, Motion: GDAL/OGR 2.2.2 RC1 is promoted to be the official 2.2.2 release. +1 Daniel -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] git(hub) migration ?
Whatever option we go with, I agree that it is important to maintain the full history of code and tickets. In addition to the "svn blame" example that Even gave, being able to track the provenance of each line of code is also good practice for legal reasons. Daniel On 2017-09-06 2:40 PM, Even Rouault wrote: On mercredi 6 septembre 2017 21:16:46 CEST Dmitry Baryshnikov wrote: > Hi Even, > > I think this is great proposal. Github is modern tool for develop, code > review and test software. > > I like idea to migrate code and tickets (3). Not sure we need to migrate > closed tickets. I'd wish closed tickets to be migrated as well (I don't think this is more complicated to migrate both opened+closed tickets than just opened tickets). More than once I had to "svn blame" and was happy to be able to find a reference to a >10 year old ticket that gives some context for a change. Tickets are true assets of a project (at least for the developpers) (I was thinking to suggest the "fossil" SCM (*) which has the big advantage of including tickets in the repository, but of course we would miss the increased social collaboration aspect with such a choice :-)) > Also it worth thinking to migrate only the 2.x code > tree. I'd like the whole history to be preserved in the migration. > There are not so many releases in 2.x, so branches can be convert > to tags manually. We could indeed probably create the tags manually without recreating the whole clone. > > Anyhow you made me thinking about this. > By the way this work may be the subject of GSoC 2018 (not sure if this > allowed by program). I don't think that would be appropriate for GSoc which requires coding for a project. Infrastructure work like this is not allowed AFAIK. Even (*) https://www.fossil-scm.org/xfer/doc/trunk/www/index.wiki -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption
On 2017-09-06 12:14 PM, Kurt Schwehr wrote: Now that Tamas has added the msvc2015/2-17SDK's, I'd like to call a vote by the PSC on RFC68: C++11 compilation mode. The draft is here: https://trac.osgeo.org/gdal/wiki/rfc68_cplusplus11 -Kurt +0 It's not clear to me that the benefits of the C++11 requirement justify the potential trouble for those who have to support platforms with older compilers. I do care about portability, it was one of the founding principles of the project 20 years ago and I do not think that "stick to GDAL 2.2" is an acceptable answer to the portability question. The fact that other SDKs or apps may have the C++11 requirement is also not a justification in my mind either for a core piece as important as GDAL. That being said, I don't think I will be directly affected by the change, and there seem to be enough contributors who are keen on dealing with this that I do not need to worry about the problems and should not block progress. Daniel -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motions: Promote 2.1.4RC1 and 2.2.1RC1 for release
+1 Daniel On 2017-06-28 4:47 AM, Even Rouault wrote: Hi, Motion 1: GDAL/OGR 2.1.4RC1 is promoted to be the official 2.1.4 release. Motion 2: GDAL/OGR 2.2.1RC1 is promoted to be the official 2.2.1 release. --- +1 to both: Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Promote GDAL 2.2.0 RC1 for release
+1 Daniel On 2017-05-04 5:36 AM, Even Rouault wrote: Hi, No critical issues have been raised on RC1, so --- Motion: GDAL/OGR 2.2.0 RC1 is promoted to be the official 2.2.0 final release. --- My vote: +1 Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Adopt RFC 67 Null values in OGR
+1 Daniel On 2017-02-07 11:49 AM, Even Rouault wrote: Hi, I move to adopt RFC 67: Null values in OGR https://trac.osgeo.org/gdal/wiki/rfc67_nullfieldvalues Starting with my +1, Best regards, Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Promote 2.1.3RC1 for release
On 2017-01-25 3:27 AM, Even Rouault wrote: Motion: GDAL/OGR 2.1.3RC1 is promoted to be the official 2.1.3 final release. +1 Daniel -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: adopt RFC 64: Triangle, Polyhedral surface and TIN
Thank you for the clarification. Since those changes are useful by themselves then I change my vote to +1 Daniel On 2016-12-14 10:19 AM, Even Rouault wrote: On mercredi 14 décembre 2016 10:05:46 CET Daniel Morissette wrote: +0 as I'm wondering if there could be a better way to handle this, i.e. it's not clear to me how useful it is to read/write those new geometry types without maintaining the (topological?) relationships between the objects. I am no expert with that type of data structures so my concerns may be completely invalid too and I have no alternative to offer, hence my +0. The Simple Feature model clearly doesn't maintain topological relationships. Topological consistency must be checked in a later stage with a IsValid() call for example (this also holds true for already handled geometry types). And if you look at some drivers that implement TIN currenlty like PostGIS or GML, they are based on the Simple Feature model as well. Only shapefile/filegdb has something a bit stronger with shared nodes. I think that support for topological geometries would be a completely different concept to be added in OGR. Would require management of nodes, edges and faces, and conversions between simple feature geometries and topogeometries. I had some preliminary discussions about that with an interested party in the past but they didn't go further. In the current state of things, the TIN support should be hopefully good enough for conversions between PostGIS, GML, DXF and shapefile/filegdb. Even Daniel On 2016-12-13 1:13 PM, Even Rouault wrote: > On vendredi 9 décembre 2016 12:10:25 CET Even Rouault wrote: >> Hi, >> >> >> >> There have been some good remarks, one regarding integration with GEOS > > that > >> I've taken into account in the implementation, another one regarding the >> >> possibility to get indexed TIN that I think can be later added if needed. >> >> >> >> So I move to adopt RFC 64: Triangle, Polyhedral surface and TIN >> >> >> >> https://trac.osgeo.org/gdal/wiki/rfc64_triangle_polyhedralsurface_tin >> >> >> >> Starting with my +1, > > Friendly remainder that this motion is under vote. > > > > 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 -- 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 -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: adopt RFC 64: Triangle, Polyhedral surface and TIN
+0 as I'm wondering if there could be a better way to handle this, i.e. it's not clear to me how useful it is to read/write those new geometry types without maintaining the (topological?) relationships between the objects. I am no expert with that type of data structures so my concerns may be completely invalid too and I have no alternative to offer, hence my +0. Daniel On 2016-12-13 1:13 PM, Even Rouault wrote: On vendredi 9 décembre 2016 12:10:25 CET Even Rouault wrote: Hi, There have been some good remarks, one regarding integration with GEOS that I've taken into account in the implementation, another one regarding the possibility to get indexed TIN that I think can be later added if needed. So I move to adopt RFC 64: Triangle, Polyhedral surface and TIN https://trac.osgeo.org/gdal/wiki/rfc64_triangle_polyhedralsurface_tin Starting with my +1, Friendly remainder that this motion is under vote. 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 -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Planning code sprint in Daytona Beach, FL (please vote on dates if interested)
(I apologize in advance for the cross-posting.) We are considering holding the annual "C Tribe" Code Sprint in Daytona Beach, FL and are currently considering two dates. If you are interested in attending, then please confirm your interest and the dates that work for you in this Doodle. We will keep the doodle open until early next week: http://doodle.com/poll/vyyew4ibbwcdp6ka You can find out more about the plan as it evolves in the wiki: https://wiki.osgeo.org/wiki/Daytona_Beach_Code_Sprint_2017 and follow the full discussion on the "tosprint" list: https://lists.osgeo.org/pipermail/tosprint/2016-November/000644.html * Note that the "C Tribe Sprint" is labelled this way only for historical reasons since and is really open to all "tribes". The goal is cross-project collaboration and all OSGeo projects are invited. Daniel ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: adopt RFC 65: IETF RFC7946 GeoJSON
+1 Daniel On 2016-10-29 9:02 AM, Even Rouault wrote: Hi, I move to formally adopt RFC 65: IETF RFC7946 GeoJSON https://trac.osgeo.org/gdal/wiki/rfc65_rfc7946_geojson The implementation has been committed into trunk the past days. --- Starting with my +1 Even -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Promote 2.1.2RC4 for release
On 2016-10-25 4:39 AM, Even Rouault wrote: Motion: GDAL/OGR 2.1.2RC4 is promoted to be the official 2.1.2 final release. +1 Daniel -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: adopt RFC 66: OGR random layer read/write capabilities
+1 Daniel On 2016-10-05 6:44 AM, Even Rouault wrote: Hi, I know that Howard has expressed some concerns regarding the potential confusion that this could add, but I'm not sure what better alternatives there would be to address the needs it tries to solve. So I move to adopt RFC 66: OGR random layer read/write capabilities https://trac.osgeo.org/gdal/wiki/rfc66_randomlayerreadwrite --- Starting with my +1 Even -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: adopt RFC 63 : Sparse datasets improvements
On 2016-07-26 11:00 AM, Even Rouault wrote: Hi, I move to adopt RFC 63 : Sparse datasets improvements https://trac.osgeo.org/gdal/wiki/rfc63_sparse_datasets_improvements --- Starting with my +1 Even +1 on the overall idea and proposed solution. +0 on the implementation details as I'm not the most qualified to comment on those details. -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Tickets that mention e00
On 2016-07-26 9:17 AM, Even Rouault wrote: On Tuesday 26 July 2016 07:08:02 Jukka Rahkonen wrote: Hi, I wonder how likely it is that the tickets dealing with Arc/Info coverages http://www.gdal.org/drv_avce00.html will still receive some bug fixes. Would it be a big mistake to close them all as won't fix? Hi Jukka, unless a maintainer pops up, that sounds like an appropriate action. Even Agreed. BTW, if it helps we could move the upstream AVCBin/AVCE00 source to github so that Even and others GDAL devs can update them. Daniel -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motions: Promote 1.11.5 RC 1, 2.0.3 RC2 and and 2.1.1 RC2 for release
+0 on all three. I didn't have a chance to fully test, but I'm very supportive. Daniel On 2016-07-08 6:02 AM, Even Rouault wrote: Hi, Motions under vote: Motion 1: GDAL/OGR 1.11.5 RC1 is promoted to be the official 1.11.5 final release. Motion 2: GDAL/OGR 2.0.3 RC2 is promoted to be the official 2.0.3 final release. To replace the retracted motion 3: Motion 3bis: GDAL/OGR 2.1.1 RC2 is promoted to be the official 2.1.1 final release. -- My votes : Motion 1: + 1 Motion 2: + 1 Motion 3bis: + 1 Best regards, Even -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Spatial index to raster VRT
On 2016-05-26 8:40 AM, Jukka Rahkonen wrote: Hi, Any thoughts about alternatives to implement the feature request from https://trac.osgeo.org/gdal/ticket/5762? What I dream of is to be able to utilize all the nice on-the-fly tweaks that can be done with VRT at similar speed that Mapserver is reaching with tileindex. That would be a nice enhancement. As usual I guess we need a champion and/or some funding to make this happen. I came across a similar use case not long ago and realized that to get top performance at all zoom levels we'd also need the ability to associate overviews with the VRT. I didn't check if creating external overviews with gdaladdo would work for a VRT already. Maybe it does? -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Promote 2.1.0RC4 for release
On 2016-04-27 4:18 AM, Even Rouault wrote: Motion: GDAL/OGR 2.1.0RC4 is promoted to be the official 2.1.0 final release. +1 Daniel -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Committer Status for Lucian Plesea
+1 Daniel On 2016-02-23 7:10 PM, Even Rouault wrote: Motion: Committer Status for Lucian Plesea --- Dear PSC, Lucian is the maintainer of the MRF (Meta Raster Format) driver who has existed as an out-of-tree driver and whose main repository is at https://github.com/nasa-gibs/mrf . Recently I've worked with him to get the driver also integrated in the GDAL tree itself, and he merged back the changes in the above mentionned repository, so that both code base are now in sync. For the future, it would be convenient if Lucian could directly maintain the GDAL copy directly and keep in sync both repositories, so I motion to grant him commit rights. Lucian scope of interest also includes the WMS driver. I'll start the voting with: +1 Even Lucian, Please, could you answer to this message and state that you have read and agreed to the committer guidelines as outlined in the RFC3 ( http://trac.osgeo.org/gdal/wiki/rfc3_commiters ) -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Fwd: [OSGeo-Discuss] [@Mentors: Action required] GSoC 2016 Ideas page
On 2016-02-19 9:12 AM, Even Rouault wrote: Le vendredi 19 février 2016 15:01:05, Daniel Morissette a écrit : I've added my own wish: M support in GPX driver and other formats which support M dimension. Hi Daniel, That's actually a topic I wanted to address partly for the code sprint : https://wiki.osgeo.org/wiki/Paris_Code_Sprint_2016_:_GDAL_Agenda Ha! I wasn't aware of that. That's even better. :-) For GPX, I guess M would hold the time information ? Presumably as a unix time since we are bound to double values. Um... you're right, good point. I didn't think of the fact that the M was stored in a float. I guess using unix time it will have to be. Let's talk about that at the code sprint next week. -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Fwd: [OSGeo-Discuss] [@Mentors: Action required] GSoC 2016 Ideas page
On 2016-02-19 1:48 AM, Ari Jolma wrote: 19.02.2016, 03:42, Even Rouault kirjoitti: Le mardi 16 février 2016 11:28:33, Even Rouault a écrit : Hi, Potential mentors and students: time to update https://trac.osgeo.org/gdal/wiki/SummerOfCode To help resolving the blank page syndrome, I've drafted, with heterogeneous level of details, a few ideas : https://trac.osgeo.org/gdal/wiki/SummerOfCode Edit, add your owns, or kill the bad ones. I've added a few. A wish list. I've added my own wish: M support in GPX driver and other formats which support M dimension. -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC 61: Call for vote on adoption
On 2016-02-05 3:04 AM, Ari Jolma wrote: I'd like to ask the PSC and others to vote on adopting RFC 61: Support for measured geometries. The draft RFC is at https://trac.osgeo.org/gdal/wiki/rfc61_support_for_measured_geometries +1 Daniel -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motions: Promote 1.11.4 RC2 and 2.0.2 RC4 for release
+1 on both. Daniel On 2016-01-27 5:29 AM, Even Rouault wrote: Hi, Motion 1: GDAL/OGR 1.11.4 RC2 is promoted to be the official 1.11.4 final release. Motion 2: GDAL/OGR 2.0.2 RC4 is promoted to be the official 2.0.2 final release. -- My votes : Motion 1: + 1 Motion 2: + 1 Best regards, -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Commit access to David Adler
+1 Daniel On 2015-12-02 5:04 PM, Mateusz Loskot wrote: Motion: Committer Status for David Adler --- Dear PSC, David is preparing contribution of new OGR driver for DB2 [1]. I would like to propose motion to grant the SVN commit access to David Adler. This will help David to support any new features or changes and allow 'streamline' maintenance of the DB2 driver. David has demonstrated necessary knowledge of GDAL/OGR code base, despite the new driver currently targets Windows platform, he is willing to continue development and support targeting Linux as well. David is a very experienced developer, specialised in IBM DB2 technologies. I have met David in person some time ago. I'm not a PSC member, but in this particular case I feel eligible to start voting with symbolic +1. David, Please, could you answer to this very message and state that you have read and agreed to the committer guidelines as outlined in the RFC3 [2]. [1] https://trac.osgeo.org/gdal/ticket/6191 [2] http://trac.osgeo.org/gdal/wiki/rfc3_commiters Best regards, -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Call for discussion on RFC 60: Improved round-tripping in OGR
the original query, and more.
When I pipe this through ogr2ogr to spatially filter, here are the
results:
$ curl
https://api.mapbox.com/v4/geocode/mapbox.places/1600+pennsylvania+ave+nw.json?access_token=$MAPBOX_ACCESS_TOKEN
| ogr2ogr -clipsrc -100 30 -70 60 -f GeoJSON /vsistdout/ /vsistdin/
{
"type": "FeatureCollection",
"crs": { "type": "name", "properties": { "name":
"urn:ogc:def:crs:OGC:1.3:CRS84" } },
"features": [
{ "type": "Feature", "properties": { }, "geometry": { "type":
"Point", "coordinates": [ -77.034389, 38.897693 ] } },
{ "type": "Feature", "properties": { }, "geometry": { "type":
"Point", "coordinates": [ -76.634388, 39.30307 ] } },
{ "type": "Feature", "properties": { }, "geometry": { "type":
"Point", "coordinates": [ -80.272062, 40.687045 ] } },
{ "type": "Feature", "properties": { }, "geometry": { "type":
"Point", "coordinates": [ -95.54508, 34.841595 ] } }
]
}
The extensions are lost. This means that ogr2ogr can't be used in
pipelines that process extended GeoJSON.
If you want your GeoJSON to pass through OGR in high fidelity, you
have to put everything in the Feature.properties object no matter
whether that's the best place for it or not. In practice, the
Feature.properties object becomes a grey goo of feature attributes,
styling properties, and you name it.
The implementation of RFC 60 would pass through GeoJSON extensions
in full hi-fi. OGR will no longer be an impediment to extension
developers.
[1] http://wiki.openstreetmap.org/wiki/Overpass_turbo/GeoJSON
[2] https://github.com/mapbox/carmen/blob/master/carmen-geojson.md
Yours,
On Wed, Sep 23, 2015 at 9:29 AM, Even Rouault
<even.roua...@spatialys.com <mailto:even.roua...@spatialys.com>> wrote:
Hi,
This is a call for discussion on "RFC 60: Improved
round-tripping in OGR".
https://trac.osgeo.org/gdal/wiki/rfc60_improved_roundtripping_in_ogr
This RFC defines how to improve better round-tripping in
conversion of vector
formats, in particular for GeoJSON extensions.
Best regards,
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org <mailto:gdal-dev@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org <mailto: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
--
Daniel Morissette
http://www.mapgears.com/
T: +1 418-696-5056 #201
http://evouala.com/ - Location Intelligence Made Easy
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Add Kurt Schwehr to GDAL PSC
+1 Daniel On 2015-10-07 4:54 PM, Even Rouault wrote: Hi, I propose to add Kurt Schwehr to the GDAL project steering committee. Kurt has been a committer for 2 years, and over the last few months has substantially increased his level of involvment, mainly in the area of improving code quality, going through the Coverity Scan database of code defects, other code cleanups, test suite improvements, ... He has also confirm his interest in long term involvment in the project. I believe he would be a good asset for the project. Motion: To add Kurt Schwehr to the GDAL PSC. +1 from me. Best regards, Even -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Adopt RFC 59.1: GDAL/OGR utilities as a library
On 2015-09-29 6:45 AM, Even Rouault wrote: Hi, Since no remarks have been done on the latest proposal, I move to adopt RFC 59.1: GDAL/OGR utilities as a library https://trac.osgeo.org/gdal/wiki/rfc59.1_utilities_as_a_library +1 Daniel -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Looking for info on ADS/ODF imagery format
Hi everyone, I have been sent an imagery dataset in what looks like an ADS imagery format, and to my great surprise, it does not seem to be supported by GDAL. The dataset is a directory starting with a set of header files 15_20140507_1441_RGBNN00L1.ads 15_20140507_1441_RGBNN00L1.hist 15_20140507_1441_RGBNN00L1.min 15_20140507_1441_RGBNN00L1.odf 15_20140507_1441_RGBNN00L1.odf.adj 15_20140507_1441_RGBNN00L1.sup 15_20140507_1441_RGBNN00L1.xml and with a set of 84 TIF files with filenames as follows: 15_20140507_1441_RGBNB19L1_0_0.tif to 15_20140507_1441_RGBNB19L1_0_84.tif The TIF files appear to be adjacent tiles of 4096x20660 pixels each, but unfortunately there is no georeferencing info in any of the TIF files, and I do not find any useful georeferencing or origin coordinates info in any of the readable header files either. Well, I can tell in which UTM projection/zone the data is, but all coordinate values are zeros for the tile references in the XML header files. The only info I can find on the Net is here: http://www.pcigeomatics.com/geomatica-help/references/pcifunction_r/modeler/m_cdads.html which suggests that the .odf file contains "position and orientation data". Of course, I tried a quick binary dump of the .odf file but it is quite large (12MB) and I do not see anything obvious at first sight. Does anybody know how to deal with that format, or how I can extract location information for the TIF files out of that .ODF file? Thanks in advance -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motions: Promote 1.11.3 RC2 and 2.0.1 RC1 for release
On 2015-09-21 6:27 AM, Even Rouault wrote: Hi, Saving a few bits, 2 motions in one email: Motion 1: GDAL/OGR 1.11.3 RC2 is promoted to be the official 1.11.3 final release. +1 Motion 2: GDAL/OGR 2.0.1 RC1 is promoted to be the official 2.0.1 final release. +1 Daniel -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] 2.0.1 (and 1.11.3) release schedule ?
On 2015-08-19 6:56 AM, Jukka Rahkonen wrote: Even Rouault even.rouault at spatialys.com writes: Hi, I was wondering if we couldn't prepare RCs of 2.0.1 and 1.11.3 for the week of September 14th. That would be 3 months after 2.0.0 release. There are ~ 30 tickets closed in both branches. Nothing dramatically critical I can think of, but going beyond the .0.0 of 2.0.0 will probably make it more psychologically attractive for wider adoption. Does that sound OK ? Anybody interested in tackling that ? Otherwise I guess I have some idea for a volunteer... +1 for making releases. I doubt you get too many volunteers, for our team even casting votes is sometimes too heavy a task. +1 for the release and another +1 for the volunteer you have in mind. -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Adopt RFC 26: GDAL Block Cache Improvements
On 2015-06-23 10:06 AM, Even Rouault wrote: Le vendredi 19 juin 2015 09:52:30, Even Rouault a écrit : Hi, As no points have been raised on the RFC: Motion : I move to adopt RFC 26: GDAL Block Cache Improvements https://trac.osgeo.org/gdal/wiki/rfc26_blockcache Starting with my +1 Hi, Just a reminder this motion is still under vote (with only one voter, me excluded, up to now). Even +1. I can't claim that I understood all the implementation details, but since it solves a significant issue with large datasets without introducing new side-effects then I'm all for it. -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Promote 2.0.0RC2 for release
+1 Daniel On 2015-06-18 5:26 AM, Even Rouault wrote: Le mardi 16 juin 2015 10:02:37, Even Rouault a écrit : Motion: GDAL/OGR 2.0.0RC2 is promoted to be the official 2.0.0 final release. --- No critical issue has been reported on RC2 so far, so I invite PSC members to vote on this motion after doing your own testing and validation. Input from everyone else who can test it is also very welcome. I'll start the voting with my : +1 Even Technically, there's only +1 from Jukka and myself on this motion after 2 business days. I'd appreciate more votes from other PSC members. Even -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: adopt RFC 58: Removing Dataset Nodata Value
+1 Daniel On 2015-06-03 8:01 AM, Howard Butler wrote: On Jun 3, 2015, at 4:13 AM, Even Rouault even.roua...@spatialys.com wrote: Hi, As no points have been raised on the RFC itself (peripheral discussions on how to address out-of-range nodata values) : Motion : I move to adopt RFC 58: Removing Dataset Nodata Value https://trac.osgeo.org/gdal/wiki/rfc58_removing_dataset_nodata_value Starting with my +1 +1 Howard ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] MotionS: adopt RFC 56 and RFC 57
+1 for both RFC 56 and RFC 57. Daniel On 2015-04-09 2:39 PM, Even Rouault wrote: Hi, Motion 1 : I move to adopt RFC 56: OFTTime/OFTDateTime millisecond accuracy https://trac.osgeo.org/gdal/wiki/rfc56_millisecond_precision Starting with my +1 - Motion 2: I move to adopt RFC 57: 64-bit bucket counts for histograms https://trac.osgeo.org/gdal/wiki/rfc57_histogram_64bit_count Starting with my +1 Best regards, Even -- Daniel Morissette T: +1 418-696-5056 #201 http://www.mapgears.com/ Provider of Professional MapServer Support since 2000 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC 57: 64-bit bucket counts for histograms
Hi Even, No comment on the actual change which sounds fine to me. However, could we add a Version: ... field to the header of RFCs to make it easier to track down the version to which a RFC applies? I saw that you indicate the version in the status field after a RFC has been implemented, but while it's in draft and during the discussion phase there is no indication of the target version. In this specific case, I presume it is a V2.0 change since it breaks API/ABI compatibility, right? Same comment for the Date/Time RFC that was discussed earlier this week. Thanks Daniel On 2015-04-07 3:33 PM, Even Rouault wrote: Hi, This is a call for discussion on 64-bit bucket counts for histograms (last one for today ;-) and hopefully a no-brainer) https://trac.osgeo.org/gdal/wiki/rfc57_histogram_64bit_count Summary : This RFC modifies the GDALRasterBand GetHistogram(), GetDefaultHistogram() and SetDefaultHistogram() methods to accept arrays of 64-bit integer instead of the current arrays of 32-bit integer for bucket counts. This will fix issues when operating on large rasters that have more than 2 billion pixels. Even -- Daniel Morissette T: +1 418-696-5056 #201 http://www.mapgears.com/ Provider of Professional MapServer Support since 2000 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC 57: 64-bit bucket counts for histograms
On 2015-04-08 10:05 AM, Even Rouault wrote: Daniel, No comment on the actual change which sounds fine to me. However, could we add a Version: ... field to the header of RFCs to make it easier to track down the version to which a RFC applies? I saw that you indicate the version in the status field after a RFC has been implemented, but while it's in draft and during the discussion phase there is no indication of the target version. Sure, added Thanks. That will help. FYI I added a missing [[BR]] in the header. -- Daniel Morissette T: +1 418-696-5056 #201 http://www.mapgears.com/ Provider of Professional MapServer Support since 2000 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] UFO format / GDAL 3.0
Good morning Even, That sounds like an ambitious world (universe?) domination plan, but before going too deep into the implementation details, can you comment on the potential for real life widespread adoption of such a universal format in a world where everyone and their dog wants to have their own file format which is so much better than everybody else's? In other words: GML failed in a similar attempt to replace all other formats, so despite the benefits of BF over XML encoding, what would give UFO more chances of succeeding? Have a nice ... day. Daniel On 2015-04-01 8:16 AM, Even Rouault wrote: Hi, Since some time a few ideas came to my mind and I felt today was a good one to share them and get feedback. Considering the never ending proliferation of GIS file formats, currently 220 handled in GDAL trunk, it seems wise to put an end to it. Especially since the counter used to iterate over the drivers is a unsigned 8 bit, so we will soon be unable to add more, or at the expense of sacrificing our ports to Intel 8008 or Motorola 6800, which would be pretty sad. Therefore I'd like to propose the UFO format, which stands for Universal Format Oh-yeaaah! The basic idea of UFO is that it isn't a fixed format, but a varying and self- described one. XML (or perhaps EXI?) + XSD + XSLT + XPath + Schematron could probably do it, but for efficiency I thought to a byte-code interpreted by libgdal and whose interface with libgdal would match the GDAL driver interface. So basically each dataset would contain its own driver. The big plus is that you could write image translators that would generate binary encodings optimized for the particular dataset being encoded: for example, it is kind of stupid to write the values of each pixel of a Mandelbrot fractal whereas its mathematical description fits into a few lines of code. Furthermore, still pursuing with that example, we could even have raster of arbitrary resolution, since that's a characteristics of fractals. And many GIS datasets have indeed fractal charasterics, such as coastlines ( http://en.wikipedia.org/wiki/Coastline_paradox ) For security reason, we should aim at supporting only simple verifiable languages, so Brainfuck (Brainf**k for the most puritans of us) seems to be a good fit : http://en.wikipedia.org/wiki/Brainfuck. Basically it is a Turing complete language with only 8 commands. So as much powerful as needed, while being very easy to learn and implement. To save some efforts, I'd humbly suggest we adopt libbf ( http://savannah.nongnu.org/projects/libbf ), an older project of mine that also incorporates a on-the-fly optimizer compiler for most popular architectures. The plan would be to have an initial version of the UFO driver ready for GDAL 2.0 and push strongly for its widespread adoption in all GIS, remote sensing, OSS proprietary vendors, etc Perhaps we should establish a dedicated workgroup at OGC to make it a standard ? Then we could deprecate and remove all existing drivers and at the time of GDAL 3.0, UFO would be the only one remaining driver, making the Intel 8008 port very happy! Happy to hear from your thoughts before formalizing that as a RFC, Even -- Daniel Morissette T: +1 418-696-5056 #201 http://www.mapgears.com/ Provider of Professional MapServer Support since 2000 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
