Hi Even,
Sorry for the delay, but I’ve now tested with PR3216, alone, and then with
PR3127. I’m getting the same behavior as I reported below. Perhaps my best
chance at getting this to work is to either directly make proj calls, or
construct the pipeline myself and pass through gdal?
Steve
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 c
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 separation
Steve,
you may try PR https://github.com/OSGeo/PROJ/pull/3126 or
https://github.com/OSGeo/PROJ/pull/3127, that might potentially help,
but they don't make consensus (see discussions of those PRs). Basically
it is a nightmare to deal with the old TOWGS84 / PROJ4_GRIDS approach,
that poorly spe
Hi Even,
I tried the fix with the CRS’s I sent, and it worked. But as I mentioned, my
real target CRS is a custom projected system (below), and it still fails with
what seems to be the same error as in my original email.
COMPD_CS["TempTM + CGVD28 height - HT2_0",
PROJCS["Custom",
GE
Hi
Is there a "more modern" way to use a geoid file that is not included in
the default ones? (let's say, a non open one, like the German)
EXTENSION["PROJ4_GRIDS","HT2_0.gtx"] seems to be "proj4 style", right?
Even mentioned months ago that the tag GEOIDMODEL meaning was changed by
EPSG somehow (
Thanks very much, Even. For reporting the problem, I “packaged up” a case with
CRS’s with EPGS codes. For the actual problem I’m working, the target CRS is a
custom projection –no EPSG.
From: Even Rouault
Sent: Friday, March 18, 2022 5:05 PM
To: Steve Riddell ; gdal-dev@lists.osgeo.org
Subject
Steve,
Fix in PROJ queued in https://github.com/OSGeo/PROJ/pull/3123
The complexity of dealing with legacy features TOWGS84[] and PROJ4_GRIDS
is highly stressing PROJ pipeline computation engine.
Using the plain EPSG codes EPSG:4955 -> EPSG:4617+5713 would be much
preferable here
Even
Le
Hi,
I’m getting an error (below) using GDAL trying to set up a transformation
between NAD83(CSRS) geodetic, w/ ellipsoidal heights, and NAD83(CSRS) geodetic,
CGVD28 heights. Similar transformations work fine on some datums, but fail on
others. Hope someone can offer some insight. Note the if
On jeudi 23 janvier 2020 18:43:24 CET Even Rouault wrote:
> On jeudi 23 janvier 2020 18:35:40 CET Edzer Pebesma wrote:
> > On 1/23/20 5:58 PM, Even Rouault wrote:
> > >> Thanks! Yes, with SRS->importFromUserInput("EPSG:3857"); etc this works
> > >> fine; I'm OK with the warning, I just don't see ho
On jeudi 23 janvier 2020 18:35:40 CET Edzer Pebesma wrote:
> On 1/23/20 5:58 PM, Even Rouault wrote:
> >> Thanks! Yes, with SRS->importFromUserInput("EPSG:3857"); etc this works
> >> fine; I'm OK with the warning, I just don't see how the subsequent error
> >> relates to syntax that is deprecated.
On 1/23/20 5:58 PM, Even Rouault wrote:
>> Thanks! Yes, with SRS->importFromUserInput("EPSG:3857"); etc this works
>> fine; I'm OK with the warning, I just don't see how the subsequent error
>> relates to syntax that is deprecated.
>
> I'm looking at this, but haven't yet an explanation. This is
> Thanks! Yes, with SRS->importFromUserInput("EPSG:3857"); etc this works
> fine; I'm OK with the warning, I just don't see how the subsequent error
> relates to syntax that is deprecated.
I'm looking at this, but haven't yet an explanation. This is very subtle,
and seems to be linked specifically
On 1/23/20 5:29 PM, Sean Gillies wrote:
> Hi,
>
> On Thu, Jan 23, 2020 at 8:01 AM Edzer Pebesma
> mailto:edzer.pebe...@uni-muenster.de>>
> wrote:
>
> The combination of GDAL 3.0.3 and PROJ 6.3.0 arriving on debian
> platforms is causing some havoc for some spatial R packages. I could
>
Hi,
On Thu, Jan 23, 2020 at 8:01 AM Edzer Pebesma
wrote:
> The combination of GDAL 3.0.3 and PROJ 6.3.0 arriving on debian
> platforms is causing some havoc for some spatial R packages. I could
> bring one particular problem back to the following C++ program:
>
> #include
> #include "ogrsf_frmt
The combination of GDAL 3.0.3 and PROJ 6.3.0 arriving on debian
platforms is causing some havoc for some spatial R packages. I could
bring one particular problem back to the following C++ program:
#include
#include "ogrsf_frmts.h"
#include
int main() {
OGRSpatialReference *aSRS = new OGRSpa
16 matches
Mail list logo
