AW: AW: [gdal-dev] gdalwarp and GTiff creation option NBITS
Hi Frank, I'm sorry for my missing response yet. Nevertheless thank you for your helpful explanation! But since it seems that there is no way getting gdal converted tif-files with creation option NBITS=1 properly displayed in MapInfo Professional, it might make sense looking for another shell program. This could work in-a-pipe and should convert a paletted gdal output file into a 1bit file without color table just IrfanView does. Do you know a free software tool that will fit my needs? Or is there another way to think about? If the behavior of MapInfo Professional isn't default I could contact Pitney Bowes for sure as well. But I wouldn't rather wait for a solution from there ... Thanks so far, Best regards Andreas Mit freundlichen Grüßen Im Auftrag Andreas Fischer Kreis Unna - Der Landrat Zentrale Datenverarbeitung Friedrich-Ebert-Straße 17 59425 Unna Fon 02 3 03 27-44 16 Fax 0 23 03 27-28 96 andreas.fisc...@kreis-unna.de www.kreis-unna.de -Ursprüngliche Nachricht- Von: fwarmer...@gmail.com [mailto:fwarmer...@gmail.com] Im Auftrag von Frank Warmerdam Gesendet: Dienstag, 15. Juni 2010 16:34 An: Fischer, Andreas Cc: gdal-dev@lists.osgeo.org Betreff: Re: AW: [gdal-dev] gdalwarp and GTiff creation option NBITS On Mon, Jun 14, 2010 at 11:06 AM, Fischer, Andreas andreas.fisc...@kreis-unna.de wrote: Hi Frank, thanks for your hints. I could finally use tiffinfo very easily from FWTools-Shell, for I'm testing with a windows machine :-) ... b) File transformed with gdalwarp (gdal-file) TIFFReadDirectory: Warning, Unknown field with tag 42113 (0xa481) encountered. TIFF Directory at offset 0x10a8036 (17465398) Image Width: 11812 Image Length: 11812 Bits/Sample: 1 Sample Format: unsigned integer Compression Scheme: None Photometric Interpretation: palette color (RGB from colormap) Samples/Pixel: 1 Rows/Strip: 5 Planar Configuration: single image plane Color Map: (present) Tag 42113: 255 c) gdal-file (b) opened with IrfanView and saved as a copy without changes TIFF Directory at offset 0x10a35bc (17446332) Image Width: 11812 Image Length: 11812 Resolution: 0, 0 pixels/inch Bits/Sample: 1 Compression Scheme: None Photometric Interpretation: min-is-white Orientation: row 0 top, col 0 lhs Samples/Pixel: 1 Rows/Strip: 5 Planar Configuration: single image plane Software: IrfanView Andreas, The most obvious difference between these is that the GDAL generated file has a color table while IrfanView does not save one with it's 1 bit output file. It would appear that some software packages do not properly support paletted one bit files. Unfortunately, because GDAL sees the min-is-white input file as paletted it produces a paletted output file. I cannot think of an easy way of avoiding this. 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 Diese E-Mail wurde beim Ausgang auf Viren geprueft. Wegen der potentiellen Gefahr auf den Uebertragungswegen wird zu einer Vireneingangskontrolle geraten. Eine Haftung für Virenfreiheit wird ausgeschlossen. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GDAL WMS Driver - Image Size
I am doing some testing of the WMS driver with gdal and have a question. If I define the SizeX and SizeY parameters as 2000px I would expect that the WMS request would request a image width and height of 2000. When I checked the log files GDAL is requesting a 976x976 image and then rescaling the returned image. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Geotiff AREA_OR_POINT
Am I correct in interpreting this post to mean that the pixel-is-area and pixel-is-point tiffs are read the exact same way by GDAL, with the only difference being in the value of the AREA_OR_POINT metadata key? Should viewers then be looking for the AREA_OR_POINT key in addition to the georeferencing information, and shift the display to center the top-left pixel on (0,0) if it's set to Point? That's my understanding, it's just a metadata tag there for use if you need it. I would say that viewers should only modify their behaviour from Area if they have the distinction for centre point vs. cell based views. I've seen it used to set centre-based TIN-like renderings, vs. cell-based image renderings - but there's nothing in the GDAL raster storage model that prevents you taking on either interpretation AFAIK, though the default is cell-based. (There can be a problem interpreting more flexible array formats like NetCDF, that can store irregularly spaced coordinate vectors for, say, the centres of cells on the X axis - and there's rarely any metadata (in the file) to say explicitly that it's centre- not corner-based. ) Cheers, Mike. On Tue, Jun 29, 2010 at 8:12 AM, Gillian WALTER gwal...@mdacorporation.com wrote: Hi, I'm trying to wrap my head around Geotiff's AREA_OR_POINT=Area versus AREA_OR_POINT=Point, and how that translates into GDAL. I've read the PixelIsPoint Raster Space and PixelIsArea Raster Space sections of the geotiff spec, and tried to find previous posts on the topic with very limited success ( http://osgeo-org.1803224.n2.nabble.com/GRASS-Problem-importing-geotiff-with-r-in-gdal-td1879130.html ). Am I correct in interpreting this post to mean that the pixel-is-area and pixel-is-point tiffs are read the exact same way by GDAL, with the only difference being in the value of the AREA_OR_POINT metadata key? Should viewers then be looking for the AREA_OR_POINT key in addition to the georeferencing information, and shift the display to center the top-left pixel on (0,0) if it's set to Point? Thanks, Gillian Walter Software Developer Geospatial Services Inc. 57 Auriga Drive - Suite 201 Ottawa, ON K2E 8B2 Telephone: (613) 727-1087 #245 Facsimile: (613) 727-5853 Email: gwal...@mdacorporation.com This e-mail and any attachments are intended solely for the use of the intended recipient(s) and may contain legally privileged, proprietary and/or confidential information. Any use, disclosure, dissemination, distribution or copying of this e-mail and any attachments for any purposes that have not been specifically authorized by the sender is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply e-mail and permanently delete all copies and attachments. The entire content of this e-mail is for information purposes only and should not be relied upon by the recipient in any way unless otherwise confirmed in writing by way of letter or facsimile. ___ 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] Geotiff AREA_OR_POINT
On 28-06-2010 23:21, Michael Sumner wrote: Am I correct in interpreting this post to mean that the pixel-is-area and pixel-is-point tiffsare read the exact same way by GDAL, with the only difference being in the value of theAREA_OR_POINT metadata key? Should viewers then be looking forthe AREA_OR_POINT key in addition to the georeferencing information, and shift thedisplay to center the top-left pixel on (0,0) if it's set to Point? That's my understanding, it's just a metadata tag there for use if you need it. I would say that viewers should only modify their behaviour from Area if they have the distinction for centre point vs. cell based views. I've seen it used to set centre-based TIN-like renderings, vs. cell-based image renderings - but there's nothing in the GDAL raster storage model that prevents you taking on either interpretation AFAIK, though the default is cell-based. (There can be a problem interpreting more flexible array formats like NetCDF, that can store irregularly spaced coordinate vectors for, say, the centres of cells on the X axis - and there's rarely any metadata (in the file) to say explicitly that it's centre- not corner-based. ) Cheers, Mike. netCDF grids created by GMT have always (~20 years) made that distinction and store that information. Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Geotiff AREA_OR_POINT
Thanks for the heads up, I've not used GMT versions of NetCDF much, or recently. The vast majority of NetCDF I've had to work with do not make this explicit, and this is about the most detailed discussion I've seen: http://www.mail-archive.com/cf-metad...@cgd.ucar.edu/msg00566.html Cheers, Mike. On Tue, Jun 29, 2010 at 8:33 AM, Joaquim Luis jl...@ualg.pt wrote: netCDF grids created by GMT have always (~20 years) made that distinction and store that information. Joaquim ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
RE: [gdal-dev] Modify an image color table?
Well elevation, particularly bathymetry, is an obvious application for colourmaps for negative data. Marco, I deal with colourmaps with negative values using the LUT vrt element instead of the ColorTable element. See below, (note the data is a single band raster, but the VRT exands this to 3 band RGB. VRTDataset rasterXSize=415 rasterYSize=340 VRTRasterBand dataType=Byte band=1 ColorInterpRed/ColorInterp ComplexSource SourceFilename relativeToVRT=1test.bil/SourceFilename SourceBand1/SourceBand LUT -5:0, -4:25, -3:50, -2:75, -1:100, 0:125, 1:150, 2:175, 3:200, 4:225, 5:250 /LUT /ComplexSource /VRTRasterBand VRTRasterBand dataType=Byte band=2 ColorInterpGreen/ColorInterp ComplexSource SourceFilename relativeToVRT=1test.bil/SourceFilename SourceBand1/SourceBand LUT -5:0, -4:25, -3:50, -2:75, -1:100, 0:125, 1:150, 2:175, 3:200, 4:225, 5:250 /LUT /ComplexSource /VRTRasterBand VRTRasterBand dataType=Byte band=3 ColorInterpBlue/ColorInterp ComplexSource SourceFilename relativeToVRT=1test.bil/SourceFilename SourceBand1/SourceBand LUT -5:0, -4:25, -3:50, -2:75, -1:100, 0:125, 1:150, 2:175, 3:200, 4:225, 5:250 /LUT /ComplexSource /VRTRasterBand /VRTDataset Luke -Original Message- From: gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Frank Warmerdam Sent: Friday, 25 June 2010 10:13 PM To: Marco Stelluti Cc: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] Modify an image color table? Marco Stelluti wrote: Hi, I'm a new gdal user and I've a little problem. I have to modify the color to an ASCII raster. 1_ I converted the raster using gdalbuildvrt; 2_ I modified the file *.vrt adding: ColorInterpPalette/ColorInterp ColorTable Entry c1=255 c2=255 c3=255 c4=255/ Entry c1=0 c2=0 c3=150 c4=255/ Entry c1=0 c2=0 c3=150 c4=255/ ... /ColorTable 3_ I know: The entries are ordered and will be assumed to start from color table entry 0 4_ But I have some negative value on the ASCII raster, the range is from -31 to 65. 5_ How I can resolve this problem? Marco, Generally speaking GDAL color maps do not have an obvious application to negative or non-integer data. You could use the raster attribute table mechanism to represent color assignments to negative values, but since so few applications make use of this data object it is nearly useless to do so. What application do you want the color table to work in? How you handle the situation will depend on the output application. If preserving the original pixel values isn't important you may want to reprocess/rescale your raster. 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 -- If you have received this transmission in error please notify us immediately by return e-mail and delete all copies. If this e-mail or any attachments have been sent to you in error, that error does not constitute waiver of any confidentiality, privilege or copyright in respect of information in the e-mail or attachments. Please consider the environment before printing this email. -- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] csharp dll hell
We have a legacy app that is using the csharp binaries. I tried to build the csharp bins using the visual studio 2008 command prompt. Everything works fine on the box that the bins were built on or any box that has visual studio (2009) installed but once it goes on a non-dev box, I start getting error on OSgeo.ogr.ogr.registerall(), can't find entry point. I made sure the redistro package for VS is installed and dependency walker doesn't give me much except that it says MSVCR90.dll cannot be found but if I scroll down the list I see MSVCR90.dll show next msvcp90.dll. I am building gdal 1.7.2 and using swigwin 1.3.31 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Support for SHAPEFILE to VMAP?
On Tue, Jun 29, 2010 at 3:41 AM, Axline, John john.axl...@ngc.com wrote: We have a need to generate VMAP files from ESRI shapefiles. The most-promising utility I’m aware of is OGR/OGDI, but that appears to perform only the opposite conversion, VMAP to SHP. Am I missing a capability, or another resource? Thanks, and apologies in advance for additional neophyte questions I’m certain to post… John, I am afraid that GDAL/OGR, and OGDI do not have any support for writing VPF. I'm not aware of any open source solution for writing VPF though something might exist. 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
