hej,
Am 03.03.2011 um 07:01 schrieb Hamish:
William wrote:
g.extension also changes how GRASS_ADDON_PATH is
interpreted, from GRASS 6 - it used to be a direct path to
the executable folder, ie bin/, now it's a path to the
parent of that. The default user addon paths set by
the Mac startup
Markus wrote:
I can confirm this bug.
The offending line is
sed -e '1d' $STATSTMP | awk -F | '{printf \nUPDATE '${TABLE}' SET
'${col[0]}' = %i , '${col[1]}' = %.2f , '${col[2]}' = %.2f,
'${col[3]}' = %.2f , '${col[4]}' = %.2f , '${col[5]}' = %.2f ,
'${col[6]}' = %.2f , '${col[7]}' = %.2f
On Wed, Mar 2, 2011 at 11:49 PM, Rich Shepard rshep...@appl-ecosys.com wrote:
On Wed, 2 Mar 2011, Markus Neteler wrote:
I fully agree - but we can change only in GRASS 7 for backward
compatibility.
Markus,
As long as I can continue working from the command line in 7 I'll be
happy. Shell
I started making my own legend, but I can't seem to make one with pattern :(
The rectangle function does not accept a pat command. Any workaround or ideas?
Thanks,
Martin
-Opprinnelig melding-
Fra: Hamish [mailto:hamis...@yahoo.com]
Sendt: 3. mars 2011 02:29
Til:
Martin Album Ytre-Eide wrote:
I started making my own legend, but I
can't seem to make one with pattern :( The rectangle
function does not accept a pat command. Any workaround or
ideas?
one idea: try adding clone vareas, but with smaller pwidth and
an impossible SQL where clause so nothing is
Hamish wrote:
one idea: try adding clone vareas, but with smaller pwidth
sorry, use scale*2 with that, not pwidth (pattern line width)
and an impossible SQL where clause so nothing is ever drawn to
the map. Then use those mini-patterns in the vlegend.
Use 'lpos 0' for the real areas so that
On Thu, Mar 3, 2011 at 9:12 AM, Johannes Radinger jradin...@gmx.at wrote:
hej,
Am 03.03.2011 um 07:01 schrieb Hamish:
William wrote:
g.extension also changes how GRASS_ADDON_PATH is
interpreted, from GRASS 6 - it used to be a direct path to
the executable folder, ie bin/, now it's a path
On Wed, 2 Mar 2011, Michael Perdue wrote:
Hate to be a wet blanket, but both NAD27 and NAD83 UTM coordinates are
supposed to be in meters.
Michael,
It's been quite a while but I recall data in NAD27 having units of feet.
Regardless, ...
Since the data have both lat/lon and some version
On Mar 3, 2011, at 12:01 AM, Hamish wrote:
William wrote:
g.extension also changes how GRASS_ADDON_PATH is
interpreted, from GRASS 6 - it used to be a direct path to
the executable folder, ie bin/, now it's a path to the
parent of that. The default user addon paths set by
the Mac startup
On Wed, 2 Mar 2011, Hamish wrote:
The DEMs were originally in lat/lon (NAD83) and imported to that
location.
if the originals are lat/lon then they need to be imported to a lat/lon
location,
As stated.
ok, that looks good, although I wonder why the east and west have become
negative.
Nepomuk Reinhard wrote:
Dear all,
I'm a newbie in grass GIS so I'm sorry, if this question is very simple.
Has anyone any idea how to create a raster map including only the
information of the latitude and longitude of each cell? I want to write a
script to compute the solar elevation
I have a 3-column table with 110,337 rows. The first column is the primary
key to a postgres attribute table, the second column is the longitude, and
the third column is the latitude. Based on the manual page I made the field
separators the pipe '|'. However, I have a syntax error and I don't
On Thu, Mar 03, 2011 at 12:53:04PM -0700, we recorded a bogon-computron
collision of the ru...@bogodyn.org flavor, containing:
On Thu, Mar 03, 2011 at 06:15:39AM -0800, we recorded a bogon-computron
collision of the rshep...@appl-ecosys.com flavor, containing:
On Wed, 2 Mar 2011, Michael
Unfortunately, there are all too many government contractors, who because there
are
still maps out there in NAD 27 use that as the datum and then give UTM
coordinates.
It can be done with many GPS units...
Best, Mark Hall
BLM
From: Rich Shepard
Hi Rich
On 03/03/2011 08:10 PM, Rich Shepard wrote:
I have a 3-column table with 110,337 rows. The first column is the
primary
key to a postgres attribute table, the second column is the longitude,
and
the third column is the latitude. Based on the manual page I made the
field
separators
On Thu, Mar 03, 2011 at 06:15:39AM -0800, we recorded a bogon-computron
collision of the rshep...@appl-ecosys.com flavor, containing:
On Wed, 2 Mar 2011, Michael Perdue wrote:
Hate to be a wet blanket, but both NAD27 and NAD83 UTM coordinates are
supposed to be in meters.
Michael,
On Thu, Mar 03, 2011 at 06:15:39AM -0800, we recorded a bogon-computron
collision of the rshep...@appl-ecosys.com flavor, containing:
On Wed, 2 Mar 2011, Michael Perdue wrote:
Hate to be a wet blanket, but both NAD27 and NAD83 UTM coordinates are
supposed to be in meters.
[SNIP]
On Thu, 3 Mar 2011, Micha Silver wrote:
Worked for me on those few rows. My guess is that somewhere down among
those 100,000 rows there's one that's either missing the '|' character. or
missing the actual digits or some such.
OK. I'll go look.
BTW, if you're specifying the '-t' option to
On Thu, 3 Mar 2011, Tom Russo wrote:
This is true of State Plane Coordinate Systems in NAD27, but not UTM.
Tom,
That looks famililar.
FWIW, it looks like since your lat/lons are specified at such low
precision, the NAD27/NAD83 datum shift might be irrelevant.
I decided to use the
On Thu, 3 Mar 2011, Tom Russo wrote:
Well, maybe I'm wrong about that. I used the cs2cs utility from the
proj.4 system to convert the first line of your lat/lons to UTM in both
NAD83 and NAD27, and in neither case did I get what is in the table for
UTM:
Interesting, Tom. Thanks for
On Thu, 3 Mar 2011, Micha Silver wrote:
My guess is that somewhere down among those 100,000 rows there's one
that's either missing the '|' character. or missing the actual digits or
some such.
Micha,
It turns out there were two types of faulty rows to be eliminated. My awk
script got rid
On Thu, 3 Mar 2011, Micha Silver wrote:
Worked for me on those few rows. My guess is that somewhere down among
those 100,000 rows there's one that's either missing the '|' character. or
missing the actual digits or some such. BTW, if you're specifying the '-t'
option to *not* create the attrib
Almost there:
GRASS 6.5.svn (Nevada-utm27):~/grassdata v.in.ascii -b --o
in=/home/rshepard/GIS/data/Nevada/nv_wells.txt out=water_wells format=point
fs='|' skip=1 columns='well_log varchar(8), x double precision, y double
precision' x=2 y=3 z=0 cat=0
Scanning input for column types...
Maximum
Hi All,
I'm having a problem importing a jpeg using r.in.gdal. I've done it
successfully in the past but I have forgotten what I did. Now when I import
a jpeg into an xy location it is just a solid block of color (name.red,
name.blue, name.green). I think it has something to do with the
24 matches
Mail list logo
