Re: [GRASS-user] Does Grass Support Layers??

2008-02-28 Thread Jachym Cepicky
Kunal, maybe time for some documentation/book ?

Kunal Malik píše v Čt 28. 02. 2008 v 10:03 +0530:
 Could I create ,delete  modify layers in Grass Tools  how??

http://grass.osgeo.org/grass63/manuals/html63_user/helptext.html
http://grass.osgeo.org/grass63/manuals/html63_user/rasterintro.html
http://grass.osgeo.org/grass63/manuals/html63_user/imageryintro.html
http://grass.osgeo.org/grass63/manuals/html63_user/vectorintro.html


 Could i set Transparency of Layers using Grass,.

yes, do you mean raster or vector layers?

for rasters: d.rast -o
for vectors: d.vect

for both: check the gui

jachym

 Please Suggest?
 
 
 
 -- 
 Thanks  Regards
 
 Kunal Malik
 09871147561 
 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user
-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub


signature.asc
Description: Toto je digitálně	 podepsaná část	 zprávy
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] Can't import shape files

2008-02-28 Thread mohannbr

Hi,
 
   I use postgresql driver for GRASS. I have GRASS 6.2.2 installed in my
comp. with 'host=localhost,dbname=grass60test'.
When i try to import .shp files using v.in.ogr , i get the error...
ERROR:  invalid byte sequence for encoding UTF8: 0xae
HINT:  This error can also happen if the byte sequence does not match the
encoding expected by the server, which is controlled by client_encoding.
How do i correct it???

Sometimes i get the error ...
A datum name nad27 (North_American_Datum_1927) was specified without
transformation parameters.

Non-interactive mode: the GRASS default for nad27 is
towgs84=-22.000,157.000,176.000.

Projection of dataset does not appear to match current location.

I overcome the above error using -o flag.but then while displayin the img,
get the error...
The bounding box of the map is outside the current region, nothing drawn..
I tried importing some 30 sample shape files and am desperate for a
solution. please help.
-Mohan
-- 
View this message in context: 
http://www.nabble.com/Can%27t-import-shape-files-tp15732106p15732106.html
Sent from the Grass - Users mailing list archive at Nabble.com.

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Can't import shape files

2008-02-28 Thread Hamish
mohannbr wrote:
 but then while displayin the img,get the error...
 The bounding box of the map is outside the current region, nothing
 drawn..


set the region zoom to match the extents of the vector map with
g.region.

http://grass.gdf-hannover.de/wiki/Region_Map



Hamish



  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] statistic values transfer between vector layers

2008-02-28 Thread christian Brandt

Dear List,

I am trying to transfer statistic values tabulatedfrom one vector theme 
(buildings) to an attribute table of a second theme (grid net, please see the  
attachement). The target of this operation will be a rasterisation of the 
second theme with the category of the statistic values.

Any suggestions?

 Regards

Chris
_
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/attachment: geb_grd_klein.png___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] v.digit background colour

2008-02-28 Thread Craig Leat

Hi

It appears that the v.digit option: settings - Symbology - Background 
is broken, because I am unable to change the background colour. A 
further annoyance is that the background colour changes from white to 
cyan whenever a background vector is added. If a raster is added the 
background stays white.


Am I missing something?

My system: GRASS trunk and Ubuntu Gutsy

Regards

Craig.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] v.digit background colour

2008-02-28 Thread Nikos Alexandris
On Thu, 2008-02-28 at 13:19 +0200, Craig Leat wrote:
 Hi
 
 It appears that the v.digit option: settings - Symbology - Background 
 is broken, because I am unable to change the background colour. A 
 further annoyance is that the background colour changes from white to 
 cyan whenever a background vector is added. If a raster is added the 
 background stays white.

I confirm this.
 
 Am I missing something?
 
 My system: GRASS trunk and Ubuntu Gutsy
The same

 Regards
 
 Craig.

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] statistic values transfer between vector layers

2008-02-28 Thread Martin Wegmann
On Donnerstag, 28. Februar 2008 11:28:00 christian Brandt wrote:
 Dear List,

 I am trying to transfer statistic values tabulatedfrom one vector theme
 (buildings) to an attribute table of a second theme (grid net, please see
 the  attachement). The target of this operation will be a rasterisation of
 the second theme with the category of the statistic values.

 Any suggestions?

v.to.rast separated by attributes
set g.region to grid
r.resamp.stats

more ideas at Dylans blog:
http://casoilresource.lawr.ucdavis.edu/drupal/node/275

Martin

  Regards

 Chris
 _
 Express yourself instantly with MSN Messenger! Download today it's FREE!
 http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/



-- 
**

University of Wuerzburg
Institute of Geography
Department of Remote Sensing
Am Hubland
97074 Wuerzburg, Germany
@
German Aerospace Center (DLR)
German Remote Sensing Data Center (DFD)
Environment and Security (US)

Phone:  +49-(0)931-888-4797
Fax:+49-(0)931-888-4961
Email:  [EMAIL PROTECTED]

**
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] Re: GRASS-user] Does Grass Support Layers??

2008-02-28 Thread Michael Barton


On Feb 28, 2008, at 3:25 AM, [EMAIL PROTECTED] wrote:


Date: Thu, 28 Feb 2008 10:03:35 +0530
From: Kunal Malik [EMAIL PROTECTED]
Subject: [GRASS-user] Does Grass Support Layers??
To: grass-user@lists.osgeo.org, [EMAIL PROTECTED]
Message-ID:
[EMAIL PROTECTED]
Content-Type: text/plain; charset=iso-8859-1

Could I create ,delete  modify layers in Grass Tools  how??
Could i set Transparency of Layers using Grass,.
Please Suggest?



--  
Thanks  Regards


Kunal Malik
09871147561


While there are different ways to to this, it is handled in a very  
straightforward way in the GUI. Are you using the GUI?


Michael
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] Help: Completely confused about multi-layered vectors trying to import TIGER/Line files

2008-02-28 Thread Tom Russo
I have been trying to wrap my brain around multi-layered GRASS vectors and
have only succeeded in wrapping my brain into knots.  Perhaps someone here with 
a solid understanding of this stuff can help me.

I'm trying to figure out how to import TIGER/Line data and actually get the
attributes of areas pulled in.  This is trouble.

The v.in.ogr documentation has an example of how to do it:


v.in.ogr  dsn=~/TIGER/BC_TGR  layer=CompleteChain,PIP output=t35001_all \
 type=boundary,centroid snap=-1

which does indeed import the CompleteChain layer and PIP (Polygon Internal 
Point) layers --- it puts the boundaries in layer 1 and the centroids in 
layer 2, and if I do a 
  d.vect t35001_all layer=2
I can see the areas just fine.

Thing is, TIGER data has almost no usable attributes in the PIP layer itself 
--- this is nothing more than a centroid with an attribute POLYID, telling 
nothing about the area.  To get that information, one needs additional tables 
linked to the POLYID field.  The TIGER data tries to be a normal form database,
so there are many tables with no geometry that relate back to linking fields
in the attribute tables that are attached to geometry.

There's another table in the TIGER data called Polygon that has more 
attributes related to the census, such as congressional district and such.
Actual names  and types of areas (parks, military installations, etc) are 
linked through two tables, AreaLandmarks and Landmarks --- the first links 
POLYID to a LAND attribute (an integer) and the second links the LAND 
attribute to an actual name --- there is a many-to-one relationship between
AreaLandmarks and Landmarks.  The latter table actually contains the feature 
class code that tells you what type of landmark the polygon represents.  Not 
every polygon has a matching record in AreaLandmarks, only those that actually 
represent landmarks.  The other polygons are just administrative regions or 
other artificial areas.  On top of that, there appear to be some records of
Landmarks that do NOT have any connection to records in AreaLandmarks -- these 
are point landmarks, and so the Landmarks layer of the TIGER data also has 
point geometry.  Where there is a relationship between Landmarks and 
AreaLandmarks I suppose the Landmark point would be usable as a label point.

Attaching the Polygon records to the centroids seems an easy problem, as
every centroid has a Polygon record with attributes, and all that's needed 
is a table join on the POLYID field between the table already attached to the 
centroids and the Polygon table imported with db.in.ogr.  I can do that.

The AreaLandmarks are another matter --- only a small fraction of the 
polygons have associated AreaLandmarks.  For example, in the TIGER/Line data 
for Bernalillo County, New Mexico, there are 18597 PIP and Polygon records, 
but only 1292 AreaLandmarks records.  This makes it seem to me that 
AreaLandmarks would be a prime candidate for a third layer in the 
t35001_all vector.  My problem is selecting the geometric objects to tie to 
the records of the AreaLandmarks table.

I have tried a number of naive things that didn't work.  First, I tried to
add a cat field to the AreaLandmarks table, then use an SQL UPDATE query
to copy the cat column of the table associated with the PIP records (which
gets called t35001_all_2 by the v.in.ogr import) that have POLYIDs that
match the ones in the AreaLandmarks:

   echo UPDATE t35001_AreaLandmarks SET cat=(SELECT cat FROM t35001_all_2 
WHERE t35001_all_2.POLYID=t35001_AreaLandmarks.POLYID) | db.execute

and then adding AreaLandmarks as a third database connection.  That SQL
update worked fine in the sense that the AreaLandmarks table got the right
cat values out of the layer 2 table, but the approach didn't work, because 
as far as I understand it the categories of objects in layer 2 haven't 
actually been assigned to geometric objects for layer 3 yet, so linking this 
way is meaningless at this step.  Attaching the table gives me some warnings, 
and apparently attaches no database records to any geometry at all.

So then I tried creating a new reclassified vector with 

  v.reclass in=t35001_all out=foo col=POLYID layer=2 type=centroid

setting the categories of layer 2 in the new vector to be equal to the POLYID 
of layer 2 in the old vector without copying the table, then doing:

  echo  UPDATE t35001_AreaLandmarks SET cat=POLYID | db.execute

and attaching that table to layer 2 of the reclassified vector.  This sorta
kinda worked, in that the AreaLandmarks records were attached to features
properly, but left a very large fraction of the features without database
connections.  So I could display vector foo and use d.what.vect to query
my new attributes, but there were 17305 polygons out of 18597 that I could 
click and get a warning of a missing database entry --- I would rather have 
only the polygons that have an AreaLandmarks record show up at all when 
displaying this 

Re: [GRASS-user] Can't import shape files

2008-02-28 Thread mohannbr



hamish_b wrote:
 
 mohannbr wrote:
 but then while displayin the img,get the error...
 The bounding box of the map is outside the current region, nothing
 drawn..
 
 
 set the region zoom to match the extents of the vector map with
 g.region.
 
 http://grass.gdf-hannover.de/wiki/Region_Map
 
 
 
 Hamish
 
 
 
  
 
 Looking for last minute shopping deals?  
 Find them fast with Yahoo! Search. 
 http://tools.search.yahoo.com/newsearch/category.php?category=shopping
 
 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user
 
 
Thank u! g.region did work.but how do i solve the error ERROR:  invalid
byte sequence for encoding UTF8: 0xae .. Also, could u please send some
links where i can find sample area vector shape files.
-Mohan
-- 
View this message in context: 
http://www.nabble.com/Can%27t-import-shape-files-tp15732106p15739203.html
Sent from the Grass - Users mailing list archive at Nabble.com.

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Help: Completely confused about multi-layered vectors trying to import TIGER/Line files

2008-02-28 Thread Dylan Beaudette
On Thu, Feb 28, 2008 at 7:39 AM, Tom Russo [EMAIL PROTECTED] wrote:
 I have been trying to wrap my brain around multi-layered GRASS vectors and
  have only succeeded in wrapping my brain into knots.  Perhaps someone here 
 with
  a solid understanding of this stuff can help me.

  I'm trying to figure out how to import TIGER/Line data and actually get the
  attributes of areas pulled in.  This is trouble.

  The v.in.ogr documentation has an example of how to do it:


  v.in.ogr  dsn=~/TIGER/BC_TGR  layer=CompleteChain,PIP output=t35001_all \
  type=boundary,centroid snap=-1

  which does indeed import the CompleteChain layer and PIP (Polygon Internal
  Point) layers --- it puts the boundaries in layer 1 and the centroids in
  layer 2, and if I do a
   d.vect t35001_all layer=2
  I can see the areas just fine.

  Thing is, TIGER data has almost no usable attributes in the PIP layer itself
  --- this is nothing more than a centroid with an attribute POLYID, telling
  nothing about the area.  To get that information, one needs additional tables
  linked to the POLYID field.  The TIGER data tries to be a normal form 
 database,
  so there are many tables with no geometry that relate back to linking fields
  in the attribute tables that are attached to geometry.

  There's another table in the TIGER data called Polygon that has more
  attributes related to the census, such as congressional district and such.
  Actual names  and types of areas (parks, military installations, etc) are
  linked through two tables, AreaLandmarks and Landmarks --- the first links
  POLYID to a LAND attribute (an integer) and the second links the LAND
  attribute to an actual name --- there is a many-to-one relationship between
  AreaLandmarks and Landmarks.  The latter table actually contains the feature
  class code that tells you what type of landmark the polygon represents.  Not
  every polygon has a matching record in AreaLandmarks, only those that 
 actually
  represent landmarks.  The other polygons are just administrative regions or
  other artificial areas.  On top of that, there appear to be some records of
  Landmarks that do NOT have any connection to records in AreaLandmarks -- 
 these
  are point landmarks, and so the Landmarks layer of the TIGER data also has
  point geometry.  Where there is a relationship between Landmarks and
  AreaLandmarks I suppose the Landmark point would be usable as a label point.

  Attaching the Polygon records to the centroids seems an easy problem, as
  every centroid has a Polygon record with attributes, and all that's needed
  is a table join on the POLYID field between the table already attached to the
  centroids and the Polygon table imported with db.in.ogr.  I can do that.

  The AreaLandmarks are another matter --- only a small fraction of the
  polygons have associated AreaLandmarks.  For example, in the TIGER/Line data
  for Bernalillo County, New Mexico, there are 18597 PIP and Polygon records,
  but only 1292 AreaLandmarks records.  This makes it seem to me that
  AreaLandmarks would be a prime candidate for a third layer in the
  t35001_all vector.  My problem is selecting the geometric objects to tie to
  the records of the AreaLandmarks table.

  I have tried a number of naive things that didn't work.  First, I tried to
  add a cat field to the AreaLandmarks table, then use an SQL UPDATE query
  to copy the cat column of the table associated with the PIP records (which
  gets called t35001_all_2 by the v.in.ogr import) that have POLYIDs that
  match the ones in the AreaLandmarks:

echo UPDATE t35001_AreaLandmarks SET cat=(SELECT cat FROM t35001_all_2 
 WHERE t35001_all_2.POLYID=t35001_AreaLandmarks.POLYID) | db.execute

  and then adding AreaLandmarks as a third database connection.  That SQL
  update worked fine in the sense that the AreaLandmarks table got the right
  cat values out of the layer 2 table, but the approach didn't work, because
  as far as I understand it the categories of objects in layer 2 haven't
  actually been assigned to geometric objects for layer 3 yet, so linking this
  way is meaningless at this step.  Attaching the table gives me some warnings,
  and apparently attaches no database records to any geometry at all.

  So then I tried creating a new reclassified vector with

   v.reclass in=t35001_all out=foo col=POLYID layer=2 type=centroid

  setting the categories of layer 2 in the new vector to be equal to the POLYID
  of layer 2 in the old vector without copying the table, then doing:

   echo  UPDATE t35001_AreaLandmarks SET cat=POLYID | db.execute

  and attaching that table to layer 2 of the reclassified vector.  This sorta
  kinda worked, in that the AreaLandmarks records were attached to features
  properly, but left a very large fraction of the features without database
  connections.  So I could display vector foo and use d.what.vect to query
  my new attributes, but there were 17305 polygons out of 18597 that I 

[GRASS-user] GRASS tutorial in Portuguese (pt-br)

2008-02-28 Thread Carlos Guâno Grohmann
Hello all.

This is just to announce that a new tutorial is available, in
Brazilian Portuguese (pt-br). I wrote it over the last year, and
tested it in short-course I gave last week. The plans are to keep
updating it, with new sections and errors corrections. Some of it is
based on the GDF tutorial (Dassau et al), and some is based on my own
experience.

http://www.igc.usp.br/pessoais/guano/grass.html

cheers

Carlos



-- 
+---+
  Carlos Henrique Grohmann - Guano
  Geologist M.Sc  - Doctorate Student at IGc-USP - Brazil
Linux User #89721  - carlos dot grohmann at gmail dot com
+---+
_
Good morning, doctors. I have taken the liberty of removing Windows
95 from my hard drive.
--The winning entry in a What were HAL's first words contest judged
by 2001: A SPACE ODYSSEY creator Arthur C. Clarke

Can't stop the signal.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] How to find out an angle between to points on the map (for r.plane, r.lake)

2008-02-28 Thread Philipp Steigenberger

Hi
I want to work with r.plane and r.lake to get simulate floodings in DTMs.

In the section of interest there is a river which runs from about SSW to 
NNE. For r.plane I need the

azimuth. Is there a tool in GRASS which tells me the angle between two
points I mark on the map like I can measure in between two points with 
d.measure?




Could you recommend other tools to simulate  flooding events in GRASS?


Thank you
cheers
Philipp
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] kml topology... ?

2008-02-28 Thread Dylan Beaudette
On Tuesday 26 February 2008, Nikos Alexandris wrote:
 Continuing my small quest with kml files... and bombing you with simple
 questions ;-p

 are kml files carrying topology information besides coordinates?

I doubt it. As far as I know they are just simple features.


 I needed to manually correct a kml file which looked very bad after
 importing in GRASS (with -c  otherwise it was not useful!)

i am not surprised that a KML file resulted in a topologically broken file. 
These days everyone and their brother are creating KML via all sorts of 
methods-- most of which have little notion/concern for 
topological-correctness. 

 Automatic cleaning is really not useful even after trying to feed with
 logical thresholds the various tools.

Try opening the file with v.digit and look for oddities.

 Cheers,

 Nikos

Dylan

-- 
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] kml topology... ?

2008-02-28 Thread Nikos Alexandris

On Thu, 2008-02-28 at 09:15 -0800, Dylan Beaudette wrote:

Thank you for your reply Dylan!

 On Tuesday 26 February 2008, Nikos Alexandris wrote:
  Continuing my small quest with kml files... and bombing you with simple
  questions ;-p
 
  are kml files carrying topology information besides coordinates?
 
 I doubt it. As far as I know they are just simple features.
 
 
  I needed to manually correct a kml file which looked very bad after
  importing in GRASS (with -c  otherwise it was not useful!)
 
 i am not surprised that a KML file resulted in a topologically broken file. 
 These days everyone and their brother are creating KML via all sorts of 
 methods-- most of which have little notion/concern for 
 topological-correctness. 
+1
 
  Automatic cleaning is really not useful even after trying to feed with
  logical thresholds the various tools.
 
 Try opening the file with v.digit and look for oddities.

Had to correct (almost) everything. Tha data are supposed to come from a
GPS measurement session.

All polygons were open after importing in GRASS. Yet there were
centroids inside this virtually closed boundaries. And the strange thing
is that one (call it) centroid was out of the virtual boundaries... 

Don't know, maybe my mistake for this last statement about the centroid
falling out.

Cheers!

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Help: Completely confused about multi-layered vectors trying to import TIGER/Line files

2008-02-28 Thread Dylan Beaudette
On Thursday 28 February 2008, Tom Russo wrote:
 On Thu, Feb 28, 2008 at 07:57:48AM -0800, we recorded a bogon-computron 
collision of the [EMAIL PROTECTED] flavor, containing:
  TIGER data (in its current format) is a beast to work with-- in any
  GIS. I have found that the simplest way to get normal looking data
  out of the TIGER files was with the tutorial on processing these data
  using PostGIS [1]. There are excellent instructions on the GeoServer
  page [1] that make use of basic PostGIS functionality, along with some
  self-contained java utilities. Following those instructions I was able
  to get *most* of the point, line, and polygon data (with meaningful
  attributes) extracted to simple tables in PostGIS. It would be a
  simple matter to export to GRASS from there.

 I will take a look at that.

 I can also do some of this processing using OGR and Python (I once had the
 displeasure of working on such a script to make polygon shapefiles out
 of TIGER/Line files), but my goal here is not so much what tools external
 to GRASS can I use to recast the problem but how can I learn GRASS tools
 better?

Understandable-- although I would look for a better data set from which to 
learn about layers. That TIGER data is a beast.

  I think that you can get 2000 TIGER data, by county, from our favorite
  'leading GIS vendor' for free [2]. That format should be simpler to
  use.

 Yeah, but that won't teach me anything about layers in GRASS.

Understandably.

  There is also tiger2shp [3] which is now distributed for free (Windows).
 
  Finally, it looks like the US Census will be moving away from the
  current data format, and will be henceforth distributing their data as
  shapefiles [4]. Hurray!

 Yeah, saw that some time ago.  I had concerns about the initial set of
 attributes they said they would be distributing in the data, but they have
 changed that and it looks usable.  Those will be available in March,
 according to http://www.census.gov/geo/www/tiger/tgrshp.html

  I cannot offer any insight into the GRASS vector/layers system right
  now, but there are several good threads from a couple of months ago on
  this very topic (vector/layers/confusion).

 I'll see if I can search the archives and find those.

Here is a good starting point:

http://www.nabble.com/forum/Search.jtp?forum=1200local=yquery=layer

If there aren't any good examples, it might be nice to work up something for 
the new NC sample dataset -- so that there is a common framework for 
teaching/learning about vector layers. In the last 5 years I have seen the 
topic come up several times.


Cheers,
Dylan

-- 
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] RE: [GRASS-dev] r.out.gdal Gtiff output does not preserve color tables

2008-02-28 Thread Patton, Eric
can you zoom a little bit so that the region is smaller than the raster
and then export with r.out.gdal to see whether it is still black?
Are you also getting warning about nulls in the data even if there  
are none?
I think there is a bug in the program (and it also does not let you set
the number of decimal digits so it produces numbers with large number
of digits that are useless).

thanks, Helena

Helena,

Zooming in to a smaller region than the raster doesn't change the results. I do 
get 
warnings about nulls, but it seems to make sense given the shape of the data 
I'm working
with relative to the region.

I exported a series of tiffs using r.out.gdal today, using type=Byte and 
type=UInt16. ArcGIS 9.2
was able to load the UInt16 tiffs, although very, very slowly. The 
elevation.10m raster from
Spearfish took about 2 minutes to load, and it was only 5.6MB in size. The long 
loading time
was due to the enormous size of the color table: 65,536 (2^16) colors. I can't 
imagine
how long it would take Arc to load a 200MB tiff with this many colors. It would 
probably crash.

All of the Byte tiffs were red. A look at the color table in Arc showed that 
all of the 255 colors were a repeating 
pattern of white-to-red (i.e., 0-31, 32-63, etc.), with no green or blue 
colors. 

I've never had a problem with the output from r.out.tiff, using it for 6 years 
now. I can view these
tiffs in every image viewer and GIS on both Linux and Windows. I imagine the 
reason for this is the relatively
simplified color tables in r.out.tiff tiffs? I would be great if there was a 
way to get 
georeferencing information installed in the headers of tiffs created from 
r.out.tiff. The output from 
r.out.gdal seems to be either way too detailed, or not mapped properly into a 
255 color space. 

Has anyone had success using the type=Byte in r.out.gdal to get consistently 
good output for use in other GIS?

~ Eric.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] kml topology... ?

2008-02-28 Thread Nikos Alexandris

On Thu, 2008-02-28 at 09:23 -0800, Dylan Beaudette wrote:
 On Thursday 28 February 2008, Nikos Alexandris wrote:
  On Thu, 2008-02-28 at 09:15 -0800, Dylan Beaudette wrote:
 
  Thank you for your reply Dylan!
 
   On Tuesday 26 February 2008, Nikos Alexandris wrote:
Continuing my small quest with kml files... and bombing you with simple
questions ;-p
   
are kml files carrying topology information besides coordinates?
  
   I doubt it. As far as I know they are just simple features.
  
I needed to manually correct a kml file which looked very bad after
importing in GRASS (with -c  otherwise it was not useful!)
  
   i am not surprised that a KML file resulted in a topologically broken
   file. These days everyone and their brother are creating KML via all
   sorts of methods-- most of which have little notion/concern for
   topological-correctness.
 
  +1
 
Automatic cleaning is really not useful even after trying to feed with
logical thresholds the various tools.
  
   Try opening the file with v.digit and look for oddities.
 
 Hi,
 
  Had to correct (almost) everything. Tha data are supposed to come from a
  GPS measurement session.
 
 I would think that the results from such as session be points or lines...

Probably. GPS measurement from a Forest Service office in Greece. I am
not saying it ironically, but not everybody knows how and, even worse,
takes the time to set-up a GPS session properly... and this could be the
case.
 
  All polygons were open after importing in GRASS. Yet there were
  centroids inside this virtually closed boundaries. And the strange thing
  is that one (call it) centroid was out of the virtual boundaries...
 
 I wonder where the polygons came from -- could it be that one of the import 
 steps mistook the geometry in KML file as polygons? Line data that are 
 interpreted as polygons---especially in the presence of overlapping 
 features---would definitely cause some craziness.  

Fire, as known, was for Greece a Tragedy this summer. There is a private
initiative from somebody doing a great job: collecting burnt area's and
publishing under GPL in kml formats. It's a great job from all kinds of
aspects (political, social, etc). Of course this is not the place to
extend the discussion about this.

However,

I discovered that importing a kml file of my interest (finally) in GRASS
didn't show me what I expected to see.

 
  Don't know, maybe my mistake for this last statement about the centroid
  falling out.
 
  Cheers!
 
 Have the original data on hand?

One example http://tilaphos.blogspot.com/2008/01/blog-post_30.html 

The kml file I am talking about is (for which it is stated that it's
only a rough estimation of burned areas):
http://tilaphos.googlepages.com/Korinthia_estimate_2007.kmz

(there are lot's of kml's.. all of them referering to burned areas)

I am about to prepare a small step-by-step guide on how to import kml's
in GRASS. I got support from the man who run's the blog as well.

I would like to point out some basics about topology, shapefiles and kml
files. Of course I am not the Expert on all but a some remarks I could
provide to improve future GPS sessions.

If you are interested more I can play the translator.

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Help: Completely confused about multi-layered vectors trying to import TIGER/Line files

2008-02-28 Thread Moritz Lennert

On 28/02/08 16:39, Tom Russo wrote:

I have been trying to wrap my brain around multi-layered GRASS vectors and
have only succeeded in wrapping my brain into knots.  Perhaps someone here with 
a solid understanding of this stuff can help me.




[...]



Since I'm rambling now, I'll just cut to the chase and ask my question:

 Given a GRASS vector with two attached database tables, one of which (layer
 2, attaching attributes to centrois) has a key field POLYID, how can I create 
 a new layer using a third, much smaller table, that also has a POLYID field, 
 such that the new layer only contains that subset of centroids where the 
 third layer table's POLYID matches layer 2's POLYID for that centroid?





I think at this stage your best bet is probably to do something like this:

v.category OldMap option=add layer=3 out=NewMap

#find a link between the category numbers created and the original
# categories, this should work:

v.build OldMap option=cdump  TempFile

# You will have to edit TempFile to only take into account layer 2 and
# then find a way to import the results into your database

v.db.connect -o NewMap layer=3 table=NewTable

#to remove all centroids you do not want:
v.edit tool=delete
or
v.extract

There might be an easier way, though...

I think that you also might want to file a few wishes in the tracker, 
such as:


- extend v.category with an option to use a column linked to an existing 
layer as the cat for a new layer
- allow v.extract to write the results to another layer of the same file 
instead of a different file
- extend v.patch to allow to patch different maps into different layers 
of the output map

- create a v.copy.layers to copy elements of one layer to another

Moritz
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Re: GRASS-user] Help: Completely confused about multi-layered vectors trying to import TIGER/Line files

2008-02-28 Thread Tom Russo
On Thu, Feb 28, 2008 at 10:38:00AM -0700, we recorded a bogon-computron 
collision of the [EMAIL PROTECTED] flavor, containing:
 
 On Feb 28, 2008, at 8:57 AM, [EMAIL PROTECTED] wrote:
 
 Date: Thu, 28 Feb 2008 08:39:29 -0700
 From: Tom Russo [EMAIL PROTECTED]
 Subject: [GRASS-user] Help: Completely confused about multi-layered
  vectors trying to import TIGER/Line files
 To: grass-user@lists.osgeo.org
 Message-ID: [EMAIL PROTECTED]
 Content-Type: text/plain; charset=us-ascii
 
 I have been trying to wrap my brain around multi-layered GRASS vectors 
 and
 have only succeeded in wrapping my brain into knots.  Perhaps someone here 
 with
 a solid understanding of this stuff can help me.
 
 I'm trying to figure out how to import TIGER/Line data and actually get 
 the
 attributes of areas pulled in.  This is trouble.
 

Michael:

Thank you for answering, but your answer has either highlighted how
poorly I expressed my question, or thrown into sharper relief how
confused I am about this.  Some of what you say below was already
clear to me, but there's a big gap between Each vector file (and
object) can have more than one key field to link it to an attribute
table, (which I knew), Each key (AKA 'cat in layer #') can link to
a line/record in an attribute table (which also must have an 
identical integer key field, that doesn't HAVE to be called cat, but
often is).(which I also knew), and the thing I really want to know --- and
it is the latter that I think I haven't explained well.

 The 'layers' you mention here are 2 very different beasts.
 
 First OGR. The underlying concept is that some data (e.g., CAD) come in a 
 file that has multiple 'layers' of vectors that may (or may not) have 
 different associated data. I don't know TIGER files, so I don't know if 
 they come this way or not. 

I'll clarify, then, because that's not exactly how TIGER is layed out.
There are a number of vectors, and each is related to one or more
tables of attributes, but OGR doesn't make the connection itself --- there 
are simply common attributes between tables that one is left to associate
onesself.

The TIGER data comes in a number of files, each containing a series of
records.  Each file has a different record type.  There is a record
type that defines nodes in Complete Chains, a record type for shape
points that define the vertices (between the nodes) of the chains, a
record type for Polygon Internal Points (centroids), a record for
polygon attributes, a record for linking chains to polygons (with
left/right polygon ids) etc.

When unpacked into a directory, OGR views the collection as a set of 
layers (I HATE that this word is used in so many different ways).  A quick
ogrinfo shows:

INFO: Open of `/users/russo/TIGER/BC_TGR'
  using driver `TIGER' successful.

Layer name: CompleteChain
Geometry: Line String
Feature Count: 58942
Extent: (-107.196170, 34.869024) - (-106.149575, 35.219639)
Layer SRS WKT: [...]
MODULE: String (8.0)
TLID: Integer (10.0) - This is a Line ID to link to other tables
[... tons more attributes for linear features...]

Layer name: AltName --- table of alternate feature names in addition
 to the one in CompleteChain 
Geometry: None
Feature Count: 6026
Layer SRS WKT:[...]
MODULE: String (8.0)
TLID: Integer (10.0)  --- this one could be used to relate the
   alternate names back to linear features
RTSQ: Integer (3.0)
FEAT: IntegerList (8.0)   --- and this one links to the next table,
   which actually has the names

Layer name: FeatureIds
Geometry: None
Feature Count: 10235
Layer SRS WKT: [...]
MODULE: String (8.0)
FILE: Integer (5.0)
FEAT: Integer (8.0)   --- linking column for AltName table
FEDIRP: String (2.0)
FENAME: String (30.0)
FETYPE: String (4.0)
FEDIRS: String (2.0)

Layer name: ZipCodes
Geometry: None
Feature Count: 1827
Layer SRS WKT:[...]
MODULE: String (8.0)
TLID: Integer (10.0)   links back to CompleteChain
RTSQ: Integer (3.0)
[...]

Layer name: Landmarks
Geometry: Point
Feature Count: 448
Extent: (-107.119811, 34.889113) - (-106.232580, 35.205106)
Layer SRS WKT:
GEOGCS[NAD83,
DATUM[North_American_Datum_1983,
SPHEROID[GRS 1980,6378137,298.257222101]],
PRIMEM[Greenwich,0],
UNIT[degree,0.0174532925199433]]
MODULE: String (8.0)
FILE: Integer (5.0)
LAND: Integer (10.0) -- linking column to AreaLandmarks
SOURCE: String (1.0)
CFCC: String (3.0)
LANAME: String (30.0)
LALONG: Integer (10.0)
LALAT: Integer (9.0)
FILLER: String (1.0)

Layer name: AreaLandmarks
Geometry: None
Feature Count: 1292
Layer SRS WKT:
GEOGCS[NAD83,
DATUM[North_American_Datum_1983,
SPHEROID[GRS 1980,6378137,298.257222101]],
PRIMEM[Greenwich,0],
UNIT[degree,0.0174532925199433]]
MODULE: String (8.0)
FILE: String (5.0)
STATE: Integer (2.0)
COUNTY: Integer (3.0)
CENID: String (5.0)
POLYID: Integer (10.0)  - Linking column to 

Re: [GRASS-user] Help: Completely confused about multi-layered vectors trying to import TIGER/Line files

2008-02-28 Thread Tom Russo
On Thu, Feb 28, 2008 at 06:54:09PM +0100, we recorded a bogon-computron 
collision of the [EMAIL PROTECTED] flavor, containing:
 On 28/02/08 16:39, Tom Russo wrote:
 I have been trying to wrap my brain around multi-layered GRASS vectors and
 have only succeeded in wrapping my brain into knots.  Perhaps someone here 
 with a solid understanding of this stuff can help me.
 
 
 [...]
 
 
 Since I'm rambling now, I'll just cut to the chase and ask my question:
 
  Given a GRASS vector with two attached database tables, one of which (layer
  2, attaching attributes to centrois) has a key field POLYID, how can I 
 create  a new layer using a third, much smaller table, that also has a 
 POLYID field,  such that the new layer only contains that subset of 
 centroids where the  third layer table's POLYID matches layer 2's POLYID 
 for that centroid?
 
 
 
 I think at this stage your best bet is probably to do something like this:
 
 v.category OldMap option=add layer=3 out=NewMap
 
 #find a link between the category numbers created and the original
 # categories, this should work:
 
 v.build OldMap option=cdump  TempFile
 
 # You will have to edit TempFile to only take into account layer 2 and
 # then find a way to import the results into your database

With the potential for tens of thousands of records, anything
involving manually editing a dump of categories seems an unworkable solution.

 v.db.connect -o NewMap layer=3 table=NewTable
 
 #to remove all centroids you do not want:
 v.edit tool=delete
 or
 v.extract
 
 There might be an easier way, though...

I sure hope so.

 I think that you also might want to file a few wishes in the tracker, such 
 as:
 
 - extend v.category with an option to use a column linked to an existing 
 layer as the cat for a new layer
 - allow v.extract to write the results to another layer of the same file 
 instead of a different file
 - extend v.patch to allow to patch different maps into different layers of 
 the output map
 - create a v.copy.layers to copy elements of one layer to another

Once I actually understand the steps of what I really need to do, then
perhaps I could intelligently formulate a real wish for the tracker.
At this point I'm simply adrift in a sea of v. and db. commands and
SQL queries with no compass.

-- 
Tom RussoKM5VY   SAR502   DM64ux  http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 http://kevan.org/brain.cgi?DDTNM
And, isn't sanity really just a one-trick pony anyway? I mean all you get is
 one trick, rational thinking, but when you're good and crazy, oooh, oooh,
 oooh, the sky is the limit!  --- The Tick
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Using v.edit to snap dangling lines

2008-02-28 Thread David Mahoney

Works like a charm. Thanks!

David

On 27-Feb-08, at 2:01 PM, Martin Landa wrote:


Hi,

2008/2/27, David Mahoney [EMAIL PROTECTED]:

I rewrote today query=dangle part of v.edit to use the algorithm of
v.clean tool=rmdangle|chdangle (lib/vector/Vlib/dangles.c). I am not
sure if it can solve your problem. I also added possibility to define
different threshold values for coordinates selection, snapping and
querying.


I've been trying to use v.edit to snap dangling lines after patching
 together a bunch of maps. However, the query=dangle option does not
 seem to work. I've tried:
 v.edit map=roads tool=select query=dangle thresh=0
 v.edit map=roads tool=select query=dangle thresh=-0
 v.edit map=roads tool=select query=dangle thresh=1
 v.edit map=roads tool=select query=dangle thresh=-1


(from Spearfish, selecting dangles shorter then 100 map units)

v.edit map=roads tool=select query=dangle thresh=-1,0,-100 --v
35 of 825 features selected from vector map [EMAIL PROTECTED]

to snap selected features in threshold 5 map units

$ v.edit map=roads tool=snap query=dangle thresh=-1,5,-100 --v
Threshold value for querying is -100.00
35 of 825 features selected from vector map [EMAIL PROTECTED]
Threshold value for snapping is 5.00
--
All vertices  :   86
Registered points :   83
Nodes marked as anchor:   80
Nodes marked to be snapped:3
Snapped vertices  :3
New vertices  :0
--

[snip]


 I'm using GRASS 6.3 cvs (about a month old) on Mac OS X


Hope it helps.

Martin

-- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/ 
~landa *


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Re: Just a successful report ; -) --- Compiling GRASS source code under Ubuntu 7.10 64-bit with...

2008-02-28 Thread Markus Neteler
On Wed, Feb 27, 2008 at 11:46 PM, Tim Michelsen
[EMAIL PROTECTED] wrote:
 Hello!

  I would like to put that on the wiki if there no objections.
  I would like to have your nice HowTo in the wiki.

  We could think to develop a script that does the GRASS compilation and
  install each time there's a new version out.

This is on the (long) TODO list. The idea (one idea) is to use the buildbot
from OSGeo for this purpose (http://wiki.osgeo.org/wiki/BuildBot_Configuration).
I guess we need a volunteer or two for this...

Markus
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] How to find out an angle between to points on the map (for r.plane, r.lake)

2008-02-28 Thread Markus Neteler
On Thu, Feb 28, 2008 at 5:55 PM, Philipp Steigenberger
[EMAIL PROTECTED] wrote:
  Could you recommend other tools to simulate  flooding events in GRASS?

Last week, at the IX Meeting degli Utenti Italiani di GRASS - GFOSS in Perugia,
a new approach was presented:
http://www.grassmeeting2008.unipg.it/?q=node/70

(in funny English:
 
http://translate.google.com/translate?sourceid=mozclientu=http%3A//www.grassmeeting2008.unipg.it/%3Fq%3Dnode/70
). You could contact Bianca Federici for details.

Markus
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] How to find out an angle between to points on the map (for r.plane, r.lake)

2008-02-28 Thread Dylan Beaudette
On Thursday 28 February 2008, Philipp Steigenberger wrote:
 Hi
 I want to work with r.plane and r.lake to get simulate floodings in DTMs.

 In the section of interest there is a river which runs from about SSW to
 NNE. For r.plane I need the
 azimuth. Is there a tool in GRASS which tells me the angle between two
 points I mark on the map like I can measure in between two points with
 d.measure?



Simple trigonometry is a start. Or on a computer the atan2() function is 
useful:

atan2( (end_y - start_y) , (end_x - start_x) ) * 180/pi

will return the angle in degrees. The above example is from R, but the C 
implementation should be similar. Check your local documentation.

It shouldn't be hard to add something like this to d.measure for interactive 
estimation of bearings.

On a related note, I wrote a module for GRASS sometime ago called d.bearing 
which would create a transect from a starting point, a bearing, and a 
distance along the resulting line. I will dig the source out and see if it 
still compiles. It might be useful to combine that functionality with what 
you are talking about.


Dylan

-- 
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] How to find out an angle between to points on the map (for r.plane, r.lake)

2008-02-28 Thread Dylan Beaudette
On Thursday 28 February 2008, Philipp Steigenberger wrote:
 Hi
 I want to work with r.plane and r.lake to get simulate floodings in DTMs.

 In the section of interest there is a river which runs from about SSW to
 NNE. For r.plane I need the
 azimuth. Is there a tool in GRASS which tells me the angle between two
 points I mark on the map like I can measure in between two points with
 d.measure?


Well of course I had to go and try this out.

attached is a patch (against todays SVN) to optionally print the bearing 
between clicks.

Dylan


-- 
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
Index: display/d.measure/local_proto.h
===
--- display/d.measure/local_proto.h	(revision 30395)
+++ display/d.measure/local_proto.h	(working copy)
@@ -1,7 +1,8 @@
 /* draw_line.c */
 int draw_line(int, int, int, int, int, int);
 /* msurements.c */
-int measurements(int, int, int, int, int);
+int measurements(int, int, int, int, int, int);
 int print_en(double, double, int);
 int print_length(double, int, int);
+int print_bearing_deg (double, double, double, double, int);
 int add_point(double **, double **, int *, int *, double, double);
Index: display/d.measure/msurements.c
===
--- display/d.measure/msurements.c	(revision 30395)
+++ display/d.measure/msurements.c	(working copy)
@@ -2,11 +2,14 @@
 #include grass/display.h
 #include grass/raster.h
 #include local_proto.h
+#include math.h
+#include unistd.h
 
+#define PI  M_PI
 
 FILE *output;
 
-int measurements(int color1,int color2, int s_flag, int m_flag, int k_flag)
+int measurements(int color1,int color2, int s_flag, int m_flag, int k_flag, int b_flag)
 {
 double *x, *y;
 int npoints, nalloc;
@@ -89,7 +92,14 @@
 draw_line(screen_x,screen_y,cur_screen_x,cur_screen_y,color1,color2)  ;
 		add_point (x, y, npoints, nalloc, ux, uy);
 length += G_distance(cur_ux, cur_uy, ux, uy) ;
+
+if(b_flag)
+	print_bearing_deg(cur_ux, ux, cur_uy, uy, s_flag);
+	
 print_length(length, s_flag, k_flag);
+
+
+
 cur_screen_x = screen_x ;
 cur_screen_y = screen_y ;
 cur_ux = ux ;
@@ -163,6 +173,19 @@
 return 0;
 }
 
+int print_bearing_deg (double cur_ux, double ux, double cur_uy, double uy, int s_flag)
+{
+/* Use stderr for TCLTK-Output */
+if( s_flag )
+  output = stderr;
+else
+  output = stdout;
+	
+fprintf (output,Bearing:   %3.2f degrees\n, atan2(uy - cur_uy, ux - cur_ux) * 180/PI) ;
+
+return 0;
+}
+
 int add_point (double **x, double **y,
 int *npoints, int *nalloc, double ux, double uy)
 {
Index: display/d.measure/main.c
===
--- display/d.measure/main.c	(revision 30395)
+++ display/d.measure/main.c	(working copy)
@@ -20,6 +20,7 @@
  *
  */
 #include stdlib.h
+
 #include grass/gis.h
 #include grass/display.h
 #include grass/raster.h
@@ -38,8 +39,9 @@
 	   struct Flag *s;
 	   struct Flag *m;
 	   struct Flag *k;
+	   struct Flag *b;
 	} parm;
-	int color1, color2, s_flag, m_flag, k_flag;
+	int color1, color2, s_flag, m_flag, k_flag, b_flag;
 
 	/* Initialize the GIS calls */
 	G_gisinit(argv[0]) ;
@@ -79,6 +81,10 @@
 	parm.k-key = 'k';
 	parm.k-description = _(Output in kilometers as well);
 	
+	parm.b = G_define_flag();
+	parm.b-key = 'b';
+	parm.b-description = _(Print bearing between points);
+	
 	if (argc  1  G_parser(argc,argv))
 	exit(EXIT_FAILURE);
 
@@ -96,8 +102,9 @@
 	s_flag = parm.s-answer;
 	m_flag = parm.m-answer;
 	k_flag = parm.k-answer;
+	b_flag = parm.b-answer;
 
-	measurements(color1, color2, s_flag, m_flag, k_flag ) ;
+	measurements(color1, color2, s_flag, m_flag, k_flag, b_flag ) ;
 
 	R_close_driver();
 
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] How to find out an angle between to points on the map (for r.plane, r.lake)

2008-02-28 Thread Dylan Beaudette
On Thursday 28 February 2008, Dylan Beaudette wrote:
 On Thursday 28 February 2008, Philipp Steigenberger wrote:
  Hi
  I want to work with r.plane and r.lake to get simulate floodings in DTMs.
 
  In the section of interest there is a river which runs from about SSW to
  NNE. For r.plane I need the
  azimuth. Is there a tool in GRASS which tells me the angle between two
  points I mark on the map like I can measure in between two points with
  d.measure?

 Well of course I had to go and try this out.

 attached is a patch (against todays SVN) to optionally print the bearing
 between clicks.

 Dylan

And of course here is an updated patch which computes bearing from 0 (math 
style North = 90 deg) or from 90 (compass style North = 0 deg).



-- 
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
Index: display/d.measure/local_proto.h
===
--- display/d.measure/local_proto.h	(revision 30395)
+++ display/d.measure/local_proto.h	(working copy)
@@ -1,7 +1,8 @@
 /* draw_line.c */
 int draw_line(int, int, int, int, int, int);
 /* msurements.c */
-int measurements(int, int, int, int, int);
+int measurements(int, int, int, int, int, int, int);
 int print_en(double, double, int);
 int print_length(double, int, int);
+int print_bearing_deg (double, double, double, double, int, int);
 int add_point(double **, double **, int *, int *, double, double);
Index: display/d.measure/msurements.c
===
--- display/d.measure/msurements.c	(revision 30395)
+++ display/d.measure/msurements.c	(working copy)
@@ -2,11 +2,14 @@
 #include grass/display.h
 #include grass/raster.h
 #include local_proto.h
+#include math.h
+#include unistd.h
 
+#define PI  M_PI
 
 FILE *output;
 
-int measurements(int color1,int color2, int s_flag, int m_flag, int k_flag)
+int measurements(int color1,int color2, int s_flag, int m_flag, int k_flag, int b_flag, int c_flag)
 {
 double *x, *y;
 int npoints, nalloc;
@@ -89,7 +92,14 @@
 draw_line(screen_x,screen_y,cur_screen_x,cur_screen_y,color1,color2)  ;
 		add_point (x, y, npoints, nalloc, ux, uy);
 length += G_distance(cur_ux, cur_uy, ux, uy) ;
+
+if(b_flag)
+	print_bearing_deg(cur_ux, ux, cur_uy, uy, s_flag, c_flag);
+	
 print_length(length, s_flag, k_flag);
+
+
+
 cur_screen_x = screen_x ;
 cur_screen_y = screen_y ;
 cur_ux = ux ;
@@ -163,6 +173,42 @@
 return 0;
 }
 
+/**
+\brief compute the bearing in degrees from click to next click. 
+
+\note North is at 90 degrees by default, it can be shifted to 0 degrees (like a compass) with the '-c' flag
+*/
+int print_bearing_deg (double cur_ux, double ux, double cur_uy, double uy, int s_flag, int c_flag)
+{	
+	double bearing_deg ;
+	double dx, dy;
+	
+/* Use stderr for TCLTK-Output */
+if( s_flag )
+  output = stderr;
+else
+  output = stdout;
+   	
+   	dx = ux - cur_ux ;
+   	dy = uy - cur_uy ;
+   	
+   	/* put north at 0 deg by subtracting PI/2 */
+   	if( c_flag)
+   		{
+		bearing_deg = (atan2(dy, dx) - PI/2) * 180/PI ;
+		if(bearing_deg  0)
+			bearing_deg = 360 + bearing_deg;
+		}
+	
+	/* north is at 90 deg */
+	else
+		bearing_deg = atan2(dy, dx) * 180/PI ;
+	
+fprintf (output,Bearing:   %3.2f degrees\n, bearing_deg) ;
+
+return 0;
+}
+
 int add_point (double **x, double **y,
 int *npoints, int *nalloc, double ux, double uy)
 {
Index: display/d.measure/main.c
===
--- display/d.measure/main.c	(revision 30395)
+++ display/d.measure/main.c	(working copy)
@@ -20,6 +20,7 @@
  *
  */
 #include stdlib.h
+
 #include grass/gis.h
 #include grass/display.h
 #include grass/raster.h
@@ -38,8 +39,10 @@
 	   struct Flag *s;
 	   struct Flag *m;
 	   struct Flag *k;
+	   struct Flag *b;
+	   struct Flag *c;
 	} parm;
-	int color1, color2, s_flag, m_flag, k_flag;
+	int color1, color2, s_flag, m_flag, k_flag, b_flag, c_flag;
 
 	/* Initialize the GIS calls */
 	G_gisinit(argv[0]) ;
@@ -79,6 +82,14 @@
 	parm.k-key = 'k';
 	parm.k-description = _(Output in kilometers as well);
 	
+	parm.b = G_define_flag();
+	parm.b-key = 'b';
+	parm.b-description = _(Compute bearing between points (north is 90 degrees));
+	
+	parm.c = G_define_flag();
+	parm.c-key = 'c';
+	parm.c-description = _(Use compass-style bearing (north is 0 degrees));
+	
 	if (argc  1  G_parser(argc,argv))
 	exit(EXIT_FAILURE);
 
@@ -96,8 +107,10 @@
 	s_flag = parm.s-answer;
 	m_flag = parm.m-answer;
 	k_flag = parm.k-answer;
+	b_flag = parm.b-answer;
+	c_flag = parm.c-answer;
 
-	measurements(color1, color2, s_flag, m_flag, k_flag ) ;
+	

Re: [GRASS-user] Re: [GRASS-dev] r.out.gdal Gtiff output does not preserve color tables

2008-02-28 Thread Hamish
Dylan Beaudette wrote:
 - r.out.gdal never worked for me (or rather the resulting file would
 not open in ArcMap)

did you try adding  INTERLEAVE=PIXEL  and *not* using LZW compression
for createopt=?


From the help r.out.gdal page:
{{{
NOTES

When writing out GeoTIFF format for users of ESRI software or
ImageMagick, the band interleaving should be switched to pixel
interleaving using createopt=INTERLEAVE=PIXEL. 

To specify multiple options use a comma separated list
(createopt=TFW=YES,COMPRESS=DEFLATE).
}}}



Hamish



  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Just a successful report ; -) --- Compiling GRASS source code under Ubuntu 7.10 64-bit with...

2008-02-28 Thread Nikos Alexandris
On Wed, 2008-02-27 at 19:11 +0100, Nikos Alexandris wrote:
 On Wed, 2008-02-27 at 18:47 +0100, Maciej Sieczka wrote:
  Nikos Alexandris pisze:
[...]
 
 Thanx for the tip. I can just add the rest then.

Attached is a txt file slightly modified (removed the FFTW section).

SuperSimple question:

I am not sure how to upload the file in the wiki although I have seen an
upload link. I ask before I do it... is it a global upload tool or
is it necessary to upload something from within a specific page of the
wiki?

# Compiling latest GRASS source code on a 64-bit machine (with an ATI graphic 
card) under Ubuntu 7.10 64-bit with support for:
# 64-bit, SQLite, OpenGL, PYTHON, FFMPEG
#
# Based on script for Ubuntu 7.06 by David 

# Assuming it is the first time installing SVN, PROJ, GDAL/OGR



*** PREPARATION ***

sudo apt-get update  sudo apt-get upgrade


# installing SVN

sudo apt-get install subversion


# installing dependencies for compiling (in general)
# and dependencies for GRASS: PROJ, GDAL/OGR

sudo apt-get install grass build-essential flex bison libncurses5-dev 
zlib1g-dev \
libjpeg62-dev libgdal1-dev libtiff4-dev ligcc++ bpng12-dev tcl8.4-dev 
tk8.4-dev fftw-dev \
libfreetype6-dev libavcodec-dev libxmu-dev gdal-bin libreadline5 
libreadline5-dev \
make


# installing SQLite

sudo apt-get install sqlite3 libsqlite3-dev


# download latest source code from GRASS SVN repository

svn checkout https://svn.osgeo.org/grass/grass/trunk grass_trunk
  
# in case of a subsequent update: use the command svn up (without quotes)



# before attempting to compile GRASS
# READ section (C) in the INSTALL file located in the main directory of GRASS 
source code
# entitled: (C) COMPILATION NOTES for 64bit platforms section



*** FFTW ***

# installing FFTW3 if not already on system

sudo apt-get install fftw3 fftw3-dev

# not sure if the -dev is realy necessary!



*** FFMPEG ***

# from: http://stream0.org/2008/01/install-ffmpeg-on-ubuntu-gutsy.html

# checkout svn source code

svn checkout svn://svn.mplayerhq.hu/ffmpeg/trunk ffmpeg


# install dependencies

sudo apt-get install liblame-dev libfaad2-dev libfaac-dev libxvidcore4-dev 
liba52-0.7.4 liba52-0.7.4-dev libx264-dev libdts-dev checkinstall 
build-essential subversion


# guide to ffmpeg directory

cd ffmpeg


# if necessary make distclean (without quotes)

./configure --enable-gpl --enable-pp --enable-libvorbis --enable-libtheora 
--enable-liba52 --enable-libdc1394 --enable-libgsm --enable-libmp3lame 
--enable-libfaad --enable-libfaac --enable-libxvid --enable-pthreads 
--enable-libx264 --enable-shared


# compilation

make


# installation on /usr/local/bin -- important to know when configuring GRASS' 
source code for compilation

sudo checkinstall


* go for GRASS!

cd /to/wherever/your/GRASS/source/code/is


# configuration

CFLAGS=-g -Wall LDFLAGS=-s ./configure --enable-64bit 
--with-libs=/usr/lib64 --with-cxx --with-freetype=yes 
--with-postgres=no --with-sqlite=yes --enable-largefile=yes 
--with-tcltk-includes=/usr/include/tcl8.4 
--with-freetype-includes=/usr/include/freetype2 
--with-opengl-libs=/usr/include/GL --with-readline --with-python=yes 
--with-ffmpeg=yes --with-ffmpeg-includes=/usr/local/include/ffmpeg


# if OpenGL fails then maybe it is necessary to link glxATI.h with glx.h and 
re-run configuration

# (1) cd /usr/include/GL
# (2) sudo ln glxATI.h glx.h
# (3) back to configuration


# compilation

make


# compilation is expected to end with a no errors statement:

# Started compilation: Wed Feb 27 00:24:36 CET 2008
# --
# Errors in:
# No errors detected.


# installation

sudo make install


# launch 64-bit GRASS.6.3.sv

grass63



*** NOTES ***

# in case of errors in future compilation attempts, remember to remove program 
binaries with

make clean

# and the files created with the configuration from previous compilations with

make distclean
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Re: Just a successful report ; -) --- Compiling GRASS source code under Ubuntu 7.10 64-bit with...

2008-02-28 Thread Nikos Alexandris
On Thu, 2008-02-28 at 23:15 +0100, Markus Neteler wrote:
 On Wed, Feb 27, 2008 at 11:46 PM, Tim Michelsen
 [EMAIL PROTECTED] wrote:
[...]
 
   We could think to develop a script that does the GRASS compilation and
   install each time there's a new version out.
 
 This is on the (long) TODO list. The idea (one idea) is to use the buildbot
 from OSGeo for this purpose 
 (http://wiki.osgeo.org/wiki/BuildBot_Configuration).
 I guess we need a volunteer or two for this...

 Markus

I could (try to) join this attempt although my knowledge is rather
limited.

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] How to find out an angle between to points on the map (for r.plane, r.lake)

2008-02-28 Thread Hamish
Dylan Beaudette wrote:
  Well of course I had to go and try this out.
 
  attached is a patch (against todays SVN) to optionally print the
  bearing between clicks.


Hi,

you should add a check so that it won't allow bogus results if the
location is in Lat/Lon:

e.g. from d.grid:
if (geogrid-answer  G_projection() == PROJECTION_LL)
  G_fatal_error(_(.. option is not available for LL projection));

(the great circle line's bearing changes with distance along it; unless
you are interested in the rhumbline?)


for this stuff also checkout m.cogo, r.transect, r.profile,
d.rhumbline, d.geodesic


Hamish



  

Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] About .mdb geo-data base file format... please some information about alternative file formats!

2008-02-28 Thread Nikos Alexandris

Some time ago I said that I will post a question in EEA about ...why only
shapefiles and mdb's. So I did.

It took some time but I received a reply. I posted back my feedback using
some CLC tiles and I was waiting (still waiting) for a second reply (this
second is of minor importance I think).

Reading again my questions I realise that they could have been formulated
better, from a more correct perspective. Anyhow, here they are (my
question and the reply). If anybody is interested about contact details just
give me a sign.

  Dear Madams/ Sirs,
  
  herewith I kindly request an answer to the following question:
  
  Why are the geospatial data (available in EEA's data portal) provided
  only in closed source geo-data file formats (e.g. ESRI shapefile, .mdb
  geo-data base)?
  
  Why not also in open-source file formats?
  
  As a student, trying to satisfy my experimental needs, I am not in
 the
  financial position to pay for proprietary softare.
  
  The alternatives (Free and Open Source) for processing and analysing
  geo-spatial data exist, and allow me to state, some of them
 demonstrate
  superior performance and experience a continuous development.
  
  Students and teachers and both the academic and the scientific
 community
  worldwide can benefit if EEA's geo-data are available publicly (with a
  subscription) in open source file formats.
  
  
  Thank you for your time in advance.
  
  Sincerely,
  
  Nikos Alexandris.

and the reply:

 Dear Nikos Alexandris,
 
 Thank you for contacting the European Environment Agency.
  
 Based on your e-mail, I have consulted a colleague working with
 geospatial data. He has responded that shape files can be seen as an
 open industry format and can be read by many open source software today.
 Also DBF files also both have limitations such as support on
 multilingualism (UTF8, UTF16). EEA also provide, where possible,
 everything in textual or XML formats. We also provide other industrial
 formats to insure we have no loss of quality or information. Soon we
 will be able to provide GML, WFS formats once those formats have been
 better understood by us. The amount of formats provided depends on the
 cost producing them.
 
 Please let me know if you have further questions that have not been
 answered by the explanation above.
 
 
 Kind regards,

...
-- 
View this message in context: 
http://www.nabble.com/About-.mdb-geo-data-base-file-format...-please-some-information-about-alternative-file-formats%21-tp14899928p15751329.html
Sent from the Grass - Users mailing list archive at Nabble.com.

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] Steps Required to run sample program in Grass

2008-02-28 Thread Kunal Malik
Hi !!

I want to know steps needed for the compilation  running the sample program
in grass.
I want to run one sample program say import of raster image..
please give the steps for executing this.it will help me to start
development on grass.



I have tried to add r.example in the raster dir then make the neccesary
changes in Make file..
then I run make,make install ..but it does not work..



-- 
Thanks  Regards

Kunal Malik
09871147561
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Re: [GRASS-dev] r.out.gdal Gtiff output does not preserve color tables

2008-02-28 Thread Dylan Beaudette
On Thursday 28 February 2008, Hamish wrote:
 Dylan Beaudette wrote:
  - r.out.gdal never worked for me (or rather the resulting file would
  not open in ArcMap)

 did you try adding  INTERLEAVE=PIXEL  and *not* using LZW compression
 for createopt=?


 From the help r.out.gdal page:
 {{{
 NOTES

 When writing out GeoTIFF format for users of ESRI software or
 ImageMagick, the band interleaving should be switched to pixel
 interleaving using createopt=INTERLEAVE=PIXEL.

 To specify multiple options use a comma separated list
 (createopt=TFW=YES,COMPRESS=DEFLATE).
 }}}



 Hamish


Yep-- I have tried both of those options. I either get a file which will not 
open (mysterious ESRI error), or the file's data range is reported as some 
huge negative number -- to some huge positive number, something like 
3x10^25 . I will check on the exact value and report back.

Dylan


-- 
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] v.in.ogr ERROR: invalid byte sequence for encoding UTF8: 0xae

2008-02-28 Thread mohannbr

Hi,
 
   I use postgresql driver for GRASS. I have GRASS 6.2.2 installed in my
comp. with 'host=localhost,dbname=grass60test'.
When i try to import .shp files using v.in.ogr , i get the error...
ERROR:  invalid byte sequence for encoding UTF8: 0xae
HINT:  This error can also happen if the byte sequence does not match the
encoding expected by the server, which is controlled by client_encoding.
How do i correct it??? 

-Mohan
-- 
View this message in context: 
http://www.nabble.com/v.in.ogr-ERROR%3A--invalid-byte-sequence-for-encoding-%22UTF8%22%3A-0xae-tp15751969p15751969.html
Sent from the Grass - Users mailing list archive at Nabble.com.

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] Re: [GRASS-dev] r.out.gdal Gtiff output does not preserve color tables

2008-02-28 Thread Michael Barton


On Feb 28, 2008, at 10:36 PM, [EMAIL PROTECTED] wrote:


Date: Thu, 28 Feb 2008 20:40:36 -0800
From: Dylan Beaudette [EMAIL PROTECTED]
Subject: Re: [GRASS-user] Re: [GRASS-dev] r.out.gdal Gtiff output does
not preserve color tables
To: Hamish [EMAIL PROTECTED]
Cc: grass-user@lists.osgeo.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain;  charset=iso-8859-1

On Thursday 28 February 2008, Hamish wrote:

Dylan Beaudette wrote:

- r.out.gdal never worked for me (or rather the resulting file would
not open in ArcMap)


did you try adding  INTERLEAVE=PIXEL  and *not* using LZW compression
for createopt=?


From the help r.out.gdal page:
{{{
NOTES

When writing out GeoTIFF format for users of ESRI software or
ImageMagick, the band interleaving should be switched to pixel
interleaving using createopt=INTERLEAVE=PIXEL.

To specify multiple options use a comma separated list
(createopt=TFW=YES,COMPRESS=DEFLATE).
}}}



Hamish



Yep-- I have tried both of those options. I either get a file which  
will not
open (mysterious ESRI error), or the file's data range is reported  
as some

huge negative number -- to some huge positive number, something like
3x10^25 . I will check on the exact value and report back.


We've also had this problem. We are using geotiffs as a standard  
raster format for archiving. So this is a real pain.


However, FWIW, we've also experienced the same problem that Dylan  
reports above in geotiffs produced by ArcGIS--a bunch of huge,  
meaningless numbers in the data.


So if we can fix this, we're one up on the commercial competition.

Michael
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] How to find out an angle between to points on the map (for r.plane, r.lake)

2008-02-28 Thread Michael Barton


On Feb 28, 2008, at 6:32 PM, [EMAIL PROTECTED] wrote:


Date: Thu, 28 Feb 2008 16:17:17 -0800
From: Dylan Beaudette [EMAIL PROTECTED]
Subject: Re: [GRASS-user] How to find out an angle between to points
on the  map (for r.plane, r.lake)
To: grass-user@lists.osgeo.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=iso-8859-15

On Thursday 28 February 2008, Philipp Steigenberger wrote:

Hi
I want to work with r.plane and r.lake to get simulate floodings  
in DTMs.


In the section of interest there is a river which runs from about  
SSW to

NNE. For r.plane I need the
azimuth. Is there a tool in GRASS which tells me the angle between  
two
points I mark on the map like I can measure in between two points  
with

d.measure?



Well of course I had to go and try this out.

attached is a patch (against todays SVN) to optionally print the  
bearing

between clicks.

Dylan


In the new wxPython GUI, the measure tool prints bearing as well as  
distance between click points.


Michael

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Re: [GRASS-dev] r.out.gdal Gtiff output does not preserve color tables

2008-02-28 Thread Hamish
Hamish:
  did you try adding  INTERLEAVE=PIXEL  and *not* using LZW
  compression for createopt=?
Dylan:
 Yep-- I have tried both of those options. I either get a file which
 will not open (mysterious ESRI error),

I decided (out of complete frustration) never to use Arc again before I
started much with GRASS, so I can't comment on that. For exporting
stuff for colleagues I usually go with r.out.arc and don't get many
complaints.

 or the file's data range is reported as some huge negative number
 -- to some huge positive number, something like 3x10^25 . I will
 check on the exact value and report back.

This will be the nodata value? Or wrong data type? (float read as int)


Hamish



  

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] Re: v.digit background colour

2008-02-28 Thread Craig Leat

Craig Leat wrote:

Hi

It appears that the v.digit option: settings - Symbology - 
Background is broken, because I am unable to change the background 
colour. A further annoyance is that the background colour changes from 
white to cyan whenever a background vector is added. If a raster is 
added the background stays white.


Am I missing something?

My system: GRASS trunk and Ubuntu Gutsy


http://trac.osgeo.org/grass/ticket/74

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user