[GRASSLIST:98] Considering replacing ESRI

GRASS GRASS user
1

Folks,

  First of all I need to let you know that I am not currently working in the
  GIS field. I do however support the Unix systems that are currently used
  by the people in our GIS area.

  I certainly don't understand the complexities of our GIS area but I can
  see that we have a huge investment in ESRI products:

  ArcInfo
  ArcView
  ArcSDE
  ArcIMS

  These products are tied to an Oracle backend.

  My question is this: Is GRASS able to replace any of the above listed products
  and if so has anyone ever made this type of move in the past. I can see
  huge cost savings here if it is possible.

  I would appreciate any feedback. I am trying to determine if it is
  worthwhile for me to explore Open Source alternatives for our GIS area so
  if anyone can offer some insight it would really help me out.

Thanks.

--
CJR

2

I am a self-taught, non-geology/geography person (physics is my "trade"). I began learning GIS from the ground up without guidance in 1995 to assist a Geology Prof in the school where I was an adjunct. I have used IDRISI, Xmap8, Grass, ArcView/ArcGIS and a lot of associated tools and have had considerable time and opportunity to onsider the "commercial package" option. It is ALWAYS possible to provide the functionality you need, but you have to understand the techniques well-enough to evaluste the outcomes. You also need a scripter or coder around who can do the conversions and batching, etc, that are inevitable when the tools) available don't quite do what you want.

ESRI is analogous to Microsoft if GIS suites are regarded as spatial data OS's. It was created with huge investments of time and energy according to a single philosophy of analysis in an effort to provide a single modular interface for this kind of work. How much of Windows, Office, etc do you really take advantage of when you purchase the latest and greatest version (simply to remain "current", whatever that means with software versioning/patching).?

When you know what you need and you know what is available you can work (almost) for free.

seeker@eventhorizon.ca wrote:

Folks,

  First of all I need to let you know that I am not currently working in the
  GIS field. I do however support the Unix systems that are currently used
  by the people in our GIS area.

  I certainly don't understand the complexities of our GIS area but I can
  see that we have a huge investment in ESRI products:

  ArcInfo
  ArcView
  ArcSDE
  ArcIMS

  These products are tied to an Oracle backend.

  My question is this: Is GRASS able to replace any of the above listed products
  and if so has anyone ever made this type of move in the past. I can see
  huge cost savings here if it is possible.

  I would appreciate any feedback. I am trying to determine if it is
  worthwhile for me to explore Open Source alternatives for our GIS area so
  if anyone can offer some insight it would really help me out.

Thanks.

--
CJR

3

Absolutely right,

Many people think like 'GIS = ESRI', like 'Red Hat = Linux' or 'Database = Oracle'. The point is to understand the principles and objectives of GIS, not ArcInfo or GRASS. If you know what to do, pick the tool you prefer!

In my field of interest - GIS-enhanced webmapping - a combined framework of GRASS/PostGIS/UMN MapServer does a perfect job.

Evaluate your prerequisits and needs to the system. Keep asking questions in the various OpenSource GIS/mapping mailinglists on required features and if they exist. You will see that (nearly) everything is available. Only the approach is different to a major application framework like the ESRI suite with all its components. With the available OpenSource tools, you don't get the single ,"Microsoft/Word"-style like GUI to work with. Still what count is the outcome, not the nice buttons :slight_smile:

I still ask myself, what can ArcInfo do for me that GRASS can't, what can Oracle Spatial do for me that PostGIS can't, what can ArcIMS do for me that the UMN MapServer can't? And if I recognise some features, is it really worth the price?

regards,
alex.
________________________________________________________

Departement of Geography and Regional Research
University of Vienna
Cartography and GIS
--------------------------------------------------------
Virtual Map Forum: http://www.gis.univie.ac.at/vmf
--------------------------------------------------------

Andrew wrote:

I am a self-taught, non-geology/geography person (physics is my "trade"). I began learning GIS from the ground up without guidance in 1995 to assist a Geology Prof in the school where I was an adjunct. I have used IDRISI, Xmap8, Grass, ArcView/ArcGIS and a lot of associated tools and have had considerable time and opportunity to onsider the "commercial package" option. It is ALWAYS possible to provide the functionality you need, but you have to understand the techniques well-enough to evaluste the outcomes. You also need a scripter or coder around who can do the conversions and batching, etc, that are inevitable when the tools) available don't quite do what you want.

ESRI is analogous to Microsoft if GIS suites are regarded as spatial data OS's. It was created with huge investments of time and energy according to a single philosophy of analysis in an effort to provide a single modular interface for this kind of work. How much of Windows, Office, etc do you really take advantage of when you purchase the latest and greatest version (simply to remain "current", whatever that means with software versioning/patching).?

When you know what you need and you know what is available you can work (almost) for free.

seeker@eventhorizon.ca wrote:

Folks,

    First of all I need to let you know that I am not currently working in the
    GIS field. I do however support the Unix systems that are currently used
    by the people in our GIS area.

    I certainly don't understand the complexities of our GIS area but I can
    see that we have a huge investment in ESRI products:

    ArcInfo
    ArcView
    ArcSDE
    ArcIMS

    These products are tied to an Oracle backend.

    My question is this: Is GRASS able to replace any of the above listed products
    and if so has anyone ever made this type of move in the past. I can see
    huge cost savings here if it is possible.

    I would appreciate any feedback. I am trying to determine if it is
    worthwhile for me to explore Open Source alternatives for our GIS area so
    if anyone can offer some insight it would really help me out.

Thanks.

--
CJR

4

Hello,

Free Software has much to offer for geographic data processing.
We've done a couple projects where Free Software replaced
ESRI product at Intevation.
So it is possible to use Free Software in principle and worth exploring.

Whether it is easy and what Free Software components you should try
depends on a deeper analysis of your situation and field of use.

Note that freegis.org lists almost 200 entries regarding Free Software
and geographic information processing.
Asking on the FreeGIS mailinglist might hold more interesting
answers to your question. So I'm crossposting my answer.

Let me give you a few pointers:

GRASS is a heavy weight for GIS and analysis.
Therefore it is in the usage realms of ArcInfo and ArcSDE.

Webmapping which is offered by ArcIMS can be done by Mapserver.
Mapserver is a mature product which has been prefered to ArcIMS
by a number of organisations already.

PostGIS with extensions can solve similiar problems then ArcSDE and Oracle.

ArcInfo is a some sort of frontend, exploration and map making tool
which can be used for many things.
There are Free Software applications in that realm, too,
like OpenEV, OpenMap and the upcoming Thuban to just name a few.
(Disclosure: Intevation is the main driving force behind Thuban.)

To the cost saving question:
Usually Free Software has a better "Total cost of operation",
which is realised in the mid term.
In short terms the migration and training costs can be high,
but in the mid term the return of the investment is quite good
in the average.

  Bernhard

On Wed, May 21, 2003 at 05:07:37AM -0600, seeker@eventhorizon.ca wrote:

  First of all I need to let you know that I am not currently
  working in the GIS field. I do however support the Unix
  systems that are currently used by the people in our GIS
  area.

  I certainly don't understand the complexities of our GIS area but I can
  see that we have a huge investment in ESRI products:

  ArcInfo
  ArcView
  ArcSDE
  ArcIMS

  These products are tied to an Oracle backend.

  My question is this: Is GRASS able to replace any of the
  above listed products and if so has anyone ever made this
  type of move in the past. I can see huge cost savings here
  if it is possible.

  I would appreciate any feedback. I am trying to determine
  if it is worthwhile for me to explore Open Source
  alternatives for our GIS area so if anyone can offer some
  insight it would really help me out.

5

On Wed, May 21, 2003 at 04:20:42PM +0200, Bernhard Reiter wrote:

ArcInfo is

In this this paragraph I've mean to address ArcView.
(Thanks for the readers who pointed that out to me.)

a some sort of frontend, exploration and map making tool
which can be used for many things.
There are Free Software applications in that realm, too,
like OpenEV, OpenMap and the upcoming Thuban to just name a few.
(Disclosure: Intevation is the main driving force behind Thuban.)

6

I think you might be posing your question to the wrong audience. You should ask your GIS users if they would like to change, because without their interest and commitment you are not likely to see success. ESRI has developed an incredible degree of loyalty in their users. For those users, suggesting a change, even for the better, may not be popular.

Rich

At 05:07 AM 5/21/2003 -0600, you wrote:

Folks,

        First of all I need to let you know that I am not currently working in the
        GIS field. I do however support the Unix systems that are currently used
        by the people in our GIS area.

        I certainly don't understand the complexities of our GIS area but I can
        see that we have a huge investment in ESRI products:

        ArcInfo
        ArcView
        ArcSDE
        ArcIMS

        These products are tied to an Oracle backend.

        My question is this: Is GRASS able to replace any of the above listed products
        and if so has anyone ever made this type of move in the past. I can see
        huge cost savings here if it is possible.

        I would appreciate any feedback. I am trying to determine if it is
        worthwhile for me to explore Open Source alternatives for our GIS area so
        if anyone can offer some insight it would really help me out.

Thanks.

--
CJR

Richard W. Greenwood, PLS
Greenwood Mapping, Inc.
Rich@GreenwoodMap.com
(307) 733-0203
http://www.GreenwoodMap.com

7

Yes, I've discovered that already but we are in need of some serious cost
cutting and we have been mandated by our executives to explore all options.
Change is never easy but in this case, it may be necessary so even if it is an
unpopular idea with my GIS users it must be explored and they are aware of
that.

This thread has been extremely helpful to me and I think I have a good
starting point. I think at this point I need to enlist the help of my GIS
folks and start exploring some of the options pointed out here. I needed to
know if the Open Source options were viable and from what I've seen so far it
looks like there are a ton of options.

Thanks for your help.

On Wed, May 21, 2003 at 09:29:46AM -0600, Richard Greenwood wrote:

I think you might be posing your question to the wrong audience. You should
ask your GIS users if they would like to change, because without their
interest and commitment you are not likely to see success. ESRI has
developed an incredible degree of loyalty in their users. For those users,
suggesting a change, even for the better, may not be popular.

--
CJR

8

On Wednesday, May 21, 2003, at 04:12 AM, Alexander Pucher wrote:

I still ask myself, what can ArcInfo do for me that GRASS can't...?

Okay, how about orienting maps to other than true north (which I think is called "false northing")?

I had limited experience with ArcInfo etc 10 years ago, but I remember that I could reorient maps, which was very useful. I'm currently looking at a mountain range which trends NW-SE, and if I could orient my work that way I believe it would be both easier to look at and faster to work on, as there wouldn't be any processing time devoted to areas outside my area of interest (i.e. the SW and NE corners of my current region).

I'm still a newbie to GRASS and have been hoping I would come across a way to do this, but lately I have begun to suspect that, as it appears, GRASS lacks this capacity. Can someone prove me wrong?

yrs,
David

9

I don't think that grass can rotate rasters (ESRI can).

I tried to get around this a few months ago by writing a Python script that did the work. Unfortunately, it isn't very efficient and can take 20 mins or so to rotate large grids. If you are interested I can send you the script.

David Finlayson

David Strauch wrote:

On Wednesday, May 21, 2003, at 04:12 AM, Alexander Pucher wrote:

I still ask myself, what can ArcInfo do for me that GRASS can't...?

Okay, how about orienting maps to other than true north (which I think is called "false northing")?

I had limited experience with ArcInfo etc 10 years ago, but I remember that I could reorient maps, which was very useful. I'm currently looking at a mountain range which trends NW-SE, and if I could orient my work that way I believe it would be both easier to look at and faster to work on, as there wouldn't be any processing time devoted to areas outside my area of interest (i.e. the SW and NE corners of my current region).

I'm still a newbie to GRASS and have been hoping I would come across a way to do this, but lately I have begun to suspect that, as it appears, GRASS lacks this capacity. Can someone prove me wrong?

yrs,
David

10

On Thu, 22 May 2003, David Finlayson wrote:

I don't think that grass can rotate rasters (ESRI can).

I tried to get around this a few months ago by writing a Python script
that did the work. Unfortunately, it isn't very efficient and can take
20 mins or so to rotate large grids. If you are interested I can send
you the script.

Consider that after rotation the projection would no longer be what it
was. So the new raster would have to be stored in a new (XY) location.

Why not simply export tif/png, rotate with Gimp or other external image
handler, reimport into XY-location?

11

On Wed, 21 May 2003, David Strauch wrote:

Okay, how about orienting maps to other than true north (which I think
is called "false northing")?

I don't think this is correct. The orientation of the map is defined by
the projection. False northing/easting is just an offset in up/down,
right/left direction, but it does not change the angle toward 'north'.

12

On Wed, 21 May 2003, David Strauch wrote:

On Wednesday, May 21, 2003, at 04:12 AM, Alexander Pucher wrote:
> I still ask myself, what can ArcInfo do for me that GRASS can't...?

Okay, how about orienting maps to other than true north (which I think
is called "false northing")?

I had limited experience with ArcInfo etc 10 years ago, but I remember
that I could reorient maps, which was very useful. I'm currently
looking at a mountain range which trends NW-SE, and if I could orient
my work that way I believe it would be both easier to look at and
faster to work on, as there wouldn't be any processing time devoted to
areas outside my area of interest (i.e. the SW and NE corners of my
current region).

You could define a mask (r.mask) to exclude the corners you weren't
interested in. This would speed up processing for most GRASS
raster modules.

I'm still a newbie to GRASS and have been hoping I would come across a
way to do this, but lately I have begun to suspect that, as it appears,
GRASS lacks this capacity. Can someone prove me wrong?

I don't think it would be possible without a lot of work. In theory you
could have rotation information (centre of rotation co-ordinates and
an angle) stored along with the projection information, and the projection
programs modified to take account of the rotation when re-projecting
between different locations.

But I think the big problem would be in the region handling. As far
as I understand it GRASS only stores two northings (top & bottom) and two
eastings (right & left), which define the region. If the region wasn't
aligned to north/south and east/west the method in which raster cell
row/column co-ordinates, or pixels in the monitor are converted to
eastings and northings wouldn't work correctly. At present you can say,
e.g.
cell easting = (easting of left-hand edge of region) +
                         ( (east-west resolution) * (cell column no.) )
This wouldn't make sense if the region wasn't aligned with north/south and
east/west.

At a minimum the region would have to be defined in terms of the
co-ordinates of its four corners, and many other changes to calculations
would be needed. Possibly every module would have to be checked to see
that it didn't make assumptions about the alignment of the region. (I know
recent changes I made to s.surf.idw assume the easting and northing can
be calculated by multiplying the row/column number by the resolution and
adding it to the value for the region edge.)

Of course if you wanted to rotate the map and not keep the geo-referencing
it would be fairly simple to implement. But I'm assuming Arc/Info does
something more advanced than that (I've never used it).

Paul

13

That is similar to what I eventually did, though I hesitate to admit that I dumped the grid from Grass, did the rotation in ArcInfo and then brought it back into Grass for my final processing.

The problem with this approach is that my program can only be ported to another user if they have all of the dependent programs (ArcInfo in this case, or the Gimp, or Image magic etc).

I think that this is the unspoken down side to the Unix paradigm. You wind up with this spaghetti of dependencies that make it impossible to hand a script over to a buddy on their machine.

It would be better if I learned enough C to get my rotation program added to Grass. Or better yet, write a Python interface to the C API so that I could read and write to the rasters directly from Python!

Cheers,

David Finlayson

Morten Hulden wrote:

On Thu, 22 May 2003, David Finlayson wrote:

I don't think that grass can rotate rasters (ESRI can).

I tried to get around this a few months ago by writing a Python script that did the work. Unfortunately, it isn't very efficient and can take 20 mins or so to rotate large grids. If you are interested I can send you the script.

Consider that after rotation the projection would no longer be what it was. So the new raster would have to be stored in a new (XY) location.

Why not simply export tif/png, rotate with Gimp or other external image handler, reimport into XY-location?

--
David Finlayson
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

14

David Finlayson wrote:

That is similar to what I eventually did, though I hesitate to admit
that I dumped the grid from Grass, did the rotation in ArcInfo and then
brought it back into Grass for my final processing.

The problem with this approach is that my program can only be ported to
another user if they have all of the dependent programs (ArcInfo in this
case, or the Gimp, or Image magic etc).

Another option for rotation would be convert to a sites list with
r.to.sites, rotate the sites list, then import the result with
s.surf.rst or s.to.rast (depending upon whether it's meaningful to
interpolate the data).

The main problem with rotating a raster directly is that it can't be
done a row at a time; you would have to read the whole thing into
memory.

I think that this is the unspoken down side to the Unix paradigm. You
wind up with this spaghetti of dependencies that make it impossible to
hand a script over to a buddy on their machine.

It would be better if I learned enough C to get my rotation program
added to Grass.

The quickest way to do this would be to modify r.proj, replacing
pj_do_proj() with an affine transformation (and discarding the other
PROJ stuff).

Or better yet, write a Python interface to the C API so
that I could read and write to the rasters directly from Python!

If you want to get the raw cell values without using C, you can read
the output from "r.stats -1 ...".

--
Glynn Clements <glynn.clements@virgin.net>

15

On Thu, 22 May 2003, Glynn Clements wrote:

David Finlayson wrote:

> Or better yet, write a Python interface to the C API so
> that I could read and write to the rasters directly from Python!

Just a thought: GDAL compiled with libraries for GRASS can read GRASS
rasters, I think write too, and has Python bindings, so reading and
writing from Python via GDAL ought to be feasible?

If you want to get the raw cell values without using C, you can read
the output from "r.stats -1 ...".

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand@nhh.no

16

Can GRASS do the same type of layout that you can do
on ArcGIS, with all the "bells and whisles", I mean,
legends, scalebars, north arrows? I know tou can put
those on the display but on the E$RI product this is
just as easy as building a Power Point presentation...

Daniel
--- Roger Bivand <Roger.Bivand@nhh.no> wrote:

On Thu, 22 May 2003, Glynn Clements wrote:

>
> David Finlayson wrote:
>
> > Or better yet, write a Python interface to the C
API so
> > that I could read and write to the rasters
directly from Python!
>
Just a thought: GDAL compiled with libraries for
GRASS can read GRASS
rasters, I think write too, and has Python bindings,
so reading and
writing from Python via GDAL ought to be feasible?

> If you want to get the raw cell values without
using C, you can read
> the output from "r.stats -1 ...".
>
>

--
Roger Bivand
Economic Geography Section, Department of Economics,
Norwegian School of
Economics and Business Administration, Breiviksveien
40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand@nhh.no

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

17

That's a great idea. I'll look into this.

David

Roger Bivand wrote:

On Thu, 22 May 2003, Glynn Clements wrote:

David Finlayson wrote:

Or better yet, write a Python interface to the C API so that I could read and write to the rasters directly from Python!

Just a thought: GDAL compiled with libraries for GRASS can read GRASS rasters, I think write too, and has Python bindings, so reading and writing from Python via GDAL ought to be feasible?

If you want to get the raw cell values without using C, you can read
the output from "r.stats -1 ...".

--
David Finlayson
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

18

> Or better yet, write a Python interface to the C API so
> that I could read and write to the rasters directly from Python!

If you want to get the raw cell values without using C, you can read
the output from "r.stats -1 ...".

Quite interesting.
And now, reverse question : is it possible to create a raster from stdin ? I
was having in mind to send the output of "r.stats -1", play with it, and send
it back to...to...to this mysterious command that may not even exist, without
having to write any file on the hard disk. Of course, you have guessed that I
do not speak C.
Thanks for any idea.

--
------------------------------
Soil and Water Laboratory
Biological and Environmental Engineering Department
Cornell University
Riley-Robb Hall
ITHACA, NY 14853 - USA

19

Soil & Water Lab. wrote:

> > Or better yet, write a Python interface to the C API so
> > that I could read and write to the rasters directly from Python!
>
> If you want to get the raw cell values without using C, you can read
> the output from "r.stats -1 ...".

Quite interesting.
And now, reverse question : is it possible to create a raster from stdin ? I
was having in mind to send the output of "r.stats -1", play with it, and send
it back to...to...to this mysterious command that may not even exist, without
having to write any file on the hard disk. Of course, you have guessed that I
do not speak C.

r.in.ascii and r.in.{pbm,pgm,ppm} all accept text (non-binary) input.

--
Glynn Clements <glynn.clements@virgin.net>

20

> And now, reverse question : is it possible to create a raster from stdin
> ? I was having in mind to send the output of "r.stats -1", play with it,
> and send it back to...to...to this mysterious command that may not even
> exist, without having to write any file on the hard disk. Of course, you
> have guessed that I do not speak C.

r.in.ascii and r.in.{pbm,pgm,ppm} all accept text (non-binary) input.

OK, a r.in.ascii commands would work, provided that I don't forget to put the
proper header before the processed stream (and I guess I can grab the header
from lines 3-8 of an adequate WIND file fairly easily). I wonder if it's
worth, eventually, computer-time-wise, to process/compute maps with a script
instead of a C prog... For fairly simple calculations, "r.mapcalc" gives
results fast enough. For more complex computations, that can be an issue,
though, I'm afraid I'll have to learn C. Or at least Perl
Still, thanks for the r.in.ascii trick.
P.
PS: the link to the HTML version of the GRASS5.0 Programmer manual is broken.