Slashdot Mirror

← Back to Stories (view on slashdot.org)

Grass 5.0 beta to be released on Feb 1st.

Posted by sengan on from the makes-nice-pictures dept.

GRASS 5.0 will be released on Febuary 1st, the Baylor University GRASS web site reports GRASS is a public-domain raster-based/vector Geographical Information System which processes images, models spatial data producing images. Source-code for Grass is provided, and it should be useful to environmentalists and people using the GPL'd Tiger Line Data set. There are quite a few demos of it on the web.

10 of 22 comments (clear)

  1. Good deal by jabbo · · Score: 1
    Grass is a powerful package -- really powerful -- but it is a stupendous pain in the ass to compile and build. I hope and pray that 5.0 will be easier to configure and compile than 4.2.1 -- after trying mightily to compile it on SCO and Linux, I finally gave up and installed the binaries. (yeah yeah, but I have deadlines, see?)

    If 5.0 can be built by mere mortals I'll make an RPM out of it, no problem. There's a nice tutorial for GRASS at

    Leicester University's GRASS Seeds Tutorial

    and the place where I got the binaries was the

    Grass 4.2.1 Main Page

    at the University of Hanover. Why? Because my boss said to... ;-)

    Incidentally, getting the TclTkGrass menu interface (and building it from within Grass) is a Good Thing to do if you're a clod like me.

    --
    Remember that what's inside of you doesn't matter because nobody can see it.
  2. World Wide Data Set by ptomblin · · Score: 1

    I believe that Digital Chart of the World isn't available any more. Does anybody know if its successor (which I believe is called VMap) is out, where I can get it, and if it can be loaded into GRASS?

    --
    The next Cmdr Taco duplicate will be ready soon, but subscribers can beat the rush and see it early!
  3. Microsoft mappoint by sheldon · · Score: 1

    I don't know much about mappoint, but the mapping package which is integrated with Microsoft Office was built by Strategic Mapping, makers of Atlas*GIS.

    ESRI bought them out about two years ago. Perhaps Microsoft bought the rights to that product during the ESRI acquisition?

  4. Arc/Info & GRASS by sheldon · · Score: 1

    I'd be curious to see how GRASS has changed. I last used it in 1995 and it really pretty much sucked at the time. We did however use LTPlus for our map generation and it was a slick program.

    Arc/Info was bloated, it was expensive. But damn did it do everything, and it worked pretty well. Because the application was so massive, ESRI did tend to release buggy code, and you really wanted to wait for like version x.1 or x.2 before using it.

    Arc/Info really wasn't a end-user package. Everything you did was pretty much done by writing macros. ArcView was their end-user package, although they also bought Strategic Mapping out a couple years ago so now have Atlas*GIS.

    Ohwell, I miss Arc/Info and my mapping days to some extent. :(

    Steve

  5. CD's, anyone? by Bruce+Perens · · Score: 1
    A CD set with GRASS and the TIGER/Line data in the appropriate format should be nice. I'll work on that. I'll make the RPMs and .DEBs if nobody beats me to the task.

    The raw TIGER data is about 25 GB uncompressed. It's in the form of ZIP archives on 6 CDs, and I have been recompressing it in the form of individual .bz2 files. That will probably get the data on 5 CDs instead of 6, there's about a 20% savings. However, my shell driving bzip2 -9 --repetitive-best has been running since Friday and is still not done (on a Pentium 120) :-) .

    Bruce

    --
    Bruce Perens.
  6. ArcView is killing me, but will GRASS cut it? by GianfrancoZola · · Score: 1

    I noticed that you mentioned using ArcView for printing maps. . . I don't know exactly what quality you are shooting for, perhaps it's not important, but ArcView makes really cruddy maps. I believe there are some plugins available (don't remember URL) to port ArcView .shp files over to Adobe Illustrator, which I have seen make some excellent looking maps of high cartographic quality.

    On a side note--anyone know how Rob's submission thing works? I posted the news of this beta release announcement a couple of hours after the folks at Baylor put it up, and today was the first mention of it on /. Weird. It's not a big deal, I suppose interested geographers like myself and other folks that work with GIS would have heard about this fairly quickly anyway.

    Cheers,
    Joel

  7. Thank god... by kurowski · · Score: 1
    I've been waiting for this for a long time. I've almost convinced a BIG client to use GRASS for a web-app, and some of 5.0's new features may make it a reality. Being forced to use proprietary ol' ArcInfo might kill me, since parts of this app require adding custom GIS routines.

    Down with ESRI, and open up the MapQuest source code!

  8. Finally... by Kimbotha · · Score: 1

    This one has been a long time coming...
    We use GRASS as the backend GIS for a Web based map query system (http://www.agcrc.csiro.au/4dgm/grasslinks/) it is nice to have a GIS that is free and opensource, and the fact that it has a strong commandline interface makes it easy to script, perfect for CGIs...
    Hopefully 5.0 will have better support for Sites lists and NULL values, maybe even 64bit Archs...
    :)

  9. ArcView is killing me, but will GRASS cut it? by Seb · · Score: 1
    I'm working in County Planning Office and having a lot of work with GIS related stuff. I use ArcView on Winbloze, primarily for printing maps. I find GRASS of no use to me, beacuse it is raster oriented, while I'm dealing with lines/polygons all of the time.

    With time our datasets grew big, and it is pain to handle them with ArcView. We are thinking about migrating to ArcInfo+SDE connecting to Oracle.

    We will be happy to use any tool that works, but after fiddling with GRASS 4.2 I am definitely sure that it does NOT fill our needs.

    Any comments?

  10. Correction of polygon data by Seb · · Score: 1
    Most of the time we work on correcting existing polygon data, both spatial and attributes. We collect data from various sources, so there is a big amount of data editing.

    This is the problem #1. And the problem #2 are sophisticated printouts of that data which are royal PITA to compose in ArcView.

    Next, we have plain old RDBMS keeping some statistical data we wish to throw in. At the moment we use 'linked tables' in ArcView to link ArcView polygons to records in RDBMS tables using something like parcell ID as a key. However, very often polygon gets splitted (or joined or deleted) and RDBMS must be informed manually of these changes.

    BTW, can GRASS handle attribute table attached to some vector dataset?