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

GRASS GRASS user
1

Hello,
I am analysiing data for a whole country.
To get an idea of the landuse I would like to use corine landcover (CLC) tiles
in shapefile format.
My location is in Lat/Lon (WGS84).

Is there any way that I can import all tiles at once and also reprojecting the
CLC shapes into LL?

In the GRASS book I read that I would first need to create a location for each
file in their native projection. Then import it via v.in.ogr and later use
v.proj to get it into the location I am working in.

Please give me some hints here.

Thanks.

Timmie

2

Tim Michelsen pisze:

Is there any way that I can import all tiles at once and also
reprojecting the CLC shapes into LL?

Use ogr2ogr to reproject Shapefiles outside GRASS (it accepts directory
of shapefiles as input as well as single shapefiles) and then import
them all with v.in.ogr. You can automate v.in.ogr in Shell using "for in
do" syntax (plenty of examples in the archive or Google it).

Cheers,
Maciek

--
Maciej Sieczka
www.sieczka.org

3

On 23/07/08 22:36, Maciej Sieczka wrote:

Tim Michelsen pisze:

Is there any way that I can import all tiles at once and also
reprojecting the CLC shapes into LL?

Use ogr2ogr to reproject Shapefiles outside GRASS (it accepts directory
of shapefiles as input as well as single shapefiles) and then import
them all with v.in.ogr. You can automate v.in.ogr in Shell using "for in
do" syntax (plenty of examples in the archive or Google it).

I don't think you actually need a for-loop. From the v.in.ogr man page:

layer=string[,string,...]
     OGR layer name. If not given, all available layers are imported

So, normally, if you don't give a layer all the shapefiles in the directory (dsn=) will be imported.

You will, however, need a loop for the v.proj step...

Moritz

4

Moritz Lennert pisze:

On 23/07/08 22:36, Maciej Sieczka wrote:

Use ogr2ogr to reproject Shapefiles outside GRASS (it accepts directory of shapefiles as input as well as single shapefiles) and
then import them all with v.in.ogr. You can automate v.in.ogr in Shell using "for in do" syntax (plenty of examples in the archive or Google it).

I don't think you actually need a for-loop. From the v.in.ogr man page:

layer=string[,string,...] OGR layer name. If not given, all available
layers are imported

So, normally, if you don't give a layer all the shapefiles in the directory (dsn=) will be imported.

Note this loads the Shapefiles as *layers* (in the GRASS meaning of it)
of a single output vector map. Not necessarily what one might want.

You will, however, need a loop for the v.proj step...

ogr2ogr is more convenient than going through a temporary location
creation, Shapefile import and reprojection with v.proj, IMHO. Much less
work.

Maciek

--
Maciej Sieczka
www.sieczka.org

5

Hello,
thanks very much for answering.

> So, normally, if you don't give a layer all the shapefiles in the
> directory (dsn=) will be imported.

Note this loads the Shapefiles as *layers* (in the GRASS meaning of it)
of a single output vector map. Not necessarily what one might want.

That means that they would get imported as patched tiles?
That's exactly what I want.

Here is my workflow

1) import all landcovers in the UTM location=> v.in.ogr
2) patch all landcover tiles => v.patch in=list_of_tiles out=tiles_all
3) import the tiles_all into the lat/lon location

Can this be done more efficiently?

> You will, however, need a loop for the v.proj step...

ogr2ogr is more convenient than going through a temporary location
creation, Shapefile import and reprojection with v.proj, IMHO. Much less
work.

If I want to change the projection of the lat/lon location with g.setproj do I
also need to reporject all layers inside that location?

Thanks and regards,
Timmie

6

Tim Michelsen pisze:

Maciej Sieczka wrote:

Moritz Lennert wrote:

So, normally, if you don't give a layer all the shapefiles in the
directory (dsn=) will be imported.

Note this loads the Shapefiles as *layers* (in the GRASS meaning of
it) of a single output vector map. Not necessarily what one might
want.

That means that they would get imported as patched tiles?

Not exactly - the geometry would be in a single vector map, but each
ex-tile would have a separate attribute table and categories of features
in each ex-tile would not be unique cross-layer. Read about the layer
concept in the GRASS manual.

Here is my workflow

1) import all landcovers in the UTM location=> v.in.ogr 2) patch all
landcover tiles => v.patch in=list_of_tiles out=tiles_all 3) import
the tiles_all into the lat/lon location

That's different than what you wrote initially - you wrote you need to
reproject first, and then import all reprojected tiles into one location.

Given the above workflow, mind that each UTM zone is a different CRS
actually. Do all your shapefiles fit into a single UTM zone?

Can this be done more efficiently?

You can patch and reproject multiple shapefiles with ogr2ogr alone. See
it's manual. Then import into GRASS location in a single v.in.ogr step.

You will, however, need a loop for the v.proj step...

ogr2ogr is more convenient than going through a temporary location creation, Shapefile import and reprojection with v.proj, IMHO. Much
less work.

If I want to change the projection of the lat/lon location with
g.setproj do I also need to reporject all layers inside that
location?

I don't quite understand what you mean.

Maciek

--
Maciej Sieczka
www.sieczka.org

7

On Thu, 24 Jul 2008, Maciej Sieczka wrote:

Tim Michelsen pisze:

If I want to change the projection of the lat/lon location with
g.setproj do I also need to reporject all layers inside that
location?

I don't quite understand what you mean.

g.setproj does not automatically reproject maps when the projection of the location changes. If you try runnig it you will see a nice big warning in capital letters reminding you of that - presumably it was a concern of the original g.setproj author that people might have overly high expectations of its capabilities!

Paul

8

On 23/07/08 23:45, Maciej Sieczka wrote:

Moritz Lennert pisze:

On 23/07/08 22:36, Maciej Sieczka wrote:

Use ogr2ogr to reproject Shapefiles outside GRASS (it accepts directory of shapefiles as input as well as single shapefiles) and
then import them all with v.in.ogr. You can automate v.in.ogr in Shell using "for in do" syntax (plenty of examples in the archive or Google it).

I don't think you actually need a for-loop. From the v.in.ogr man page:

layer=string[,string,...] OGR layer name. If not given, all available
layers are imported

So, normally, if you don't give a layer all the shapefiles in the directory (dsn=) will be imported.

Note this loads the Shapefiles as *layers* (in the GRASS meaning of it)
of a single output vector map. Not necessarily what one might want.

No definitely not. Didn't know that. IMHO this should be changed...

You will, however, need a loop for the v.proj step...

ogr2ogr is more convenient than going through a temporary location
creation, Shapefile import and reprojection with v.proj, IMHO. Much less
work.

+1

Moritz

9

Moritz Lennert wrote:

>>> Use ogr2ogr to reproject Shapefiles outside GRASS (it accepts
>>> directory of shapefiles as input as well as single shapefiles) and
>>> then import them all with v.in.ogr. You can automate v.in.ogr in
>>> Shell using "for in do" syntax (plenty of examples in the archive or
>>> Google it).
>
>> I don't think you actually need a for-loop. From the v.in.ogr man page:
>>
>> layer=string[,string,...] OGR layer name. If not given, all available
>> layers are imported
>>
>> So, normally, if you don't give a layer all the shapefiles in the
>> directory (dsn=) will be imported.
>
> Note this loads the Shapefiles as *layers* (in the GRASS meaning of it)
> of a single output vector map. Not necessarily what one might want.

No definitely not. Didn't know that. IMHO this should be changed...

If you want to load multiple files as individual maps, run v.in.ogr in
a loop.

I don't see any reason to add this functionality to every *.in.*
module, and even less reason to add it to some modules but not others.

In general, each *.in.* module generates a single map. The only
exception which I can think of is for multi-channel (e.g. RGB) raster
files, where each channel is imported as a separate raster map (GRASS
itself doesn't support multiple channels in a raster map).

--
Glynn Clements <glynn@gclements.plus.com>

10

On 24/07/08 15:13, Glynn Clements wrote:

Moritz Lennert wrote:

Use ogr2ogr to reproject Shapefiles outside GRASS (it accepts directory of shapefiles as input as well as single shapefiles) and
then import them all with v.in.ogr. You can automate v.in.ogr in Shell using "for in do" syntax (plenty of examples in the archive or Google it).

I don't think you actually need a for-loop. From the v.in.ogr man page:

layer=string[,string,...] OGR layer name. If not given, all available
layers are imported

So, normally, if you don't give a layer all the shapefiles in the directory (dsn=) will be imported.

Note this loads the Shapefiles as *layers* (in the GRASS meaning of it)
of a single output vector map. Not necessarily what one might want.

No definitely not. Didn't know that. IMHO this should be changed...

If you want to load multiple files as individual maps, run v.in.ogr in
a loop.

I don't see any reason to add this functionality to every *.in.*
module, and even less reason to add it to some modules but not others.

In general, each *.in.* module generates a single map. The only
exception which I can think of is for multi-channel (e.g. RGB) raster
files, where each channel is imported as a separate raster map (GRASS
itself doesn't support multiple channels in a raster map).

I won't make an issue of this, but there is a difference in that v.in.ogr takes a data source (directory or file) as input, and this data source can contain many layers. AFAIK, it's the only *.in.* module to do this.

But I don't care enough to worry about it... loops work fine for me. Just don't really understand the advantage of loading all layers into different layers of a GRASS map...

Moritz

11

Moritz Lennert wrote:

>>> Note this loads the Shapefiles as *layers* (in the GRASS meaning of it)
>>> of a single output vector map. Not necessarily what one might want.
>> No definitely not. Didn't know that. IMHO this should be changed...
>
> If you want to load multiple files as individual maps, run v.in.ogr in
> a loop.
>
> I don't see any reason to add this functionality to every *.in.*
> module, and even less reason to add it to some modules but not others.
>
> In general, each *.in.* module generates a single map. The only
> exception which I can think of is for multi-channel (e.g. RGB) raster
> files, where each channel is imported as a separate raster map (GRASS
> itself doesn't support multiple channels in a raster map).

I won't make an issue of this, but there is a difference in that
v.in.ogr takes a data source (directory or file) as input, and this data
source can contain many layers. AFAIK, it's the only *.in.* module to do
this.

And it's only some formats. The OGR shapefile driver accepts a
directory as a data source, but most drivers don't. So far as OGR is
concerned, a directory of .shp/.dbf files is a single multi-layer map,
so that's how it gets imported.

But I don't care enough to worry about it... loops work fine for me.
Just don't really understand the advantage of loading all layers into
different layers of a GRASS map...

Well, I'm not really sure of the reason for having multi-layer maps
(other than "that's how ArcGIS does it"). But given that we have them,
presumably this is how they are supposed to be used.

--
Glynn Clements <glynn@gclements.plus.com>

12

On Thu, 24 Jul 2008, Moritz Lennert wrote:

I won't make an issue of this, but there is a difference in that v.in.ogr takes a data source (directory or file) as input, and this data source can contain many layers. AFAIK, it's the only *.in.* module to do this.

But I don't care enough to worry about it... loops work fine for me. Just don't really understand the advantage of loading all layers into different layers of a GRASS map...

If I might barge in here and suggest a couple of things without fully researching the issue, perhaps (a) this is the simplest solution to avoid the problem of conflicting category IDs in the different Shapefiles and associated dbf files - I would hazard a guess that category IDs can be duplicated between GRASS layers? Complicated cat-renumbering systems are thus neatly avoided by using separate layers. And (b) given discussion in the past about how confusing the GRASS concept of layers is, this would seem to be a case where the GRASS term "layer" makes perfect sense in the context - perhaps the term originally derived from this analogy with the OGR data model?

Paul

13

Tim,
I had a similar problem some time ago, with a lots of shapefiles (very
large area, forest cover).

Here you can find some scripts, perhaps useful.
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

Regards, Paolo

14

Ooops, I forgot the attachment.

Sorry!

2008/7/25 Paolo Craveri <pcraveri@gmail.com>:

Tim,
I had a similar problem some time ago, with a lots of shapefiles (very
large area, forest cover).

Here you can find some scripts, perhaps useful.
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

Regards, Paolo

--
--
Craveri Paolo Livio

Lat. 44° 39' 11.08'' N Long. 7° 23' 25.26'' E
-------------------------------------------------------------
Preferisco ricevere allegati in formato OpenDocument
http://it.wikipedia.org/wiki/OpenDocument
I prefer to receive attachments in OpenDocument format
http://en.wikipedia.org/wiki/OpenDocument

http://www.gnu.org/philosophy/no-word-attachments.it.html

(attachments)

scripts.zip (1.65 KB)

15

Hello,

Here you can find some scripts, perhaps useful.

Thanks you for these scripts. They are really useful.

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.
* I cannot reproject these on the fly be changing the projection of my
location.

=> 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 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?
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. Since geographical analysis also involves data aquisition
and -- later -- a interpretation I want to minimise the processing 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.
But really, GIS is visual work with geoGRAPHICAL data.
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.

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).

Kind regards and thanks for your help,
Timmie

16

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

17

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@hotmail.com, Gchat: jgrn307

18

Tim Michelsen ha scritto:

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.

So, use QGIS! :wink:
Seriously, I understand your feelings. I know most GRASS developers do
not agree with me, but I still think the good thing about GRASS is its
analytical power, and the easiest way to approach it (until you're at
ease with CLI) is through QGIS. Unfortunately this route did not attract
much interest from GRASS (and until recently also from QGIS) developers,
so there are still things to improve in this area.
All the best.
pc
--
Paolo Cavallini, see: * http://www.faunalia.it/pc *

19

Hello Tim,

On Tue, Jul 29, 2008 at 11:41 PM, Tim Michelsen
<timmichelsen@gmx-topmail.de> wrote:
...

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.

We could easily add v.in.ogr.all or v.external.all, I suppose two or
three lines of shell script :slight_smile: Could be stored in the Addons wiki.

* I cannot reproject these on the fly be changing the projection of my
location.

Yes, because it was decided to not support that (see archive of this list).
And, using QGIS I regularly *fail* to do this job.

=> 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 clear words this means that the software is not ready, yet.

I don't agree. You can easily import and reproject single maps even
with the various d.m/gis.m/wxpython user interfaces:
- create new location *graphically* from startup menu, now even with
  location wizard.
- run r/v.proj

Not too much keyboard needed here.

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?

see
http://grass.osgeo.org/wiki/WxPython-based_GUI_for_GRASS#Cartography_tools
-> work in progress

...

Why did I write disappointment? Because GRASS is advertised by OSGEO as
THE most powerful free GIS that can perform any task.

Where did you see "any task"?

Markus

20

>> Here you can find some scripts, perhaps useful.
Thanks you for these scripts. They are really useful.

I tried the merge process with the script "shpmerge.sh" that Paolo sent.
That is really effective and works well.

The only issue is that it show the following error in the bash:
"shpmerge.sh: line 1: #!/bin/bash: No such file or directory"

So the question:
* Can we get this script into GRASS as an utility program?
* Shall we ask the OGR-developers to include
this into their program/distribution?
* Could be wrap a nice GUI around it?
* Could there be a page on the wiki where we can put such utility programs?

Kind regards and thanks,
Timmie