Chaitanya,
Same result with 1.8.0
With some effort we can test with 1.9, as we have not found any
OGDI-compiled OGR for 1.9
Then also I assume we can insert debug-flags to maybe get more
information. We have experimented with the Java bindings (jar) as we
will integrate OGR with a Java servlet
In GDAL 1.9.0 and Python 2.7.2,
feature.SetField(0, u'xxx')
raises the following exception
NotImplementedError: Wrong number of arguments for overloaded
function 'Feature_SetField'.
Possible C/C++ prototypes are:
SetField(OGRFeatureShadow *,int,char const *)
SetField(
As far as I know none of the drivers install their dependent DLLs. But I could
be wrong.
Glad you are up and running.
-Original Message-
From: Gavin Fleming [mailto:ga...@afrispatial.co.za]
Sent: mardi 10 avril 2012 16:09
To: Kirk McKelvey
Cc: gdal-dev
Subject: Re: [gdal-dev] MrSID won
Thanks Kirk, that did the trick
On 10/04/2012 18:06, Kirk McKelvey wrote:
The undefined references you are seeing with MrSID SDK v7 should not be getting
compiled for v7, e.g.:
#if defined(LTI_SDK_MAJOR)&& LTI_SDK_MAJOR>= 8
lt_uint8 gen;
bool raster;
LT_STATUS eStat =
That was my first suggestion to the guy who call me about that problem. He
tried and then he sent me the file and I tried and that did not work. I was
really surprised.
> ---Original Message---
> From: Etienne Tourigny
> To: Ivan Lucena
> Cc: gdal-dev@lists.osgeo.org
> Subject: R
I suspect you get "expected" results if you force the crs like this:
gdal_translate -a_srs EPSG:26943 in.tif out.tif
gdalinfo out.tif
On Tue, Apr 10, 2012 at 5:41 PM, Ivan Lucena wrote:
> Hi Etienne,
>
> OK, let's keep the focus on 1.9. I did what you said:
>
>> Can you try using 'gdalsrsinfo E
Hi Frank,
Yes, we can say that there is nothing wrong with the WKT, but the EPSG notation
is quite important for me and that is missing. And yes, we could say that
there is probably something wrong with the GTIFF driver. But - Don't let
Ethiene knows that I did again ;) - I ran the 1.9 gdalinf
On Tue, Apr 10, 2012 at 1:41 PM, Ivan Lucena wrote:
> It seems to me that the GTIFF driver tries to interprets the WKT instead of
> just pass it on. Is that right? It doesn't seems to be doing it right.
Ivan,
When the GeoTIFF file contains parameters in addition to the PCS code,
it is likely th
Hi Etienne,
OK, let's keep the focus on 1.9. I did what you said:
> Can you try using 'gdalsrsinfo EPSG:26943' with gdal 1.9 and
> associated data dir?
And I got the same result from gdalsrsinfo as you did (using only 1.9) but I
still getting a different result from gdalinfo with a image that
Ivan,
I don't see any *errors* in the new results. The order of the
standard parallels is arbitrary. But it is odd how different the
PCS name is and that the EPSG authority code is not preserved.
I will note that gdalsrsinfo against 1.9 for EPSG:26943 reports:
... Ah Etienne already beat me to
Your email is slightly contradictory, you say you use data from 1.8 in
both tests.
you definitely should not be mixing gdal version with associated data.
You chould be getting correct results when not mixing them, is that
the case?
Can you try using 'gdalsrsinfo EPSG:26943' with gdal 1.9 and
asso
Hi There,
I am getting some weird results from a simple geotiff file and it seems to be a
problem with the data folder.
If I run gdalinfo using GDAL 1.9 or 1.8 with the data folder installed from 1.8
the WKT comes with no EPSG Authority code:
D:\> set GDAL_DATA=D:\GDAL-1.9\data
D:\> gdalinfo s
Gavin,
I was confused by the formatting of your output snippet. It looks to me like
your MrSID SDK v8 build succeeded, however the "make install" does not actually
install the mrsid library. Should just be a matter of copying libltidsdk.so
into your gdal/lib directory and you are good to go.
The undefined references you are seeing with MrSID SDK v7 should not be getting
compiled for v7, e.g.:
#if defined(LTI_SDK_MAJOR) && LTI_SDK_MAJOR >= 8
lt_uint8 gen;
bool raster;
LT_STATUS eStat =
MrSIDImageReaderInterface::getMrSIDGeneration(poOpenInfo->pabyHeader,
gen, rast
On 10-04-2012 13:14, Robert Zermeno wrote:
Ladies and Gents,
I have yet to properly configure GDAL to compile with a repository
OpenJpeg V2, but I wanted to see how GDAL uses openjpeg tile request.
I created my own project and modified IReadBlock() to be standalone to
view a tile request.
Selon Chaitanya kumar CH :
> Andreas,
>
> Could you first test your data with the latest version of GDAL? The latest
> Windows binaries can be obtained through the OSGeo4W installer.
>
> In any case, I couldn't find any reference to DNC in the OGDI library,
> which is used by OGR to read VPF files
Andreas,
Could you first test your data with the latest version of GDAL? The latest
Windows binaries can be obtained through the OSGeo4W installer.
In any case, I couldn't find any reference to DNC in the OGDI library,
which is used by OGR to read VPF files.
On Tue, Apr 10, 2012 at 5:22 PM, Andr
Even Rouault mines-paris.org> writes:
> Hum, would be interesting to have a sample to examine one of the
geometry that
> triggers the error. The SRID hypothesis seems unlikely, and as far
as the
> geometry type is concerned, it is weird because you have specified -nlt
> MULTIPOLYGON ...
>
>
> I am using a sample data file provided by openjpeg data folder named
> p1_04.j2k. How is the data retrieved from opj_decode_tile_data() is being
> stored in the buffer? To access pixel 0, is it just buffer[0] or is there
> another way?
> For some reason, my request for Tile (0,0) of length 12
Ladies and Gents,
I have yet to properly configure GDAL to compile with a repository OpenJpeg V2,
but I wanted to see how GDAL uses openjpeg tile request. I created my own
project and modified IReadBlock() to be standalone to view a tile request.
I am using a sample data file provided by openj
I cannot make OGR work with VPF DNC data.
ogrinfo and ogr2ogr crashes when trying to read data from any level
inside the VPF structure. DHT and LAT files do exist.
OGR does work for standard VMAP0 and VMAP1 data.
Is this a known limitation?
Does DNC require some special syntax?
I have used e.g.
On 03/04/2012 23:22, Frank Warmerdam wrote:
Could you search for "XTIFFClientOpen" in config.log after the
configure failure? Often there details in there on why the probe
failed
root@study:/tmp/libgdal-mrsid-build.1b1ICV/libgdal-mrsid-1.9.0# grep
XTIFF config.log
configure:3490: checking fo
This worked on one Ubuntu 11.10 box but not on another (where I really
need it to work). I'd be grateful for any help:
--with MrSID SDK 7:
./configure --with-geotiff=internal
--with-mrsid=/usr/local/Geo_DSDK-7.0.0.2167 --with-threads --with-python
/bin/bash /home/gavin/src/gdal/libtool --mod
Noura,
First, note that osm tiles are presented in EPSG:900913 reference system.
The usual way of requesting the tiles is based on the extent coordinates.
GDAL's WMS driver[1] can be used to access it. For that you need an XML
file[2] specifying the service.
Once you obtain the coordinates like
DTED files are really simple to undertand. A DTED CD-ROM is organized like
this :
- *dted (folder)*
- *D### (folder)*
- H##.dt# (file)
- H##.dt# (file)
- ...*
*
- *D### (folder)*
- *...
*
- *gazette (folder)
*
- *text (folder)
25 matches
Mail list logo
