[gdal-dev] errror in building qgis
Hello all, I am trying to build qgis for Qt in fedora I have INSTALLED dependies for Python pyqt. and sip It is building upto following Steps Scanning dependencies of target python_module_qgis_networkanalysis [ 92%] Building CXX object python/CMakeFiles/python_module_qgis_networkanalysis.dir/analysis/network/sipnetworkanalysispart0.cpp.o [ 92%] Building CXX object python/CMakeFiles/python_module_qgis_networkanalysis.dir/analysis/network/sipnetworkanalysispart1.cpp.o [ 92%] Building CXX object python/CMakeFiles/python_module_qgis_networkanalysis.dir/analysis/network/sipnetworkanalysispart2.cpp.o [ 92%] Building CXX object python/CMakeFiles/python_module_qgis_networkanalysis.dir/analysis/network/sipnetworkanalysispart3.cpp.o Linking CXX shared library ../output/python/qgis/networkanalysis.so [ 92%] Built target python_module_qgis_networkanalysis [ 92%] Generating ui_qgsplugininstallerbase.py Any Help for the above Problem is greatly apprieciated Thanking You ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] convert dwg/dgn to raster/vector files (windows)
Hi, please can you help me with following? I'm trying to find the best way to convert dgn/dwg files to vector(svg) and raster(png) formats. In the OGR Vector formats table http://www.gdal.org/ogr/ogr_formats.html is stated that dwg and dgn formats are compiled by default. On another side I see in AutoCad dwg description http://www.gdal.org/ogr/drv_dwg.html that we need Open Design Alliance Teiga library. Does this mean that the Teiga library is included in gdal (it just needs to be included during the build)? Thank you in advance. Regards, Miro ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] MinGW build
Folks I'm building GDAL (the trunk) in latest MinGW. For some reason I don't understand I need to add -lstdc++ to LDFLAGS in GDALmake.opt. I'm not sure if this is the best way to fix the problem - probably not - but it works. The problem is the step where the library file libgdal.dll.a is made. Anybody have any ideas why this is like this? Otherwise http://trac.osgeo.org/gdal/wiki/BuildingWithMinGW seems up to date. Ari ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] convert dwg/dgn to raster/vector files (windows)
Selon Miro Karpis miroslav.kar...@gmail.com: Hi, please can you help me with following? I'm trying to find the best way to convert dgn/dwg files to vector(svg) and raster(png) formats. In the OGR Vector formats table http://www.gdal.org/ogr/ogr_formats.html is stated that dwg and dgn formats are compiled by default. No, have a look again ;-) Format Name CodeCompiled by default AutoCAD DWG DWG No Microstation DGNDGN Yes On another side I see in AutoCad dwg description http://www.gdal.org/ogr/drv_dwg.html that we need Open Design Alliance Teiga library. Does this mean that the Teiga library is included in gdal (it just needs to be included during the build)? Not having experimenting that driver myself, but presumably, you need the Open Design Alliance Teiga library when compiling GDAL and at runtime too. Thank you in advance. Regards, Miro ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] MinGW build
Selon Ari Jolma ari.jo...@gmail.com: Folks I'm building GDAL (the trunk) in latest MinGW. For some reason I don't understand I need to add -lstdc++ to LDFLAGS in GDALmake.opt. I'm not sure if this is the best way to fix the problem - probably not - but it works. The problem is the step where the library file libgdal.dll.a is made. Anybody have any ideas why this is like this? And is it specific to trunk (meaning does it work with 1.9 without adding -lstdc++) ? It's interesting since someone reported a few days/weeks ago a similar problem with CentOS I believe. I haven't in mind a change that would have directly targetted changing libstdc++ linking, but it is probably a side-effect of something else. Might depend on which external libs are linked too : perhaps some indirectly bring libstdc++ dependency, and when they are not linked in, it isn't found ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGR SQL: Excecuting select where column name contains .
Even Rouault wrote: Selon Jukka Rahkonen jukka.rahko...@mmmtike.fi: This should definitely work too, but it does not ogrinfo WFS:http://188.64.1.61/cgi-bin/tinyows -sql select code_reg from tows: france INFO: Open of `WFS:http://188.64.1.61/cgi-bin/tinyows' using driver `WFS' successful. ERROR 1: SQL Expression Parsing Error: syntax error Sorry for the undue judgement. This is the correct way to do it on Windows ogrinfo WFS:http://188.64.1.61/cgi-bin/tinyows -sql select 'nom.dept' from 'tows:dot.test' It is just always as hard for me to remember the right syntax. OGR SQL follows SQL on this : column and table/layer names are identifiers. So they must start with a letter or underscore, and subsequent characters must be letters, underscores or digits. If the identifier is more complex than that, it must be quoted. To follow SQL, it is recommended to you double-quote characters, which might require SHELL escaping since they are already in a double-quoted string, like : ogrinfo poly.shp -sql select eas_id from poly Yes, that's a good theory but it is not easy to use it on Windows. Does anybody in the world know how should this one be escaped? I have already tried to use ^ as inner double quotes but without success, as well as having two ^^ and three ^^^. gdal_devogrinfo WFS:http://188.64.1.61/cgi-bin/tinyows -sql select nom.dept from tows:dot.test INFO: Open of `WFS:http://188.64.1.61/cgi-bin/tinyows' using driver `WFS' successful. ERROR 1: SQL Expression Parsing Error: syntax error OGR currently also accepts quoting of column/table names with single-quote character (which is normally reserved for string literals), but this can lead to some ambiguity. If you use 'foo', OGR will currently choose the column name foo if it exists, instead of the string literal 'foo' as standard SQL would mandate. -Jukka- ___ 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] convert dwg/dgn to raster/vector files (windows)
thanks, yes that makes sence ;-) so basically with the dwg library I should be able to make the conversion using gdal, correct? As far as I know the library is available only to the open design alliance members (paid membership) correct? Regarding the dgn format, it should be able to read it and convert it to for example svg/png format. Am I right? Once again, thanks for the help. Regards, Miro On Saturday, January 10, 1970, Even Rouault even.roua...@mines-paris.org wrote: Selon Miro Karpis miroslav.kar...@gmail.com: Hi, please can you help me with following? I'm trying to find the best way to convert dgn/dwg files to vector(svg) and raster(png) formats. In the OGR Vector formats table http://www.gdal.org/ogr/ogr_formats.html is stated that dwg and dgn formats are compiled by default. No, have a look again ;-) Format Name CodeCompiled by default AutoCAD DWG DWG No Microstation DGNDGN Yes On another side I see in AutoCad dwg description http://www.gdal.org/ogr/drv_dwg.html that we need Open Design Alliance Teiga library. Does this mean that the Teiga library is included in gdal (it just needs to be included during the build)? Not having experimenting that driver myself, but presumably, you need the Open Design Alliance Teiga library when compiling GDAL and at runtime too. Thank you in advance. Regards, Miro ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGR SQL: Excecuting select where column name contains .
To follow SQL, it is recommended to you double-quote characters, which might require SHELL escaping since they are already in a double-quoted string, like : Yes, that's a good theory but it is not easy to use it on Windows. Does anybody in the world know how should this one be escaped? I have already tried to use ^ as inner double quotes but without success, as well as having two ^^ and three ^^^. Doh! my webmail client has changed what I have typed ! To escape double-quote in Windows shell, you need to put a backslash character before them. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] MinGW build
On 10/05/2012 06:57 PM, Even Rouault wrote: Selon Ari Jolma ari.jo...@gmail.com: Folks I'm building GDAL (the trunk) in latest MinGW. For some reason I don't understand I need to add -lstdc++ to LDFLAGS in GDALmake.opt. I'm not sure if this is the best way to fix the problem - probably not - but it works. The problem is the step where the library file libgdal.dll.a is made. Anybody have any ideas why this is like this? And is it specific to trunk (meaning does it work with 1.9 without adding -lstdc++) ? I don't know. I haven't been building with MinGW for a long time and it's starting to look that this time was a mistake too. I got libgdal.dll compiled but the Perl bindings seem even harder (the bindings dll does not load). While MinGW and MSYS seem to be improved, it still is a horror. Ari It's interesting since someone reported a few days/weeks ago a similar problem with CentOS I believe. I haven't in mind a change that would have directly targetted changing libstdc++ linking, but it is probably a side-effect of something else. Might depend on which external libs are linked too : perhaps some indirectly bring libstdc++ dependency, and when they are not linked in, it isn't found ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Topological pointer
Hi All, We are working on project which renders S57 dataset , I used GDAL for rendering GIS data and DOTSPATIAL for displaying map. Here I could read dataset , but can any one know how do we get Topological Indicator value 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] Topological pointer
Nikhil, Can you explain what you mean by topology indicator? On Fri, Oct 5, 2012 at 11:36 PM, Nikhil Sai Parupalli nikhil.parupa...@iictechnologies.com wrote: Hi All, We are working on project which renders S57 dataset , I used GDAL for rendering GIS data and DOTSPATIAL for displaying map. Here I could read dataset , but can any one know how do we get Topological Indicator value 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 -- 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
Re: [gdal-dev] update to overview resampling methods?
also any objection I change the parameters to upper case in gdaladdo docs, to be in line with the names in the code? Etienne On Fri, Oct 5, 2012 at 4:18 PM, Etienne Tourigny etourigny@gmail.com wrote: Hi Even, thanks for you time On Fri, Oct 5, 2012 at 1:36 PM, Even Rouault even.roua...@mines-paris.org wrote: Selon Etienne Tourigny etourigny@gmail.com: Hi list, I would like to know if the overview resampling methods listed on help pages are really up-to-date, because I found some discrepancies in the docs and code: - gdaladdo utility page / http://www.gdal.org/gdaladdo.html nearest,average,gauss,cubic,average_mp,average_magphase,mode - GDALDataset::BuildOverviews / http://www.gdal.org/classGDALDataset.html#a2aa6f88b3bbc840a5696236af11dde15 NEAREST, GAUSS, CUBIC, AVERAGE, MODE, AVERAGE_MAGPHASE or NONE NONE is a provision for drivers/users that would need to create the overview bands but don't want them to be initialized, because they use their own resampling method. - searching the code I found the following undocumented resampling methods (there may be others) AVERAGE_BIT2GRAYSCALE, AVERAGE_BIT2GRAYSCALE_MINISWHITE, AVERAGE_BIT2, AVERAGE_BIT2GR, NO_REGEN Internal implementation details of drivers. - gtiff overviews (in frmts/gtiff/gt_overviews.cpp) only mentions the following, does it also support all others? AVERAGE_BIT2, NEAR, AVERAGE, GAUSS They are specific cases it handles (some for optimizations), but they are not the only ones ok So I have a few questions: 1) why are some methods not listed in GDALDataset::BuildOverviews and gdaladdo docs average_mp, AVERAGE_BIT2*, NO_REGEN (there may be others) - average_mp is documented in gdaladdo as not ready for use in production, so could be likely undocumented in gdaladdo man page - AVERAGE_BIT2* stuff is internal implementation detail for computing overviews of 1-bit raster as a 8-bit band. Must not be documented in user doc. - NO_REGEN: implementation hack for Imagine overviews. Must not be documented in user doc I understand that these are set internally when a certain condition is met? 2) are there some methods which are not supported in specific drivers, such as e.g. CUBIC in the gtiff driver? The generic overview code is in gcore/overview.cpp. Unless some driver has a very specific implementation of IBuildOverview() not relying on gcore/overview.cpp, all methods should be available. GTiff and HFA have implementations of IBuildOverviews(), but that's to create the overview bands/files : at the end, they fallback to gcore/overview.cpp to compute the pixel values. ok 3) why is AVERAGE_MP considered unfit for use in the gdaladdo docs? and why is it still available? Historical remain ? Could likely be undocumented. ok I will remove it, should it be removed/commented from the code also? 4) AVERAGE_MAGPHASE has been reported as buggy by some QGIS users, could someone comment? see http://hub.qgis.org/issues/284 I've never used it, but my understanding of the code is that it is (should be) restricted to images whose datatype is one of the complex types, like CInt16, CInt32, CFloat32 or CFloat64. For other datatypes, I would tink it is interpreted as standard average, but my understanding of the code might be insufficient. 5) should the docs be updated and harmonized, including any driver-specific options, or are they too obscure to worry about? Some precision could be perhaps given by knowleagable people on what average_magphase does exactly (my undersanding is that it averages the real and imaginary components of source pixels, and then does some kind of re-normalization of the result), but no need to document the other internal stuff that are implementation details of drivers. ok thanks, if someone has official documentation/information on average_magphase please let me know. regards, Etienne ___ 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] update to overview resampling methods?
1) why are some methods not listed in GDALDataset::BuildOverviews and gdaladdo docs average_mp, AVERAGE_BIT2*, NO_REGEN (there may be others) - average_mp is documented in gdaladdo as not ready for use in production, so could be likely undocumented in gdaladdo man page - AVERAGE_BIT2* stuff is internal implementation detail for computing overviews of 1-bit raster as a 8-bit band. Must not be documented in user doc. - NO_REGEN: implementation hack for Imagine overviews. Must not be documented in user doc I understand that these are set internally when a certain condition is met? Actually, about AVERAGE_BIT2GRAYSCALE, I was a bit quick in my answer. It is a value that can be passed to BuildOverviews(). This has been implemented per http://trac.osgeo.org/gdal/ticket/1908 . Seems that the documentation part was never done. For NO_REGEN, if you're really curious about it, you'll have to study the HFA driver. (But only if you are bored and have nothing more interesting to do ;-)) 3) why is AVERAGE_MP considered unfit for use in the gdaladdo docs? and why is it still available? Historical remain ? Could likely be undocumented. ok I will remove it, should it be removed/commented from the code also? Undocumenting seems appropriate. As far as removing the implementation, you might want to check with the original committer (FrankW) ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] gdaladdo bus errors for large, LZW-compressed GTiff
While the topic of gdaladdo resampling methods is active... I get bus errors when I use gdaladdo's gauss resampling method for large, float32, LZW-compressed GTiff. This is repeatable. Using a different gdaladdo resampling method (e.g., average) on the same LZW-compressed GTiff works. When I decompress first, gdaladdo with gauss works. For smaller, LZW-compressed GTiff input, gdaladdo with gauss works. I'm using gdal 1.9.1 with internal libtiff, libgeotiff, libz on OS X 10.7. Hopefully this will involve a simple fix. Thanks. -David gdalinfo WV02_10JUL091534204-P1BS-1030010005B3D100__WV02_10JUL091533199-P1BS-103001000612DC00-DEM.tif Driver: GTiff/GeoTIFF Files: WV02_10JUL091534204-P1BS-1030010005B3D100__WV02_10JUL091533199-P1BS-103001000612DC00-DEM.tif Size is 17719, 14955 Coordinate System is: PROJCS[unnamed, GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4326]], PROJECTION[Polar_Stereographic], PARAMETER[latitude_of_origin,70], PARAMETER[central_meridian,-45], PARAMETER[scale_factor,1], PARAMETER[false_easting,0], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]]] Origin = (-20.404963798559038,-2284012.343544036149979) Pixel Size = (1.000,-1.000) Metadata: AREA_OR_POINT=Area Image Structure Metadata: COMPRESSION=LZW INTERLEAVE=BAND Corner Coordinates: Upper Left ( -20.405,-2284012.344) ( 50d 1'55.27W, 69d 3'39.06N) Lower Left ( -20.405,-2298967.344) ( 49d59'58.03W, 68d55'39.79N) Upper Right ( -183392.405,-2284012.344) ( 49d35'26.36W, 69d 4'26.88N) Lower Right ( -183392.405,-2298967.344) ( 49d33'39.31W, 68d56'27.28N) Center ( -192251.905,-2291489.844) ( 49d47'44.82W, 69d 0' 3.78N) Band 1 Block=256x256 Type=Float32, ColorInterp=Gray NoData Value=0 LZW-compressed, -r gauss: gdaladdo -r gauss WV02_10JUL091534204-P1BS-1030010005B3D100__WV02_10JUL091533199-P1BS-103001000612DC00-DEM.tif 2 4 8 16 32 0Bus error LZW-compressed, -r average: gdaladdo -r average WV02_10JUL091534204-P1BS-1030010005B3D100__WV02_10JUL091533199-P1BS-103001000612DC00-DEM.tif 2 4 8 16 32 0...10...20...30...40...50...60...70...80...90...100 - done. Decompressed, -r gauss: gdaladdo -r gauss WV02_10JUL091534204-P1BS-1030010005B3D100__WV02_10JUL091533199-P1BS-103001000612DC00-DEM_nolzw.tif 2 4 8 16 32 0...10...20...30...40...50...60...70...80...90...100 - done. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdaladdo bus errors for large, LZW-compressed GTiff
Le vendredi 05 octobre 2012 22:21:27, David Shean a écrit :
While the topic of gdaladdo resampling methods is active...
I get bus errors when I use gdaladdo's gauss resampling method for large,
float32, LZW-compressed GTiff. This is repeatable.
Repeatable on various large float32 LZW-compressed GTiff, or that particular
one
?
Using a different
gdaladdo resampling method (e.g., average) on the same LZW-compressed
GTiff works. When I decompress first, gdaladdo with gauss works.
For smaller, LZW-compressed GTiff input, gdaladdo with gauss works.
I'm using gdal 1.9.1 with internal libtiff, libgeotiff, libz on OS X 10.7.
Hopefully this will involve a simple fix. Thanks.
This is something very likely related to update-in-place TIFF support, so
generally not in the simple fix category. You might want to re-check with
GDAL trunk whose internal libtiff has received per
http://trac.osgeo.org/gdal/ticket/4771 a fix in that area (no promise that it
fixes your particular issue).
Otherwise, if you can provide a link to the dataset, I can try to see if I
reproduce.
That kind of bug really depends on how the imagery compress. I have created a
fake dataset with similar characteristics to yours with :
$ python
from osgeo import gdal
ds = gdal.GetDriverByName('GTiff').Create('buglzw.tif', 17719, 14955, \
1, gdal.GDT_Float32, options = ['TILED=YES', 'COMPRESS=LZW'])
ds.GetRasterBand(1).SetNoDataValue(0)
ds = None
And :
$ gdaladdo -r gauss buglzw.tif 2 4 8 16 32
0...10...20...30...40...50...60...70...80...90...100 - done.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] update to overview resampling methods?
On Fri, Oct 5, 2012 at 12:56 PM, Even Rouault even.roua...@mines-paris.orgwrote: 3) why is AVERAGE_MP considered unfit for use in the gdaladdo docs? and why is it still available? Historical remain ? Could likely be undocumented. ok I will remove it, should it be removed/commented from the code also? Undocumenting seems appropriate. As far as removing the implementation, you might want to check with the original committer (FrankW) Etienne, Are AVERAGE_MP and AVERAGE_MAGPHASE really different things? That seems odd. I don't know why it reports them as not ready for production use. I would not want them removed, but I don't mind them not being documented. I peeked at the qgis bug report about magphase but I see the test data is no longer available. If there are problems with magphase support that can be demonstrated and filed as a bug I'd be interested in resolving them. 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
[gdal-dev] GDAL WCS driver
I have encountered a couple of issues with the WCS driver of GDAL 1.9.0 when accessing my WCS 1.0.0 server. The WCS driver doesn't recognize the color interpretations of image bands. For example (from a server not accessible to the outside world): [dev:~] gdalinfo gdal_wcs_terrapixel.xml Driver: WCS/OGC Web Coverage Service Files: gdal_wcs_terrapixel.xml Size is 106056, 28584 Coordinate System is: PROJCS[NAD83 / UTM zone 15N, ... Origin = (260489.000,3667255.000) Pixel Size = (0.500,-0.500) Corner Coordinates: Upper Left ( 260489.000, 3667255.000) ( 95d34' 1.15W, 33d 7' 3.30N) Lower Left ( 260489.000, 3652963.000) ( 95d33'47.69W, 32d59'19.66N) Upper Right ( 313517.000, 3667255.000) ( 94d59'56.38W, 33d 7'40.78N) Lower Right ( 313517.000, 3652963.000) ( 94d59'45.90W, 32d59'56.96N) Center ( 287003.000, 3660109.000) ( 95d16'52.90W, 33d 3'31.34N) Band 1 Block=1024x512 Type=Byte, ColorInterp=Undefined Overviews: 53028x14292, 26514x7146, 13257x3573, 6628x1786, 3314x893, 1657x446, 828x223 Band 2 Block=1024x512 Type=Byte, ColorInterp=Undefined Overviews: 53028x14292, 26514x7146, 13257x3573, 6628x1786, 3314x893, 1657x446, 828x223 Band 3 Block=1024x512 Type=Byte, ColorInterp=Undefined Overviews: 53028x14292, 26514x7146, 13257x3573, 6628x1786, 3314x893, 1657x446, 828x223 Band 4 Block=1024x512 Type=Byte, ColorInterp=Undefined Overviews: 53028x14292, 26514x7146, 13257x3573, 6628x1786, 3314x893, 1657x446, 828x223 They're all Undefined. However, if I use GDAL to examine the 2x2 GeoTIFF sample image that GDAL requests from the WCS server to determine the band types, GDAL reports the information properly, of course: [dev:~] gdalinfo terra_gdal_sampler.tif Driver: GTiff/GeoTIFF Files: terra_gdal_sampler.tif Size is 2, 2 Coordinate System is: PROJCS[NAD83 / UTM zone 15N, ... Origin = (260488.500,3667255.500) Pixel Size = (1.000,-1.000) Metadata: AREA_OR_POINT=Area TIFFTAG_IMAGEDESCRIPTION=Geo.scene_id: terrapixel TIFFTAG_RESOLUTIONUNIT=1 (unitless) TIFFTAG_SOFTWARE=CubeWerx Suite 6.3.4 TIFFTAG_XRESOLUTION=1 TIFFTAG_YRESOLUTION=1 Image Structure Metadata: COMPRESSION=DEFLATE INTERLEAVE=PIXEL Corner Coordinates: Upper Left ( 260488.500, 3667255.500) ( 95d34' 1.17W, 33d 7' 3.32N) Lower Left ( 260488.500, 3667253.500) ( 95d34' 1.16W, 33d 7' 3.25N) Upper Right ( 260490.500, 3667255.500) ( 95d34' 1.09W, 33d 7' 3.32N) Lower Right ( 260490.500, 3667253.500) ( 95d34' 1.09W, 33d 7' 3.25N) Center ( 260489.500, 3667254.500) ( 95d34' 1.13W, 33d 7' 3.29N) Band 1 Block=2x2 Type=Byte, ColorInterp=Red Mask Flags: PER_DATASET ALPHA Band 2 Block=2x2 Type=Byte, ColorInterp=Green Mask Flags: PER_DATASET ALPHA Band 3 Block=2x2 Type=Byte, ColorInterp=Blue Mask Flags: PER_DATASET ALPHA Band 4 Block=2x2 Type=Byte, ColorInterp=Alpha Shouldn't it be able to retain this information? As it is, clients won't be able to utilize the Alpha channel. It looks like it's thrown away in the inforation being cached in the WCS_GDAL file: PreferredFormatGeoTIFF/PreferredFormat BandCount4/BandCount BandTypeByte/BandType There's no band description other than the count and data type and it doesn't attempt to retain the 2x2 sample GeoTIFF image, which is relatively small. There's also an oddity with the sample image requested. The request from GDAL in my http log is: base_url?datastore=cwtileSERVICE=WCSVERSION=1.0.0REQUEST=GetCoverageCOVERAGE=terrapixelFORMAT=GeoTIFFBBOX=260489,3667254,260490,3667255WIDTH=2HEIGHT=2CRS=EPSG:26915 As you can see in the gdalinfo of the WCS itself, the pixel resolution is 0.5m, but this request is for 1.0m, since WCS BBOX= coordinates use pixel-is-point sematics rather than pixel-is-area, this is requesting a different resolution from the native resolution and is going outside of the source-data area, which is advertised in the WCS DescribeCoverage as: gml:Envelope srsName=EPSG:26915 gml:pos dimension=2260489.25 3652963.25/gml:pos gml:pos dimension=2313516.75 3667254.75/gml:pos /gml:Envelope The gdalinfo interprets this (and the equivalent RectifiedGrid) information from the WCS correctly with the pixel-is-point semantic and converts it properly to GDAL's pixel-is-area semantic and displays: Upper Left ( 260489.000, 3667255.000) ( 95d34' 1.15W, 33d 7' 3.30N) Lower Left ( 260489.000, 3652963.000) ( 95d33'47.69W, 32d59'19.66N) Upper Right ( 313517.000, 3667255.000) ( 94d59'56.38W, 33d 7'40.78N) Lower Right ( 313517.000, 3652963.000) ( 94d59'45.90W, 32d59'56.96N) Center ( 287003.000, 3660109.000) ( 95d16'52.90W, 33d 3'31.34N) The same thing happens when requesting live data, which elevates this oddity to a bug. If I enter the following into my own application (which uses pixel-is-area semantics like GDAL does) for a 10m x 10m window at the top-left corner: [dev:~] cwplot gdal_wcs_terrapixel.xml format=gdal bbox=260489,3667245,260499,3667255
