Date   
Re: [rasterio-dev] debugging build_overviews

Sean Gillies
 

Hi Guy,

Let's try to answer your questions on the main discussion group. The dev group is for discussing development of the library itself: new API methods, infrastructure, governance, &c. I've cross-posted to main@rasterio.groups.io.

Yes, if you configure and build a debug-enabled version of GDAL (see the GDAL wiki for instructions) and build Rasterio using that build you can run your program under gdb or lldb and set breakpoints in Rasterio and GDAL. However, there is very little logic in the Rasterio code around building overviews:


We do some pre-overview error handling and then call GDALBuildOverviews:


I have seen various reports of overview bugs in the old GDAL tracker, mostly fixed, but maybe there is a lingering one in your case. It may be worth a check in the tracker for open issues or ones that sound familiar.

Simpler than using a debugger: add some logging statements to rasterio/_io.pyx in a custom build of Rasterio to report the overview factors and resampling method passed to GDALBuildOverviews.

On Wed, Jan 2, 2019 at 1:59 AM Guy Doulberg <guyd@...> wrote:
Hi guys,

I wonder if you can give me some ideas about something,
I am working on a raster (with mask) that I am creating overviews on it.

It looks like that in some of the overviews (not all) I am getting artifacts, these artifacts looks like the product of using masked values in the resampling algo. 

How would you debug such a problem?

If I understand correctly some of the code that handles the build overviews is in cython code (rasterio) and some is part of GDAL c code.  Can I run a debug tool that I can traverse these two code bases and add breakpoints in them  

What else can I do?

artifact example:
first plot is of original data, the white spaces are masks:



and now in and overview for X8 resolution I get the black line



Any advice can help,

Thanks



--
Sean Gillies

Re: [rasterio-dev] Writing azure blobs does not create blobs

Sean Gillies
 

In https://github.com/OSGeo/gdal/issues/1189#issuecomment-452716305, Even reminds us that GDAL does not support writing TIFFs to S3 and I'm pretty sure that this applies to Azure as well. See the note about sequential writing at https://www.gdal.org/gdal_virtual_file_systems.html#gdal_virtual_file_systems_vsiaz.

On Fri, Jan 4, 2019 at 1:40 PM Sean Gillies <sean.gillies@...> wrote:
Hi Niklas,

First off, in my original reply I missed the chance to suggest that we move this discussion to the main (not dev) discussion group, which has more users. The dev group is for discussing and planning new features for the library. I'm going to cross post over to main@rasterio.groups.io and would appreciate it if you would follow up there.

Nothing in the logs jumps out at me, so I'm stumped. I don't have any experience using Azure blob storage and have never used GDAL or Rasterio to write to cloud objects of any kind. In my own applications, I write local files and then upload them to AWS S3 using the AWS Python SDK (boto3 &c). There may be some limitations or required GDAL configuration that I am not aware of.

Are you able to write blobs to the same Azure bucket using gdal_translate instead of a Rasterio program?

And of course, we really need to know what versions of Rasterio and GDAL are employed here and where they come from: PyPI or Conda-forge or where else?

On Thu, Jan 3, 2019 at 5:25 AM Niklas Heim <heim.niklas@...> wrote:
Hi Sean,

Thank you for your reply!
After setting the CURL_CA_BUNDLE environment variable I could run the above script without GDAL_HTTP_UNSAFESSL.
The logs with CPL_CURL_VERBOSE enabled are attached below. It looks like the new blob is not created?
...

Re: [rasterio-dev] Writing azure blobs does not create blobs

Niklas Heim <heim.niklas@...>
 

Hi Sean,

Thank you for you help and excuse the late reply! I will find another way of accomplishing this.

Best regards,
Niklas

Am Mi., 9. Jan. 2019 um 22:12 Uhr schrieb Sean Gillies via Groups.Io <sean=mapbox.com@groups.io>:

In https://github.com/OSGeo/gdal/issues/1189#issuecomment-452716305, Even reminds us that GDAL does not support writing TIFFs to S3 and I'm pretty sure that this applies to Azure as well. See the note about sequential writing at https://www.gdal.org/gdal_virtual_file_systems.html#gdal_virtual_file_systems_vsiaz.

On Fri, Jan 4, 2019 at 1:40 PM Sean Gillies <sean.gillies@...> wrote:
Hi Niklas,

First off, in my original reply I missed the chance to suggest that we move this discussion to the main (not dev) discussion group, which has more users. The dev group is for discussing and planning new features for the library. I'm going to cross post over to main@rasterio.groups.io and would appreciate it if you would follow up there.

Nothing in the logs jumps out at me, so I'm stumped. I don't have any experience using Azure blob storage and have never used GDAL or Rasterio to write to cloud objects of any kind. In my own applications, I write local files and then upload them to AWS S3 using the AWS Python SDK (boto3 &c). There may be some limitations or required GDAL configuration that I am not aware of.

Are you able to write blobs to the same Azure bucket using gdal_translate instead of a Rasterio program?

And of course, we really need to know what versions of Rasterio and GDAL are employed here and where they come from: PyPI or Conda-forge or where else?

On Thu, Jan 3, 2019 at 5:25 AM Niklas Heim <heim.niklas@...> wrote:
Hi Sean,

Thank you for your reply!
After setting the CURL_CA_BUNDLE environment variable I could run the above script without GDAL_HTTP_UNSAFESSL.
The logs with CPL_CURL_VERBOSE enabled are attached below. It looks like the new blob is not created?
...

Rasterio Resampling documentation needs some key descriptions such as the libraries to call

Eyal Saiet
 

Hello Rasterio community,
while I have been using GDAL-python for a few years, I am delighted to learn about Rasterio. Both in GDAL and Rasterio (matter of fact any programming) require detail and to be exact. For newcomers to Rasterio, the details are critical for a smooth adoption.

The Resampling documentation link  does not have key pieces. First, it misses the required import libraries:
import rasterio
from rasterio.warp import Affine, Resampling, reproject # this line is key for the resampling code to work
numpy as np

Second, along  the code I would highlight the read() method so numpy's shape would read all bands from the raster correctly. 

Thanks for an otherwise, excellent library and excellent project!  

Re: Rasterio Resampling documentation needs some key descriptions such as the libraries to call

Sean Gillies
 

Hi,

I'm glad you're liking the project and appreciate your comments about the documentation. I've made a new ticket to track these issues: https://github.com/mapbox/rasterio/issues/1596.

Yours,


On Fri, Jan 11, 2019 at 3:26 PM Eyal Saiet <ejsaiet@...> wrote:
Hello Rasterio community,
while I have been using GDAL-python for a few years, I am delighted to learn about Rasterio. Both in GDAL and Rasterio (matter of fact any programming) require detail and to be exact. For newcomers to Rasterio, the details are critical for a smooth adoption.

The Resampling documentation link  does not have key pieces. First, it misses the required import libraries:
import rasterio
from rasterio.warp import Affine, Resampling, reproject # this line is key for the resampling code to work
numpy as np

Second, along  the code I would highlight the read() method so numpy's shape would read all bands from the raster correctly. 

Thanks for an otherwise, excellent library and excellent project!  



--
Sean Gillies

Resampling raster error message: ValueError: Invalid source

Eyal Saiet
 

I am testing the Resamling code from the documentation-link, to resample a tiff file:
#resampling a raster
import rasterio
from rasterio.warp import Affine, Resampling, reproject
import numpy as np
src=rasterio.open(r'/home/esaiet/Documents/18_12_thesis_work/data/Aialik_glacier_bay.tif')
src_np=src.read()
newarr = np.empty(shape=(src_np.shape[0],round(src_np.shape[1] * 0.5), round(src_np.shape[2] * 0.5)))

aff = src.transform
newaff = Affine(aff.a / 0.5, aff.b, aff.c,aff.d, aff.e / 0.5, aff.f)

reproject(src, newarr,src_transform = aff,dst_transform = newaff,src_crs = src.crs,dst_crs = src.crs,resampling = Resampling.bilinear)
src.close()
But I am getting an error (ValueError: Invalid Source), I don't think it is the raster. Googling around did not find aynting. Perhaps the UTM projection is the problem!?
If the error was Invalid Source Image, then I would suspect a problem with the data source, but that does not seem to be the case.  I saw some post perhaps it is the "nodata" definition the probelm!? Thanks
--------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-31-cb98e54d177e> in <module>()
     12 
     13 reproject(src, newarr,src_transform = aff,dst_transform = newaff,src_crs = src.crs,dst_crs = src.crs,
---> 14     resampling = Resampling.bilinear)

/usr/local/lib/python3.6/dist-packages/rasterio/env.py in wrapper(*args, **kwds)
    371         else:
    372             with Env.from_defaults():
--> 373                 return f(*args, **kwds)
    374     return wrapper
    375 

/usr/local/lib/python3.6/dist-packages/rasterio/env.py in wrapper(*args, **kwds)
    594                                 param, full_kwds[param], inequality, version, reason))
    595 
--> 596             return f(*args, **kwds)
    597 
    598         return wrapper

/usr/local/lib/python3.6/dist-packages/rasterio/warp.py in reproject(source, destination, src_transform, gcps, src_crs, src_nodata, dst_transform, dst_crs, dst_nodata, src_alpha, dst_alpha, resampling, num_threads, init_dest_nodata, warp_mem_limit, **kwargs)
    295         src_alpha=src_alpha, resampling=resampling,
    296         init_dest_nodata=init_dest_nodata, num_threads=num_threads,
--> 297         warp_mem_limit=warp_mem_limit, **kwargs)
    298 
    299 

rasterio/_warp.pyx in rasterio._warp._reproject()

ValueError: Invalid source

Implementing -scale functionality of gdal_translate

linden.kyle@...
 

Is there any way to replicate the -scale functionality of gdal_translate in Rasterio to scale the input pixels of a geotiff to a different range?

Re: Implementing -scale functionality of gdal_translate

Sean Gillies
 

Hi,

Rasterio's rio-convert program can linearly scale pixels and apply offsets:

$ rio convert --help
Usage: rio convert [OPTIONS] INPUTS... OUTPUT

  Copy and convert raster datasets to other data types and formats.

  Data values may be linearly scaled when copying by using the --scale-ratio
  and --scale-offset options. Destination raster values are calculated as

    dst = scale_ratio * src + scale_offset

  For example, to scale uint16 data with an actual range of 0-4095 to 0-255
  as uint8:

    $ rio convert in16.tif out8.tif --dtype uint8 --scale-ratio 0.0625

  Format specific creation options may also be passed using --co. To tile a
  new GeoTIFF output file, do the following.

    --co tiled=true --co blockxsize=256 --co blockysize=256

  To compress it using the LZW method, add

    --co compress=LZW

Options:
  -o, --output PATH               Path to output file (optional alternative to
                                  a positional arg).
  -f, --format, --driver TEXT     Output format driver
  -t, --dtype [ubyte|uint8|uint16|int16|uint32|int32|float32|float64]
                                  Output data type.
  --scale-ratio FLOAT             Source to destination scaling ratio.
  --scale-offset FLOAT            Source to destination scaling offset.
  --rgb                           Set RGB photometric interpretation.
  --co, --profile NAME=VALUE      Driver specific creation options.See the
                                  documentation for the selected output driver
                                  for more information.
  --help                          Show this message and exit.

Different forms of scaling are possible if you use the Python API, numpy, and scikit-image.

Hope this helps,

On Fri, Jan 25, 2019 at 10:44 AM <linden.kyle@...> wrote:
Is there any way to replicate the -scale functionality of gdal_translate in Rasterio to scale the input pixels of a geotiff to a different range?



--
Sean Gillies

Re: Implementing -scale functionality of gdal_translate

linden.kyle@...
 

Thanks, Sean. I apologize for not clarifying this, but even though I referenced the gdal translate tool I was looking to do this through the Rasterio API. I was able to take a look at the code for rio convert, and I think I'll be able to figure it out from there.

Rasterio 1.0.14

Sean Gillies
 

Hi all,

Rasterio 1.0.14 is on PyPI now: https://pypi.org/project/rasterio/1.0.14/.

The changes are listed here: https://github.com/mapbox/rasterio/blob/master/CHANGES.txt#L4-L17. We've attempted to overhaul and improve the CRS class without breaking anything, Let me know if we've succeeded.

There are a couple changes in the OS X and Linux wheels. We now include GDAL 2.4.0 (skipping over 2.3.3) and have added HTTP/2 support.

--
Sean Gillies

Re: Rasterio 1.0.14

Madhav Desetty
 

Wow! This is awesome! I made similar changes to add GS support locally. I will pull 1.0.14 and see if all GCS related workflow works as expected in my Kubernetes cluster.

Thanks!

Madhav

Rasterio and pip 19

Sean Gillies
 

Hi all,

I was tripped up by the release of pip 19 and want to share what I learned so that you can avoid the same bruises.

Rasterio has a pyproject.toml file since version 1.0. This file specifies the build requirements of Rasterio, the packages you must have to build working modules from the source. These include Cython, because Rasterio is largely written in the Cython language, and Numpy, because Cython needs Numpy's C headers.

When pip 10 was released, it began to use this pyproject.toml file and you may have noticed that the old two-step build of Rasterio

  pip install numpy cython
  pip install --no-binary rasterio rasterio

wasn't necessary anymore. Pip would check the pyproject.toml file and install numpy and cython before moving on to Rasterio's own setup script. Note well that pip 10 would install numpy and cython into the site-packages folder of the currently active Python environment. Pip 19 changes this.

With pip 19, the default is to create a new temporary environment and install numpy and cython into it. And because I didn't specify versions in pyproject.toml, this means the latest numpy (1.16.0 as I type this). Extension modules compiled using the 1.16.0 headers aren't compatible with older versions of numpy. Importing them will result in a ValueError and a message about mismatched struct sizes.

In Rasterio's wheel-building system we have a different way of satisfying the build-time dependencies, but the new temporary environment snuck in, entailed a dependency on numpy 1.16.0 and then when we tested the wheels with versions of numpy that *should* have been compatible, we had failed tests. It was rather perplexing until I reminded myself to check the pip change log. The problem was easy enough to solve: we use the --no-build-isolation option of pip install and our builds go on as they did with earlier pip versions.

You'll see the same thing if you build wheels for production and then try to use them with an older version of numpy.

I'm hesitant to pin numpy in pyproject.toml because the right version sort of depends on your Python version. However, there's a potential stumbling block here that needs to be addressed. If anybody has more experience and wisdom to share about the new features of pip, I'm all ears.

--
Sean Gillies

Re: Rasterio and pip 19

Joris Van den Bossche
 

Op vr 25 jan. 2019 om 22:45 schreef Sean Gillies via Groups.Io <sean=mapbox.com@groups.io>:
I'm hesitant to pin numpy in pyproject.toml because the right version sort of depends on your Python version. However, there's a potential stumbling block here that needs to be addressed. If anybody has more experience and wisdom to share about the new features of pip, I'm all ears.

You can (nowadays) specify the numpy version depending on the python version in pyproject.toml, which should make this possible. Something like:
    "numpy==1.8.2; python_version<='3.4'",
    "numpy==1.9.3; python_version=='3.5'",
    "numpy==1.12.1; python_version=='3.6'",
    "numpy==1.13.1; python_version>='3.7'",
In principle we should always pin the numpy version to the oldest supported version (if using build isolation), as otherwise using the built package in an environment with another numpy version breaks, as you explained.

Last year, we added a pyproject.toml to pandas, but it gave a lot of problems (https://github.com/pandas-dev/pandas/issues/20775), related to the fact that the above python-dependent numpy version was not possible yet (environment markers in pyproject.toml files were not yet supported at that time) + build dependencies needed to be installed as wheels instead of from source (which can give problems on certain platforms for which there are no wheels; this is also fixed in the meantime in pip I think). So in the end we decided to remove it again for the next release.
But it seems we should maybe look into adding it again.

Joris

 

Re: Rasterio 1.0.14

Madhav Desetty
 

I setup rasterio 1.0.14 and try to do a rasterio.open with gs:// url and I get following error. I did set GOOGLE_APPLICATION_CREDENTIALS to json key file. What am I missing?

>>> import rasterio
>>> import rasterio as rio
>>> fp = rio.open("gs://pdd-stac/disasters/hurricane-harvey/0831/20170831_172754_101c_3b_Visual.tif")
Traceback (most recent call last):
  File "rasterio/_base.pyx", line 198, in rasterio._base.DatasetBase.__init__
  File "rasterio/_shim.pyx", line 64, in rasterio._shim.open_dataset
  File "rasterio/_err.pyx", line 205, in rasterio._err.exc_wrap_pointer
rasterio._err.CPLE_OpenFailedError: gs://pdd-stac/disasters/hurricane-harvey/0831/20170831_172754_101c_3b_Visual.tif: No such file or directory
 
During handling of the above exception, another exception occurred:
 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/madhavdesetty/.pyenv/versions/3.6.5/envs/venv365/lib/python3.6/site-packages/rasterio/env.py", line 421, in wrapper
    return f(*args, **kwds)
  File "/Users/madhavdesetty/.pyenv/versions/3.6.5/envs/venv365/lib/python3.6/site-packages/rasterio/__init__.py", line 216, in open
    s = DatasetReader(path, driver=driver, **kwargs)
  File "rasterio/_base.pyx", line 200, in rasterio._base.DatasetBase.__init__
rasterio.errors.RasterioIOError: gs://pdd-stac/disasters/hurricane-harvey/0831/20170831_172754_101c_3b_Visual.tif: No such file or directory
>>> rio.__version__
'1.0.14'
 
 

Re: Rasterio and pip 19

Sean Gillies
 

Thanks, Joris! I'm going to capture this in a rasterio ticket.

On Fri, Jan 25, 2019 at 3:28 PM Joris Van den Bossche <jorisvandenbossche@...> wrote:
Op vr 25 jan. 2019 om 22:45 schreef Sean Gillies via Groups.Io <sean=mapbox.com@groups.io>:
I'm hesitant to pin numpy in pyproject.toml because the right version sort of depends on your Python version. However, there's a potential stumbling block here that needs to be addressed. If anybody has more experience and wisdom to share about the new features of pip, I'm all ears.

You can (nowadays) specify the numpy version depending on the python version in pyproject.toml, which should make this possible. Something like:
    "numpy==1.8.2; python_version<='3.4'",
    "numpy==1.9.3; python_version=='3.5'",
    "numpy==1.12.1; python_version=='3.6'",
    "numpy==1.13.1; python_version>='3.7'",
In principle we should always pin the numpy version to the oldest supported version (if using build isolation), as otherwise using the built package in an environment with another numpy version breaks, as you explained.

Last year, we added a pyproject.toml to pandas, but it gave a lot of problems (https://github.com/pandas-dev/pandas/issues/20775), related to the fact that the above python-dependent numpy version was not possible yet (environment markers in pyproject.toml files were not yet supported at that time) + build dependencies needed to be installed as wheels instead of from source (which can give problems on certain platforms for which there are no wheels; this is also fixed in the meantime in pip I think). So in the end we decided to remove it again for the next release.
But it seems we should maybe look into adding it again.

Joris

 



--
Sean Gillies

Re: Rasterio 1.0.14

Madhav Desetty
 

@Sean
I think something is not right with the PyPI distribution of rasterio 1.0.14. I did pip install rasterio into a clean virtualenv and it installed rasterio. See the pip show rasterio output:

rio
---
Metadata-Version: 2.1
Name: rasterio
Version: 1.0.14
Summary: Fast and direct raster I/O for use with Numpy and SciPy
Home-page: https://github.com/mapbox/rasterio
Author: Sean Gillies
Author-email: sean@...
Installer: pip
License: BSD
Location: /usr/local/lib/python2.7/dist-packages
Requires: cligj, snuggs, click, enum34, attrs, affine, numpy, click-plugins
Classifiers:
  Development Status :: 4 - Beta
  Intended Audience :: Developers
  Intended Audience :: Information Technology
  Intended Audience :: Science/Research
  License :: OSI Approved :: BSD License
  Programming Language :: C
  Programming Language :: Cython
  Programming Language :: Python :: 2.7
  Programming Language :: Python :: 3.3
  Programming Language :: Python :: 3.4
....

However, when I look at site-packages at /usr/local/lib/python2.7/dist-packages/rasterio/ and code for path.py session.py there is no GSSession class or no gs:// paths in the remote schemes in path.py. I got around by git pull source from mapbox/rasterio and doing a local pip install -e . and the above code I pasted works. I don't know if something is wrong with PyPI package distribution. I am curious if others have had success with the latest rasterio 1.0.14 and the new features.
pip show rasterio

pip show rasterio

Re: Rasterio 1.0.14

Sean Gillies
 

Yes, you are absolutely right. Google cloud support landed in master and I failed to cherry pick it before 1.0.14 as I'd intended. Sorry! I'm going to release a 1.0.15 to fix this tonight.


On Sun, Jan 27, 2019 at 3:09 PM <madhav@...> wrote:
@Sean
I think something is not right with the PyPI distribution of rasterio 1.0.14. I did pip install rasterio into a clean virtualenv and it installed rasterio. See the pip show rasterio output:

rio
---
Metadata-Version: 2.1
Name: rasterio
Version: 1.0.14
Summary: Fast and direct raster I/O for use with Numpy and SciPy
Author: Sean Gillies
Author-email: sean@...
Installer: pip
License: BSD
Location: /usr/local/lib/python2.7/dist-packages
Requires: cligj, snuggs, click, enum34, attrs, affine, numpy, click-plugins
Classifiers:
  Development Status :: 4 - Beta
  Intended Audience :: Developers
  Intended Audience :: Information Technology
  Intended Audience :: Science/Research
  License :: OSI Approved :: BSD License
  Programming Language :: C
  Programming Language :: Cython
  Programming Language :: Python :: 2.7
  Programming Language :: Python :: 3.3
  Programming Language :: Python :: 3.4
....

However, when I look at site-packages at /usr/local/lib/python2.7/dist-packages/rasterio/ and code for path.py session.py there is no GSSession class or no gs:// paths in the remote schemes in path.py. I got around by git pull source from mapbox/rasterio and doing a local pip install -e . and the above code I pasted works. I don't know if something is wrong with PyPI package distribution. I am curious if others have had success with the latest rasterio 1.0.14 and the new features.
pip show rasterio

pip show rasterio



--
Sean Gillies

Re: Rasterio 1.0.14

Madhav Desetty
 

Great! I am good for now through local rasterio 1.0.14 packaging but happy to test out GS support  again once rasterio 1.0.15 is out.


On Sun, Jan 27, 2019 at 6:15 PM Sean Gillies via Groups.Io <sean=mapbox.com@groups.io> wrote:
Yes, you are absolutely right. Google cloud support landed in master and I failed to cherry pick it before 1.0.14 as I'd intended. Sorry! I'm going to release a 1.0.15 to fix this tonight.

On Sun, Jan 27, 2019 at 3:09 PM <madhav@...> wrote:
@Sean
I think something is not right with the PyPI distribution of rasterio 1.0.14. I did pip install rasterio into a clean virtualenv and it installed rasterio. See the pip show rasterio output:

rio
---
Metadata-Version: 2.1
Name: rasterio
Version: 1.0.14
Summary: Fast and direct raster I/O for use with Numpy and SciPy
Author: Sean Gillies
Author-email: sean@...
Installer: pip
License: BSD
Location: /usr/local/lib/python2.7/dist-packages
Requires: cligj, snuggs, click, enum34, attrs, affine, numpy, click-plugins
Classifiers:
  Development Status :: 4 - Beta
  Intended Audience :: Developers
  Intended Audience :: Information Technology
  Intended Audience :: Science/Research
  License :: OSI Approved :: BSD License
  Programming Language :: C
  Programming Language :: Cython
  Programming Language :: Python :: 2.7
  Programming Language :: Python :: 3.3
  Programming Language :: Python :: 3.4
....

However, when I look at site-packages at /usr/local/lib/python2.7/dist-packages/rasterio/ and code for path.py session.py there is no GSSession class or no gs:// paths in the remote schemes in path.py. I got around by git pull source from mapbox/rasterio and doing a local pip install -e . and the above code I pasted works. I don't know if something is wrong with PyPI package distribution. I am curious if others have had success with the latest rasterio 1.0.14 and the new features.
pip show rasterio

pip show rasterio



--
Sean Gillies



--
Madhav Desetty
Chief Software Architect
Airbus Aerial
(404) 918-0481

Rasterio 1.0.15

Sean Gillies
 

Hi all,

1.0.15 is available on PyPI now and fixes two problems with 1.0.14 and its binary wheels. The first is that 1.0.14 didn't have the advertised Google cloud storage support. The second is that the wheels lacked the advertised HTTP/2 support.

--
Sean Gillies

Re: Rasterio 1.0.15

Madhav Desetty
 

@Sean
Just tested 1.0.15, GS support works great! Thanks...

Madhav