Re: [GRASS-user] Does Grass Support Layers??
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
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
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
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
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
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
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??
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
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
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
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)
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)
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... ?
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... ?
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
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
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... ?
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
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
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
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
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...
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)
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)
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)
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)
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
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...
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...
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)
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!
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
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
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
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
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)
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
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
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