Re: [gdal-dev] Installing the latest GDAL version on ubuntu 20.04
Hi, Recent GDAL release is available in UbuntuGIS unstable ppa: https://launchpad.net/~ubuntugis/+archive/ubuntu/ubuntugis-unstable On 3/18/21 2:48 PM, Adzorv1 wrote: For some time i have been trying to install the latest version of GDAL or anything above 3.1.0 on my ubuntu 20.04 system, unfortunately the version that keeps being installed is 3.0.4 which is outdated for the uses we need. I have followed several online guides but keep hitting the same issue. if i try to run: pip3 install GDAL==3.1.0 I get a huge red wall of errors with the final line stating that the wheel failed to build. any suggestions would be really appreciated -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Angelos Tzotsos, PhD President Open Source Geospatial Foundation http://users.ntua.gr/tzotsos ___ 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 ?
Sorry for the typo :) On 1/20/21 1:32 PM, michael.smith.e...@gmail.com wrote: Angelos, OSGeo is a US non profit 501(c)(4), not (c)(3). We can receive donations but they are not tax deductible. Michael Smith OSGeo Treasurer On Jan 20, 2021, at 4:27 AM, Angelos Tzotsos wrote: Hi, OSGeo is an approved 501(c)(3) organization. https://en.wikipedia.org/wiki/501(c)_organization#501.28c.29.284.29 https://www.osgeo.org/about/ The only contact for (in kind) sponsorship was with Microsoft, and that did not move forward because they needed another status (401). Regards, Angelos On 1/14/21 11:34 AM, Paul Harwood wrote: Just a quick question. Since the FAANGs were the question, do you know if OSGeo has been vetted and approved as a Foundation by any of the FAANGs? As I say, when I was involved on the other side for one, they had more than a 2 year lead time for that process (I don't know if that was universal or if they solved that problem). If the answer is yes, then that could be a way forward - and indeed in at least two of FAANGs that I know the employees have virtual "pots" of both money and time that they can donate to approved organisations to "give back" - so appealing to the grass roots could be a way forward. You might have to spin it as "promoting the value of Geo software to solve world problems" or some such - since as I say paying for free software is questionable legal territory. On Thu, 14 Jan 2021 at 09:00, Angelos Tzotsos wrote: Perhaps we could ask some of these organizations to sponsor GDAL through https://github.com/sponsors/OSGeo which is a recurring sponsorship ? Angelos On 1/14/21 12:58 AM, Howard Butler wrote: On Jan 13, 2021, at 4:28 PM, Nyall Dawson wrote: On Thu, 14 Jan 2021 at 06:24, David Strip wrote: What is the path forward? One path Howard suggests is establishing a foundation similar to that behind Qgis. Another alternative, probably far more controversial, is a license change. I'm pretty clueless regarding licenses -- but this is an interesting thought. I wonder if any new drivers added to GDAL could be done with a dual-licensing under both GPL + some other license which requires ongoing sponsorship of the GDAL project? License monkey business isn't viable in any way with GDAL. It would just create confusion and erode trust, which we can't get back if broken. The big organizations running 100,000,000s of CPU hours extracting information from imagery they're reading in COGs with GDAL need to be donating substantial resources into an organization that provides coordination. The last time I did a fund raise with gdalbarn.com <http://gdalbarn.com/> <http://gdalbarn.com/> I was called out for naming some of these organizations and expressing my disappointment they couldn't find a way to participate or simply ignored the request. Maybe they will step forward this time around. Whether it is in a new foundation or an existing one like NumFocus, substantial resources need to be dumped in a pot that are earmarked for supporting work that generates value for the project. Chasing new feature work to subsidize project maintenance activities is not sustainable in two directions – burn out for the maintainer and creeping feature-itis for the project. It's clear what's happened in the past is a combination of luck and graciousness by both Frank and Even. Howard ___ gdal-dev mailing listgdal-dev@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev -- Angelos Tzotsos, PhD President Open Source Geospatial Foundationhttp://users.ntua.gr/tzotsos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Angelos Tzotsos, PhD President Open Source Geospatial Foundation http://users.ntua.gr/tzotsos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Angelos Tzotsos, PhD President Open Source Geospatial Foundation http://users.ntua.gr/tzotsos ___ 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 ?
Hi, OSGeo is an approved 501(c)(3) organization. https://en.wikipedia.org/wiki/501(c)_organization#501.28c.29.284.29 https://www.osgeo.org/about/ The only contact for (in kind) sponsorship was with Microsoft, and that did not move forward because they needed another status (401). Regards, Angelos On 1/14/21 11:34 AM, Paul Harwood wrote: Just a quick question. Since the FAANGs were the question, do you know if OSGeo has been vetted and approved as a Foundation by any of the FAANGs? As I say, when I was involved on the other side for one, they had more than a 2 year lead time for that process (I don't know if that was universal or if they solved that problem). If the answer is yes, then that could be a way forward - and indeed in at least two of FAANGs that I know the employees have virtual "pots" of both money and time that they can donate to approved organisations to "give back" - so appealing to the grass roots could be a way forward. You might have to spin it as "promoting the value of Geo software to solve world problems" or some such - since as I say paying for free software is questionable legal territory. On Thu, 14 Jan 2021 at 09:00, Angelos Tzotsos wrote: Perhaps we could ask some of these organizations to sponsor GDAL through https://github.com/sponsors/OSGeo which is a recurring sponsorship ? Angelos On 1/14/21 12:58 AM, Howard Butler wrote: On Jan 13, 2021, at 4:28 PM, Nyall Dawson wrote: On Thu, 14 Jan 2021 at 06:24, David Strip wrote: What is the path forward? One path Howard suggests is establishing a foundation similar to that behind Qgis. Another alternative, probably far more controversial, is a license change. I'm pretty clueless regarding licenses -- but this is an interesting thought. I wonder if any new drivers added to GDAL could be done with a dual-licensing under both GPL + some other license which requires ongoing sponsorship of the GDAL project? License monkey business isn't viable in any way with GDAL. It would just create confusion and erode trust, which we can't get back if broken. The big organizations running 100,000,000s of CPU hours extracting information from imagery they're reading in COGs with GDAL need to be donating substantial resources into an organization that provides coordination. The last time I did a fund raise with gdalbarn.com <http://gdalbarn.com/> <http://gdalbarn.com/> I was called out for naming some of these organizations and expressing my disappointment they couldn't find a way to participate or simply ignored the request. Maybe they will step forward this time around. Whether it is in a new foundation or an existing one like NumFocus, substantial resources need to be dumped in a pot that are earmarked for supporting work that generates value for the project. Chasing new feature work to subsidize project maintenance activities is not sustainable in two directions – burn out for the maintainer and creeping feature-itis for the project. It's clear what's happened in the past is a combination of luck and graciousness by both Frank and Even. Howard ___ gdal-dev mailing listgdal-dev@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev -- Angelos Tzotsos, PhD President Open Source Geospatial Foundationhttp://users.ntua.gr/tzotsos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Angelos Tzotsos, PhD President Open Source Geospatial Foundation http://users.ntua.gr/tzotsos ___ 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 ?
Perhaps we could ask some of these organizations to sponsor GDAL through https://github.com/sponsors/OSGeo which is a recurring sponsorship ? Angelos On 1/14/21 12:58 AM, Howard Butler wrote: On Jan 13, 2021, at 4:28 PM, Nyall Dawson wrote: On Thu, 14 Jan 2021 at 06:24, David Strip wrote: What is the path forward? One path Howard suggests is establishing a foundation similar to that behind Qgis. Another alternative, probably far more controversial, is a license change. I'm pretty clueless regarding licenses -- but this is an interesting thought. I wonder if any new drivers added to GDAL could be done with a dual-licensing under both GPL + some other license which requires ongoing sponsorship of the GDAL project? License monkey business isn't viable in any way with GDAL. It would just create confusion and erode trust, which we can't get back if broken. The big organizations running 100,000,000s of CPU hours extracting information from imagery they're reading in COGs with GDAL need to be donating substantial resources into an organization that provides coordination. The last time I did a fund raise with gdalbarn.com <http://gdalbarn.com/> I was called out for naming some of these organizations and expressing my disappointment they couldn't find a way to participate or simply ignored the request. Maybe they will step forward this time around. Whether it is in a new foundation or an existing one like NumFocus, substantial resources need to be dumped in a pot that are earmarked for supporting work that generates value for the project. Chasing new feature work to subsidize project maintenance activities is not sustainable in two directions – burn out for the maintainer and creeping feature-itis for the project. It's clear what's happened in the past is a combination of luck and graciousness by both Frank and Even. Howard ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Angelos Tzotsos, PhD President Open Source Geospatial Foundation http://users.ntua.gr/tzotsos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] [OSGeoLive] Issue #2068 on Mint 19
I thought we had fixed this issue some months ago... Will look further into this. Cheers, Angelos On Sat, Sep 15, 2018 at 4:43 PM Sebastiaan Couwenberg wrote: > On 9/15/18 2:28 PM, Micha Silver wrote: > > AFAIK, you don't necessarily need the ubuntugis repo in bionic distros. > > The regular ubuntu repos have pretty recent versions. On my Mint systems > > I get GRASS 7.4.0, and gdal 2.2.3. But every invocation of gdal > > commands begins with: > > micha@TP480:~$ gdalinfo --version > > ERROR 1: libgrass_dgl.7.4.0.so: cannot open shared object file: No such > > file or directory > > ERROR 1: libgrass_dgl.7.4.0.so: cannot open shared object file: No such > > file or directory > > ERROR 1: libgrass_vector.7.4.0.so: cannot open shared object file: No > > such file or directory > > ERROR 1: libgrass_vector.7.4.0.so: cannot open shared object file: No > > such file or directory > > GDAL 2.2.3, released 2017/11/20 > > That's a known issue on Ubuntu based systems which build with > --as-needed by default. A fix was added in libgdal-grass (2.3.0-2) > triggered by https://trac.osgeo.org/osgeolive/ticket/2068. > > This fix is also available in libgdal-grass (2.2.3-3~bionic0) in the > OSGeoLive PPA, but not in the ubuntugis-unstable PPA (any more). It's > possible that a later rebuild of the libgdal-grass package reverted the > fix. > > > And these errors are appearing also in R with the MODIS package. > > > > What are the implications of adding the ubuntugis-unstable repo to solve > > this? > > The libgdal-grass package in the UbuntuGIS PPA needs to be fixed. The > older package from bionic most likely also doesn't have this fix. > > Kind Regards, > > Bas > ___ > osgeolive mailing list > osgeol...@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/osgeolive > -- Angelos Tzotsos, PhD OSGeo Charter Member http://users.ntua.gr/tzotsos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Coordinate system improvements - GDAL, libgeotiff, PROJ barn raising
Congratulations and thanks to all the sponsors! Best, Angelos On Tue, May 15, 2018 at 6:27 PM, Even Rouault wrote: > Hi all, > > > > Excellent news: the last third of the funding was completed yesterday, so > this project will come true ! Thanks to all sponsors who have contributed > making this possible [1] > > > > So what does this mean for GDAL ? Obviously all the functionality > mentionned below will become available once implemented. > > > > Most of the initial work will be done in PROJ first, with GDAL catching it > up afterwards (or in an experimental branch at first to follow the "eat > your own dog food" principle). I'll come back later with more concrete > implementation plans. > > > > I guess some disruption is to be expected temporarily as functionnality > will move from GDAL down to PROJ. This will probably mean that PROJ master > will be a required dependency for GDAL master (and PROJ 6.0 a minimum and > compulsory requirement for GDAL 2.4) > > > > Best regards, > > > > Even > > > > > > [1] > > (Anonymous) > > AppGeo > > Applied Imagery > > Azavea > > Boundless > > Carto > > ESRI > > GeoCue > > LizardTech > > LINZ > > Mapbox > > Mobile Geographics > > Oslandia > > Safe Software > > Sparkgeo > > Spatial Networks > > Radiant Solutions > > Terranodo > > The Timoney Group > > > > > Hi, > > > > > > A barn raising to improve coordinate system abilities in GDAL, > libgeotiff, > > > and PROJ has been publicly launched today. You can find more details > about > > > the proposal, its current sponsors and technical information at: > > > > > > https://gdalbarn.com > > > > > > The hightlights of the planned work are: > > > > > > * migration for CSV support data to a SQLite database shared between > > > projects, offering more capabilities > > > > > > * WKT2 support: increased interoperability between implementations. > better > > > ground for definitions, especially in areas such as axis, vertical > control, > > > and epochs > > > > > > * end of WGS84 as a compulsory datum pivot, to be replaced by > "late-binding" > > > transformations that PROJ.5 now allows. > > > > > > We are currently at 2/3 of the final funding goal. If your software and > > > projects benefit from the GDAL, libgeotiff and PROJ stack, this is your > > > chance to concretely help in its future improvements. > > > > > > Best regards, > > > > > > Howard Butler > > > Kristian Evers > > > Paul Ramsey > > > Even Rouault > > > > > > -- > > 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 > -- Angelos Tzotsos, PhD OSGeo Charter Member http://users.ntua.gr/tzotsos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] deb package for 2.2.3
On 05/04/2018 11:08 AM, Sebastiaan Couwenberg wrote: On 05/04/2018 10:06 AM, Angelos Tzotsos wrote: Let me check if I can push 2.2.3 to experimental within the weekend. Do you mean 2.2.4? Note that no transition is required from 2.2.3 to 2.2.4, but there is from 2.2.2 and earlier. Kind Regards, Bas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev Yes, thanks. Lets wait for 2.3.0 then. Best, Angelos -- Angelos Tzotsos, PhD Charter Member Open Source Geospatial Foundation http://users.ntua.gr/tzotsos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] deb package for 2.2.3
Hi, I am planning to update UbuntuGIS with the new GDAL 2.3.0 release once it is out. Let me check if I can push 2.2.3 to experimental within the weekend. Cheers, Angelos On 05/04/2018 08:39 AM, Grégory Bataille wrote: wow, ok, a bit more work than I expected. Now I understand why it's hard to keep it up-to-date. Thanks for the osgeolive pointer, did not know about it. Cool if you move soon to 2.3.0 and therefore feeds ubuntugis. I'll still see if I can quickly get somewhere is the meantime on my own with what you sent cheers --- Gregory Bataille On Fri, May 4, 2018 at 7:28 AM Sebastiaan Couwenberg wrote: On 05/04/2018 07:11 AM, Grégory Bataille wrote: I'm running gdal 2.2.2 from ubuntu-gis/experimental .deb package and I just got stuck by https://trac.osgeo.org/gdal/ticket/7143. Took me some time to debug because I develop locally on Mac, where the package is at 2.2.3 and the bug is fixed. What does it take to build the .deb package. Is this something that someone can do? is this something sufficiently scripted that I can do it and give you guys the result for publication? In the case of UbuntuGIS, you can rebuild the source package from Debian. The sources are available in git: https://salsa.debian.org/debian-gis-team/gdal https://salsa.debian.org/debian-gis-team/gdal-grass Once you have rebuild the gdal package, you need to rebuild all reverse dependencies (packages that depend on libgdal20) with the new gdal to have them use the new virtual ABI dependency. Because of interdependencies you need to rebuild the packages in the correct order, have a look at: https://trac.osgeo.org/ubuntugis/wiki/BuildOrder Note that this page may have become outdated again. The Debian GIS transition trackers shows all libgdal20 reverse dependencies in Debian unstable: https://linuxminded.nl/debian/gis-transitions/html/gdal.html You will need to host all the rebuild packages in your own PPA to easily install them. If your goal is to update the gdal packages in the UbuntuGIS PPA, you need to coordinate your contributions on the appropriate mailinglist: https://lists.osgeo.org/mailman/listinfo/ubuntu Due to the lack of manpower, pretty much all the packages in the UbuntuGIS PPA get copied from the OSGeoLive PPA where a little more manpower is available to create backports of Debian GIS packages for Ubuntu LTS releases. The next OSGeoLive release will be based on bionic, and will rely for a large part on the packages already available in Ubuntu because they're up-to-date with the latest upstream releases. At least proj & gdal will most likely be updated to 5.0.1 & 2.3.0 for OSGeoLive 12.0. So you can also just wait for those packages to find their way from the OSGeoLive PPA to the UbuntuGIS PPA. Contributing to OSGeoLive is also most welcome. Kind Regards, Bas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Angelos Tzotsos, PhD Charter Member Open Source Geospatial Foundation http://users.ntua.gr/tzotsos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 2.2.3 planning
The tar ball is automatically extracted from Debian git: http://http.debian.net/debian/pool/main/libg/libgdal-grass/libgdal-grass_2.2.2.orig.tar.gz Best, Angelos On 11/18/2017 06:06 PM, Even Rouault wrote: Markus, @Even: would it be possible to extract the "gdal-grass" as a separate tarball? The existing one is too old: http://download.osgeo.org/gdal/gdal-grass-1.11.2.tar.gz06-Feb-2015 07:37 49K We should probably create an "old_releases" subdirectory and put everything in the top directory in it. The most recent one is in: http://download.osgeo.org/gdal/2.2.0/gdal-grass-2.2.0.tar.gz But that's true it is not in http://download.osgeo.org/gdal/2.2.2/ We should probably put in every point release, even if unchanged. Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Angelos Tzotsos, PhD Charter Member Open Source Geospatial Foundation http://users.ntua.gr/tzotsos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] [OGC Portal] OGC Compliance Renewal Notification (Final Expiration Notice)
Update on the status of OGC renewals: Submission deadline is today. This issue is holding back GDAL passing the test: https://github.com/opengeospatial/ets-kml22/issues/14 The technical contact reported that this issue is now fixed and that the plan is to deploy the fix end of November. We have asked OGC to extend the deadline until this fix is deployed and waiting for their answer. Best, Angelos On 10/31/2017 08:15 PM, Angelos Tzotsos wrote: Hi all, Just an update on the status of our OGC certification renewals: We currently have 3 projects under certification: MapServer, GDAL and pycsw. pycsw has passed all the tests for CSW 2.0 and CSW 3.0 and is ready to be certified once again. Even has reported an issue with CITE tests and GDAL, so our application is waiting for feedback from CITE developers. Unfortunately MapServer has not yet responded (adding mapserver-dev list in CC). There is still time for other projects to submit their CITE test results and get certified through the OSGeo account. Best, Angelos On 10/31/2017 04:03 PM, Barbara Sherman wrote: Open Source Geospatial Foundation *! Your Compliance Records Expire Today !* This is an automated email to inform you that your OGC-certified compliance license(s) for the following products are due to be renewed by *October 31st, 2017*. After that date your products will no longer be listed as certified OGC compliant. If you have already received an earlier notice and have started the renewal process please ignore this message. We invite you to easily renew online in our implementation portal: http://www.opengeospatial.org/resource/products/registration As a reminder, the account used to manage your certification listings is: *osgeo (i...@osgeo.org <mailto:i...@osgeo.org>)* If you have any questions please send an email to complia...@opengeospatial.org <mailto:complia...@opengeospatial.org>. The OGC compliance team will be more than glad to help you. Current OGC-Compliant Listings GDAL/OGR 1.11 Specification(s) Original Certification OGC KML 2.2.0 2014-08-15 OGC KML (Level 2) 2.2.0 2014-08-15 OGC KML (Level 3) 2.2.0 2014-08-15 GDAL/OGR 2.1 Specification(s) Original Certification OGC KML 2.2.0 (OGC Reference Implementation) 2016-11-30 OGC KML (Level 2) 2.2.0 (OGC Reference Implementation) 2016-11-30 OGC KML (Level 3) 2.2.0 (OGC Reference Implementation) 2016-11-30 MapServer 6.2 Specification(s) Original Certification OpenGIS Web Map Service (WMS) Implementation Specification 1.3.0 (OGC Reference Implementation) 2016-01-12 pycsw 1.10 Specification(s) Original Certification OpenGIS Catalogue Service Implementation Specification 2.0.2 2016-01-26 OpenGIS Catalogue Service Implementation Specification [Catalogue Service for the Web] 2.0.2 2016-01-26 pycsw 2.0 Specification(s) Original Certification OGC® Catalogue Services 3.0 Specification - HTTP Protocol Binding 3.0 (OGC Reference Implementation) 2016-11-30 OGC® Catalogue Services 3.0 Specification - HTTP Protocol Binding (OpenSearch) 3.0 (OGC Reference Implementation) 2016-11-30 OpenGIS Catalogue Service Implementation Specification 2.0.2 (OGC Reference Implementation) 2016-11-30 OpenGIS Catalogue Service Implementation Specification [Catalogue Service for the Web] 2.0.2 (OGC Reference Implementation) 2016-11-30 -- Angelos Tzotsos, PhD Charter Member Open Source Geospatial Foundation http://users.ntua.gr/tzotsos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Gdal2tiles gains parallel processing features
Thank you for this feature! Best, Angelos On 09/29/2017 06:59 PM, Even Rouault wrote: On vendredi 29 septembre 2017 17:50:11 CEST Grégory Bataille wrote: Hi all, I just wanted to announce that after a few months of work (took long, I got lazy), *gdal2tiles has gained parallel computing abilities* It is now *on trunk*. Thanks for your great work on this - Because the rewrite + the pararellization are a big and risky work (since there were no tests really), there is a new gdal2tiles_old.py script on trunk to provide an easy "back-out" for people who would get into trouble in their production Note: I actually removed gdal2tiles_old.py when merging your work back into SVN (should have told you before). It was the same as the version you can find in the 2.2 branch, so one could still grab it from there if really needed. Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Angelos Tzotsos, PhD Charter Member Open Source Geospatial Foundation http://users.ntua.gr/tzotsos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Binary of the latest released GDAL for travis?
In that case, you are either using a ppa mixed environment (perhaps you use the postgres ppa?) or you are using a package that still depends on the upstream gdal version. On 04/11/2017 01:22 PM, Ari Jolma wrote: 11.04.2017, 13:05, Angelos Tzotsos kirjoitti: Hi Ari, sudo add-apt-repository ppa:ubuntugis/ubuntugis-unstable sudo apt-get update sudo apt-get install libgdal-dev This should do it. No. I tried that before (found it in my .travis.yml file...) and it pulls in older version 1.10.0. Ari Cheers, Angelos On 04/11/2017 11:05 AM, Ari Jolma wrote: 11.04.2017, 10:49, Bas Couwenberg kirjoitti: On 2017-04-11 09:30, Ari Jolma wrote: How could I pull into travis the binaries of the latest released GDAL (now 2.1.3)? There seems to be experimental debian package https://packages.debian.org/experimental/libgdal-dev Does anybody have experience with them? OSGeo-Live includes these packages, (re)built for Ubuntu xenial. Right now I'm pulling in the source code and building it in the overall build but that's really slow. The ubuntugis-unstable PPA has the GDAL 2.1.3 packages for xenial too (from OSGeo-Live), you can add the PPA in the travis setup script and install the packages from there. What's the package name I should use? sudo add-apt-repository ppa:ubuntugis/ubuntugis-unstable -y gpg: keyring `/tmp/tmp2gKbLJ/secring.gpg' created gpg: keyring `/tmp/tmp2gKbLJ/pubring.gpg' created gpg: requesting key 314DF160 from hkp server keyserver.ubuntu.com gpg: /tmp/tmp2gKbLJ/trustdb.gpg: trustdb created gpg: key 314DF160: public key "Launchpad ubuntugis-stable" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) OK sudo apt-get update $ sudo apt-get install libgdal-dev_2.1.3 Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to locate package libgdal-dev_2.1.3 E: Couldn't find any package by regex 'libgdal-dev_2.1.3' Ari https://launchpad.net/~ubuntugis/+archive/ubuntu/ubuntugis-unstable/+packages Kind Regards, Bas ___ 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 -- Angelos Tzotsos, PhD Charter Member Open Source Geospatial Foundation http://users.ntua.gr/tzotsos ___ 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 -- Angelos Tzotsos, PhD Charter Member Open Source Geospatial Foundation http://users.ntua.gr/tzotsos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Binary of the latest released GDAL for travis?
Hi Ari, sudo add-apt-repository ppa:ubuntugis/ubuntugis-unstable sudo apt-get update sudo apt-get install libgdal-dev This should do it. Cheers, Angelos On 04/11/2017 11:05 AM, Ari Jolma wrote: 11.04.2017, 10:49, Bas Couwenberg kirjoitti: On 2017-04-11 09:30, Ari Jolma wrote: How could I pull into travis the binaries of the latest released GDAL (now 2.1.3)? There seems to be experimental debian package https://packages.debian.org/experimental/libgdal-dev Does anybody have experience with them? OSGeo-Live includes these packages, (re)built for Ubuntu xenial. Right now I'm pulling in the source code and building it in the overall build but that's really slow. The ubuntugis-unstable PPA has the GDAL 2.1.3 packages for xenial too (from OSGeo-Live), you can add the PPA in the travis setup script and install the packages from there. What's the package name I should use? sudo add-apt-repository ppa:ubuntugis/ubuntugis-unstable -y gpg: keyring `/tmp/tmp2gKbLJ/secring.gpg' created gpg: keyring `/tmp/tmp2gKbLJ/pubring.gpg' created gpg: requesting key 314DF160 from hkp server keyserver.ubuntu.com gpg: /tmp/tmp2gKbLJ/trustdb.gpg: trustdb created gpg: key 314DF160: public key "Launchpad ubuntugis-stable" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) OK sudo apt-get update $ sudo apt-get install libgdal-dev_2.1.3 Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to locate package libgdal-dev_2.1.3 E: Couldn't find any package by regex 'libgdal-dev_2.1.3' Ari https://launchpad.net/~ubuntugis/+archive/ubuntu/ubuntugis-unstable/+packages Kind Regards, Bas ___ 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 -- Angelos Tzotsos, PhD Charter Member Open Source Geospatial Foundation http://users.ntua.gr/tzotsos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] [Live-demo] [Board] Retire MapTiler from OSGeo-Live
Hi Even, On 02/13/2015 02:05 PM, Even Rouault wrote: Hi, (adding gdal-dev in CC as it is of interest) As far as I understand (but I may be wrong as I haven't looked deeply at the code), maptiler (the open source project) consists of an improved gdal2tiles.py + a python gui. The duplication between gdal2tiles.py in maptiler and GDAL isn't something particularly great. Ideally there should be one single version maintained in the OSGeo ecosystem. So there are several possibilities I can imagine : 1) Merge maptiler's gdal2tiles enhancements into GDAL version, and make maptiler just a GUI over it 2) Merge maptiler's gdal2tiles enhancements into GDAL version, and also import the GUI (I think it is lightweight) if there's no too strong build complications involved for GDAL. Would have to be checked 3) Remove gdal2tiles from GDAL so that the reborne maptiler is the reference. But there are perhaps fixes in GDAL gdal2tiles that should be merged into maptiler one (Python3 compatibility comes to mind) Any option would need someone to champion it of course... IMO, the third option should not be considered at all, since gdal2tiles is very important tool in gdal and many people (including me) prefer the script from any GUI out there. I have also seen an improved version of this script dealing with multiple threads. My preference would be option 1. Just my 2c :) Even Hi Eli, replying to your email, CC OSGeo-Live list (with your permission). I agree that we don't want to be promoting a proprietary product from an Open Source page. I suspect Angelos' subsequent email partially addresses your suggestions: On 13/02/2015 10:47 am, Angelos Tzotsos wrote: We have also discussed that in order to remove the project, we request that there is an official source code repository to link to. This way we can prove that the project was open source and can be forked in the future. Unfortunately the main repository of the project was recently deleted. Without this, one can have the impression that OSGeoLive and OSGeo has endorsed and distributed proprietary software. Also we plan to introduce IceTiler in the next version of OSGeoLive. For this OSGeo-Live release we will do what we can achieve within the time available. On 13/02/2015 11:58 am, Eli Adam wrote: Hi Cameron, I know that timeline is as big of a challenge as anything else in this case. I have a marketing/presentation question for you below. On Thu, Feb 12, 2015 at 2:23 PM, Cameron Shorter wrote: Hi Petr, OSGeo-Live team, OSGeo Board, Is our OSGeoLive meeting, we discussed retiring of MapTiler from OSGeoLive. CCing OSGeo Board in discussion, in case the board wish to comment. Summary: * MapTiler was Open Source, and was included in prior OSGeo-Live distributions * Petr, the author, found the Open Source business model was not working for him, and has since moved future enhancements to a proprietary model. * The "maptiler" brand name now points to a URL of a proprietary product. * Petr has requested MapTiler be removed from OSGeo-Live. * As far as I've noticed, while there has been some disappointment to loose MapTiler as an Open Source project, we respect Petr's right to continue development using whatever model works for him. We are now working out how to cleanly transition. Of note: * We have prior OSGeo-Live releases and documentation which reference the previous Open Source Maptiler. * OSGeo-Live wish to retain our reputation of promoting Open Source products, both now, and in the past. Proposal for our imminent OSGeo-Live 8.5 release: * OSGeoLive will add a statement to our contents page [1] stating: "Maptiler: not included after OSGeo-Live 8.0, after project moved to proprietary business model" On 13/02/2015 11:58 am, Eli Adam wrote: This seems odd to reference proprietary software at all. The contents page [1] is a wonderful showcase of *open source* software. Why include an advertisement to go look for a proprietary software that started as open source? Linking to the last open source code with no name makes more sense to me (I know that isn't possible unless we put the code somewhere). Or linking to http://gdal.org/gdal2tiles.html which has some similar functionality and common ancestry. Looks like maybe licenses have varied in different points in time from different sources too. On the short timeline, there is no fork and no name to link to yet. If there were a fork and name would you list and link that? If so would you list or link "MapTiler" too? You could link (or save all the information from), https://web.archive.org/web/20131216172514/http://www.maptiler.org/ The Google Code SVN repo is also accessible through that method. It appears that google code svn still works, for instance, svn checkout http://maptiler.googlecode.com/svn/trunk/ maptiler-read-only I'm sure that you'll work it out fine but just wanted you to think a
Re: [gdal-dev] GDAL/OGR 1.10.0 Release Candidate 3 available
Hi, Testing rpm binaries for openSUSE are available here: https://build.opensuse.org/package/show?package=libgdal&project=home%3Atzotsos%3AApplication%3AGeo repository: http://download.opensuse.org/repositories/home:/tzotsos:/Application:/Geo/ As long as there is a final release this will replace https://build.opensuse.org/package/show?package=libgdal&project=Application%3AGeo and will be available on CentOS, RHEL, SLE, openSUSE and ScientificLinux. Cheers, Angelos On 04/18/2013 11:26 PM, Even Rouault wrote: Hi, I've prepared a third (and hopefully last) release candidate for GDAL/OGR 1.10.0. The fixes added since RC2 are : #5029: Fixed problem with JP2 write with ECW SDK 5.0 #5055: OSM driver: Too many members referenced #5056: OSM waterway #5057: Geocoder only reports geometry on first feature Please test and report any problems promptly. Soon I will initiate a motion to declare this release candidate the final release and PSC members can vote on that after doing some checks themselves. Source Code: http://download.osgeo.org/gdal/gdal-1.10.0RC3.tar.gz http://download.osgeo.org/gdal/gdal-1.10.0RC3.tar.gz.md5 http://download.osgeo.org/gdal/gdal1100RC3.zip http://download.osgeo.org/gdal/gdal1100RC3.zip.md5 Autotest Suite: http://download.osgeo.org/gdal/gdalautotest-1.10.0.tar.gz Documentation: http://download.osgeo.org/gdal/gdal1100doc.zip NEWS: http://svn.osgeo.org/gdal/tags/1.10.0/gdal/NEWS Best regards, Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] libFileGDBAPI.so not found with compiling gdal 1.9.2 on openSUSE 12.2 x64.
Hi Donovan, comments inline: On 01/26/2013 01:34 AM, Donovan Cameron wrote: When I check-out the libgdal package and I run the osc build command, isn't this building locally and not trying to *upload *any binaries? I thought this chroot was in my local machine and only making changes there? Yes this chroot is local when you use osc build command. Be careful not to push your changes though. Those local rpms can be saved and used, no problem. I was trying to keep this all a local build by following the instructions at: https://en.opensuse.org/openSUSE:Build_Service_Tutorial maybe I misunderstood what "local" really means. Should I not be using osc to build this and instead use the rpmbuild commands directly? As long as you don't push proprietary binaries to OBS it is ok to build locally. I'll explore those two options you've suggested, I was trying to do option 2, but kept running into permission issues when the source tarball for the API was being extracted to the chroot environment at /usr/lib64 with permission denied. I would suggest to create a spec file that installs that API, build locally and then require that rpm for your local gdal build. I'll read more on this stuff, thanks again. You are welcome :) I think I just need to read more on how to handle user permissions in the spec file, so I'll take some time to read some more docs on bundling RPMs from spec files. Cheers, Angelos -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] libFileGDBAPI.so not found with compiling gdal 1.9.2 on openSUSE 12.2 x64.
27;t even think that's necessary. I only had to set that to get the API test to work. I'm not sure where this is going wrong. If anyone has any input or needs more information, let me know. Thanks! Donovan ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev _______ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OpenJPEG 2.0 released
On 11/26/2012 05:44 PM, Even Rouault wrote: Selon Jeff McKenna : On 12-11-26 5:51 AM, Angelos Tzotsos wrote: Thanks Even, I have disabled openjpeg2 support until 1.10. Cheers, Angelos Thanks Angelos/Even, I will do the same. Just to be clear: if you have already packaged GDAL 1.9 with openjpeg "old" v2 branch, there's no reason to change that right now, unless you have other users of openjpeg 2.0 or have some other good reason to upgrade it now. The issue in my case is that openjpeg was updated upstream in openSUSE Factory so the previous gdal package does not find the correct SO name, so it breaks. -jeff -- Jeff McKenna MapServer Consulting and Training Services http://www.gatewaygeomatics.com/ ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev Best, Angelos -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OpenJPEG 2.0 released
On 11/26/2012 10:29 AM, Even Rouault wrote: Selon Angelos Tzotsos : On 11/20/2012 09:23 PM, Even Rouault wrote: Hi, Just to inform you that the OpenJPEG project has just released OpenJPEG 2.0.0. GDAL users of GDAL 1.10dev that need support for JPEG2000 can (must) now rely on a released version, and no longer on the openjpeg SVN v2 branch (which has been removed by the way) Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev Hi Even, openjpeg-2.0 final has just been upgraded in openSUSE, causing gdal-1.9.2 build to break. Yes this is expected. OpenJPEG 2.0 API has been changed during the merge of their v2 feature branch into their trunk. Is there a patch available to apply or should I disable openjpeg until gdal-1.10 release? I don't foresee doing a patch at this point of GDAL 1.9.X lifetime to bring support of OpenJPEG 2.0. You could decide shiping the old v2 branch of openjpeg in the state it was, but I doubt that you'll do this for a distribution since it would be a bit confusing. So yes the best is probably to wait for GDAL 1.10. Best, Angelos -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev Thanks Even, I have disabled openjpeg2 support until 1.10. Cheers, Angelos -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OpenJPEG 2.0 released
On 11/20/2012 09:23 PM, Even Rouault wrote: Hi, Just to inform you that the OpenJPEG project has just released OpenJPEG 2.0.0. GDAL users of GDAL 1.10dev that need support for JPEG2000 can (must) now rely on a released version, and no longer on the openjpeg SVN v2 branch (which has been removed by the way) Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev Hi Even, openjpeg-2.0 final has just been upgraded in openSUSE, causing gdal-1.9.2 build to break. Is there a patch available to apply or should I disable openjpeg until gdal-1.10 release? Best, Angelos -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ogrinfo in GDAL 1.9.2 reporting wrong dimension for layer geometry type
On 10/19/2012 02:15 AM, Even Rouault wrote: Hi, Just to inform you that we have spotted a regression in 1.9.2 : ogrinfo (and any code using OGRGeometryTypeToName()) will report 3D geometry types for 2D layers, and vice versa. See http://trac.osgeo.org/gdal/ticket/4871 This is now fixed in SVN in trunk and 1.9 branch. And this will get into 1.9.3 when it will be released. Best regards, Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev Thanks Even, I will patch openSUSE builds. Angelos -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] [update] Re: Travis CI continuous integration service for GDAL
On 10/10/2012 02:16 AM, Even Rouault wrote: Le dimanche 07 octobre 2012 11:42:30, Even Rouault a écrit : Hi, Following a recent similar move from MapServer, I've setup an instance of Travis CI, hosted continuous integration service. After each SVN commit in trunk, GDAL is built and the Java, Perl and Python tests are run. Travis CI currently offers Ubuntu 12.04 i386 virtual machines. The GDAL build is configured with almost any possible dependencies to external libraries (see http://trac.osgeo.org/gdal/wiki/Buildbot for the list) You can access to the latest builds here : https://travis-ci.org/#!/rouault/gdal/builds Just a follow-up to inform you that GDAL SVN is now fully mirrored (meaning that it includes all branches and tags) at : https://github.com/OSGeo/gdal (The update script still runs on my PC.) Travis builds are available consequently at : https://travis-ci.org/#!/OSGeo/gdal Both trunk and 1.9 branch benefit from Travis configuration. Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev Hi all, This is great news. I believe that gdal would benefit a lot with a full move to git. Also I am wondering if we should add more OSGeo projects and members under this OSGeo github account. What do you think? Regards, Angelos -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Classification Accuracy Utility
Hi everyone, I recently needed to compute classification accuracy measures (completeness, correctness, quality) for a journal paper. So I took some time to write the following utility: http://users.ntua.gr/tzotsos/code/gdal_accuracy.py I would be very happy if it could be included in gdal utilities. Please let me know of any ideas, comments etc. Regards, Angelos -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Fail to build with OpenJpeg
Hi Joaquim, In order to build with OpenJpeg, you must use the unreleased version 2.0 of OpenJpeg. Try the following: http://code.google.com/p/openjpeg/downloads/detail?name=openjpeg_v2_alpha_0.zip Regards, Angelos On 03/09/2011 03:23 AM, Joaquim Luis wrote: Hi, My attempt to build gdal (trunk) on Windows with OpenJpeg failed with these errors C:\programs\GDALtrunk\gdal\frmts>cd openjpeg && nmake /nologo /f makefile.vc && cd .. || exit 1 cl /nologo /MD /EHsc /Ox /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE /DNDEBUG /W4 /wd4127 /wd4251 /wd4275 /wd4786 /wd4100 /wd4245 /wd4206 /wd4018 /wd4389 -I..\..\port -I..\..\ogr -I..\..\gcore -I..\..\alg -I..\..\ogr\ogrsf_frmts -IC:\programs\compa_libs\openjpeg_v1_4\libopenjpeg -DOGR_ENABLED /c openjpegdataset.cpp openjpegdataset.cpp openjpegdataset.cpp(80) : error C2146: syntax error : missing ';' before identifier 'JP2OpenJPEGDataset_Read' openjpegdataset.cpp(80) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int openjpegdataset.cpp(80) : error C2061: syntax error : identifier 'OPJ_UINT32' I greped for OPJ_UINT32 in the OpenJpeg source and on GDAL's) and there was no sign of it. I am using openjpeg_v1_4_source_r697 as per its web site. Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Geomedia mdb files
I am checking with some old colleagues at Intergraph to see if the data are free to redistribute. On 01/22/2011 06:26 PM, Even Rouault wrote: Le samedi 22 janvier 2011 16:58:27, Angelos Tzotsos a écrit : Hi Even. Good work. I can provide a sample mdb file made from GeoMedia. Is there any particular shapefile, you would like me to translate? Perhaps we can include the US Sample Data as provided by Intergraph. If the samples provided by intergraph are licenced as being freely redistribuable, that's OK. But fake geometries drawn at hand (one point, one line, one polygon, one polygon with a hole, one multipolygon, one geometry collection, etc...) would be preferred to be on the safe side (and to have a small file). -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Geomedia mdb files
Hi Even. Good work. I can provide a sample mdb file made from GeoMedia. Is there any particular shapefile, you would like me to translate? Perhaps we can include the US Sample Data as provided by Intergraph. Best regards, Angelos On 01/22/2011 05:42 PM, Even Rouault wrote: Hi, I've just added a read-only geomedia driver in GDAL trunk (GDAL 1.9.0dev). Testing is appreciated. It would be usefull if someone could provide a small and freely redistribuable geomedia .mdb (possibly hand-made with fake data) with different types of geometries (1 feature for each geometry type is enough) so that it can be included in the autotest suite. For now, it has just been tested with the MMSDTestDB.zip attachment found on http://forum.manifold.net/forum/t106539.11 What is mainly missing is SRS support. I see that the GCoordSystem contains all the info. For the above example : Stor2CompMatrix1 (Real) = 0.3048 GeodeticDatum (Integer) = 0 Ellipsoid (Integer) = 21 EquatorialRadius (Real) = 6378407.621 InverseFlattening (Real) = 298.269875040474 ProjAlgorithm (Integer) = 2 AzimuthAngle (Real) = (null) FalseX (Real) = 247193.2944 FalseY (Real) = 0 Hemisphere (Integer) = (null) LatOfOrigin (Real) = 41.75 LatOfTrueScale (Real) = (null) LonOfOrigin (Real) = -89.4 RadOfStandCircle (Real) = (null) ScaleReductFact (Real) = 1 StandPar1 (Real) = 42.90833 StandPar2 (Real) = 43.23056 But the GeodeticDatum, Ellipsoid and ProjAlgorithm fields presumably map to enumerations, so examples of databases using various SRS (starting with the most common ones like lat/long WGS84 and UTM WGS84) with the "text" description of the SRS would be necessary to establish this mapping. Unless someone knows where to find a spec of this ? From the above sample and a bit of googling, I've deduced this is equivalent to the following ESRI WKT : PROJCS["NAD_1983_HARN_Adj_WI_Dane_Feet",GEOGCS["GCS_NAD_1983_HARN_Adj_WI_Dane",DATUM["D_NAD_1983_HARN_Adj_WI_DN",SPHEROID["GRS_1980_Adj_WI_DN",6378407.621,298.269876997368]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Lambert_Conformal_Conic"],PARAMETER["False_Easting",811000.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",-89.43],PARAMETER["Standard_Parallel_1",42.908333],PARAMETER["Standard_Parallel_2",43.230555],PARAMETER["Latitude_Of_Origin",41.75],UNIT["Foot_US",0.3048006096012192]] So ProjAlgorithm 2 is likely meaning Lambert_Conformal_Conic_2SP and Ellipsoid = 21 = GRS_1980_Adj_WI_DN ? Best regards, Even Le mardi 12 octobre 2010 18:33:59, Frank Warmerdam a écrit : Moskovitz, Bob wrote: Frank, I'm also interested in seeing a Geomedia driver for gdal. Btw, gvSIG has a Geomedia plugin (see https://code.google.com/p/extmdb ). This might help you figure out how to make a driver for gdal. Bob, Interesting. Using the extmdb MDBGeometryAdapter.java code it should be possible to fairly easily implement geomedia feature reading in OGR. Anyone interested in taking the task on or funding it? Best regards, ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_extents utility?
Hi Even, Thank you for your comments. At this point the code serves the purposes of the gimed metadata editor. Of course the utility is going to be re-written if it is to be included in gdal (with different license). All your suggestions are very welcome and will be taken under consideration. I will look into what you propose with the CSV driver. Looks interesting. As for your last question, this has to be handled with some kind of external parameter from the user. Best regards, Angelos On 11/07/2010 11:13 PM, Even Rouault wrote: Angelos, Speaking for myself : Your utility is certainly usefull for your purposes, but I'm not sure if there is enough "added value" and/or general purposeness to include it as a new utility. Is the output of the utility aimed at some other utilities of a larger processing chain ? Some things I noticed : 1) The licence : code that goes into GDAL source tree must be licenced under the X/MIT licence 2) The hard-coded Greek SRS. You should use the one from the GDAL dataset / OGR layer instead of the hard coded value. 3) The extent reported on a GDAL dataset won't match the ones reported by gdalinfo. For some reason you add a half-pixel shift 4) What is that DTM file ? Looks like it could be handled by the CSV driver with the help of OGR VRT wrapper file. 5) If the OGR datasource has more than one layer, several lines will be written. Is it wanted ? Best regards, Even -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] gdal_extents utility?
Hi everyone, I have written a small utility based on gdal recently that extracts the bounding box of any supported spatial data file. http://gimed.svn.sourceforge.net/viewvc/gimed/trunk/utils/geo_extents.c?revision=14&view=markup This utility is very useful for creating metadata geographic extents according to ISO19139 I would like to improve it and contribute it to gdal utilities under the name "gdal_extents". Would this kind of utility be of interest? Could you please suggest improvements needed? Regards, Angelos -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
