Re: [gdal-dev] Problems with large ASTER GeoTIFF

[Jean-Roc Morreale]

EUDEM is an "hybrid product based on SRTM and ASTER GDEM data fused by a 
weighted averaging approach"


Le 2014-04-15 19:55, Joaquim Luis a écrit :

but the ASTER grids have lower real resolution than the SRTM (despite
being distributed as 1 arc sec grids) and the later are originally
int16 , so scaling to 2 bytes ints should be OK.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] [EXTERNAL] Re: ogr oracle multiple geometries

[Smith, Michael ERDC-RDE-CRREL-NH]

Oracle does support multiple geometry columns per table.

Mike

On 4/15/14, 6:29 PM, "Even Rouault"  wrote:

>Le mardi 15 avril 2014 23:43:13, Martin Landa a écrit :
>> Hi,
>> 
>> when importing my testing GML file to Oracle DB I discovered that
>> layers with multiple geometries are not handled by OCI driver
>> correctly - only first geometry is converted to DB. When I tried PG on
>> Linux, I got tables with multiple geometry columns but not in the
>> Oracle. Does anyone have such experience?
>
>This is expected. I don't know if Oracle supports multiple geometry
>columns at 
>all, but even if it does, nobody has upgraded yet the driver to RFC 41.
>
>> 
>> Thanks in advance, Martin
>
>-- 
>Geospatial professional services
>http://even.rouault.free.fr/services.html
>___
>gdal-dev mailing list
>gdal-dev@lists.osgeo.org
>http://lists.osgeo.org/mailman/listinfo/gdal-dev

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Problems with large ASTER GeoTIFF

[Even Rouault]

Le lundi 14 avril 2014 16:16:09, Nicole Stoffels a écrit :
> Dear Gdal-List,
> 
> I have a large ASTER file (downloaded from
> http://www.eea.europa.eu/data-and-maps/data/eu-dem#tab-european-data) in
> the GeoTIFF-format. It is compressed with LZW. What I want to do is:
> 
> 1. unpack it
> 2. seperate a smaller region from it
> 3. convert this regional GeoTIFF to a PNG

I've downloaded the file and it contains only "nan" (not a number) values. So 
nothing wrong with GDAL. It is just a tile that is at the border of the whole 
dataset and has no useful data in it.

If you look at the coordinates :

Upper Left  ( 600.000, 500.000) ( 46d 5'30.86"E, 64d 4'23.83"N)
Lower Left  ( 600.000, 400.000) ( 37d47' 0.49"E, 56d 7'28.33"N)
Upper Right ( 700.000, 500.000) ( 61d24'37.34"E, 58d45'47.24"N)
Lower Right ( 700.000, 400.000) ( 51d32'27.75"E, 51d55'27.24"N)
Center  ( 650.000, 450.000) ( 49d 5'19.45"E, 58d 0'56.34"N)

The center is ~ N 58 E 49, and Moscow is ~ N 55 E 37, so you're definitely 
outside European Union...

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Questions about building 1.11.0beta1 on Windows

[Even Rouault]

Le mardi 15 avril 2014 17:11:02, Carl Godkin a écrit :
> Hi,
> 
> I tried out 1.11.0beta1 yesterday and today and everything I have tried
> seems fine to me on Win64.
> 
> I have two small questions:
> 
> 1. I really like the change in the Windows build procedure that introduces
> the "nmake.local" include in which I can put many of my growing collection
> of local edits.  I say "many" instead of "all" because I don't see how to
> effectively "comment out" a makefile variable using the nmake.local method.
> 
> For instance, I want to build without ODBC support.  The nmake.opt file
> contains the instruction
> 
> # Comment out the following to disable ODBC support.
> ODBC_SUPPORTED = 1
> 
> Can anyone think of a way to undo the ODBC_SUPPORTED definition
> (on by default) from nmake.local?  The variable is later checked in three
> places with "!IFDEF ODBC_SUPPORTED" so changing its value won't work, not
> to mention that the nmake.local inclusion comes before ODBC_SUPPORTED
> definition.

It would probably be a matter of changing that to something like

!IFNDEF ODBC_SUPPORTED
ODBC_SUPPORTED = 1
!ELSE
!IF "$(ODBC_SUPPORTED)" != "1"
ODBC_SUPPORTED  =
!ENDIF
!ENDIF

That way if nothing is specified in nmake.local, it would default to 
ODBC_SUPPORTED=1 as currently. And if you define it to 0 in nmake.local, it 
would be disabled.

Completely untested...

> 
> 2. When building on Win64, I always notice lots of warnings (C4244 and
> C4267) that arise because of implicit conversions from (say) size_t to int.
>  I was wondering why many open source projects (including GDAL) don't seem
> to fix these - is it because the necessary casts make the code less
> readable in someone's opinion?  Or is it just because no one has gotten
> around to it?  If it's the latter, I would be willing to submit a ticket
> with some patches.  It seems a pity to build with /W4 but put up with so
> many warnings.

Yes, I guess correcting warnings is not very fun. You can try to fix them and 
submit a patch, but be careful that automatic casting is not always the most 
appropriate fix for a warning. Sometimes it is just a sign that the target type 
should be fixed. It would be good if you can also separate a patch to GDAL own 
code, from patches to imported external libraries in the GDAL source tree 
(libtiff, libgeotiff, libpng, libjpeg, giflib, degrib, etc..). For the later 
ones, the fixes should be submitted first to the upstream projects.

Even


-- 
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] ogr oracle multiple geometries

[Even Rouault]

Le mardi 15 avril 2014 23:43:13, Martin Landa a écrit :
> Hi,
> 
> when importing my testing GML file to Oracle DB I discovered that
> layers with multiple geometries are not handled by OCI driver
> correctly - only first geometry is converted to DB. When I tried PG on
> Linux, I got tables with multiple geometry columns but not in the
> Oracle. Does anyone have such experience?

This is expected. I don't know if Oracle supports multiple geometry columns at 
all, but even if it does, nobody has upgraded yet the driver to RFC 41.

> 
> Thanks in advance, Martin

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] ogr oracle multiple geometries

[Martin Landa]

Hi,

when importing my testing GML file to Oracle DB I discovered that
layers with multiple geometries are not handled by OCI driver
correctly - only first geometry is converted to DB. When I tried PG on
Linux, I got tables with multiple geometry columns but not in the
Oracle. Does anyone have such experience?

Thanks in advance, Martin

-- 
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] [EXTERNAL] ogr oracle unable to create index

[Martin Landa]

Hi,

2014-04-15 22:44 GMT+02:00 Smith, Michael ERDC-RDE-CRREL-NH
:
> The error indicates that there already is an index by that name. If you
> drop the index manually, then the spatial index will get created.

it doesn't seems to be like that...

drop index obce_idx
Error report -
SQL Error: ORA-01418: specified index does not exist
01418. 0 -  "specified index does not exist"
*Cause:
*Action:

Martin
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] OCI driver and setting the client encoding

[Martin Landa]

Hi,

2012-09-20 20:06 GMT+02:00 Jukka Rahkonen :
>> So, if I understood it, you are using ogr2ogr in a Finnins-Finland
> Windows locale but Oracle is set for
>> american.america and the OGR/OCI driver doesn't make the distinction
> automatically.

I had similar problem, I noticed that with Oracle 11g EX works with

set NLS_LANG=american_america.UTF8

(note an underscore, not a dot). Are you sure that your syntax is
correct? It can be that Oracle is changing it on its own.

It would be really helpful to document it on driver page. I will try
to put there at least a small note about that in the next days. Martin
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] [EXTERNAL] ogr oracle unable to create index

[Smith, Michael ERDC-RDE-CRREL-NH]

Martin,

The error indicates that there already is an index by that name. If you
drop the index manually, then the spatial index will get created.

Mike

-- 
Michael Smith

US Army Corps
Remote Sensing GIS/Center



On 4/15/14, 4:24 PM, "Martin Landa"  wrote:

>Hi all,
>
>when playing with Oracle I discovered that `ogr2ogr -f OCI` fails to
>create a spatial index.
>
>Deleting directly.
>OCI: Prepare(CREATE INDEX "OBCE_IDX" ON OBCE("ORA_GEOMETRY") INDEXTYPE
>IS MDSYS.SPATIAL_INDEX )
>ERROR 1: ORA-00955: name is already used by an existing object
> in CREATE INDEX "OBCE_IDX" ON OBCE("ORA_GEOMETRY") INDEXTYPE IS
>MDSYS.SPATIAL_INDEX
>OCI: Prepare(DROP INDEX "OBCE_IDX")
>
>Any similar experience or ideas what could be wrong (testing GDAL from
>trunk on MS Windows)? Thanks in advance, Martin
>
>-- 
>Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
>___
>gdal-dev mailing list
>gdal-dev@lists.osgeo.org
>http://lists.osgeo.org/mailman/listinfo/gdal-dev

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] ogr oracle unable to create index

[Martin Landa]

Hi all,

when playing with Oracle I discovered that `ogr2ogr -f OCI` fails to
create a spatial index.

Deleting directly.
OCI: Prepare(CREATE INDEX "OBCE_IDX" ON OBCE("ORA_GEOMETRY") INDEXTYPE
IS MDSYS.SPATIAL_INDEX )
ERROR 1: ORA-00955: name is already used by an existing object
 in CREATE INDEX "OBCE_IDX" ON OBCE("ORA_GEOMETRY") INDEXTYPE IS
MDSYS.SPATIAL_INDEX
OCI: Prepare(DROP INDEX "OBCE_IDX")

Any similar experience or ideas what could be wrong (testing GDAL from
trunk on MS Windows)? Thanks in advance, Martin

-- 
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Problems with large ASTER GeoTIFF

[Joaquim Luis]

On 15-04-2014 18:43, MORREALE Jean Roc wrote:
If you're talking about the EAA EU_DEM then PNG isn't a good solution 
as the whole raster as to be loaded to access a subset of it, a 
compressed TIFF with TILED=YES would be better.


Also, you should not try to scale it down to byte as it would only 255 
values, if I remember well the original data is in ctfloat32 so try to 
scale it down to int32 for a huge size gain.


but the ASTER grids have lower real resolution than the SRTM (despite 
being distributed as 1 arc sec grids) and the later are originally int16 
, so scaling to 2 bytes ints should be OK.


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Problems with large ASTER GeoTIFF

[MORREALE Jean Roc]

If you're talking about the EAA EU_DEM then PNG isn't a good solution as 
the whole raster as to be loaded to access a subset of it, a compressed 
TIFF with TILED=YES would be better.


Also, you should not try to scale it down to byte as it would only 255 
values, if I remember well the original data is in ctfloat32 so try to 
scale it down to int32 for a huge size gain.



Le 15/04/2014 16:51, Nicole Stoffels a écrit :

Thanks Chaitanya!



The problem is reading the source file itself. GDAL is unable to find
any valid pixels. Check if you are using the latest GDAL binaries. Use
"gdalinfo -version".


I just installed the latest gdal-version (1.10.1). But it did not solve
my problems. I still get the same error while trying to display the min
and max.

Use qgis to view the input and output. GIMP can't

handle anything except basic pixel types.

But with qgis I can visualize my original large EU_DEM-files. :)

Best regards
Nicole

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] [EXTERNAL] oci and oracle express 11

[Martin Landa]

Hi,

2014-04-12 11:12 GMT+02:00 Jukka Rahkonen :

> It took quite a lot of thinking for many people before you got it to work.
> Driver page http://www.gdal.org/ogr/drv_oci.html does not give any help, it
> does not even mention that oci.dll is somehow involved. Could the more
> advanced OCI users/developers suggest what to add to the driver page for
> helping next new users?

right, I will try to add some useful notes about that. Martin

-- 
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Problems with large ASTER GeoTIFF

[Chaitanya kumar CH]

Nicole,
You should be able to perform those operations from qgis too. Crop it to
your extents, scale the pixel values and save as PNG.

--
Best regards,
Chaitanya Kumar CH
On 15-Apr-2014 8:21 pm, "Nicole Stoffels"  wrote:

> Thanks Chaitanya!
>
>
>> The problem is reading the source file itself. GDAL is unable to find
>> any valid pixels. Check if you are using the latest GDAL binaries. Use
>> "gdalinfo -version".
>>
>
> I just installed the latest gdal-version (1.10.1). But it did not solve my
> problems. I still get the same error while trying to display the min and
> max.
>
> Use qgis to view the input and output. GIMP can't
>
>> handle anything except basic pixel types.
>>
> But with qgis I can visualize my original large EU_DEM-files. :)
>
> Best regards
> Nicole
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Questions about building 1.11.0beta1 on Windows

[Carl Godkin]

Hi,

I tried out 1.11.0beta1 yesterday and today and everything I have tried
seems fine to me on Win64.

I have two small questions:

1. I really like the change in the Windows build procedure that introduces
the "nmake.local" include in which I can put many of my growing collection
of local edits.  I say "many" instead of "all" because I don't see how to
effectively "comment out" a makefile variable using the nmake.local method.

For instance, I want to build without ODBC support.  The nmake.opt file
contains the instruction

# Comment out the following to disable ODBC support.
ODBC_SUPPORTED = 1

Can anyone think of a way to undo the ODBC_SUPPORTED definition
(on by default) from nmake.local?  The variable is later checked in three
places with "!IFDEF ODBC_SUPPORTED" so changing its value won't work, not
to mention that the nmake.local inclusion comes before ODBC_SUPPORTED
definition.

2. When building on Win64, I always notice lots of warnings (C4244 and
C4267) that arise because of implicit conversions from (say) size_t to int.
 I was wondering why many open source projects (including GDAL) don't seem
to fix these - is it because the necessary casts make the code less
readable in someone's opinion?  Or is it just because no one has gotten
around to it?  If it's the latter, I would be willing to submit a ticket
with some patches.  It seems a pity to build with /W4 but put up with so
many warnings.

Thanks,

carl
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Problems with large ASTER GeoTIFF

[Nicole Stoffels]

Thanks Chaitanya!



The problem is reading the source file itself. GDAL is unable to find
any valid pixels. Check if you are using the latest GDAL binaries. Use
"gdalinfo -version".


I just installed the latest gdal-version (1.10.1). But it did not solve 
my problems. I still get the same error while trying to display the min 
and max.


Use qgis to view the input and output. GIMP can't

handle anything except basic pixel types.

But with qgis I can visualize my original large EU_DEM-files. :)

Best regards
Nicole

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] OGR SQLAnywhere driver

[DeHaan, Dave]

Hello GDAL developers,

Are there any GDAL committers who would be willing to review my contribution of 
a new SQLAnywhere OGR driver?  The latest attachment on the ticket below 
contains code that has been built and tested on both Ubuntu and Windows.  I can 
provide assistance with deploying a SQL Anywhere development instance for 
anyone who wants to try it out.

Best regards,
Dave DeHaan

From: gdal-dev-boun...@lists.osgeo.org 
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of DeHaan, Dave
Sent: Saturday, April 05, 2014 3:23 AM
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] OGR SQLAnywhere driver

Hello,

I recently mentioned on gdal-dev that we would like to contribute an OGR driver 
for SAP SQL Anywhere.  I have opened ticket 5430 
http://trac.osgeo.org/gdal/ticket/5430 to track this.  A patch file is attached 
to the ticket.



My apologies for not getting this uploaded before the 1.11.0 first beta was 
prepared.  We would certainly like to get this into 1.11.0 RC1 if at all 
possible (sorry for the tight timeline).



Best regards,

Dave DeHaan


Dr. David DeHaan
PI HANA Plat DM
SAP Canada
445 Wes Graham Way
Waterloo, ON N2L 6R2, Canada
T (519) 883-6487
F (519) 747-4971
E dave.deh...@sap.com
http://www.sap.com>>

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Problems with large ASTER GeoTIFF

[Chaitanya kumar CH]

Nicole,

The problem is reading the source file itself. GDAL is unable to find any
valid pixels. Check if you are using the latest GDAL binaries. Use
"gdalinfo -version". Use qgis to view the input and output. GIMP can't
handle anything except basic pixel types. The -mm option should find some
valid pixels if everything is good.

Later, you should scale the pixel values to 0-255 range to represent them
in PNG.

--
Best regards,
Chaitanya Kumar CH
On 15-Apr-2014 4:40 pm, "Nicole Stoffels"  wrote:

> Thank you both for your answers. I have applied your suggestions.
>
> Making a single command works but does not change the result.
>
> Concerning the compression, I used LZW instead of NONE. However, it also
> does not make any difference.
>
> I also changed the srcwin parameters. I do not get any errors and the
> gdalinfo says that the subarea is within the original area.
>
> I skipped the png part to make it easier first. And after trying to open
> the new tif with gimp and getting an error message that the float32 data
> cannot be displayed I added the ot-flag. Here is my new command line:
>
> $ gdal_translate -ot Byte -srcwin 0 0 4000 4000 -co COMPRESS=LZW
> EUD_CP-DEMS_6500035000-AA.tif test.tif
>
> What I get is a completely black tif. Here are the two gdalinfo-outputs,
> that I get:
>
> $ gdalinfo -mm EUD_CP-DEMS_6500035000-AA.tif
> Driver: GTiff/GeoTIFF
> Files: EUD_CP-DEMS_6500035000-AA.tif
> Size is 4, 4
> Coordinate System is:
> PROJCS["ETRS89 / ETRS-LAEA",
> GEOGCS["ETRS89",
> DATUM["European_Terrestrial_Reference_System_1989",
> SPHEROID["GRS 1980",6378137,298.257222127,
> AUTHORITY["EPSG","7019"]],
> AUTHORITY["EPSG","6258"]],
> PRIMEM["Greenwich",0],
> UNIT["degree",0.0174532925199433],
> AUTHORITY["EPSG","4258"]],
> PROJECTION["Lambert_Azimuthal_Equal_Area"],
> PARAMETER["latitude_of_center",52],
> PARAMETER["longitude_of_center",10],
> PARAMETER["false_easting",4321000],
> PARAMETER["false_northing",321],
> UNIT["metre",1,
> AUTHORITY["EPSG","9001"]],
> AUTHORITY["EPSG","3035"]]
> Origin = (600.000,400.000)
> Pixel Size = (25.000,-25.000)
> Metadata:
>   TIFFTAG_DOCUMENTNAME=EUD_CP-DEMS_6500035000-AA.tif
>   TIFFTAG_IMAGEDESCRIPTION=File written by egcs_wrgtif 2.1
>   TIFFTAG_SOFTWARE=IDL 8.2, Exelis Visual Information Solutions, Inc.
>   TIFFTAG_DATETIME=2013:09:17 21:00:27
>   TIFFTAG_XRESOLUTION=100
>   TIFFTAG_YRESOLUTION=100
>   TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
>   AREA_OR_POINT=Area
> Image Structure Metadata:
>   COMPRESSION=LZW
>   INTERLEAVE=BAND
> Corner Coordinates:
> Upper Left  ( 600.000, 400.000) ( 37d47'0.49"E, 56d 7'28.33"N)
> Lower Left  ( 600.000, 300.000) ( 32d47'35.21"E, 47d45'16.08"N)
> Upper Right ( 700.000, 400.000) ( 51d32'27.75"E, 51d55'27.24"N)
> Lower Right ( 700.000, 300.000) ( 44d57'3.39"E, 44d18'11.63"N)
> Center  ( 650.000, 350.000) ( 41d41'39.51"E, 50d15'46.40"N)
> Band 1 Block=4x1 Type=Float32, ColorInterp=Gray
> ERROR 1: Failed to compute min/max, no valid pixels found in sampling.
>
> $ gdalinfo -mm test.tif
> Driver: GTiff/GeoTIFF
> Files: test.tif
> Size is 4000, 4000
> Coordinate System is:
> PROJCS["ETRS89 / ETRS-LAEA",
> GEOGCS["ETRS89",
> DATUM["European_Terrestrial_Reference_System_1989",
> SPHEROID["GRS 1980",6378137,298.2572221010002,
> AUTHORITY["EPSG","7019"]],
> AUTHORITY["EPSG","6258"]],
> PRIMEM["Greenwich",0],
> UNIT["degree",0.0174532925199433],
> AUTHORITY["EPSG","4258"]],
> PROJECTION["Lambert_Azimuthal_Equal_Area"],
> PARAMETER["latitude_of_center",52],
> PARAMETER["longitude_of_center",10],
> PARAMETER["false_easting",4321000],
> PARAMETER["false_northing",321],
> UNIT["metre",1,
> AUTHORITY["EPSG","9001"]],
> AUTHORITY["EPSG","3035"]]
> Origin = (600.000,400.000)
> Pixel Size = (25.000,-25.000)
> Metadata:
>   TIFFTAG_DOCUMENTNAME=EUD_CP-DEMS_6500035000-AA.tif
>   TIFFTAG_IMAGEDESCRIPTION=File written by egcs_wrgtif 2.1
>   TIFFTAG_SOFTWARE=IDL 8.2, Exelis Visual Information Solutions, Inc.
>   TIFFTAG_DATETIME=2013:09:17 21:00:27
>   TIFFTAG_XRESOLUTION=100
>   TIFFTAG_YRESOLUTION=100
>   TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
>   AREA_OR_POINT=Area
> Image Structure Metadata:
>   COMPRESSION=LZW
>   INTERLEAVE=BAND
> Corner Coordinates:
> Upper Left  ( 600.000, 400.000) ( 37d47'0.49"E, 56d 7'28.33"N)
> Lower Left  ( 600.000, 390.000) ( 37d10'18.23"E, 55d18'7.26"N)
> Upper Right ( 610.000, 400.000) ( 39d16'14.71"E, 55d46'30.54"N)
> Lower Right ( 610.000, 390.000) ( 38d38'6.52"E, 54d57'38.92"N)
> Center  ( 605.000, 395.000) ( 38d12'51.64"E, 55d32'35.70"N)
> Band 1 Block=4000x2 Type=Byte, ColorI

Re: [gdal-dev] Problems with large ASTER GeoTIFF

[Nicole Stoffels]

Thank you both for your answers. I have applied your suggestions.

Making a single command works but does not change the result.

Concerning the compression, I used LZW instead of NONE. However, it also 
does not make any difference.


I also changed the srcwin parameters. I do not get any errors and the 
gdalinfo says that the subarea is within the original area.


I skipped the png part to make it easier first. And after trying to open 
the new tif with gimp and getting an error message that the float32 data 
cannot be displayed I added the ot-flag. Here is my new command line:


$ gdal_translate -ot Byte -srcwin 0 0 4000 4000 -co COMPRESS=LZW 
EUD_CP-DEMS_6500035000-AA.tif test.tif


What I get is a completely black tif. Here are the two gdalinfo-outputs, 
that I get:


$ gdalinfo -mm EUD_CP-DEMS_6500035000-AA.tif
Driver: GTiff/GeoTIFF
Files: EUD_CP-DEMS_6500035000-AA.tif
Size is 4, 4
Coordinate System is:
PROJCS["ETRS89 / ETRS-LAEA",
GEOGCS["ETRS89",
DATUM["European_Terrestrial_Reference_System_1989",
SPHEROID["GRS 1980",6378137,298.257222127,
AUTHORITY["EPSG","7019"]],
AUTHORITY["EPSG","6258"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4258"]],
PROJECTION["Lambert_Azimuthal_Equal_Area"],
PARAMETER["latitude_of_center",52],
PARAMETER["longitude_of_center",10],
PARAMETER["false_easting",4321000],
PARAMETER["false_northing",321],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AUTHORITY["EPSG","3035"]]
Origin = (600.000,400.000)
Pixel Size = (25.000,-25.000)
Metadata:
  TIFFTAG_DOCUMENTNAME=EUD_CP-DEMS_6500035000-AA.tif
  TIFFTAG_IMAGEDESCRIPTION=File written by egcs_wrgtif 2.1
  TIFFTAG_SOFTWARE=IDL 8.2, Exelis Visual Information Solutions, Inc.
  TIFFTAG_DATETIME=2013:09:17 21:00:27
  TIFFTAG_XRESOLUTION=100
  TIFFTAG_YRESOLUTION=100
  TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
  AREA_OR_POINT=Area
Image Structure Metadata:
  COMPRESSION=LZW
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  ( 600.000, 400.000) ( 37d47'0.49"E, 56d 7'28.33"N)
Lower Left  ( 600.000, 300.000) ( 32d47'35.21"E, 47d45'16.08"N)
Upper Right ( 700.000, 400.000) ( 51d32'27.75"E, 51d55'27.24"N)
Lower Right ( 700.000, 300.000) ( 44d57'3.39"E, 44d18'11.63"N)
Center  ( 650.000, 350.000) ( 41d41'39.51"E, 50d15'46.40"N)
Band 1 Block=4x1 Type=Float32, ColorInterp=Gray
ERROR 1: Failed to compute min/max, no valid pixels found in sampling.

$ gdalinfo -mm test.tif
Driver: GTiff/GeoTIFF
Files: test.tif
Size is 4000, 4000
Coordinate System is:
PROJCS["ETRS89 / ETRS-LAEA",
GEOGCS["ETRS89",
DATUM["European_Terrestrial_Reference_System_1989",
SPHEROID["GRS 1980",6378137,298.2572221010002,
AUTHORITY["EPSG","7019"]],
AUTHORITY["EPSG","6258"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4258"]],
PROJECTION["Lambert_Azimuthal_Equal_Area"],
PARAMETER["latitude_of_center",52],
PARAMETER["longitude_of_center",10],
PARAMETER["false_easting",4321000],
PARAMETER["false_northing",321],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AUTHORITY["EPSG","3035"]]
Origin = (600.000,400.000)
Pixel Size = (25.000,-25.000)
Metadata:
  TIFFTAG_DOCUMENTNAME=EUD_CP-DEMS_6500035000-AA.tif
  TIFFTAG_IMAGEDESCRIPTION=File written by egcs_wrgtif 2.1
  TIFFTAG_SOFTWARE=IDL 8.2, Exelis Visual Information Solutions, Inc.
  TIFFTAG_DATETIME=2013:09:17 21:00:27
  TIFFTAG_XRESOLUTION=100
  TIFFTAG_YRESOLUTION=100
  TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
  AREA_OR_POINT=Area
Image Structure Metadata:
  COMPRESSION=LZW
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  ( 600.000, 400.000) ( 37d47'0.49"E, 56d 7'28.33"N)
Lower Left  ( 600.000, 390.000) ( 37d10'18.23"E, 55d18'7.26"N)
Upper Right ( 610.000, 400.000) ( 39d16'14.71"E, 55d46'30.54"N)
Lower Right ( 610.000, 390.000) ( 38d38'6.52"E, 54d57'38.92"N)
Center  ( 605.000, 395.000) ( 38d12'51.64"E, 55d32'35.70"N)
Band 1 Block=4000x2 Type=Byte, ColorInterp=Gray
Computed Min/Max=0.000,0.000

Am 14.04.2014 19:51, schrieb Etienne Tourigny:>



On Mon, Apr 14, 2014 at 11:16 AM, Nicole Stoffels mailto:stoff...@f2e.de>> wrote:

Dear Gdal-List,

I have a large ASTER file (downloaded from
http://www.eea.europa.eu/data-__and-maps/data/eu-dem#tab-__european-data
)
in the GeoTIFF-format. It is compressed with LZW. What I want to do is:

1. unpack it
2. seperate a smaller region from it
3. convert this regional GeoTIFF to a PNG

What I am doing:

$ gdal_translate -co COMPRESS=NONE EUD_CP-DEMS_6500035000-AA.tif
tmp1.tif

$ gdal_

[gdal-dev] ReprojectImage and nodata

[Luca Delucchi]

I everybody,

I'm using Python ReprojectImage function to reproject some images but
there is no way to assign nodata value.

There was already a request for help about one year ago [0], there are
some news?
Otherwise could I open a ticket? is it a bug or enhancement?

Thanks a lot for any hints

[0] 
http://osgeo-org.1560.x6.nabble.com/gdal-dev-ReprojectImage-and-nodata-td5057270.html

-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev