[GRASS-user] Re: import a folder full of shapefiles and reproject on-the-fly?

[Maciej Sieczka]

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