[GRASSLIST:5933] Re: Multiple coordinate systems

John Harrop wrote:

> Is there a way to overlay different projections and/or non-earth 
> coordinate systems in grass on-the-fly?  (Similar to how MapInfo and 
> other systems handle it.)

No; re-projection has to be done explicitly.

--

-- 
Glynn Clements <glynn.clements <at> virgin.net>

[GRASSLIST:5934] Re: Grid transformations

Raymond Wright wrote:

> I would be very grateful if anyone could let me know how to do regridding
> with GRASS5. Specifically, I want to take the EMEP emissions maps of
> sulphur, nitrogen, VOC and carbon monoxide (http://webdab.emep.int/
> <http://webdab.emep.int/> ), which are on a polar-stereographic projection,
> and re-cast them on a Lambert Conformal grid in various grid square sizes
> from 4 to 108km. Is this possible with Grass? What do I need to do? Any help
> would be much appreciated.

Create two locations; one whose projection matches the source data,
and one with the projection you wish to use. Start GRASS using the
first location, and import the data. Exit GRASS, restart it using the
second location, then use r.proj to reproject the data.

--

-- 
Glynn Clements <glynn.clements <at> virgin.net>

[GRASSLIST:5935] Re: Trouble with v.surf.rst

> I am trying to create a surface map from vector contour lines.  The method
> I've been trying is v.surf.rst.

try v.to.rast and r.contour instead of r.surf.contour.
works for me.

r.contour caveat:
It apparently uses a value of 0 for NULL, so any coastline arc will disappear. It's a pain and already filed as
bug 1402. Changing the line to be 0.01 or something fixes it.

are your lines labeled correctly?

[GRASSLIST:5936] Re: Trouble with v.surf.rst

On Tue, Apr 01, 2003 at 02:29:40PM +1200, H Bowman wrote:
[...]
> r.contour caveat:
> It apparently uses a value of 0 for NULL, so any coastline arc will
> disappear. It's a pain and already filed as bug 1402. Changing the line to
> be 0.01 or something fixes it.

>From Justin Hickey I have a new version of r.contour (untested).
It were nice to find a volunteer for testing and comparing.

Markus Neteler

[GRASSLIST:5937] Re. Trouble with v.surf.rst

[GRASSLIST:5938] Re: Multiple coordinate systems

John,

With being a geochemist I often have to work with samples taken along 
lines (north & non-north) and plot them on a UTM map.  I personally just 
load all my data into a database (I like PostgreSQL, but anything is 
good) which has grid and utm coordinate columns.  Then I have a few 
functions (in postgresql and MS Access) that based upon the usergrid 
base-point and degrees of rotation from north, transform all my 
coordinates to UTM or geographic.  For me it's always more convient to 
let my database handle all the coordinate transformations because often 
there is a mixture of samples collected with UTM, usergrid, or 
geographic coordinates or even drill/trench samples (that have a collar 
point, orientation, and from-to distances).  Now with all the samples 
having the same type of coordinates everything can be pulled into the 
map as one big layer if necessary.  And regenerations are faster.

Your e-mail indicates that you are dealing with geophysics and I will 
guess that you are trying to overlay some of those lovely non-north 
grids based upon lines that the project geo layed out for you.  I know 
they are necessary but they drive me crazy too.  But again I have been 
hearing that PostGIST with possibly or can now handle grid data.  In the 
future I think rdms based data will be the proper route even for 
cross-sections such as IP lines.  For one of my clients I have 
PostgreSQL views that transform the sample coordinates (UTM E/N/Elev) to 
user-defined cross-sections coordinates to plot them up in ArcView or 
MapInfo.     

good luck,

Phillip J. Allen
Consulting Geochemist/Geologist
Lima Peru
e-mail: paallen <at> attglobal.net

John Harrop wrote:

> Hi,
>
> I've not been able to come up with a comfortable way of handling 
> projects with multiple coordinate systems in grass.  Perhaps I'm 
> missing something...
>
> Our typical project uses at least two coordinate systems.  One is a 
> local coordinate system oriented by data collection methods and used 
> for processing of such data.  The second is usually a UTM projection 
> and most final maps are produced in this projection.  The relationship 
> between the two is a simple shift and rotate operation since the areas 
> we are working with are quite small.
>
> I can see how to transform one mapset while importing into another 
> mapset, but after that is done you obviously have a potential map 
> version conflict when one but not the other is updated with new data.
>
> Is there a way to overlay different projections and/or non-earth 
> coordinate systems in grass on-the-fly?  (Similar to how MapInfo and 
> other systems handle it.)
>
> Any comments folks?
>
> Thanks,
>
> John Harrop
>
>

[GRASSLIST:5939] Label files from .dxf

[GRASSLIST:5940] reclass imported area files: more awk tricks

The behavior of Grass 5.0 when importing .e00 area files has caused me some
heartache the past. I always end up with thousands of areas with unique
type numbers assigned in dig_cats, even though many areas share the same
text label value. I have come up with an awk script and a command line that
will automatically generate reclass input files to create maps that use the
text label to identify type instead of the arbitrary number assigned by
grass at import time.

First cd to the relevant dig_cats directory.
If your vector file name is $MAP, the command line to create the reclass
file is:

              sort -k 2 -t : $MAP | awk -f reclass.awk > reclass

To fix the vector file, the commands are:

cat reclass | v.reclass -d type=area input=$MAP output=`echo $MAP`_reclass;
v.support `echo $MAP`_reclass;

The same basic process works for raster files if you do it the "cats"
directory and use "r.reclass input=$MAP output=`echo $MAP`_reclass" instead
of v.reclass.

The reclass.awk file is:

##########################################
#   reclass.awk
#   input must be sorted by cat label before running this!
##########################################

 BEGIN { FS=":" ; ind=0 }

/^[#%A-Za-z0]../ { next }

/^[1-9]../ {
if (ind==0) {
   test = $2
   ind++
}

if ($2 != test) ind++
test=$2
printf("%d=%d %s\n",$1,ind,$2)
}
##########################################

[GRASSLIST:5941] basic projection problem

I am trying to project some tiger line data (which I have been told it 
projectionless)
from lat long in it's current location into a new location with is UTM 
zone 10. I created the
new UTM location but when I tried to use v.proj from the new location 
to pull the old lat long map into a new location, I got the following 
error:

cannot initialize pj
cause: elliptical usage required

HELP!

Schuyler Fishman
Schuylerfish <at> earthlink.net
www.mindlikesky.com

[GRASSLIST:5942] Re: basic projection problem

Which version of GRASS? Did you try the latest CVS (I fixed some bugs
yesterday)? Can you provide the output of g.projinfo for your two
locations?

Paul

On Tue, 1 Apr 2003, Schuyler Fishman wrote:

> I am trying to project some tiger line data (which I have been told it
> projectionless)
> from lat long in it's current location into a new location with is UTM
> zone 10. I created the
> new UTM location but when I tried to use v.proj from the new location
> to pull the old lat long map into a new location, I got the following
> error:
>
> cannot initialize pj
> cause: elliptical usage required
>
> HELP!
>
> Schuyler Fishman
> Schuylerfish <at> earthlink.net
> www.mindlikesky.com
>
>