You have also the Julia wrapper that needs no ffi lib to do the bindings
https://github.com/visr/GDAL.jl
From: gdal-dev [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Ari Jolma
Sent: Thursday, December 21, 2017 1:03 AM
To: Sean Gillies ; Kurt Schwehr
Cc: gdal dev
Subject: Re: [gdal-dev]
Sean Gillies kirjoitti 21.12.2017 klo 11:48:
Ari,
This sounds great. I don't use Perl as much as I used to – unless you
count GNU Parallel, which I use about 320 hours a day – but I'll
follow your progress.
It seems to me that the idea of a common API across different
scripting languages is
Ari,
This sounds great. I don't use Perl as much as I used to – unless you count
GNU Parallel, which I use about 320 hours a day – but I'll follow your
progress.
It seems to me that the idea of a common API across different scripting
languages isn't attractive to programmers like it once was. R a
Cool! Should be useful for other languages to see what is possible with
libffi
On Dec 20, 2017 3:23 PM, "Ari Jolma" wrote:
Folks,
I've been experimenting with the Perl module FFI::Platypus, to create a
Perl interface to GDAL with its help(1) and it's progressing well.
FFI::Platypus itself uses
Folks,
I've been experimenting with the Perl module FFI::Platypus, to create a
Perl interface to GDAL with its help(1) and it's progressing well.
FFI::Platypus itself uses libffi, which is a portable interface library.
That, and Alien::gdal, which is a Perl module to use GDAL in a system
that
Dmitry Baryshnikov kirjoitti 21.12.2017 klo 08:58:
Hi Ari,
The pull request and discussion can be found here:
https://github.com/OSGeo/gdal/pull/280
Yes. Sorry. I didn't see that. Maybe Kurt also didn't see that - or the
aspect of it that he brought up here. Maybe a place for some
instit
On jeudi 21 décembre 2017 00:58:53 CET Dmitry Baryshnikov wrote:
> Hi Ari,
>
> The pull request and discussion can be found here:
> https://github.com/OSGeo/gdal/pull/280
>
> I cannot imagine that this improvements will affect something else. MD5
> used for cache paths initially, I only added som
Hi Ari,
The pull request and discussion can be found here:
https://github.com/OSGeo/gdal/pull/280
I cannot imagine that this improvements will affect something else. MD5
used for cache paths initially, I only added some improvements for WMS
cache size limits, expire time and split cache per
My comments on this:
1) The MD5 function seems to be needed only(?) for the WMS cache and
probably also WFS. To me that highlights the need for some integration
work regarding caching in GDAL. I also implemented yet another caching
code for the WCS (without MD5). Looking at my $HOME/.gdal I se
Mike,
I could replicate. The issue is not in GDAL, but in the underlying ogdi
library.
Ubuntu 16.04 ships with ogdi 3.2.0-beta2. With final ogdi 3.2.0 (available in
Ubuntu zesty), the crash no longer occurs.
Compiling ogdi from source for modern distributions is a bit of a pain. You
could pro
Dmitry,
Statements like this indicate a world of trouble:
> I'm not sure that Python produce the same hash than cvs_MD5*.
> Also I'm not sure what in future they will be the same.
If you remove the swig and python stuff, move the CPLMD5String to
cpl_md5.{cpp,h}, and follow Even's suggestions, I
So using Ubuntu 16.04, and Ubuntu gis-unstable ppa, which has gdal 2.2.2.
Sample data
https://dnc.nga.mil/DNC/library.php?c=C12
Direct link
https://dnc.nga.mil/DNCSiteContent/StaticFiles/data12/vpf/coa12f.zip
I can do an ogrinfo gltp:/vrf/path/DNC12/COA12F
and get all the layers. I can pick a
Just the note that CPLMD5String not only for Python, but any other API
clients: C/C++, Java, Perl, etc.
But, I agree, it can be easily removed.
Best regards,
Dmitry
20.12.2017 18:35, Even Rouault пишет:
And why are you exposing this to python? Python has md5 hashing
already
built in.
Just the note that CPLMD5String not only for Python, but any other API
clients: C/C++, Java, Perl, etc.
But, I agree, it can be easily removed.
Best regards,
Dmitry
20.12.2017 18:35, Even Rouault пишет:
And why are you exposing this to python? Python has md5 hashing
already
built in.
> > And why are you exposing this to python? Python has md5 hashing
already
> > built in.
>
> I'm not sure that Python produce the same hash than cvs_MD5*.
I do hope they return the same thing. MD5 is a standardized algorithm:
https://tools.ietf.org/html/rfc1321
I'm not sure we really need to
Will answer in letter body
20.12.2017 17:39, Kurt Schwehr пишет:
My personal opinion...
It was not in fact in the core of GDAL for all users. My primary
environment does not include the WMS *driver*. My take is that only the
memory and gtiff raster drivers are really required for GDAL (vector
On mercredi 20 décembre 2017 06:39:37 CET Kurt Schwehr wrote:
> My personal opinion...
>
> It was not in fact in the core of GDAL for all users. My primary
> environment does not include the WMS *driver*. My take is that only the
> memory and gtiff raster drivers are really required for GDAL (ve
On 2017-12-20 9:41 AM, Jeff McKenna wrote:
https://trac.osgeo.org/gdal/wiki/SupportedCompilers
Thanks for this page Kurt. Can you also make sure that it is linked to
from the main wiki opening page? (so people can find it)
https://trac.osgeo.org/gdal/wiki Thanks,
ah I found it on Bu
I'm hesitant to link that page in the main page. It's not particularly
complete and this was the first update in years.
On Wed, Dec 20, 2017 at 6:41 AM, Jeff McKenna wrote:
> On 2017-12-19 7:01 PM, Kurt Schwehr wrote:
>
>>
>> I just took a pass at updating the supported compiler list. Please a
On 2017-12-19 7:01 PM, Kurt Schwehr wrote:
I just took a pass at updating the supported compiler list. Please add
more tested configs. I mostly just wanted to get statements about
supporting old platforms out of there.
https://trac.osgeo.org/gdal/wiki/SupportedCompilers
Thanks for this
My personal opinion...
It was not in fact in the core of GDAL for all users. My primary
environment does not include the WMS *driver*. My take is that only the
memory and gtiff raster drivers are really required for GDAL (vector, I'm
not so sure).
What do you mean by the same or similar for gen
In fact it was part of core of GDAL but hidden in WMS driver folder. The
same or similar is in:
1. ogr/ogrsf_frmts/generic
2. ogr/ogrsf_frmts/geojson
What solution can be suitable here (I mean md5 case)?
Best regards,
Dmitry
20.12.2017 17:19, Kurt Schwehr пишет:
I have not looked in th
I have not looked in the wms code much, but my comment was not about adding
an external dependency. It is about code quality in the core of GDAL.
On Dec 20, 2017 6:07 AM, "Dmitry Baryshnikov" wrote:
> Hi Kurt.
>
> The md5.cpp and md5.h were in frmst/wms driver folder. As I see from
> header this
Hi Kurt.
The md5.cpp and md5.h were in frmst/wms driver folder. As I see from
header this files are not initially from GDAL project.
I moved this files to port with minimum changes - only macros for
suppress Doxygen parsing.
The motivation of this moving was:
1. md5 functions used in sever
Hi all,
Can we discuss cvs_MD5* from https://trac.osgeo.org/gdal/changeset/41086 ?
I very much appreciate the work that bishop is doing and I hate to slow
down a contributor
I am really worried about code like this going into GDAL, especially into
port/
But my worries are:
- this in no way con
Even,
that was really helpful. Finally, I solved it without any need to modify
GDAL.
I do the mmap() myself in my application. Then I create VSILFILE out of the
mmapped block by VSIFileFromMemBuffer().
I can then GDALOpen() the /vsimem/ file and fork freely.
The GTIFF_USE_MMAP is a cherry on th
26 matches
Mail list logo
