Il 19/05/2015 18:13, Even Rouault ha scritto:
> Well, you could cheat a bit by generating inverted VRT for one of the two
> categories with :
Merci Even.
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
__
Hi,
I used GDAL to reproject the TM images, and the original projection of the TM
images was longitude/latitude WGS84, the final projection was UTM 51. The codes
I used is as following:
void doCore()
{
GDALDataType eDT;
GDALDataset *hDstDS;
GDALDataset *hSrcDS;
GDALAllRegister();
// c
Claire,
About a year ago I had a similar issue reading NAIP imagery. I was able to use
Global Mapper to convert the images. After that MapServer using GDAL could
serve the images correctly. I don't know if that will help you, but it worked
for me. Converting 4.3 TB of imagery took a while..
Hello,
I use the OpenJPEG 2.0 driver to decode the JP2 images within NITF files
(1B level NITF images from DigitalGlobe). For 4 band images, the driver
interprets the 4th band as Alpha. When I warp the imagery using gdalwarp,
the 4th band in the output is all zeros. If I convert the image using
Le mardi 19 mai 2015 16:48:20, Paolo Cavallini a écrit :
> Hi all.
> I have several images, appearing correctly in BW, but with different
> color tables:
>
> Color Table (RGB with 2 entries)
> 0: 255,255,255,255
> 1: 0,0,0,255
>
> Color Table (RGB with 2 entries)
> 0: 0,0,0,255
>
Hi all.
I have several images, appearing correctly in BW, but with different
color tables:
Color Table (RGB with 2 entries)
0: 255,255,255,255
1: 0,0,0,255
Color Table (RGB with 2 entries)
0: 0,0,0,255
1: 255,255,255,255
When building a virtual raster, obviously they appear r
Le mardi 19 mai 2015 16:31:52, Jukka Rahkonen a écrit :
> Even Rouault spatialys.com> writes:
> > I'm wondering if it might not make more sense to modify the input
>
> driver(s) to
>
> > not report out-of-range nodata values ? I fail to see a reason to report
> > an out-of-range nodata value.
>
Even Rouault spatialys.com> writes:
>
> I'm wondering if it might not make more sense to modify the input
driver(s) to
> not report out-of-range nodata values ? I fail to see a reason to report an
> out-of-range nodata value.
I wonder what happens for the nodata value if we convert images wi
Le mardi 19 mai 2015 16:16:05, Ivan Lucena a écrit :
> > From: even.roua...@spatialys.com
> > To: gdal-dev@lists.osgeo.org
> > Subject: Re: [gdal-dev] RFC 58: Removing Dataset Nodata Value
> > Date: Tue, 19 May 2015 16:10:38 +0200
> > CC: lucena_i...@hotmail.com; jukka.rahko...@maanmittauslaitos.fi
> From: even.roua...@spatialys.com
> To: gdal-dev@lists.osgeo.org
> Subject: Re: [gdal-dev] RFC 58: Removing Dataset Nodata Value
> Date: Tue, 19 May 2015 16:10:38 +0200
> CC: lucena_i...@hotmail.com; jukka.rahko...@maanmittauslaitos.fi
>
> Le mardi 19 mai 2015 16:06:59, Ivan Lucena a écrit :
>
Le mardi 19 mai 2015 16:06:59, Ivan Lucena a écrit :
> Jukka/Even,
>
> Yes, you guy are right. The "-a_nodata none" will help but I still need to
> implement a value range check on my CreateCopy anyway. So users don't need
> to run gdal_translate again after they find the problem or use "-a_nodat
Jukka/Even,
Yes, you guy are right. The "-a_nodata none" will help but I still need to
implement a value range check on my CreateCopy anyway. So users don't need to
run gdal_translate again after they find the problem or use "-a_nodata none"
all the time (in a script for example) and miss the
Ivan Lucena hotmail.com> writes:
> Would that be feasible to accept the option "-a_nodata NO" on GDAL command
lines, to indicate that NoData should not pass from the input to the output
dataset?
Would it be something different than "-a_nodata none"?
-a_nodata value:
Assign a specified nodat
Hi Ivan,
>
> Since the SetNoDataValue and GetNodataValue is based on the limitation of
> GeoTiff I would not expect DeleteNoDataValue to be any different. For
> example, there is no way to set/get NoData for individuals bands, there is
> no way to set/get an array of NoData values or NoData value
Hi Vicent,
Since the SetNoDataValue and GetNodataValue is based on the limitation of
GeoTiff I would not expect DeleteNoDataValue to be any different. For example,
there is no way to set/get NoData for individuals bands, there is no way to
set/get an array of NoData values or NoData value range
Hi,
I would like to implement filters and stretches for the GDAL library as
described here (
https://github.com/avyavkumar/GDAL-idea/blob/master/proposal-edit.txt). I
would really like to work on the same, but I still need advice. I would
appreciate guidance on the following tasks:
Help regarding
19.05.2015, 14:04, Even Rouault kirjoitti:
Le mardi 19 mai 2015 13:02:48, Ari Jolma a écrit :
19.05.2015, 13:25, Even Rouault kirjoitti:
ogrinfo strade.shp -dialect sqlite -sql "select spatialite_version()"
"no such function" :D
It's not finding the SpatiaLite at all. I'm using libsqlite3-0
Le mardi 19 mai 2015 13:02:48, Ari Jolma a écrit :
> 19.05.2015, 13:25, Even Rouault kirjoitti:
> > ogrinfo strade.shp -dialect sqlite -sql "select spatialite_version()"
>
> "no such function" :D
>
> It's not finding the SpatiaLite at all. I'm using libsqlite3-0 from
> ubuntu and libspatialite i
19.05.2015, 13:25, Even Rouault kirjoitti:
ogrinfo strade.shp -dialect sqlite -sql "select spatialite_version()"
"no such function" :D
It's not finding the SpatiaLite at all. I'm using libsqlite3-0 from
ubuntu and libspatialite is now my own compiled. I removed the ubuntu
version. ldconfig
On Tue, 19 May 2015 11:25:27 +0200, Even Rouault wrote:
Debian Sid, might be a platform specific issue?
https://bugs.debian.org/785091
few technical details useful to understand better:
a) starting since November 2013 it become definitely clear
that the older self-registration mechanism ba
Le mardi 19 mai 2015 12:21:15, Ari Jolma a écrit :
> Hi all.
> I'm consistently getting a segfault from:
>
> ogr2ogr OUTPUTLAYER.shp strade.shp strade -dialect sqlite -sql "SELECT
> ST_Line_Interpolate_Point( geometry , 0.5 ),* FROM 'strade' "
>
> Anything I can
Hi all.
I'm consistently getting a segfault from:
ogr2ogr OUTPUTLAYER.shp strade.shp strade -dialect sqlite -sql "SELECT
ST_Line_Interpolate_Point( geometry , 0.5 ),* FROM 'strade' "
Anything I can do for debugging?
Running under gdb and displaying the stack trace.
ogr2ogr OUTPUTLAYER.shp st
Il 19/05/2015 11:43, Paolo Cavallini ha scritto:
> Il 19/05/2015 11:18, Antonio Falciano ha scritto:
>
>> ogr2ogr OUTPUTLAYER.shp strade.shp -dialect sqlite -sql "SELECT
>> ST_Line_Interpolate_Point(geometry, 0.5), * FROM strade"
>> What happens in this case?
>
> Same thing, segfault.
> Reading b
Il 19/05/2015 11:18, Antonio Falciano ha scritto:
> ogr2ogr OUTPUTLAYER.shp strade.shp -dialect sqlite -sql "SELECT
> ST_Line_Interpolate_Point(geometry, 0.5), * FROM strade"
> What happens in this case?
Same thing, segfault.
Reading better notes from Debian developer I get convinced is the same
Il 19/05/2015 11:18, Antonio Falciano ha scritto:
> ogr2ogr OUTPUTLAYER.shp strade.shp -dialect sqlite -sql "SELECT
> ST_Line_Interpolate_Point(geometry, 0.5), * FROM strade"
> What happens in this case?
Same thing, segfault.
Reading better notes from Debian developer I get convinced is the same
Le mardi 19 mai 2015 11:24:19, Ari Jolma a écrit :
> 19.05.2015, 12:05, Even Rouault kirjoitti:
> > Paolo,
> >
> >> Hi all.
> >> I'm consistently getting a segfault from:
> >>
> >> ogr2ogr OUTPUTLAYER.shp strade.shp strade -dialect sqlite -sql "SELECT
> >> ST_Line_Interpolate_Point( geometry , 0.
19.05.2015, 12:05, Even Rouault kirjoitti:
Paolo,
Hi all.
I'm consistently getting a segfault from:
ogr2ogr OUTPUTLAYER.shp strade.shp strade -dialect sqlite -sql "SELECT
ST_Line_Interpolate_Point( geometry , 0.5 ),* FROM 'strade' "
Anything I can do for debugging?
Running under gdb and disp
Il 19/05/2015 11:07, Paolo Cavallini ha scritto:
Il 19/05/2015 11:01, Ari Jolma ha scritto:
Can you give us the back trace what led to the segfault? Can you share
the shapefile?
The shape is irrelevant, it happens with anyone.
I'll try to get the backtrace later, I'm now in a workshop.
Could
Il 19/05/2015 11:01, Ari Jolma ha scritto:
> Can you give us the back trace what led to the segfault? Can you share
> the shapefile?
The shape is irrelevant, it happens with anyone.
I'll try to get the backtrace later, I'm now in a workshop.
Could anyone get the command working on Sid?
Thanks for
Paolo,
> Hi all.
> I'm consistently getting a segfault from:
>
> ogr2ogr OUTPUTLAYER.shp strade.shp strade -dialect sqlite -sql "SELECT
> ST_Line_Interpolate_Point( geometry , 0.5 ),* FROM 'strade' "
>
> Anything I can do for debugging?
Running under gdb and displaying the stack trace.
> Debia
19.05.2015, 11:54, Paolo Cavallini kirjoitti:
Hi all.
I'm consistently getting a segfault from:
ogr2ogr OUTPUTLAYER.shp strade.shp strade -dialect sqlite -sql "SELECT
ST_Line_Interpolate_Point( geometry , 0.5 ),* FROM 'strade' "
Anything I can do for debugging?
Paolo,
Can you give us the bac
Hi all.
I'm consistently getting a segfault from:
ogr2ogr OUTPUTLAYER.shp strade.shp strade -dialect sqlite -sql "SELECT
ST_Line_Interpolate_Point( geometry , 0.5 ),* FROM 'strade' "
Anything I can do for debugging?
Debian Sid, might be a platform specific issue?
https://bugs.debian.org/785091
Al
Le mardi 19 mai 2015 10:12:46, Luca Delucchi a écrit :
> Hi devs,
>
> I noticed something strange about the position of EXTRA_IMAGES with
> different DPI values.
>
> If I set a value lower than 73 the EXTRA_IMAGE it is added in the
> right place, but If I increase the value the EXTRA_IMAGE it is
Hi devs,
I noticed something strange about the position of EXTRA_IMAGES with
different DPI values.
If I set a value lower than 73 the EXTRA_IMAGE it is added in the
right place, but If I increase the value the EXTRA_IMAGE it is moved
up from the correct point.
Is this normal or a bug?
Is there
On 13 May 2015 at 09:30, Vankadara, Sunil
wrote:
> Hi Jukka,
>
Hi devs,
I did several test, and
>
> I could understand from your mail that the mediabox is nothing but the image
> size in terms of width and height and the user unit is nothing but each
> pixel size.
>
>
>
> Does it mean it is the
On 05/18/2015 08:37 PM, Sean Gillies wrote:
Hi all,
In consultation with Even Rouault, I've written up RFC 58.
https://trac.osgeo.org/gdal/wiki/rfc58_removing_dataset_nodata_value
The gist of it: allowing deletion of a nodata value defined for a dataset,
thereby rendering all pixels valid wit
36 matches
Mail list logo