Le 24/03/2022 à 18:36, Erixen Cruz a écrit :
PROJ4_GRIDS provided a way to specify exactly which geoid file(s)
to use. Some vertical datums, such as NAVD88, only have a single
EPSG code for multiple geoids – what’s the replacement for
PROJ4_GRIDS in PROJ9? If I could switch
Steve,
(adding proj mailing list since it's actually purely a PROJ topic
Does the fact that there isn’t a consensus mean 3126 & 3127 aren’t
going to end up in a PROJ release?
Did you try them to confirm they help ? Maybe if you want to weight in
the PRs (if they actually help) that could
Sean,
You can use any of the existing cloud-storage oriented configuration
option, so for example for AWS, you could just set the AWS_PROFILE
(being one listed in
https://gdal.org/user/virtual_file_systems.html#vsis3-aws-s3-files) that
corresponds to a path. The main use case was for code
Hi Even,
Does the fact that there isn’t a consensus mean 3126 & 3127 aren’t going to end
up in a PROJ release?
I read through the PR’s. Are you thinking my issue is that a vertical shift is
being introduced because of a transformation to WGS84 (from NAD83(CSRS)) to
look up the geoid
Even,
At the very least, the new file duplicates storage of credentials that may
already be stored in cloud-specific credentials files, and creates a new
way for users to expose their secrets. Also, cloud providers and
organizations have moved or are moving to focusing on short-lived
credentials,
Sean,
I saw them as business-as-usual enhancements not impacting the software
in fundamental ways. I'm not sure what I would put in a RFC that is not
in their commit message. Maybe I don't understand what your concern is.
Even
Le 24/03/2022 à 15:28, Sean Gillies a écrit :
Hi all,
The
Hi all,
The intent and scope of the features developed in
https://github.com/OSGeo/gdal/pull/5463 and
https://github.com/OSGeo/gdal/pull/5390 seem rather big and unclear to me.
This seems to me to warrant an RFC. Yes? No?
--
Sean Gillies
___
gdal-dev
Bas,
given that autoconf support for GDAL will remain in 3.5.0, we can keep
things unchanged for now in frmts/grass/GNUmakefile if the driver
remains in-tree. Once autoconf support for GDAL is gone, indeed the
simplification of your patch could be done.
But the status of last discussions is
How will the gdal-grass tarball be generated?
Will frmts/grass/GNUmakefile remain with only the dist target, e.g. like
attached patch?
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1diff --git a/frmts/grass/GNUmakefile
Hi All,
First of all, thank you for your support and great work on GDAL!
I have a strange issue using either ogrinfo (GDAL 3.0.4, released
2020/01/28) on Ubuntu 20 or OGR WFS driver on Mapserver 7.6.4-1 .
When I call on a particular public server, gdal / ogr
On 24.03.22 12:23, Even Rouault wrote:
- I wasn't able to figure out how to build the docs? cmake
-DBUILD_DOCS=On works so far as cmake configuration succeeds. Then
make documentation fails with missing br/ru localized files, and
commenting those targets out there seems to be a mismatch
On 3/24/22 12:23, Even Rouault wrote:
- do like we did in recent versions, ie have no doc/ directory in the
tarball, and just generated man pages (will need
https://github.com/OSGeo/gdal/issues/5491 to be implemented to
automatically have CMake to install the generated man pages)
This has my
Hi Sandro,
I gave it a spin for Fedora:
- Does not build against JasPer-3.0.2: there are two signature
mismatches:
Jasper support will be dropped soon (see
https://github.com/OSGeo/gdal/pull/5269). You should rather use the
JP2OpenJPEG driver using libopenjp2 from
On 21.03.22 00:05, Even Rouault wrote:
Hi,
As discussed a few weeks ago, here's a GDAL 3.5.0alpha1 snapshot,
mostly for the sake of exercising the new CMake build system (thanks
to all early testers and contributors!). The libtool numbers have
*not* been updated (I believe they are still
14 matches
Mail list logo
