Progress with other libraries and tools is happening. Maybe not speedy,
but it's going.
e.g. I just got this patch in for Vision Workbench:
https://github.com/visionworkbench/visionworkbench/pull/42
On Fri, Jan 29, 2016 at 2:36 PM, Roger Bivand wrote:
> Even Rouault spatialys.com> writes:
>
>
Even Rouault spatialys.com> writes:
>
> Le vendredi 29 janvier 2016 15:20:07, Bas Couwenberg a écrit :
> > Even Rouault wrote:
> > > It is not definite how long the team will still maintain the 1.11 branch,
> > > so users are strongly encouraged to migrate to 2.0.2.
> >
> > Because not all reve
Thanks Jürgen for the information - I was getting a little desperate :-)
Regards Bo Victor
2016-01-29 14:08 GMT+01:00 Jürgen E. :
> Hi Bo Victor Thomsen,
>
> On Fri, 29. Jan 2016 at 14:01:49 +0100, Bo Victor Thomsen wrote:
> > Is there anywhere I can download Windows binaries of these GDAL
> ver
Le vendredi 29 janvier 2016 16:24:00, Daniel Fenton a écrit :
> Even,
>
> I'm not sure if this helps,
Me neither ;-), but thanks for jumping into this.
> but in dealing with an issue with WKID 5514,
EPSG:5514 is east-north oriented (like EPSG:5221, the GIS friendly equivalent
of EPSG:2065), s
Even,
I'm not sure if this helps, but in dealing with an issue with WKID 5514,
this WKT workers to properly convert data from WGS84. This was confirmed
against a customer's source data.
'
PROJCS["S-JTSK_Krovak_East_North",GEOGCS["GCS_S_JTSK",DATUM["Jednotne_Trigonometricke_Site_Katastralni",SPHERO
Le vendredi 29 janvier 2016 15:20:07, Bas Couwenberg a écrit :
> Even Rouault wrote:
> > It is not definite how long the team will still maintain the 1.11 branch,
> > so users are strongly encouraged to migrate to 2.0.2.
>
> Because not all reverse dependencies support GDAL 2.0 yet, the next Debia
Even Rouault wrote:
> It is not definite how long the team will still maintain the 1.11 branch, so
> users are strongly encouraged to migrate to 2.0.2.
Because not all reverse dependencies support GDAL 2.0 yet, the next Debian
stable release (stretch) will most likely stick to 1.11.x as will the
Hi Bo Victor Thomsen,
On Fri, 29. Jan 2016 at 14:01:49 +0100, Bo Victor Thomsen wrote:
> Is there anywhere I can download Windows binaries of these GDAL versions ?
> (gisinternals.com doesn't contain ver. 2.0.n)
osgeo4w contains 2.0.2 (not yet the final, but RC2 I think) as experimental
(enable
Is there anywhere I can download Windows binaries of these GDAL versions ?
(gisinternals.com doesn't contain ver. 2.0.n)
Regards
Bo Victor Thomsen
-- Forwarded message --
From: Even Rouault
Date: 2016-01-29 12:16 GMT+01:00
Subject: [gdal-dev] GDAL/OGR 2.0.2 and 1.11.4 releas
Hi,
On behalf of the GDAL/OGR development team, I am pleased to
announce the release of the GDAL/OGR 1.11.4 and 2.0.2 bug fix versions. They
contain respectively 44 and 92 bug fixes since 1.11.3 / 2.0.1.
The sources for 1.11.4 are available at:
http://download.osgeo.org/gdal/1.11.4/gdal-1.11.
Le mercredi 27 janvier 2016 11:29:09, Even Rouault a écrit :
> Hi,
>
> Motion 1: GDAL/OGR 1.11.4 RC2 is promoted to be the official 1.11.4 final
> release.
>
> Motion 2: GDAL/OGR 2.0.2 RC4 is promoted to be the official 2.0.2 final
> release.
>
> --
>
> My votes :
> Motion 1: + 1
> Motion 2: +
Le vendredi 29 janvier 2016 10:52:48, Jukka Rahkonen a écrit :
> Ari Jolma gmail.com> writes:
> > Should storing data, with measures, into a format, which does not
> > support measures, remove M values from the data? This would be similar
> > to the current behavior with curved geometries and form
Ari Jolma gmail.com> writes:
> Should storing data, with measures, into a format, which does not
> support measures, remove M values from the data? This would be similar
> to the current behavior with curved geometries and formats which do not
> support them.
I wonder what should happen when
29.01.2016, 11:04, Even Rouault kirjoitti:
I had let an inline comment in the RFC regarding that. My opinion is that
child geometries should be affected to avoid building geometries that are
odd, and perhaps non conformant (should be checked but I'd be surprised
it is legal to have the containe
29.01.2016, 11:20, Ari Jolma kirjoitti:
29.01.2016, 11:13, Even Rouault kirjoitti:
Le vendredi 29 janvier 2016 08:55:37, Ari Jolma a écrit :
A question about OGRPoint.
There are copy constructor, assignment, and clone. Shouldn't these do
basically the same thing but with a bit different sy
29.01.2016, 11:13, Even Rouault kirjoitti:
Le vendredi 29 janvier 2016 08:55:37, Ari Jolma a écrit :
A question about OGRPoint.
There are copy constructor, assignment, and clone. Shouldn't these do
basically the same thing but with a bit different syntax?
Yes they are supposed to do the same
>
> Perhaps it works because I am only appending to a single layer that has the
> same schema throughout?
Yes
> I did test this, but the performance was indeed slower. Is there a way for
> me to specify the schema before-hand and avoid a full first pass?
>
> Perhaps for a driver implementation
Le vendredi 29 janvier 2016 08:55:37, Ari Jolma a écrit :
> A question about OGRPoint.
>
> There are copy constructor, assignment, and clone. Shouldn't these do
> basically the same thing but with a bit different syntax?
Yes they are supposed to do the same thing and hopefully the implementation
> > I had let an inline comment in the RFC regarding that. My opinion is that
> > child geometries should be affected to avoid building geometries that are
> > odd, and perhaps non conformant (should be checked but I'd be surprised
> > it is legal to have the container and the containee with differ
29.01.2016, 09:55, Ari Jolma kirjoitti:
A question about OGRPoint.
There are copy constructor, assignment, and clone. Shouldn't these do
basically the same thing but with a bit different syntax? By the same
thing I mean that the new point or assignee should have the same flags
(is_empty, is
20 matches
Mail list logo
