[GRASSLIST:9007] ArcView vs GRASS

GRASS GRASS user
21

Dear GRASS Community:

This discussion is far too interesting to pass making some comments. First off, I could not agree more with most (if not all) comments. The price/performance comparison alone makes GRASS the easy winner and the user support is outrageously good. I work for aU.S. federal agency and admittedly the GRASS community is small by comparison to ESRI. That's an irony, of course, since GRASS was developed by the U.S. Army Corps of Engineers. What is also ironic is that there is a strong analogy between ESRI/GRASS and the MS-Windows/Intel versus Apple Macintosh/Linux world — but with an interesting twist. The reason many have identified for the groundswell of GIS users using ESRI software is ease of use with the GUI which purportedly is not available with GRASS. Some comments have shown this is not quite the case.

The lack of cross-platform support with ESRI software is a huge issue with many and has caused significant problems in my agency due to the fact that our real-time operational environment is Linux; we would like to have GIS intimately intertwined with our operational environment at each workstation (having multiple monitors) but this really crowds the desktop space not to mention that one would have to use simultaneously a MS-Windows environment on one computer and Linux on the other — what a mess!! So, I have been gently pushing GRASS when the opportunity presents itself.

For much of what we do at U.S. National Weather Service (NWS) River Forecast Centers involves handling large amounts of GIS data repetitively. This means that scripts must be used to handle the analysis of these data. It is quite easy in GRASS to write simple shell, Perl, or whatever scripts to handle the data analysis requirements we have.

I should also add the importance of GRASS/QGIS interoperability and interoperability with R, gstat, GMT, etc. Combined, these make an incredibly powerful GIS environment that easily rivals the ESRI world. ESRI still holds the marketing edge with the perception of creating stunning maps, which captures the attention of end-users. Probably a stronger tie between GMT and GRASS would help.

GRASS rocks!

Māris Nartišs wrote:

Hi,

I'm leading GIS practical works for students and we use ArcGIS. Most
of students after those practical works have no clue why they where
pressing all those buttons, they even have no clue what is coordinate
system and why they should define it. Formally they are educated GIS
users, but in reality they are dumb as brick. I have to agree - easy
to use systems may lead to dumb users - You can do all stuff without
understanding why You are doing this.

On 11. 11. 2005. we had so called "GIS Day". I was there with
presentation about Open Source. There was some interest from some huge
(in local terms :wink: companies about OS GIS solutions. Most of interest
was about MapServer - looks like this will be OS GIS tool No. 1. in
nearest future. Most of ppl are not ready for open source and are not
ready to think, but I'm doing my best to show that OS GIS can be used
instead of closed source tools.

As I see, GDAL/OGR has Geodatabase support, as ESRI has published its
shema, only problem - it can be accessed via ODBC. There is a mdb read
library on SF.net. We need someone to put all this stuff in one peace.

With thanks to all OS developers and supporters,
Maris Nariss.

2005/11/13, Francisco Alonso <alonsarp@um.es>:

Hi all,

I have been teaching GIS using GRASS for years and definitively good students
adquire a better knowledge about what GIS is than using ArcView. However the
ironic result is that when they have a job, and they have it easely, they
have to work with ArcView "because it is what their employers bought". At the
end they do the stuff in GRASS and show it with Arc.View!

Best regards

Paco

--
Francisco Alonso Sarría
Departamento de Geografía (Area de Geografía Física)
Universidad de Murcia. Campus La Merced
E-30001 Murcia
Telfn: +34 968364357
www.um.es/geograf/sigmur

--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177

EMAIL: thomas.adams@noaa.gov

VOICE: 937-383-0528
FAX: 937-383-0033

22

2005/11/13, Christian Ferreira <christian.grass@gmail.com>:

[...]

But it needs with a easier/better UI and localized version to pt_BR
(without this is really difficult to make a big switch, because many GIS
techs don't know English very well). That's my opinion.

Just to drop a note that I'm working in the l10n of GRASS to pt_BR,
have a look at
http://grass.itc.it/devel/i18n.php#statistics to see how is it going.

I planned to do a sprint, now that I'm enjoying vacations from work.
But as I got a bad RSI in my right wrist, I feel I'll have to postpone
it.

If someone wants to take over, jump into it!!

P.S.: It's hard to type just left-handedly...And _slow_!

cheers.
--
Paulo Marcondes
http://rj.debianbrasil.org

23

On Nov 14, 2005, at 4:30 AM, Thomas Adams wrote:

Dear GRASS Community:

This discussion is far too interesting to pass making some comments. First off, I could not agree more with most (if not all) comments. The price/performance comparison alone makes GRASS the easy winner and the user support is outrageously good. I work for aU.S. federal agency and admittedly the GRASS community is small by comparison to ESRI. That's an irony, of course, since GRASS was developed by the U.S. Army Corps of Engineers. What is also ironic is that there is a strong analogy between ESRI/GRASS and the MS-Windows/Intel versus Apple Macintosh/Linux world — but with an interesting twist. The reason many have identified for the groundswell of GIS users using ESRI software is ease of use with the GUI which purportedly is not available with GRASS. Some comments have shown this is not quite the case.

Interesting times indeed.

The lack of cross-platform support with ESRI software is a huge issue with many and has caused significant problems in my agency due to the fact that our real-time operational environment is Linux; we would like to have GIS intimately intertwined with our operational environment at each workstation (having multiple monitors) but this really crowds the desktop space not to mention that one would have to use simultaneously a MS-Windows environment on one computer and Linux on the other — what a mess!! So, I have been gently pushing GRASS when the opportunity presents itself.

Here in the small Land, Air, and Water Resources Dept. of the University of Ca in Davis I have been confronted with the same problems. Many of my collegaues and I use Linux and MacOS, yet GIS in integrated deeply into our research (soil science). I became a GRASS user out of both curiosity AND neccessity. Fortunately, with every ESRI-related mess that my collegues have to deal with, one more comes and asks about GRASS. Thos last screen shots from Radim were quite excellent, and I am looking forward to trying out the GRASS->QGIS plugin system.

For much of what we do at U.S. National Weather Service (NWS) River Forecast Centers involves handling large amounts of GIS data repetitively. This means that scripts must be used to handle the analysis of these data. It is quite easy in GRASS to write simple shell, Perl, or whatever scripts to handle the data analysis requirements we have.

I should also add the importance of GRASS/QGIS interoperability and interoperability with R, gstat, GMT, etc. Combined, these make an incredibly powerful GIS environment that easily rivals the ESRI world. ESRI still holds the marketing edge with the perception of creating stunning maps, which captures the attention of end-users. Probably a stronger tie between GMT and GRASS would help.

Good point. As with GRASS, I made myself learn how to use GMT out of neccessity: I needed high quality cartographic output. There have been numerous efforts to integrate GRASS and GMT, including: shape2gmt, r.out.gmt.py (David F.), r.out.gmt (Hamish and I), as well as 2 new modules that are currently only on paper v.out.gmt (Hamish and I), and possibly g.out.gmt (complete GMT script creation- Hamish and I).

I am enjoying this thread quite a bit. Perhaps it would be a good idea to summarize the important points, and put it up somewhere. Maybe adjusting the tone a bit so as not to be too abrasive, :slight_smile: .

Cheers,

--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341

24

Dylan,

Thanks for the comments! I agree that it would be worthwhile to summarize the salient (and edited) points someplace. I'd like to try out the GRASS-GMT code you and Hamish are working on. BTW, the maps on my office website (http://www.erh.noaa.gov/er/ohrfc) are created with GMT.

Tom

Dylan Beaudette wrote:

On Nov 14, 2005, at 4:30 AM, Thomas Adams wrote:

Dear GRASS Community:

This discussion is far too interesting to pass making some comments. First off, I could not agree more with most (if not all) comments. The price/performance comparison alone makes GRASS the easy winner and the user support is outrageously good. I work for aU.S. federal agency and admittedly the GRASS community is small by comparison to ESRI. That's an irony, of course, since GRASS was developed by the U.S. Army Corps of Engineers. What is also ironic is that there is a strong analogy between ESRI/GRASS and the MS-Windows/Intel versus Apple Macintosh/Linux world — but with an interesting twist. The reason many have identified for the groundswell of GIS users using ESRI software is ease of use with the GUI which purportedly is not available with GRASS. Some comments have shown this is not quite the case.

Interesting times indeed.

The lack of cross-platform support with ESRI software is a huge issue with many and has caused significant problems in my agency due to the fact that our real-time operational environment is Linux; we would like to have GIS intimately intertwined with our operational environment at each workstation (having multiple monitors) but this really crowds the desktop space not to mention that one would have to use simultaneously a MS-Windows environment on one computer and Linux on the other — what a mess!! So, I have been gently pushing GRASS when the opportunity presents itself.

Here in the small Land, Air, and Water Resources Dept. of the University of Ca in Davis I have been confronted with the same problems. Many of my collegaues and I use Linux and MacOS, yet GIS in integrated deeply into our research (soil science). I became a GRASS user out of both curiosity AND neccessity. Fortunately, with every ESRI-related mess that my collegues have to deal with, one more comes and asks about GRASS. Thos last screen shots from Radim were quite excellent, and I am looking forward to trying out the GRASS->QGIS plugin system.

For much of what we do at U.S. National Weather Service (NWS) River Forecast Centers involves handling large amounts of GIS data repetitively. This means that scripts must be used to handle the analysis of these data. It is quite easy in GRASS to write simple shell, Perl, or whatever scripts to handle the data analysis requirements we have.

I should also add the importance of GRASS/QGIS interoperability and interoperability with R, gstat, GMT, etc. Combined, these make an incredibly powerful GIS environment that easily rivals the ESRI world. ESRI still holds the marketing edge with the perception of creating stunning maps, which captures the attention of end-users. Probably a stronger tie between GMT and GRASS would help.

Good point. As with GRASS, I made myself learn how to use GMT out of neccessity: I needed high quality cartographic output. There have been numerous efforts to integrate GRASS and GMT, including: shape2gmt, r.out.gmt.py (David F.), r.out.gmt (Hamish and I), as well as 2 new modules that are currently only on paper v.out.gmt (Hamish and I), and possibly g.out.gmt (complete GMT script creation- Hamish and I).

I am enjoying this thread quite a bit. Perhaps it would be a good idea to summarize the important points, and put it up somewhere. Maybe adjusting the tone a bit so as not to be too abrasive, :slight_smile: .

Cheers,

--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341

--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177

EMAIL: thomas.adams@noaa.gov

VOICE: 937-383-0528
FAX: 937-383-0033

25

On Nov 14, 2005, at 10:43 AM, Thomas Adams wrote:

Dylan,

Thanks for the comments! I agree that it would be worthwhile to summarize the salient (and edited) points someplace. I'd like to try out the GRASS-GMT code you and Hamish are working on. BTW, the maps on my office website (http://www.erh.noaa.gov/er/ohrfc) are created with GMT.

Tom

Hi,

Well if I can get my act together, we can expect an article or 2 in the coming GRASS newsletter.

Nice maps. Here is an example of a map done in GMT:

  http://casoilresource.lawr.ucdavis.edu/drupal/node/102

Cheers,

Dylan

Dylan Beaudette wrote:

On Nov 14, 2005, at 4:30 AM, Thomas Adams wrote:

Dear GRASS Community:

This discussion is far too interesting to pass making some comments. First off, I could not agree more with most (if not all) comments. The price/performance comparison alone makes GRASS the easy winner and the user support is outrageously good. I work for aU.S. federal agency and admittedly the GRASS community is small by comparison to ESRI. That's an irony, of course, since GRASS was developed by the U.S. Army Corps of Engineers. What is also ironic is that there is a strong analogy between ESRI/GRASS and the MS-Windows/Intel versus Apple Macintosh/Linux world — but with an interesting twist. The reason many have identified for the groundswell of GIS users using ESRI software is ease of use with the GUI which purportedly is not available with GRASS. Some comments have shown this is not quite the case.

Interesting times indeed.

The lack of cross-platform support with ESRI software is a huge issue with many and has caused significant problems in my agency due to the fact that our real-time operational environment is Linux; we would like to have GIS intimately intertwined with our operational environment at each workstation (having multiple monitors) but this really crowds the desktop space not to mention that one would have to use simultaneously a MS-Windows environment on one computer and Linux on the other — what a mess!! So, I have been gently pushing GRASS when the opportunity presents itself.

Here in the small Land, Air, and Water Resources Dept. of the University of Ca in Davis I have been confronted with the same problems. Many of my collegaues and I use Linux and MacOS, yet GIS in integrated deeply into our research (soil science). I became a GRASS user out of both curiosity AND neccessity. Fortunately, with every ESRI-related mess that my collegues have to deal with, one more comes and asks about GRASS. Thos last screen shots from Radim were quite excellent, and I am looking forward to trying out the GRASS->QGIS plugin system.

For much of what we do at U.S. National Weather Service (NWS) River Forecast Centers involves handling large amounts of GIS data repetitively. This means that scripts must be used to handle the analysis of these data. It is quite easy in GRASS to write simple shell, Perl, or whatever scripts to handle the data analysis requirements we have.

I should also add the importance of GRASS/QGIS interoperability and interoperability with R, gstat, GMT, etc. Combined, these make an incredibly powerful GIS environment that easily rivals the ESRI world. ESRI still holds the marketing edge with the perception of creating stunning maps, which captures the attention of end-users. Probably a stronger tie between GMT and GRASS would help.

Good point. As with GRASS, I made myself learn how to use GMT out of neccessity: I needed high quality cartographic output. There have been numerous efforts to integrate GRASS and GMT, including: shape2gmt, r.out.gmt.py (David F.), r.out.gmt (Hamish and I), as well as 2 new modules that are currently only on paper v.out.gmt (Hamish and I), and possibly g.out.gmt (complete GMT script creation- Hamish and I).

I am enjoying this thread quite a bit. Perhaps it would be a good idea to summarize the important points, and put it up somewhere. Maybe adjusting the tone a bit so as not to be too abrasive, :slight_smile: .

Cheers,

--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341

--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177

EMAIL: thomas.adams@noaa.gov

VOICE: 937-383-0528
FAX: 937-383-0033

--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341

26

I should also add the importance of GRASS/QGIS interoperability and
interoperability with R, gstat, GMT, etc. Combined, these make an
incredibly powerful GIS environment that easily rivals the ESRI world.
ESRI still holds the marketing edge with the perception of creating
stunning maps, which captures the attention of end-users. Probably a
stronger tie between GMT and GRASS would help.

Ok then,

I have written a r.out.gmt script which is for a large part based on the
GRASS -> GMT tutorial by Dylan Beaudette of UC Davis.
  http://169.237.35.250/~dylan/grass_user_group/map1.html

It is now on the GRASS Wiki add-ons page.
  http://grass.gdf-hannover.de/twiki/bin/view/GRASS/GrassAddOns

It still needs a bit of refinement but the basics are done. (ie plea for
a real GMT user to take it from here) e.g. It could be updated to use
GMT's xyz2grd instead of writing the binary file directly (support for
export of DCELL maps)?

It outputs a GRASS map to a GMT binary grid; generates a GMT color table
from the GRASS color table; and prepares the GMT commands needed to make
PostScript output. You can (almost) do:
   GRASS> eval `r.out.gmt -p mapname`
and end up with a GMT PostScript file!

Probably better to do:
   GRASS> r.out.gmt -p mapname > map_gmt_script.sh
and flavour to suit for now.

It is much like the tutorial, with a few useful enhancements (and
probably several regressions as I know very little about GMT). The main
idea is to use the script as a pre-processor to get folks started, not
to do a full GMT session.

enhancements:
* auto DCELL -> FCELL (sadly r.out.gdal netCDF support is read-only)
* auto GRASS -> GMT color table converter
* auto tick spacing
* uses awk not bc for FP math as bc isn't installed everywhere
* GRASSify region calculations a little
* with "r.out.gmt -p 2> /dev/null" you can generate a .ps script
(almost)

regressions:
* PostScript file is semi-broken: x,y offset & gv stalls
* more??

outstanding issues:
* still needs colr[colr2] file existence test. or make "r.colors -o"?
* default paper should be taken from /etc/papersize or $GRASS_PAPERSIZE
?
   (same issue for ps.map I guess, but a4 is default there)

possibilities:
* add a vect=map1[,map2,...] option to allow overlay of vector files
* more??

best,
Hamish