?
On Tue, Apr 27, 2021 at 12:08 AM wrote:
> Ok. Have a nice day.
>
> On 27 Apr. 2021 04:45, jovajova24 wrote:
>
> Brad,
>
> Thanks for the reply!
> The objects I'm referring to are what I have listed i.e.,
>
> NITFSegmentInfo
> NITFDESGetXml
>
> These objects were changed in the PR I have list
Ok. Have a nice day. On 27 Apr. 2021 04:45, jovajova24 wrote:Brad,
Thanks for the reply!
The objects I'm referring to are what I have listed i.e.,
NITFSegmentInfo
NITFDESGetXml
These objects were changed in the PR I have listed i.e.,
https://github.com/OSGeo/gdal/pull/3153/files#diff-084e5d55477
GDAL_DATA is evaluated as the argument of fopen(), so if it is relative,
you need to be a current directory consistent with the relative path for
it to work. You'd generally want ot use an absolute path for GDAL_DATA
I see that in pytest.ini a commented line with #GDAL_DATA =
../gdal/data. And
On Mon, Apr 26, 2021 at 10:44 AM Even Rouault
wrote:
> DGN writing indeeds need GDAL_DATA to be set and point to the directory
> that contains seed_2d.dgn
>
Is it the case that GDAL_DATA is relative to the directory containing the
test rather than the test driver directory (autotest)? Changing a
Is this a know bug?
Now, yes :-)
Maybe fixed in PROJ 8.0.0? (I had not time to test it there yet)
No, it is GDAL specific. You'll need to patch
OGRSpatialReference::GetAxesCount() in the ( d->m_pjType ==
PJ_TYPE_COMPOUND_CRS ) case, to test if a component of the compound CRS
is a bound C
If I try to get the number of axes in C++ from the srs "EPSG:29901+5773", I
get different values depending on how I create the wkt.
I am using the method "OGRSpatialReference::GetAxesCount()"
If I create it with projinfo with the option "--boundcrs-to-wgs84", the
number of axis is 0.
and the error
Brad,
Thanks for the reply!
The objects I'm referring to are what I have listed i.e.,
NITFSegmentInfo
NITFDESGetXml
These objects were changed in the PR I have listed i.e.,
https://github.com/OSGeo/gdal/pull/3153/files#diff-084e5d55477ff6b3acacb5bf240281a52d778c07106fb1fb2b53f1275988a25eR2476-
DGN writing indeeds need GDAL_DATA to be set and point to the directory
that contains seed_2d.dgn
You can source scripts/setdevenv.sh to set the appropriate environment
variables for a dev env.
Le 26/04/2021 à 16:38, Andrew Bell a écrit :
On Mon, Apr 26, 2021 at 10:18 AM Even Rouault
mail
On Mon, Apr 26, 2021 at 10:18 AM Even Rouault
wrote:
> Andrew,
>
> you don't need to add autotest/ogr to GDAL_DATA.
>
> Normally this is done in autotest/pytest.ini
>
Thanks. I missed that.
> I suspect you don't have the pytest-env python module installed.
>
> You should probably just run:
>
> p
Andrew,
you don't need to add autotest/ogr to GDAL_DATA.
ARCGEN is now a deprecated driver and must be explictly enabled with
GDAL_ENABLE_DEPRECATED_DRIVER_ARCGEN=YES env variable.
Normally this is done in autotest/pytest.ini
I suspect you don't have the pytest-env python module installed.
Hi,
I'm trying to run autotests and am failing to find data. For instance, I
get the error:
def test_ogr_arcgen_points():
ds = ogr.Open('data/arcgen/points.gen')
> assert ds is not None, 'cannot open dataset'
E AssertionError: cannot open dataset
E assert None is no
Hi,
I have prepared a GDAL/OGR 3.3.0 release candidate. The feedback on beta1 was
useful to spot and fix a few bugs.
The changes between beta1 and RC1 are identified in:
https://github.com/OSGeo/gdal/commit/a882173d688e6042c9dc7b1b57d8d169b04abe2b
Note a potential impact on packaging recipees r
12 matches
Mail list logo
