Re: [gdal-dev] libecwj2 with multiple readers
Hi Mateusz, Looking at NCJP2FileView.cpp, I can see that most accesses to sm_Views are protected with CNCSJPCGlobalLock _Lock; Perhaps it should also be added to CNCSJP2FileView::Shutdown() which seems the only place in that file not protected by the lock. Best regards, Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] libecwj2 with multiple readers
On 16 January 2013 10:13, Even Rouault even.roua...@mines-paris.org wrote: Hi Mateusz, Looking at NCJP2FileView.cpp, I can see that most accesses to sm_Views are protected with CNCSJPCGlobalLock _Lock; Perhaps it should also be added to CNCSJP2FileView::Shutdown() which seems the only place in that file not protected by the lock. Hi Even, Lock is one side of the problem. The second one is non-deterministic nature static initialization and static deinitialisation issue. In this case, the latter. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] RPC transform
Hi I have a question about the RPC transform implemented in gdal_rpc.cpp. If a dem file is specified in the transform options (RPC_DEM) the file is sampled to retrieve the elevation of the transformed point. In the case where the dem file is a DTED file (which defines AREA_OR_POINT to POINT), shouldn't the pixel/line values in the dem file be offset by half a pixel to get the correct height? Thanks Yehiyam This message (including any attachments) issued by RAFAEL- ADVANCED DEFENSE SYSTEMS LTD. (hereinafter RAFAEL) contains confidential information intended for a specific individual and purpose, may constitute information that is privileged or confidential or otherwise protected from disclosure. If you are not the intended recipient, you should contact us immediately and thereafter delete this message from your system. You are hereby notified that any disclosure, copying, dissemination, distribution or forwarding of this message, or the taking of any action based on it, is strictly prohibited. If you have received this e-mail in error, please notify us immediately by e-mail mailto:law...@rafael.co.il and completely delete or destroy any and all electronic or other copies of the original message and any attachments thereof. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Removing Dangle lines in shape files
Siva, Is your code working? If not, what were the errors? On Wed, Jan 16, 2013 at 1:17 PM, SIVA RAMA KRISHNA s.r.kriis...@gmail.comwrote: Dear All, I am Trying to remove Dangle Lines from a shape file containing OGRLineString (polyline).I am thinking that if a line(2),line(3),line(4) crosses a another line(1) detecting the point of intersection and removing the part beyond line1 . I am employing following code and attaching it. Any suggestion is highly appreciated with Regards -- 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] how to test for version number in python with gdal 1.10 ?
Hi, Detection of gdal version in python using the following method fails when using gdal-1.10 . print gdal.VersionInfo(RELEASE_NAME) 1.10dev print( gdal.VersionInfo(RELEASE_NAME) = 1.7 ) False print( gdal.VersionInfo(RELEASE_NAME) = 1.10 ) True What is the recommended way to test for previous versions of gdal that is backwards compatible and that support 1.10? The following seems to work using VERSION_NUM: in 1.10dev: gdal.VersionInfo(VERSION_NUM) '110' print( int(gdal.VersionInfo(VERSION_NUM)) = 1900 ) True print( int(gdal.VersionInfo(VERSION_NUM)) = 110 ) True and in 1.9.2: print( int(gdal.VersionInfo(VERSION_NUM)) = 1900 ) True print( int(gdal.VersionInfo(VERSION_NUM)) = 110 ) False thanks, Etienne ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] how to test for version number in python with gdal 1.10 ?
The following seems to work using VERSION_NUM: in 1.10dev: gdal.VersionInfo(VERSION_NUM) '110' print( int(gdal.VersionInfo(VERSION_NUM)) = 1900 ) True print( int(gdal.VersionInfo(VERSION_NUM)) = 110 ) True and in 1.9.2: print( int(gdal.VersionInfo(VERSION_NUM)) = 1900 ) True print( int(gdal.VersionInfo(VERSION_NUM)) = 110 ) False This is actually what I've used recently in swig/python/samples/ogr_layer_algebra.py thanks, 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] RPC transform
Yehiyam, For that kind of issue my advise is to run in debugging mode. The GDAL transformation engine must have an internal pixel geolocation defined. It is probably CENTER of the pixel, as in AREA. I am not sure. In that case the returning pixel/line refers to AREA and you might need to do the adjustment. But again, I would debug it to make sure. We have instructions on how to debug GDAL using VS and NetBeans on wiki. I just can't find it. I can't find anything about the RPC_DEM either. Where did you get it? Regards, Ivan On 1/16/13 7:40 AM, Livneh Yehiyam wrote: Hi I have a question about the RPC transform implemented in gdal_rpc.cpp. If a dem file is specified in the transform options (RPC_DEM) the file is sampled to retrieve the elevation of the transformed point. In the case where the dem file is a DTED file (which defines AREA_OR_POINT to POINT), shouldn't the pixel/line values in the dem file be offset by half a pixel to get the correct height? Thanks Yehiyam This message (including any attachments) issued by RAFAEL- ADVANCED DEFENSE SYSTEMS LTD. (hereinafter RAFAEL) contains confidential information intended for a specific individual and purpose, may constitute information that is privileged or confidential or otherwise protected from disclosure. If you are not the intended recipient, you should contact us immediately and thereafter delete this message from your system. You are hereby notified that any disclosure, copying, dissemination, distribution or forwarding of this message, or the taking of any action based on it, is strictly prohibited. If you have received this e-mail in error, please notify us immediately by e-mail mailto:law...@rafael.co.il and completely delete or destroy any and all electronic or other copies of the original message and any attachments thereof. ___ 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] RPC transform
Hi Ivan, Look here: http://www.gdal.org/gdal__alg_8h.html#af4c3c0d4c79218995b3a1f0bac3700a0 You can find such options: * RPC_HEIGHT: a fixed height offset to be applied to all points passed in. In this situation the Z passed into the transformation function is assumed to be height above ground, and the RPC_HEIGHT is assumed to be an average height above sea level for ground in the target scene. * RPC_HEIGHT_SCALE: a factor used to multiply heights above ground. Usefull when elevation offsets of the DEM are not expressed in meters. (GDAL = 1.8.0) * RPC_DEM: the name of a GDAL dataset (a DEM file typically) used to extract elevation offsets from. In this situation the Z passed into the transformation function is assumed to be height above ground. This option should be used in replacement of RPC_HEIGHT to provide a way of defining a non uniform ground for the target scene (GDAL = 1.8.0) * RPC_DEMINTERPOLATION: the DEM interpolation (near, bilinear or cubic) Best regards, Dmitry 16.01.2013 19:54, Ivan Lucena ?: Yehiyam, For that kind of issue my advise is to run in debugging mode. The GDAL transformation engine must have an internal pixel geolocation defined. It is probably CENTER of the pixel, as in AREA. I am not sure. In that case the returning pixel/line refers to AREA and you might need to do the adjustment. But again, I would debug it to make sure. We have instructions on how to debug GDAL using VS and NetBeans on wiki. I just can't find it. I can't find anything about the RPC_DEM either. Where did you get it? Regards, Ivan On 1/16/13 7:40 AM, Livneh Yehiyam wrote: Hi I have a question about the RPC transform implemented in gdal_rpc.cpp. If a dem file is specified in the transform options (RPC_DEM) the file is sampled to retrieve the elevation of the transformed point. In the case where the dem file is a DTED file (which defines AREA_OR_POINT to POINT), shouldn't the pixel/line values in the dem file be offset by half a pixel to get the correct height? Thanks Yehiyam This message (including any attachments) issued by RAFAEL- ADVANCED DEFENSE SYSTEMS LTD. (hereinafter RAFAEL) contains confidential information intended for a specific individual and purpose, may constitute information that is privileged or confidential or otherwise protected from disclosure. If you are not the intended recipient, you should contact us immediately and thereafter delete this message from your system. You are hereby notified that any disclosure, copying, dissemination, distribution or forwarding of this message, or the taking of any action based on it, is strictly prohibited. If you have received this e-mail in error, please notify us immediately by e-mail mailto:law...@rafael.co.il and completely delete or destroy any and all electronic or other copies of the original message and any attachments thereof. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] how to test for version number in python with gdal 1.10 ?
ok merci. It might be good to write this somewhere? Not sure where though, perhaps the gdal/ogr wiki page? Etienne On Wed, Jan 16, 2013 at 1:40 PM, Even Rouault even.roua...@mines-paris.org wrote: The following seems to work using VERSION_NUM: in 1.10dev: gdal.VersionInfo(VERSION_NUM) '110' print( int(gdal.VersionInfo(VERSION_NUM)) = 1900 ) True print( int(gdal.VersionInfo(VERSION_NUM)) = 110 ) True and in 1.9.2: print( int(gdal.VersionInfo(VERSION_NUM)) = 1900 ) True print( int(gdal.VersionInfo(VERSION_NUM)) = 110 ) False This is actually what I've used recently in swig/python/samples/ogr_layer_algebra.py thanks, 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] how to test for version number in python with gdal 1.10 ?
On 16 January 2013 16:07, Etienne Tourigny etourigny@gmail.com wrote: It might be good to write this somewhere? Not sure where though, perhaps the gdal/ogr wiki page? It's documented in the comments of gdal_header.h http://svn.osgeo.org/gdal/trunk/gdal/gcore/gdal_version.h Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] how to test for version number in python with gdal 1.10 ?
On Wed, Jan 16, 2013 at 2:12 PM, Mateusz Loskot mate...@loskot.net wrote: On 16 January 2013 16:07, Etienne Tourigny etourigny@gmail.com wrote: It might be good to write this somewhere? Not sure where though, perhaps the gdal/ogr wiki page? It's documented in the comments of gdal_header.h http://svn.osgeo.org/gdal/trunk/gdal/gcore/gdal_version.h I meant it would be good to document the recommended way to test for version in *python* Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RPC transform
Yehiyam, I do not see why you think the AREA_OR_POINT value ought to have any influence on how DEM values are interpolated. Note that a PixelIsPoint GeoTIFF file will already result in a GDAL GeoTransform that is offset by half a pixel. The GDAL GeoTransform always treats pixels as areas, and GDAL interpolators - presumably including the for RPCs - should treat the pixel value as being at the center of the pixel area for the purpose of interpolation (regardless of whether that value is point or area). On the other hand, I am denying the possibility that the RPC DEM interpolation is always off by half a pixel. I haven't actually looked closely at that code lately and the RPC code is not so very well tested and validated. Best regards, Frank On Wed, Jan 16, 2013 at 4:40 AM, Livneh Yehiyam ye...@rafael.co.il wrote: Hi I have a question about the RPC transform implemented in gdal_rpc.cpp. If a dem file is specified in the transform options (RPC_DEM) the file is sampled to retrieve the elevation of the transformed point. In the case where the dem file is a DTED file (which defines AREA_OR_POINT to POINT), shouldn't the pixel/line values in the dem file be offset by half a pixel to get the correct height? ** ** Thanks Yehiyam This message (including any attachments) issued by RAFAEL- ADVANCED DEFENSE SYSTEMS LTD. (hereinafter RAFAEL) contains confidential information intended for a specific individual and purpose, may constitute information that is privileged or confidential or otherwise protected from disclosure. If you are not the intended recipient, you should contact us immediately and thereafter delete this message from your system. You are hereby notified that any disclosure, copying, dissemination, distribution or forwarding of this message, or the taking of any action based on it, is strictly prohibited. If you have received this e-mail in error, please notify us immediately by e-mail mailto:law...@rafael.co.il and completely delete or destroy any and all electronic or other copies of the original message and any attachments thereof. ___ 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
Re: [gdal-dev] RPC transform
Hi Frank, I only want to note that the default is bilinear interpolation of the DEM. Part of the code: const char *pszDEMInterpolation = CSLFetchNameValueDef( papszOptions, RPC_DEMINTERPOLATION, bilinear ); Best regards, Dmitriy 16.01.2013 22:47, Frank Warmerdam ?: Yehiyam, I do not see why you think the AREA_OR_POINT value ought to have any influence on how DEM values are interpolated. Note that a PixelIsPoint GeoTIFF file will already result in a GDAL GeoTransform that is offset by half a pixel. The GDAL GeoTransform always treats pixels as areas, and GDAL interpolators - presumably including the for RPCs - should treat the pixel value as being at the center of the pixel area for the purpose of interpolation (regardless of whether that value is point or area). On the other hand, I am denying the possibility that the RPC DEM interpolation is always off by half a pixel. I haven't actually looked closely at that code lately and the RPC code is not so very well tested and validated. Best regards, Frank On Wed, Jan 16, 2013 at 4:40 AM, Livneh Yehiyam ye...@rafael.co.il mailto:ye...@rafael.co.il wrote: Hi I have a question about the RPC transform implemented in gdal_rpc.cpp. If a dem file is specified in the transform options (RPC_DEM) the file is sampled to retrieve the elevation of the transformed point. In the case where the dem file is a DTED file (which defines AREA_OR_POINT to POINT), shouldn't the pixel/line values in the dem file be offset by half a pixel to get the correct height? Thanks Yehiyam This message (including any attachments) issued by RAFAEL- ADVANCED DEFENSE SYSTEMS LTD. (hereinafter RAFAEL) contains confidential information intended for a specific individual and purpose, may constitute information that is privileged or confidential or otherwise protected from disclosure. If you are not the intended recipient, you should contact us immediately and thereafter delete this message from your system. You are hereby notified that any disclosure, copying, dissemination, distribution or forwarding of this message, or the taking of any action based on it, is strictly prohibited. If you have received this e-mail in error, please notify us immediately by e-mail mailto:law...@rafael.co.il mailto:law...@rafael.co.il and completely delete or destroy any and all electronic or other copies of the original message and any attachments thereof. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org mailto: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 mailto:warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam http://pobox.com/%7Ewarmerdam 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 mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Giventiff with colortable, how do i assign one of the colors to be an alpha channel
Hi All, I have a tiff in which each pixel is a single byte (0-255) which references a colortable. Each element of the colortable has 4 values (RGBA). I would like to convert my black color (entry 1 in the color table (0,0,0,255)) to be transparent (new colortable entry is (0,0,0,0)) Another way to say it is, how do I create a tiff with an indexed colormap but also have it contain an alpha channel? Thanks in advance, Isaac ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Giventiff with colortable, how do i assign one of the colors to be an alpha channel
Le mercredi 16 janvier 2013 20:03:14, Isaac Gerg a écrit : Hi All, I have a tiff in which each pixel is a single byte (0-255) which references a colortable. Each element of the colortable has 4 values (RGBA). I would like to convert my black color (entry 1 in the color table (0,0,0,255)) to be transparent (new colortable entry is (0,0,0,0)) Another way to say it is, how do I create a tiff with an indexed colormap but also have it contain an alpha channel? TIFF color palette are only RGB, not RGBA. What you can do, however, is assign a nodata value (note this is a GDAL specific TIFF tag that will only be understood by GDAL based software) gdal_translate src.tif src_with_nodata.tif -a_nodata 0 You can create a TIFF with an indexed colormap and an alpha channel with the following extra steps : gdal_translate src_with_nodata.tif mask.tif -b mask gdalbuildvrt tmp.vrt src.tif mask.tif -separate gdal_translate src.tif src.vrt -of VRT the with a text editor copy the lines that look line the following ones from src.vrt ColorInterpPalette/ColorInterp ColorTable Entry c1=112 c2=120 c3=56 c4=255 / [...] Entry c1=204 c2=208 c3=164 c4=255 / /ColorTable and paste them just below VRTRasterBand dataType=Byte band=1 in tmp.vrt Finally : gdal_translate tmp.vrt pct_with_alpha.tif -co ALPHA=YES That's it. But I'm not sure that this will be properly displayed by viewers. A safest alternative would be to build a RGBA TIFF : gdal_translate -expand rgb src.tif rgb.tif gdal_translate -b 1 rgb.tif r.tif gdal_translate -b 2 rgb.tif g.tif gdal_translate -b 3 rgb.tif b.tif gdalbuildvrt rgba.vrt r.tif g.tif b.tif mask.tif -separate gdal_translate rgba.vrt rgba.tif -co ALPHA=YES Thanks in advance, Isaac ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Giventiff with colortable, how do i assign one of the colors to be an alpha channel
Even, Thanks for your quick response. I believe I understand that three options you presented me. I believe option 1 is viable but like you mentioned will only work with GDAL software. Options 2 and 3 are good but, especially with option 3, the resulting tifs are too large. I have 20 .tif which are 3MB a piece. Together, they form trackline of a sensor data. I would like to load this information into a WMS server for display in Google Earth or Arc Explorer. Currently I am using Geoserver. Anyways, I must mosaic these 20 .tifs together. These tifs are indexed images with a colormap. Here is my current algorithm: 1. Expand images to RGBA using gdal_translate 2. Rotate images north up using gdal_warp 3. Mosiac images using gdal_merge with -co COMPRESS=LZW -co PREDICTOR=1 -ot Byte -co TILED=YES -n 0 At this point, I now have an RGBA image that is huge (300MB). With all the tile collections I must process, 300MB is too big. I was thinking the total would be around (20 tiles)*(3MB per tile) = 60MB. 300 is simply unacceptable. 4. Run the gdal_retile to make image pyramid. This will yeild a size that is roughly twice that of my mosiac. Is there any way I can make the RGBA file in step 3 smaller in size specifically to match the theoretical size of 60MB? Thanks again, Isaac On Wed, Jan 16, 2013 at 2:21 PM, Even Rouault even.roua...@mines-paris.orgwrote: Le mercredi 16 janvier 2013 20:03:14, Isaac Gerg a écrit : Hi All, I have a tiff in which each pixel is a single byte (0-255) which references a colortable. Each element of the colortable has 4 values (RGBA). I would like to convert my black color (entry 1 in the color table (0,0,0,255)) to be transparent (new colortable entry is (0,0,0,0)) Another way to say it is, how do I create a tiff with an indexed colormap but also have it contain an alpha channel? TIFF color palette are only RGB, not RGBA. What you can do, however, is assign a nodata value (note this is a GDAL specific TIFF tag that will only be understood by GDAL based software) gdal_translate src.tif src_with_nodata.tif -a_nodata 0 You can create a TIFF with an indexed colormap and an alpha channel with the following extra steps : gdal_translate src_with_nodata.tif mask.tif -b mask gdalbuildvrt tmp.vrt src.tif mask.tif -separate gdal_translate src.tif src.vrt -of VRT the with a text editor copy the lines that look line the following ones from src.vrt ColorInterpPalette/ColorInterp ColorTable Entry c1=112 c2=120 c3=56 c4=255 / [...] Entry c1=204 c2=208 c3=164 c4=255 / /ColorTable and paste them just below VRTRasterBand dataType=Byte band=1 in tmp.vrt Finally : gdal_translate tmp.vrt pct_with_alpha.tif -co ALPHA=YES That's it. But I'm not sure that this will be properly displayed by viewers. A safest alternative would be to build a RGBA TIFF : gdal_translate -expand rgb src.tif rgb.tif gdal_translate -b 1 rgb.tif r.tif gdal_translate -b 2 rgb.tif g.tif gdal_translate -b 3 rgb.tif b.tif gdalbuildvrt rgba.vrt r.tif g.tif b.tif mask.tif -separate gdal_translate rgba.vrt rgba.tif -co ALPHA=YES Thanks in advance, Isaac ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Giventiff with colortable, how do i assign one of the colors to be an alpha channel
Le mercredi 16 janvier 2013 20:58:51, Isaac Gerg a écrit : Even, Thanks for your quick response. I believe I understand that three options you presented me. I believe option 1 is viable but like you mentioned will only work with GDAL software. Options 2 and 3 are good but, especially with option 3, the resulting tifs are too large. I have 20 .tif which are 3MB a piece. Together, they form trackline of a sensor data. I would like to load this information into a WMS server for display in Google Earth or Arc Explorer. Currently I am using Geoserver. Anyways, I must mosaic these 20 .tifs together. These tifs are indexed images with a colormap. Here is my current algorithm: 1. Expand images to RGBA using gdal_translate 2. Rotate images north up using gdal_warp 3. Mosiac images using gdal_merge with -co COMPRESS=LZW -co PREDICTOR=1 -ot Byte -co TILED=YES -n 0 At this point, I now have an RGBA image that is huge (300MB). With all the tile collections I must process, 300MB is too big. I was thinking the total would be around (20 tiles)*(3MB per tile) = 60MB. 300 is simply unacceptable. 4. Run the gdal_retile to make image pyramid. This will yeild a size that is roughly twice that of my mosiac. Is there any way I can make the RGBA file in step 3 smaller in size specifically to match the theoretical size of 60MB? You can try rgb2pct.py on the mosaic Or you can also try to gdal_translate -co COMPRESS=LZW on the mosaic, since I'm not sure how efficient the compression done by gdal_merge will be. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Giventiff with colortable, how do i assign one of the colors to be an alpha channel
rgb2pct.py does not work on tifs with indexed colormaps -- I have already tried this. I am already using COMPRESS=LZW on the mosiac. Isaac On Wed, Jan 16, 2013 at 3:17 PM, Even Rouault even.roua...@mines-paris.orgwrote: can also try to gdal_translate -co COMPRESS=LZW on the mosaic, since I'm not sure how efficient the compression done by gdal_ ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Giventiff with colortable, how do i assign one of the colors to be an alpha channel
I mispoke. rgb2pct.py will work but only on RGB images -- no colortables. When I use it on a RGBA image, the transparency is no longer preservered. Isaac On Wed, Jan 16, 2013 at 3:17 PM, Even Rouault even.roua...@mines-paris.orgwrote: Le mercredi 16 janvier 2013 20:58:51, Isaac Gerg a écrit : Even, Thanks for your quick response. I believe I understand that three options you presented me. I believe option 1 is viable but like you mentioned will only work with GDAL software. Options 2 and 3 are good but, especially with option 3, the resulting tifs are too large. I have 20 .tif which are 3MB a piece. Together, they form trackline of a sensor data. I would like to load this information into a WMS server for display in Google Earth or Arc Explorer. Currently I am using Geoserver. Anyways, I must mosaic these 20 .tifs together. These tifs are indexed images with a colormap. Here is my current algorithm: 1. Expand images to RGBA using gdal_translate 2. Rotate images north up using gdal_warp 3. Mosiac images using gdal_merge with -co COMPRESS=LZW -co PREDICTOR=1 -ot Byte -co TILED=YES -n 0 At this point, I now have an RGBA image that is huge (300MB). With all the tile collections I must process, 300MB is too big. I was thinking the total would be around (20 tiles)*(3MB per tile) = 60MB. 300 is simply unacceptable. 4. Run the gdal_retile to make image pyramid. This will yeild a size that is roughly twice that of my mosiac. Is there any way I can make the RGBA file in step 3 smaller in size specifically to match the theoretical size of 60MB? You can try rgb2pct.py on the mosaic Or you can also try to gdal_translate -co COMPRESS=LZW on the mosaic, since I'm not sure how efficient the compression done by gdal_merge will be. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Giventiff with colortable, how do i assign one of the colors to be an alpha channel
Le mercredi 16 janvier 2013 21:21:29, Isaac Gerg a écrit : I mispoke. rgb2pct.py will work but only on RGB images -- no colortables. When I use it on a RGBA image, the transparency is no longer preservered. Combine it with the first hints I gave ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Giventiff with colortable, how do i assign one of the colors to be an alpha channel
Even, I am confused. You said in your first response to me that TIFF does not support indexed colormaps of RGBA. Am I understanding you correctly -- it sounds like it is not possible to create an indexed color TIFF that has background transparency. Is this correct? Isaac On Wed, Jan 16, 2013 at 3:23 PM, Even Rouault even.roua...@mines-paris.orgwrote: Le mercredi 16 janvier 2013 21:21:29, Isaac Gerg a écrit : I mispoke. rgb2pct.py will work but only on RGB images -- no colortables. When I use it on a RGBA image, the transparency is no longer preservered. Combine it with the first hints I gave ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Giventiff with colortable, how do i assign one of the colors to be an alpha channel
To be clear, suppose I want to make the red bow in the image below as a tiff file with transparency. But instead of using RGBA, can tiff create it with indexed color? http://d241yswl6yg9sc.cloudfront.net/remove-background2/4.png Isaac On Wed, Jan 16, 2013 at 3:40 PM, Isaac Gerg isaac.g...@gergltd.com wrote: Even, I am confused. You said in your first response to me that TIFF does not support indexed colormaps of RGBA. Am I understanding you correctly -- it sounds like it is not possible to create an indexed color TIFF that has background transparency. Is this correct? Isaac On Wed, Jan 16, 2013 at 3:23 PM, Even Rouault even.roua...@mines-paris.org wrote: Le mercredi 16 janvier 2013 21:21:29, Isaac Gerg a écrit : I mispoke. rgb2pct.py will work but only on RGB images -- no colortables. When I use it on a RGBA image, the transparency is no longer preservered. Combine it with the first hints I gave ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RPC transform
Hi Frank, On the other hand, I am denying the possibility that the RPC DEM interpolation is always off by half a pixel. I haven't actually looked closely at that code lately and the RPC code is not so very well tested and validated. That is exactly what I understood from Yehiyam on his first message. We all believe that GDAL transformation knows the input dataset pixel reference; and knows the GCPs pixel reference. What we are not sure, is if it is doing the right thing when reading from the auxiliary DEM dataset in terms of pixel reference. Regards, Ivan ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RPC transform
Folks, As I often seem to do, I exactly stated my point. I meant write: On the other hand, I am *not* denying the possibility that the RPC DEM interpolation is always off by half a pixel in all cases. Sorry for that. On Wed, Jan 16, 2013 at 1:35 PM, Ivan Lucena ivan.luc...@princeton-ma.us wrote: Hi Frank, On the other hand, I am denying the possibility that the RPC DEM interpolation is always off by half a pixel. I haven't actually looked closely at that code lately and the RPC code is not so very well tested and validated. That is exactly what I understood from Yehiyam on his first message. We all believe that GDAL transformation knows the input dataset pixel reference; and knows the GCPs pixel reference. What we are not sure, is if it is doing the right thing when reading from the auxiliary DEM dataset in terms of pixel reference. Regards, Ivan -- ---+-- 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] RPC transform
On Wed, Jan 16, 2013 at 1:49 PM, Frank Warmerdam warmer...@pobox.com wrote: Folks, As I often seem to do, I exactly stated my point. I meant write: Garr, once again missing a keyword. I meant to say I exactly stated my point *wrong*. On the other hand, I am *not* denying the possibility that the RPC DEM interpolation is always off by half a pixel in all cases. Sorry for that. On Wed, Jan 16, 2013 at 1:35 PM, Ivan Lucena ivan.luc...@princeton-ma.us wrote: Hi Frank, On the other hand, I am denying the possibility that the RPC DEM interpolation is always off by half a pixel. I haven't actually looked closely at that code lately and the RPC code is not so very well tested and validated. That is exactly what I understood from Yehiyam on his first message. We all believe that GDAL transformation knows the input dataset pixel reference; and knows the GCPs pixel reference. What we are not sure, is if it is doing the right thing when reading from the auxiliary DEM dataset in terms of pixel reference. Regards, Ivan -- ---+-- 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 -- ---+-- 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] Creating Raster using Spatial Coordinates (Latitude and Longitude)
Hi, I am trying to create a Raster using grid of points(with latitude and longitude values) within an area which are separated at a distance measured in degrees. At higher latitudes the number of samples reduce that is number of points for a row reduces. When distance between points is determined with a fixed degree, how do I create a raster where the number of columns for higher latitudes reduces ? In this case, points for grid at higher latitudes are not exactly above the points at lower latitudes. Can some one suggest a way to create raster for spatial coordinates in this case? Thanks, Dheeraj ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Creating Raster using Spatial Coordinates (Latitude and Longitude)
I am using C# Gdal library. On Wed, Jan 16, 2013 at 5:25 PM, Dheeraj Reddy Mamidi drmam...@rothwellgroup.com wrote: Hi, I am trying to create a Raster using grid of points(with latitude and longitude values) within an area which are separated at a distance measured in degrees. At higher latitudes the number of samples reduce that is number of points for a row reduces. When distance between points is determined with a fixed degree, how do I create a raster where the number of columns for higher latitudes reduces ? In this case, points for grid at higher latitudes are not exactly above the points at lower latitudes. Can some one suggest a way to create raster for spatial coordinates in this case? Thanks, Dheeraj -- Dheeraj Reddy Mamidi Software Developer The Rothwell Group, L.P. Email: drmam...@rothwellgroup.com atvaug...@rothwellgroup.com Phone: 713-952-5355 ext.30 Web: www.rothwellgroup.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
