[GRASS-dev] GDAL/Proj modules role in Grass

kavitesh.singh at wipro.com kavitesh.singh at wipro.com
Wed Apr 8 10:50:51 EDT 2009


Hi Markus, 

 

Thank you for prompt reply. I would like to further ask you few more
questions, and sure you would overlook my ignorance.

 

My requirement is to make a strip down GIS tool using GRASS engine
focusing on raster image for the time being and preferably on windows
platform.

 

I would prefer to use the GRASS data format so that I am not bounded on
any commercial file format for my application and also provide user the
option to use GRASS or Quantum GIS. 

 

Please highlight the following doubts:

1.    The grass would be providing me APIs where in I can take any
raster image, geo-reference it and then store in GRASS's native format.
Can you please point out to the modules I would require just to perform
this action?

2.    Once I have converted to the GRASS native format, I would like to
display the image in visual form. Now you have pointed to several
options available with the existing version. I wanted to know is the
display eventually like a photo viewer especially when GRASS is layering
the information one over another. Also would grass provide me some
standardized output in terms of jpg, bmp etc which I can display in any
application? Any pointers to the similar options available on windows
platform?

 

 

> 2.    The input to the GDAL can be any raster format like BMP,
GeoTIFF,

> TIFF, PNG etc. What would be the output format GDAL produces after it

> manipulates the original raster image.

 

> If the input is geo-coded incl. metadata, this is respected. Otherwise
it

> is imported as XY map.

 

So if the information is geo-coded already, GRASS would not perform any
additionally operation but will still convert and store in the native
format. Correct?

Additionally, if I have to display a GDAL processed input, does GRASS
let me do that? Or are there tools which will help me see and understand
what exactly is the output. (I hope I am able to present my point)

 

It is my understanding, that OGR would be similar to GDAL with focus on
the vector data, which is further converted to the GRASS native format
for processing and viewing.

 

I have worked mostly on windows platform, hence there are lot of
questions as GRASS is based on Linux and current winGrass version is
using the cygwin. Though I was reading the full windows version would be
out soon.

 

The architecture diagram was really helpful in getting the overall idea
of where all libraries fit in.

Thanks a lot..

 

Regards,

Kavitesh Singh

 

-----Original Message-----
From: neteler.osgeo at gmail.com [mailto:neteler.osgeo at gmail.com] On Behalf
Of Markus Neteler
Sent: Wednesday, April 08, 2009 06:52 PM
To: Kavitesh Singh 
Cc: GRASS developers list
Subject: Re: [GRASS-dev] GDAL/Proj modules role in Grass

 

On Wed, Apr 8, 2009 at 1:52 PM,  <kavitesh.singh at wipro.com> wrote:

> Hi All,

> 

> 

> 

> I am beginner at learning GRASS and was trying to understand the
overall

> architecture of GRASS using various libraries like GDAL/PROJ etc.

> 

> 

> 

> I wanted to know how GDAL and PROJ library fit into GRASS for raster

> processing of maps?

 

These libraries are requirements for GRASS (see more below).

 

> I would like to verify my understanding of GDAL with my current
reading for

> raster format like JPEG,BMP

> 

> 1.    It is used for geo-referencing any raster image by providing the

> corner file data. Does the geo-referencing internally call PROJ
library to

> reference according to any particular datum?

 

It depends:

- yes for r.proj and v.proj

- no for i.rectify

 

> 2.    The input to the GDAL can be any raster format like BMP,
GeoTIFF,

> TIFF, PNG etc. What would be the output format GDAL produces after it

> manipulates the original raster image.

 

If the input is geocoded incl. metadata, this is respected. Otherwise it

is imported as XY map.

 

> 3.    Once the output is generated, is it available for processing in
the

> memory or it produces some file which is later read by GRASS for

> visualization?

 

GRASS is storing its files in its internal format (except for r.external
and

v.external). So, yes, files are produced.

 

I have just drawn the GRASS architecture:

 

http://trac.osgeo.org/grass/browser/grass-web/trunk/images

-      grass6_arch.odg

-      grass6_arch.png

-      grass7_arch.odg

-      grass7_arch.png

 

(please improve!)

 

See also here:

http://download.osgeo.org/grass/grass6_progman/

 

> 4.    I wanted to know how GRASS uses the geo-referenced raster image
for

> display. Is it using some 3rd party library or has developed a display
panel

> specific to GIS needs.

 

There is both in different implementations:

- built-in display system (X11 based)

- Tcl based display system

- wxPython based display system

- Cairo based display system

- PS based display system

- PNG based display system

- HTML based display system

 

All of them are drivers.

 

> 5.    It is my understanding that GRASS data output directory is not
related

> to GDAL/PROJ.

 

Right. It is called GISBASE. See

http://grass.osgeo.org/grass64/manuals/html64_user/helptext.html

 

> This is native GRASS format and the GRASS engine displays the

> data on the panel using some inbuilt functions.

 

Right.

 

> Please excuse me, if the questions have been asked before also. I
would

> appreciate any help in this regard.

 

Hope this helps,

Markus


Please do not print this email unless it is absolutely necessary. 

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. 

www.wipro.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-dev/attachments/20090408/9ae6aa66/attachment-0001.html


More information about the grass-dev mailing list