Re: [gdal-dev] Censor area in tiles of aerial image
Carsten, gdal_rasterize definitely supports burning into existing files. I'm not sure about the configuration of your raster -- some formats are not updatable-in-place, but the limitation isn't in gdal_rasterize. Best regards, Frank On Tue, Mar 19, 2024 at 8:42 AM Carsten Lockenkötter < carsten.lockenkoet...@web.de> wrote: > Hi Frank, > > I have read about gdal_rasterize but it seems it works a bit different as > i need it. > Gdal_rasterize converts a vector layer to a raster layer with specific > dimensions and create a new file, like a mask. > It could be work for me yes, because i publish the raster files as image > mosiac at the geoserver. > Maybe the new "mask" file overlays on me original files and the created > wmts tiles of the geoserver could contain the mask. > > I will try it, but is there another option to burn the vectorlayer into > existing tiles? > > Regards, > Carsten > Am 19.03.24, 00:14 schrieb Frank Warmerdam : > >> Carsten, >> >> The gdal_rasterize command allows you to "burn in" polygons from an OGR >> supported datasource into an existing raster. If your raster is a 3 band >> RGB file, you could use --burn 100 150 200 to burn in the RGB value >> (100,150,200). This will only work if the raster format you are using >> supports update-in-place. >> >> You would have to regenerate pyramids after this process -- they are not >> automatically updated by GDAL when the "base layer" is updated. >> >> Best regards, >> Frank >> >> >> On Mon, Mar 18, 2024 at 5:34 PM Carsten Lockenkötter via gdal-dev < >> gdal-dev@lists.osgeo.org> wrote: >> >>> Hi, >>> >>> >>> >>> is it possible to censor specific areas of an aerial image using GDAL? >>> >>> >>> >>> I have several smaller tiles that I've already transformed into my >>> desired coordinate system and generated internal pyramids. >>> >>> Subsequently, I would like to censor certain areas based on polygons >>> (e.g., from a shapefile or an Oracle DB) (coloring them grayish). >>> >>> Set the color must be done after transforming coordinatesystem and >>> generating pyramids. >>> >>> >>> >>> I usually use the compiled Windows binaries from gisinternals.com. >>> >>> Presumably, my plan doesn't work with that, right? At least I haven't >>> found anything in that direction. >>> >>> I suppose this could be done with a Python, but I've never worked with >>> Python before. >>> >>> Do I need to adjust the internal pyramids as well? Or do I have to >>> recreate them? >>> >>> >>> >>> Could you please show me a brief example of how it could work, so I have >>> an approach? >>> >>> I just need an idea of how to implement this and possibly some tips on >>> what else I need to consider. >>> >>> >>> >>> Regards, >>> >>> Carsten >>> ___ >>> gdal-dev mailing list >>> gdal-dev@lists.osgeo.org >>> https://lists.osgeo.org/mailman/listinfo/gdal-dev >>> >> >> >> -- >> >> ---+-- >> I set the clouds in motion - turn up | Frank Warmerdam, >> warmer...@pobox.com >> light and sound - activate the windows | USA: +1 650-701-7823 >> <http://voice.google.com/calls?a=nc,%2B16507017823> >> and watch the world go round - Rush| CAN: +1 343-550-9984 >> > -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | USA: +1 650-701-7823 <http://voice.google.com/calls?a=nc,%2B16507017823> and watch the world go round - Rush| CAN: +1 343-550-9984 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Censor area in tiles of aerial image
Carsten, The gdal_rasterize command allows you to "burn in" polygons from an OGR supported datasource into an existing raster. If your raster is a 3 band RGB file, you could use --burn 100 150 200 to burn in the RGB value (100,150,200). This will only work if the raster format you are using supports update-in-place. You would have to regenerate pyramids after this process -- they are not automatically updated by GDAL when the "base layer" is updated. Best regards, Frank On Mon, Mar 18, 2024 at 5:34 PM Carsten Lockenkötter via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hi, > > > > is it possible to censor specific areas of an aerial image using GDAL? > > > > I have several smaller tiles that I've already transformed into my desired > coordinate system and generated internal pyramids. > > Subsequently, I would like to censor certain areas based on polygons > (e.g., from a shapefile or an Oracle DB) (coloring them grayish). > > Set the color must be done after transforming coordinatesystem and > generating pyramids. > > > > I usually use the compiled Windows binaries from gisinternals.com. > > Presumably, my plan doesn't work with that, right? At least I haven't > found anything in that direction. > > I suppose this could be done with a Python, but I've never worked with > Python before. > > Do I need to adjust the internal pyramids as well? Or do I have to > recreate them? > > > > Could you please show me a brief example of how it could work, so I have > an approach? > > I just need an idea of how to implement this and possibly some tips on > what else I need to consider. > > > > Regards, > > Carsten > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | USA: +1 650-701-7823 <http://voice.google.com/calls?a=nc,%2B16507017823> and watch the world go round - Rush| CAN: +1 343-550-9984 ___ 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 Frank On Wed, Oct 11, 2023 at 12:39 PM Rahkonen Jukka via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > +1 > > -Jukka Rahkonen- > > -Alkuperäinen viesti- > Lähettäjä: gdal-dev Puolesta Howard > Butler via gdal-dev > Lähetetty: keskiviikko 11. lokakuuta 2023 19.14 > Vastaanottaja: gdal dev > Aihe: [gdal-dev] Motion: Annual Contracts for Maintainers > > 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 > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -- -------+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | USA: +1 650-701-7823 <http://voice.google.com/calls?a=nc,%2B16507017823> and watch the world go round - Rush| CAN: +1 343-550-9984 ___ 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 Frank On Sat, Sep 16, 2023 at 7:32 AM 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 > > -- > 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 > -- ---+------ I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | USA: +1 650-701-7823 <http://voice.google.com/calls?a=nc,%2B16507017823> and watch the world go round - Rush| CAN: +1 343-550-9984 ___ 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
+1 FrankW On Tue, Sep 12, 2023 at 7:26 PM Kurt Schwehr wrote: > +1 KurtS > > On Tue, Sep 12, 2023, 12:21 PM 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 >> > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -- -------+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | USA: +1 650-701-7823 <http://voice.google.com/calls?a=nc,%2B16507017823> and watch the world go round - Rush| CAN: +1 343-550-9984 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Python bindings: enabling exceptions by default?
Folks, As long as there is a clear path to disabling python exception handling fairly cleanly I can live with it. Like Kurt, we have a large code base using GDAL mostly without exceptions enabled for GDAL. If there is going to be a change, I also agree 4.0 is the time to do it. Best regards, Frank On Mon, Mar 20, 2023 at 4:07 PM Kurt Schwehr wrote: > We are heavy users of the swig bindings. We have some Fiona users and are > only just now in the process of starting to use rasterio. We have only 3 > instances of calling UseExceptions. Turning on UseExceptions > immediately blew up a bunch of my tests that were making incorrect > assumptions. Nothing major, but I haven't looked for more than a couple > seconds for trouble. > > +1 for switching to have it enabled by default. I'm not sure if it would > be better with 3.7.0 or 4.0.0. > > On Mon, Mar 20, 2023 at 10:58 AM Howard Butler wrote: > >> >> >> > On Mar 19, 2023, at 7:34 AM, Even Rouault >> wrote: >> > >> > Hi, >> > >> > I've prepared a pull request that does the above, but this raises a >> number of questions. See my longish comment at >> https://github.com/OSGeo/gdal/pull/7475#issuecomment-1475239852. >> Thoughts appreciated >> >> First off, thank you for doing this. >> >> Speaking for myself, pretty much all of the ogr.py/gdal.py code I've >> written for the past 15 years has gdal.UseExceptions() after the "from >> osgeo import gdal" import. The reasons why we had to have this 15 years ago >> were reasonable, but now it is just confusing boilerplate. It's time to >> ditch it. >> >> It has been a regret that we didn't clean up the secondary effects of >> UseExceptions/DontUseExceptions a long time ago. I'm sure the original sin >> was a result of my mucking with the SWIG bindings to get something that >> kind of worked and giving up after that. I'm glad your PR addresses this >> and makes things better for other handler-aware code that is often mixed >> together with gdal.py such as Fiona/rasterio, QGIS bindings, or PDAL stuff >> (in my case). >> >> As for enabling them by default at our next 3.7 release ... one one hand, >> it has been fifteen years already and the project has been telegraphing >> through the options that this could/should change. On the other, GDAL is >> *very* conservative with API evolution, and making UseExceptions default >> behavior in the Python bindings breaks existing code that wasn't doing >> gdal.UseExceptions already. The nice thing about activating this behavior >> is that it causes it to throw an exception and tell the user about >> something that was otherwise silently failing, so the remedy in the case of >> most of these breakages is going to be clear. >> >> I would vote that we go for enabling UseExceptions by default for GDAL >> 3.7 based on the following assumptions: >> * The group that will feel the largest impact by the change is GDAL's own >> autotest suite >> * Exceptions are the Python Way, and default behavior of GDAL's bindings >> is out of step >> * Tons of user-land code is already doing UseExceptions, as it is a >> practice that is recommended in many tutorials and books and SE posts >> * The largest portion of GDAL-using Python developers are using Rasterio >> or Fiona, not gdal.py and ogr.py, and they would not be impacted by these >> changes (and maybe be impacted positively as the ticket describes). >> >> Are you a GDAL Python bindings user? Would you be impacted by this policy >> change? Please chime in. >> >> Howard >> ___ >> 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 > -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Removal of Python SWIG python generated files from git
Folks, At one time we were very sensitive to the exact version of SWIG so providing pre-generated bindings removed a large class of versioning problems. I am ok with removing them. Best regards, Frank On Thu, Mar 9, 2023 at 3:14 PM Even Rouault wrote: > > > To play devil's advocate, were there any (perceived) benefits to this > > arrangement when originally introduced, other than not needing the > > SWIG binary to compile Python bindings? > > That predates the start of my involvement with GDAL, so my guess would > be that this was just what you mention: for the sake of simplicity of > people building GDAL, at a time where its only build requirement was the > basic tools autoconf, make and g++. Nowadays, getting SWIG isn't harder > than getting PROJ or any of the "optional" dependencies you generally > want to make a reasonably feature complete GDAL build. > > 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 > -- ---+------ I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Approve RFC90: Direct access to compressed raster data
+1 Frank On Mon, Jan 16, 2023 at 1:49 PM Rahkonen Jukka < jukka.rahko...@maanmittauslaitos.fi> wrote: > +1 > > -Jukka Rahkonen- > > -Alkuperäinen viesti- > Lähettäjä: gdal-dev Puolesta Even > Rouault > Lähetetty: maanantai 16. tammikuuta 2023 19.03 > Vastaanottaja: gdal-dev@lists.osgeo.org > Aihe: [gdal-dev] Motion: Approve RFC90: Direct access to compressed raster > data > > Hi, > > Motion: Approve RFC90: Direct access to compressed raster data: > > > https://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOSGeo%2Fgdal%2Fpull%2F7020=05%7C01%7Cjukka.rahkonen%40maanmittauslaitos.fi%7C4f723d3633d343e143e308daf7e38d49%7Cc4f8a63255804a1c92371d5a571b71fa%7C0%7C0%7C638094853948894849%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=GYfxNFA5oYiL8wGZzuAvyur6t8oxBVqQYgDB8SWLIwg%3D=0 > > Starting with my +1 > > Even > > -- > > https://eur06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.spatialys.com%2F=05%7C01%7Cjukka.rahkonen%40maanmittauslaitos.fi%7C4f723d3633d343e143e308daf7e38d49%7Cc4f8a63255804a1c92371d5a571b71fa%7C0%7C0%7C638094853948894849%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=rCvk7GKM68zEfkMNNexSx2%2Flp1%2BK6ohRXGHmkQWwSW8%3D=0 > My software is free, but my time generally not. > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > > https://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fgdal-dev=05%7C01%7Cjukka.rahkonen%40maanmittauslaitos.fi%7C4f723d3633d343e143e308daf7e38d49%7Cc4f8a63255804a1c92371d5a571b71fa%7C0%7C0%7C638094853948894849%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=%2FWT%2FhEfr2WEZ3jIlTRhlY%2FNDWz3OBxhuqAOcJ%2BxRWkY%3D=0 > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Call for review and comments on RFC90: Direct access to compressed raster data
Even, Very nice! I am quite supportive. The interfaces make sense to me. Best regards, Frank On Fri, Jan 6, 2023 at 7:28 AM Michael Sumner wrote: > beautiful! > > This has been low level on my mind to ask about. Thanks! > > Cheers, Mike > > On Fri, 6 Jan 2023, 01:42 Even Rouault, > wrote: > >> Hi, >> >> I've submitted RFC90: Direct access to compressed raster data for review >> and comments: >> >> https://github.com/OSGeo/gdal/pull/7020 >> >> Summary: """ >> >> The document proposes 2 new methods to directly obtain the content of a >> window of interest of a raster dataset in its native compressed format. >> Those methods can be optionally implemented and used by drivers to >> perform: >> - extraction of a compressed tile as a standalone file from a container >> format (GeoTIFF, GeoPackage, etc.) >> - creation of mosaics from a set of tiles in individual files >> - lossless conversion between container formats using the same >> compression method >> """ >> >> 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 > -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ 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 FrankW On Mon, Nov 21, 2022 at 9:17 AM Kurt Schwehr wrote: > +1 KurtS > > On Mon, Nov 21, 2022, 5:43 AM 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 >> >> -- >> 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 > -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Call for discussion: RFC88: Use GoogleTest framework for C/C++ unit tests
On Sun, Nov 20, 2022 at 8:21 PM Even Rouault wrote: > Hi Frank, > > > I'm not a huge GoogleTest fan but then I'm also not saying it *worse* than > any alternative, but the reasons are reasonably convincing, and I'm happy > if those running and contributing tests are happy! > > Just curious what you don't like with GoogleTest ? > Even, There is nothing meaningful to offer. I've been mildly annoyed by the dependencies it implied in other projects (ie. PixelLoom), but really this is not material. My point was more along the line of "I hate every test environment / ticket system / language / ...", but that given that I do not find it worse than most. :-) Should I understand from the RFC that > https://github.com/rouault/gdal/tree/gtest implements the migration? > (ie. we have already done the work to migrate, we just need to agree on it?) > > Yes the implementation is ready in https://github.com/OSGeo/gdal/pull/6732 > . I find it more convincing when there's an implementation backing a RFC > (it was partial when I submitted the RFC and I finished it as the initial > feedback was positive) > Awesome. While sometimes it is a bit "heavy" to implement an idea before proposing it, it does make it much easier to adopt knowing the implementation is waiting in the wings. Best regards, Frank > Even > > -- http://www.spatialys.com > My software is free, but my time generally not. > > -- -------+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 <http://voice.google.com/calls?a=nc,%2B16507017823> and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Call for discussion: RFC88: Use GoogleTest framework for C/C++ unit tests
Even, I'm not a huge GoogleTest fan but then I'm also not saying it *worse* than any alternative, but the reasons are reasonably convincing, and I'm happy if those running and contributing tests are happy! Should I understand from the RFC that https://github.com/rouault/gdal/tree/gtest implements the migration? (ie. we have already done the work to migrate, we just need to agree on it?) Best regards, Frank On Fri, Nov 18, 2022 at 2:27 PM Javier Jimenez Shaw wrote: > I am not in the PSC, but this RFC sounds very good. Thanks! > > Now that the tests are going to change, maybe it is a good idea to apply > clang-format to them. > .___ ._ ..._ .. . ._. .___ .. __ . _. . __.. ... ._ .__ > Entre dos pensamientos racionales > hay infinitos pensamientos irracionales. > > > > On Wed, 16 Nov 2022 at 20:28, Kurt Schwehr wrote: > >> I am +1 for this switch, but I'm definitely biased by working at Google. >> My thoughts: >> >> tut definitely gets the job done, but I found it a bit awkward too. But >> I think the updates and the additional features of GoogleTest are probably >> worth it. I especially like the distinction between ASSERT.* that >> immediately stops a test when it finds and issue and EXPECT that lets the >> test move forward until the end of that test so that I can see all of the >> results of EXPECTS. The formerly separate "mock" capabilities are really >> handy too. >> >> I wrote a bunch of C++ GDAL tests using GoogleTests in the 2013-207 time >> frame (Even used a bit of that work as starters to the tests in PROJ, but >> he went way beyond what I had). I have a lot of the tests in github, but >> they are written against very old versions of GDAL. And, the GoogleTest >> ability to work with newer versions of C++ has gotten a lot stronger. >> C++17 wasn't even available when I wrote a lot of the test code. We have >> been upgrading GDAL and improving the tests, so if there is interest, I can >> try to do some updates to the repo. If any of the autotest2 code is used, >> the license should be switched from Apache 2.0 to the MIT style license >> mentioned >> here >> <https://github.com/OSGeo/gdal/blob/a394f9cb299b2c3c2159098483d1fece3a464fda/LICENSE.TXT#L15> >> . >> >> https://github.com/schwehr/gdal-autotest2/tree/master/cpp >> >> -Kurt >> >> >> On Wed, Nov 16, 2022 at 10:42 AM Even Rouault >> wrote: >> >>> Hi, >>> >>> As this is RFC season. I've prepared RFC88: Use GoogleTest framework for >>> C/C++ unit tests >>> >>> Text at https://github.com/OSGeo/gdal/pull/6720 >>> >>> Summary: >>> >>> The document proposes and describes conversion of the existing C/C++ >>> autotest suite to use the `GoogleTest >>> framework <https://github.com/google/googletest>`__. >>> >>> GoogleTest is a popular and maintained framework for C/C++ test >>> writing, that is a better replacement for the `TUT framework >>> <https://github.com/mrzechonek/tut-framework>`__ that we use currently. >>> >>> 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 > -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ 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 Frank On Sun, Aug 28, 2022 at 9:56 AM Kurt Schwehr wrote: > +1 KurtS > > On Sat, Aug 27, 2022, 5:43 AM 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 >> > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] JPEG compressed COGs nodata
G with JPEG compression with transparent > nodata values without much success. Is this possible without creating a > secondary mask? > > Any hints? > > Regards > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GEOS Maintenance Grant
+1 FrankW I'm very pleased as a GDAL PSC member and a sponsor who depends on the full stack. On Tue, Feb 15, 2022 at 2:46 PM Kurt Schwehr wrote: > +1 KurtS - GDAL PSC member > > On Tue, Feb 15, 2022 at 7:38 AM 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 >> > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ 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 FrankW On Tue, Jan 25, 2022 at 9:12 PM Daniel Morissette wrote: > +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 > -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Nodata is None, but still has blanks?
Matt, Tiffinfo reports the following. Note the "Transparency Mask" subfile. $ tiffinfo sample-no-mask.tif ... TIFF Directory at offset 0xe2 (226) Image Width: 304 Image Length: 285 Tile Width: 512 Tile Length: 512 Bits/Sample: 8 Sample Format: unsigned integer Compression Scheme: JPEG Photometric Interpretation: YCbCr YCbCr Subsampling: 2, 2 Samples/Pixel: 3 Planar Configuration: single image plane Reference Black/White: 0: 0 255 1: 128 255 2: 128 255 Tag 33550: 100.00,100.00,0.00 Tag 33922: 0.00,0.00,0.00,343739.586723,1091611.850704,0.00 Tag 34735: 1,1,0,7,1024,0,1,1,1025,0,1,1,1026,34737,21,0,2049,34737,6,21,2054,0,1,9102,3072,0,1,3578,3076,0,1,9001 Tag 34737: NAD83 / Yukon Albers|NAD83| JPEG Tables: (142 bytes) TIFF Directory at offset 0x33a (826) Subfile Type: transparency mask (4 = 0x4) Image Width: 304 Image Length: 285 Tile Width: 512 Tile Length: 512 Bits/Sample: 1 Sample Format: unsigned integer Compression Scheme: AdobeDeflate Photometric Interpretation: transparency mask Samples/Pixel: 1 Planar Configuration: single image plane Predictor: none 1 (0x1) This is recognised by GDAL and treated as a special kind of mask as indicated in the gdalinfo report: $ gdalinfo sample-no-mask.tif Driver: GTiff/GeoTIFF Files: sample-no-mask.tif Size is 304, 285 ... Origin = (343739.586723418149631,1091611.850704099284485) Pixel Size = (100.000,-100.000) Metadata: AREA_OR_POINT=Area Image Structure Metadata: COMPRESSION=YCbCr JPEG INTERLEAVE=PIXEL SOURCE_COLOR_SPACE=YCbCr Corner Coordinates: Upper Left ( 343739.587, 1091611.851) Lower Left ( 343739.587, 1063111.851) Upper Right ( 374139.587, 1091611.851) Lower Right ( 374139.587, 1063111.851) Center ( 358939.587, 1077361.851) Band 1 Block=512x512 Type=Byte, ColorInterp=Red Mask Flags: PER_DATASET Band 2 Block=512x512 Type=Byte, ColorInterp=Green Mask Flags: PER_DATASET Band 3 Block=512x512 Type=Byte, ColorInterp=Blue Mask Flags: PER_DATASET In QGIS's "Information" tab under properties I see: "More Information: Mask band (exposed as alpha band)" So QGIS is using the special mask as alpha. I find that if I do: tiffcp sample-no-mask.tif,0 x0.tif I get an "x0.tif" with just the jpeg image, and not the mask. That may be helpful for you (without uncompressing the jpeg image). Best regards, Frank On Mon, Jan 17, 2022 at 7:38 PM wrote: > I’m confused. The attached image has no Nodata, but when dropped into Qgis > and ArcGIS large areas are still drawn transparently, and there is no 4th > band for a mask or alpha. How is this happening? > > > > (I’m trying to get completely rid of all Nodata and Mask info, so as to > start over creating one of those from blank slate). > > > > *Matt Wilkie* > > Geomatics Developer & Administrator > > Environment | Technology, Innovation and Mapping > > T 867-667-8133 | *Yukon.ca <http://yukon.ca/>* > > *Hours: 08:30-16:30, Mon-Wed: Office, Thu: Remote, Fri: Away.* > > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] current geolocation array implementation status
Frederico, I've updated the ticket to reflect that I backed away from work on a new implementation. I would still like to see a reliable geolocation transformer. I am also still interested in the general topic of iterative approximate inverses for transformers which are not inherently invertible. Best regards, Frank On Tue, Nov 2, 2021 at 1:18 PM Even Rouault wrote: > Frederico, > > Le 01/11/2021 à 23:22, Frederico Liporace a écrit : > > Hello, > > > > I'm debugging an artifact that I encountered while using geolocation > arrays: > > https://github.com/OSGeo/gdal/issues/4707 > > > > While searching I found this ticket mentioning that the backward map > > implementation is broken and a new implementation is being considered: > > https://trac.osgeo.org/gdal/ticket/6959 > > > > I could help with this implementation. Is there more context available > > on why it is being reconsidered? It seems to me that the general case > > for the backward implementation is very hard - for instance, what kind > > of discontinuities (gaps, overlaps) would be allowed in the > > geolocation array? Would it be expected to be robust enough to correct > > the Landsat 7 ETM+ SLC-off for instance? My guess is not. > > Yes the general case is likely hard and would probably require special > techniques that could possibly be sensor specific. I guess the > requirements for improvements on the existing code would be at least not > degrade what works currently. > > An idea for a new implementation would be to use an iterative process > using the backward map as an initial guess and then iterating with the > bilinear interpolation of the forward path to refine the solution up to > convergence to some threshold of error to decide (could be 15% of a > pixel size like the default setting of the gdalwarp approximate > transformer of coordinate transformations) > > 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 > -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ 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 FrankW On Tue, Sep 14, 2021 at 9:59 PM 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 > -- ---+------ I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ 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 FrankW ! On Tue, Aug 17, 2021 at 10:33 PM 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 > -- ---+------ I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to deal with security related bug reports?
Even, I agree with you and Kurt that we should try to avoid the overhead of special security handling. MapServer is intended to be web facing. GDAL is not. That said, we should attempt to resolve security issues in the normal course of bug fixing and releases. If there is a strong case for a different approach, hopefully it will be made by folks willing to pay for the extra work (through sponsorship or other contributions). Best regards, Frank On Wed, Jul 28, 2021 at 3:36 PM Kurt Schwehr wrote: > My take is pretty much the same as Even's. I suggest that we add a > SECURITY.md that says we do not currently treat security bugs in gdal > privately and that we don't generally do specific releases for security > issues. I thought there used to be a statement somewhere in the files > that said that the code should not be considered secure / safe. I think we > should bring something like that back that says something along the lines > of: > > Some effort is made to ensure the code is safe, but analysis tools like > ossfuzz continually find issues in the code. Data from untrusted sources > should be treated with caution. When security is a major concern, consider > running GDAL or code using GDAL in a restricted sandbox environment. If > someone wants to specifically fund a security effort, then we can consider > doing something more. > > > I'm one of those running gdal in a space where security is a huge issue. > We (Google) have GDAL running in a very restricted sandbox for any > untrusted data. > > But, I'd definitely like to hear people with opposing views. > > -kurt > > On Wed, Jul 28, 2021 at 10:38 AM Even Rouault > wrote: > >> PSC, >> >> We just got https://github.com/OSGeo/gdal/issues/4146 from someone >> trying to get in touch with a security issue. How do we want to deal >> with that ? Personally dealing with all the secrecy about security >> issues is not super appealing and my natural inclination would be to >> deal with them as any other issue. >> >> An alternative, used by Mapserver, would be to setup a dedicated private >> github repository, where we would invite only users (but they are likely >> able to see all issues, not just theirs). Or perhaps just make a >> repository accessible to PSC / trusted developers, interact with the >> reporter through email (who wants to be in the email loop?) and paste >> there the report and updates, but that becomes cumbersome. >> >> Another point, assuming we have a private issue tracker, is, assuming >> the issue is confirmed and we have a fix for it, how do we deal with it >> ? My inclination would be to just commit the fix (the issue would become >> more or less public once a candidate pull request is issued) and not >> issue a dedicated release, but use our regular bugfix releases. >> >> Thoughts ? >> >> 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 > -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ 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
+1 FrankW On Tue, Jun 8, 2021 at 5:59 PM Kurt Schwehr wrote: > +1 KurtS > > On Tue, Jun 8, 2021 at 1:10 PM Even Rouault > wrote: > >> 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 >> >> -- >> 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 > -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ 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 FrankW I do think we need to give ourselves (the PSC) some latitude on how proposals are solicited and evaluated. I am quite pleased with the characterization of the maintenance tasks. Best regards, On Tue, Jun 8, 2021 at 9:37 AM Howard Butler wrote: > +1 Howard > > > On Jun 8, 2021, at 7:31 AM, Mateusz Loskot wrote: > > > > +1 Mateusz > > > > On Tue, 8 Jun 2021 at 12: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 > >> > >> -- > >> 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 > > > > > > > > -- > > 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 > -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ 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 Frank On Fri, Jun 4, 2021 at 12:36 PM Daniel Morissette wrote: > +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 > -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Formation of advisory board
Sounds good to me! On Thu, May 13, 2021 at 4:20 PM Even Rouault wrote: > PSC, > > Per > https://gdal.org/development/rfc/rfc80_numfocus_relationship.html#gdal-advisory-board, > we institute a Advisory Board with part of the sponsors. We need to put > that into reality soon. > > After discussing with Chris, here are the following suggestions: > > - consider May 31st as the deadline for the set of sponsors we consider in > the designation process of the representative of the Gold (at least, 1 > representative for every 3 Gold sponsors. Chris suggested we could ask each > if they'd like to be) and Silver (1 representative for the whole set of > Silver sponsors) sponsors for the year to come. > > - ask OSGeo SAC for the creation of a gdal-advisory-board mailing list. > Only approved subscribers will be allowed to post (representative of > sponsors + PSC members willing to be part of it + people benefiting from > funding), but it will be publicly archived. > > Any objection ? > > 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 > -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] About gdal RasterizeLayer
Miguel, I can't seem to find this in the docs, but I think what you want is "MERGE_ALG" set to ADD instead of the default REPLACE. https://github.com/OSGeo/gdal/blob/master/gdal/alg/gdalrasterize.cpp#L1165 This doesn't address the buffering (I guess you might still want to buffer the whole set), but it should take care of the additive step. I actually implemented this as part of a programming test for my current job - to build heatmaps of satellite coverage. Best regards, Frank On Tue, May 4, 2021 at 1:30 PM Miguel A. Manso wrote: > Dear all > > I have a multiline layer type (tracking) and I want to make a heat map > (densities) on a buffer of them, so that in those places where several > buffers overlap the density is added as many times as lines overlap. > > Now I'm doing it with a python script that reads from a shp the lines, > generates a buffer and rasterize the polygon filling it with a given > value with gda.RasterizeLayer(). I read the image as an array and with > numpy I add it to another array (accumulating). When I finish I convert > it to an image and save it in a geotiff. > > This procedure is relatively slow. Especially if you have to do it for > many lines. > > My question is along the lines of whether the RasterizeLayer function > itself could do this process in a more efficient way, making the burning > of the objects not an OR operation but an arithmetic sum... > > Any suggestions would be welcome. > > Regards > Miguel A. Manso > > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: adopt RFC80
+1 FrankW On Fri, Apr 16, 2021 at 12:53 PM Kurt Schwehr wrote: > +1 KurtS > > On Fri, Apr 16, 2021 at 7:50 AM 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 >> >> >> -- >> 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 > -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Sustainable GDAL initiative and fundraising
PSC Folks, Has work started on an RFC formalizing the NumFocus relationship, and the sponsorship program? I'd be interested in helping, though somewhat less in leading it. It feels like an important step to make a formal decision via our PSC procedures. Potentially we might want to do two RFCs, one for the relationship with NumFocus (and perhaps with the application being tied to the RFC), and one defining the sponsorship program. The use of sponsorship money for maintenance may fall under https://gdal.org/development/rfc/rfc9_maintainer.html or perhaps we will want to supersede that. For those interested, there has been extensive informal discussion of this effort with the PSC and a few other parties already, but no formal decision making yet. Best regards, Frank On Thu, Apr 15, 2021 at 9:58 AM Paolo Cavallini wrote: > Great news, thanks Even! > Long life GDAL. > > Il 15/04/21 15:31, Even Rouault ha scritto: > > All, > > > > I wanted to inform you about an initiative that the PSC recently > > started, and which is now sufficiently advanced to share and develop > > further publicly along with the larger GDAL community. As you all know, > > GDAL is a foundational piece of the open-source and proprietary > > geospatial software ecosystem. While the project has successfully > > attracted contributions for adding new features and capabilities, it > > lacked financial capacity and a vehicle to support difficult-to-fund > > maintenance and infrastructure. > > > > The PSC recently applied to be fiscally hosted by NumFOCUS > > (https://numfocus.org) to receive donations to provide that vehicle (*). > > I should underline that GDAL is and will continue to remain a OSGeo > > project for all other concerns. > > > > We approached a first round of potential sponsors and received > > substantial multi-year pledges, which make us confident that our minimum > > target, of being able to fund the equivalent of a full-time senior > > engineer for three years, will eventually be reached. These resources > > will help fund *several* co-maintainers, enable increasing the bus > > factor of the project, and address the many tasks (ticket triaging and > > addressing, CI maintenance, pull request reviews, release management, > > etc.) needed to make it even better. > > > > The sponsorship funding will be entirely used for activities that > > benefit the project and its associated dependencies such as PROJ, > > libgeotiff, and libtiff. The PSC will be developing procedures and > > details of how the sponsorship resources will be allocated, and we will > > update the GDAL website with them as they are finalized. > > > > Finally, we would like to thank our initial sponsors, who have provided > > the project with generous three-year pledges of support: > > - Platinium (50k USD/yr): Microsoft and Planet > > - Gold (25k USD/yr): Esri, Google, Safe Software > > - Silver (10k USD/yr): Koordinates, Sparkgeo, Mapgears > > > > On behalf of the PSC, > > > > Even > > > > (*) NumFocus being a 501(c)3 organization, donations from US companies > > and persons are tax deductible. > > > > > > ___ > > gdal-dev mailing list > > gdal-dev@lists.osgeo.org > > https://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > -- > Paolo Cavallini > www.faunalia.eu - QGIS.org > training, support, development on QGIS, PostGIS and more > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] What is lost when converting 12 bit imagery to 8 bit?
Patrick, FWIW, Rob's post is on the process he uses in Photoshop to prepare images for various venues. For imagery published through the platform we (Planet) do not use per-image white-point and black-point (or we would not have day to day, and scene to scene consistency). We do apply color curves Rob prepared in our automated process but with "fixed" black/white point which results in an automated 8bit RGB product that tends to be very suboptimal in dark or bright areas. The imagery Planet shows in our web-explorer interface is served from highly compressed JPEG-in-TIFF adding an additional layer of image damage. :-) While that pains me, we are keeping around nearly 3 billion scenes online at nearly full resolution for fast visualization so some compromises have to be made. Beyond nit-picking, I think my point is: - given 12bit "rawer" data you have the opportunity to do careful scene dependent conversion to 8bit in a way that best brings out the details available in the source data if you have the time and patience. - having this process done for you in advance by a skilled supplier (perhaps in such a way as to maintain reasonable consistency for large area coverages) may actually save you a lot of work if you mostly just want to fairly generic visualization - and it might even be a better visualization than you would do yourself if you aren't going to do a lot of work. Best regards, Frank On Wed, Mar 17, 2021 at 11:13 PM Patrick Young < patrick.mckendree.yo...@gmail.com> wrote: > I would guess you usually see 8bit RGB images because that is what your > monitor can display. What is lost is a deeper question, per channel you > have to squeeze the original [0 - 4095] pixel value range per channel down > to [0 -255], and there are lots of ways to do it. The problem is sometimes > called tone mapping > <https://en.wikipedia.org/wiki/Tone_mapping#:~:text=Tone%20mapping%20is%20a%20technique,a%20more%20limited%20dynamic%20range.>. > Planet had a nice blog post describing how they manually convert their > imagery to 8bit RGB here <https://www.planet.com/pulse/color-correction/>. > If you were using the imagery for analytic things (e.g. converting pixel > values to reflectance) you'd probably not want the 8bit product. > > To get GDAL in the mix, note that gdal_translate can do simple tone > mapping for you: > https://gdal.org/programs/gdal_translate.html#cmdoption-gdal_translate-scale > > Patrick > > > > > > On Wed, Mar 17, 2021 at 3:23 PM wrote: > >> SPOT 6/7 satellite imagery is captured with a dynamic range of 12 bits >> per pixel per channel (ref <https://eos.com/spot-6-and-7/>). However >> almost all of the SPOT imagery I have seen in use has been 8 bits per >> channel, and split into RGB natural colour (Bands-321) and Near-infrared-RG >> false colour (Bands-432). What information is lost in this 12 to 8 bits >> conversion? >> >> I'm wondering if we should be altering our request for purchase >> specifications to deliver the full bit depth. >> >> *Although I'm referencing SPOT imagery specifically the question is >> general and really applies to any satellite or sensor system.* >> >> Cross-post: >> https://gis.stackexchange.com/questions/390315/what-is-lost-when-converting-12-bit-imagery-to-8-bit >> >> >> >> >> >> *Matt Wilkie* >> >> Geomatics Analyst >> >> Environment | Technology, Innovation and Mapping >> >> T 867-667-8133 | *Yukon.ca <http://yukon.ca/>* >> >> *Hours: 08:30-16:30, Tue-Wed: Office, Thu-Fri: Remote.* >> >> >> ___ >> 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 > -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ 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
On Thu, Mar 4, 2021 at 11:40 AM Howard Butler wrote:
>
>
> > On Mar 4, 2021, at 10:32 AM, 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
>
> +1
>
> Howard
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
--
---+--
I set the clouds in motion - turn up | Frank Warmerdam,
warmer...@pobox.com
light and sound - activate the windows | +1 650-701-7823
and watch the world go round - Rush| Geospatial Software Developer
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: remove and deprecate a few drivers
On Wed, Mar 3, 2021 at 6:55 PM Even Rouault wrote: > Frank, > > Even, > > I'm -1 on this motion as it stands. There are a quite a few formats that > I think we ought to continue to support for archival purposes > indefinitely including FIT, JDEM, GMT, DOQ1/2, LAN, MFF, NDF, SDTS, SGI, > XPM, and TIGER. I am prepared to be listed as supporting maintainer for > these drivers. > > Those formats were aimed for the runtime deprecation mechanism. The idea > was to get ~ 1 year feedback period to see if people really need that > nowadays, which I strongly doubt about. There are Docker images of older > GDAL versions available for people that would still need to access such > archives. I believe I tried to make previously the point that the issue > wasn't the individual maintenance of those formats, but the weight they had > to the whole for little benefit to the majority of users & developers. > > Are you OK at least with the removal of the drivers I mentioned in the > first bullet of the motion ? (the ones of > https://github.com/OSGeo/gdal/pull/3373). I'm not willing to support them > any longer (and I'm not asking anyone to step up for that!) > Even > > -- http://www.spatialys.com > > Even, I'm ok with the removal list. I do not really agree with the deprecating the formats I listed. I feel like the deprecate and wait for useful feedback is more appropriate to formats that are hard to support now (like those depending on external libraries) and that the main kind of feedback to be sought would be someone willing to be responsible for them. Best regards, Frank -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: remove and deprecate a few drivers
Even,
I'm -1 on this motion as it stands. There are a quite a few formats that I
think we ought to continue to support for archival purposes
indefinitely including FIT, JDEM, GMT, DOQ1/2, LAN, MFF, NDF, SDTS, SGI,
XPM, and TIGER. I am prepared to be listed as supporting maintainer for
these drivers.
Best regards,
Frank
On Wed, Mar 3, 2021 at 1:49 PM Even Rouault
wrote:
> Hi,
>
> Following the discussions of past weeks, I motion to:
>
> - remove the vector drivers BNA, AeronavFAA, HTF, OpenAir, SEGUKOOA,
> SEGY, SUA, XPlane and raster drivers BPG, E00GRID, EPSILON,
> IGNFHeightASCIIGrid, NTv1. They have all been authored by myself and I'm
> not aware of them having been much used or being still in use.
> Implemented in https://github.com/OSGeo/gdal/pull/3373. They (driver
> code, doc and tests) have been moved to the
> https://github.com/OSGeo/gdal-extra-drivers
>
> - deprecate the raster drivers DODS, FIT, GS7BG, GSAG, GSBG, JDEM,
> JPEG2000, JPEGLS, MG4LIDAR,
> GMT, DOQ1, DOQ2, FUJIBAS, IDA, LAN, MFF, NDF, SDTS, SGI, XPM, ZMAP
> and vector driver ARCGEN, ArcObjects, CLOUDANT, COUCHDB, DB2, DODS, FME,
> GEOMEDIA, GTM, INGRES, MONGODB, REC, SDTDS, TIGER, WALK. They will now
> be disabled
> at runtime by default, unless the
> GDAL_ENABLE_DEPRECATED_DRIVER_{drivername}
> configuration option is set to YES, and will be removed in GDAL 3.5.
> Implemented in https://github.com/OSGeo/gdal/pull/3505
>
> Starting with my +1
>
> Even
>
> --
> http://www.spatialys.com
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
--
-------+--
I set the clouds in motion - turn up | Frank Warmerdam,
warmer...@pobox.com
light and sound - activate the windows | +1 650-701-7823
and watch the world go round - Rush| Geospatial Software Developer
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] New JPEG 2000 Driver
Folks, When Andrew first mentioned RFC 34 I skimmed it and was a bit surprised it existed though perhaps it seemed a wee bit familiar. Now that Even mentions it was not ever implemented I see that *I* proposed it and presumably did not actually follow up on implementing it or getting it adopted. It still seems like a vaguely good idea, but also apparently one without a compelling need since it has not been followed up on. However, it does not solve the build-time problem posed by Greg. I think the approach that inclusion of reciprocally licensed or proprietary drivers requiring explicit inclusion at configure time is a reasonable approach to avoid accidental license violations by packagers. Best regards, Frank On Wed, Mar 3, 2021 at 3:31 PM Even Rouault wrote: > Hi, > > https://gdal.org/development/rfc/rfc34_license_policy.html > > As indicated in the top of the RFC, its status is "development" (draft), > which here means stalled/non-adopted given that it was proposed long > time ago. So there's no runtime mechanism to control license compatibility. > > > > But, I'm worried about something different. As a packager, I'd like to > > know that unless I take the affirmative step of passing --enable-foo, > > for any GPLish or proprietary foo, I won't end up with a gdal build > > linked with foo just because it happened to be present in my build > > environment. > > This should normally be the case. One of the few GPL dependencies is > Poppler and must be explicitly enabled with --with-poppler . Similarly > with MySQL. All proprietary dependencies need also to be explicitly > enabled AFAIK (you actually need to point to their SDK). > > GEOS (LGPL) is enabled by default is found. > > Even > > -- > > http://www.spatialys.com > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] New JPEG 2000 Driver
Folks, The GDAL driver code would need to be licensed the same as the rest of GDAL (which I see from the PR is the case). It is fine for the Grok library to be under the AGPL as long as it is an optional dependency of GDAL. Folks who are prepared to comply with it's license can enable it at build time. While I'm somewhat sad about further complexification of the GDAL JPEG2000 landscape, I do not see a fundamental reason not to add a Grok based driver. That said, it would require a GDAL committer interested in addressing the PR. Best regards, Frank On Sat, Feb 27, 2021 at 2:51 PM Greg Troxel wrote: > > Even Rouault writes: > > > Can you transparently tell us why Grok is AGPL licensed ? Do you sell > > commercial licenses for people who couldn't comply with the AGPL license > ? > > Certainly a good question. I have no idea in this case and my comments > should not be taken to imply anything about this particular library > > I am guessing that gdal would not contemplate a license change to GPL > lightly, and that many (most?) would be opposed to changing to AGPL. > > My impression is that gdal is all MIT licensed, and that absen't giving > some configure arguments to link against proprietary libraries, one ends > up with a pure MIT licensed result. If that's wrong, please let me konw > and I'll fix up pkgsrc's metadata. > > Perhaps due to the use of AGPL in many cases as a club to sell > proprietary licenses, rather than as a tool to advaance software > freedom, or perhaps just due to concerns about network access, I think > there is a lot of concern about using AGPL software. When the software > is fundamentally a web service, that's one thing (e.g. nextcloud), but > when it's a library that then forces large amounts of other software to > be offered under AGPL (and perhaps only, with the rlying sources as > derived works notion), it seems broadly uncomfortable and in large part > unacceptable. > > My impression is that Debian does not have issues with AGPL3 as it it is > formally a Free Software license, even when being used to subvert > software freedom. However, I personally view AGPL3 as not reasonable > when there is a proprietary-license-also model. I do view it as > reasonable when there is no possibility to get a proprietary license AND > contributions are accepted back without any kind of mechanism that would > enable proprietary licenses (assignment or grants in a CLA). > > In pkgsrc, which I realize is a minority packaging system, we have > excluded AGPL from the set of defautl licenses (equivalent to Debian > main) because of the notion that people would find obligations > triggereed by merely running software with network access to be > surprising. So for us, a license change to AGPL would be a big deal. > > So while I'd like to understand the licensing stance of Grok, as long as > it's AGPL instead of MIT, it seems entirely out of the question to me. > I should note that I do not have any -1/+1 tokens to throw around, but > that doesn't stop me from ranting :-) > > Greg > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Considering drivers removal ?
On Tue, Jan 12, 2021 at 12:38 PM Howard Butler wrote: > The only question that matters here is "Who is going to maintain it?" and > if the answer to that is "no one", it should be removed. There doesn't need > to be any meetings because the only criteria that matters is if someone is > willing to maintain it. We should provide the list of drivers and assign > the GitHub handles that step forward to be responsible for each. If obscure > government one-offs formats have an audience of downtrodden government > users forced to use them, they need to put their handle in and take > ownership. They then need to find the time, money, or attention to carry > things forward. > Howard / Even, I'd be willing to commit to maintaining some of the archaic drivers that meet the conditions I mentioned (buildable, testable in core build). If Even would like I can provide a sublist of those he proposed i'd be willing to be responsible for. Best regards, -- ---+------ I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Considering drivers removal ?
Even,
My opinion is that old drivers which do not depend on external
libraries/services and that we have tests for should be retained until they
cause painful problems. I would be supportive of dropping drivers for
which there is no apparent interest, and that are not buildable and
testable due to dependence on external libraries and services. We can
always reintroduce them if someone comes forward and wants them and is
willing to help support them.
LAN, NTv1 and SDTS Raster are examples (IMHO) of relatively low value
drivers that should be retained because they are buildable, testable and
not problematic.
Best regards,
Frank
On Sun, Jan 10, 2021 at 6:02 PM Even Rouault
wrote:
> Hi,
>
> It's not spring yet, but I'm in a mood lately of axing useless things, and
> we
> probably have tons of candidate for that in GDAL, especially in drivers.
> I was going to just axe the DB2 driver
> (https://github.com/OSGeo/gdal/pull/3366) but the issue is more general.
>
> Any idea how we can know what is used and what isn't ? A "call-home"
> functionality where we would track driver usage would only be acceptable
> if
> people enable it and have network connectivity, so we won't probably get
> lots
> of feedback. Having a spreadsheet with the driver list and asking people
> to
> fill it would probably also receive little feedback. So the idea I had was
> to
> do something like the following in the Open() method of a candidate for
> removal:
>
> GDALDataset* FooDriver::Open( )
> {
>if( !Identify(poOpenInfo) )
> return nullptr;
>
>if( !CPLTestBool(CPLGetConfigOption("GDAL_ENABLE_DRIVER_FOO", "NO") )
>{
>CPLError(CE_Failure, CPLE_AppDefined,
> "Driver FOO is considered for removal in GDAL 3.5. You are invited "
> "to convert any dataset in that format to another more common one ."
> "If you need this driver in future GDAL versions, create a ticket at "
> "https://github.com/OSGeo/gdal (look first for an existing one first)
> to "
> "explain how critical it is for you (but the GDAL project may still "
> "remove it), and to enable it now, set the GDAL_ENABLE_DRIVER_FOO "
> "configuration option / environment variable to YES");
>return nullptr;
> }
> ...
> }
>
> That is, when we detect a file to be handled by the driver, emit the above
> error message and do not open the dataset, unless the user defines the
> environment variable.
> Similarly in the Create()/CreateCopy() methods.
> If we ship this in 3.3, with a 3.5 milestone for removal, this would offer
> a
> feedback period of one year / 2 feature versions.
>
> Here's my own list of candidates for retirement (probably
> over-conservative).
> Mostly based on gut feeling. None of them are particularly bad citizens,
> but I
> have no indication that they are still used, which doesn't mean they
> aren't.
>
> * Raster side:
> BPG
> DB2Raster
> DOQ1
> DOQ2
> E00GRID
> Epsilon
> FujiBAS
> GS7BG
> GSAG
> IDA
> JDEM
> JPEG2000 (Jasper): JP2OpenJPEG is a better replacement
> JPEGLS
> LAN
> MFF
> MG4Lidar ?
> NDF
> NTv1
> SDTS Raster
> SGI
> XPM
> ZMap
>
> * Vector side:
> AERONAVFAA
> ESRI ArcObjects
> ARCGEN
> BNA
> Cloudant
> CouchDB
> DB2
> DODS
> FMEObjects Gateway
> Geomedia MDB
> GMT ASCII Vectors
> GTM
> HTF
> INGRES
> MongoDB (the old one, superseded by MongoDBv3)
> OpenAIR
> REC
> SDTS
> SUA
> SVG
> TIGER
> WALK
>
>
> Anything you'd add / remove ?
>
> What is not obvious is what would be the criterion for keeping a driver:
> 1,
> 10, 100 users asking for the driver to be kept ?
> If a GDAL developer contributing to the overall good of the project needs
> the
> preservation of a driver to be able to justify its continued involvement,
> I'd
> tend to think it to be enough to keep it.
>
>
> 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
>
--
---+--
I set the clouds in motion - turn up | Frank Warmerdam,
warmer...@pobox.com
light and sound - activate the windows | +1 650-701-7823
and watch the world go round - Rush| Geospatial Software Developer
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Using GDALRPCTransform with a pre-loaded DEM
Julien, The least disruptive approach to this would be for you to store your DEM in a "memory dataset" and reference that. I've done this in the past when I had it in a numpy array by using the numpy driver. The "MEM" dataset can be used to reference approximately arbitrary in-memory arrays. Best regards, Frank On Mon, Sep 28, 2020 at 8:21 AM Julien Osman wrote: > Dear GDAL community, > > I use the RPC transformer available in GDAL (GDALCreateRPCTransformer > and GDALRPCTransform). > > To provide a DEM to the transformer, one needs to set the option > "RPC_DEM" with the path to the DEM file. In my workflow, this is not > very convenient because the DEM is already loaded in memory as a > GDALDataset. This means that I need to write it to the disk and let > GDALCreateRPCTransformer load it again. In my opinion, it would make > sens to open a little the API so one can provide the DEM directly as a > GDALDataset. > > If this is OK for you, I can implement this functionality and propose a > Pull Request. The solution I see would be to add a function > GDALRPCAddDEM, similar to GDALRPCOpenDEM without the part opening the > GDALDataset. What do you think? > > Best regards. > Julien Osman. > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev -- -------+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Serve COG images - GEE & Google Cloud Storage
Arun, For what it's worth, I routinely do this by preparing signed urls to the objects in GCS and just using normal /vsicurl/ references in mapfiles, etc. If you happen to be using boto libraries in Python signed urls can be created with the generate_url() call on "key" objects. Of course if you data is publish, you can just use the direct GCS urls without signing them. Best regards, Frank On Fri, Sep 4, 2020 at 8:38 AM Michael Smith wrote: > Another option is a fuse level driver that maps cloud storage to a drive > path. > > > > Mike > > > > > > -- > > Michael Smith > > US Army Corps of Engineers > > Remote Sensing/GIS Center > > > > > > *From: *gdal-dev on behalf of Travis > Kirstine > *Date: *Friday, September 4, 2020 at 8:35 AM > *To: *gdal dev > *Subject: *Re: [gdal-dev] Serve COG images - GEE & Google Cloud Storage > > > > > > There is a good article here on how to do this using MapServer and S3, > this may work for Google as well > > > > > https://github.com/mapserver/mapserver/wiki/Render-images-straight-out-of-S3-with-the-vsicurl-driver > > > > You can configure MapServer as a WMS server and add the layers to Open > Layers or take the extra step and configure MapCache to generate a tiled > output and caching using your WMS as source > > > > > > > > On Fri, 4 Sep 2020 at 03:01, Even Rouault > wrote: > > Arun, > > > > Not sure this completely answer your question, but GDAL has gained a > > Google Cloud Storage virtual file system handler similar > > to the AWS S3 one since the post you mention. > > See > https://gdal.org/user/virtual_file_systems.html#vsigs-google-cloud-storage-files > > > > Even > > > > > Hi > > > In this article, I came across about servicing rasters on AWS S3: > > > > https://www.azavea.com/blog/2019/04/23/using-cloud-optimized-geotiffs-cogs/ > > > , https://lists.osgeo.org/pipermail/gdal-dev/2015-October/042975.html > > > > > > I am trying to see if something similar exists for Google? I'm exporting > > > COG from Google Earth Engine (GEE) to a Google Cloud Storage bucket in > the > > > hopes to access and serve it with other layers using GeoServer or create > > > tile map services. I've many dates and many products (true color, false > > > color, ndvi) for many sites. So I'm not sure what's the best way to serve > > > them. I tried researching online, asking in StackExchange, GeoServer and > > > GEE forums and reaching out to a few people, but I couldn't get specific > > > info... Most info is on AWS and S3... > > > > > > My requirement is to somehow get the images of "GEE to bucket" exported > > > images into Openlayers (web mapping) and JavaScript (frontend). GEE can > > > export to my Drive or a GCP bucket. So serving from GEE to GCP to S3 > means > > > some download, unzip, zip and upload - so more time consuming and manual > > > steps. In my experience, AWS was costly (as my EC2 runs all the time) > than > > > a VPS server... > > > > > > I'll appreciate your help. Thank you! > > > > > > -- > > Spatialys - Geospatial professional services > > http://www.spatialys.com > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > > ___ gdal-dev mailing list > gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Complexity of algorithms
Zachary, The interesting geometry functions are essentially all from GEOS, so I'd suggest investigating there for information. https://trac.osgeo.org/geos/ Most GDAL raster operations are essentially linear in the number of pixels though there are a few things (like hole filling, and polygonization, and contour generation) that have more interesting properties. I am not aware an effort to characterize the complexity of these in the GDAL project though at least some thought went into complexity analysis when implementing some of these. Best regards, Frank On Wed, Sep 2, 2020 at 12:50 PM Zachary Déziel < zachary.dez...@usherbrooke.ca> wrote: > > > Hi all, > > > > Sorry for disturbing and I hope I am passing through the right channel for > my question. If not, please feel free to redirect me! > > > > I have been searching in the documentation and elsewhere for information > regarding the time complexity of the algorithms of GDAL/OGR. More precisely > around the classic operations on point, line and polygon data structures > (buffer, intersect, etc). I have not found any mention of complexity in the > documentation. Is there some hidden documentation gem somewhere that covers > the time and/or memory complexity of the algorithms? If no such > documentation exists, are there reasons for it not existing? Is it simply a > matter of not being a priority in the development cycle? > > > > Sorry for the compact and numerous questions, if you have any interest in > the subject please reach out. > > > > Sincerely, > > > > Zac > > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Python/Java GDAL - How to estimate the geo coordinates and width / height without warping dataset?
Pham,
My point was that I use gdalwarp itself along with all the options (such as
setting the target resolution), but to VRT format. I imagine the
"commandline gdalwarp API" interface would be able to do this from Java.
If often just shell out and run the command.
Best regards,
Frank
On Tue, May 19, 2020 at 12:37 PM Pham Huu Bang wrote:
> @Even Rouault
>
> Unfortunately, this method is not enough to solve my problem as I *also
> have a given geo X, Y resolutions *in target CRS (EPSG:4326) as input.
>
> Below is what I've with Python GDAL:
>
> src_ds = gdal.GetDriverByName("VRT").Create("", 1830, 1830)
> src_ds.SetGeoTransform([60.000, 60, 0, 5900040, 0, -60])
>
> // source CRS EPSG:32632
> src_srs = osr.SpatialReference()
> src_srs.ImportFromEPSG(32632)
> src_wkt = src_srs.ExportToWkt()
>
> // destination CRS EPSG:4326
> dst_srs = osr.SpatialReference()
> dst_srs.ImportFromEPSG(4326)
> dst_wkt = dst_srs.ExportToWkt()
>
>// This method doesn't have the possibility to add the given geo X, Y
> resolutions in EPSG:4326 (!)
> dst_ds = gdal.AutoCreateWarpedVRT(src_ds,
> src_wkt,
> dst_wkt,
> gdal.GRA_NearestNeighbour,
> 0.125)
>
> On Tue, 19 May 2020 at 18:14, Even Rouault
> wrote:
>
>> On mardi 19 mai 2020 12:01:58 CEST Frank Warmerdam wrote:
>>
>> > Pham,
>>
>> >
>>
>> > I have sometimes taken the approach of doing a "gdalwarp to VRT" which
>>
>> > creates the configuration of the target dataset in VRT format, but does
>> not
>>
>> > actually resample any imagery. The you can open the VRT and query it's
>>
>> > configuration. There are also lower level apis to get this information
>> but
>>
>> > they are not normally exposed through SWIG in Java, Python, etc as far
>> as I
>>
>> > know.
>>
>> >
>>
>>
>>
>> gdal.AutoCreateWarpedVRT() is available in Java bindings:
>>
>>
>>
>> https://gdal.org/java/org/gdal/gdal/gdal.html
>>
>>
>>
>> Even
>>
>>
>>
>> --
>>
>> Spatialys - Geospatial professional services
>>
>> http://www.spatialys.com
>>
>
--
---+--
I set the clouds in motion - turn up | Frank Warmerdam,
warmer...@pobox.com
light and sound - activate the windows | +1 650-701-7823
and watch the world go round - Rush| Geospatial Software Developer
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Python/Java GDAL - How to estimate the geo coordinates and width / height without warping dataset?
Pham, I have sometimes taken the approach of doing a "gdalwarp to VRT" which creates the configuration of the target dataset in VRT format, but does not actually resample any imagery. The you can open the VRT and query it's configuration. There are also lower level apis to get this information but they are not normally exposed through SWIG in Java, Python, etc as far as I know. Best regards, On Tue, May 19, 2020 at 11:59 AM Pham Huu Bang wrote: > Hello, > > I have a Sentinel 2 in UTM32 with these metadata from gdalinfo: > > Size is 1830, 1830 > Pixel Size = (60.000,-60.000) > Lower Left ( 60.000, 5790240.000) > Upper Left ( 60.000, 5900040.000) > > How can I have these same metadata* by GDAL Python/Java binding* but in > EPSG:4326, given Pixel Size = (0.0007000,-0.0007000) *without > running gdalwarp*? > > Because, the input file can be big and I don't need the reprojected file, > just need these metadata in EPSG:4326, for example: > > Size is 2395, 1454 > Lower Left ( 10.4649804, 52.2224083) > Upper Left ( 10.4649804, 53.2402083) > > I've tried to find some method, but this one only exist in C++ ( > GDALSuggestedWarpOutput) > https://github.com/OSGeo/gdal/blob/106c8288e7a05f4efc1a588c5a3b2da7ec52d915/gdal/alg/gdaltransformer.cpp#L177 > > Thanks, > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev -- -------+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] COG - RGBI
Travis, The big benefit of JPEG compression comes with YCbCr color space which I do not believe can be mixed with a 4 band RGBI product. So I'm not sure how one would do this. One could certainly put the NIR in a distinct directory in the GeoTIFF, but not many applications would know how to utilize that, and it would not appear as just a 4th band from the GDAL view of things. In theory you could do BAND interleaved JPEG and compress each of the 4 bands separately but I do not think you get a great quality/compression result from this. I'm also curious if you were wanting to just do 8bit or 12/16bit? I would love to have a way of distributing 12/16 bit RGBI data with a good (gentle) lossy compression and good application compatibility in TIFF. Best regards, Frank On Fri, May 8, 2020 at 3:08 PM Travis Kirstine wrote: > Is it possible to create RGBI Cloud Optimized Tiffs with JPEG compression? > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | +1 650-701-7823 and watch the world go round - Rush| Geospatial Software Developer ___ 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 Frank On Tue, Oct 8, 2019 at 6:49 AM Even Rouault wrote: > Hi, > > This motion is to spend 5 USD/month * 12 = 60 USD annually to buy one > "data > pack" ([1]) to extend the quota of the OSGeo GitHub organization for LFS > (Large File Storage) from > 1 GB of storage + 1 GB /month of bandwith > to > 50 GB of storage + 50 GB/month of bandwidth > > This is within our yearly 5000 USD budget, for which we have already spent > 4107.60 USD for Travis-CI > > The first & main beneficiary of this GitHub LFS extension will actually be > the > proj-datumgrid repository, that has just reached the bandwidth quota: > https://github.com/OSGeo/proj-datumgrid/issues/57 > > ~~ > > My vote: +1 > > Even > > [1] > > https://help.github.com/en/articles/about-billing-for-git-large-file-storage > > -- > 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 -- -------+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | and watch the world go round - Rush| Geospatial Software Developer ___ 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 Frank On Tue, Sep 17, 2019 at 9:21 AM 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 -- ---+------ I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | and watch the world go round - Rush| Geospatial Software Developer ___ 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 Frank On Tue, Sep 17, 2019 at 9:22 AM 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 -- ---+------ I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | and watch the world go round - Rush| Geospatial Software Developer ___ 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 Frank On Wed, May 15, 2019 at 9:45 AM Daniel Morissette wrote: > +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 -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | and watch the world go round - Rush| Geospatial Software Developer ___ 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 ?
Even, I think calling it 3.0 would be reasonable. Best regards, Frank On Wed, May 1, 2019 at 11:56 AM 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 -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | and watch the world go round - Rush| Geospatial Software Developer ___ 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 Frank I think we are using it at scale and have ironed out our problems. On Tue, Dec 18, 2018 at 10:16 AM Tamas Szekeres wrote: > +1 > > Tamas > > > Even Rouault ezt írta (időpont: 2018. dec. > 18., K, 12:35): > >> 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 >> >> -- >> Spatialys - Geospatial professional services >> http://www.spatialys.com >> ___ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/gdal-dev > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Twenty years of GDAL !
Even, Wow, 20 years! Thanks for pointing out this milestone. It is a huge pleasure to know that: - it has been a core technology supporting so many other software packages and projects - it has been a project that lots of people have felt comfortable contributing to GDAL is the core of our data processing pipeline at Planet where we have a number of esoteric internal GDAL drivers, so I continue to use it every day. Special thanks to Even who's outsize contribution has kept the project healthy and progressing as I focused on other activities. Best regards, Frank On Wed, Oct 17, 2018 at 6:51 PM Even Rouault wrote: > Hi, > > I nearly missed it [1] (actually I'm already on the 18th here, but let's > consider > Canadian time so still on the 17th), but exactly 20 years go on Oct 17th > 1998, > Frank Warmerdam committed for the first time in the CSV repository. > > ''' > commit 149db916aafcbee9bb64572fafda83441c94a552 > Author: Frank Warmerdam > Date: Sat Oct 17 19:24:36 1998 + > > Initial implementation. > > > git-svn-id: https://svn.osgeo.org/gdal/trunk@2 > f0d54148-0727-0410-94bb-9a71ac55c965 > ''' > > > https://github.com/OSGeo/gdal/commit/149db916aafcbee9bb64572fafda83441c94a552 > > 169 lines for a first version of the virtual I/O layer... > > Since then, > * 39075 commits have been added on top of it, > * 159 raster drivers > * 96 vector drivers [2] > * by 161 committers (actually there are more contributors, here just > counting > the ones who have directly authored a CVS, SVN or git commit), > * adding 7110 files in the repository, for a grand total of > * 2.192 millions lines in 3745 files with extensions c, cpp, h, hh, hpp, > py, > html, java, cs, i, pl, vc, sh, bat, dox, ac, GNUmakefile (80 MB) (all > the text files) > so an average of 300 lines per day added > * 64 releases > * 6287 tickets closed > * 49097 messages posted on gdal-dev > * more than 100 software proudly mentionning using it > > Happy birthday and long life to GDAL and its commmnity of contributors, > either > by code, documentation, testing, packaging, reports, ... ! > > Even > > [1] thanks to Robert Coup for reminding me a few days ago about the > approaching date ! > [2] you'll note that 155 + 96 = 255, but I don't think there's a > Byte limitation for the number of drivers ... > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com > -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Proposed updates to the GDAL feature style spec
Alan, I'm also supportive of your change while not having a strong opinion on the ogr-brush-1 issue. Thanks for showing some love to feature styles *including* the specification. Best regards, Frank On Wed, Jan 3, 2018 at 12:52 AM, Alan Thomas <atho...@thinkspatial.com.au> wrote: > Thanks for the feedback, Even. If there is no other feedback in the > next few days I will merge the change, as well as an extra code fix to > implement change 8. > > On 2 January 2018 at 21:47, Even Rouault <even.roua...@spatialys.com> wrote: >>> 5. [...] change the definition of >>> ogr-brush-1 to mean a solid fill in the selected background color; >>> change the suggested default for BRUSH bc to transparent >>> (#FF00). >> >> I'd suggest that we add a rule so as to keep the current semantics: if >> ogr-brush-1 is used, then bc must be omitted (or set to a color with >> alpha=0). It would be confusing to have the possibility to have 2 ways to >> express a solid fill with either ogr-brush-0 + fc or ogr-brush-1 + bc. So >> people wanting a solid fill should use ogr-brush-0 (or don't specify it) >> > > I expected that this might be a problematic change. I'm happy to leave > ogr-brush-1 alone. If existing code is already special-casing > ogr-brush-1, then keeping the spec the way it is would be less > confusing. > > Therefore line 492 will say "null brush (transparent - no fill, > irrespective of fc or bc values)". > > Alan > > -- > Alan Thomas > Software Developer > ThinkSpatial > http://www.thinkspatial.com.au > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] vsicurl configuration design decisions
Sean, The obvious answer is that interfaces that are organized around the dataset name do not make it easy to transport other parameters in a way that is specific to one dataset. While I worry a bit about complex dataset syntaxes I do think there is a power to embedding these options in the dataset name. I sometimes wish we had a more generalized way of wrapping options into dataset names with clear escaping rules, and a way to avoid interference between different levels of wrapping and virtualization. I would add that I requested a mechanism to control /vsicurl/ retry strategies as we this machinery widely and failure to do "normal retries" in /vsicurl was a problem for us. Best regards, Frank On Mon, Oct 9, 2017 at 7:18 PM, Sean Gillies <s...@mapbox.com> wrote: > Hi all, > > It's written in > http://gdal.org/gdal_virtual_file_systems.html#gdal_virtual_file_systems_vsicurl: > >> Starting with GDAL 2.3, options can be passed in the filename with the >> following syntax: /vsicurl/option1=val1[,optionN=valN]*,url=http://... > > I'd like to discuss the design decisions that are being made here before > this gets out into the world. > > I'm uncomfortable with the way configuration is spread between environment > variables, config options that surface in the API, and also in identifiers. > I don't think it's a great idea to that expand the amount of configuration > in dataset identifiers. It's redundant, the syntax is complicated, and it > dilutes the network effects of reusing identifiers in our applications. > > Are there specific advantages to this > > ogrinfo -so /vsicurl/max_retry=10,url=https://example.com/poly.shp > > that we can't also have with a curl-style > > ogrinfo -so --max-retry=10 /vsicurl/https://example.com/poly.shp > > or, better yet, in my opinion > > ogrinfo -so --max-retry=10 https://example.com/poly.shp > > on the command line? > > -- > Sean Gillies > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] A modified version of your get_soundg.py
Dave, Thanks for the notice. I am not updating the upstream get_soundg.py but I've taken the liberty of cc:ing this reply to the gdal-dev mailing list so more potentially interested folks will be aware of your changes, and your blog post: http://micuisine.com/code-projects/?page_id=10 I was particularly amused by change entry "Changed feat2 to feat1 to prevent searching for unused feat1.". Indeed looking back at the code there must have been some history behind my use of feat2 that was lost and now is just confusing. Best regards, Frank On Sat, Jul 29, 2017 at 7:46 AM, Dave Liske <d...@micuisine.com> wrote: > Mr. Warmerdam, > > In recently looking for a method to split the depth values from NOAA S-57 > files for a personal art project, I came across your 2003 get_soundg.py file > for accomplishing the task via Python. In running your file with > us3fl28m.000 I found that it did, in fact, accomplish what I was trying to > do. But it also generated a number of errors, the reasons of which are not > clear as it likely didn't generate those same errors in 2003 when you > originally released the script. > > Sir I know this is out-of-the-blue but I wanted you to know that, with some > changes to correct current errors, your 2003 code still does what you > intended. I then took it a few more steps to hopefully make it more useful > for some as well. > > I've made the following changes, saving the new version as > s57_kml_extract_soundg.py: > > * Added error handling if SOUNDG layer or source S-57 file is not found. > * Deleted second usage argument: Added code to create target file in same > directory as source S-57 file. > * Added new second usage argument: Select soundings as provided as 'metre', > or calculate new sounding values as 'feet' > * Target File Type: Changed to KML. Errors are subsequently handled > correctly, i.e. the errors are suppressed while the FFPT_RIND and LNAM_REFS > fields are also not included in the resulting KML file. > * Added "_metre" or "_feet" to the new filename based on second usage > argument > * Added WGS84 CSR to the target KML file. > * Changed created layer name from 'out' to 'KML_SOUNDG'. When imported into > QGIS the resulting layer is displayed as _KML_SOUNDG_Point in the > Browser Panel. > * Changed target field 'ELEV' to 'DEPTH', which is accurate for soundings. > * Changed precision for 'DEPTH' field from 4 to 0 to reflect chart usage. > * Added target fields 'LAT' and 'LONG' for xcoord and ycoord. > * Changed feat2 to feat1 to prevent searching for unused feat1. > * Added completion messages. > > I've posted the new code at http://micuisine.com/code-projects/?page_id=10 > along with further descriptions, as well as a link to a ZIP file containing > s57_kml_extract_soundg.py. > > I hope this email finds you well, and that these updates are useful and not > offensive in some manner. Please feel free to contact me with any comments > or questions about this updated work. > > Sincerely, > Dave Liske > Luna Pier, Michigan -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Dropping dlopen/LoadLibrary loading of proj.4 ?
Even, I'm +0 on this change. On the one hand, I *like* the fact that the dlopen() approach means that adding libproj.so after the fact means that GDAL starts supporting coordinate system conversion without a rebuild. On the other hand, it isn't clear why we do this only for libproj. I have some appreciation for Ivan's stated concerns with regard to regression, but I don't think that should hold back cleanup in major new versions. Best regards, Frank On Sat, May 6, 2017 at 12:09 PM, Even Rouault <even.roua...@spatialys.com> wrote: > Ivan, > > > >> I understand the good intention of cleaning up code but that should not > >> remove functionality. You are breaking backward compatibility. What if > >> someone updates GDAL in some installation, proj4 is there and it will not > >> going to be used? > > > > Well that would be documented in the release notes... There are a number of > breaks in each new release. That's not really different. And the way of > solving in the case you mention is rather simple. > > > >> I my case, I *cannot* distribute proj4 into my GDAL build > > > > I've the feeling you're abusing -1 for a reason which you mentionned > privately to me but in my opinion isn't really valid for the rest of the > community. But this is not an important enough topic for me to fight about > and create useless tensions among contributors. > > > > So I'm dropping the ball on this. For posterity, my patch is at: > > https://trac.osgeo.org/gdal/ticket/6882 > > > > > > 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 -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Feasibility of expanding VRT schema to allow users to specify X/Y dimension for HDF data?
Brian / Even,
Certainly it is desirable for the HDF (and perhaps other super
flexible formats like netcdf) to support an open option to select
alternative axes. But the ability to transpose a dataset could also
be quite valuable in the VRT driver to "fix" any input transposed
dataset.
I'm also not entirely certain why one couldn't supply an appopriately
transposed geotransform to accomplish something similar. This could
be done without any code changes in the existing VRT format.
Best regards,
Frank
On Thu, Aug 4, 2016 at 3:32 PM, Even Rouault <even.roua...@spatialys.com> wrote:
> On Thursday 04 August 2016 16:31:25 H. Joe Lee wrote:
>> Hi,
>>
>> My name is Joe Lee and I'm very interested in improving GDAL's
>> capability to access NASA HDF4/HDF5 data so that users can work with
>> HDF easily through GDAL. For example, my goal is to allow users to
>> translate any HDF data into GeoTIFF via gdal_translate.
>>
>> I've worked with diverse NASA HDF products and provided solution for
>> visualizing data correctly through Python/MATLAB/IDL/NCL [1] and I
>> know that many products, other than HDF-EOS, may not work well with
>> GDAL because HDF is flexible and NASA data producers do not
>> necessarily follow the conventions that GDAL uses.
>>
>> By default, GDAL HDF4/HDF5 driver uses the following convention for
>> unknown products.
>>
>> For HDF4 (frmts/hdf4/hdf4imagedataset.cpp):
>>
>> // Search for the starting "X" and "Y" in the names or take
>> // the last two dimensions as X and Y sizes
>> iXDim = nDimCount - 1;
>> iYDim = nDimCount - 2;
>>
>> For HDF5 (frmts/hdf5/hdf5imagedataset.cpp):
>>
>> int GetYIndex() const { return IsComplexCSKL1A() ? 0 : ndims - 2; }
>> int GetXIndex() const { return IsComplexCSKL1A() ? 1 : ndims - 1; }
>>
>> The above code works well as long as Unknown HDF product follows the
>> above convention. However, in reality, HDF data can have an arbitrary
>> order in terms of Band, X and Y dimension like this:
>>
>> dset4D[XDim=360][YDim=180][Band1=2][Band2=3]
>> dimindex:0 12 3
>>
>> Since ndims=4, ndims-2 becomes 2 and ndims-1=3. In such case, GDAL
>> generates 360x180 bands of 2x3 images, instead of the desired 2x3
>> bands of 360x180 images.
>>
>> Thus, I'm wondering if GDAL can expand VRT schema so that VRT allows
>> users to specify the correct dimension index because specifying
>> dimension order for each different NASA product in [1] is
>> impractical. For example, I'd like suggest a new tag like
>> "SourceDimension" like below:
>>
>>
>>
>> > relativeToVRT="0">HDF4_SDS:UNKNOWN:"DATA_WITH_4D_DATASET.hdf":7> ame>
>> 1
>> > DataType="UInt16" BlockXSize="360" BlockYSize="180" />
>>...
>>
>>
>>
>> Once user specifies correct dimensions by editing VRT, it can be
>> used by GDAL HDF4/HDF5 drivers and the HDF drivers read the data
>> correctly for GDAL's image buffer.
>>
>> Do you think it's right and feasible approach to solve wrong X/Y
>> dimension order problem? Or do you have any other existing solution
>> that can mitigate this problem in GDAL? The GEE project team has
>> experimented the idea by creating another separate XML file [2] but I
>> think it's time to sync with GDAL development team and come up with
>> the most elegant solution. In my opinion, VRT looks best and I wish
>> GDAL development team can give me some feedback on this idea.
>
> Joe,
>
> I would rather suggest to add open options to the drivers and pass them with
> the exiting VRT OpenOptions element, rather than adding a new element in the
> VRT that would be specific of a few drivers
>
>
>
> relativeToVRT="0">HDF4_SDS:UNKNOWN:"DATA_WITH_4D_DATASET.hdf":7
>
> 0
> 1
>
> 1
> BlockXSize="360" BlockYSize="180" />
>...
>
>
> Which is equivalent to:
>
> gdalinfo HDF4_SDS:UNKNOWN:"DATA_WITH_4D_DATASET.hdf":7 -oo RASTERXDIM=0 -oo
> RASTERYDIM=0
>
>
> 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
--
---+--
I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Software Developer
___
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 Frank Welcome aboard Lucien! On Tue, Feb 23, 2016 at 4:42 PM, Kurt Schwehr <schw...@gmail.com> wrote: > +1 Kurt > > On Tue, Feb 23, 2016 at 4:10 PM, Even Rouault <even.roua...@spatialys.com> > 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 ) >> >> -- >> 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 > > > > > -- > -- > http://schwehr.org > > _______ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ 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 Frank I've spoken (emailed) with David a few times over the years, and I would be pleased to have him taking direct care of the DB2 driver, and potentially helping on other aspects of GDAL assuming the usual agreement to the committer guidelines. Best regards, Frank On Wed, Dec 2, 2015 at 5:04 PM, Mateusz Loskot <mate...@loskot.net> 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, > -- > Mateusz Loskot, http://mateusz.loskot.net > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev -- -------+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ 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
Folks, I worked closely with Kurt at Google, and I am very supportive of adding him to the GDAL PSC. +1 Frank Best regards, Frank On Wed, Oct 7, 2015 at 4:54 PM, Even Rouault <even.roua...@spatialys.com> 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 > > -- > 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 -- ---+------ I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ 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 59 (v2): GDAL/OGR utilities as a library
Even / Faza, I clearly should have been commenting sooner. I am concerned that having messy structures of options for each program is going to complicate maintaining the actually commandline programs, and that it will still be a fragile and complicated point of entry as commandline arguments evolve over time. I'd prefer if the approach had just been to embed the main()'s in a library and to still pass the exact same vector of arguments (in the char **argv format) to these functions instead of shelling out a program. I'd also have (as usual) preferred this to be embedded in libgdal.so so there weren't additional library layers to keep track of. We are clearly a kitchen sink style library - lets own that. :-) I would love to be able to replace many places where I shell out to run gdal command line programs with a library call with essentially the same arguments. PS. One benefit of built-in programs is that I can do things like invoke gdal_translate on an in memory data by using the right name for it since it is in the same process space. Lack of that has frequently frustrated me. It would also mean you could register new formats without having deploy plugin .so's, or register VRT plugin functions more easily. Best regards, Frank On Wed, Aug 26, 2015 at 11:27 AM, Even Rouault even.roua...@spatialys.com wrote: Hi, Summer of code 2015 being finished now, Faza's work now include librarification of gdalinfo, gdal_translate, gdalwarp and ogr2ogr. Faza will continue working on some other utilities. We'd be happy to hear about your comments, especially on the API. So speak now please. The overview of the work is there: https://trac.osgeo.org/gdal/wiki/rfc59_utilities_as_a_library I'd like to call for a vote soon as I'd want that to be merged as soon as possible, so it gets more widely tested and to avoid increasing merge difficulties. 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 -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RPC orthorectification accuracy issues.
Even, I feel that the RPC coefficients have well establish meanings from the NITF spec, and file formats like _rpc.txt. I assume they are center-of-pixel oriented. I would *not* want the RPC metadata we keep (ie https://trac.osgeo.org/gdal/wiki/rfc22_rpc) to have a different meaning for the pixel/line locations. So I would suggest we should not need to transform the RPC coefficients when they are imported - instead it is the evaluator which needs to adapt between the RPC pixel/line model and the usual GDAL interpretation. I'll note this opinion in the ticket as well. This is going to be moderately distruptive. :-( Pablo - thank you for bringing this to light! Best regards, Frank On Fri, Jun 19, 2015 at 7:35 AM, Even Rouault even.roua...@spatialys.com wrote: Le vendredi 19 juin 2015 15:47:54, Pablo d'Angelo a écrit : Dear GDAL Developers, i have recently compared the results of our internal RPC based orthorectification software and have found several difference, which I think are due to various corner vs center of pixel issues in the RPC transform code. This lead to significant shifts when using lower resolution DEMs, such as SRTM, particularly in hilly and mountainous regions. I have prepared an analysis and patches to fix these issues at: https://trac.osgeo.org/gdal/ticket/5993 Hi Pablo, I had seen your well documented ticket and wanted to give feedback. Thanks for the reminder. To my opinion, adjustments between vendor/formats conventions and the GDAL convention (0,0=upper-left corner of upper-lef pixel) should be done during the reading of the RPC parameters from their source (similarly to what is done when reading a geotransform with pixel-is-center convention), so as to make the https://trac.osgeo.org/gdal/attachment/ticket/5993/fix_RPCTransformPoint.patch patch unnecessary. Apart .rpb and .rpc_txt, we can also read RPC from GeoTIFF, NITF, ENVI, Oracle, PCIDSK... so I'm wondering what our situation is related to them. Of course this also leaves the embarassing question of which convention to adopt when writing RPC values in .rpb or _rpc.txt files... Probably DG convention for .rpb ? fix_rpc_dem_interpolation.patch looks good to me. 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 -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to check whether a GRIB file uses a sphere or a spheroid?
Simon, I skimmed the code and there is no actual datum support in the grib reader. It does attempt to differentiate between ellipsoids and spheres so I assume the file actually did record things as a sphere. Generally speaking it is not clear to me that the GRIB driver can actually do better based on the information in the files but I'd be happy to be proven wrong. In the meantime, it appears you will need to overwrite the geographic coordinate system in your ingestor. Best regards, Frank On Wed, Mar 11, 2015 at 1:25 PM, Simon (Vsevolod) Ilyushchenko sim...@google.com wrote: Hi, If I use GDAL to read GRIB files like these: ftp://hydro1.sci.gsfc.nasa.gov/data/s4pa/NLDAS/NLDAS_NOAH0125_H.002/2015/065/NLDAS_NOAH0125_H.A20150306.1300.002.grb the CRS I get back is: GEOGCS[Coordinate System imported from GRIB file, DATUM[unknown, SPHEROID[Sphere,6371200,0]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433]] Plotting these files shows that they are shifted 1.5 pixels north, but setting CRS to EPSG:4326 that uses SPHEROID[WGS 84,6378137,298.257223563 instead fixes the issue. I'm trying to understand whether the source files incorrectly specifies that it's a sphere, or whether the GDAL driver is wrong, but I cannot find a GRIB reader that would show me this information about the file. What's the best way to debug this? Thanks, Simon ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal.FileFromMemBuffer
Patrick,
After the FileFromMemBuffer() call, the content has been copied to an
internal buffer. I think the C++ API has a way of avoiding the copy (if
desired) but the python does not.
The good thing is, no need to worry about the lifetime of the request
result object.
Best regards,
Frank
On Mon, Feb 23, 2015 at 12:12 PM, Patrick Young
patrick.mckendree.yo...@gmail.com wrote:
Hi all,
I've been playing around a bit with the vsimem stuff in gdal using python,
works great! Basically, I'm getting a json response from an ArcServer
endpoint and I want to get out of the ESRI world as quick as I can.
My question is, when I do something like this,
r = requests.get(url, params=payload, timeout=timeout)
gdal.FileFromMemBuffer('/vsimem/temp', r.content)
does the buffer get copied to the created virtual file? I know I need to
clean up with a gdal.Unlink(('/vsimem/temp'), but does something bad happen
when Python frees the r request?
Thanks a ton!
-Patrick
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
---+--
I set the clouds in motion - turn up | Frank Warmerdam,
warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Software Developer
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Appoint Even Rouault PMC Chair
Folks, The motion passes with support from Frank, Tamas, Howard and Daniel. Thanks for taking this on Even! Best regards, Frank On Mon, Jan 5, 2015 at 12:45 PM, Frank Warmerdam warmer...@pobox.com wrote: Folks, Motion: Appoint Even Roualt as GDAL Project Management Committee Chair +1 Frank --- For at least a couple years, if not longer, Even has been the leading contributor to the GDAL project. As we start a fresh year in the middle of the 2010s I think it is time for us to formally acknowledge Even as the project leader. The PMC chair doesn't really have many responsibilities, beyond ensuring that the PMC operates in an orderly fashion and acting as liason to the OSGeo board when needed. But it is also a recognition of Even's great work, technically and increasingly in other outward facing efforts such as his upcoming presentation on GDAL at FOSS4G NA in March. I am very pleased to have my project pass into his capable hands, and I trust his instincts on technical and collaborative matters. I will continue on as a member of the PMC and commiters list of course. Best regards, Frank -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Request for reintroduction of an override line into gcs.override.csv
) line used to be included in the gcs.override.csv file until GDAL 1.7.3: [2] Would it be possible to re-include this override line into the gcs.override.csv? Thank you, Andy [1]: Formulas and constants for the calculation of the Swiss conformal cylindrical projection and for the transformation between coordinate systems, chapter 1.4: http://www.swisstopo.admin.ch/internet/swisstopo/en/home/topics/survey/sys /refsys.parsysrelated1.2487.downloadList.82881.DownloadFile.tmp/swissprojec tionen.pdf [2]: https://github.com/OSGeo/gdal/blob/733829bf6f88530a92c25457a0f4d0ef0eb5f03 a/gdal/data/gcs.override.csv#L29-L31 Andreas Schmid GIS-Informatiker Amt für Geoinformation SO!GIS-Koordination Rötistrasse 4 4501 Solothurn Telefon +41 32 627 75 93 Telefax +41 32 627 75 98 andreas.sch...@bd.so.ch http://www.so.ch ___ 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 -- 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 -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Motion: Appoint Even Rouault PMC Chair
Folks, Motion: Appoint Even Roualt as GDAL Project Management Committee Chair +1 Frank --- For at least a couple years, if not longer, Even has been the leading contributor to the GDAL project. As we start a fresh year in the middle of the 2010s I think it is time for us to formally acknowledge Even as the project leader. The PMC chair doesn't really have many responsibilities, beyond ensuring that the PMC operates in an orderly fashion and acting as liason to the OSGeo board when needed. But it is also a recognition of Even's great work, technically and increasingly in other outward facing efforts such as his upcoming presentation on GDAL at FOSS4G NA in March. I am very pleased to have my project pass into his capable hands, and I trust his instincts on technical and collaborative matters. I will continue on as a member of the PMC and commiters list of course. Best regards, Frank -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Adopt RFC 51: RasterIO() improvements : resampling and progress callback
+1 Frank On Mon, Dec 1, 2014 at 10:48 AM, Even Rouault even.roua...@spatialys.com wrote: Hi, I think that the points raised in the discussion have been answered. Since the call for discussion, I've made a change in the RFC and proposed implementation so that the GDALRasterIOExtraArg* psExtraArg argument of RasterIO() remains optional for out-of-tree C++ code, but compulsory for in- tree code : http://trac.osgeo.org/gdal/wiki/rfc51_rasterio_resampling_progress?action=diffversion=4old_version=3 https://github.com/rouault/gdal2/commit/31a814acd091c93bd498b4b8c219b83bb40bb3ae So: Motion : I move to adopt RFC 51: RasterIO() improvements : resampling and progress callback http://trac.osgeo.org/gdal/wiki/rfc51_rasterio_resampling_progress Starting with my +1 Best regards, 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 -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Adopt RFC 50: OGR field subtypes
+1 Frank On Mon, Nov 24, 2014 at 12:38 AM, Even Rouault even.roua...@spatialys.com wrote: Hi, I think that the points raised in the discussion have been answered. So: Motion : I move to adopt RFC 50: OGR field subtypes http://trac.osgeo.org/gdal/wiki/rfc50_ogr_field_subtype Starting with my +1 Best regards, 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 -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Commit access for Jukka Rahkonen
+1 Frank On Mon, Sep 29, 2014 at 12:11 PM, Even Rouault even.roua...@spatialys.com wrote: Motion: Extend GDAL/OGR commit access to Jukka Rahkonen --- I'd like to make it easier for Jukka to do documentation improvements and fixes by giving him direct access to SVN. It will be a great asset for the project to benefit from Jukka's great knowledge of the software and his lights as a power user. Jukka, could you answer to this email to state that you have read and agreed to the GDAL commiter guideline : http://trac.osgeo.org/gdal/wiki/rfc3_commiters I'll start the voting with: +1 Even Best regards, -- 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 -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] OGR WCTS Security Issue / Migration To Spike
Folks, Robert Coup has noticed a security problem with the OGR WCTS service. As I am not aware of anyone using it, and it hasn't been maintained for a while, I'm going to move it to svn spike from trunk and added a small warning about it there. Anyone actually running this as a service may want to review the notes added to the index.html and/or talk to Robert. If there is desire to keep this in the GDAL/OGR distribution let me know and we could work on a fix. The brief (incomplete) description follows, and the code can now be found at: http://svn.osgeo.org/gdal/spike/wcts/ h2a id=securitySecurity Concern/a/h2 The OGR WCTS server has been moved to spike due to lack of maintenance and a non-trivial SSRF security bug. In light of this problem, it is advised that this service only be used with caution. Robert Coup describes it this way: p i If the WCTS stuff is compiled with -DHAVE_CURL, then the ogrwcts process is vulnerable to SSRF. The wctsclient process (which looks to me like a cgi server) is always vulnerable, since it doesn't care about -DHAVE_CURL.p (a) Either passing in a user-supplied URL which isn't validated before requesting it - this leaves internal http services which should only be readable to the server readable to any client.p (b) Using a redirect to the gopher protocol a client can send HTTP POST requests or other payloads to any host accessible to the server. *Why* curl enables the gopher protocol is beyond me, but it does.p We can protect against (b) by disabling redirect-following (CURLOPT_FOLLOWLOCATION=0). But we can't really protect against (a) at all without adding some black/whitelist of IP addresses.p Steps to reproduce:p Overview: ol li send evil request to wctsclient or ogrwcts services li wcts requests client-specified http url (via FileUrl in ogrwcts, or WCTSServer/GMLURL in wctsclient) li either that reveals private inf /ol /i Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] EPSG 8.5 Upgrade
Folks, With help from Howard Butler, I have upgraded GDAL trunk to using EPSG 8.5 definitions in trunk. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Adding a Commercial support section on gdal.org?
support section on gdal.org ? Message-ID: 201408202202.36022.even.roua...@spatialys.com Content-Type: Text/Plain; charset=us-ascii Hi, I'm wondering if there would be a concensus and interest to add a Commercial support section on gdal.org. A number of OSGeo projects have such page (see [1]), so that wouldn't be completely awkward to have one for GDAL as well. The OSGeo Service provider database reference 137 companies/individuals that have registered themselves as providing GDAL support ([2]) ! Pretty cool, but I'm wondering how a user not familiar with the project could effectively use that list to identify core contributors from casual advanced users. If we agree for adding a Commercial support section, the question is : on which criteria do we accept an organization/individual to be listed in the section ? We would want them to be as most objective and non debatable as possible. A simple criterion could be anyone who has commit rights (in trunk, not just in a sandbox or customer branch). There are currently 56 SVN committers. That could be strengthened with a minimum number of commits/lines changed during a period, but we perhaps don't need that level of complexity. We could possibly also extend that to entities that provide public support to users through gdal-dev or other public forums (gis.stackexchange, others?). Other suggestions ? Should we distinguish several categories of actors ? - QGIS makes a division between Core contributors vs Contributors. GeoServer has Core contributors, Experienced providers and Additional services (the last one is populated on service provider request). - On the other side, deegree, Geomoose or Geotools simply list them in a single section. The answer likely depends on the number of organizations that would be listed (I guess below 10 we don't need much structure). The difficulty here would be to establish the categories and criteria. So, could entities interested in being listed reply to this email so we can have a better idea of how many would be listed, and if we need more stricter criteria or several categories ? As far as I'm concerned, Spatialys would be interested. Best regards, Even [1] Non exhaustive list of OSGeo projects with a commercial support section : http://geoserver.org/support/ http://www.geomoose.org/info/commercial_support.html http://docs.geotools.org/latest/userguide/welcome/support.html http://wiki.deegree.org/deegreeWiki/GettingSupport http://qgis.org/en/site/forusers/commercial_support.html [2] OSGeo Service Provider catalog with entities declaring GDAL expertise : http://www.osgeo.org/search_profile?SET=1MUL_TECH[]=00013 -- Spatialys - Geospatial professional services http://www.spatialys.com -- -- Carlo A. Bertelli Charta servizi e sistemi per il territorio e la storia ambientale srl Dipendenze del palazzo Doria, vc. alla Chiesa della Maddalena 9/2 16124 Genova (Italy) tel. +39(0)10 2475439 fax +39(0)10 2475439 gsm:+39 393 1590711 -- ___ 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 -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Adopt RFC 46 : GDAL/OGR unification
+1 Frank On Mon, May 19, 2014 at 1:29 PM, Even Rouault even.roua...@mines-paris.orgwrote: Hi, I think that the points raised in the discussion have been answered. I've just done a minor edit to the RFC text to mention RFC 36, as rightly suggested by Ivan. So: Motion : I move to adopt RFC 46: GDAL/OGR unification http://trac.osgeo.org/gdal/wiki/rfc46_gdal_ogr_unification Starting with my +1 Best regards, Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Fwd: Motion: Promote 1.11.0RC1 for release
Even, I have built it with a few custom options and run the test suite and all looks well. +1 Frank Thanks for your great work on preparing the release! PS. the cantopo gdalhttp.py test fails, and investigating I see: $ gdalinfo /vsicurl/ ftp://ftp2.cits.rncan.gc.ca/pub/cantopo/250k_tif/MCR2010_01.tif --debug on VSICURL: GetFileSize( ftp://ftp2.cits.rncan.gc.ca/pub/cantopo/250k_tif/MCR2010_01.tif)=0 response_code=226 ERROR 4: `/vsicurl/ ftp://ftp2.cits.rncan.gc.ca/pub/cantopo/250k_tif/MCR2010_01.tif' does not exist in the file system, and is not recognised as a supported dataset name. gdalinfo failed - unable to open '/vsicurl/ ftp://ftp2.cits.rncan.gc.ca/pub/cantopo/250k_tif/MCR2010_01.tif'. We might want to consider removing it if this is often the victim of timeouts. Best regards, Frank On Thu, Apr 24, 2014 at 10:28 AM, Even Rouault even.roua...@mines-paris.org wrote: PSC, Only I and Jukka have voted on the motion. It would be good if you could find some time to test RC1 and cast your vote. Best regards, Even -- Message transmis -- Sujet : [gdal-dev] Motion: Promote 1.11.0RC1 for release Date : dimanche 20 avril 2014, 16:03:08 De : Even Rouault even.roua...@mines-paris.org À : GDAL-dev list gdal-dev@lists.osgeo.org Motion: GDAL/OGR 1.11.0RC1 is promoted to be the official 1.11.0 final release. --- No critical issue has been specifically reported on RC1 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 -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev --- -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Fwd: Motion: Promote 1.11.0RC1 for release
Even, Likely my connection is a bit lame. It might be better to setup the test against a smaller file done on ftp.remotesensing.org. I'll try to look into this at some point. Best regards, Frank On Thu, Apr 24, 2014 at 12:08 PM, Even Rouault even.roua...@mines-paris.org wrote: PS. the cantopo gdalhttp.py test fails, and investigating I see: $ gdalinfo /vsicurl/ ftp://ftp2.cits.rncan.gc.ca/pub/cantopo/250k_tif/MCR2010_01.tif --debug on VSICURL: GetFileSize( ftp://ftp2.cits.rncan.gc.ca/pub/cantopo/250k_tif/MCR2010_01.tif)=0 response_code=226 ERROR 4: `/vsicurl/ ftp://ftp2.cits.rncan.gc.ca/pub/cantopo/250k_tif/MCR2010_01.tif' does not exist in the file system, and is not recognised as a supported dataset name. gdalinfo failed - unable to open '/vsicurl/ ftp://ftp2.cits.rncan.gc.ca/pub/cantopo/250k_tif/MCR2010_01.tif'. We might want to consider removing it if this is often the victim of timeouts. Works for me, and works most of the time with the Travis instances AFAIR. The reliability of online resources is indeed a problem. Not sure how we can address it. The interest of that test was to check that ReadDir() API works on FTP with /vsicurl/ Best regards, Frank On Thu, Apr 24, 2014 at 10:28 AM, Even Rouault even.roua...@mines-paris.org wrote: PSC, Only I and Jukka have voted on the motion. It would be good if you could find some time to test RC1 and cast your vote. Best regards, Even -- Message transmis -- Sujet : [gdal-dev] Motion: Promote 1.11.0RC1 for release Date : dimanche 20 avril 2014, 16:03:08 De : Even Rouault even.roua...@mines-paris.org À : GDAL-dev list gdal-dev@lists.osgeo.org Motion: GDAL/OGR 1.11.0RC1 is promoted to be the official 1.11.0 final release. --- No critical issue has been specifically reported on RC1 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 -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev --- -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Geospatial professional services http://even.rouault.free.fr/services.html -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Commit Access for Vincent Mora
+1 Frank On Fri, Mar 14, 2014 at 8:42 AM, Even Rouault even.roua...@mines-paris.orgwrote: Motion: Extend GDAL/OGR commit access to Vincent Mora. --- I'd like to make it easier for Vincent to maintain and improve the recently committed OGR WaSP driver, without me being the bottleneck. He has demonstrated a good knowledge of OGR working, and good interaction with our community. Vincent, could you answer to this email to state that you have read and agreed to the GDAL commiter guidelines : http://trac.osgeo.org/gdal/wiki/rfc3_commiters I'll start the voting with: +1 Even Best regards, -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Misc. subjects : OSGeo Vienna code sprint, release plans, GDAL 2.0
On Thu, Feb 13, 2014 at 1:14 PM, Even Rouault even.roua...@mines-paris.orgwrote: Currently we have no such breakage in trunk so it could qualify as GDAL 1.11. Perhaps we should just release it as such for now before the bigger changes ? Even, I think that 2.0 could be kept for breaking changes, and that if we aren't going to accomplish those big projects we should just aim for a 1.11 release. Somes topics I can see for GDAL 2.0 that impact API/ABI : - well, the mythological unification of OGR driver model with GDAL driver model. - XYZM support - Curve geometries - 64 bit integer support I think the above could potentially justify a 2.0 release. I think a change to github or cmake do not because they don't affect applications using GDAL. Best regards, Frank Other possible structural changes : - Change of master version control system: switch to git / GitHub ? - New build system : cmake ? Of course all of this will more likely happen if contributors or funders show up ! Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Commit Access for Jürgen Fischer
+1 Frank On Thu, Jan 30, 2014 at 11:09 AM, Even Rouault even.roua...@mines-paris.org wrote: Motion: Extend GDAL/OGR commit access to Jürgen Fischer. --- I'd like to make it easier for Jürgen (who is also a contributor to QGIS) to continue maintaining and improving the OGR NAS driver in which he has regularly worked over the last past months (years?). Up to now I used to commit his changes, but it would be more efficient if he could do it himself. Jürgen, could you answer to this email to state that you have read and agreed to the GDAL commiter guidelines : http://trac.osgeo.org/gdal/wiki/rfc3_commiters I'll start the voting with: +1 Even Best regards, -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Adopt RFC45 : GDAL datasets and raster bands as virtual memory mapping
+1 On Sun, Jan 12, 2014 at 5:03 AM, Even Rouault even.roua...@mines-paris.orgwrote: Motion : I move to adopt RFC 45 (GDAL datasets and raster bands as virtual memory mapping) http://trac.osgeo.org/gdal/wiki/rfc45_virtualmem Starting with my +1 Best regards, Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Standard Dev. Environment?
Jay, Are you needing Jasper? Normally a default build (./configure) should work pretty well on a precise system. I'm guessing you have enabled jasper because it is key to what you want to do? If not --without-jasper should be straight forward. Best regards, Frank On Thu, Jan 9, 2014 at 8:00 PM, Jay L. jla...@asu.edu wrote: List, I wonder if a standard dev. environment exists? I am working to extend a driver and am having trouble getting an environment working that will compile. Current setup is a VagrantVM, Ubuntu 12.04 32-bit with source downloaded from SVN. Attempting to build with minimized drivershttp://trac.osgeo.org/gdal/wiki/BuildingOnUnixWithMinimizedDriversas per the build documentation and am having build errors due to dec_jpeg2000 (jasper I believe). Q: Are devs using a standard environment (or a different flavor of *nix?)? ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ 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 45: GDAL datasets and raster bands as virtual memory mappings
Even, Sorry, I was thinking of mmap() directly to the file, and having something like: CPLVirtualMem CPL_DLL* GDALBandGetVirtualMemAuto( GDALRasterBandH hBand, int *pnPixelSpace, GIntBig *pnLineSpace, char **papszOptions ); I imagined an available virtual method on the band which could be implemented - primarily by the RawBand class to try and mmap() the data and return the layout. But when that fails, or is unavailable it could use your existing methodology with a layout that seems well tuned to the underlying data organization. Certainly there is no need to hold things up for this. What you are proposing is already wonderfully useful. I'm wondering if there would be ways of making what you propose work with Python Numpy in such a way that a numpy array could be requested which is of this virtual memory. That would also be a nice extension. Best regards, Frank On Wed, Dec 18, 2013 at 2:10 AM, Even Rouault even.roua...@mines-paris.orgwrote: Le mercredi 18 décembre 2013 06:55:50, Frank Warmerdam a écrit : Even, Very impressive work, I am supportive. IMHO it would be wonderful if there was also an mmap() based mechanism where you could ask for the virtual memory chunk and you get it back (if it works) along with stride values to access in it. This could likely be made to work for most raw based formats and a few others too. It might also allow non-mmap() based files to return an organization based more on their actual organization for efficiency. Hi Frank, I'm not completely sure to have understood your idea. Would that be something like : CPLVirtualMem CPL_DLL* GDALDatasetGetVirtualMemAuto( GDALDatasetH hDS, GDALRWFlag eRWFlag, int nXOff, int nYOff, int nXSize, int nYSize, int nBufXSize, int nBufYSize, GDALDataType eBufType, int nBandCount, int* panBandMap, int *pnPixelSpace, GIntBig *pnLineSpace, GIntBig *pnBandSpace, size_t nCacheSize, int bSingleThreadUsage, char **papszOptions ); Difference with GDALDatasetGetVirtualMem() : the stride values are now output values and no more nPageSizeHint parameter. In your mind, would the spacings be determined in a generic way from the dataset properties(block size and INTERLEAVED=PIXEL/BAND metadata item), or would that require some direct cooperation of the driver ? Since you mention raw formats, perhaps you are thinking more to a file-based mmap() rather than a anonymous mmap() combined with RasterIO(), like currently proposed ? This is something I've mentionned in the Related thoughts paragraph but there are practical annoyance with how Linux manages memory with file-based mmap(). I'd be happy if someone has successfull experience with that by the way (and that doesn't require explicit madvise() each time you're done with a range of memory) --- Reading again your words, I'm now wondering if you are not thinking to a Dataset / RasterBand virtual method that could be implemented by drivers ? virtual CPLVirtualMem* GetVirtualMem(...) They would directly use the low-level CPLVirtualMem to create the mapping and provide their own callback to fill pages when page fault occurs. So they could potentially avoid using the block cache layer and do direct file I/O ? Looking at RawRasterBand::IRasterIO(), I can see that it can use (under some circumstances with a non obvious heuristics) direct file I/O without going to the block cache. So the current proposed implementation could potentially already benefit from that. Perhaps we would need a flag to RasterIO to ask it to avoid block cache when possible. Or just call CPLSetThreadLocalConfigOption(GDAL_ONE_BIG_READ, YES) in GDALVirtualMem::DoIOBandSequential() / DoIOPixelInterleaved() Even -- Geospatial professional services http://even.rouault.free.fr/services.html -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ 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 45: GDAL datasets and raster bands as virtual memory mappings
On Wed, Dec 18, 2013 at 11:46 AM, Even Rouault even.roua...@mines-paris.org wrote: Le mercredi 18 décembre 2013 19:53:37, Frank Warmerdam a écrit : Even, Sorry, I was thinking of mmap() directly to the file, and having something like: CPLVirtualMem CPL_DLL* GDALBandGetVirtualMemAuto( GDALRasterBandH hBand, int *pnPixelSpace, GIntBig *pnLineSpace, char **papszOptions ); I imagined an available virtual method on the band which could be implemented - primarily by the RawBand class to try and mmap() the data and return the layout. But when that fails, or is unavailable it could use your existing methodology with a layout that seems well tuned to the underlying data organization. Yes, that should be doable, but with the limitation I raised about the memory management of file-based mmap() : if you mmap() a file larger than RAM, and read it entirely, without explicit madvise() to discard regions no longer needed, it will fill RAM and cause disk swapping. I should retest to confirm. Perhaps there are some OS level tuning to avoid that ? Even, That was not my experience for readonly mmap() of actual files on disk back in the day. In any event, I'd suggest sticking with what you have, and if I'm keen perhaps one day I'll try and implement mmap() support. If I do, I feel like it needs to go down through the VSI*L system and once a file is mmapped() the VSI*L IO should also be using the mmaped images. Once upon a time this had performance benefits. I'm not sure if that is the case any more. Best regards, Frank -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ 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 45: GDAL datasets and raster bands as virtual memory mappings
On Wed, Dec 18, 2013 at 11:46 AM, Even Rouault even.roua...@mines-paris.org wrote: I'm wondering if there would be ways of making what you propose work with Python Numpy in such a way that a numpy array could be requested which is of this virtual memory. That would also be a nice extension. Hum, how would that be different from what is proposed in the SWIG bindings section of the RFC ? Even, Ahem - I apparently did not read the RFC closely enough. You are well ahead of me on this idea. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ 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 45: GDAL datasets and raster bands as virtual memory mappings
Even, Very impressive work, I am supportive. IMHO it would be wonderful if there was also an mmap() based mechanism where you could ask for the virtual memory chunk and you get it back (if it works) along with stride values to access in it. This could likely be made to work for most raw based formats and a few others too. It might also allow non-mmap() based files to return an organization based more on their actual organization for efficiency. Best regards, Frank On Tue, Dec 17, 2013 at 1:01 PM, Even Rouault even.roua...@mines-paris.orgwrote: Le mardi 17 décembre 2013 21:54:31, Even Rouault a écrit : Hi, This is a call for discussion for RFC 45: GDAL datasets and raster bands as virtual memory mappings Here's the link to the RFC : http://trac.osgeo.org/gdal/wiki/rfc45_virtualmem Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] VS2010-VS2013 s57
Dmitriy,
It is not clear to me why this should be necessary. osAcronym is a long
lived std::string (well CPLString derived from std::string) living in the
registrars attribute list. I assume the following method is used to
convert the CPLString to const char * which should amount to the same
thing you did.
operator const char* (void) const { return c_str(); }
Perhaps there is some subtle reason I don't see that the compiler is
creating a temporary std::string in between?
In any event, if you file a ticket I can apply this change upstream. There
are other accessors on the same class that look like they could have
similar issues.
Best regards,
Frank
On Wed, Dec 4, 2013 at 12:11 PM, Dmitriy Baryshnikov
bishop@gmail.comwrote:
Hi,
I have such error: the GDAL compiled with VS2010-VS2013 in s57 driver
loose all additional fields values. But the same code compiled with gcc or
previous VS works fine.
I found the root of problems here (ogr\ogrsf_frmts\s57\s57reader.cpp:932):
const char *pszAcronym = poRegistrar-GetAttrAcronym(nAttrId);
iField = poFeature-GetDefnRef()-GetFieldIndex(pszAcronym);
The pszAcronym always empty.
The problem comes from this function (ogr\ogrsf_frmts\s57\s57.h:140):
const char *GetAttrAcronym( int i )
{ return GetAttrInfo(i) == NULL ? NULL : aoAttrInfos[i]-osAcronym; }
It seems to me that during execution this function I have situation when
c_str() result becomes invalid (the std::string is destroyed or a
non-const member function of the string is called).
If I change function
const char *GetAttrAcronym( int i )
{ return GetAttrInfo(i) == NULL ? NULL :
aoAttrInfos[i]-osAcronym.c_str(); }
the problem gone.
So I need some confirmation/verification my ideas.
If I'm right, I can make changes to s57 driver.
Best regards,
Dmitry
--
http://www.avast.com/
Это сообщение свободно от вирусов и вредоносного ПО благодаря avast!
Antivirus http://www.avast.com/ защита активна.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
---+--
I set the clouds in motion - turn up | Frank Warmerdam,
warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Software Developer
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RFC 44: JSON/XML output for ogrinfo/gdalinfo
Howard, I was a bit surprised that the RFC doesn't actually define the format. I gather we are supposed to deduce it from the modified ogrinfo code? On the GDAL side, rather than have gdalinfo support some secondary reporting format, I *feel* it would be better to just have a method on a dataset to provide a summary report somewhat similar to what gdalinfo would give. In XML this would essentially be what you would get from doing a gdal_translate -of VRT abc.tif abc.vrt . I must confess there isn't such a clean analog on the ogrinfo side, and if you want to also capture feature data written out by ogrinfo it gets someone more complicated. Skimming the (json missing) example ogrinfo it seems like a lot of work - particularly to maintain in a way that will keep all output formats in line. I started out supportive, but the more I think about the approach the less keen I am. Best regards, Frank On Tue, Nov 19, 2013 at 8:42 AM, Howard Butler how...@hobu.co wrote: All, Dan Little and myself would like to put forward an RFC proposing -xml and -json output support for both ogrinfo and gdalinfo. No changes are proposed to the current text format (which would continue to be the default output format), but having JSON and XML available would greatly ease the integration of gdalinfo and ogrinfo into existing processing workflows without requiring that someone jump into scripting land. Though it might have been overkill to have an RFC, I thought it would be useful to have something to collaborate on if others have ideas about these particular features. http://trac.osgeo.org/gdal/wiki/rfc44_gdalinfoxml We look forward to your feedback, Howard ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ogr2og / forcing a +-180 system
Robb, Have you tried the -wrapdateline switch? I do not believe geometries that cross the dateline will be handled ideally (they aren't split as one might hope), but if you don't have them then the rest of the geometries should be wrapped. I see there is even now a -datelineoffset switch if someone needed 0 to 360. Best regards, Frank On Mon, Nov 18, 2013 at 8:36 AM, Robb K. Wright robbkwri...@gmail.comwrote: I need to use ogr2ogr (or any other command line) to convert a shapefile with longitudes spanning from -220 to -60, forcing it into a +-180 scheme, so the -220 coordinate would come out as +140 and the -60 stays as -60. I don't need to worry about the polys that actually cross the 180 line. Any thoughts? I was thinking that running it through EPSG:4326 would reshape it (as it does in Esri-land), but no luck. Robb ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal for WindowCE
Martin, The only DWG support that I recall depends on the libraries from the Open Design Alliance and I'm not sure if they work on windows CE. Also, that driver has many limitations - rendering the DWG features down to simple features in OGR. You might want to investigate that it really gives you want you want. Some more info on the DWG driver is available at: http://www.gdal.org/ogr/drv_dwg.html If it does suit your needs, and the ODA libraries can be built on WinCE then it would be great to have you helping keeping GDAL/OGR working properly on WinCE. Best regards, Frank On Fri, Nov 15, 2013 at 11:37 AM, Martin Pineault martin.pinea...@geo-plus.com wrote: Hi, We may be interested in maintaining the CE/Mobile flavor of gdal. But first someone told us that Autocad DWG files where supported (this is our need). But can’t find any mention in your web page. Thank you. *MARTIN PINEAULT* Vice-President, Business Development [image: ligne intermediaire] [image: logo et age cie] 555, rue de l'Aréna, suite 102 Saint-Nicolas, Qc, G7A 1E5 [image: icone telephone] 1-888-831-3668, #40 [image: icone fax] 1-866-635-7344 *martin.pinea...@geo-plus.com maurice.temf...@geo-plus.com* ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer image004.jpgimage002.gifimage003.jpgimage001.png___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] (no subject)
Phelippe, There are a few ways we could move forward on this. I believe the apparent master version of the PCIDSK SDK from GDAL's point of view is: http://svn.osgeo.org/gdal/sandbox/warmerdam/pcidsk And I think the process I used before was to periodally migrate this into the GDAL tree at: http://svn.osgeo.org/gdal/trunk/gdal/frmts/pcidsk/sdk/ Approaches: 1) You just drop a code dump on us, and existing developers integrate it. 2) We arrange commit access for you and you prepare an updated SDK in the sandbox area in SVN. We could then migrate that into the GDAL PCIDSK driver itself when we are comfortable with it. 3) We arrange full commit access for you and you do your integration directly in GDAL itself. I prefer option (2) which avoids the likely breakage in GDAL that might come from a wholesale replacement of the existing inside-GDAL code. But those who wish can still built against the standalone SDK for testing purposes and so forth. I'd imagine I'd be the GDAL developer to help move things over eventually. If you are ok with (2) then please create an OSGeo at: http://www.osgeo.org/osgeo_userid/ And I'll try to arrange sandbox-only commit access for you. Best regards, Frank On Fri, Nov 8, 2013 at 12:19 PM, Phelippe Neveu ne...@pcigeomatics.comwrote: To whom it may concern, We have updates to the PCIDSK library that we would like to upstream to GDAL. We have fixed numerous bugs, we have done many optimizations, and we also implemented a new binary tile directory. How should we proceed with the upstream? Thanks, Phelippe ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] geotiff projection not showing up
Norman,
My apologies. The GCP projection is actually supposed to be passed as the
third value in the SetGCPs call - where you have passed the string
Richmond. Instead pass the whole WKT strings for the coordinate system.
Best regards,
Frank
On Wed, Nov 6, 2013 at 4:00 PM, Norman Goldstein norm...@telus.net wrote:
Frank,
I am using GDAL
Version : 1.9.2
so maybe that is why I do not see the method SetGCPProjection().
I think you have convinced me, though, to calculate the 6 coefficients
directly,
and then call SetGeoTransform(). Will let you guys know how this works out
for me.
Thank you,
Norm
On 11/06/2013 01:51 PM, Frank Warmerdam wrote:
Norman,
I believe you want to call SetGCPProjection() instead of SetProjection()
when using GCPs instead of an affine transform.
Best regards,
Frank
On Wed, Nov 6, 2013 at 1:23 PM, Norman Goldstein norm...@telus.netwrote:
I have created a geotiff file using the GTiff driver, and have
successfully set options for it to be a strips file with no compression.
Also, successfully called the functions
dataset-SetMetadataItem( AREA_OR_POINT,
Point,
nullptr ) )
and
dataset-SetGCPs( 3,
gcps,
Richmond )
Here is the listgeo dump:
# listgeo dump ##
Geotiff_Information:
Version: 1
Key_Revision: 1.0
Tagged_Information:
ModelTiepointTag (6,3):
0249 0
000
399 249 0
1000 00
000
02000 0
End_Of_Tags.
Keyed_Information:
GTRasterTypeGeoKey (Short,1): RasterPixelIsPoint
End_Of_Keys.
End_Of_Geotiff.
Corner Coordinates:
... unable to transform points between pixel/line and PCS space
#
I also set the reference system using the following code:
/// c++ code
OGRSpatialReference oSRS;
oSRS.SetProjCS( NoWhere );
oSRS.SetWellKnownGeogCS( WGS84 );
oSRS.SetEquirectangular( 0.0,// Centre lat
0.0,// Centre lon
0.0, // False Easting
0.0 ); // False Northing
char* wkt = nullptr;
if( OGRERR_NONE != oSRS.exportToPrettyWkt( wkt ) )
{
error...
}
if( CE_Failure == dataset-SetProjection( wkt ) )
{
error...
}
///
So, why is listgeo not able to transform points between pixel/line and
PCS space?
I am happy to upload a full working example if needed.
Thank you.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
---+--
I set the clouds in motion - turn up | Frank Warmerdam,
warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Software Developer
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
---+--
I set the clouds in motion - turn up | Frank Warmerdam,
warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Software Developer
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] NewDataset and SetBand error
Seung,
If the fields, like papoBands in the dataset seem ok before stepping into
SetBand(), and corrupt once you are inside I would suspect that GDAL and
your application have been built with different gdal_priv.h include files
*or* with different structure alighnments flags for Visual Studio. Did you
build GDAL from source using the same configuration you are building your
application with?
Best regards,
Frank
On Thu, Nov 7, 2013 at 1:03 AM, Seung Ae Lim sa...@pixoneer.co.kr wrote:
Dear,
I make a console application with VS2010 linking gdal_i.lib.
The steps are :
* 1. Create New Dataset and Band in main.cpp*
class XXDataset : public GDALPamDataset
{
public:
XXDataset() {};
~XXDataset() {};
static GDALDataset* Open(GDALOpenInfo*);
};
class XXRasterBand : public GDALPamRasterBand
{
public:
XXRasterBand( GDALDataset*, int, GDALDataType );
~XXRasterBand() {};
};
GDALDataset* XXDataset::Open(GDALOpenInfo* pOpenInfo)
{
XXDataset* poDS = new XXDataset();
poDS- nRasterXSize = 100;
poDS- nRasterYSize = 200;
poDS- eAccess = GA_Update;
poDS- nBands = 3;
int iBand = 0;
for(iBand = 1; iBand = 3; iBand++ )
{
XXRasterBand* band = new XXRasterBand( poDS, iBand, GDT_Byte);
poDS- SetBand( iBand, band );
}
return poDS;
}
XXRasterBand::XXRasterBand( GDALDataset *poDS, int nBand, GDALDataType
eType)
{
this- poDS = poDS;
this- nBand = nBand;
this- eDataType = eType;
nRasterXSize = 100;
nRasterYSize = 200;
nBlockXSize = nRasterXSize;
nBlockYSize = nRasterYSize;
}
*2. Add the code in main function*
void main()
{
GDALDataset* pDSTemp = XXDataset::Open(NULL);
if (pDSTemp) GDALClose(pDSTemp);
}
I compile and try to debug this app.
But in poDS-SetBand line of XXDataset::Open, the app is broken when
the first band is ready to set.
In XXDataset::Open, all value of parameters is right.
But When stepping into the SetBand function, the values may be corrupted.
papobands of GDALDataset is not null and it make an error.
Please let me know the reason or some tips.
Thanks.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
---+--
I set the clouds in motion - turn up | Frank Warmerdam,
warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Software Developer
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] geotiff projection not showing up
Norman,
I believe you want to call SetGCPProjection() instead of SetProjection()
when using GCPs instead of an affine transform.
Best regards,
Frank
On Wed, Nov 6, 2013 at 1:23 PM, Norman Goldstein norm...@telus.net wrote:
I have created a geotiff file using the GTiff driver, and have
successfully set options for it to be a strips file with no compression.
Also, successfully called the functions
dataset-SetMetadataItem( AREA_OR_POINT,
Point,
nullptr ) )
and
dataset-SetGCPs( 3,
gcps,
Richmond )
Here is the listgeo dump:
# listgeo dump ##
Geotiff_Information:
Version: 1
Key_Revision: 1.0
Tagged_Information:
ModelTiepointTag (6,3):
0249 0
000
399 249 0
1000 00
000
02000 0
End_Of_Tags.
Keyed_Information:
GTRasterTypeGeoKey (Short,1): RasterPixelIsPoint
End_Of_Keys.
End_Of_Geotiff.
Corner Coordinates:
... unable to transform points between pixel/line and PCS space
#
I also set the reference system using the following code:
/// c++ code
OGRSpatialReference oSRS;
oSRS.SetProjCS( NoWhere );
oSRS.SetWellKnownGeogCS( WGS84 );
oSRS.SetEquirectangular( 0.0,// Centre lat
0.0,// Centre lon
0.0, // False Easting
0.0 ); // False Northing
char* wkt = nullptr;
if( OGRERR_NONE != oSRS.exportToPrettyWkt( wkt ) )
{
error...
}
if( CE_Failure == dataset-SetProjection( wkt ) )
{
error...
}
///
So, why is listgeo not able to transform points between pixel/line and PCS
space?
I am happy to upload a full working example if needed.
Thank you.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
---+--
I set the clouds in motion - turn up | Frank Warmerdam,
warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Software Developer
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Docs attribution for upcoming book!
Tyler, That approach sounds good to me. I look forward to seeing the book. Best regards, Frank On Fri, Nov 1, 2013 at 12:55 PM, TYLER MITCHELL tylermitch...@shaw.cawrote: Hi all, I'm working with Gary Sherman via Locate Press to (finally) publish the GDAL reference manual, along with some more examples and other GDAL/OGR related material I've written over the past year. It will be in a book entitle Geospatial Power Tools. I just wanted to let you know about it and to confirm the attribution approach we took for the GDAL docs portion. I've included the main licensing text, with copyright Frank Warmerdam, but for authors I put GDAL Developers. Does that make sense? We will likely have a preview version out for sale today or tomorrow at http://locatepress.com/gpt Best wishes, Tyler ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Setting the georeferencing priority for GDAL
Jukka, Part of why behavior is inconsistent now is that the logic is in each driver. Some might give precidence to a world file over something internal, or to .aux.xml. I think it would be *desirable* for .aux.xml to take precedence over internal information when it is available as it is normally only in the .aux.xml file because it was updated or accurate information could not be written within the file itself. I'm not sure how we would go about updating all drivers to have consistent behavior. I do like the idea that drivers can control this. I just think it would be good to have a suggested behavior we aim for. I'm not too keen on a configuration option as those are always a sort of hack, though it is possible. I will note you can always gdal_translate to VRT and then hand edit or alter it with gdal_edit.py to get a wrapped dataset with the desired georeferencing and other metadata. Best regards, Frank On Sun, Oct 27, 2013 at 4:02 PM, Jukka Rahkonen jukka.rahko...@mmmtike.fiwrote: Hi, Sometimes an image can have several and ambiguous metadata for georeferencing. Mapserver has a method to deal with ambiguous internal geotiff metadata and world files and user can override the internal metadata by using PROCESSING EXTENT_PRIORITY=WORLD in the mapfile. http://www.mapserver.org/input/raster.html#special-processing-directives. I thought it was PROCESSING EXTENT_PRIORITY=WORLDFILE but perhaps both keywords are supported. I wonder if GDAL supports this same worldfile override with some secret config option. At least it is not listed on page http://trac.osgeo.org/gdal/wiki/ConfigOptions. I can also see that GDAL does have a config option GMLJP2OVERRIDE but I could not easily find what is is doing. And finally when I was playing with a gdal_edit.py utility I discovered that there are at least 4 ways to georeference a JPEG2000 file: - use worldfile .wld or .j2w - use internal GeoJP2 (GeoTIFF) georeferencing - use internal GML georeferencing - use an external .aux.xlm file I noticed that command python gdal_edit.py -a_srs epsg:3067 metajp2test.jp2 was creating a file names metajp2test.jp2.aux which does contain the right georeferencing data. However, if I run gdalinfo it is looking for the internal GeoJP2 metadata and it reports that my JPEG2000 file is still using an unknown projection. This feels a bit messy. Perhaps there is a need to have a GDAL wide config option for what metadata to search and use for georeferencing. In my case I would like to set it to use external GDAL aux.xml. In addition, I think that this setting should be made safe so that if aux.xml file is not found then the image is considered to be without georeferencing. Or perhaps the config option could take a list like auxiliary_xml,GeoJP2 with all the acceptable alternatives in priority order. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Call for discussion for RFC 43 GDALMajorObject::GetMetadataDomainList()
Even, I'm happy with this RFC. It's a bit sad that the list of domains is duplicated and has to be freed again by the caller, but it certainly avoids any doubts about the lifetime of the returned list. I have an internal driver here at Planet Labs where I tree any subnode in our JSON metadata format as a GDAL metadata domain. It will be interested to write an implementation of GetMetadataDomainList() for that. Best regards, Frank On Sat, Oct 19, 2013 at 11:59 AM, Even Rouault even.roua...@mines-paris.org wrote: Hi, This is a call for discussion for RFC 43 GDALMajorObject::GetMetadataDomainList() : http://trac.osgeo.org/gdal/wiki/rfc43_getmetadatadomainlist Beginning of the RFC inline : == Summary == This (mini)RFC proposes a new virtual method, GetMetadataDomainList(), in the GDALMajorObject class (and a C API) to return the list of all available metadata domains. == Background == GDALMajorObject currently offers the GetMetadata() and GetMetadataItem() methods that both accept a metadata domain argument. But there is no way to auto-discover which metadata domains are valid for a given GDALMajorObject (i.e. a dataset or raster band). This make it impossible to have generic code that can exhaustively discover all metadata in a dataset/raster band. [...] Best regards, Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] EPSG 8.2 Upgrade
Patch applied in trunk... On Thu, Oct 3, 2013 at 9:06 AM, Paul Meems bontepaar...@gmail.com wrote: Thanks Even, That patch works great. Hopefully it will get implemented soon. Paul *Paul Meems * Release manager, configuration manager and forum moderator of MapWindow GIS. www.mapwindow.org Owner of MapWindow.nl - Support for Dutch speaking users. www.mapwindow.nl * * 2013/10/3 Even Rouault even.roua...@mines-paris.org Selon Paul Meems bontepaar...@gmail.com: I'm not sure if this is the correct place to report this. If not please let me know. I'm having trouble compiling the trunk version of PROJ.4 with the updated EPSG 8.2 database definitions. I'm running Win7 and use VS2008. I'm getting these errors and warnings: Warning 1Command line warning D9002 : ignoring unknown option '/Op' cl Warning 2warning C4129: 'P' : unrecognized character escape sequencepj_open_lib.c Warning 3warning C4129: 'S' : unrecognized character escape sequencepj_open_lib.c Error4error C2143: syntax error : missing ';' before 'type' PJ_healpix.c Error5error C2143: syntax error : missing ';' before 'type' PJ_healpix.c Error6error C2065: 'xc' : undeclared identifierPJ_healpix.c Error7error C2065: 'xc' : undeclared identifierPJ_healpix.c Error8error C2065: 'tau' : undeclared identifierPJ_healpix.c Error9error C2065: 'tau' : undeclared identifierPJ_healpix.c When I use the zipped source code for v4.8.0 I don't have these problems. Can anybody assist? There's a patch pending in Trac for the MSVC compilation issues : http://trac.osgeo.org/proj/ticket/223 Thanks, Paul 2013/10/2 Frank Warmerdam warmer...@pobox.com Folks, I have upgraded libgeotiff, GDAL and PROJ.4 trunk's with the EPSG 8.2 database definitions. I have come to the conclusion that the EPSG Postgresql .sql files are distributed in WIN1252 encoding, not LATIN1, and so some special characters - mostly in comments - should be translated better. Let me know if you see problems or have questions. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ 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 -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] can't fetch the projection definition string on Linux
Daniel, This is likely due to problems looking up the coordinate system. If you built and installed GDAL yourself it will likely be looking in /usr/local/share/gdal/data for the file pcs.csv. If you installed it via apt-get then it should be looking in /usr/share/gdal/data (or perhaps /usr/share/gdal/data/1.10) for the file. So, step one is to confirm that the pcs.csv file exists in one of those locations. If GDAL is looking in the wrong place for the file, setting the GDAL_DATA environment variable may help. ie. export GDAL_DATA=/usr/local/share/gdal/data gdalinfo abc.tif It is also possible that the GDAL GeoTIFF driver actually needs the libgeotiff support csv files which would normally live somewhere like /usr/share/epsg_csv and key files would have names like coordinate_reference_system.csv. Best regards, Frank On Wed, Oct 2, 2013 at 2:29 PM, Daniel Testa danielte...@suremptec.com.ar wrote: Hello everyone, I´m experiencing a weird behavior when reading a raster image (GTiff/GeoTIFF) I'm using GDAL 1.9.1 for Linux (Ubuntu 12.04 LTS) and Windows (Win 7 Ultimate SP1) to open a raster image with EPSG:22194 Sample output from gdalinfo for that image on Windows (WKT): [...] PROJCS[Campo Inchauspe / Argentina 4, GEOGCS[Campo Inchauspe, DATUM[Campo_Inchauspe, SPHEROID[International 1924,6378388,297.0005, AUTHORITY[EPSG,7022]], AUTHORITY[EPSG,6221]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4221]], PROJECTION[Transverse_Mercator], PARAMETER[latitude_of_origin,-90], PARAMETER[central_meridian,-63], PARAMETER[scale_factor,1], PARAMETER[false_easting,450], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]], AUTHORITY[EPSG,22194]] [...] Now the output from gdalinfo for the same image on Linux (WKT): [...] LOCAL_CS[Campo Inchauspe / Argentina 4, GEOGCS[Campo Inchauspe, DATUM[unknown, SPHEROID[unretrievable - using WGS84,6378137,298.257223563]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433]], AUTHORITY[EPSG,22194], UNIT[metre,1]] [...] Any idea of why this might be happening? it also happens with EPSG:22184 Any idea, suggestion or comment is very welcome :) Thanks in advance. Regards, Daniel. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] EPSG 8.2 Upgrade
Folks, I have upgraded libgeotiff, GDAL and PROJ.4 trunk's with the EPSG 8.2 database definitions. I have come to the conclusion that the EPSG Postgresql .sql files are distributed in WIN1252 encoding, not LATIN1, and so some special characters - mostly in comments - should be translated better. Let me know if you see problems or have questions. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Add Jukka Rahkonen to GDAL PSC
+1 - a worthy addition! On Sat, Sep 28, 2013 at 1:42 AM, Even Rouault even.roua...@mines-paris.org wrote: Hi, Jukka is one of our most active power users since many years. You've certainly noticed him many times answering to question from other users on the mailing list, testing bleeding edge trunk or doing precise bug reports. Jukka is also involved into other OSGeo (or related) communities such as MapServer, GeoServer or Spatialite, which gives him a quite broad vision in the geospatial field. Based on his involvment, I would like to include him in the project steering committee. Motion: To add Jukka Rahkonen to the GDAL PSC. +1 from me. Best regards, Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] assert failure (tif_open)
Nik, I assume you are using the built in libtiff in GDAL. In that case the file gdal/frmts/gtiff/libtiff/tif_config.h will include cpl_port.h and includes this line: #define TIFF_UINT64_T GUIntBig I assume TIFF_UINT64 ultimately is used to define uint64. So I think you need to go through gdal/port/cpl_port.h and gdal/port/cpl_config.h to try and figure out how GUIntBig is getting defined. In cpl_port.h it helps to search for the block of code titled 64bit support. I would guess you want to use unsigned long long in which case you would need to have HAVE_LONG_LONG defined in cpl_config.h. I'm not aware of any recent changes in this logic so I'm not sure why it used to work and doesn't now. Best regards, Frank On Thu, Sep 26, 2013 at 4:33 PM, Nik Sands nix...@nixanz.com wrote: Hi list members, I've been using GDAL 1.10 as a statically linked library in an iOS app for some time. I recently recompiled GDAL again from the same local set of source files, using my notes on configuration options that I used last time, and ever since I've been having a problem every time the app attempts to open an image file. The app fails an assert() in the included tiff library (in tif_open.c), throwing the error: Assertion failed: (sizeof(uint64)==8), function TIFFClientOpen, file tif_open.c, line 99. The line in question is the last line of the code snippet from tif_open.c below: /* The following are configuration checks. They should be redundant, but should not * compile to any actual code in an optimised release build anyway. If any of them * fail, (makefile-based or other) configuration is not correct */ assert(sizeof(uint8)==1); assert(sizeof(int8)==1); assert(sizeof(uint16)==2); assert(sizeof(int16)==2); assert(sizeof(uint32)==4); assert(sizeof(int32)==4); assert(sizeof(uint64)==8); // - SIBABRT HERE The comments indicate that there may be a problem with the configure options I used when building GDAL, however I'm using exactly the same options (copy and pasted) as I used last time when it worked OK. So this leads me to think that perhaps something has changed in my environment, and the only thing I can think of is that I may be using a different version of GCC (I'm using the 'gcc' included with Apple's 'Xcode' IDE, and since the last compile of GDAL, I've upgraded from a beta build of Xcode to the production build of Xcode 5). I've tried it with GDAL 1.10.1 as well and get exactly the same problem. I'm stumped as to how to proceed with resolving this issue. Can anybody help me to overcome this? Note that the problem occurs when running on the real iOS device (armv7s) and on the iOS simulator (i386). Cheers, Nik. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] jpeg, tiff, IPP 8.0 and suspended I/O.
On Sun, Sep 22, 2013 at 10:21 PM, Tomaka, Jacek jacek.tom...@intergraph.com wrote: Hi, Recently I tried to compile GDAL 1.10 with libjpeg + IPP 8.0. I compiled IPP powered jpeglib 6b (taken from old IPP 7.0 samples, as IPP 8.0 examples contain version 8b). I run into several issues, after some investigation it turned out that different issues appear depending on the configuration of libjpeg library. 1. When libjpeg.IPP is compiled with IPP_SUSPENS defined then JPEG decoding does not work. i.e. gdal_translate from jpeg to tiff produces strange image. JPEG encoded TIFFs were all right in this configuration. 2. When libjpeg.IPP is compiled with IPP_SUSPENS not defined then JPEG encoded TIFFs decoding produces warning Warning 1: JPEGLib:Premature end of JPEG file. JPEG decoding is fine in this configuration. Strangely enough, the decoded images (JPEG encoded TIFFS) seem to be correct in this case, despite the warning. Note, I confirmed that IPPJ_HUFF is defined during jpeg, and gtiff formats compilation. If I don't define it I got the same warning but in greater abundance. Is there something obvious for You that I am missing? I read http://trac.osgeo.org/gdal/wiki/JpegIPP but it turns a blind eye on libjpeg configuration. Jacek, I don't recall any details about IPP_SUSPENS or IPPJ_HUFF. I'm not sure what is causing your problem and I haven't tried building with IPP for several years now. I also tried to compile GDAL with jpeglib 8b but with no luck. Is this version supported? My understanding is that modern GDAL's should work with libjpeg 8. If this isn't working, filing a ticket could be helpful. Is GDAL taking advantage of suspended I/O? Not that I'm aware of. Another issue is that when IPP is doing IDCT when decoding jpegs, autotests fail as it gives different checksums. Should I open a ticket for it? No need to file a ticket about this. I would expect the jpeg checksum based tests to fail. Has anyone had success making jpegs and tiffs compiled against jpeglib + IPP work? As I mention, it has been several years since I last did this, though it did work then with the notes in the JpegIPP trac topic. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Extracting (arbitrary?) overviews from ECW file
Markus, I believe the GDAL ECW driver will pass RasterIO() requests through to the ECW SDK to evaluate meaning that there is no constraint based on the advertized power-of-two overviews exposed from GDAL and no loss of quality. Best regards, Frank On Wed, Sep 4, 2013 at 6:52 AM, Markus Schneider schnei...@occamlabs.dewrote: Dear list, I am new to programming with GDAL (and to the ECW format). Let me say thank you first, because my first experiences have been rather pleasant, even if my setup is relatively involved (thanks everybody for providing good documentation): - Ubuntu 12.04 (AMD64) - GDAL 1.10.1 (build from source) - ECW SDK 5.0 - GDAL Java bindings I successfully created a toy Java class for extracting regions from an ECW file. Speed is impressive. My observations/questions: - If I understand correctly, ECW files internally do not have such a thing as fixed overviews. However, ECW supports extraction of regions with specified resolution on-the-fly. Is this correct? - GDAL API reports overviews for ECW datasets. Having a first look at the code, it seems to generate overview dimensions by subsequently dividing height and width by two (until a minium side length of 128 has been reached). Final question: Is it possible to efficiently retrieve (regions of) overviews at self-defined scales using the GDAL API? Or do I have to use the ECW SDK for that? Keep up the good work. Thanks for any pointers. Best regards, Markus -- Markus Schneider CEO Occam Labs UG (haftungsbeschränkt) Godesberger Allee 139 53175 Bonn, Germany +49 228 93798874 http://www.occamlabs.de ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
