A good point. I considered using SWIG to generate the bindings, it
looks like the support is pretty good, but I decided to "roll my own"
for now for a couple of reasons. I thought it would be a good way to
learn by getting my hands dirty with some of the lower-level nuts and
bolts of Go, and it wo
Hi Frank,
Thanks for the amazingly quick response!
You can access the files at:
https://www.dropbox.com/sh/f326gvclu5f1qjm/GNvp2mZLbU
I was waiting to send this response until the files had finished
uploading (280Mb in total), but I have to pop out for a few hours and
they have not yet finished.
Built OK on CentOS 6.3
and not experiencing the issue of
GDAL / Java bindings : undefined symbol:
_ZTVN10__cxxabiv120__si_class_type_infoE in libgdal.so.1 which I previously
encountered when building gdal trunk
(For more details, refer
http://www.mail-archive.com/gdal-dev@lists.osgeo.org/msg163
On Wed, Oct 3, 2012 at 5:06 PM, Simon Knapp wrote:
> Hi List,
>
> This is my first post here so please let me know if my question would
> be better placed elsewhere.
Simon,
This is a good place for the question.
> I am struggling with re-projecting integer
> grids using gdalwarp and would appre
Hi List,
This is my first post here so please let me know if my question would
be better placed elsewhere. I am struggling with re-projecting integer
grids using gdalwarp and would appreciate some help.
I have two grids containing land use data at different scales:
grid 1) a 50m (esri binary) gr
Le mercredi 03 octobre 2012 20:46:10, Luke Roth a écrit :
> For any who are interested, I've published a (incomplete, but growing)
> set of GDAL bindings for the Go language at
> https://github.com/lukeroth/gdal.go .
> The bindings cover most of the GDAL C API, the OGR C API is next.
> More details
> The proper
> solution would be to fix CPLOpenShared() to be more thread-friendly (that
> is to say to return different file handles if called with the same
> filename from different threads)
>
Should be fixed by ticket http://trac.osgeo.org/gdal/ticket/4848 that should go
into GDAL 1.9.2RC2. I
Hi Even,
thanks for your quick reply and explanation. I would kindly ask you for more
help, since I'm just trying to adapt this code quickly while still learning
all those concepts...
If I understood you well, those are changes:
hDstDS = GDALCreate(driver, output.c_str(), resX, resY,
On Wed, Oct 3, 2012 at 12:56 PM, Even Rouault
wrote:
> According to HOWTO-RELEASE, I believe that GDALmake.opt.in should have been
> bumped to LIBGDAL_REVISION:= 2 since GDAL 1.9.1 has
> LIBGDAL_REVISION = 1
Doh! I just realized I made that change in GDALmake.opt, instead of
GDALmak
Le mercredi 03 octobre 2012 19:34:03, Frank Warmerdam a écrit :
> Folks,
>
> I have prepared a GDAL/OGR 1.9.2 release candidate. I'd appreciate people
> looking it over. I didn't do any swig or configure regeneration - I'm
> not sure if
> that is needed or exactly sure where to do it to avoid ch
On 12-10-03 1:55 PM, Ari Jolma wrote:
On 10/03/2012 08:34 PM, Frank Warmerdam wrote:
http://download.osgeo.org/gdal/gdal192RC1.zip
http://download.osgeo.org/gdal/gdal-1.9.2RC1.tar.gz
I'll call for a vote promoting it to final if I don't hear of any
serious problems
today.
Looks (config
Hi Even,
thanks for your quick reply and explanation. I would kindly ask you for more
help, since I'm just trying to adapt this code quickly while still learning
all those concepts...
If I understood you well, those are changes:
hDstDS = GDALCreate(driver, output.c_str(), resX, resY,
Hi!
I thought it might be appropriate to share the openEV info to the gdal list
as well since a lot of why openEV was successful was because of solid
foundation tools like gdal.
UPDATE
I have been shown a couple of new developments using openEV that I plan to
reintegrate into the old
Le mercredi 03 octobre 2012 21:24:06, Frank Warmerdam a écrit :
> Xavier,
>
> Even has back ported some WFS fixes. I'm not clear if the recent work
> was considered a new feature and thus not appropriate to back port, he
> just omitted it or if he hadn't gotten to back porting yet.
>
> I'm hesit
Xavier,
Even has back ported some WFS fixes. I'm not clear if the recent work
was considered a new feature and thus not appropriate to back port, he
just omitted it or if he hadn't gotten to back porting yet.
I'm hesitant to just drop the whole current development version of the
WFS driver into
David,
This is intended to be a bug fix release, and we don't by default back
port new developments unless the value is high and the risk is very
low. If you want it to go out in future point releases you would need
to add it in the branches/1.9 tree.
Peeking at the ARG driver I notice it refere
Hi
I'm not familiar with the revision process. I just checked this release
candidate but it does not take into accounts the latest version of the WFS
driver which has corrected this summer by Even (Escaping function).
I've patched my 1.9.1 with the latest revision of the WFS driver and it
works
Le mercredi 03 octobre 2012 21:03:27, mighty_duck a écrit :
> Hi all,
>
> I have the following code:
>
> bool grImageWarper::createDstRaster(const std::string &output,
> GDALDatasetH hSrcDS,
> GDALDatasetH &hDstDS,
>
Hello Frank,
Is it possible to get the ARG drivers into 1.9.2? I had performed the work
on trunk, assuming it would get pulled into the next release. Is there
something I missed?
Thanks,
David
On Wed, Oct 3, 2012 at 1:55 PM, Ari Jolma wrote:
> On 10/03/2012 08:34 PM, Frank Warmerdam wrote:
>
>
Hi all,
I have the following code:
bool grImageWarper::createDstRaster(const std::string &output,
GDALDatasetH hSrcDS,
GDALDatasetH &hDstDS,
int resX,
i
For any who are interested, I've published a (incomplete, but growing)
set of GDAL bindings for the Go language at
https://github.com/lukeroth/gdal.go .
The bindings cover most of the GDAL C API, the OGR C API is next.
More details are available at the Github page. Let me know if you
find them use
That solved the problem! Thanks!
Any chance this can be done automatically for later releases?
Jack.
--
mathuin at gmail dot com
On Wed, Oct 3, 2012 at 11:26 AM, Even Rouault
wrote:
> Le mercredi 03 octobre 2012 20:23:35, John Twilley a écrit :
>> I an running Windows 7 64-bit and have downlo
Le mercredi 03 octobre 2012 20:23:35, John Twilley a écrit :
> I an running Windows 7 64-bit and have downloaded and installed the
> following software:
>
> * Python 2.7.3 for x64 from http://www.python.org/getit
> * GDAL 1.9 core and bindings for amd64 and py2.7 from
> http://www.gisinternals.c
I an running Windows 7 64-bit and have downloaded and installed the
following software:
* Python 2.7.3 for x64 from http://www.python.org/getit
* GDAL 1.9 core and bindings for amd64 and py2.7 from
http://www.gisinternals.com/sdk
* various modules including PyWin32 from
http://www.lfd.uci.edu/~
On 10/03/2012 08:34 PM, Frank Warmerdam wrote:
Folks,
I have prepared a GDAL/OGR 1.9.2 release candidate. I'd appreciate people
looking it over. I didn't do any swig or configure regeneration - I'm
not sure if
that is needed or exactly sure where to do it to avoid churn.
http://download.os
Folks,
I have prepared a GDAL/OGR 1.9.2 release candidate. I'd appreciate people
looking it over. I didn't do any swig or configure regeneration - I'm
not sure if
that is needed or exactly sure where to do it to avoid churn.
http://download.osgeo.org/gdal/gdal192RC1.zip
http://download.osge
Selon netcadturgay :
> I use Gdal 1.9 library including ERDAS R-W SDK 4.2 and when I try to write
> projection to ECW file(SetProjection) in update mode, some projections can
> written successfully. But some projections cannot written(cannot update to
> the file). Any solution about this problem?
Hi
> The file I am having problems with is a VRT file that references a raw file
> using VRTRawRasterBand.
>
> I have used gdal_translate to convert it to a TIFF and that does not have
> problems.
>
> Is it possible the VRT driver is not thread safe?
On closer review, it appears that VRTRawRaster
I use Gdal 1.9 library including ERDAS R-W SDK 4.2 and when I try to write
projection to ECW file(SetProjection) in update mode, some projections can
written successfully. But some projections cannot written(cannot update to
the file). Any solution about this problem?
Also when I try to set same p
Respected Sir,
Thank you for your reply,
As u said i have configured using gdal --with-rename-internal-
libtiff-symbols and --with-rename-internal-libgeotiff-symbols
When operating on .tif image i get same error again
*** glibc detected *** ./Multispectral: malloc(): memory corruption:
0x09edecf0
30 matches
Mail list logo
