[gdal-dev] ESRI binary grids problem

2010-10-20 Thread Sebastian E. Ovide
Hi All

I've save a ESRI binary grid using ArcMAP (in Binary format) and using
gdalinfo it looks like the RRD files are not read...

any ideas ?

thanks

g...@mapserver:~$ gdalinfo data/ie/rasters/ie_t02_q200/
Driver: AIG/Arc/Info Binary Grid
Files: data/ie/rasters/ie_t02_q200/
   data/ie/rasters/ie_t02_q200/z001014x.adf
   data/ie/rasters/ie_t02_q200/prj.adf
   data/ie/rasters/ie_t02_q200/z001002.adf
   data/ie/rasters/ie_t02_q200/z001003.adf
   data/ie/rasters/ie_t02_q200/z001011x.adf
   data/ie/rasters/ie_t02_q200/z001008.adf
   data/ie/rasters/ie_t02_q200/z001004.adf
   data/ie/rasters/ie_t02_q200/dblbnd.adf
   data/ie/rasters/ie_t02_q200/w001001x.adf
   data/ie/rasters/ie_t02_q200/z001009x.adf
   data/ie/rasters/ie_t02_q200/z001012x.adf
   data/ie/rasters/ie_t02_q200/w001001.adf
   data/ie/rasters/ie_t02_q200/z001003x.adf
   data/ie/rasters/ie_t02_q200/sta.adf
   data/ie/rasters/ie_t02_q200/z001015.adf
   data/ie/rasters/ie_t02_q200/z001005.adf
   data/ie/rasters/ie_t02_q200/z001013x.adf
   data/ie/rasters/ie_t02_q200/z001010.adf
   data/ie/rasters/ie_t02_q200/w001000.adf
   data/ie/rasters/ie_t02_q200/z001006.adf
   data/ie/rasters/ie_t02_q200/z001014.adf
   data/ie/rasters/ie_t02_q200/hdr.adf
   data/ie/rasters/ie_t02_q200/z001001.adf
   data/ie/rasters/ie_t02_q200/z001005x.adf
   data/ie/rasters/ie_t02_q200/z001010x.adf
   data/ie/rasters/ie_t02_q200/z001004x.adf
   data/ie/rasters/ie_t02_q200/w001000x.adf
   data/ie/rasters/ie_t02_q200/z001013.adf
   data/ie/rasters/ie_t02_q200/z001015x.adf
   data/ie/rasters/ie_t02_q200/z001001x.adf
   data/ie/rasters/ie_t02_q200/z001007x.adf
   data/ie/rasters/ie_t02_q200/z001006x.adf
   data/ie/rasters/ie_t02_q200/z001011.adf
   data/ie/rasters/ie_t02_q200/z001007.adf
   data/ie/rasters/ie_t02_q200/z001008x.adf
   data/ie/rasters/ie_t02_q200/z001002x.adf
   data/ie/rasters/ie_t02_q200/z001009.adf
   data/ie/rasters/ie_t02_q200/z001012.adf
Size is 64402, 89106
Coordinate System is:
PROJCS[unnamed,
GEOGCS[WGS 84,
DATUM[WGS_1984,
SPHEROID[WGS 84,6378137,298.257223563,
AUTHORITY[EPSG,7030]],
TOWGS84[0,0,0,0,0,0,0],
AUTHORITY[EPSG,6326]],
PRIMEM[Greenwich,0,
AUTHORITY[EPSG,8901]],
UNIT[degree,0.0174532925199433,
AUTHORITY[EPSG,9108]],
AUTHORITY[EPSG,4326]],
PROJECTION[Transverse_Mercator],
PARAMETER[latitude_of_origin,53.5],
PARAMETER[central_meridian,-8],
PARAMETER[scale_factor,1.35],
PARAMETER[false_easting,20],
PARAMETER[false_northing,25],
UNIT[METERS,1]]
Origin = (15390.000,461520.000)
Pixel Size = (5.000,-5.000)
Corner Coordinates:
Upper Left  (   15390.000,  461520.000) ( 10d54'41.98W, 55d21'55.72N)
Lower Left  (   15390.000,   15990.000) ( 10d39'3.41W, 51d22'1.58N)
Upper Right (  337400.000,  461520.000) (  5d49'56.05W, 55d22'51.38N)
Lower Right (  337400.000,   15990.000) (  6d 1'35.29W, 51d22'49.73N)
Center  (  176395.000,  238755.000) (  8d21'17.49W, 53d23'54.38N)
Band 1 Block=512x4 Type=Float32, ColorInterp=Undefined
  Min=1.000 Max=4.000
  NoData Value=-3.4028234663852886e+38
ERROR 3: Attempt to read past EOF in
data/ie/rasters/ie_t02_q200//../info/arc.dir.
ERROR 4: Failed to open table .VAT


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

Re: [gdal-dev] Reading GML

2010-10-20 Thread Chaitanya kumar CH
Paul,

1.7 doesn't support some geometry types that 1.8 does. GDAL1.8 is yet to be
released. You have to build it yourselves.
You can find a nightly snapshot of the source code for the trunk (1.8) at
http://trac.osgeo.org/gdal/wiki/DownloadSource#NightlySnapshots
Build hints: http://trac.osgeo.org/gdal/wiki/BuildHints


On Wed, Oct 20, 2010 at 2:45 PM, Paul Meems bontepaar...@gmail.com wrote:

 Hi all,

 I have a GML which I want to convert to shapefile.
 I've started with checking the file with ogrinfo (v1.7.2).
 It returns Unrecognised geometry type Surface.

 After searching a bit it seems GDAL v1.8 might read the GML properly.
 So I'm looking for the binaries of GDAL v1.8. At Tamas his site I can
 download the v1.7.2 version but I can't find the v1.8 binaries.

 Does anybody know where I can download that version or do I need to build
 them myself?

 Thanks,

 Paul
 The Netherlands


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




-- 
Best regards,
Chaitanya kumar CH.
/tʃaɪθənjə/ /kʊmɑr/
+91-9494447584
17.2416N 80.1426E
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Reading GML

2010-10-20 Thread Ari Jolma

On 10/20/2010 12:15 PM, Paul Meems wrote:

Hi all,

I have a GML which I want to convert to shapefile.
I've started with checking the file with ogrinfo (v1.7.2).
It returns Unrecognised geometry type Surface.

After searching a bit it seems GDAL v1.8 might read the GML properly.
So I'm looking for the binaries of GDAL v1.8. At Tamas his site I can 
download the v1.7.2 version but I can't find the v1.8 binaries.


Does anybody know where I can download that version or do I need to 
build them myself?


Geoinformatica contains a very recent GDAL (1.8 is not yet released) 
built for Windows with MinGW: 
http://geoinformatics.tkk.fi/files/Geoinformatica/win32/Geoinformatica-2010-10-18.exe


It contains Xerces so GML should be supported (if that's a requirement - 
I don't use GML much) - I have no idea if GML surfaces are supported. 
Mark Overmeer develops a Perl module for GML but as of yet there's no 
integration with Geoinformatica (which contains Perl support for GDAL).


Ari



Thanks,

Paul
The Netherlands


___
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] Reading GML

2010-10-20 Thread Even Rouault
Paul,

you can find GDAL 1.8dev binary packages on Tamas site. They are identified as
the -dev releases.

Selon Chaitanya kumar CH chaitanya...@gmail.com:

 Paul,

 1.7 doesn't support some geometry types that 1.8 does. GDAL1.8 is yet to be
 released. You have to build it yourselves.
 You can find a nightly snapshot of the source code for the trunk (1.8) at
 http://trac.osgeo.org/gdal/wiki/DownloadSource#NightlySnapshots
 Build hints: http://trac.osgeo.org/gdal/wiki/BuildHints


 On Wed, Oct 20, 2010 at 2:45 PM, Paul Meems bontepaar...@gmail.com wrote:

  Hi all,
 
  I have a GML which I want to convert to shapefile.
  I've started with checking the file with ogrinfo (v1.7.2).
  It returns Unrecognised geometry type Surface.
 
  After searching a bit it seems GDAL v1.8 might read the GML properly.
  So I'm looking for the binaries of GDAL v1.8. At Tamas his site I can
  download the v1.7.2 version but I can't find the v1.8 binaries.
 
  Does anybody know where I can download that version or do I need to build
  them myself?
 
  Thanks,
 
  Paul
  The Netherlands
 
 
  ___
  gdal-dev mailing list
  gdal-dev@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/gdal-dev
 



 --
 Best regards,
 Chaitanya kumar CH.
 /tʃaɪθənjə/ /kʊmɑr/
 +91-9494447584
 17.2416N 80.1426E



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


Re: [gdal-dev] Reading GML

2010-10-20 Thread Paul Meems
Even,

You are completely right.
I was a bit confused by all the numbers in the package names ;)

I'm going the check my GML now.

Thanks,
Paul

2010/10/20 Even Rouault even.roua...@mines-paris.org

 Paul,

 you can find GDAL 1.8dev binary packages on Tamas site. They are identified
 as
 the -dev releases.

 Selon Chaitanya kumar CH chaitanya...@gmail.com:

  Paul,
 
  1.7 doesn't support some geometry types that 1.8 does. GDAL1.8 is yet to
 be
  released. You have to build it yourselves.
  You can find a nightly snapshot of the source code for the trunk (1.8) at
  http://trac.osgeo.org/gdal/wiki/DownloadSource#NightlySnapshots
  Build hints: http://trac.osgeo.org/gdal/wiki/BuildHints
 
 
  On Wed, Oct 20, 2010 at 2:45 PM, Paul Meems bontepaar...@gmail.com
 wrote:
 
   Hi all,
  
   I have a GML which I want to convert to shapefile.
   I've started with checking the file with ogrinfo (v1.7.2).
   It returns Unrecognised geometry type Surface.
  
   After searching a bit it seems GDAL v1.8 might read the GML properly.
   So I'm looking for the binaries of GDAL v1.8. At Tamas his site I can
   download the v1.7.2 version but I can't find the v1.8 binaries.
  
   Does anybody know where I can download that version or do I need to
 build
   them myself?
  
   Thanks,
  
   Paul
   The Netherlands
  
  
   ___
   gdal-dev mailing list
   gdal-dev@lists.osgeo.org
   http://lists.osgeo.org/mailman/listinfo/gdal-dev
  
 
 
 
  --
  Best regards,
  Chaitanya kumar CH.
  /tʃaɪθənjə/ /kʊmɑr/
  +91-9494447584
  17.2416N 80.1426E
 



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

Re: [gdal-dev] ESRI binary grids problem

2010-10-20 Thread Frank Warmerdam

Sebastian E. Ovide wrote:

Hi All

I've save a ESRI binary grid using ArcMAP (in Binary format) and using 
gdalinfo it looks like the RRD files are not read... 


Sebastian,

Unfortunately, it is hard for me to figure out much without access to
the dataset.   For a counter example, I'll provide a trimmed gdalinfo
report for an aigrid dataset where the .rrd's are used:

Driver: AIG/Arc/Info Binary Grid
Files: h_dem
   h_dem.aux
   h_dem.rrd
   h_dem/vat.adf
   h_dem/metadata.xml
   h_dem/log
   h_dem/w001001.adf
   h_dem/dblbnd.adf
   h_dem/hdr.adf
   h_dem/w001001x.adf
   h_dem/sta.adf
   h_dem/prj.adf
Size is 3602, 1802
Coordinate System is:
GEOGCS[WGS 84,
...
Origin = (-180.094,90.123)
Pixel Size = (0.100,-0.100)
Corner Coordinates:
Upper Left  (-180.100,  90.100) (180d 6' 0.00W, 90d 6' 0.00N)
Lower Left  (-180.100, -90.100) (180d 6' 0.00W, 90d 6' 0.00S)
Upper Right ( 180.100,  90.100) (180d 6' 0.00E, 90d 6' 0.00N)
Lower Right ( 180.100, -90.100) (180d 6' 0.00E, 90d 6' 0.00S)
Center  (   0.000,   0.000) (  0d 0' 0.00E,  0d 0' 0.00N)
Band 1 Block=256x4 Type=Int16, ColorInterp=Undefined
  Min=-405.000 Max=7512.000
  NoData Value=-32768
  Overviews: 899x449, 448x223, 223x110, 110x54
  Metadata:
LAYER_TYPE=athematic

Note the .aux and .rrd files listed in the file list above the grid
directory.  Also note the Overviews: listed in the band description.

The error report in yours about not being able to read the contents of
the info directory are not uncommon and I wouldn't expect that to interefere
with the .aux/.rrd access though I'm not sure there is no side effect.  You
might try hiding your info directory temporarily to see if that helps.

Best regards,
--
---+--
I set the clouds in motion - turn up   | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent

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


[gdal-dev] PDF--JPEG--KML. Confused about association between KML bounding box and PDF's neatline and corner coordinates.

2010-10-20 Thread Boris Dev
My objective is to make a KML ground overlay with a geospatial PDF map.

Using GDAL's translate utility I have converted the PDF to a JPEG. The next
step and problem for me is to write the text of the KML ground overlay,
which requires a text of bounding box information like this:

LatLonBox
north37.91904192681665/north
south37.46543388598137/south
east15.35832653742206/east
west14.60128369746704/west

rotation-0.1556640799496235/rotation
  /LatLonBox


As GDAL's output, I saw that the entire PDF with legend, title, etc and not
just the map image was converted.

As GDAL's output, I also saw 2 parts of data that seem they are useful to
match a bounding box to the map within the jpeg, but I cant figure out the
puzzle of how to make this work? Can I get the bounding box of the entire
PDF image with this information below?

Corner Coordinates:
Upper Left  (  666937.758, 2024687.983)
Lower Left  (  666991.811, 2018338.153)
Upper Right (  674511.276, 2024754.795)
Lower Right (  674565.328, 2018404.965)
Center  (  670751.543, 2021546.474)

MDI key=NEATLINEPOLYGON ((672676.488065659650601
2019417.955749646294862,672636.091432046378031
2024030.267778463661671,667347.405745737953112
2023983.612156898481771,667385.539170471020043
2019370.524140953086317,672676.488065659650601
2019417.955749646294862,672676.488065659650601
2019417.955749646294862,672676.488065659650601
2019417.955749646294862,672676.488065659650601
2019417.955749646294862))/MDI

I realize the coordinate above need to be converted to lat/long to be a KML
ground overlay onto Google Maps, which I think I can handle.

But I am unsure if I need to extract the map image from the jpeg using the
NEATLINE?
How are the Corner Coordinates translated into a bounding box?

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

[gdal-dev] [gdal_retile]reshape ecw

2010-10-20 Thread Tacot

Hi,

I try to cut an image in several tiles.
I use this command:

gdal_retile -of ECW -ps 1 1 -targetDir C:\GDAL\ECW Image.ecw

I obtain 4 tiles, but after I've got this message:

Traceback (most recent call last):
  File C:\PROGRA~1\FWTOOL~1.7\bin\gdal_retile.py, line 941, in ?
sys.exit(main(sys.argv))
  File C:\PROGRA~1\FWTOOL~1.7\bin\gdal_retile.py, line 858, in main
dsCreatedTileIndex = tileImage(minfo,ti)
  File C:\PROGRA~1\FWTOOL~1.7\bin\gdal_retile.py, line 336, in tileImage
createTile(minfo, offsetX, offsetY, width, height,tilename,OGRDS)
  File C:\PROGRA~1\FWTOOL~1.7\bin\gdal_retile.py, line 507, in createTile
data = s_band.ReadRaster( 0,0,readX,readY,readX,readY,  t_band.DataType
)
  File C:\PROGRA~1\FWTOOL~1.7\pymod\gdal.py, line 851, in ReadRaster
buf_xsize, buf_ysize,buf_type)
MemoryError

So I guess that's a memory's problem.
So Is there a means to by-pass it?

Thanks

-- 
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/gdal-retile-reshape-ecw-tp5655048p5655048.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] PDF--JPEG--KML. Confused about association between KML bounding box and PDF's neatline and corner coordinates.

2010-10-20 Thread Brent Fraser

Boris,

  Use gdalwarp to convert your jpeg to Geographic coordinates (I think 
it needs to be converted for KML anyways):


gdalwarp -t_srs EPSG:4326 in.jpg out.jpg

then use gdalinfo to get the corner coordinates.

Currently the entire page of the PDF is rendered into the image.   
Perhaps we can convince Even to add an option to convert only the mapped 
area (or mask everything else?)


Best Regards,
Brent Fraser

On 10/20/2010 8:07 AM, Boris Dev wrote:

My objective is to make a KML ground overlay with a geospatial PDF map.

Using GDAL's translate utility I have converted the PDF to a JPEG. The 
next step and problem for me is to write the text of the KML ground 
overlay, which requires a text of bounding box information like this:


LatLonBox
 north37.91904192681665/north
 south37.46543388598137/south
 east15.35832653742206/east
 west14.60128369746704/west


 rotation-0.1556640799496235/rotation
   /LatLonBox

As GDAL's output, I saw that the entire PDF with legend, title, etc 
and not just the map image was converted.


As GDAL's output, I also saw 2 parts of data that seem they are useful 
to match a bounding box to the map within the jpeg, but I cant figure 
out the puzzle of how to make this work? Can I get the bounding box of 
the entire PDF image with this information below?


Corner Coordinates:
Upper Left  (  666937.758, 2024687.983)
Lower Left  (  666991.811, 2018338.153)
Upper Right (  674511.276, 2024754.795)
Lower Right (  674565.328, 2018404.965)
Center  (  670751.543, 2021546.474)

MDI key=NEATLINEPOLYGON ((672676.488065659650601 
2019417.955749646294862,672636.091432046378031 
2024030.267778463661671,667347.405745737953112 
2023983.612156898481771,667385.539170471020043 
2019370.524140953086317,672676.488065659650601 
2019417.955749646294862,672676.488065659650601 
2019417.955749646294862,672676.488065659650601 
2019417.955749646294862,672676.488065659650601 
2019417.955749646294862))/MDI


I realize the coordinate above need to be converted to lat/long to be 
a KML ground overlay onto Google Maps, which I think I can handle.


But I am unsure if I need to extract the map image from the jpeg using 
the NEATLINE?

How are the Corner Coordinates translated into a bounding box?

Any suggestions?


___
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] [gdal_retile]reshape ecw

2010-10-20 Thread christian . mueller
The error does not occur in the gdal_retile.py  python code, it occurs  
in the gdal C code.  Your tile size
is really large producing images with 100 millions of pixel. Try a  
smaller  pixel size, each pixel needs some bytes, dependent on your  
color model.


Quoting Tacot cfa...@hotmail.fr:



Hi,

I try to cut an image in several tiles.
I use this command:

gdal_retile -of ECW -ps 1 1 -targetDir C:\GDAL\ECW Image.ecw

I obtain 4 tiles, but after I've got this message:

Traceback (most recent call last):
  File C:\PROGRA~1\FWTOOL~1.7\bin\gdal_retile.py, line 941, in ?
sys.exit(main(sys.argv))
  File C:\PROGRA~1\FWTOOL~1.7\bin\gdal_retile.py, line 858, in main
dsCreatedTileIndex = tileImage(minfo,ti)
  File C:\PROGRA~1\FWTOOL~1.7\bin\gdal_retile.py, line 336, in tileImage
createTile(minfo, offsetX, offsetY, width, height,tilename,OGRDS)
  File C:\PROGRA~1\FWTOOL~1.7\bin\gdal_retile.py, line 507, in createTile
data = s_band.ReadRaster( 0,0,readX,readY,readX,readY,  t_band.DataType
)
  File C:\PROGRA~1\FWTOOL~1.7\pymod\gdal.py, line 851, in ReadRaster
buf_xsize, buf_ysize,buf_type)
MemoryError

So I guess that's a memory's problem.
So Is there a means to by-pass it?

Thanks

--
View this message in context:   
http://osgeo-org.1803224.n2.nabble.com/gdal-retile-reshape-ecw-tp5655048p5655048.html

Sent from the GDAL - Dev mailing list archive at Nabble.com.






This message was sent using IMP, the Internet Messaging Program.


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


Re: [gdal-dev] PDF--JPEG--KML. Confused about association between KML bounding box and PDF's neatline and corner coordinates.

2010-10-20 Thread Even Rouault
You don't need to convince anyone to add new functionnality. It already exists
;-)

See the -cutline option of gdalwarp. Basically you use the NEATLINE reported by
gdalinfo as the CUTLINE (that was the sole purpose of reporting the NEATLINE by
the way !)

The easiest way is to make a simple CSV like this :

foo,WKT
bla,POLYGON(())

and you paste the content of NEATLINE as the value of the WKT.

and do a gdalwarp without reprojecting to crop (use -crop_to_cutline) to the
neatline. Then you can do a 2nd gdalwarp to reproject to the target SRS.

(if you want to do just one gdalwarp, you'll have to do ogr2ogr to reproject the
cutline.csv into the target SRS)

See http://gdal.org/gdalwarp.html and/or
http://gdal.org/structGDALWarpOptions.html#0ed77f9917bb96c7a9aabd73d4d06e08


 Boris,

Use gdalwarp to convert your jpeg to Geographic coordinates (I think
 it needs to be converted for KML anyways):

 gdalwarp -t_srs EPSG:4326 in.jpg out.jpg

 then use gdalinfo to get the corner coordinates.

 Currently the entire page of the PDF is rendered into the image.
 Perhaps we can convince Even to add an option to convert only the mapped
 area (or mask everything else?)

 Best Regards,
 Brent Fraser

 On 10/20/2010 8:07 AM, Boris Dev wrote:
  My objective is to make a KML ground overlay with a geospatial PDF map.
 
  Using GDAL's translate utility I have converted the PDF to a JPEG. The
  next step and problem for me is to write the text of the KML ground
  overlay, which requires a text of bounding box information like this:
 
  LatLonBox
   north37.91904192681665/north
   south37.46543388598137/south
   east15.35832653742206/east
   west14.60128369746704/west
 
 
   rotation-0.1556640799496235/rotation
 /LatLonBox
 
  As GDAL's output, I saw that the entire PDF with legend, title, etc
  and not just the map image was converted.
 
  As GDAL's output, I also saw 2 parts of data that seem they are useful
  to match a bounding box to the map within the jpeg, but I cant figure
  out the puzzle of how to make this work? Can I get the bounding box of
  the entire PDF image with this information below?
 
  Corner Coordinates:
  Upper Left  (  666937.758, 2024687.983)
  Lower Left  (  666991.811, 2018338.153)
  Upper Right (  674511.276, 2024754.795)
  Lower Right (  674565.328, 2018404.965)
  Center  (  670751.543, 2021546.474)
 
  MDI key=NEATLINEPOLYGON ((672676.488065659650601
  2019417.955749646294862,672636.091432046378031
  2024030.267778463661671,667347.405745737953112
  2023983.612156898481771,667385.539170471020043
  2019370.524140953086317,672676.488065659650601
  2019417.955749646294862,672676.488065659650601
  2019417.955749646294862,672676.488065659650601
  2019417.955749646294862,672676.488065659650601
  2019417.955749646294862))/MDI
 
  I realize the coordinate above need to be converted to lat/long to be
  a KML ground overlay onto Google Maps, which I think I can handle.
 
  But I am unsure if I need to extract the map image from the jpeg using
  the NEATLINE?
  How are the Corner Coordinates translated into a bounding box?
 
  Any suggestions?
 
 
  ___
  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] Re: [gdal_retile]reshape ecw

2010-10-20 Thread Tacot

Hi,

Why do you talk about million pixels?

I'm trying now with this command:
gdal_retile -of ECW -ps 1000 1000 -targetDir C:\GDAL\ECW Image.ecw
It's not finished yet, but there's so many tiles!!

I thought maybe using gdalbuildvrt, it could be a possibility.
-- 
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/gdal-retile-reshape-ecw-tp5655048p5655301.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] Re: [gdal_retile]reshape ecw

2010-10-20 Thread christian . mueller
The -ps parameter specifies the pixel width and pixel height of a  
tile. You must multiply these values.


-ps  1000 1000

means 1000x1000 = 1 million pixels for each tile

As a consequence, a tile needs 1 MB .. n MB , depending on your color  
model. The file size of the tiles my be smaller if compression is  
used. (e. g. png), but in memory during calculations, the  raster data  
is uncompressed.


Quoting Tacot cfa...@hotmail.fr:



Hi,

Why do you talk about million pixels?

I'm trying now with this command:
gdal_retile -of ECW -ps 1000 1000 -targetDir C:\GDAL\ECW Image.ecw
It's not finished yet, but there's so many tiles!!

I thought maybe using gdalbuildvrt, it could be a possibility.
--
View this message in context:   
http://osgeo-org.1803224.n2.nabble.com/gdal-retile-reshape-ecw-tp5655048p5655301.html

Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev






This message was sent using IMP, the Internet Messaging Program.


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


Re: [gdal-dev] PDF--JPEG--KML. Confused about association between KML bounding box and PDF's neatline and corner coordinates.

2010-10-20 Thread Brent Fraser
Hmmm.  My PDF doesn't seem to have a neatline, only a MediaBox and two 
BBoxes...


Brent

On 10/20/2010 9:04 AM, Even Rouault wrote:

You don't need to convince anyone to add new functionnality. It already exists
;-)

See the -cutline option of gdalwarp. Basically you use the NEATLINE reported by
gdalinfo as the CUTLINE (that was the sole purpose of reporting the NEATLINE by
the way !)

The easiest way is to make a simple CSV like this :

foo,WKT
bla,POLYGON(())

and you paste the content of NEATLINE as the value of the WKT.

and do a gdalwarp without reprojecting to crop (use -crop_to_cutline) to the
neatline. Then you can do a 2nd gdalwarp to reproject to the target SRS.

(if you want to do just one gdalwarp, you'll have to do ogr2ogr to reproject the
cutline.csv into the target SRS)

See http://gdal.org/gdalwarp.html and/or
http://gdal.org/structGDALWarpOptions.html#0ed77f9917bb96c7a9aabd73d4d06e08



Boris,

Use gdalwarp to convert your jpeg to Geographic coordinates (I think
it needs to be converted for KML anyways):

gdalwarp -t_srs EPSG:4326 in.jpg out.jpg

then use gdalinfo to get the corner coordinates.

Currently the entire page of the PDF is rendered into the image.
Perhaps we can convince Even to add an option to convert only the mapped
area (or mask everything else?)

Best Regards,
Brent Fraser

On 10/20/2010 8:07 AM, Boris Dev wrote:

My objective is to make a KML ground overlay with a geospatial PDF map.

Using GDAL's translate utility I have converted the PDF to a JPEG. The
next step and problem for me is to write the text of the KML ground
overlay, which requires a text of bounding box information like this:

LatLonBox
  north37.91904192681665/north
  south37.46543388598137/south
  east15.35832653742206/east
  west14.60128369746704/west


  rotation-0.1556640799496235/rotation
/LatLonBox

As GDAL's output, I saw that the entire PDF with legend, title, etc
and not just the map image was converted.

As GDAL's output, I also saw 2 parts of data that seem they are useful
to match a bounding box to the map within the jpeg, but I cant figure
out the puzzle of how to make this work? Can I get the bounding box of
the entire PDF image with this information below?

Corner Coordinates:
Upper Left  (  666937.758, 2024687.983)
Lower Left  (  666991.811, 2018338.153)
Upper Right (  674511.276, 2024754.795)
Lower Right (  674565.328, 2018404.965)
Center  (  670751.543, 2021546.474)

MDI key=NEATLINEPOLYGON ((672676.488065659650601
2019417.955749646294862,672636.091432046378031
2024030.267778463661671,667347.405745737953112
2023983.612156898481771,667385.539170471020043
2019370.524140953086317,672676.488065659650601
2019417.955749646294862,672676.488065659650601
2019417.955749646294862,672676.488065659650601
2019417.955749646294862,672676.488065659650601
2019417.955749646294862))/MDI

I realize the coordinate above need to be converted to lat/long to be
a KML ground overlay onto Google Maps, which I think I can handle.

But I am unsure if I need to extract the map image from the jpeg using
the NEATLINE?
How are the Corner Coordinates translated into a bounding box?

Any suggestions?


___
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] PDF--JPEG--KML. Confused about association between KML bounding box and PDF's neatline and corner coordinates.

2010-10-20 Thread Even Rouault
NEATLINE is only a concept of geospatial PDF encoded according to the OGC Best 
Practice. Adobe-style have only bbox. That could be turned into a pseudo 
neatline I guess.

Le mercredi 20 octobre 2010 19:26:36, Brent Fraser a écrit :
 Hmmm.  My PDF doesn't seem to have a neatline, only a MediaBox and two
 BBoxes...
 
 Brent
 
 On 10/20/2010 9:04 AM, Even Rouault wrote:
  You don't need to convince anyone to add new functionnality. It already
  exists ;-)
  
  See the -cutline option of gdalwarp. Basically you use the NEATLINE
  reported by gdalinfo as the CUTLINE (that was the sole purpose of
  reporting the NEATLINE by the way !)
  
  The easiest way is to make a simple CSV like this :
  
  foo,WKT
  bla,POLYGON(())
  
  and you paste the content of NEATLINE as the value of the WKT.
  
  and do a gdalwarp without reprojecting to crop (use -crop_to_cutline) to
  the neatline. Then you can do a 2nd gdalwarp to reproject to the target
  SRS.
  
  (if you want to do just one gdalwarp, you'll have to do ogr2ogr to
  reproject the cutline.csv into the target SRS)
  
  See http://gdal.org/gdalwarp.html and/or
  http://gdal.org/structGDALWarpOptions.html#0ed77f9917bb96c7a9aabd73d4d06e
  08
  
  Boris,
  
  Use gdalwarp to convert your jpeg to Geographic coordinates (I think
  
  it needs to be converted for KML anyways):
  
  gdalwarp -t_srs EPSG:4326 in.jpg out.jpg
  
  then use gdalinfo to get the corner coordinates.
  
  Currently the entire page of the PDF is rendered into the image.
  Perhaps we can convince Even to add an option to convert only the mapped
  area (or mask everything else?)
  
  Best Regards,
  Brent Fraser
  
  On 10/20/2010 8:07 AM, Boris Dev wrote:
  My objective is to make a KML ground overlay with a geospatial PDF map.
  
  Using GDAL's translate utility I have converted the PDF to a JPEG. The
  next step and problem for me is to write the text of the KML ground
  overlay, which requires a text of bounding box information like this:
  
  LatLonBox
  
north37.91904192681665/north
south37.46543388598137/south
east15.35832653742206/east
west14.60128369746704/west


rotation-0.1556640799496235/rotation
  
  /LatLonBox
  
  As GDAL's output, I saw that the entire PDF with legend, title, etc
  and not just the map image was converted.
  
  As GDAL's output, I also saw 2 parts of data that seem they are useful
  to match a bounding box to the map within the jpeg, but I cant figure
  out the puzzle of how to make this work? Can I get the bounding box of
  the entire PDF image with this information below?
  
  Corner Coordinates:
  Upper Left  (  666937.758, 2024687.983)
  Lower Left  (  666991.811, 2018338.153)
  Upper Right (  674511.276, 2024754.795)
  Lower Right (  674565.328, 2018404.965)
  Center  (  670751.543, 2021546.474)
  
  MDI key=NEATLINEPOLYGON ((672676.488065659650601
  2019417.955749646294862,672636.091432046378031
  2024030.267778463661671,667347.405745737953112
  2023983.612156898481771,667385.539170471020043
  2019370.524140953086317,672676.488065659650601
  2019417.955749646294862,672676.488065659650601
  2019417.955749646294862,672676.488065659650601
  2019417.955749646294862,672676.488065659650601
  2019417.955749646294862))/MDI
  
  I realize the coordinate above need to be converted to lat/long to be
  a KML ground overlay onto Google Maps, which I think I can handle.
  
  But I am unsure if I need to extract the map image from the jpeg using
  the NEATLINE?
  How are the Corner Coordinates translated into a bounding box?
  
  Any suggestions?
  
  
  ___
  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] DTED Elevations with Java and gdal

2010-10-20 Thread Corrado, George P.
Hey Even,

So I was messing around with one of the gdal examples that prints a lot of 
debug info, which is nice.  I found a thread where someone wanted to get 
elevation data at a certain point or pixel.  I think it was Frank who responded 
to it.  Anyway, I tried to follow along, and I think I'm in the right place in 
code.  I've got the dted file loaded, it has gone through this line without 
error:

returnVal = poBand.ReadRaster_Direct(0, 0, poBand.getXSize(), 
poBand.getYSize(), xsize, ysize, buf_type, data.slice());


and this bit of code:

short[][] shorts = new short[bandCount][];
for (int i = 0; i  bandCount; i++)
{
shorts[i] = new short[pixels];
bands[i].asShortBuffer().get(shorts[i]);
}
imgBuffer = new DataBufferShort(shorts, pixels);
buffer_type = DataBuffer.TYPE_USHORT;
sampleModel = new BandedSampleModel(buffer_type,
xsize, ysize, xsize, banks, offsets);
data_type = BufferedImage.TYPE_USHORT_GRAY;


does the imgBuffer or the sampleModel contain any elevation data for a given 
point?  Or do I have to get it from the Band class higher up in the code?  I 
think it would be cool to get all the pixel elevation data and then color each 
pixel according to elevation height.

I think this is the example I was working with:
http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/java/apps/GDALtest.java

I saw this piece of code when I was browsing around the threads, but wasn't 
sure what geo_x and geo_y should be or where they come from.

double[] test = poDataset.GetGeoTransform();
double pixel_x = (geo_x - test[0]) / test[1];
double pixel_y = (geo_y - test[3]) / test[5];


Sorry for all the questions and pasting code.
Thanks,
George
-Original Message-
From: Even Rouault [mailto:even.roua...@mines-paris.org] 
Sent: Tuesday, October 19, 2010 2:04 PM
To: gdal-dev@lists.osgeo.org
Cc: Corrado, George P.
Subject: Re: [gdal-dev] DTED Elevations with Java and gdal

George,

It's not appropriate to convert from DTED to PNG. See the warning of 
gdal_translate : DTED is signed 16 bits, but PNG can only support unsigned 16 
bits. So if you translate from DTED to PNG you'll lose the negative values 
(and in particular the nodata=-32767). I'm not sure why you want to convert 
your DTED file and not use it directly ? If you really don't want to read the 
DTED, convert to Geotiff instead

To do this with Java, see the Driver.CreateCopy() method :

http://gdal.org/java/org/gdal/gdal/Driver.html#CreateCopy(java.lang.String,
%20org.gdal.gdal.Dataset)

Best regards,

Even

Le mardi 19 octobre 2010 19:33:53, Corrado, George P. a écrit :
 Hello,
 
 Does anyone have a java example on how to get elevations from a .dt1 file. 
 My ultimate goal would be to take a .dt1, translate it to a png, and then
 feed the png into gdal to get elevations and coordinates.
 
 I ran the gdal_translate on one of my .dt1 files and came up with this. 
 Note: this is actually DTED2 even though the file ext is dt1.  Not sure
 why that is, maybe because it's really old.
 
 C:\jdk1.6.0_21\bingdal_translate -of PNG --config GDAL_CACHEMAX 30
 C:\DTED2\DTED\E032\N34.DT1 C:\DTED2\DTED\E032\N34.pn g
 Input file size is 3601, 3601
 Warning 6: PNG driver doesn't support data type Int16. Only eight bit
 (Byte) and sixteen bit (UInt16) bands supported. D efaulting to Byte
 
 0...10...20...30...40...50...60...70...80...90...100 - done.
 
 It created a png file along with an xml file.  I had to do this with the
 gdal_translate.exe file, but eventually I would like to use straight Java.
 
 Thanks,
 George
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] gdal_merge: stacking and band statistics

2010-10-20 Thread Matt Hanneman

 Hi,

Can anyone help a newbie? I have been trying to calculate statistics 
with gdal_merge when merging/stacking several tiffs together into a HFA 
format (see below for syntax). However, when loaded into ArcGIS it 
reports that there are no statistics calculated for any of the bands. 
Will the 'STATISTICS' option not work when stacking multiple bands? As 
you can probably tell I am fairly new to this, so forgive my ignorance.


gdal_merge -co STATISTICS=YES -v -o E:/Temp/A2E.img -of HFA -separate 
A.TIF B.TIF C.TIF D.TIF E.TIF F.TIF


Thanks,

Matt

--

*Matt Hanneman*
Director of GIS and Remote Sensing
Global Forest Watch Canada
10337 146 St, Edmonton, AB T5N 3A3
Tel: 780-422-5989 Fax: 780-454-5521
www.globalforestwatch.ca http://www.globalforestwatch.ca/

**

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

Re: [gdal-dev] gdal_merge: stacking and band statistics

2010-10-20 Thread Elijah Robison




Matt out of curiosity is this a new install of ArcGIS you're talking
about, maybe version 9.2? As I recall installs of 9.2 require a
service pack to calc raster stats. Otherwise, rasters show all black
when loaded, etc.

Elijah, 

VillaGIS, Inc.,
Branson, MO

Matt Hanneman wrote:

  
Hi,
  
Can anyone help a newbie? I have been trying to calculate statistics
with gdal_merge when merging/stacking several tiffs together into a HFA
format (see below for syntax). However, when loaded into ArcGIS it
reports that there are no statistics calculated for any of the bands.
Will the 'STATISTICS' option not work when stacking multiple bands? As
you can probably tell I am fairly new to this, so forgive my ignorance.
  
gdal_merge -co STATISTICS=YES -v -o "E:/Temp/A2E.img" -of HFA -separate
"A.TIF" "B.TIF" "C.TIF" "D.TIF" "E.TIF" "F.TIF"
  
Thanks,
  
Matt 
   
  -- 
  
  Matt Hanneman
  Director of
GIS and
Remote Sensing
Global Forest Watch Canada
10337 146 St, Edmonton, AB T5N 3A3
Tel: 780-422-5989 Fax: 780-454-5521 
  www.globalforestwatch.ca
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

___
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] gdal_merge: stacking and band statistics

2010-10-20 Thread Jason Roberts
Matt,

 

Although I have not worked with multi-band HFA format, I have experimented
fairly extensively with single-band, GDAL-produced, HFA-format files in
ArcGIS 9.3.1 SP1. Maybe my experience will be interesting to you anyway.

 

My experience was that calculating the statistics with GDAL and with ArcGIS
was not equivalent. For example, when I calculated the statistics with GDAL
for integer rasters, they did not show up with a random color classification
in ArcGIS by default. They appeared to use a black-to-white stretch instead.
This was not desirable for categorical data (e.g. landcover values). But if
I calculated the statistics using ArcGIS, they did show up with random
colors.

 

Unfortunately I did not take extensive notes on this, summarizing my
experience in my own code with this comment:

 

# Do not use GDAL to calculate statistics.

# Even though GDAL can do it faster than the geoprocessor, we

# prefer to use the geoprocessor to maximize the compatibility

# of the output raster with ArcGIS. For example, I do not know

# how to get GDAL to build an ArcGIS-compatible histogram.

# Without the histogram ArcGIS defaults to displaying integer

# rasters using a black-to-white stretch rather than a unique

# value classifier with random colors. ArcGIS users will

# expect colors; to get the necessary histogram, we have to

# calculate statistics with the geoprocessor.

 

I also recall there being some other differences, possibly with floating
point files, too. I'm sorry I did not take better notes.

 

I found the whole thing a bit bizarre because I thought that ArcGIS 9.3.1
used GDAL internally to manipulate HFA files. But maybe not in all
circumstances. And 9.3.1 has an ESRI-customized version of GDAL 1.4, so it
is not like they are running the latest GDAL code.

 

Anyway, hope this helps,

 

Jason

 

From: gdal-dev-boun...@lists.osgeo.org
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Matt Hanneman
Sent: Wednesday, October 20, 2010 4:51 PM
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] gdal_merge: stacking and band statistics

 

Hi,

Can anyone help a newbie? I have been trying to calculate statistics with
gdal_merge when merging/stacking several tiffs together into a HFA format
(see below for syntax). However, when loaded into ArcGIS it reports that
there are no statistics calculated for any of the bands. Will the
'STATISTICS' option not work when stacking multiple bands? As you can
probably tell I am fairly new to this, so forgive my ignorance.

gdal_merge -co STATISTICS=YES -v -o E:/Temp/A2E.img -of HFA -separate
A.TIF B.TIF C.TIF D.TIF E.TIF F.TIF

Thanks,

Matt 

 

-- 

Matt Hanneman
Director of GIS and Remote Sensing
Global Forest Watch Canada
10337 146 St, Edmonton, AB T5N 3A3
Tel: 780-422-5989 Fax: 780-454-5521 
www.globalforestwatch.ca http://www.globalforestwatch.ca/ 

 

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

Re: [gdal-dev] PDF--JPEG--KML. Confused about association between KML bounding box and PDF's neatline and corner coordinates.

2010-10-20 Thread Boris Dev
thanks..I am almost there...I think I am making a simple usage typo?

gdalwarp without the option '-t_srs EPSG:4326' works OK.

But it doesnt work with the command written exactly as you have it


 gdalwarp -t_srs EPSG:4326 in.jpg out.jpg


After that command, I do not get anything processed (it just outputs to the
screen the usage info).

I also had no luck with trying different variations of the -t_srs option
such as

gdalwarp -t_srs +proj=EPSG:4326 in.jpg out.jpg

I am using the most recent SVN GDAL.



  then use gdalinfo to get the corner coordinates.

 Currently the entire page of the PDF is rendered into the image.   Perhaps
 we can convince Even to add an option to convert only the mapped area (or
 mask everything else?)

 Best Regards,
 Brent Fraser


 On 10/20/2010 8:07 AM, Boris Dev wrote:

 My objective is to make a KML ground overlay with a geospatial PDF map.

 Using GDAL's translate utility I have converted the PDF to a JPEG. The next
 step and problem for me is to write the text of the KML ground overlay,
 which requires a text of bounding box information like this:

 LatLonBox
 north37.91904192681665/north
 south37.46543388598137/south
 east15.35832653742206/east
 west14.60128369746704/west


 rotation-0.1556640799496235/rotation
   /LatLonBox


 As GDAL's output, I saw that the entire PDF with legend, title, etc and not
 just the map image was converted.

 As GDAL's output, I also saw 2 parts of data that seem they are useful to
 match a bounding box to the map within the jpeg, but I cant figure out the
 puzzle of how to make this work? Can I get the bounding box of the entire
 PDF image with this information below?

 Corner Coordinates:
 Upper Left  (  666937.758, 2024687.983)
 Lower Left  (  666991.811, 2018338.153)
 Upper Right (  674511.276, 2024754.795)
 Lower Right (  674565.328, 2018404.965)
 Center  (  670751.543, 2021546.474)

 MDI key=NEATLINEPOLYGON ((672676.488065659650601
 2019417.955749646294862,672636.091432046378031
 2024030.267778463661671,667347.405745737953112
 2023983.612156898481771,667385.539170471020043
 2019370.524140953086317,672676.488065659650601
 2019417.955749646294862,672676.488065659650601
 2019417.955749646294862,672676.488065659650601
 2019417.955749646294862,672676.488065659650601
 2019417.955749646294862))/MDI

 I realize the coordinate above need to be converted to lat/long to be a KML
 ground overlay onto Google Maps, which I think I can handle.

 But I am unsure if I need to extract the map image from the jpeg using the
 NEATLINE?
 How are the Corner Coordinates translated into a bounding box?

 Any suggestions?


 ___
 gdal-dev mailing 
 listgdal-...@lists.osgeo.orghttp://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.UseExceptions() doesn't raise an exception on a non-existant dataset [SEC=UNCLASSIFIED]

2010-10-20 Thread Pinner, Luke
OGR doesn't raise an exception on attempting to open a non-existant
dataset even if ogr.UseExceptions() has been called, GDAL does though.
Is this intentional or a bug?
GDAL version = 1.7.2

from osgeo import gdal,ogr
gdal.UseExceptions()
ogr.UseExceptions()

ds=ogr.Open('foo')
#No exception raised by ogr

ds=gdal.Open('foo')
Traceback (most recent call last):
  File interactive input, line 1, in module
RuntimeError: `foo' does not exist in the file system,
and is not recognised as a supported dataset name.

Regards
Luke

If you have received this transmission in error please notify us immediately by 
return e-mail and delete all copies. If this e-mail or any attachments have 
been sent to you in error, that error does not constitute waiver of any 
confidentiality, privilege or copyright in respect of information in the e-mail 
or attachments.

Please consider the environment before printing this email.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


RE: [gdal-dev] gdaldem color-relief color_text_files

2010-10-20 Thread Mark Millman
Thanks, as you say this doesn't really solve my problem but it is a useful
tool, as was SpaceEyes3D Viewer color-relief editor.

In exploring my problem I've written some Java code to interpolate shades
within a color_text_file.  If you set up a color-text-file with color
differences at 1000 meter intervals, this code will fill in equally spaced
colors at 100m (or any increment you want) to produce a file with lots of
shades.  If anyone is interested I can provide the code for this.  If anyone
is interested in this let me know and I'll send you a copy.  

Mark

-Original Message-
From: gdal-dev-boun...@lists.osgeo.org
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of John Donovan
Sent: Tuesday, October 19, 2010 2:53 AM
To: gdal-dev@lists.osgeo.org
Subject: RE: [gdal-dev] gdaldem color-relief color_text_files

This isn't quite what you need, but for creating thematic colour
schemes, http://colorbrewer2.org/ is a rather neat tool. I suppose it
wouldn't be too much of a stretch to interpolate between the colours it
generates for a full 256 pallette.
 
-JD



From: gdal-dev-boun...@lists.osgeo.org
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Mark Millman
Sent: 15 October 2010 01:17
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] gdaldem color-relief color_text_files



I am in need of some color_text files to use with the gdaldem
color-relief utility to create color relief versions of Slope, Aspect,
Roughness, TRI,  TPI maps.  I seems to me that these ought to be pretty
standard and as my skill set is on the developer side rather than the
cartographer side of things I am hoping that some generous cartographer
out there has already created some eye candy quality color_text_files
for this purpose.

 

Thanks in advance.  Mark


__
This email has been scanned for Virtalis Ltd by the MessageLabs Email
Security System.
__


...
___
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