[gdal-dev] Spatial Reference syntax
Hello I'm reading a few examples of GDALWARP usage and I have a few questions regarding spatial reference syntax. Is there any Wiki explaining explaining coordinates systems definition to be passed to GDALWARP/other GDAL tool? Thanks ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] gdalwarp -t_srs problems
Hi, [yet another "funny" image problem. - yay] Using Ubuntu 9.10 Karmic with gdal 1.5.4-4 (I think - how can I check for sure? --help doesn't help) I've tried various -t_srs permutations trying to convert a tiff ortho from LATLONG to UTM34S but I keep ending up with PROJCS in the Northern hemisphere, even though the Corner Coordinates show a latitude in the South. The UTM coords are not in the expected value range, either. Note I am not using -s_srs as I am expecting that from the TIFF headers. gdalwarp -t_srs 'epsg:32734' 3319bc23.tif bc23.tif Notice the UTM zone, Central Meridian and False Northing in the target bc23.tif file. Here are gdalinfo outputs for the following 3 images: (Third being a reference image that is slightly East of the bc23 image) -rw-rw-r-- 1 1001 geograph 376 2010-02-20 17:43 3319bc23.IF -rw-rw-r-- 1 1001 geograph 118 2010-02-19 09:57 3319bc23.tfw -rw-rw-r-- 1 1001 geograph 158072320 2010-02-19 09:57 3319bc23.tif -rw-r--r-- 1 1001 geograph 295016802 2010-02-25 11:02 bc23.tif -rw-r--r-- 1 1001 geograph 355 2010-02-24 09:19 worcester.IF -rw-r--r-- 1 1001 geograph 207421516 2010-02-24 09:22 worcester.MR -rw-r--r-- 1 1001 geograph 585550792 2010-02-24 09:11 worcester.tif z...@gl1:/home/gisortho/t4a/breederivier$ gdalinfo 3319bc23.tif Driver: GTiff/GeoTIFF Files: 3319bc23.tif Size is 7259, 7256 Coordinate System is: GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.2572235629972, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4326"]] Origin = (19.598375571136735,-33.448385541900883) Pixel Size = (0.07335933852,-0.07335933852) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left ( 19.5983756, -33.4483855) ( 19d35'54.15"E, 33d26'54.19"S) Lower Left ( 19.5983756, -33.5016151) ( 19d35'54.15"E, 33d30'5.81"S) Upper Right ( 19.6516271, -33.4483855) ( 19d39'5.86"E, 33d26'54.19"S) Lower Right ( 19.6516271, -33.5016151) ( 19d39'5.86"E, 33d30'5.81"S) Center ( 19.6250013, -33.4750003) ( 19d37'30.00"E, 33d28'30.00"S) Band 1 Block=7259x1 Type=Byte, ColorInterp=Red Band 2 Block=7259x1 Type=Byte, ColorInterp=Green Band 3 Block=7259x1 Type=Byte, ColorInterp=Blue z...@gl1:/home/gisortho/t4a/breederivier$ z...@gl1:/home/gisortho/t4a/breederivier$ gdalinfo bc23.tif Driver: GTiff/GeoTIFF Files: bc23.tif Size is 9688, 10117 Coordinate System is: PROJCS["UTM Zone -34, Northern Hemisphere", GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.2572235629972, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4326"]], PROJECTION["Transverse_Mercator"], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",-387], PARAMETER["scale_factor",0.9996], PARAMETER["false_easting",50], PARAMETER["false_northing",0], UNIT["metre",1, AUTHORITY["EPSG","9001"]]] Origin = (4985652.260930398479104,-4864755.980756304226816) Pixel Size = (0.945609074139101,-0.945609074139101) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left ( 4985652.261,-4864755.981) ( 18d25'30.82"E, 33d43'5.31"S) Lower Left ( 4985652.261,-4874322.708) ( 18d26'54.45"E, 33d46'51.98"S) Upper Right ( 4994813.322,-4864755.981) ( 18d28'22.86"E, 33d41'23.95"S) Lower Right ( 4994813.322,-4874322.708) ( 18d29'45.37"E, 33d45'10.62"S) Center ( 4990232.791,-4869539.344) ( 18d27'38.64"E, 33d44'7.92"S) Band 1 Block=9688x1 Type=Byte, ColorInterp=Red Band 2 Block=9688x1 Type=Byte, ColorInterp=Green Band 3 Block=9688x1 Type=Byte, ColorInterp=Blue z...@gl1:/home/gisortho/t4a/breederivier$ Reference image: z...@gl1:/home/gisortho/t4a/breederivier$ gdalinfo worcester.tif Driver: GTiff/GeoTIFF Files: worcester.tif Size is 15556, 12545 Coordinate System is: PROJCS["WGS 84 / UTM zone 34S", GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.2572235629972, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4326"]], PROJECTION["Transverse_Mercator"], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",21], PARAMETER["scale_factor",0.9996], PARAMETER["false_easting",50], PARAMETER["false_northing",1000], UNIT["metre",1, AUTHORITY["EPSG","9001"]], AUTHORITY["EPSG","32734"]] Origin = (352199.486889008665457,628.033236353658140) Pixel Size = (0.597834417917855,-0.597834417917858) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left ( 352199.487, 628.033) ( 19d24'24.68"E, 33d36'34.29"S) Lower Left ( 352199.487, 6272500.200) ( 19d24'20.20"E, 33d40'37.72"S) Upper Right ( 361499.399, 628.033) ( 19d30'25.45"E, 33d36'38.79"S) Lower Right ( 361499.399, 6272500.200) ( 19d30'21.25"E, 33d40'42.23"S) Center ( 356849.443, 6276250.117) ( 19d27'22.89"E,
Re: [gdal-dev] Spatial Reference syntax
Luisa Peña wrote: I'm reading a few examples of GDALWARP usage and I have a few questions regarding spatial reference syntax. Is there any Wiki explaining explaining coordinates systems definition to be passed to GDALWARP/other GDAL tool? I've just been where you are now :-) I managed to work out something by looking at the gcs.csv and pcs.csv files, and at: http://www.gdal.org/gdalwarp.html and http://www.gdal.org/gdal_utilities.html HTH, Zoltan -- === Zoltan Szecsei Director Geograph (Pty) Ltd. P.O. Box 7, Muizenberg 7950, South Africa. 65 Main Road, Muizenberg 7945 Western Cape, South Africa. 34° 6'16.35S 18°28'5.62E Tel: +27-21-7884897 Mobile: +27-83-6004028 Fax: +27-86-6115323www.geograph.co.za === No virus found in this outgoing message. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2708 - Release Date: 02/24/10 21:34:00 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp -t_srs problems SOLVED
Zoltan Szecsei wrote: I've tried various -t_srs permutations trying to convert a tiff ortho from LATLONG to UTM34S but I keep ending up with PROJCS in the Northern hemisphere, even though the Corner Coordinates show a latitude in the South. The UTM coords are not in the expected value range, either. Note I am not using -s_srs as I am expecting that from the TIFF headers. gdalwarp -t_srs 'epsg:32734' 3319bc23.tif bc23.tif Notice the UTM zone, Central Meridian and False Northing in the target bc23.tif file. The reason for this problem is that the coordinates embedded in the source tif image are garbage. The image originates from a SID image, that is in Lo19 Gauss using Hartebeeshoek94 (epsg:2048) On export Lizardtech's GeoViewer defaults to LatLong. I was able to get the original SID SDW files for the image, and noticed that it's contents were Gauss values, so I re-exported the image from GeoViewer, forcing use of the world files, and now everything is hunkey-dorey. Thanks anyway. Kind regards, Zoltan -- === Zoltan Szecsei Director Geograph (Pty) Ltd. P.O. Box 7, Muizenberg 7950, South Africa. 65 Main Road, Muizenberg 7945 Western Cape, South Africa. 34 6'16.35"S 1828'5.62"E Tel: +27-21-7884897 Mobile: +27-83-6004028 Fax: +27-86-6115323www.geograph.co.za === No virus found in this outgoing message. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2708 - Release Date: 02/24/10 21:34:00 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] OGRSFDriverRegistrar question
Hi All, How can make OGRSFDriverRegistrar::Open fails when trying to open an ESRI Shapefile and the first parameter *pszName has extension different to shp*? I know when extension is different to shp, dbf and shx it fails, but I need that also fails when extension is dbf or shx. Any idea? Thanks in advance. Alejandro. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGRSFDriverRegistrar question
Alejandro Mostovoi wrote:
Hi All,
How can make OGRSFDriverRegistrar::Open fails when trying to open an
ESRI Shapefile and the first parameter /pszName has extension
different to shp/?
I know when extension is different to shp, dbf and shx it fails,
but I need that also fails when extension is dbf or shx.
Any idea?
Alejandro,
You could modify OGRShapeDataSource::Open() in
gdal/ogr/ogrsf_frmts/shape/ogrshapedatasource.cpp so that is checks this.
change:
if( VSI_ISREG(stat.st_mode) )
{
if( !OpenFile( pszNewName, bUpdate, bTestOpen ) )
to:
if( VSI_ISREG(stat.st_mode) )
{
if( !EQUAL(CPLGetExtension(pszNewName),shp)
|| !OpenFile( pszNewName, bUpdate, bTestOpen ) )
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
Re: [gdal-dev] gdal_proximmity.py
Vincent Honnet wrote: Hi, I'm trying to use gdal_proximity.py. through an installation of FWTools 2.4.5 or 2.4.6. The first thing is that there is, I think, a mistake at line 150: the variable dst_ts is wrong, it should dst_ds, then the exception of the try can set the right variable to None. My command line is: gdal_proximity.py T:\vincent\tmp\SwissBoarder.tif T:\vincent\tmp\test.tif -srcband 1 -of GTiff -values 255 -nodata 0 -distunits GEO -maxdist 100 that way, the result is: Traceback (most recent call last): File c:\FWTools2.4.5\bin\gdal_proximity.py, line 171, in ? gdal.ComputeProximity( srcband, dstband, options, AttributeError: 'module' object has no attribute 'ComputeProximity' Did someone use this command that way ? Is my command wrong ? Vincent, gdal_proximity requires the next generation python api. FWTools still distributes the old python bindings for OpenEV compatability. You will need to use a different environment like OSGeo4W's gdal-dev package. I have fixed the dst_ts thing in trunk now. 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
Re: [gdal-dev] OGRSFDriverRegistrar question
Ok.
Thanks.
Alejandro.
On 25 February 2010 11:57, Frank Warmerdam warmer...@pobox.com wrote:
Alejandro Mostovoi wrote:
Hi All,
How can make OGRSFDriverRegistrar::Open fails when trying to open an
ESRI Shapefile and the first parameter /pszName has extension
different to shp/?
I know when extension is different to shp, dbf and shx it fails,
but I need that also fails when extension is dbf or shx.
Any idea?
Alejandro,
You could modify OGRShapeDataSource::Open() in
gdal/ogr/ogrsf_frmts/shape/ogrshapedatasource.cpp so that is checks this.
change:
if( VSI_ISREG(stat.st_mode) )
{
if( !OpenFile( pszNewName, bUpdate, bTestOpen ) )
to:
if( VSI_ISREG(stat.st_mode) )
{
if( !EQUAL(CPLGetExtension(pszNewName),shp)
|| !OpenFile( pszNewName, bUpdate, bTestOpen ) )
Best regards,
--
---+--
I set the clouds in motion - turn up | Frank Warmerdam,
warmer...@pobox.com
light and sound - activate the windows |
http://pobox.com/~warmerdamhttp://pobox.com/%7Ewarmerdam
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
Re: [gdal-dev] Converting JP2 to GeoTIFF
Zoltan,
I tested the data provided by you. I was able to open it with GDAL using the
MrSID driver with no problem.
Can you give the details of GDAL version you are using and the output of the
command gdalinfo --formats?
On Wed, Feb 24, 2010 at 8:19 PM, Zoltan Szecsei zolt...@geograph.co.zawrote:
Herewith .
Thank you,
Regards,
Zoltan
Chaitanya kumar CH wrote:
Zoltan,
Can you provide a sample dataset that raised this error?
On Wed, Feb 24, 2010 at 8:05 PM, Zoltan Szecsei zolt...@geograph.co.zawrote:
Hi,
I'm trying to convert a jpeg2000 image to a geotiff, but I keep getting a
segmentation fault. Please can someone point me in the direction of a
solution.
Thanks in advance,
Zoltan.
**
z...@gl1:/mnt/gm0_sdd1/gisortho/t4a/breederivier$ gdal_translate trvr.jp2
trvr.tif
Segmentation fault
**
z...@gl1:/mnt/gm0_sdd1/gisortho/t4a/breederivier$ gdalinfo trvr.jp2
Segmentation fault
**
z...@gl1:/mnt/gm0_sdd1/gisortho/t4a/breederivier$ ls -la trvr.*
-rwxr-xr-x 1 1001 geograph151 2010-02-24 16:01 trvr.j2w
-rwxr-xr-x 1 1001 geograph4031979 2010-02-24 16:01 trvr.jp2
-rwxr-xr-x 1 1001 geograph417 2010-02-24 16:01 trvr.prj
**
$ cat trvr.prj
PROJCS[UTM Zone 34, Southern Hemisphere,GEOGCS[Geographic Coordinate
System,DATUM[WGS84,SPHEROID[WGS84,6378137,298.257223560493]],PRIMEM[Greenwich,0],UNIT[degree,0.0174532925199433]],PROJECTION[Transverse_Mercator],PARAMETER[latitude_of_origin,0],PARAMETER[central_meridian,21],PARAMETER[scale_factor,0.9996],PARAMETER[false_easting,50],PARAMETER[false_northing,1000],UNIT[Meter,1]]
**
z...@gl1:/mnt/gm0_sdd1/gisortho/t4a/breederivier$ cat trvr.j2w
1.0
0.0
0.0
-1.0
408298.9098975249800
6312778.315788120
**
z...@gl1:/mnt/gm0_sdd1/gisortho/t4a/breederivier$ gdal_translate
Usage: gdal_translate [--help-general]
[-ot {Byte/Int16/UInt16/UInt32/Int32/Float32/Float64/
CInt16/CInt32/CFloat32/CFloat64}] [-strict]
[-of format] [-b band] [-outsize xsize[%] ysize[%]]
[-scale [src_min src_max [dst_min dst_max]]]
[-srcwin xoff yoff xsize ysize] [-projwin ulx uly lrx lry]
[-a_srs srs_def] [-a_ullr ulx uly lrx lry] [-a_nodata value]
[-gcp pixel line easting northing [elevation]]*
[-mo META-TAG=VALUE]* [-quiet] [-sds]
[-co NAME=VALUE]*
src_dataset dst_dataset
GDAL 1.5.4, released 2009/01/07
The following format drivers are configured and support output:
VRT: Virtual Raster
etc etc
--
===
Zoltan Szecsei
Director
Geograph (Pty) Ltd.
P.O. Box 7, Muizenberg 7950, South Africa.
65 Main Road, Muizenberg 7945
Western Cape, South Africa.
34° 6'16.35S 18°28'5.62E
Tel: +27-21-7884897 Mobile: +27-83-6004028
Fax: +27-86-6115323www.geograph.co.za
===
No virus found in this outgoing message.
Checked by AVG - www.avg.com
Version: 9.0.733 / Virus Database: 271.1.1/2706 - Release Date: 02/23/10
21:34:00
___
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-9848167848
17.241582N 80.142635E
--
===
Zoltan Szecsei
Director
Geograph (Pty) Ltd.
P.O. Box 7, Muizenberg 7950, South Africa.
65 Main Road, Muizenberg 7945
Western Cape, South Africa.
34° 6'16.35S 18°28'5.62E
Tel: +27-21-7884897 Mobile: +27-83-6004028
Fax: +27-86-6115323www.geograph.co.za
===
1.0
0.0
0.0
-1.0
408298.9098975249800
6312778.315788120
PROJCS[UTM Zone 34, Southern Hemisphere,GEOGCS[Geographic Coordinate
System,DATUM[WGS84,SPHEROID[WGS84,6378137,298.257223560493]],PRIMEM[Greenwich,0],UNIT[degree,0.0174532925199433]],PROJECTION[Transverse_Mercator],PARAMETER[latitude_of_origin,0],PARAMETER[central_meridian,21],PARAMETER[scale_factor,0.9996],PARAMETER[false_easting,50],PARAMETER[false_northing,1000],UNIT[Meter,1]]
No virus found in this outgoing message.
Checked by AVG - www.avg.com
Version: 9.0.733 / Virus Database: 271.1.1/2706 - Release Date: 02/23/10
21:34:00
--
Best regards,
Chaitanya kumar CH.
/tʃaɪθənjə/ /kʊmɑr/
+91-9848167848
17.241582N
Re: [gdal-dev] Converting JP2 to GeoTIFF
Hi Chaitanya, Thanks for looking. I did look at the jp2 image in vi, but only saw ER Mapper ECW in the gibberish, not MrSID. Now that you hilited that, I have opened the JP2 in GeoViewer and successfully exported to TIFF. I have provided the gdalinfo output for this resulting tiff image, for your interest - I have also provided your requested info so that you may use it to improve gdal, or tell me to upgrade :-) Thanks for your efforts. Kind regards, Zoltan. (home-time for me now :-) ) *** -rwxr-xr-x 1 1001 geograph 151 2010-02-24 16:01 trvr.j2w -rwxr-xr-x 1 1001 geograph 4031979 2010-02-24 16:01 trvr.jp2 -rwxr-xr-x 1 1001 geograph 417 2010-02-24 16:01 trvr.prj -rwxr-xr-x 1 1001 geograph 126 2010-02-25 18:23 trvr.tfw -rwxr-xr-x 1 1001 geograph 35837170 2010-02-25 18:23 trvr.tif *** z...@gl1:/mnt/gm0_sdd1/gisortho/t4a/breederivier$ gdalinfo trvr.jp2 Segmentation fault *** z...@gl1:/mnt/gm0_sdd1/gisortho/t4a/breederivier$ gdalinfo trvr.tif Driver: GTiff/GeoTIFF Files: trvr.tif Size is 3243, 3682 Coordinate System is: LOCAL_CS["unnamed", UNIT["unknown",1]] Origin = (408298.409897524979897,6312778.815788120031357) Pixel Size = (1.000,-1.000) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left ( 408298.410, 6312778.816) Lower Left ( 408298.410, 6309096.816) Upper Right ( 411541.410, 6312778.816) Lower Right ( 411541.410, 6309096.816) Center ( 409919.910, 6310937.816) Band 1 Block=3243x2 Type=Byte, ColorInterp=Red Band 2 Block=3243x2 Type=Byte, ColorInterp=Green Band 3 Block=3243x2 Type=Byte, ColorInterp=Blue z...@gl1:/mnt/gm0_sdd1/gisortho/t4a/breederivier$ z...@gl1:/mnt/gm0_sdd1/gisortho/t4a/breederivier$ z...@gl1:/mnt/gm0_sdd1/gisortho/t4a/breederivier$ z...@gl1:/mnt/gm0_sdd1/gisortho/t4a/breederivier$ cat trvr.tfw 1.000 0.000 0.000 -1.000 408298.90989752498 6312778.31578812000 z...@gl1:/mnt/gm0_sdd1/gisortho/t4a/breederivier$ *** z...@gl1:~$ gdalinfo --version GDAL 1.5.4, released 2009/01/07 *** z...@gl1:~$ gdalinfo --formats Supported Formats: VRT (rw+): Virtual Raster GTiff (rw+): GeoTIFF NITF (rw+): National Imagery Transmission Format RPFTOC (ro): Raster Product Format TOC format HFA (rw+): Erdas Imagine Images (.img) SAR_CEOS (ro): CEOS SAR Image CEOS (ro): CEOS Image JAXAPALSAR (ro): JAXA PALSAR Product Reader (Level 1.1/1.5) GFF (ro): Ground-based SAR Applications Testbed File Format (.gff) ELAS (rw+): ELAS AIG (ro): Arc/Info Binary Grid AAIGrid (rw): Arc/Info ASCII Grid SDTS (ro): SDTS Raster OGDI (ro): OGDI Bridge DTED (rw): DTED Elevation Raster PNG (rw): Portable Network Graphics JPEG (rw): JPEG JFIF MEM (rw+): In Memory Raster JDEM (ro): Japanese DEM (.mem) GIF (rw): Graphics Interchange Format (.gif) ESAT (ro): Envisat Image Format BSB (ro): Maptech BSB Nautical Charts XPM (rw): X11 PixMap Format BMP (rw+): MS Windows Device Independent Bitmap DIMAP (ro): SPOT DIMAP AirSAR (ro): AirSAR Polarimetric Image RS2 (ro): RadarSat 2 XML Product PCIDSK (rw+): PCIDSK Database File PCRaster (rw): PCRaster Raster File ILWIS (rw+): ILWIS Raster Map SGI (ro): SGI Image File Format 1.0 SRTMHGT (rw): SRTMHGT File Format Leveller (rw+): Leveller heightfield Terragen (rw+): Terragen heightfield GMT (rw): GMT NetCDF Grid Format netCDF (rw): Network Common Data Format HDF4 (ro): Hierarchical Data Format Release 4 HDF4Image (rw+): HDF4 Dataset PNM (rw+): Portable Pixmap Format (netpbm) DOQ1 (ro): USGS DOQ (Old Style) DOQ2 (ro): USGS DOQ (New Style) ENVI (rw+): ENVI .hdr Labelled EHdr (rw+): ESRI .hdr Labelled GenBin (ro): Generic Binary (.hdr Labelled) PAux (rw+): PCI .aux Labelled MFF (rw+): Vexcel MFF Raster MFF2 (rw+): Vexcel MFF2 (HKV) Raster FujiBAS (ro): Fuji BAS Scanner Image GSC (ro): GSC Geogrid FAST (ro): EOSAT FAST Format BT (rw+): VTP .bt (Binary Terrain) 1.3 Format LAN (ro): Erdas .LAN/.GIS CPG (ro): Convair PolGASP IDA (rw+): Image Data and Analysis NDF (ro): NLAPS Data Format DIPEx (ro): DIPEx ISIS3 (ro): USGS Astrogeology ISIS cube (Version 3) ISIS2 (ro): USGS Astrogeology ISIS cube (Version 2) PDS (ro): NASA Planetary Data System ERS (rw+): ERMapper .ers Labelled JPEG2000 (rw): JPEG-2000 part 1 (ISO/IEC 15444-1) L1B (ro): NOAA Polar Orbiter Level 1b Data Set FIT (rw): FIT Image RMF (rw+): Raster Matrix Format WCS (ro): OGC Web Coverage Service
[gdal-dev] make install -- copy shapefil.h into the include dir
Hi, I have a MEX that links against shapelib and works fine. However, I just tried to link it against GDAL since it has the same ability to read shapefiles in OGR and it also works. All I had to do was to copy the shapefil.h from ...\gdal\ogr\ogrsf_frmts\shape to ...\gdal\include so can I ask as a kind of enhancement request that the shapefil.h be moved to the include dir by the make install procedure so that for the next GDAL release I can have my makefiles link that MEX to GDAL only and therefore drop the need of having also a shapelib instaled? Thanks Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] make install -- copy shapefil.h into the include dir
Joaquim, I'm not sure this is a good idea. Shapelib and its header file is an internal dependency of GDAL/OGR and should probably remain as such. I'd note we made recently necessary changes to some utilities (gdaltindex comes to mind) to use OGR API and drop their explicit dependency to shapelib. I'd note that, in some builds of GDAL, shapelib symbols embedded in the Shapefile driver could even not be exported (for example if configure is run with --with-hide-internal-symbols) Le Thursday 25 February 2010 17:49:23 Joaquim Luis, vous avez écrit : Hi, I have a MEX that links against shapelib and works fine. However, I just tried to link it against GDAL since it has the same ability to read shapefiles in OGR and it also works. All I had to do was to copy the shapefil.h from ...\gdal\ogr\ogrsf_frmts\shape to ...\gdal\include so can I ask as a kind of enhancement request that the shapefil.h be moved to the include dir by the make install procedure so that for the next GDAL release I can have my makefiles link that MEX to GDAL only and therefore drop the need of having also a shapelib instaled? Thanks Joaquim Luis ___ 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] gdal_translate with -a_srs option using proj4 syntax and +a=ellipsoid
Hi all,
I have a tiff image that has been exported from meteorological software
that has know geographic parameters:
ELLIPSOID_EQUATOR_RADIUS6378206.5
ELLIPSOID_POLAR_RADIUS 6356584
ELLIPSOID_FLATTENING0.00339
UPPER_LEFT_X-3507992.25
UPPER_LEFT_Y6780696
LOWER_RIGHT_X 3601343.75
LOWER_RIGHT_Y 2337361
PROJECTION_TYPE Mercator
CENTER_LONGITUDE_MERCATOR_SPECIFIC -96
CENTER_LATITUDE 37.910004
CENTER_LONGITUDE-95.580002
ROTATION0
I am trying to convert this to a geotiff with my eventual goal of
converting it to an unprojected tiff.
First step is to add the geographic information to the tiff:
gdal_translate -a_ullr -3507992.25 6780696 3601343.75 2337361-a_srs
+proj=merc +lon_0=96w +a=6378206.5 +f=0.00339 src_image.tiff
dest_image.tiff
The failure I get is:
Failed to process SRS definition: +proj=merc +lon_0=96w +a=6378206.5
+f=0.00339
My second attempt was the try the same above command except with a proj
string that does not include the +a or +f options
But instead +proj=merc +lon_0=96w +datum=WGS84. This did work.
The problem I am now having is that I bring this image into ArcInfo and
for some reason it is shifted north. I think that being able to
correctly apply the ellipsoid equator radius and ellipsoid flattening
may fix my problem or am I missing something?
The second step is to create an un-projected image from this data:
My presumption is the below command will accomplish
Just that:
gdalwarp -t_srs '+proj=latlong' -r ${sample_method} ${tmp_image_3}
${final_image
Any help is fully appreciated.
Thanks,
Bill
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGRSFDriverRegistrar question
Alejandro Mostovoi wrote: Hi All, How can make OGRSFDriverRegistrar::Open fails when trying to open an ESRI Shapefile and the first parameter /pszName has extension different to shp/? I know when extension is different to shp, dbf and shx it fails, but I need that also fails when extension is dbf or shx. Any idea? Requirements and customizations of this kind are responsibility of a client, so cope with it in your application. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] make install -- copy shapefil.h into the include dir
Even, Thanks for the feedback. I think I understand what you mean but on the other hand I got puzzled as well. Glad that my memory is not too rotten with age as I remember one of your mails that ended up as ticket #1810 http://trac.osgeo.org/gdal/ticket/1810 where you explained that (and this is my interpretation of it), on Windows the --with-hide-internal-symbols behavior is the default one. But I'm testing on Windows and it worked fine with the link to gdal_i.lib. If it works here, why should it fail on *nix? Joaquim Joaquim, I'm not sure this is a good idea. Shapelib and its header file is an internal dependency of GDAL/OGR and should probably remain as such. I'd note we made recently necessary changes to some utilities (gdaltindex comes to mind) to use OGR API and drop their explicit dependency to shapelib. I'd note that, in some builds of GDAL, shapelib symbols embedded in the Shapefile driver could even not be exported (for example if configure is run with --with-hide-internal-symbols) Le Thursday 25 February 2010 17:49:23 Joaquim Luis, vous avez écrit : Hi, I have a MEX that links against shapelib and works fine. However, I just tried to link it against GDAL since it has the same ability to read shapefiles in OGR and it also works. All I had to do was to copy the shapefil.h from ...\gdal\ogr\ogrsf_frmts\shape to ...\gdal\include so can I ask as a kind of enhancement request that the shapefil.h be moved to the include dir by the make install procedure so that for the next GDAL release I can have my makefiles link that MEX to GDAL only and therefore drop the need of having also a shapelib instaled? Thanks Joaquim Luis ___ 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] make install -- copy shapefil.h into the include dir
I didn't check for that particular case, but yes, they are indeed exported. Is it by design or just because it is like it is ? I don't know... ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] raster to polygon
Hi, Currently, I'm using gdal and ogr to convert a map after classification into a point shape file. Since the classification map typically consists of zones, a polygon shape file would make more sense. I'm wondering if anyone would know or share the idea of how to convert a map into a polygon shape file directly. Thanks Xiaodong ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: Motion: Commit Access for Adam Nowacki
I agree with the RFC 3: GDAL Commiter Guildlines. Even Rouault wrote: Motion: Extend GDAL/OGR Commit Access to Adam Nowacki. --- Hi, Adam is the author of the GDAL WMS driver, that he contributed during the 2007 Google Summer of Code. Since then, he has regularly taken part to discussions related to the driver and contributes patches, such as in : http://trac.osgeo.org/gdal/ticket/3224 http://trac.osgeo.org/gdal/ticket/2750 http://trac.osgeo.org/gdal/ticket/2646 http://trac.osgeo.org/gdal/ticket/3420 Adam is also using GDAL heavily in the context of his professionnal activities. It would be convenient to give him direct commit access to subversion. Adam, could you reply to this message indicating your agreement to the guidelines listed in: http://trac.osgeo.org/gdal/wiki/rfc3_commiters I'll start voting with my support: +1 Best regards, ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Possible bug in gdaldem color-relief, zero always transparent
Le Friday 26 February 2010 00:13:22 Matt Williamson, vous avez écrit :
Ok, got some clarification.
The _real_ problem was that my dataset did not have it's NODATA value set
properly. That being the case, gdaldem apparently assumes 0 is the NODATA
value...sort of...if you have an nv line in the color table, perhaps.
Since I had a nv line in my color table, it seems that the setting for 0
and the setting for nv were conflicting. The result was still rather odd,
so I might still toss this in the bug tracker and see what you guys think
of the behavior.
Yes, please do. While reviewing the code, it appears that in the case 'nv' is
defined but there's no NODATA value defined for the dataset, it is wrongly
interprated as 0. I agree it should be ignored in that case. So you ended up
with 2 entries in the color file with the same key, which leaks to an
undefined behaviour for which entry will be used.
I tried removing the nv entry from the color table, and the results were
perfectly sensible. Removing the explicit zero entry and leaving the nv
setting produced strange results...it seems that in this case, the value
for zero gets set to black with the opacity of the nv entry, unless the nv
entry has opacity 255, in which case the zero value is the color specified
for nv.
It's probably one of those cases where if you have a nv entry specified for
a dataset without a NODATA value, then the behavior is undefined...which is
fine, but it took me a while to figure out what the heck was going on.
What's really strange to me though is that the actual NODATA pixels
(-3, in this case) also seemed to be taking on the nv color settings,
correctly, even though no NODATA value was set...a fluke probably, but
whatever.
On a separate note, the reason I had a file with no NODATA value specified
was that I expected gdalwarp to pass-through the NODATA value from the
source file if none of the -*nodata switches were present--but it doesn't.
I can mostly understand this, but it's somewhat counterintuitive since
gdal_translate works this way.
-srcnodata should not been needed. If not specified, gdalwarp will use the
nodata value of the source bands.
But currently, you need to specify -dstnodata. I guess the reason is
historical / backward compatibility with behaviour of previous versions of
gdalwarp.
Also, I am forced to specify a value for
-dstnodata to get it to work--but as it happens I'm trying to process
multiple files in batch, which have different output data types, and
different source NODATA values...is there a way to have gdalwarp
passthrough the NODATA value from the source to the destination file
automatically?
If you're on Unix/Linux, use of usual command line utilities should do it :
NODATA_VAL=$(gdalinfo in.tif | grep NoData Value | awk '{print $2}' |
awk -F '=' '{print $2}')
if $NODATA_VAL != ; then
gdalwarp -dstnodata $NODATA_VAL in.tif out.tif
else
gdalwarp in.tif out.tif
fi
But this could be worth an enhancement ticket. I'd imagine something
like gdalwarp -dstnodata source src.tif dst.tif to use the source nodata
values as dest nodata values.
Thanks again,
-Matt
On Feb 23, 2010, at 3:55 PM, Even Rouault wrote:
Hum, then I have no clue. Yes I tested with a dataset with zeros.
You can file a ticket on Trac with the dataset and the .clr file
attached, provided that the dataset is not too big (no more than 1 MB).
Otherwise, you'll have to provide a link to the dataset.
Le Tuesday 23 February 2010 22:26:44 Matt Williamson, vous avez écrit :
Hmm! Thanks, that is definitely not something I would have
checked--However, I don't think it's my problem. I checked my .clr file
I'm running, and I don't see anything out of the ordinary:
$ xxd T_SFC.clr
000: 2d34 302e 3020 2031 3237 2032 3535 2032 -40.0 127 255 2
010: 3535 0a2d 3330 2e31 2020 3139 3220 3235 55.-30.1 192 25
...
070: 320a 2d31 302e 3020 2020 3634 2020 3634 2.-10.0 64 64
080: 2020 3634 0a2d 302e 3120 2020 3132 372064.-0.1 127
090: 3132 3720 3132 3720 3235 350a 3020 2020 127 127 255.0
0a0: 2020 2020 3634 2020 3634 2031 3237 2032 64 64 127 2
0b0: 3535 0a30 2e31 2020 2020 2036 3420 2036 55.0.1 64 6
0c0: 3420 3132 3720 3235 350a 392e 3920 2020 4 127 255.9.9
...
You ran it on a dataset with zeroes? Everything works properly for me
except the zero values in the source GeoTIFF--everything else is colored
as expected, with the correct alpha values.
In fact (I probably should have mentioned this), when I first noticed
the problem, I did not have the 0.1 value line in there, and it was
actually interpolating the alpha from 0-255 between the values 0 and 9.9
(i.e. it got progressively more opaque between those values).
Also, FWIW, I encountered this issue under 1.7.0 and upgraded to 1.7.1
to make sure it wasn't a bug fixed in .1, but no, it does it in both
versions.
[gdal-dev] Querying Field Names
Hi, I'm using Python to do some work with shape files, with GDAL/OGR, although I am not particularly experienced in GIS programming (so I apologise for any incorrect terminology, etc.). What I need to do is retrieve the list of field names in the shape file; fields can be queried by name or row number, surely the field names can be listed? (Then I can query the field given that I know the field name)... I have searched the documentation quite thoroughly with no luck.. Perhaps my terminology is incorrect? Using QGIS to bring up the attribute table shows (for example): IDStreet_Add Road_Locat Title 1143 1 Lake Place Ilam Smith, C. J. 2144 3 Tower Road Riccarton Townshend, P. 3145 7 Lake Place Ilam Morrison, J. 4146 9 Harper Court Ilam Doe, J. 5147 11 Tower Road South Ricc Black, F. I need to find what field names are available; e.g. ID, Street_Add, Road_Locat, Title... Thanks in advance, Stacy -- View this message in context: http://n2.nabble.com/Querying-Field-Names-tp4636867p4636867.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] raster to polygon
Xiaodong, Have you tried the gdal_polygonize.py script ( http://www.gdal.org/gdal_polygonize.html)? Since your raster is classified, this should work nicely. On Fri, Feb 26, 2010 at 3:38 AM, Xiaodong Zhang xiaodong.zha...@und.eduwrote: Hi, Currently, I'm using gdal and ogr to convert a map after classification into a point shape file. Since the classification map typically consists of zones, a polygon shape file would make more sense. I'm wondering if anyone would know or share the idea of how to convert a map into a polygon shape file directly. Thanks Xiaodong ___ 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-9848167848 17.241582N 80.142635E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Querying Field Names
Stacy, This should help: http://trac.osgeo.org/gdal/browser/trunk/autotest/ogr/ogr_shape.py#L1384 On Fri, Feb 26, 2010 at 8:25 AM, Livingstone stakk_...@hotmail.com wrote: Hi, I'm using Python to do some work with shape files, with GDAL/OGR, although I am not particularly experienced in GIS programming (so I apologise for any incorrect terminology, etc.). What I need to do is retrieve the list of field names in the shape file; fields can be queried by name or row number, surely the field names can be listed? (Then I can query the field given that I know the field name)... I have searched the documentation quite thoroughly with no luck.. Perhaps my terminology is incorrect? Using QGIS to bring up the attribute table shows (for example): IDStreet_Add Road_Locat Title 1143 1 Lake Place Ilam Smith, C. J. 2144 3 Tower Road Riccarton Townshend, P. 3145 7 Lake Place Ilam Morrison, J. 4146 9 Harper Court Ilam Doe, J. 5147 11 Tower Road South Ricc Black, F. I need to find what field names are available; e.g. ID, Street_Add, Road_Locat, Title... Thanks in advance, Stacy -- View this message in context: http://n2.nabble.com/Querying-Field-Names-tp4636867p4636867.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 -- Best regards, Chaitanya kumar CH. /tʃaɪθənjə/ /kʊmɑr/ +91-9848167848 17.241582N 80.142635E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] RE: Simple Q: fatal error LNK1120: 19 unresolved externals
Thank you very much Sjur for the detailed respond. Now I'm getting only error LNK2001: unresolved external symbol _main error LNK1120: 1 unresolved externals By the way Sjur, have you ever thought of making some video tutorials and posting them on youtube? I always find them very useful and they are easy to find... -- View this message in context: http://n2.nabble.com/Simple-Q-fatal-error-LNK1120-19-unresolved-externals-tp4577872p4637053.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
