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

Tue Jul 29 19:31:58 EDT 2008

GRASS'ers:

Although I don't echo Tim's dissapointment with GRASS (I use it 
routinely and wouldn't trade it for the world), I do agree that GRASS is 
more programmer-friendly than casual-user friendly environment.  GRASS 
reminds me, in many ways, of Arc/Info (pre-ArcMap, the 'ol command line 
ESRI product).  I am a bit curious (this has been on my mind recently 
when using GRASS) what is the long-term view of GRASS development, in 
terms of making it easier to use, making sure certain processing chains 
are available (e.g. right now you can't really perform an end-to-end 
remote sensing analysis completely within GRASS), etc?  Chief 
developers: are the big pushes still to design/implement standard data 
models, make the programming environment consistent and easy to develop 
for, get basic GIS/raster functionality in place, or are there specific 
processing chain goals on the horizon?  How are you all doing for 
funding, and is anyone getting funding for continued development and 
what can *we* as the user community do to help out (e.g. if you went for 
a grant, I bet you could get tens or hundreds of letters of support for 
funding)?  Is GRASS shooting for being a GIS package, remote sensing 
package, or all things to all people -- which would be great, but to 
date even the commercial vendors haven't come up with the perfect 
geospatial analysis product -- don't get me started on ESRI products...

Just wanted to drop a few thoughts -- I'm happy to help with identifying 
what is missing and designing a remote sensing analysis chain (my 
particular specialty) but of course from my emails you'd know I'd be 
hard pressed to do any of the actual coding. 

Keep up the great work!

--j

Maciej Sieczka wrote:
> 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
>

-- 
Jonathan A. Greenberg, PhD
Postdoctoral Scholar
Center for Spatial Technologies and Remote Sensing (CSTARS)
University of California, Davis
One Shields Avenue
The Barn, Room 250N
Davis, CA 95616
Cell: 415-794-5043
AIM: jgrn307, MSN: jgrn307 at hotmail.com, Gchat: jgrn307