On Thu, 7 Nov 2019 at 20:05, Roger Bivand wrote:
> Thanks for contributing! In research reproducibility, being able now to
> get the same results as when the research was conducted using the same
> software is basic.
(again, apologies if I'm ignorant here -- I'm coming from a totally
different d
On Thu, 7 Nov 2019, Even Rouault wrote:
On jeudi 7 novembre 2019 11:10:26 CET Roger Bivand wrote:
On Thu, 7 Nov 2019, Even Rouault wrote:
On jeudi 7 novembre 2019 15:24:44 CET Nyall Dawson wrote:
On Wed, 30 Oct 2019 at 06:16, Even Rouault
wrote:
I realise this too, but to permit legacy re
On jeudi 7 novembre 2019 11:10:26 CET Roger Bivand wrote:
> On Thu, 7 Nov 2019, Even Rouault wrote:
> > On jeudi 7 novembre 2019 15:24:44 CET Nyall Dawson wrote:
> >> On Wed, 30 Oct 2019 at 06:16, Even Rouault
> >
> > wrote:
> I realise this too, but to permit legacy results to be replicated
On Thu, 7 Nov 2019, Even Rouault wrote:
On jeudi 7 novembre 2019 15:24:44 CET Nyall Dawson wrote:
On Wed, 30 Oct 2019 at 06:16, Even Rouault
wrote:
I realise this too, but to permit legacy results to be replicated,
Some legacy behaviour was just plain wrong/inaccurate. Trying to replicate
On Thu, 7 Nov 2019, Nyall Dawson wrote:
On Wed, 30 Oct 2019 at 06:16, Even Rouault wrote:
I realise this too, but to permit legacy results to be replicated,
Some legacy behaviour was just plain wrong/inaccurate. Trying to
replicate it in PROJ would be heartbreaking, an extra maintaince
b
On jeudi 7 novembre 2019 15:24:44 CET Nyall Dawson wrote:
> On Wed, 30 Oct 2019 at 06:16, Even Rouault
wrote:
> > > I realise this too, but to permit legacy results to be replicated,
> >
> > Some legacy behaviour was just plain wrong/inaccurate. Trying to replicate
> > it in PROJ would be heartb
On Wed, 30 Oct 2019 at 06:16, Even Rouault wrote:
>
> > I realise this too, but to permit legacy results to be replicated,
>
> Some legacy behaviour was just plain wrong/inaccurate. Trying to replicate it
> in PROJ would be heartbreaking, an extra maintaince burden, and a confusion
> for PROJ user
> I'm a bit extreme when I say "don't use PROJ strings", but otherwise
people
> don't get it :-) So yes if you don't care about datum transformations,
don't
> use unusual axis orders, you might still use them. They won't disappear
in a
> foreseable future.
> The GDAL OGRSpatialReference class has a
On mercredi 30 octobre 2019 09:22:11 CET Michael Sumner wrote:
> Great discussion, thanks to both of you. I have a question.
>
> I wonder how we ought to specify a projection that we desire, I work in
> contexts where 1.5m or even 1.5 km is not an unreasonable level of
> precision, and we get a l
Great discussion, thanks to both of you. I have a question.
I wonder how we ought to specify a projection that we desire, I work in
contexts where 1.5m or even 1.5 km is not an unreasonable level of
precision, and we get a lot of value out of specifying local projections
(at ocean basin scale) in
> The underlying problem is that users may face silent degradation in
> workflows as they upgrade sf and rgdal to PROJ >= 6 and GDAL >= 3 if they
> are not prompted to take remedial steps themselves. I realise that users
> have become too comfortable, but user guidance will be essential to avoid
>
Even,
Thanks!
On Tue, 29 Oct 2019, Even Rouault wrote:
Roger,
In looking at ways to adapt R packages rgdal and sf to current GDAL and
PROJ, I have run into a problem. Many existing vector files (I have not
yet looked at raster) include a datum declaration, which is still
present internally
Roger,
> In looking at ways to adapt R packages rgdal and sf to current GDAL and
> PROJ, I have run into a problem. Many existing vector files (I have not
> yet looked at raster) include a datum declaration, which is still present
> internally in the OGRSpatialReference object, but is dropped in t
In looking at ways to adapt R packages rgdal and sf to current GDAL and
PROJ, I have run into a problem. Many existing vector files (I have not
yet looked at raster) include a datum declaration, which is still present
internally in the OGRSpatialReference object, but is dropped in the output
of
14 matches
Mail list logo
