Re: [gdal-dev] Motion: adopt RFC 87: Signed int8 data type for raster

Hi, Hermann Rodrigues wrote: > I dare to say that, if we are following this path, maybe GDAL should start > marketing itself as a set of command line tools and not as a > library, given that breaking compatibility just because we can is not > something a library developer should do, IMHO. Hype

Re: [gdal-dev] Motion: adopt RFC 87: Signed int8 data type for raster

Hermann, I dare to say that, if we are following this path, maybe GDAL should start marketing itself as a set of command line tools and not as a library, given that breaking compatibility just because we can is not something a library developer should do, IMHO. I believe your words aren't re

Re: [gdal-dev] Motion: adopt RFC 87: Signed int8 data type for raster

Kurt, In the ideal world, everything has a unit test. In the real world, there are a lot of applications that keep things turning around that were not developed with the same level of care. And yet, we use them everyday. We have unit tests and a lot of them, but not everybody or everything does.

Re: [gdal-dev] Motion: adopt RFC 87: Signed int8 data type for raster

Hermann, Speaking to GDAL being one (not very small) piece of an ecosystem of libraries and tools: This is exactly what unit tests are for. A well done tool or library should have the tests that cover their critical uses of libraries they depend on. It's often referred to as the "Beyonce rule":

Re: [gdal-dev] Motion: adopt RFC 87: Signed int8 data type for raster

I think long term compatibility is a very desirable feature, and several applications just use GDAL as part of their code base without even being aware of what is happening in the GDAL development front. The same is true for several other libraries, given the fact the use of package manager

Re: [gdal-dev] Call for discussion: RFC88: Use GoogleTest framework for C/C++ unit tests

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.* th

Re: [gdal-dev] Motion: adopt RFC 87: Signed int8 data type for raster

Hi > > > So based on that RFC it is a breaking change when reading signed > > images. I confess that this type of silent behavor change scares me. > It is documented in > https://github.com/OSGeo/gdal/blob/master/MIGRATION_GUIDE.TXT which is > always referenced in the release notes. > > > > Why d

[gdal-dev] Call for discussion: RFC88: Use GoogleTest framework for C/C++ unit tests

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

Re: [gdal-dev] Motion: adopt RFC 87: Signed int8 data type for raster

So based on that RFC it is a breaking change when reading signed images. I confess that this type of silent behavor change scares me. It is documented in https://github.com/OSGeo/gdal/blob/master/MIGRATION_GUIDE.TXT which is always referenced in the release notes. Why dont make this an op

Re: [gdal-dev] Motion: adopt RFC 87: Signed int8 data type for raster

Hi, So based on that RFC it is a breaking change when reading signed images. I confess that this type of silent behavor change scares me. Why dont make this an opt-in behavior instead of just breaking application code silently? Otherwise, I would rather have GDT_Byte removed so that application c

Re: [gdal-dev] Motion: adopt RFC 87: Signed int8 data type for raster

Le 16/11/2022 à 17:32, Hermann Rodrigues a écrit : Hi, I am a bit late for this discussion, but can someone please clarify if this is a breaking change? Is this keeping the old behavior in place when reading GDT_Byte or replacing it completely when reading rasters storing 8-bit pixels? Thi

Re: [gdal-dev] Motion: adopt RFC 87: Signed int8 data type for raster

Hi, I am a bit late for this discussion, but can someone please clarify if this is a breaking change? Is this keeping the old behavior in place when reading GDT_Byte or replacing it completely when reading rasters storing 8-bit pixels? Best, hermann -

Re: [gdal-dev] A CSW query that seems to me works badly

Hi Even, On Wed, 16 Nov 2022 at 14:17, Even Rouault wrote: > No, title is not in the lists of hardcoded fields by the OGR CSW driver. > Probably a fix/improvement to do in the driver. > > If I recall well from git history, I coded the driver on a rainy sunday > afternoon 7 years ago, and it didn

Re: [gdal-dev] A CSW query that seems to me works badly

Le 16/11/2022 à 14:07, andy a écrit : Hi Even, On Wed, 16 Nov 2022 at 14:00, Even Rouault wrote: No, that's not currently implemented in the driver. It hardcodes "subject" to "dc:subject" and "title" to "dc:title", and doesn't use SupportedISOQueryables. If I use `dc:title` in

Re: [gdal-dev] A CSW query that seems to me works badly

Hi Even, On Wed, 16 Nov 2022 at 14:00, Even Rouault wrote: > No, that's not currently implemented in the driver. It hardcodes "subject" > to "dc:subject" and "title" to "dc:title", and doesn't use > SupportedISOQueryables. > If I use `dc:title` in this XML query curl -X POST -H "Content-Type: a

Re: [gdal-dev] Motion: adopt RFC 87: Signed int8 data type for raster

I declare this motion passed with +1 from PSC members KurtS, JukkaR, MateuszL and me. Even Le 14/11/2022 à 13:22, Even Rouault a écrit : Hi, I feel the discussion phase has finished. There were a few questions about the existing GDT_Byte unsigned 8-bit integer type, if it should be renamed/

Re: [gdal-dev] A CSW query that seems to me works badly

Le 16/11/2022 à 13:41, andy a écrit : Here another example: http://www.pcn.minambiente.it/geoportal/csw?request=getCapabilities&service=csw In the SupportedISOQueryables I have `apiso:Title`. Is it possible to

Re: [gdal-dev] A CSW query that seems to me works badly

Here another example: http://www.pcn.minambiente.it/geoportal/csw?request=getCapabilities&service=csw In the SupportedISOQueryables I have `apiso:Title`. Is it possible to use ogrinfo and search using a where condition based on the `apiso:Title` field? Thank you -- ___ Andrea

Re: [gdal-dev] A CSW query that seems to me works badly

Hi, I'm adding another related question. In the CSW server I'm using, we have some element that I can query, as "subject" and "abstract". In the documentation I read that I can run a query using both OGC ISO AP names and Dublin core names. In example `apiso:subject` and `dc:subject`. If I run

Re: [gdal-dev] A CSW query that seems to me works badly

But I didn't imagine that write this ogrinfo --debug on -ro -al "CSW:http://geodati.gov.it/RNDT/csw"; -where "abstract LIKE 'Impianti e strutture ricettive'" was a search in OR: Impianti OR e OR strutture OR ricettive, because since it's some kind of SQL command, to me it meant exactly the w

Re: [gdal-dev] A CSW query that seems to me works badly

Even first of all thank you On Wed, 16 Nov 2022 at 11:51, Even Rouault wrote: > That returns zero feature. That said, I'm not sure that is what you want > to do, since the server should really look for a dc:subject whose value > is "Impianti e strutture ricettive", with the double quotes. > > Pr

Re: [gdal-dev] A CSW query that seems to me works badly

Hi, I need to run a CSW query using exact strings. Via curl it's in this way '"Impianti e strutture ricettive"' (using the double quotes inside): hum, well you actually hit a bug in the OGR OGC Filter code I've just fixed per https://github.com/OSGeo/gdal/pull/6713 With the fix the query s

Re: [gdal-dev] A CSW query that seems to me works badly

Hi Brad, It looks like the filter is doing something (since without it, I get about > a thousand times the results - 22700 vs 22). I think that when I have more words, it works in OR. I don't know if this is the right/standard way to work. If I apply double quotes - "Impianti e strutture ricett

Re: [gdal-dev] A CSW query that seems to me works badly

Hi Even, I need to run a CSW query using exact strings. Via curl it's in this way '"Impianti e strutture ricettive"' (using the double quotes inside): curl -X POST -H "Content-Type: application/xml; charset=UTF-8" -d 'http://www.opengis.net/cat/csw/2.0.2"; xmlns:gml="http://www.opengis.net/gml";

Re: [gdal-dev] Working with IFC files

Hi, we sponsored a feasability study for ifc support in qgis/gdal in 2021, it is in in french but I'll try to sum it up asap Le mercredi 16 novembre 2022 à 10:00 +0100, Stefano Iacovella a écrit : > Hi all, > > I am working with BIM data to integrate them in a geodatabase. > Data are delivered in

[gdal-dev] Working with IFC files

Hi all, I am working with BIM data to integrate them in a geodatabase. Data are delivered in IFC format (1) I am curious about the possibility to ingest them using OGR. As far as I know there's no driver available. Is there someone in the list who has had some experience in a similar scenario? Th