[GRASS-user] Import, project

[Nikos Alexandris]

(Apologies for the interference...)

Hamish:
> > you have to create a GRASS Location for each source map projection, then
> > pull them all into the target Location with r.proj or v.proj.

stn wrote: 
> Hi Hamish, thanks for the infos.

> Here is one thing I can't get into my head.
> 
> First there is the problem that I do not know the coordinates and
> projection etc of the two files mentioned. Of course I can go to someone
> with esri-software and ask him to check that for me.

Shapefiles are build up by various files normally (not only one). Check if you 
have the ".shx" _and_ the one with extension ".prj". If I am not wrong even 
under @rc-gis the ".prj" is required to work properly.

> But in my (apparently very naive) view I this is completely not the point.
> If I have to use esri anyway then why bother taking data into grass ??

There are several reasons why one can/should use grass. Long discussion. To 
make the long story short, there are links which might be of your interest [1]
[2][3].

If you are convinced that F(L)OSS is the way to go, then you have a *STRONG* 
reason to stick with grass and/or other "open" geo-spatial tools.

> What I would think is this: If I can find out the projection/coordinates
> etc of the shapefile by any manual means then this info MUST BE included
> in the shapefile itself. Along with the actual geodata.

I think these infos are not integrated in the file.

> More so the import-program within grass cannot import even a single byte
> without thorough knowledge of the imported format, but i seems that it can
> only read objects but not their coordinate-system.

grass-gis (in its entirety) is "strict" and clean, an honest friend which you 
can rely on, discuss, learn and find the way.
 
> So: If all the info is already in the shapefile there then why
> 
> 1) do I have to manually find it by some way outside grass and

> 2) why doesn't the import-program simply read that info from the file, read
> the coordinates and projection from the current location and the call the
> appropriate projection-program to reproject the imported file to fit the
> current location.
> 
> All the infos (proj/coord/bounds/etc) of import and target are there (says
> the naive man :-)

It would useful/helpful to feed the list with the actual information 
(filenames for example) that are beforehand. If those are there (as separate 
files, which is the way they should exist) then it should fairly easy and 
strait to import the data clean(ly) in grass' database.

> , the sequence of operations is completely obvious and
> always exactly the same and yet everything has to be done manually.
> 
> If I want to recode a moviefile to another format I tell the encoder what I
> want to have as an output and the encoder then looks by itself what format
> the original has. What is different about geodata ?
> 
> I don't really mind doing that for one map. But somehow I expect lots more
> maps from different sources being added later and each one causing lots of
> work. What is it I don't understand here?
 
>  > 3) how to export an ascii/excel/csv-list of every raster-point with a)
>  > 
> > > the corresponding scalar and b) the administrative region and c) the
> > > coordinates lat/long of the raster-point
> > 
> > r.out.xyz, or r.to.vect + v.out.ascii
> > maybe with some other custom magic along the way.
> 
> Thanks, that sounds promising. I will try ASAP.
> 
> > from the command line GDAL's ogr2ogr and gdalwarp can reproject
> > shapefiles and GeoTiffs etc directly.
> 
> Tried that (on ubuntu) :
> 
> user at nb ~ $ gdalwarp file1.shp file1.out
> ERROR 4: `file1.shp' not recognised as a supported file format.
> 
> and: gdalwrap --formats lists 88 formats including a few from esri, but no
> shapefile.

hint: check the output of "ogrinfo --formats"

(
gdal is a library of tools that handle raster data [4]. ogr tools are for 
vector stuff [5].
)

Good luck, Nikos

---
[1] <http://grass.osgeo.org/intro/firsttime.php>
[2] <http://www.gnu.org/philosophy/categories.html>
[3] <http://www.dwheeler.com/oss_fs_why.html>

[4] <http://www.gdal.org/> and <http://www.gdal.org/gdal_utilities.html>
[5] <http://www.gdal.org/ogr/> and <http://www.gdal.org/ogr_utilities.html>