Tim Michelsen pisze:
Nevertheless, I cannot get around expressing my disappointment about
GRASS in this area.
* I cannot just point the program to a directory of shapefiles and
tell it import all. QGIS, gvSIG and ArcGIS can do this.
Well, true. I clearly remember how frustrating it was for me when I
started using GRASS - how do I import those 20 shapefiles, process them
all with the same command and then export them back, withot having to
click those buttons a hundred times for an hour. Yet now I'm fine with
this as that was the first moment when I had to learn some scripting.
Maybe not really consoling for you at the moment...
* I cannot reproject these on the fly be changing the projection of
my location.
On-the fly reprojection is not what a GIS *analysis* software should do,
IMO. It's great in QGIS which is mainly a viewer/map composer (for me at
least), but even in QGIS if you want to do anything with your shapefile
in a different coordinate system, you still have to reproject it
permanently, for the performance penalty when working with
live-repojected data is not worth the comfort (e.g. try to edit a
live-reprojected shapefile in QGIS - several times slower) and also
opens a field for new issues (say area/distance/angle calculation will
be different in different CRSs - now should the native or the temporary
CRS be considered?). And it would make it necessary to adapt all GRASS
modules to support on-the-fly reprojections, consistently. And the real
fun begins in case of raster maps.
=> Whenever it comes to data format conversion and reprojection
people on QGIS/GRASS Maillists tend to tell the user: get your
keyboard and hack something with OGR/GDAL (Re: converting .asc to
.xyz, http://permalink.gmane.org/gmane.comp.gis.qgis.user/2519).
In this thread you asked about a particular conversion tool,
and there was a reply. True, the tools mentioned don't support multiple
input, but they do the work once you learn the magic:
for i in *.xyz; do gdal2xyz.py $i $i.xyz; done
(Few days ago I learned how to do it in Python and I'm an even hapier
camper :).
Nice thing is that now you can re-use the syntax in any later work that
involves batch processing on Unix. And you'll be ways more
time-efficient than having to click around, even if the GUI and multiple
input support was there (am I getting old or what?).
In clear words this means that the software is not ready, yet. This
tells me that these GIS are not made for "normal" Desktop GIS task
and mapping.
Maybe GRASS is good for some very specialised and automatisable
tasks. But to make a beautiful and printable map from a buch of data
that can be interpreted?
That's not what GRASS is for; a separate issue is that there doesn't
actually exist a decent GUI-driven FOSS map composer AFAIK (however what
Marco Hugentobler is doing now for QGIS 1.0 is extremely promissing).
Yet the latter is not a GRASS fault. I don't think GRASS development
should concetrate on a user-friendly map composer, when the dev
resources are so scarce.
I was trying my best to run my current project with GRASS and FOSS4G.
But these have such severe usability issues that I cannot affort
putting the time in.
Yes, you need to invest some time first to start being productive ...
Since geographical analysis also involves data aquisition and --
later -- a interpretation I want to minimise the processing time.
... but once you get it, you'll save a lot of time.
I am not here to rant only. I will try to update the page on usabilty
(http://grass.osgeo.org/wiki/Usability) after finishing my project.
Thanks! That would be appreciated.
But really, GIS is visual work with geoGRAPHICAL
As for the word play, I'd put it all in capital letters :).
data.
Point for me.
Why did I write disappointment? Because GRASS is advertised by OSGEO
as THE most powerful free GIS that can perform any task.
One must be honest and tell, that one needs to be a programmer (at
least bash) and run linux and have a good visual imagination because
of the non integrated GUI. The above mentioned tasks are really basic
GIS tasks.
Yes, some scripting is necessary to be any productive with massive data
processing. Even on Windows with ArcGIS. Finally, the moment "to grab
the keyboard" comes anyway :).
Someone is devloping a GUI for OGR: * http://inventis.ca/ogr2gui/ *
http://permalink.gmane.org/gmane.comp.gis.gdal.devel/16254 Hope that
this will help for future tasks.
I think it is better to reproject and merge shapefiles via
ogr2ogr. The very trivial task (in my experience) was to clean
vector after import in GRASS. v.clean tool=rmdupl,snap,bpol
Actually, it is not really trivivial. GRASS freezes the computer when
running the above mentioned command on a vector that consists of
merged corine land cover tiles (number of tiles = 20).
Some defect it seems. Please report to Trac (with details how to reproduce).
Maciek
--
Maciej Sieczka
www.sieczka.org
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
