[gdal-dev] [suggestions] easing the search for information in the GDAL documentation
Hello, On the following page http://www.gdal.org/ogr/ogr_formats.html OGR Vector Formats you should add a mention : "The following page only describes OGR vector formats. For GDAL Raster Formats, see : http://www.gdal.org/formats_list.html " You should add a version number and last date of the revision at the end, as in the page http://www.gdal.org/formats_list.html In the page http://www.gdal.org/formats_list.html you should add a mention : "The following page only describes GDAL Raster Formats. For OGR vector formats, see : http://www.gdal.org/ogr/ogr_formats.html " At the end of the page, it would be much more human friendly to mention : Last revision : 25150 Last revision date : 2012-10-17 instead of : > 25150 2012-10-17 Yours sincerely, PS Is it possible to manage a CMS documentation instead of these HTML files ? (a User-friendly User Oriented Documentation) Would it be the role of the wiki documentation ? (I mean : I am not interested to find 63 different results when I type a search for "Supported Formats" : http://trac.osgeo.org/gdal/search?q=Supported+Formats&noquickjump=1&ticket=on&changeset=on&milestone=on&wiki=on ) ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Georeferencing problem
Nitasha, I see that all the GCPs have the same value '70.2958709253187'. Correct your GCPs and try again. On Fri, Oct 19, 2012 at 1:04 PM, wrote: > Hello Sir , > I am new to GIS and I am trying to georeference a image( 15min X 15min > multispectral image) using gdal.The process that I am following is as > follows : > > 1. First i am using gdal-translate with -gcp & -a-srs epsg ; > > gdal_translate -gcp 750.473430004334 3070.53287635397 70.2958709253187 > 27.9375281361964 -gcp 4057.56191915846 4036.62967261977 70.2958709253187 > 27.9964718881037 -gcp 3695.42969944292 1084.49720804115 70.2958709253187 > 27.8162786236328 -gcp 18.5158756347083 88.546174354395 70.2958709253187 > 27.7554467555991 -gcp 2114.46778195322 2068.47766007366 70.2958709253187 > 27.8762596874124 -a_srs epsg:4326 "InputImg.tif" "OutputImg.tif" > > 2. Then I am using gdalwarp with -r option : > > gdalwarp -r Bilinear "outputImg.tif" "GeorefImg.tif" > > > But I am getting an error "failed to compute gcp transform transform is > not solvable" > > Also, please tell me if I am using correct method to georeference a image. > Please help me, I am badly struck with this problem from many days. > > > Thanks > -- Best regards, Chaitanya kumar CH. +91-9494447584 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] dotspatial map control navigation
Hi I am developing an application which has dotspatial map control do display S57 dataset. Here it is displaying fine but I have to write a code where user should be navigated to particular coordinates when clicking and RCID(it has coordinate information). If you have worked on similar type of thing do share me some idea. Thanks and Regards Nikhil Sai Parupalli Note: Do not print this email until and unless it is really required. Save paper , stay Green ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] dotspatial map control navigation
Nikhil, You should ask the dotspatial community on how to perform the pan/zoom operations. To select a feature with a particular RCID, you can set an attribute filter on that particular layer and request the next feature. Since the RCID value is unique, you will get the only feature. You have to read the geometry in that feature and then zoom/pan to that location. On Fri, Oct 19, 2012 at 3:20 PM, Nikhil Sai Parupalli < nikhil.parupa...@iictechnologies.com> wrote: > Hi > > I am developing an application which has dotspatial map control do > display S57 dataset. > Here it is displaying fine but I have to write a code where user should be > navigated to particular coordinates when clicking and RCID(it has > coordinate information). > If you have worked on similar type of thing do share me some idea. > > > > Thanks and Regards > Nikhil Sai Parupalli > > > > Note: Do not print this email until and unless it is really required. > Save paper , stay Green > -- Best regards, Chaitanya kumar CH. +91-9494447584 17.2416N 80.1426E ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] convert ENVI format dsm into Mesh
Hi all, I have a raw DSM in ENVI format and i was wondering if there is a way to select a patch or region out of it and convert it into a polygon mesh. Does GDAL support this? Regards, ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Problem using image bands
Hello! I have a problem reading an ECW image. I want to read the image using only the first band. So I use: int bmap[3] = {1,1,1}; GDALImage->RasterIO( GF_Read, x, // int nXOff, y, // int nYOff, dx, // int nXSize, dy, // int nXSize, buffer, // void* pData, xBufSize, // int nBufXSize, yBufSize, // int nBufYSize, GDT_Byte, // GDALDataType eBufType, 3, // int nBandCount, bmap, // int* panBandMap, 3, // int nPixelSpace, xBufSize * 3, // int nLineSpace, 1 // int nBandSpace ); This is working well with some ECW images (they show as grayscale) but it does not with another, big ECW. It shows in full RGB color, exactly the same as if I had written int bmap[3] = {1,2,3}; Any idea? Thanks in advance! -- View this message in context: http://osgeo-org.1560.n6.nabble.com/Problem-using-image-bands-tp5009873.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] Problem using image bands
Selon jcurru : > Hello! > > I have a problem reading an ECW image. I want to read the image using only > the first band. So I use: > int bmap[3] = {1,1,1}; > GDALImage->RasterIO( > GF_Read, > x, // int nXOff, > y, // int nYOff, > dx, // int nXSize, > dy, // int nXSize, > buffer, // void* pData, > xBufSize, // int nBufXSize, > yBufSize, // int nBufYSize, > GDT_Byte, // GDALDataType eBufType, > 3, // int nBandCount, > bmap, // int* panBandMap, > 3, // int nPixelSpace, > xBufSize * 3, // int nLineSpace, > 1 // int nBandSpace > ); > This is working well with some ECW images (they show as grayscale) but it > does not with another, big ECW. It shows in full RGB color, exactly the same > as if I had written int bmap[3] = {1,2,3}; I suppose you are using the 3.3 version of the ECW SDK ? Then, it is a known issue in the SDK itself. See http://trac.osgeo.org/gdal/ticket/4234 . A work around has been committed in the GDAL 2.0dev version just a few days ago. For currently released GDAL versions, if you only want to read one band, you could just use RasterIO() on the band object, instead of the whole dataset. If you need to read it into a RGB buffer, you just need to keep the pixel space and line space you've used in the above call, and after calling RasterIO() on the band, do a loop to copy each buffer[3*i] value into buffer[3*i+1] and buffer[3*i+2] > > Any idea? > Thanks in advance! > > > > -- > View this message in context: > http://osgeo-org.1560.n6.nabble.com/Problem-using-image-bands-tp5009873.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 > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Problem using image bands
Ouch! Thank you very much, Even. I should have asked sooner, instead of going to bed at 5 in the morning... :-) Yes, I have to read into a RGB buffer, but your solution would increase a lot the loading time for other images that are working well. I have read this: http://trac.osgeo.org/gdal/changeset/25107. So, do you recommend me to change the code in ecwdataset.cpp and rebuild the library? Thanks again! -- View this message in context: http://osgeo-org.1560.n6.nabble.com/Problem-using-image-bands-tp5009873p5009877.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] Problem using image bands
Ouch! Thank you very much, Even. I should have asked sooner, instead of going to bed at 5 in the morning... :-) Yes, I have to read into a RGB buffer, but your solution would increase a lot the loading time for other images that are working well. I have read this: http://trac.osgeo.org/gdal/changeset/25107. So, do you recommend me to change the code in ecwdataset.cpp and rebuild the library? Thanks again! José Antonio Carmena Flores > > De: Even Rouault [via OSGeo.org] >Para: jcurru >Enviado: Viernes 19 de octubre de 2012 14:42 >Asunto: Re: Problem using image bands > > >Selon jcurru <[hidden email]>: > > >> Hello! >> >> I have a problem reading an ECW image. I want to read the image using only >> the first band. So I use: >> int bmap[3] = {1,1,1}; >> GDALImage->RasterIO( >> GF_Read, >> x, // int nXOff, >> y, // int nYOff, >> dx, // int nXSize, >> dy, // int nXSize, >> buffer, // void* pData, >> xBufSize, // int nBufXSize, >> yBufSize, // int nBufYSize, >> GDT_Byte, // GDALDataType eBufType, >> 3, // int nBandCount, >> bmap, // int* panBandMap, >> 3, // int nPixelSpace, >> xBufSize * 3, // int nLineSpace, >> 1 // int nBandSpace >> ); >> This is working well with some ECW images (they show as grayscale) but it >> does not with another, big ECW. It shows in full RGB color, exactly the same >> as if I had written int bmap[3] = {1,2,3}; >I suppose you are using the 3.3 version of the ECW SDK ? Then, it is a known >issue in the SDK itself. See http://trac.osgeo.org/gdal/ticket/4234 . A work >around has been committed in the GDAL 2.0dev version just a few days ago. > >For currently released GDAL versions, if you only want to read one band, you >could just use RasterIO() on the band object, instead of the whole dataset. If >you need to read it into a RGB buffer, you just need to keep the pixel space >and >line space you've used in the above call, and after calling RasterIO() on the >band, do a loop to copy each buffer[3*i] value into buffer[3*i+1] and >buffer[3*i+2] > > >> >> Any idea? >> Thanks in advance! >> >> >> >> -- >> View this message in context: >> http://osgeo-org.1560.n6.nabble.com/Problem-using-image-bands-tp5009873.html >> Sent from the GDAL - Dev mailing list archive at Nabble.com. >> ___ >> gdal-dev mailing list >> [hidden email] >> http://lists.osgeo.org/mailman/listinfo/gdal-dev >> > >___ >gdal-dev mailing list >[hidden email] >http://lists.osgeo.org/mailman/listinfo/gdal-dev > > >> > >If you reply to this email, your message will be added to the discussion >below:http://osgeo-org.1560.n6.nabble.com/Problem-using-image-bands-tp5009873p5009874.html > >To unsubscribe from Problem using image bands, click here. >NAML > > -- View this message in context: http://osgeo-org.1560.n6.nabble.com/Problem-using-image-bands-tp5009873p5009885.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
[gdal-dev] Unable to create OGRSpatialReference
Hello! I have an old problem with TOWGS84 and OGRSpatialReference. Most likely it's because I'm no expert in GDAL. It is important for my project, and limits many of its capabilities. The fact is that, for unknown reasons (to me), proj4 does not do well conversions between coordinate system if there are not a TOWGS84 nodes inside the OGRSpatialReference(s). First of all: is this so? Do I really need that node? If not properly added, clearly some conversions fail. I continue: Imagine getting an OGRSpatialReference a shapefile or a TIF. To assign the node TOWGS84, what I do is look into the file "EPSG", found in many sites related to GDAL, that contains a list of EPSGs with corresponding parameters. Knowing the EPSG, I can generate the TOWGS84 node smoothly. The problem comes when I do not know the OGRSpatialReference’s EPSG, something very common: AutoIdentifyEPSG () gets nothing most of the time, at least with the systems in which I work. So what to do then? I need the TOWGS84 node but, with my knowledge, I can only get it from the EPSG. Many thanks in advance. -- View this message in context: http://osgeo-org.1560.n6.nabble.com/Unable-to-create-OGRSpatialReference-tp5009903.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] Unable to create OGRSpatialReference
Le vendredi 19 octobre 2012 16:41:14, jcurru a écrit : > Hello! > > I have an old problem with TOWGS84 and OGRSpatialReference. Most likely > it's because I'm no expert in GDAL. It is important for my project, and > limits many of its capabilities. The fact is that, for unknown reasons (to > me), proj4 does not do well conversions between coordinate system if there > are not a TOWGS84 nodes inside the OGRSpatialReference(s). > > First of all: is this so? Do I really need that node? If not properly > added, clearly some conversions fail. The best is to point you to some reference documentation : http://trac.osgeo.org/proj/wiki/GenParms#towgs84-DatumtransformationtoWGS84 http://docs.geotools.org/stable/javadocs/org/opengis/referencing/doc- files/WKT.html#TOWGS84 > > I continue: Imagine getting an OGRSpatialReference a shapefile or a TIF. To > assign the node TOWGS84, what I do is look into the file "EPSG", found in > many sites related to GDAL, that contains a list of EPSGs with > corresponding parameters. Knowing the EPSG, I can generate the TOWGS84 > node smoothly. > > The problem comes when I do not know the OGRSpatialReference’s EPSG, > something very common: AutoIdentifyEPSG () gets nothing most of the time, > at least with the systems in which I work. > > So what to do then? I need the TOWGS84 node but, with my knowledge, I can > only get it from the EPSG. This is indeed a difficulty that is not easily solved. The WKT in .prj that come alongside with shapefiles is in ESRI WKT that stripps TOWGS84 information. And most geotiff don't include TOWGS84 : the GeoTIFF format has only been extended very recently to convey TOWGS84 : http://trac.osgeo.org/geotiff/wiki/TOWGS84GeoKey And indeed AutoIdentifyEPSG() only works a few common cases, mainly EPSG:4326, EPSG:326XX & EPSG:327XX (WGS84 UTM projections), EPSG:267XX (NAD27 UTM projections) and EPSG:269XX (NAD83 UTM projections). ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] gdalinfo -stats Misses invalid data value in ENVI header
Hello, I have a curious problem with 'gdalinfo' (gdal version 1.9.0 ). I have an input ENVI file with the following .HDR entry: data ignore value = -9.9900e+002 gdalinfo for the IMG file provides stats that exclude all values -999.0 as expected. I then create a masked output file using 'gdal_rasterize' from that input file once again using -999.0 as the mask value. 'gdal_rasterize' produces an ENVI format output with an accompanying .HDR file. The resulting 'gdal_rasterize' HDR *does not* contain the previous 'data ignore value' entry. This is something that should be fixed in future versions of that utility. The work around is, of course, to simply concatenate the 'data ignore value' to the end of the HDR file. This is a quick step: echo "" >> myfile.hdr echo "data ignore value = -9.9900+e2" >> myfile.hdr echo "" >> myfile.hdr [NOTE: There are some other issues with ENVI HDR generation in GDAL that should also be addressed but I won't go into those here.] PROBLEM: gdalinfo does not parse the value for the concatenated header entry if it is placed at the end of the HDR file. In fact, the HDR file may be edited to move the entry to a location near the top of the file whereby it remains unacknowledged by gdalinfo. QUESTION: Does gdalinfo expect the header entries to be in a specific order? I have appended some parsing information to the end of this email. You are probably aware of most, if not all, of this information. Thanks, Peter --ENVI TEXT HEADERS--- The ENVI header file is not an 'ordered' data file. The entries may appear in any order. The generic format for entries is: = [EOL] Equals '=' normally appears on the same line as without intervening carriage return characters. It is normal for '=' to be preceded by one space character although not necessary. Equals '=' is considered to be the primary delimiter between and . ---NAMES--- '' may be any string without carriage returns, and the may include space characters. All names (and values) are trimmed of preceding and trailing white space characters at parse time. TAB'\t' is not normally used as whitespace but is parsed as though it were a space ' ' character. ---VALUES--- '' may be a singular value (ie: a number or a string with no whitespace ) or a 'list' bounded by curly braces { }. Examples of singular string values would be: Interleave = BSQ Sensor type = Unknown Wavelength units = nanometers where 'BSQ' , 'Unknown', and 'nanometers' are singular strings containing no whitespace characters. In the context of the strings containing necessary whitespace should be encoded as a list. String values may contain carriage return characters. The comma ',' is considered to be the default delimiter for list type data. Ie: My List = { some string data , another string data , yet another data string , etc data strings ad infinitum } Number formats associated with Singular Integers: My Integer = 9 My Integer = -99 My Integer = 0 Singular Reals: My Real = 0.9 My Real = .9 My Real = -9.0+e8 Lists of numbers: My Integer List = { 1 , 2 , 3, 4 , 5 , 6 } My Real List = { 1.0 , -2.00e+2 , 3.0e-4, 4.0 , .5 , 6.1 } ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalinfo -stats Misses invalid data value in ENVI header
Le vendredi 19 octobre 2012 20:41:16, Peter Willis a écrit : > Hello, > > I have a curious problem with 'gdalinfo' (gdal version 1.9.0 ). > > I have an input ENVI file with the following .HDR entry: > > data ignore value = -9.9900e+002 > > gdalinfo for the IMG file provides stats that exclude all values -999.0 as > expected. > > I then create a masked output file using 'gdal_rasterize' from that input > file once again using -999.0 as the mask value. > 'gdal_rasterize' produces an ENVI format output with an accompanying .HDR > file. There's indeed no support currently in the ENVI driver to write the "data ignore value" field. > > The resulting 'gdal_rasterize' HDR *does not* contain the previous 'data > ignore value' entry. This is something that should > be fixed in future versions of that utility. The work around is, of course, > to simply concatenate the 'data ignore value' > to the end of the HDR file. This is a quick step: > > echo "" >> myfile.hdr > echo "data ignore value = -9.9900+e2" >> myfile.hdr > echo "" >> myfile.hdr I've tried that and this worked for me. Perhaps you could send your myfile.hdr ? ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Unable to create OGRSpatialReference
Thank you again, Even. Well, I've taken a look at the documentation you mention, but no answers there, just an explanation about wgsto84 parameters and a proposal for extending the geotiff standard in order to embed the famous parameter. I guess that if you don't say "oh man, didn' you know this famous trick...?" is because the trick does not exist. So, before I continue wasting your time, would you be so kind to answer this two questions? (yes/no will be enough) 1) Do I need the towgs84 parameters to properly do transformations between coordinate systems using proj4? 2) The only way to obtain that parameter is by using the "epsg" file, and therefore I MUST know the EPSG? Thak you! -- View this message in context: http://osgeo-org.1560.n6.nabble.com/Unable-to-create-OGRSpatialReference-tp5009903p5009950.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] Unable to create OGRSpatialReference
On Fri, Oct 19, 2012 at 7:41 AM, jcurru wrote: > Hello! > > I have an old problem with TOWGS84 and OGRSpatialReference. Most likely > it's > because I'm no expert in GDAL. It is important for my project, and limits > many of its capabilities. The fact is that, for unknown reasons (to me), > proj4 does not do well conversions between coordinate system if there are > not a TOWGS84 nodes inside the OGRSpatialReference(s). > > First of all: is this so? Do I really need that node? If not properly > added, > clearly some conversions fail. > JCurru, PROJ.4 should still handle reprojection for coordinate systems without a TOWGS84 or other datum relationship to WGS84 *but* it will ignore datum shifting if the source and destination coordinate system do not have well defined relationships to WGS84. So the results will (often) be somewhat inaccurate. How big an issue this is will depend on your application and the typical coordinate systems you work with. > I continue: Imagine getting an OGRSpatialReference a shapefile or a TIF. To > assign the node TOWGS84, what I do is look into the file "EPSG", found in > many sites related to GDAL, that contains a list of EPSGs with > corresponding > parameters. Knowing the EPSG, I can generate the TOWGS84 node smoothly. > > The problem comes when I do not know the OGRSpatialReference’s EPSG, > something very common: AutoIdentifyEPSG () gets nothing most of the time, > at > least with the systems in which I work. > > So what to do then? I need the TOWGS84 node but, with my knowledge, I can > only get it from the EPSG. > If you want to handle a datum shift properly and you don't know how the datum of your coordinate system relates to WGS84 then you are essentially out of luck. 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 Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalinfo -stats Misses invalid data value in ENVI header
Hello, I am providing the failed example followed by a working example. Let me know if there is any additional information you need. Thanks, Peter --The Failed Header Sample-- ENVI description = { /web2-disk1/PR762/landsat/cubes/96_98/LSatThermalCube_96-98_float_cmsk_landm asked_ll.img} samples = 2178 lines = 1841 bands = 49 header offset = 0 file type = ENVI Standard data type = 4 interleave = bsq byte order = 0 map info = {Geographic Lat/Lon, 1, 1, -124.258818822249, 51.6708415299984, 0.000337173258151718, 0.000337173258151718,WGS-84} wavelength units = Unknown data ignore value = -9.9900e+002 band names = { Band 1, Band 2, Band 3, Band 4, Band 5, Band 6, Band 7, Band 8, Band 9, Band 10, Band 11, Band 12, Band 13, Band 14, Band 15, Band 16, Band 17, Band 18, Band 19, Band 20, Band 21, Band 22, Band 23, Band 24, Band 25, Band 26, Band 27, Band 28, Band 29, Band 30, Band 31, Band 32, Band 33, Band 34, Band 35, Band 36, Band 37, Band 38, Band 39, Band 40, Band 41, Band 42, Band 43, Band 44, Band 45, Band 46, Band 47, Band 48, Band 49} --The Working Header Sample-- ENVI description = { Band Math Result, Expression = [(float(b2 gt 0.0) * b1) + (float(b2 eq 0.0)* (-999.0))] B1:LSatThermalCube_96-98_float_cmsk.img B2:LSatThermalCube_96-98_float_cmsk_multi_channel_mask.img [Thu Oct 18 10:12:05 2012]} samples = 1677 lines = 2281 bands = 49 header offset = 0 file type = ENVI Standard data type = 4 interleave = bsq sensor type = Unknown byte order = 0 map info = {UTM, 1.000, 1.000, 412940.000, 5724563.000, 3.00e+001, 3.00e+001, 10, North, WGS-84, units=Meters} wavelength units = Unknown data ignore value = -9.9900e+002 pixel size = {3.e+001, 3.e+001, units=Meters} band names = { Band Math (Band Math (Band Math (1996_088 Landsat-4/5 TM :Surface Temperature Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatThe rmalCube_96-98_float_cmsk.img), Band Math (Band Math (Band Math (1996_104 Landsat-4/5 TM :Surface Temperature Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatThe rmalCube_96-98_float_cmsk.img), Band Math (Band Math (Band Math (1996_111 Landsat-4/5 TM :Surface Temperature Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatThe rmalCube_96-98_float_cmsk.img), Band Math (Band Math (Band Math (1996_120 Landsat-4/5 TM :Surface Temperature Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatThe rmalCube_96-98_float_cmsk.img), Band Math (Band Math (Band Math (1996_136 Landsat-4/5 TM :Surface Temperature Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatThe rmalCube_96-98_float_cmsk.img), Band Math (Band Math (Band Math (1996_152 Landsat-4/5 TM :Surface Temperature Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatThe rmalCube_96-98_float_cmsk.img), Band Math (Band Math (Band Math (1996_159 Landsat-4/5 TM :Surface Temperature Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatThe rmalCube_96-98_float_cmsk.img), Band Math (Band Math (Band Math (1996_168 Landsat-4/5 TM :Surface Temperature Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatThe rmalCube_96-98_float_cmsk.img), Band Math (Band Math (Band Math (1996_191 Landsat-4/5 TM :Surface Temperature Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatThe rmalCube_96-98_float_cmsk.img), Band Math (Band Math (Band Math (1996_200 Landsat-4/5 TM :Surface Temperature Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatThe rmalCube_96-98_float_cmsk.img), Band Math (Band Math (Band Math (1996_207 Landsat-4/5 TM :Surface Temperature Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatThe rmalCube_96-98_float_cmsk.img), Band Math (Band Math (Band Math (1996_216 Landsat-4/5 TM :Surface Temperature Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatThe rmalCube_96-98_float_cmsk.img), Band Math (Band Math (Band Math (1996_223 Landsat-4/5 TM :Surface Temperature Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatThe rmalCube_96-98_float_cmsk.img), Band Math (Band Math (Band Math (1996_232 Landsat-4/5 TM :Surface Temperature Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatThe rmalCube_96-98_float_cmsk.img), Band Math (Band Math (Band Math (1996_239 Landsat-4/5 TM :Surface Temperature Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatThe rmalCube_96-98_float_cmsk.img), Band Math (Band Math (Band Math (1996_255 Landsat-4/5 TM :Surface Temperature Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatThe rmalCube_96-98_float_cmsk.img), Band Math (Band Math (Band Math (1996_280 Landsat-4/5 TM :Surface Temperature Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatThe rmalCube_96-98_float_cmsk.img), Band Math (Band Math (
Re: [gdal-dev] gdalinfo -stats Misses invalid data value in ENVI header
Le vendredi 19 octobre 2012 22:23:49, Peter Willis a écrit : > Hello, > > I am providing the failed example followed by a working example. > Let me know if there is any additional information you need. With both headers, gdalinfo correctly reports the nodata value... But you didn't send the .hdr files you've generated since the "data ignore value" is not at their end. > > Thanks, > > Peter > > > --The Failed Header Sample-- > ENVI > description = { > /web2-disk1/PR762/landsat/cubes/96_98/LSatThermalCube_96-98_float_cmsk_land > m asked_ll.img} > samples = 2178 > lines = 1841 > bands = 49 > header offset = 0 > file type = ENVI Standard > data type = 4 > interleave = bsq > byte order = 0 > map info = {Geographic Lat/Lon, 1, 1, -124.258818822249, 51.6708415299984, > 0.000337173258151718, 0.000337173258151718,WGS-84} > wavelength units = Unknown > data ignore value = -9.9900e+002 > band names = { > Band 1, > Band 2, > Band 3, > Band 4, > Band 5, > Band 6, > Band 7, > Band 8, > Band 9, > Band 10, > Band 11, > Band 12, > Band 13, > Band 14, > Band 15, > Band 16, > Band 17, > Band 18, > Band 19, > Band 20, > Band 21, > Band 22, > Band 23, > Band 24, > Band 25, > Band 26, > Band 27, > Band 28, > Band 29, > Band 30, > Band 31, > Band 32, > Band 33, > Band 34, > Band 35, > Band 36, > Band 37, > Band 38, > Band 39, > Band 40, > Band 41, > Band 42, > Band 43, > Band 44, > Band 45, > Band 46, > Band 47, > Band 48, > Band 49} > > > > --The Working Header Sample-- > > ENVI > description = { > Band Math Result, Expression = [(float(b2 gt 0.0) * b1) + (float(b2 eq > 0.0)* > (-999.0))] B1:LSatThermalCube_96-98_float_cmsk.img > B2:LSatThermalCube_96-98_float_cmsk_multi_channel_mask.img [Thu Oct 18 > 10:12:05 2012]} > samples = 1677 > lines = 2281 > bands = 49 > header offset = 0 > file type = ENVI Standard > data type = 4 > interleave = bsq > sensor type = Unknown > byte order = 0 > map info = {UTM, 1.000, 1.000, 412940.000, 5724563.000, 3.00e+001, > 3.00e+001, 10, North, WGS-84, units=Meters} > wavelength units = Unknown > data ignore value = -9.9900e+002 > pixel size = {3.e+001, 3.e+001, units=Meters} > band names = { > Band Math (Band Math (Band Math (1996_088 Landsat-4/5 TM :Surface > Temperature > Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatTh > e rmalCube_96-98_float_cmsk.img), > Band Math (Band Math (Band Math (1996_104 Landsat-4/5 TM :Surface > Temperature > Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatTh > e rmalCube_96-98_float_cmsk.img), > Band Math (Band Math (Band Math (1996_111 Landsat-4/5 TM :Surface > Temperature > Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatTh > e rmalCube_96-98_float_cmsk.img), > Band Math (Band Math (Band Math (1996_120 Landsat-4/5 TM :Surface > Temperature > Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatTh > e rmalCube_96-98_float_cmsk.img), > Band Math (Band Math (Band Math (1996_136 Landsat-4/5 TM :Surface > Temperature > Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatTh > e rmalCube_96-98_float_cmsk.img), > Band Math (Band Math (Band Math (1996_152 Landsat-4/5 TM :Surface > Temperature > Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatTh > e rmalCube_96-98_float_cmsk.img), > Band Math (Band Math (Band Math (1996_159 Landsat-4/5 TM :Surface > Temperature > Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatTh > e rmalCube_96-98_float_cmsk.img), > Band Math (Band Math (Band Math (1996_168 Landsat-4/5 TM :Surface > Temperature > Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatTh > e rmalCube_96-98_float_cmsk.img), > Band Math (Band Math (Band Math (1996_191 Landsat-4/5 TM :Surface > Temperature > Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatTh > e rmalCube_96-98_float_cmsk.img), > Band Math (Band Math (Band Math (1996_200 Landsat-4/5 TM :Surface > Temperature > Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatTh > e rmalCube_96-98_float_cmsk.img), > Band Math (Band Math (Band Math (1996_207 Landsat-4/5 TM :Surface > Temperature > Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatTh > e rmalCube_96-98_float_cmsk.img), > Band Math (Band Math (Band Math (1996_216 Landsat-4/5 TM :Surface > Temperature > Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatTh > e rmalCube_96-98_float_cmsk.img), > Band Math (Band Math (Band Math (1996_223 Landsat-4/5 TM :Surface > Temperature > Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatTh > e rmalCube_96-98_float_cmsk.img), > Band Math (Band Math (Band Math (1996_232 Landsat-4/5 TM :Surface > Temperature > Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatTh > e rmalCube_96-98_float_cmsk.img), > Band Math (Band
Re: [gdal-dev] gdalinfo -stats Misses invalid data value in ENVI header
Hello, The one listed as 'failed' actually fails for me as it is sent . I was experimenting by moving the value near the top of the file. It continues to fail whether the entry is at the bottom of the file Or where it appears in the sample that I sent to you. Could it be a line feeds issue? I haven't tried running unix2dos/dos2unix against the HDR files. Does the program mind if the EOL are \13\10 vs. \10 ? Best Regards, Peter -Original Message- From: Even Rouault [mailto:even.roua...@mines-paris.org] Sent: October-19-12 1:44 PM To: gdal-dev@lists.osgeo.org Cc: Peter Willis Subject: Re: [gdal-dev] gdalinfo -stats Misses invalid data value in ENVI header Le vendredi 19 octobre 2012 22:23:49, Peter Willis a écrit : > Hello, > > I am providing the failed example followed by a working example. > Let me know if there is any additional information you need. With both headers, gdalinfo correctly reports the nodata value... But you didn't send the .hdr files you've generated since the "data ignore value" is not at their end. > > Thanks, > > Peter > > > --The Failed Header Sample-- > ENVI > description = { > /web2-disk1/PR762/landsat/cubes/96_98/LSatThermalCube_96-98_float_cmsk > _land > m asked_ll.img} > samples = 2178 > lines = 1841 > bands = 49 > header offset = 0 > file type = ENVI Standard > data type = 4 > interleave = bsq > byte order = 0 > map info = {Geographic Lat/Lon, 1, 1, -124.258818822249, > 51.6708415299984, 0.000337173258151718, 0.000337173258151718,WGS-84} > wavelength units = Unknown data ignore value = -9.9900e+002 band > names = { Band 1, Band 2, Band 3, Band 4, Band 5, Band 6, Band 7, Band > 8, Band 9, Band 10, Band 11, Band 12, Band 13, Band 14, Band 15, Band > 16, Band 17, Band 18, Band 19, Band 20, Band 21, Band 22, Band 23, > Band 24, Band 25, Band 26, Band 27, Band 28, Band 29, Band 30, Band > 31, Band 32, Band 33, Band 34, Band 35, Band 36, Band 37, Band 38, > Band 39, Band 40, Band 41, Band 42, Band 43, Band 44, Band 45, Band > 46, Band 47, Band 48, Band 49} > > > > --The Working Header Sample-- > > ENVI > description = { > Band Math Result, Expression = [(float(b2 gt 0.0) * b1) + (float(b2 > eq > 0.0)* > (-999.0))] B1:LSatThermalCube_96-98_float_cmsk.img > B2:LSatThermalCube_96-98_float_cmsk_multi_channel_mask.img [Thu Oct 18 > 10:12:05 2012]} > samples = 1677 > lines = 2281 > bands = 49 > header offset = 0 > file type = ENVI Standard > data type = 4 > interleave = bsq > sensor type = Unknown > byte order = 0 > map info = {UTM, 1.000, 1.000, 412940.000, 5724563.000, > 3.00e+001, 3.00e+001, 10, North, WGS-84, units=Meters} > wavelength units = Unknown data ignore value = -9.9900e+002 pixel > size = {3.e+001, 3.e+001, units=Meters} band names = { > Band Math (Band Math (Band Math (1996_088 Landsat-4/5 TM :Surface > Temperature > Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):L > SatTh > e rmalCube_96-98_float_cmsk.img), > Band Math (Band Math (Band Math (1996_104 Landsat-4/5 TM :Surface > Temperature > Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):L > SatTh > e rmalCube_96-98_float_cmsk.img), > Band Math (Band Math (Band Math (1996_111 Landsat-4/5 TM :Surface > Temperature > Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):L > SatTh > e rmalCube_96-98_float_cmsk.img), > Band Math (Band Math (Band Math (1996_120 Landsat-4/5 TM :Surface > Temperature > Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):L > SatTh > e rmalCube_96-98_float_cmsk.img), > Band Math (Band Math (Band Math (1996_136 Landsat-4/5 TM :Surface > Temperature > Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):L > SatTh > e rmalCube_96-98_float_cmsk.img), > Band Math (Band Math (Band Math (1996_152 Landsat-4/5 TM :Surface > Temperature > Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):L > SatTh > e rmalCube_96-98_float_cmsk.img), > Band Math (Band Math (Band Math (1996_159 Landsat-4/5 TM :Surface > Temperature > Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):L > SatTh > e rmalCube_96-98_float_cmsk.img), > Band Math (Band Math (Band Math (1996_168 Landsat-4/5 TM :Surface > Temperature > Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):L > SatTh > e rmalCube_96-98_float_cmsk.img), > Band Math (Band Math (Band Math (1996_191 Landsat-4/5 TM :Surface > Temperature > Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):L > SatTh > e rmalCube_96-98_float_cmsk.img), > Band Math (Band Math (Band Math (1996_200 Landsat-4/5 TM :Surface > Temperature > Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):L > SatTh > e rmalCube_96-98_float_cmsk.img), > Band Math (Band Math (Band Math (1996_207 Landsat-4/5 TM :Surface > Temperature > Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_f
Re: [gdal-dev] Unable to create OGRSpatialReference
Frank, First of all let me tell you thanks for your work. Thanks is not enough but my poor english would put me in troubles if I tried to say something more complicated. And thank you very much for your answer. Getting help from you from the other side of the ocean (I live in Madrid, Spain) is a honor. I am not an expert in GIS, but despite of it I am writting a big GIS application. My colleages are supposed to be, but they have been unable to give me a solution to this subject, so, please, be so kind to tell me if this is ok: Ignoring the towgs84 parameters has proved to give bad results when transforming coordinate systems using proj4, even working with standard systems like ETRS89 (used in Spain) or ED50. Giving the correct towgs84 parameter the errors dissapeared completely. Therefore, I decided to write a descendant from OGRSpatialReference whose constructors throw exceptions if the towgs84 parameter cannot be found. For example, there's a constructor that receives an OGRSpatialReference pointer as argument (obtained, for example, from a shapefile, a tif, a LAS file, etc using GDAL). My class builds the underlying OGRSpatialReference with that pointer and then tries to obtain the towgs84 parameter. Somethimes it is present in the OGRSpatialReference object, most doesn't. Then I try to use the "epsg." file if I can figure out the EPSG number. If everything fails then the constructor throws and the program asks for an EPSG to the user. And this is a pity because "almost all" the information I need is supplied by GDAL. The program is worst because it's not able to find out the famous parameter. You say: "If you want to handle a datum shift properly and you don't know how the datum of your coordinate system relates to WGS84 then you are essentially out of luck." The problem is that my application should work with any projection. I cannot make assumptions or make a list of "supported projections". My aim is to be able to get the towgs84 parameter whatever coordinate system the input files are projected into. I often use other programs to display geospatial information, for example Global Mapper. It realizes coordinate systems from (for example) shapefiles without EPSG, and applies transformations correctly. What am I missing? Sorry for my long message, but I've been overwhelmed with this problem for two years, and having you across the line gives me a hope. I'm sure there's a solution because many systems work fine. So thank you again. Sincerely yours, Jose Antonio. -- View this message in context: http://osgeo-org.1560.n6.nabble.com/Unable-to-create-OGRSpatialReference-tp5009903p5009971.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] gdalinfo -stats Misses invalid data value in ENVI header
Le vendredi 19 octobre 2012 22:57:13, Peter Willis a écrit : > Hello, > > The one listed as 'failed' actually fails for me as it is sent . Just to be sure we are talking about the same thing, what do you call "fail" exactly ? Is it that gdalinfo doesn't report "NoData Value=-999" for the bands ? Just for reference, I've create a fake "LSatThermalCube_96-98_float_cmsk_landmasked_ll.img" and gdalinfo on it reports : Driver: ENVI/ENVI .hdr Labelled Files: LSatThermalCube_96-98_float_cmsk_landmasked_ll.img LSatThermalCube_96-98_float_cmsk_landmasked_ll.hdr Size is 2178, 1841 Coordinate System is: 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"]] Origin = (-124.258818822248998,51.670841529998398) Pixel Size = (0.000337173258152,-0.000337173258152) Metadata: [ cut ] Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left (-124.2588188, 51.6708415) (124d15'31.75"W, 51d40'15.03"N) Lower Left (-124.2588188, 51.0501056) (124d15'31.75"W, 51d 3' 0.38"N) Upper Right (-123.5244555, 51.6708415) (123d31'28.04"W, 51d40'15.03"N) Lower Right (-123.5244555, 51.0501056) (123d31'28.04"W, 51d 3' 0.38"N) Center (-123.8916371, 51.3604735) (123d53'29.89"W, 51d21'37.70"N) Band 1 Block=2178x1 Type=Float32, ColorInterp=Undefined Description = Band 1 NoData Value=-999 Band 2 Block=2178x1 Type=Float32, ColorInterp=Undefined Description = Band 2 NoData Value=-999 [... cut ... ] Band 49 Block=2178x1 Type=Float32, ColorInterp=Undefined Description = Band 49 NoData Value=-999 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalinfo -stats Misses invalid data value in ENVI header
Hello, When I run : Gdalinfo -stats One file (success) provides statistics calculated by excluding the no data values. Ie: min=0.25 max=1234.0 mean=12.0 The other file (failed) provides statistics with -999 calculated into the stats. Ie: min = -999.0 max=1234.0 mean=-993.0 I have looked at both binary files. Each of the two files contain the mask value. ENVI loads both files and headers fine and reports the same no data value, for each file, in header info just fine. I think you could probably model the problem by generating a much smaller file with multiple channels. The steps happening are as follows: 1.) Original file (IN_IMG) is UTM projection ENVI format 49 bands BSQ, float32 2.) gdalwarp -of ENVI -t_srs "+proj=latlong +datum=WGS84" ${IN_IMG} ${OUT_IMG} 3.) put the data ignore value back in the file: echo "" >> $OUT_HDR echo "data ignore value = -9.9900e+002" >> $OUT_HDR 4.) Call gdalinfo for number of bands in original file => $BANDS 5.) loop through bands seq 1 $BANDS => $BAND gdal_rasterize -b $BAND -burn -999 -l ${LAYER_NAME} ${MASK_SHP} ${OUT_IMG} 6.) gdalinfo -stats ${OUT_IMG} At step #6, gdalinfo -stats reports data stats with the -999 values calculated into the min/max/mean/stdev. Band 2 Block=2178x1 Type=Float32, ColorInterp=Undefined Description = Band 2 Min=-999.000 Max=12.250 Minimum=-999.000, Maximum=12.250, Mean=-946.817, StdDev=222.404 NoData Value=-999 Metadata: STATISTICS_MINIMUM=-999 STATISTICS_MAXIMUM=12.25 STATISTICS_MEAN=-946.81678963104 STATISTICS_STDDEV=222.4036660914 If I perform gdalinfo -stats on the original UTM file the min/max/mean/stdev exclude -999 from calculations. Band 2 Block=1677x1 Type=Float32, ColorInterp=Undefined Description = Band Math (Band Math (Band Math (1996_104 Landsat-4/5 TM :Surface Temperature Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatThermalCube_96-98_float_cmsk.img) Min=0.250 Max=12.250 Minimum=0.250, Maximum=12.250, Mean=1.379, StdDev=0.995 NoData Value=-999 Metadata: STATISTICS_MINIMUM=0.25 STATISTICS_MAXIMUM=12.25 STATISTICS_MEAN=1.3787828985307 STATISTICS_STDDEV=0.99545771926881 I hope this helps. Let me know if you need any more information. Peter -Original Message- From: Even Rouault [mailto:even.roua...@mines-paris.org] Sent: October-19-12 2:08 PM To: gdal-dev@lists.osgeo.org Cc: Peter Willis Subject: Re: [gdal-dev] gdalinfo -stats Misses invalid data value in ENVI header Le vendredi 19 octobre 2012 22:57:13, Peter Willis a écrit : > Hello, > > The one listed as 'failed' actually fails for me as it is sent . Just to be sure we are talking about the same thing, what do you call "fail" exactly ? Is it that gdalinfo doesn't report "NoData Value=-999" for the bands ? Just for reference, I've create a fake "LSatThermalCube_96-98_float_cmsk_landmasked_ll.img" and gdalinfo on it reports : Driver: ENVI/ENVI .hdr Labelled Files: LSatThermalCube_96-98_float_cmsk_landmasked_ll.img LSatThermalCube_96-98_float_cmsk_landmasked_ll.hdr Size is 2178, 1841 Coordinate System is: 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"]] Origin = (-124.258818822248998,51.670841529998398) Pixel Size = (0.000337173258152,-0.000337173258152) Metadata: [ cut ] Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left (-124.2588188, 51.6708415) (124d15'31.75"W, 51d40'15.03"N) Lower Left (-124.2588188, 51.0501056) (124d15'31.75"W, 51d 3' 0.38"N) Upper Right (-123.5244555, 51.6708415) (123d31'28.04"W, 51d40'15.03"N) Lower Right (-123.5244555, 51.0501056) (123d31'28.04"W, 51d 3' 0.38"N) Center (-123.8916371, 51.3604735) (123d53'29.89"W, 51d21'37.70"N) Band 1 Block=2178x1 Type=Float32, ColorInterp=Undefined Description = Band 1 NoData Value=-999 Band 2 Block=2178x1 Type=Float32, ColorInterp=Undefined Description = Band 2 NoData Value=-999 [... cut ... ] Band 49 Block=2178x1 Type=Float32, ColorInterp=Undefined Description = Band 49 NoData Value=-999 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalinfo -stats Misses invalid data value in ENVI header
Hello, I am seeing that you are correct that the 'no data value' is being read in each case. Perhaps my interpretation of the problem appears incorrect. Look, however at the 'Metadata:' statistics. Both files have assigned -999 to 'No Data Value' but'STATISTICS_MINIMUM' for one file shows -999 (??). This means the values are not being ignored for the purpose of calculating statistics. --THE BAD FILE-- Band 2 Block=2178x1 Type=Float32, ColorInterp=Undefined Description = Band 2 Min=-999.000 Max=12.250 Minimum=-999.000, Maximum=12.250, Mean=-946.817, StdDev=222.404 NoData Value=-999 Metadata: STATISTICS_MINIMUM=-999 STATISTICS_MAXIMUM=12.25 STATISTICS_MEAN=-946.81678963104 STATISTICS_STDDEV=222.4036660914 ---THE GOOD FILE--- Band 2 Block=1677x1 Type=Float32, ColorInterp=Undefined Description = Band Math (Band Math (Band Math (1996_104 Landsat-4/5 TM :Surface Temperature Sensor:6:LSatThermalCube_96-98.img):LSatThermalCube_96-98_float.img):LSatThermalCube_96-98_float_cmsk.img) Min=0.250 Max=12.250 Minimum=0.250, Maximum=12.250, Mean=1.379, StdDev=0.995 NoData Value=-999 Metadata: STATISTICS_MINIMUM=0.25 STATISTICS_MAXIMUM=12.25 STATISTICS_MEAN=1.3787828985307 STATISTICS_STDDEV=0.99545771926881 Note the difference in stats calculations. Peter ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalinfo -stats Misses invalid data value in ENVI header
Le vendredi 19 octobre 2012 23:57:01, Peter Willis a écrit : > Hello, > > At step #6, gdalinfo -stats reports data stats with the -999 values > calculated into the min/max/mean/stdev. > > > Band 2 Block=2178x1 Type=Float32, ColorInterp=Undefined > Description = Band 2 > Min=-999.000 Max=12.250 > Minimum=-999.000, Maximum=12.250, Mean=-946.817, StdDev=222.404 > NoData Value=-999 > Metadata: > STATISTICS_MINIMUM=-999 > STATISTICS_MAXIMUM=12.25 > STATISTICS_MEAN=-946.81678963104 > STATISTICS_STDDEV=222.4036660914 > Ok, indeed that's not expected. Well, perhaps you could first check if there is no .aux.xml file that would contain bad values. And if so, delete it before running again gdalinfo -stats. Other than that, I've no more idea without having access to the .img file itself. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalinfo -stats Misses invalid data value in ENVI header
Hello, Good news. Removing the '.aux.xml ' file and again running gdalinfo -statsindeed fixes the problem. I now get the expected statistics values. Thank you for your help. Best Regards, Peter Le vendredi 19 octobre 2012 23:57:01, Peter Willis a écrit : > Hello, > > At step #6, gdalinfo -stats reports data stats with the -999 values > calculated into the min/max/mean/stdev. > > > Band 2 Block=2178x1 Type=Float32, ColorInterp=Undefined > Description = Band 2 > Min=-999.000 Max=12.250 > Minimum=-999.000, Maximum=12.250, Mean=-946.817, StdDev=222.404 > NoData Value=-999 > Metadata: > STATISTICS_MINIMUM=-999 > STATISTICS_MAXIMUM=12.25 > STATISTICS_MEAN=-946.81678963104 > STATISTICS_STDDEV=222.4036660914 > Ok, indeed that's not expected. Well, perhaps you could first check if there is no .aux.xml file that would contain bad values. And if so, delete it before running again gdalinfo -stats. Other than that, I've no more idea without having access to the .img file itself. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Unable to create OGRSpatialReference
On Fri, Oct 19, 2012 at 2:00 PM, jcurru wrote: > I often use other programs to display geospatial information, for example > Global Mapper. It realizes coordinate systems from (for example) shapefiles > without EPSG, and applies transformations correctly. What am I missing? > Jose, It is hard to answer this very broadly, but it is possible that Global Mapper knows how to lookup *ESRI* datum names to find towgs84 parameters. To some extent we have this information in the system now. For instance if you look in gdal_datum.csv, the last column is "ESRI_DATUM_NAME" and has D_European_1950 for EPSG datum 6230. The gcs.csv file has a TOWGS84 parameter value for GCS 4230 (which uses datum 6230). So in theory given ESRI datum names we ought to be able to (fairly often) derived a TOWGS84 shift and in fact this should quite possible be part of the morphFromESRI() process though apparently it is not now. It would make it easier to do this if we included the ESRI_DATUM_NAME field in the gcs.csv file. So if it is really just the ESRI datum's case that you want to address lets consider improving the automatic morphing within GDAL/OGR. I'm willing to help with this. In fact, digging in the code there seems to already be some machinery around doing that. Lets discuss in more detail the case where it isn't working for you now. ... OK, I tried: gdalsrsinfo ESRI::'GEOGCS["GCS_European_1950",DATUM["D_European_1950",SPHEROID["International_1924",6378388.0,297.0]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433],AUTHORITY["EPSG",4230]]' and I get as output: PROJ.4 : '+proj=longlat +ellps=intl +towgs84=-87,-98,-121,0,0,0,0 +no_defs ' OGC WKT : GEOGCS["GCS_European_1950", DATUM["European_Datum_1950", SPHEROID["International_1924",6378388.0,297.0]], PRIMEM["Greenwich",0.0], UNIT["Degree",0.01745329251994 I'm not really sure where the PROJ.4 string is getting the towgs84 parameters, but there is no evidence that the ESRI datum name lookup is being used to get these parameters. I'm up with fixing this with your support (ie. testing, prompting). I still claim solving the problem widely is not really doable. Best regards, Frank > Sorry for my long message, but I've been overwhelmed with this problem for > two years, and having you across the line gives me a hope. I'm sure there's > a solution because many systems work fine. > > So thank you again. > Sincerely yours, > Jose Antonio. > > > > -- > View this message in context: > http://osgeo-org.1560.n6.nabble.com/Unable-to-create-OGRSpatialReference-tp5009903p5009971.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 > -- ---+-- 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 Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev