Note that the same logic should be applied to the spatial features, if
these are handled (i.e. RETURN_PRIMITIVES=ON).
And for feature-feature links, i.e. RETURN_LINKAGES=ON
Thank you all for your explanations.
I'm sad that this is a mistake in the doc :-) because as you pointed out S57
spec
On 5/3/20 10:05 PM, Even Rouault wrote:
>> It's indeed not possible to make everybody happy, so the question is who
>> you do mind the least to make unhappy.
>>
>> If nothing changes packagers like me will be unhappy because they need
>> to reintroduce the virtual dependency for the unstable C++ AB
> What I menat is that in the text of NEWS, you should not say that
the C
> ABI is unchanged. A "ABI has not changed" statement implies that
one
> can swap in the new binaries without rebuilding any depending
packages.
That would be true: you could replace the .so of GDAL 3.0 by the one
of 3
Even Rouault writes:
>> Not 100% sure I followed, but: If you change the shlib major
> number,
>> you have changed the ABI, even if the symbols are the same.
>
> Yes, but the reasoning is actually the reverse: the (C++) ABI has
> changed, so given libgdal contains both a C and C++ API, we
> h
> Not 100% sure I followed, but: If you change the shlib major
number,
> you have changed the ABI, even if the symbols are the same.
Yes, but the reasoning is actually the reverse: the (C++) ABI has
changed, so given libgdal contains both a C and C++ API, we
have to bump th shlib major number.
Even Rouault writes:
>> It's indeed not possible to make everybody happy, so the question is who
>> you do mind the least to make unhappy.
>>
>> If nothing changes packagers like me will be unhappy because they need
>> to reintroduce the virtual dependency for the unstable C++ ABI.
>>
>> C-only
On Sat, 2 May 2020 at 08:01, Craig Delancy
wrote:
> I am trying to explain to a colleague how the affine transform maps image
> coordinates onto a projection system.
> Specifically, I am trying to explain how mathematically speaking, any
> parallelogram section of the coordinate system can be re
Thank you all for your explanations.
I'm sad that this is a mistake in the doc :-) because as you pointed out S57
spec has no GUID definition. With the combination of the LNAM + DSNM, it
allowed to have one that would be convenient in a PostGIS database that
contains many S-57 charts.
On my fo
> It's indeed not possible to make everybody happy, so the question is who
> you do mind the least to make unhappy.
>
> If nothing changes packagers like me will be unhappy because they need
> to reintroduce the virtual dependency for the unstable C++ ABI.
>
> C-only users will be unhappy about h
Sebastiaan Couwenberg writes:
> It's indeed not possible to make everybody happy, so the question is who
> you do mind the least to make unhappy.
>
> If nothing changes packagers like me will be unhappy because they need
> to reintroduce the virtual dependency for the unstable C++ ABI.
>
> C-only
Even Rouault writes:
> Answering Bas'
>
>> If you don't want that, then two libraries need to be built with their
>> own library versioning.
>
> and Gregs'
>
>> This doesn't make sense. The current/revision/age needs to be handled
>> differently for the C library and the C++ library, because in
On 5/3/20 9:15 PM, Even Rouault wrote:
> Answering Bas'
>
>> If you don't want that, then two libraries need to be built with their
>> own library versioning.
>
> and Gregs'
>
>> This doesn't make sense. The current/revision/age needs to be handled
>> differently for the C library and the C++ l
Answering Bas'
> If you don't want that, then two libraries need to be built with their
> own library versioning.
and Gregs'
> This doesn't make sense. The current/revision/age needs to be handled
> differently for the C library and the C++ library, because in feature
> releases one of them doe
Even Rouault writes:
[I'm behind in dealing with gdal, but otherwise would be in the same
boat as Bas]
> There has been obviously a misunderstanding. The rule we follow is that:
> - between GDAL X.Y.Z and X.Y.(Z+1), both C and C++ ABI are stable
> - between GDAL X.Y and X.(Y+1), the C ABI is sta
On 5/3/20 8:10 PM, Even Rouault wrote:
>> Why wasn't the SONAME bumped to reflect the ABI breakage?
>
> For me, SONAME bump was meant for the C ABI. I don't think this was intended
> for the C++
> one.
They share the same library, so the SONAME covers both.
If you don't want that, then two lib
> Why wasn't the SONAME bumped to reflect the ABI breakage?
For me, SONAME bump was meant for the C ABI. I don't think this was intended
for the C++
one.
> We dropped the virtual dependency that required rebuilding for every
> GDAL version change because you claimed that this wasn't required an
On 5/3/20 7:47 PM, Even Rouault wrote:
> Looking at what is presumably the native side of ogrListLayers(),
> https://salsa.debian.org/r-pkg-team/r-cran-rgdal/-/blob/master/src/ogrsource.cpp#L1090
>
> I see it use thes GDAL C++ API. Given that the C++ ABI can change between
> GDAL feature
> relea
On 5/3/20 7:36 PM, Edzer Pebesma wrote:
> In the r-cran-sf logs, I find:
>
> autopkgtest [09:48:59]: build not needed
>
> But if a new version of GDAL was just installed, a build would have been
> needed (assuming we use dynamic linking).
GDAL did not bump the SONAME, so it claims to be ABI comp
On dimanche 3 mai 2020 19:22:11 CEST Sebastiaan Couwenberg wrote:
> On 5/3/20 7:09 PM, Even Rouault wrote:
> > Looking at
> > https://ci.debian.net/data/autopkgtest/unstable/amd64/r/r-cran-rgdal/52035
> > 87/log.gz , there doesn't seem to be much detail about what fails
> > exactly.
>
> From the
Hi Bas and Even,
I'm the author/maintainer of the sf package; Roger and I both follow
this list actively. Neither Roger nor me have been involved (nor
consulted, at least I wasn't) in the creation of the r-cran-sf or
r-cran-rgdal packages. I'd be happy to check out what is wrong, but have
no clue
On 5/3/20 7:09 PM, Even Rouault wrote:
> Looking at
> https://ci.debian.net/data/autopkgtest/unstable/amd64/r/r-cran-rgdal/5203587/log.gz
> ,
> there doesn't seem to be much detail about what fails exactly.
From the log:
autopkgtest [09:49:06]: test run-unit-test: [---
..
Roger,
For my understanding, are the failing tests mentioned by Bas maintained by the
rgdal project
?
I assume they must be run by
https://salsa.debian.org/r-pkg-team/r-cran-rgdal/-/blob/master/debian/tests/run-unit-test
and the actual tests are:
https://salsa.debian.org/r-pkg-team/r-cran-rgdal/
DSNM is dataset name. I'ts defined in the DSID which only occurs in the
first field/subfield group in the dataset - not sure what the driver does
in respect of it. In terms of identifiers s-57 has "FOID"s, so each feature
has a unique id made up of a combination of the agency code and two
integers
On dimanche 3 mai 2020 09:54:22 CEST kusala nine wrote:
> DSNM is dataset name. I'ts defined in the DSID which only occurs in the
> first field/subfield group in the dataset - not sure what the driver does
> in respect of it.
Right. The driver doc was incorrect. I've just fixed it per
https://gith
Hi
I have not checked the GDAL implementation but DSNM is an unneccessary
addition to the S57 spec to generate a (potential unique) GUID.
S57 spec has no GUID definition, IDs needs only be to unique inside a
dataset/ENC cell.
DSNM belongs to the dataset-wide DSID fields, see 6.3.2 in
https:/
25 matches
Mail list logo
