On 6 May 2016 at 08:54, Gane R wrote:
> I see a link to download the source
>
> http://download.osgeo.org/gdal/2.0.2/gdal202.zip
>
> when can I find a prebuilt version of GDAL 2.0.2
https://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.n
Hei Even,
Now I investigated a bit more and it seems that the development at our mapping
authority and gdal diverged a bit.
There is a (partly) newer version of the OGR-SOSI driver at the github
repository of our mapping authority:
https://github.com/OSGeo/gdal/compare/trunk...kartverket:trunk
Stefan,
>
> Now I investigated a bit more and it seems that the development at our
> mapping authority and gdal diverged a bit.
>
> There is a (partly) newer version of the OGR-SOSI driver at the github
> repository of our mapping authority:
> https://github.com/OSGeo/gdal/compare/trunk...kartve
Hi,
I noticed this question in gis.stackexchange
http://gis.stackexchange.com/questions/192547/generalization-algorithms and
the answer lead to this this "psimpl" library
http://psimpl.sourceforge.net/. The library is MPL 1.1 licensed. Is the
license suitable for GDAL and aculd we have any use for
On 6 May 2016 at 12:06, Jukka Rahkonen
wrote:
>
> I noticed this question in gis.stackexchange
> http://gis.stackexchange.com/questions/192547/generalization-algorithms and
> the answer lead to this this "psimpl" library
> http://psimpl.sourceforge.net/. The library is MPL 1.1 licensed. Is the
> l
Le vendredi 06 mai 2016 12:06:28, Jukka Rahkonen a écrit :
> Hi,
>
> I noticed this question in gis.stackexchange
> http://gis.stackexchange.com/questions/192547/generalization-algorithms and
> the answer lead to this this "psimpl" library
> http://psimpl.sourceforge.net/. The library is MPL 1.1 l
im building off trunk, so Gdal2.1dev
Ill get that stack trace...
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Segfault-in-GDALWriteBlock-tp5264660p5264899.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
g
NoDataValue is set on a band level and FillEmptyTiles operates at a dataset
level.
I've never heard of a geotiff with different nodata per band - is this even
possible, or would it be reasonable to take the nodatavalue of the 1st band
and use this to initialise the empty tiles block?
Then there
Le vendredi 06 mai 2016 13:33:36, jramm a écrit :
> NoDataValue is set on a band level and FillEmptyTiles operates at a dataset
> level.
>
> I've never heard of a geotiff with different nodata per band - is this even
> possible, or would it be reasonable to take the nodatavalue of the 1st band
> a
> - ECW SDK 5.2.1: available for VS2010, VS2012, VS2013
I got information that the next SDK 5.3 should support VS2012, 2013 and 2015
(so no more 2010) + GCC 5
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailin
On Fri, 06 May 2016 15:00:07 +0100, Even Rouault
wrote:
- ECW SDK 5.2.1: available for VS2010, VS2012, VS2013
I got information that the next SDK 5.3 should support VS2012, 2013 and
2015
(so no more 2010) + GCC 5
And one can also build SDK 3.3 with all of those compilers (I did).
_
On 6 May 2016 at 16:20, Joaquim Luis wrote:
> On Fri, 06 May 2016 15:00:07 +0100, Even Rouault
> wrote:
>
>>> - ECW SDK 5.2.1: available for VS2010, VS2012, VS2013
>>
>>
>> I got information that the next SDK 5.3 should support VS2012, 2013 and
>> 2015
>> (so no more 2010) + GCC 5
>
>
> And one c
On 2016-05-06 11:38 AM, Mateusz Loskot wrote:
On 6 May 2016 at 16:20, Joaquim Luis wrote:
On Fri, 06 May 2016 15:00:07 +0100, Even Rouault
wrote:
- ECW SDK 5.2.1: available for VS2010, VS2012, VS2013
I got information that the next SDK 5.3 should support VS2012, 2013 and
2015
(so no more
Hi all,
For future release notes, can we include the release date at the top of
the page? For example see:
https://trac.osgeo.org/gdal/wiki/Release/2.1.0-News
I just find it very useful, and a great way to look back at progress. (I
added the date for 2.1.0)
-jeff
--
Jeff McKenna
MapSer
On 2016-05-06 12:17 PM, Jeff McKenna wrote:
Hi all,
For future release notes, can we include the release date at the top of
the page? For example see:
https://trac.osgeo.org/gdal/wiki/Release/2.1.0-News
I just find it very useful, and a great way to look back at progress. (I
added the date for
Le vendredi 06 mai 2016 17:25:44, Jeff McKenna a écrit :
> On 2016-05-06 12:17 PM, Jeff McKenna wrote:
> > Hi all,
> >
> > For future release notes, can we include the release date at the top of
> > the page?
Sure.
Not sure if that should be the date returned by gdalinfo --version, or the day
Hi Even,
sorry for the late answer.
The latest version did a good job.
I am now investigating a strange issue after the gdaladdo run but I think
it is caused by my MBTiles reader library.
Thank you for your work so far.
Regards
Lorenzo Pini
Software Engineer
==
GeoServer Professional Services fr
I have nothing to add other than a well-maintained flexible licensed DWG
reader would be very welcomed by some.
On Thu, May 5, 2016 at 1:24 PM, Борзых Александр Андреевич <
191...@niuitmo.ru> wrote:
> Hello devs,
>
> I just have posted my GSoC project info at
> https://trac.osgeo.org/gdal/wiki/DW
I was not intending for C++11 to be a big part of the discussion as it is a
much more complicated topic, but I do appreciate the discussion. I picked
the stack + memset -> std::vector(nSize, initialValue) to do first because
I thought it was a simpler issue than most and we could use it to figure
There has been lively discussion on if/when GDAL moves to require compilers
with newer C and C++ standard versions. This email is meant to fork the
this discussion away from the local stack + memset -> std::vector
discussion. I'm trying to draft a proposal based on the discussion, but it
is a lot
http://www.keittlab.org/
On Fri, May 6, 2016 at 1:55 PM, Kurt Schwehr wrote:
> I was not intending for C++11 to be a big part of the discussion as it is
> a much more complicated topic, but I do appreciate the discussion. I
> picked the stack + memset -> std::vector(nSize, initialValue) to do f
For stack ranking, see the "alternatives" section of this (and I did not
include my preferred std::vector solution in the list):
https://docs.google.com/document/d/1Y9flzxj3Uz1vTEPCBmlswgi470m8i-oepGutVkbowfc/pub
BTW, Someone pointed out that I originally listed autoptr (which just won't
work) wh
On 6 May 2016 at 21:55, Kurt Schwehr wrote:
> My belief is that for this particular proposal, we should not have the
> C++11/14 discussion unless the best overall solution requires a newer
> version of C++. The solution I propose to be the best works in C++03 and
> newer.
Simply, the initial pro
On Fri, May 6, 2016 at 3:55 PM, Kurt Schwehr wrote:
> I was not intending for C++11 to be a big part of the discussion as it is
> a much more complicated topic, but I do appreciate the discussion. I
> picked the stack + memset -> std::vector(nSize, initialValue) to do first
> because I thought i
MS4W 3.1.4 is now available containing GDAL 2.1.0 at http://ms4w.com/
-jeff
On 2016-05-02 6:19 AM, Even Rouault wrote:
Hi,
On behalf of the GDAL/OGR development team and community, I am pleased to
announce the release of GDAL/OGR 2.1.0. GDAL/OGR is a C++ geospatial
data access library for r
25 matches
Mail list logo
