when required). I could even propose a simple PR about that, if it would help.
Thanks
The long story is here: https://github.com/ajolma/Geo-GDAL-FFI/issues/53
--
Francesco P. Lovergine
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https
://upstream-tracker.org/versions/gdal.html
and specifically
http://upstream-tracker.org/compat_reports/gdal/1.9.2_to_1.10.0beta1/abi_compat_report.html
That would prospectively useful for ABI/API maitainance at distribution level
(soname settings, etc.)
--
Francesco P. Lovergine
seen as a license violation (point 2 of the license). At least it seems a
bit strange assuming a datum when no datum is specified on purpose as in many
codes.
Of course IMHO and IANAL.
--
Francesco P. Lovergine
___
gdal-dev mailing list
gdal-dev
,
there's still the possibility of non-packaged ones depending on that...
--
Francesco P. Lovergine
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
(upstream) solution.
This is exactly what I'm going to provide in 1.8/experimental for next
library transition.
--
Francesco P. Lovergine
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
much for considering this !
Note that it will sacrify binary compatibility against casual builds.
You will need to build against the Debian version of GDAL, not third
parties builds.
--
Francesco P. Lovergine
___
gdal-dev mailing list
gdal-dev
!
--
Francesco P. Lovergine
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
functionnal to a
minimum extent...
With some minor changes, introduced ages ago (trac entries pending), at least
on the Debian side.
--
Francesco P. Lovergine
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal
. And the
cpl_vsil_gzip.cpp code could certainly be adapted to work with classic or
zip64 symbols according to what is available.
--
Francesco P. Lovergine
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
inner problems of the same library. Note that
the geotiff internal gdal library has been used since 1.6.0 in debian, the old
one used the same
library you are now linking with the default configuration. So the objection
seems pointless.
--
Francesco P. Lovergine
an official bigtiff
merging in libtiff? It seems a forever pending feature currently...
--
Francesco P. Lovergine
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
://geod.nrcan.gc.ca/pub/GSD/craymer/pubs/nad83_hydroscan2006.pdf
ftp://geod.nrcan.gc.ca/pub/GSD/craymer/pubs/nad83_geomatica2006.pdf
for reference. Maybe someone more expert on the proj list could be more
precise about that.
--
Francesco P. Lovergine
___
gdal
in the nmake.opt I get unresolved
link errors the interesting thing is that the errors are not just for HDF5.
I do have SDE enabled and GRIB is enabled by default. I don’t know that the
first unresolved is but all of the error go away if I take HDF5 out of the
build.
--
Francesco P
On Fri, May 22, 2009 at 12:59:49PM +0200, Francesco P. Lovergine wrote:
On Fri, May 22, 2009 at 11:54:01AM +0200, Agustin Lobo wrote:
Apparently, there is no problem for including ECW support
in gdal binaries ?
http://n2.nabble.com/Tickets-2385-and-2683-(ECW-and-MrSID-plugins)-tt2767156
) in
the default configuration mechanism, but using a completely different
compilation line would be quite undesired.
Feel free to open up a ticket in this topic, I hope someone will be able to
take care of it (patches are welcomed).
--
Francesco P. Lovergine
15 matches
Mail list logo
