On 7 September 2017 at 01:01, Joaquim Luis wrote:
> On Wed, 06 Sep 2017 21:22:18 +0100, Mateusz Loskot wrote:
>> On 6 September 2017 at 21:53, Kurt Schwehr wrote:
>>>
>>> I was just about to write something along the lines that follow, but
Hey Norman,
Interesting idea. I think it will be a little bit tricky because it is hard to
uniquely label each band in a grib file.
I actually use a modified version of gdal_translate where I can specify the
GRIB_ELEMENT, GRIB_SHORTNAME, and GRIB_FORECAST seconds that I want to match to
On Wed, 06 Sep 2017 21:22:18 +0100, Mateusz Loskot
wrote:
On 6 September 2017 at 21:53, Kurt Schwehr wrote:
I was just about to write something along the lines that follow, but
Mateusz
looks to have more of an understanding.
My best guess was that
FYI in QGIS dev world we still not have found a clear and complete way
to migrate tracker from redmine to GH or GitLab.
More info and details can be asked to the key people that investigated
the problem... just asking in Dev list.
FYI we are still in a new updated redmine :/
Luigi Pirelli
On 6 September 2017 at 21:53, Kurt Schwehr wrote:
> I was just about to write something along the lines that follow, but Mateusz
> looks to have more of an understanding.
>
> My best guess was that it is an incomplete install of Windows? e.g.
>
>
I was just about to write something along the lines that follow, but
Mateusz looks to have more of an understanding.
My best guess was that it is an incomplete install of Windows? e.g.
https://support.microsoft.com/en-us/help/2999226/update-for-universal-c-runtime-in-windows
I haven't done
On 6 September 2017 at 21:21, Joaquim Luis wrote:
> Kurt,
>
> The Tamas SDKs are not enough as to provide all the dependencies to a GDAL
> Win installation. It miss all those dlls (didn't check if the list is
> complete) that the VS2015/17 builds now depend on. So if one wants to
>
I would also prefer to go for #3 if possible, though I don't have enough
experience how to make it happen.
Best regards,
Tamas
2017-09-06 15:14 GMT+02:00 Even Rouault :
> Hi,
>
>
>
> I've heard a few voices speaking/asking/begging for a git/github
> migration. At
Joaquim,
Please give it another go at explaining what this use case is and the
issues with it. I didn't follow your comments about the need for VS2013.
If users are on a legacy compiler (w.r.t. to C++11), can they not be served
by the 2.2 branch? How does that use case fair with the impending
On mercredi 6 septembre 2017 21:16:46 CEST Dmitry Baryshnikov wrote:
> Hi Even,
>
> I think this is great proposal. Github is modern tool for develop, code
> review and test software.
>
> I like idea to migrate code and tickets (3). Not sure we need to migrate
> closed tickets.
I'd wish closed
On 6 September 2017 at 15:14, Even Rouault wrote:
> Hi,
>
> I've heard a few voices speaking/asking/begging for a git/github migration.
> At some point we'll certainly have to do it, as SVN vs git is beginning to
> feel more and more like CVS vs SVN 15 years ago.
>
> I
On 6 September 2017 at 20:18, Joaquim Luis wrote:
> On Wed, 06 Sep 2017 18:34:06 +0100, Mateusz Loskot wrote:
>> On 6 September 2017 at 19:14, Joaquim Luis wrote:
>>>
>>> Wait, does this means that VS2013 will no longer be supported?
>>
>> With
Hi,
I'm not a PSC member, but like to note the great work Kurt has done on
C++11 compilation mode.
I strongly support this RFC.
Best regards,
Dmitry
06.09.17 19:14, Kurt Schwehr пишет:
Now that Tamas has added the msvc2015/2-17SDK's, I'd like to call a vote by
the PSC on RFC68: C++11
On 6 September 2017 at 19:14, Joaquim Luis wrote:
> Wait, does this means that VS2013 will no longer be supported?
With respect, Kurt has been asking for comments for very long time.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
On 6 September 2017 at 19:11, Even Rouault wrote:
> On mercredi 6 septembre 2017 19:04:34 CEST Mateusz Loskot wrote:
>> On 6 September 2017 at 18:58, Andrew Bell wrote:
>> > On Wed, Sep 6, 2017 at 12:14 PM, Kurt Schwehr
Wait, does this means that VS2013 will no longer be supported?
That's awful because I'll have to rebuild all my dependencies and honestly
do not understand what compiler dlls must be distributed with the code
(with VS2013 I only has to ship in 2 dlls) and the last thing I want is to
force
On mercredi 6 septembre 2017 19:04:34 CEST Mateusz Loskot wrote:
> On 6 September 2017 at 18:58, Andrew Bell wrote:
> > On Wed, Sep 6, 2017 at 12:14 PM, Kurt Schwehr wrote:
> >> Now that Tamas has added the msvc2015/2-17SDK's, I'd like to call a vote
On 6 September 2017 at 18:58, Andrew Bell wrote:
> On Wed, Sep 6, 2017 at 12:14 PM, Kurt Schwehr wrote:
>>
>> Now that Tamas has added the msvc2015/2-17SDK's, I'd like to call a vote
>> by the PSC on RFC68: C++11 compilation mode.
>>
>> The draft is
On Wed, Sep 6, 2017 at 12:14 PM, Kurt Schwehr wrote:
> Now that Tamas has added the msvc2015/2-17SDK's, I'd like to call a vote
> by the PSC on RFC68: C++11 compilation mode.
>
> The draft is here:
>
> https://trac.osgeo.org/gdal/wiki/rfc68_cplusplus11
>
I'm late to the
On mercredi 6 septembre 2017 09:14:10 CEST Kurt Schwehr wrote:
> Now that Tamas has added the msvc2015/2-17SDK's, I'd like to call a vote by
> the PSC on RFC68: C++11 compilation mode.
>
> The draft is here:
>
> https://trac.osgeo.org/gdal/wiki/rfc68_cplusplus11
+1
Just a comment regarding
Now that Tamas has added the msvc2015/2-17SDK's, I'd like to call a vote by
the PSC on RFC68: C++11 compilation mode.
The draft is here:
https://trac.osgeo.org/gdal/wiki/rfc68_cplusplus11
-Kurt
>
> > Hi Even,
>
> >
>
> > The new SDK-s have now been added.
>
> >
>
> > Best regards,
>
> >
>
>
Hi,
I am currently working on representing a grib file as a netCDF file within
GDAL. My plan is that if a user specifies the netCDF driver and opens a
grib file then the metadata from the grib will be represented as a netCDF
and the data can be read through that driver.
It may seem a bit odd
Hi,
I've heard a few voices speaking/asking/begging for a git/github migration. At
some point
we'll certainly have to do it, as SVN vs git is beginning to feel more and more
like CVS vs SVN
15 years ago.
I can see different options :
1) migrate to git, and remain within the OSGeo
Hi,
I'm considering preparing a 2.2.2 release candidate for end of next
week. Speak if you need more time to push a fix in it. Or if there are
bugs that aren't yet fixed in the branch and ought to (no promise
here)
Even
--
Spatialys - Geospatial professional services
On mardi 5 septembre 2017 20:21:17 CEST Matthew Amato wrote:
> Thanks for the detailed write up and quick fix!
>
> Just to clarify your last sentence, are you saying there are still
> potential cases where IsSame returns TRUE when it shouldn't?
Hopefully not.
> I'm just wondering if I should
Am 05.09.2017 um 20:50 schrieb Even Rouault:
Apparently
they also offer the datasets in WGS 84, so you can perhaps check which
hypothesis is right
from that.
Both datasets align with the Custom CRS including 3-parms datum shift I
included earlier in this thread.
Greetings,
André Joost
26 matches
Mail list logo