[GRASSLIST:7489] First reactions

Greetings,

I am fairly new to the GRASS list so I apologize if much of what I write has
been discussed in the past.

I recently had a renewed interest to evaluate GRASS as a remote sensing
and/or GIS tool to support our initiative to promote the use of open source
geospatial tools in conservation applications. Following are a few initial
reactions. Much of what I wrote is based on my thoughts after going through
the excellent tutorial that Markus Neteler prepared for the Open Source
Geospatial Conference recently held in Minneapolis, MN USA.

Up until this point I have been throwing most of my support behind a program
called OpenEV, primarily because it is easy to use and it handles most of
the basic visualization tasks quite well. As of GRASS version 6 I am more
seriously look at GRASS as an alternative or perhaps a compliment to OpenEV.
If I do get more involved with the GRASS community I would try to contribute
tutorials and perhaps even some software development help where needed. I
expect it will take a while for me to get a sense of who is doing what with
regard to GRASS development and where our efforts could best fit in.

I want to preface these comments by saying that they are heavily influenced
by my perception of our target audience. This audience is largely limited to
using Windows computers and the individuals' remote sensing and GIS skills
and interests are quite varied. Our intent is to provide something that
appeals to everyone, not just the "hard-core" geospatial crowd. Here are
some initial comments.

To start with, the installation goes much smoother than it used to but using
Cygwin is not an optimal solution to running GRASS on a PC. Windows users
want a look and feel that is similar to their other programs. Even
navigating for a file can be a chore for a Windows user. Using a phone modem
the installation process takes hours or days if a stable connection cannot
be maintained. Windows users want an installation that they can double-click
on and then the installation proceeds without problems. I find it easier to
run GRASS within Linux (on a Linux only computer) and that is the setup I am
using. Most of our users, however, would not want to deal with Linux.

Starting GRASS still brings up the "Data Selection" window. I find the
database / location / mapset structure to be restrictive. The benefit is
that everything is neat and tidy but there seems to be significant time and
disk space overhead and the process for defining a location is unnecessarily
complicated. Another drawback is that it is not possible to simply start
grass then open and immediately explore an image. If all image work was
based on a geographically defined area this approach might be acceptable but
for those instances (frequent for me) when you want to load an image and do
some simple processing the whole database/location framework is a pain.
Also, dealing with EPSG codes directly is somewhat cumbersome.

I expect this location/mapset restriction is the reason it is necessary to
restart GRASS 3 times when geocoding a scanned map. There must be a more
straightforward way to geocode images.

If GRASS would allow you to start the application, click on File => Open and
then have an image open in a viewer so a user could zoom, pan, read
coordinates, change bands. the interest in GRASS would increase by a factor
of 10 or more overnight. A user should not need to read a tutorial to simply
display an image of their choice. I am convinced that this instant appeal is
a critical hook to get more people interested in GRASS. The majority of
users aren't interested in the breadth of functionality offered by GRASS and
even if they are, if the most basic features are not easy to do they will
loose interest before they get into the "good" stuff. At the Open Source
Geospatial Conference Markus gave an impress presentation on GRASS 6 and
most of the people I spoke to were quite impressed. My concern is that when
those people go home and start GRASS they will be frustrated and may not
pursue it further.

Maybe the link with QGIS will fix some of this - it's hard to tell. There
was also some mention of combining some of the capabilities of GRASS with
the image processing capabilities of OSSIM. This merging of strengths would
be fantastic if indeed it is feasible. OSSIM appears to be using a state of
the art raster processing engine and GRASS had broad raster and growing
vector capabilities. I am very interested to know if anyone is following up
with this.

I realize that much of the power of GRASS is accessible through the command
line but for many people if this functionality is not available through an
intuitive menu structure then it is effectively not available.

One feature that I think would be quite useful is to add a calculator GUI to
the current map algebra option. The current r.mapcalculator work fine but in
my experience a GUI that resembles a calculator is more intuitive to use.

All in all I think GRASS has come a long way and I expect that I will begin
using it in some of our remote sensing training courses in the future. First
I need to become more proficient and knowledgeable with what GRASS can do
and how to efficiently accomplish a series of tasks.

I'll hold off additional, more specific comments until later. If anyone has
any comments or insight regarding what I wrote I would like to hear from
you.

All the best,

Ned
--
RS/GIS Program Manager
Center for Biodiversity and Conservation
American Museum of Natural History
Central Park West @ 79th St
New York, NY 10024
e-mail: horning@amnh.org
tel: 212-313-7947
fax: 212-769-5292
Home office tel: 802-382-9080
Web site: http://cbc.rs-gis.amnh.org/

Hello Ned,

thanks for your commendations, critics, proposals. It is indeed very helpful
to get to know the first impression because many users/developers are already
used to command-line & certain structures of GRASS which are entirely
incomprehensible for new users.

On Thursday 07 July 2005 18:42, you wrote:
[...]

I find
it easier to run GRASS within Linux (on a Linux only computer) and that is
the setup I am using. Most of our users, however, would not want to deal
with Linux.

I totally agree!
Installing GRASS on linux is quit easy, but for Windows an *.exe file is
missing. I am not familiar with the software-build problems, but as far as I
am aware of it, it is a license problem. Somebody has to pursue the exe-build
program. Please correct me if I am wrong.

[...]

Another drawback is that it is not possible to
simply start grass then open and immediately explore an image. If all image
work was based on a geographically defined area this approach might be
acceptable but for those instances (frequent for me) when you want to load
an image and do some simple processing the whole database/location
framework is a pain.[...]

I expect this location/mapset restriction is the reason it is necessary to
restart GRASS 3 times when geocoding a scanned map. There must be a more
straightforward way to geocode images.

If GRASS would allow you to start the application, click on File => Open
and then have an image open in a viewer so a user could zoom, pan, read
coordinates, change bands. the interest in GRASS would increase by a factor
of 10 or more overnight. A user should not need to read a tutorial to
simply display an image of their choice. I am convinced that this instant
appeal is a critical hook to get more people interested in GRASS.

Of course it is possible to enter a previously setup mapset and choose import
a raster into a newly generated one. However I fancy your proposal that the
user should be able to choose to look at the image first (r.in.gdal + d.mon
x0 + d.rast XY) without entering a location/mapset followed by an "generate
location/mapset" for the respective raster.

I don't know how easy it is to accomplish this "wish" but to zoom in and just
select a subset for import might be very interesting as well.

For other quick-looks tasks I would recommend QGIS.

I realize that much of the power of GRASS is accessible through the command
line but for many people if this functionality is not available through an
intuitive menu structure then it is effectively not available.

the d.m tcltk interface brings a pretty intuitive menu structure to GRASS
(compared to the former one) but to produce real "eye candy" a e.g. QT4 UI
project should be initialised.
Perhaps we should announce that we are looking for motivated OpenSource qt
programmer. ,-)

One feature that I think would be quite useful is to add a calculator GUI
to the current map algebra option. The current r.mapcalculator work fine
but in my experience a GUI that resembles a calculator is more intuitive to
use.

Event though I am already used to r.mapcalc and love how it works, a
calculator-like interface would lower the learning curve.

All in all I think GRASS has come a long way and I expect that I will begin
using it in some of our remote sensing training courses in the future.
First I need to become more proficient and knowledgeable with what GRASS
can do and how to efficiently accomplish a series of tasks.

Especially a recurring series of tasks is easily accomplished by GRASS using a
script - just mail if I shall send you an example script.

I think the most important thing GRASS needs are programmers who start helping
on solving bugs, wishes -- hopefully GRASS will attract them as well.

best regards, Martin

--
Martin Wegmann

DLR - German Aerospace Center
German Remote Sensing Data Center
@
Dept.of Geography
Remote Sensing and Biodiversity Unit
University of Wuerzburg
Am Hubland
97074 Würzburg

phone: +49-(0)931 - 888 4797
fax: +49-(0)931 - 888 4961
http://www.biota-africa.org
http://www.biogis.de

Mr. Horning,

Thank you for sharing your comments and observations. This kind of feedback is interesting to me as user, but it also probably helpful to the developers as well. I'm not on the GRASS development team, but you mentioned target audience and I think that the target audience for many GRASS developers, is themselves and other serious GIS users. With the advent of applications such as OpenEV and QGIS, the pressure for GRASS to be accessible to the naive user has lessened and although there have been great strides toward improving the ease of use of GRASS, it seems to me that the core effort has been to improve some of the backend power, such as the improved vector format and capabilities in version 6. Some of the features in GRASS that are helpful to the serious user are incovenient to the casual user, but I hope that these will not be sacrificed, as there is other sofware out there to support casual users. I think many GRASS users have both QGIS and GRASS on their systems along w!
ith GMT and possibly OSSIM and PostGIS and use each application as is best suited. Personally I'm very impressed with the cooperative efforts between the GRASS and QGIS development teams and having products that work in a complimentary fashion is in my opinion a much more realistic goal that creating a single monolithic application that does everything for everyone.

T
--
Trevor Wiens
twiens@interbaun.com

The greatest obstacle to discovery is not ignorance - it is the illusion of knowledge.
(Daniel J. Boorstin)

I am all for GUIs on things I use infrequently or where I just don't
want to spend weeks learning how they work. Let an expert set things
up and I will take their advise. I wouldn't use Linux, for example,
if it didn't have GUIs for things like printer and network
configuration, firewalls, etc. But in my area of expertise I want a
command line, I want full control. I AM the expert.

I think the division of QGIS and GRASS falls neatly into that
paradigm. If you are a casual GIS user, don't want to invest two weeks
into a program just to make a map. Use QGIS, that's what it's for. If,
on the other hand, you need to crunch gigabytes of complicated spatial
data, use GRASS. That's what it's for. The GUI/CLI debate is really
about meeting the needs of the casual vs hard-core users. Nobody is
hard-core about everything, but then again no one is causal about
everything either.

My 2 cents.

David

On 7/7/05, Martin Wegmann <wegmann@biozentrum.uni-wuerzburg.de> wrote:

Hello Ned,

thanks for your commendations, critics, proposals. It is indeed very helpful
to get to know the first impression because many users/developers are already
used to command-line & certain structures of GRASS which are entirely
incomprehensible for new users.

On Thursday 07 July 2005 18:42, you wrote:
[...]
>I find
> it easier to run GRASS within Linux (on a Linux only computer) and that is
> the setup I am using. Most of our users, however, would not want to deal
> with Linux.

I totally agree!
Installing GRASS on linux is quit easy, but for Windows an *.exe file is
missing. I am not familiar with the software-build problems, but as far as I
am aware of it, it is a license problem. Somebody has to pursue the exe-build
program. Please correct me if I am wrong.

[...]
> Another drawback is that it is not possible to
> simply start grass then open and immediately explore an image. If all image
> work was based on a geographically defined area this approach might be
> acceptable but for those instances (frequent for me) when you want to load
> an image and do some simple processing the whole database/location
> framework is a pain.[...]

> I expect this location/mapset restriction is the reason it is necessary to
> restart GRASS 3 times when geocoding a scanned map. There must be a more
> straightforward way to geocode images.
>
> If GRASS would allow you to start the application, click on File => Open
> and then have an image open in a viewer so a user could zoom, pan, read
> coordinates, change bands. the interest in GRASS would increase by a factor
> of 10 or more overnight. A user should not need to read a tutorial to
> simply display an image of their choice. I am convinced that this instant
> appeal is a critical hook to get more people interested in GRASS.

Of course it is possible to enter a previously setup mapset and choose import
a raster into a newly generated one. However I fancy your proposal that the
user should be able to choose to look at the image first (r.in.gdal + d.mon
x0 + d.rast XY) without entering a location/mapset followed by an "generate
location/mapset" for the respective raster.

I don't know how easy it is to accomplish this "wish" but to zoom in and just
select a subset for import might be very interesting as well.

For other quick-looks tasks I would recommend QGIS.

> I realize that much of the power of GRASS is accessible through the command
> line but for many people if this functionality is not available through an
> intuitive menu structure then it is effectively not available.

the d.m tcltk interface brings a pretty intuitive menu structure to GRASS
(compared to the former one) but to produce real "eye candy" a e.g. QT4 UI
project should be initialised.
Perhaps we should announce that we are looking for motivated OpenSource qt
programmer. ,-)

> One feature that I think would be quite useful is to add a calculator GUI
> to the current map algebra option. The current r.mapcalculator work fine
> but in my experience a GUI that resembles a calculator is more intuitive to
> use.

Event though I am already used to r.mapcalc and love how it works, a
calculator-like interface would lower the learning curve.

> All in all I think GRASS has come a long way and I expect that I will begin
> using it in some of our remote sensing training courses in the future.
> First I need to become more proficient and knowledgeable with what GRASS
> can do and how to efficiently accomplish a series of tasks.

Especially a recurring series of tasks is easily accomplished by GRASS using a
script - just mail if I shall send you an example script.

I think the most important thing GRASS needs are programmers who start helping
on solving bugs, wishes -- hopefully GRASS will attract them as well.

best regards, Martin

--
Martin Wegmann

DLR - German Aerospace Center
German Remote Sensing Data Center
@
Dept.of Geography
Remote Sensing and Biodiversity Unit
University of Wuerzburg
Am Hubland
97074 Würzburg

phone: +49-(0)931 - 888 4797
fax: +49-(0)931 - 888 4961
http://www.biota-africa.org
http://www.biogis.de

--
David Finlayson
Marine Geology & Geophysics
School of Oceanography
Box 357940
University of Washington
Seattle, WA 98195-7940
USA

Office: Marine Sciences Building, Room 112
Phone: (206) 616-9407
Web: http://students.washington.edu/dfinlays

Hi Ned,

To start with, the installation goes much smoother than it used to but
using Cygwin is not an optimal solution to running GRASS on a PC.
Windows users want a look and feel that is similar to their other
programs. Even navigating for a file can be a chore for a Windows
user. Using a phone modem the installation process takes hours or days
if a stable connection cannot be maintained. Windows users want an
installation that they can double-click on and then the installation
proceeds without problems. I find it easier to run GRASS within Linux
(on a Linux only computer) and that is the setup I am using. Most of
our users, however, would not want to deal with Linux.

If you have the chance, I highly recommend trying out the Mac OSX
version of GRASS prepared by Lorenzo Moretti. The installation & user
experience is as smooth as it gets. GRASS is inherently UNIX software
and it is a small miracle that it works with Windows at all. Most of the
developers use Linux, a number use the Mac, but I think only one uses
Windows.

A single click Windows install & runtime would have to contain cygwin &
all its warts. A couple of people have put together CDs containing both
GRASS and Cygwin with an install script for the whole lot. I have a
script for starting GRASS from an icon on the Windows desktop, but doing
so makes cygwin a GRASS slave.

But do try the Mac version if you have the chance. It is lightyears
ahead.

Starting GRASS still brings up the "Data Selection" window. I find the
database / location / mapset structure to be restrictive. The benefit
is that everything is neat and tidy but there seems to be significant
time and disk space overhead

Please explain this more.

and the process for defining a location is unnecessarily complicated.

It is designed to be explicit and reduce ambiguities down the road.
Having said that I'd love for it to be reworked into some sort of GUI
wizard with pull-down menus and things.

Another drawback is that it is not possible to simply start grass then
open and immediately explore an image. If all image work was based on
a geographically defined area this approach might be acceptable but
for those instances (frequent for me) when you want to load an image
and do some simple processing the whole database/location framework is
a pain.

[...]

If GRASS would allow you to start the application, click on File =>
Open and then have an image open in a viewer so a user could zoom,
pan, read coordinates, change bands. the interest in GRASS would
increase by a factor of 10 or more overnight.

If this is all you want to do, QGIS is much better as a data viewer for
GRASS and other GIS map formats.

Granted being able to see some progress soon after you start the program
is a great hook, but it only takes a minute with Markus's or Lorenzo's
tutorials to figure out how to bring up a map. (The g.region step isn't
intuitive at first though)

Also, dealing with EPSG codes directly is somewhat cumbersome.

But a Godsend if you already know the code. Saves you from the
unnecessarily complicated process for defining a location. It's a useful
way of bypassing the location setup if you have the code. Another trick
is to use the r.in.gdal or v.in.ogr "location" options to setup a new
location based on a geo-coded import file.

I expect this location/mapset restriction is the reason it is
necessary to restart GRASS 3 times when geocoding a scanned map.

Yup. It does tend to keep you honest and your data tidy though.

There must be a more straightforward way to geocode images.

gdal_translate and gdalwarp from gdal.org, which probably got installed
when you installed GRASS or OpenEV. e.g. I have written a script to do
thin plate spline rectification as a drop-in replacement for i.rectify
(i.warp -- not ready for prime time).

I realize that much of the power of GRASS is accessible through the
command line but for many people if this functionality is not
available through an intuitive menu structure then it is effectively
not available.

One feature that I think would be quite useful is to add a calculator
GUI to the current map algebra option. The current r.mapcalculator
work fine but in my experience a GUI that resembles a calculator is
more intuitive to use.

You should have seen it nine months ago! Yikes. The GUI is still young
and is getting better rapidly. Efforts are underway that lets QGIS use
GRASS as a backend to do simple processing & GIS commands.

regards,
Hamish

ps - try the Mac version.

> I find it easier to run GRASS within Linux (on a Linux only
> computer) and that is the setup I am using. Most of our users,
> however, would not want to deal with Linux.

I totally agree!
Installing GRASS on linux is quit easy, but for Windows an *.exe file
is missing. I am not familiar with the software-build problems, but
as far as I am aware of it, it is a license problem. Somebody has to
pursue the exe-build program. Please correct me if I am wrong.

No license problem. All the major cross platform GUI toolkits have free
software implementations: TclTk (what GRASS uses); Motif (GRASS's
xanim); gtk+ (wasn't someone working on a gtk frontend?); Java (jGRASS);
wxWidgets (no GRASS port AFAIK); and the latest release of QT (QGIS).

A GPL version of QT for Windows is the new change.

I believe the reason GRASS uses Tcl/Tk is that it was the best (or maybe
only) choice at the time. With the advent of the --interface-description
command line option and the r.* v.* breakdown, automatically generating
a GUI menu for each of the modules should be fairly straight forward
exercise. Then "all" that someone needs to do is the frontend.

But GRASS does require a UNIX environment to run in, so it has to use
something like Cygwin to provide that, along with all the complexity
that entails.

Hamish

On Friday 08 July 2005 10:09, Hamish wrote:
[...]

No license problem. All the major cross platform GUI toolkits have free
software implementations: TclTk (what GRASS uses); Motif (GRASS's
xanim); gtk+ (wasn't someone working on a gtk frontend?); Java (jGRASS);
wxWidgets (no GRASS port AFAIK); and the latest release of QT (QGIS).

A GPL version of QT for Windows is the new change.

thanks for the information - pretty diverse UI options.
BTW on kde-apps.org did chrischan
http://www.kde-apps.org/usermanager/search.php?username=crischan&PHPSESSID=ef2bde3fbf68d98f758201f8a55effc9
post a message that he/she wants to code a qt interface, however I don't know
the actual status.

[...]

But GRASS does require a UNIX environment to run in, so it has to use
something like Cygwin to provide that, along with all the complexity
that entails.

I did not know that. GRASS requires a UNIX environment and hence will never be
available as "*.exe"? Well, then does the Windows user world have to deal
with Cygwin.

thanks for clarifying these points, regards, Martin

--
Martin Wegmann

DLR - German Aerospace Center
German Remote Sensing Data Center
@
Dept.of Geography
Remote Sensing and Biodiversity Unit
University of Wuerzburg
Am Hubland
97074 Würzburg

phone: +49-(0)931 - 888 4797
fax: +49-(0)931 - 888 4961
http://www.biota-africa.org
http://www.biogis.de

Dear all,

Hi!, I am a geographer from Delhi. In my department, many 'closed' GIS softwares are being used with great efficiency. However, i don't think if any one's 'thinking' about it. I wish to read and then write something on free GIS and geography. If anyone of you has any references - articles or books - on the area of my new interest, then i'd really appreciate, if you could share them with me on the list.

I myself do not really know how to work on any of these softwares. But the very idea of closed softwares and GIS sounds bit oxymoronic to me.

waiting for enlightenment
ritika

Martin Wegmann wrote:

On Friday 08 July 2005 10:09, Hamish wrote:
[...]

No license problem. All the major cross platform GUI toolkits have free
software implementations: TclTk (what GRASS uses); Motif (GRASS's
xanim); gtk+ (wasn't someone working on a gtk frontend?); Java (jGRASS);
wxWidgets (no GRASS port AFAIK); and the latest release of QT (QGIS).

A GPL version of QT for Windows is the new change.

thanks for the information - pretty diverse UI options. BTW on kde-apps.org did chrischan http://www.kde-apps.org/usermanager/search.php?username=crischan&PHPSESSID=ef2bde3fbf68d98f758201f8a55effc9
post a message that he/she wants to code a qt interface, however I don't know the actual status.

[...]

But GRASS does require a UNIX environment to run in, so it has to use
something like Cygwin to provide that, along with all the complexity
that entails.

I did not know that. GRASS requires a UNIX environment and hence will never be available as "*.exe"? Well, then does the Windows user world have to deal with Cygwin.

thanks for clarifying these points, regards, Martin

Start your research here:

http://www.freegis.org

Many of the individual projects listed on that page have references.
There is also a book on GRASS written by Neteler and Mitasova:

http://mpa.itc.it/grassbook2/

That should keep you busy for a few days!

David

On 7/12/05, ritika@sarai.net <ritika@sarai.net> wrote:

Dear all,

Hi!, I am a geographer from Delhi. In my department, many 'closed' GIS
softwares are being used with great efficiency. However, i don't think
if any one's 'thinking' about it. I wish to read and then write
something on free GIS and geography. If anyone of you has any references
- articles or books - on the area of my new interest, then i'd really
appreciate, if you could share them with me on the list.

I myself do not really know how to work on any of these softwares. But
the very idea of closed softwares and GIS sounds bit oxymoronic to me.

waiting for enlightenment
ritika

Martin Wegmann wrote:
> On Friday 08 July 2005 10:09, Hamish wrote:
> [...]
>
>>No license problem. All the major cross platform GUI toolkits have free
>>software implementations: TclTk (what GRASS uses); Motif (GRASS's
>>xanim); gtk+ (wasn't someone working on a gtk frontend?); Java (jGRASS);
>>wxWidgets (no GRASS port AFAIK); and the latest release of QT (QGIS).
>>
>>A GPL version of QT for Windows is the new change.
>
>
> thanks for the information - pretty diverse UI options.
> BTW on kde-apps.org did chrischan
> http://www.kde-apps.org/usermanager/search.php?username=crischan&PHPSESSID=ef2bde3fbf68d98f758201f8a55effc9
> post a message that he/she wants to code a qt interface, however I don't know
> the actual status.
>
> [...]
>
>>But GRASS does require a UNIX environment to run in, so it has to use
>>something like Cygwin to provide that, along with all the complexity
>>that entails.
>
>
> I did not know that. GRASS requires a UNIX environment and hence will never be
> available as "*.exe"? Well, then does the Windows user world have to deal
> with Cygwin.
>
> thanks for clarifying these points, regards, Martin
>
>
>

--
David Finlayson
Marine Geology & Geophysics
School of Oceanography
Box 357940
University of Washington
Seattle, WA 98195-7940
USA

Office: Marine Sciences Building, Room 112
Phone: (206) 616-9407
Web: http://students.washington.edu/dfinlays

--
David Finlayson
Marine Geology & Geophysics
School of Oceanography
Box 357940
University of Washington
Seattle, WA 98195-7940
USA

Office: Marine Sciences Building, Room 112
Phone: (206) 616-9407
Web: http://students.washington.edu/dfinlays

I have published two papers about GRASS:

GROHMANN, C. H., 2005. Trend-surfaces analysis of morphometric parameters.
Computers & Geosciences.
http://dx.doi.org/10.1016/j.cageo.2005.02.011

GROHMANN, C.H. 2004. Morphometric analysis in Geographic Information
Systems: applications of free software GRASS and R. Computers &
Geosciences, 30 (9-10):1055-1067.
http://dx.doi.org/10.1016/j.cageo.2004.08.002

If you need, I can send you the pdfs

Carlos

On 7/12/05, David Finlayson <david.p.finlayson@gmail.com> wrote:

Start your research here:

http://www.freegis.org

Many of the individual projects listed on that page have references.
There is also a book on GRASS written by Neteler and Mitasova:

http://mpa.itc.it/grassbook2/

That should keep you busy for a few days!

David

On 7/12/05, ritika@sarai.net <ritika@sarai.net> wrote:
> Dear all,
>
> Hi!, I am a geographer from Delhi. In my department, many 'closed' GIS
> softwares are being used with great efficiency. However, i don't think
> if any one's 'thinking' about it. I wish to read and then write
> something on free GIS and geography. If anyone of you has any references
> - articles or books - on the area of my new interest, then i'd really
> appreciate, if you could share them with me on the list.
>
> I myself do not really know how to work on any of these softwares. But
> the very idea of closed softwares and GIS sounds bit oxymoronic to me.
>
> waiting for enlightenment
> ritika
>
> Martin Wegmann wrote:
> > On Friday 08 July 2005 10:09, Hamish wrote:
> > [...]
> >
> >>No license problem. All the major cross platform GUI toolkits have free
> >>software implementations: TclTk (what GRASS uses); Motif (GRASS's
> >>xanim); gtk+ (wasn't someone working on a gtk frontend?); Java (jGRASS);
> >>wxWidgets (no GRASS port AFAIK); and the latest release of QT (QGIS).
> >>
> >>A GPL version of QT for Windows is the new change.
> >
> >
> > thanks for the information - pretty diverse UI options.
> > BTW on kde-apps.org did chrischan
> > http://www.kde-apps.org/usermanager/search.php?username=crischan&PHPSESSID=ef2bde3fbf68d98f758201f8a55effc9
> > post a message that he/she wants to code a qt interface, however I don't know
> > the actual status.
> >
> > [...]
> >
> >>But GRASS does require a UNIX environment to run in, so it has to use
> >>something like Cygwin to provide that, along with all the complexity
> >>that entails.
> >
> >
> > I did not know that. GRASS requires a UNIX environment and hence will never be
> > available as "*.exe"? Well, then does the Windows user world have to deal
> > with Cygwin.
> >
> > thanks for clarifying these points, regards, Martin
> >
> >
> >
>
>

--
David Finlayson
Marine Geology & Geophysics
School of Oceanography
Box 357940
University of Washington
Seattle, WA 98195-7940
USA

Office: Marine Sciences Building, Room 112
Phone: (206) 616-9407
Web: http://students.washington.edu/dfinlays

--
David Finlayson
Marine Geology & Geophysics
School of Oceanography
Box 357940
University of Washington
Seattle, WA 98195-7940
USA

Office: Marine Sciences Building, Room 112
Phone: (206) 616-9407
Web: http://students.washington.edu/dfinlays

--
+-----------------------------------------------------------+
              Carlos Henrique Grohmann - Guano
  Geologist M.Sc - Doctorate Student at IGc-USP - Brazil
Linux User #89721 - carlos dot grohmann at gmail dot com
+-----------------------------------------------------------+

On Tue, Jul 12, 2005 at 02:30:21PM +0200, Martin Wegmann wrote:

On Friday 08 July 2005 10:09, Hamish wrote:

...

> But GRASS does require a UNIX environment to run in, so it has to use
> something like Cygwin to provide that, along with all the complexity
> that entails.

I did not know that. GRASS requires a UNIX environment and hence will never be
available as "*.exe"? Well, then does the Windows user world have to deal
with Cygwin.

Work is ongoing at University of Trento to port GRASS to MS-Windows
as generic EXE/DLLs using MingW compiler. Most of the libraries are
done, module testing is ongoing. Once working, Cygwin will be no longer
needed (although maybe helpful for scripting etc).

Markus

On Wed, Jul 13, 2005 at 02:25:41AM +0530, ritika@sarai.net wrote:

Dear all,

Hi!, I am a geographer from Delhi. In my department, many 'closed' GIS
softwares are being used with great efficiency. However, i don't think
if any one's 'thinking' about it. I wish to read and then write
something on free GIS and geography. If anyone of you has any references
- articles or books - on the area of my new interest, then i'd really
appreciate, if you could share them with me on the list.

I myself do not really know how to work on any of these softwares. But
the very idea of closed softwares and GIS sounds bit oxymoronic to me.

waiting for enlightenment
ritika

In additions to the other postings you can get more references here:

http://citeseer.ist.psu.edu/cis?q=grass+gis&submit=Search+Documents&cs=1

http://scholar.google.com/scholar?hl=en&lr=&q=grass+gis&btnG=Search

http://www.citeulike.org/search/all?f=abstract&q=grass+gis

http://www.gdf-hannover.de/literature#litverweise

Best regards

Markus

On Wednesday 13 July 2005 09:42, Markus Neteler wrote:
[...]

> > But GRASS does require a UNIX environment to run in, so it has to use
> > something like Cygwin to provide that, along with all the complexity
> > that entails.
>
> I did not know that. GRASS requires a UNIX environment and hence will
> never be available as "*.exe"? Well, then does the Windows user world
> have to deal with Cygwin.

Work is ongoing at University of Trento to port GRASS to MS-Windows
as generic EXE/DLLs using MingW compiler. Most of the libraries are
done, module testing is ongoing. Once working, Cygwin will be no longer
needed (although maybe helpful for scripting etc).

that would be indeed a very huge step forward for Windows users and probably
will give GRASS a huge boost. Looking forward to it even though I do not use
Windows but then I can advertise GRASS better to the majority of my
colleagues.

cheers, Maritn