Re: [GRASS-user] Elevation profile from inter secting shapefiles
georgew wrote: Hamish, please forgive my ignorance but I am not sure what you mean. As far as I know g.region is the means to change the resolution, correct, whether through the command line or the GUI. Can you please explain how to access and change the computational region settings. I was talking about when using it from the GUI. from the command line the display (d.mon) resolution is the computation region. in the GUI there are two: the active display region(+resolution) and the computational one. What you see in the display window(s) is independent of what's in the $MAPSET/WIND file. That WIND(ow) file holds the region which will be used by any modules running. The reason for all this confusion is that you can have multiple GUI display windows open at the same time, each independently zoomed to a different area and set at a different resolution (for a visual display there's no point at being at a higher resolution than you can see). Multiple displays would need multiple WIND files but the processing module (eg v.to.rast) wouldn't know which was the appropriate one to use. Thus computational region refers to what is stored in the mapset's WIND file. (sorry gui programmers if I have made small mistakes in that) In gis.m, from the Map Display window if you click on the magnifying glass icon (with the map) you get a pulldown menu. the last item is set computational region extents to match display. also in the GIS manager menu there is Config-Region. In that is Display region settings* and Change region settings which brings up the g.region GUI as if you were running it at the command prompt. [*] perhaps badly worded, nothing to do with the Map Display- it prints the current computational region to the output window. A symptom of the computational region being way out of whack compared to your display region is that you see the result as a series of huge blocks (computational resolution is too coarse), or in the other direction the resolution is so fine that takes ages to load. YMMV hope it helps, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Elevation profile from i ntersecting shapefiles
On 04/12/08 09:47, Hamish wrote: georgew wrote: Hamish, please forgive my ignorance but I am not sure what you mean. As far as I know g.region is the means to change the resolution, correct, whether through the command line or the GUI. Can you please explain how to access and change the computational region settings. I was talking about when using it from the GUI. from the command line the display (d.mon) resolution is the computation region. in the GUI there are two: the active display region(+resolution) and the computational one. What you see in the display window(s) is independent of what's in the $MAPSET/WIND file. That WIND(ow) file holds the region which will be used by any modules running. The reason for all this confusion is that you can have multiple GUI display windows open at the same time, each independently zoomed to a different area and set at a different resolution (for a visual display there's no point at being at a higher resolution than you can see). Multiple displays would need multiple WIND files but the processing module (eg v.to.rast) wouldn't know which was the appropriate one to use. Thus computational region refers to what is stored in the mapset's WIND file. (sorry gui programmers if I have made small mistakes in that) In gis.m, from the Map Display window if you click on the magnifying glass icon (with the map) you get a pulldown menu. the last item is set computational region extents to match display. And, the reverse: Zoom display to computational region. Maybe your v.to.rast worked as it should, but you just don't see the correct region in the Map Display ? BTW: I set the Location in GRASS's opening welcome screen, using the Contour.shp file to provide the boundaries. and g.region -p projection: 0 (x,y) You are aware that this means that the Contour.shp did not contain any projection info and that GRASS thus consideres it as unprojected ? Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] vectors: how to find the gravitation centre of point data ?
Hi list, is there an easy way to derive the centre of a cloud of points ? I am aware that the set of vector points (cloud of points) could be used to stake out a polygon/boundary and use v.centroid etc etc to derive in turn its' centroid, but I am hoping for an easier solution .. ? This issue stems from working with v.to.db: currently it is not possible to upload xy coordinates for multiploygons into a database, i.e: Within a vector layer, there might be several boundaries which all share the same category value. If the gravitational centre/ super-centroid for these boundaries could be (conveniently) calculated, the v.to.db issue could be taken care of. Peter -- Dr. Peter Löwe [EMAIL PROTECTED] Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: Re: [GRASS-user] Elevation profile from inter secting shapefiles
Hamish wrote: A symptom of the computational region being way out of whack compared to your display region is that you see the result as a series of huge blocks (computational resolution is too coarse), or in the other direction the resolution is so fine that takes ages to load. YMMV Note that a mismatch between computational and display regions isn't necessarily wrong. You may want to perform computations at a resolution finer than that of the display for accuracy, or coarser than it for speed. -- Glynn Clements [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Raster file from ascii file and flattening Africa .... :)
Dear Moritz,
thanks for pointing out r.in.xyz I will get a look at it, to see if it is
what I was looking for.
Concerning projection, of course I was not looking into flattening Africa with
a digger but in flattening Africa's projection (I though it was clear
from the context).
My data are in WGS84 / lat-long, but I need to use an area preserving
projection. I need to set the resolution to some sort of 100 km x 100 km
squares, or equivalent area.
My data are 1 x measurement on several specimen of the same species in
different sites, and I need to do some geographical analysis at that type of
resolution in an area preserving projection / datum.
I am asking the gurus what is the best area preserving projection / datum I
could use for Africa and the hows.
Thanks again.
On Wednesday 03 December 2008 17:05:15 Moritz Lennert wrote:
On 03/12/08 10:26, Corrado wrote:
Dear friends,
I am a kind of advanced newbie, if that makes sense.
I have a text file of the form
coordinate x,coordinate y,cat={real number between 250 and 450}
where coordinate are expressed in latitude and longitude. The files
represents measurements of the size of a skulls on sites all over Africa.
From it, I would like to build a raster file, 100 km by 100km. There are
2 problems:
1) Unfortunately, in some 100km x 100km squares, there is one of the
points whilst in others there are maybe 20. How do I average, so that in
each square I only have 1 value representing the average?
r.in.xyz does this for you directly during the import.
Or you have r.resampl.stats, r.statistics, r.average, r.mode, r.median.
2) How do we flatten Africa so that we may use 100km x 100km squares
instead of 1 degree x 1 degree, without committing a geographical crime?
What we need is to respect the areas
I don't know what you mean by flatten. IIUC, you are simply speaking
about using a projection system. You have to create a location in the
projection of your choice (I'll leave it to others to advise you on the
best choice for the whole of Africa, but according to your criteria, you
would need an equal area - see [1,2] for an introduction). Then use
r.proj to reproject your map from the lat-long location to the projected
location where you can then resample.
Moritz
[1] http://en.wikipedia.org/wiki/Map_projection#Equal-area
[2] http://egsc.usgs.gov/isb/pubs/MapProjections/projections.html
--
Corrado Topi
Global Climate Change Biodiversity Indicators
Area 18,Department of Biology
University of York, York, YO10 5YW, UK
Phone: + 44 (0) 1904 328645, E-mail: [EMAIL PROTECTED]
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] flip raster
Barry Eakins wrote: We've looked into this issue and the problem lies in how GMT v.4.3, which was used to create ETOPO1, and GDAL read and write netcdf grids. Both purport to handle netcdf COORDS-compliant grids though there is clearly a problem with one of these applications (the vertical flipping); the GDAL community forum has apparently already discussed this issue. We're working on a temporary solution, such as publishing an older GMT 3.0 netcdf grid along with the current one that GDAL doesn't read properly. GDAL does read the older netcdf grid without problem. um, about that read without problem .. FYI I had found an odd error with the Smith Sandwell 1' dataset (v10.1) in the older GMT format. As far as I could determine the old GMT grd format introduced a floating point +0.005 elevation shift error in th data. Minor, but uninvited so worth investigating. (this is using GMT tools for Debian Etch; not sure if it's a GMT processing bug or something deeper?) see http://grass.osgeo.org/wiki/Marine_Science#Bathymetric_data my other problem with that dataset (and the focus of the above link) is the rather vague map projection definition given, and struggles with understanding the projection used with GMT's img2grd program. (I haven't checked the new SS 1' v11.1 dataset; there's no readme or log) Earlier today on the PROJ.4 mailing list I got a chuckle to read the phrase geodetic abomination be used in reference to using the mercator projection on a sphere and then trying to tie it back to WGS84. that's not your problem, just something to be aware of. I hope to have something up on our web site by next week. One question that I have: Is there another file format for the ETOPO1 grids that would be of more use to the GRASS community than netcdf? As Glynn noted, GRASS relies primarily on GDAL for importing raster data, but we also have a r.in.bin module which reads raw binary blocks. This is what we've used in the past to import ETOPO2 and ETOPO5 without any problem at all. see http://grass.osgeo.org/wiki/Global_datasets#ETOPO1 We could host something such as geotiffs of the grids, which we can create easily, but I'm not a GRASS user so don't know what grid/raster file format would be easiest to import into GRASS. r.in.gdal and r.in.bin cover most file formats rather well, so there's not one single format to recommend. just a few lossy ones to avoid. I've also never used QGIS. It also heavily relies on GDAL for data import/export, but with less flexible options. GeoTiff is probably a safe bet for them. One thing it is rather good at is quickly loading/previewing large Geotiffs which bring your standard image viewer or paint program to its knees, without the overhead and effort of a big GIS suite. P.S. Sorry about the grid- v. cell-registered grids being a pain, there really is an important difference between the two. The cell registered version of ETOPO1 is trivial to import into GRASS, but what motivated me to attempt to shoehorn in the grid-registed version as chronicled in the above Global_datasets#ETOPO1 wiki page was - The grid-registered is the authoritative registration for each version. The cell-registered was derived from the grid-registered version and the conversion produces slightly flattened relief. comment on the NGDC site. I take that to mean it takes an average of the 4 grid points at each of the cell's corners? The specific problem with working with global grid registered data in GRASS is that lat/lon projects can not have bounds which exceed 90.0 deg N,S. Here's another method to flip the data once it's in GRASS: after loading the flipped raster in GDAL/GRASS export it from GRASS to Matlab (or Octave if you prefer) with the r.out.mat module, run flipud(map_data) in Matlab, resave, and import back into GRASS with r.in.mat. (quicker than writing some C code to do the same) thanks for the effort, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Elevation profile from intersecting shapefiles
georgew wrote: Thanks Micha, here we go: Micha Silver wrote: How many shapefiles did you have in the GRASSDATA directory? provide the boundaries. Here is the result: r.info contours_rast ++ | Layer: contours_rast Date: Thu Dec 4 08:50:19 2008 | | Mapset: test02 Login of Creator: george | | Location: test02 | | DataBase: /home/george/GRASSDATA | | Title: Labels ( contours_rast ) | | Timestamp: none | || | | | Type of Map: raster Number of Categories: 0 | | Data Type: DCELL | | Rows: 20 | | Columns: 20 | | Total Cells: 400 | | Projection: x,y | | N: 6020724.5 S: 6013982.586 Res: 337.0957 | | E: 2481099.136 W: 2467034.878 Res: 703.2129 | | Range of data: min = 520.00 max = 1840.00 | | | | Data Source: | | Vector Map: [EMAIL PROTECTED] in mapset test02 | | Original scale from vector map: 1:1 | | | | Data Description: | | generated by v.to.rast | | | | Comments: | | v.to.rast input=[EMAIL PROTECTED] output=contours_rast use=attr \ | | type=line layer=1 column=ELEVATION value=1 rows=10 | | | ++ GRASS 6.3.0 (test02):~ g.region -p projection: 0 (x,y) zone: 0 north: 6020724.5 south: 6013982.586 west: 2467034.878 east: 2481099.136 nsres: 337.0957 ewres: 703.2129 rows: 20 cols: 20 cells: 400 I hope all this helps. Your help so far has been invaluable, thanks a lot. PS I tried to play around with resolution in the Region dialog but the display never changed from the same chunky coloured squares. Here's What I can make out from the above: The X-Y values are about 6,000,000 N and about 2,450,000 E, and the size of your region is about 14,000 X 6500. Let's *assume* these numbers are in meters (UTM projection??). But your resolution is set to 337 e-w and 703 n-s, thus giving you a raster of 20X20 cells. That's certainly too coarse. I'd suggest: Blow away the rasters you made so far. Set resolution to 10m. X 10m. with g.region -s -p res=10 You should then see about 1400 columns by 650 rows =~ 91 cells. Now recreate those rasters. You should get better looking results. -- Micha ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] vectors: how to find the gravitation centre of point data ?
On 04/12/08 11:02, [EMAIL PROTECTED] wrote: Hi list, is there an easy way to derive the centre of a cloud of points ? I am aware that the set of vector points (cloud of points) could be used to stake out a polygon/boundary and use v.centroid etc etc to derive in turn its' centroid, but I am hoping for an easier solution .. ? This issue stems from working with v.to.db: currently it is not possible to upload xy coordinates for multiploygons into a database, i.e: Within a vector layer, there might be several boundaries which all share the same category value. If the gravitational centre/ super-centroid for these boundaries could be (conveniently) calculated, the v.to.db issue could be taken care of. Why not use v.dissolve on these polygons and then get the centroids of the result ? Another (very wild) guess: what about the mean of the coordinates of the individual polygons' centroids ? Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] shell script problem
Dear all, Apologies for the total beginner's question, but despite my efforts and searches through the GRASS mailing list archives I have not been able to solve my problem. I am trying to write a simple grass script in order to automated a process, but I have not very far yet. One thing that I would like to do is to be able to change the region, but GRASS seems to come up with the whenever I , for example, try to use the following simple lines: #!/bin/sh g.region rast=map1 r.stats -ln map1 file1 The message I get is: command not found. What am I doing wrong? Is this problem related to the setting of environment variables? I am using GRASS 6.3.0 installed on Ubuntu 8.10 thanks in advance, Mario Giacomello ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] shell script problem
Thanks for your prompt response. I have got as far as understanding that I should run scripts inside GRASS.So, the answer is yes- I have run the script inside GRASS. Marco On Thu, Dec 4, 2008 at 5:54 PM, ivan marchesini [EMAIL PROTECTED] wrote: hmmm are you starting the script inside grass? probably not... or I'm wrong? Ivan Il giorno gio, 04/12/2008 alle 17.06 +, Mario Giacomello ha scritto: Dear all, Apologies for the total beginner's question, but despite my efforts and searches through the GRASS mailing list archives I have not been able to solve my problem. I am trying to write a simple grass script in order to automated a process, but I have not very far yet. One thing that I would like to do is to be able to change the region, but GRASS seems to come up with the whenever I , for example, try to use the following simple lines: #!/bin/sh g.region rast=map1 r.stats -ln map1 file1 The message I get is: command not found. What am I doing wrong? Is this problem related to the setting of environment variables? I am using GRASS 6.3.0 installed on Ubuntu 8.10 thanks in advance, Mario Giacomello ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Ti prego di cercare di non inviarmi files .dwg, .doc, .xls, .ppt. Preferisco formati liberi. Please try to avoid to send me .dwg, .doc, .xls, .ppt files. I prefer free formats. http://it.wikipedia.org/wiki/Formato_aperto http://en.wikipedia.org/wiki/Open_format Ivan Marchesini Department of Civil and Environmental Engineering University of Perugia Via G. Duranti 93/a 06125 Perugia (Italy) Socio fondatore GFOSS Geospatial Free and Open Source Software http://www.gfoss.it e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] tel: +39(0)755853760 fax (university): +39(0)755853756 fax (home): +39(0)5782830887 jabber: [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] shell script problem
Hi Mario, On Thu, 4 Dec 2008 17:46:36 + Mario Giacomello [EMAIL PROTECTED] wrote: Thanks for your prompt response. I have got as far as understanding that I should run scripts inside GRASS.So, the answer is yes- I have run the script inside GRASS. try to start the script with: sh grassscript.sh or ./grassscript.sh (if you made it executable) regards, Otto Marco On Thu, Dec 4, 2008 at 5:54 PM, ivan marchesini [EMAIL PROTECTED] wrote: hmmm are you starting the script inside grass? probably not... or I'm wrong? Ivan Il giorno gio, 04/12/2008 alle 17.06 +, Mario Giacomello ha scritto: Dear all, Apologies for the total beginner's question, but despite my efforts and searches through the GRASS mailing list archives I have not been able to solve my problem. I am trying to write a simple grass script in order to automated a process, but I have not very far yet. One thing that I would like to do is to be able to change the region, but GRASS seems to come up with the whenever I , for example, try to use the following simple lines: #!/bin/sh g.region rast=map1 r.stats -ln map1 file1 The message I get is: command not found. What am I doing wrong? Is this problem related to the setting of environment variables? I am using GRASS 6.3.0 installed on Ubuntu 8.10 thanks in advance, Mario Giacomello ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] shell script problem
hmmm are you starting the script inside grass? probably not... or I'm wrong? Ivan Il giorno gio, 04/12/2008 alle 17.06 +, Mario Giacomello ha scritto: Dear all, Apologies for the total beginner's question, but despite my efforts and searches through the GRASS mailing list archives I have not been able to solve my problem. I am trying to write a simple grass script in order to automated a process, but I have not very far yet. One thing that I would like to do is to be able to change the region, but GRASS seems to come up with the whenever I , for example, try to use the following simple lines: #!/bin/sh g.region rast=map1 r.stats -ln map1 file1 The message I get is: command not found. What am I doing wrong? Is this problem related to the setting of environment variables? I am using GRASS 6.3.0 installed on Ubuntu 8.10 thanks in advance, Mario Giacomello ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Ti prego di cercare di non inviarmi files .dwg, .doc, .xls, .ppt. Preferisco formati liberi. Please try to avoid to send me .dwg, .doc, .xls, .ppt files. I prefer free formats. http://it.wikipedia.org/wiki/Formato_aperto http://en.wikipedia.org/wiki/Open_format Ivan Marchesini Department of Civil and Environmental Engineering University of Perugia Via G. Duranti 93/a 06125 Perugia (Italy) Socio fondatore GFOSS Geospatial Free and Open Source Software http://www.gfoss.it e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] tel: +39(0)755853760 fax (university): +39(0)755853756 fax (home): +39(0)5782830887 jabber: [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Mapping Africa in an equal area projection
Dear friends, I would like to use it to map distribution of some specimen at a resolution of 100 km x 100 km (or even down to 25 km x 25 km). I gathered some information, and ended up with: 1) Sinusoidal 2) Equatorial Lambert Azimuthal Equal Area 3) Albers Equal Area (Conic) 4) Mollweide 5) Cylindrical Equal Area I do not really know which one to choose. What do you recommend? For each of them, which ellipsoid and datum would you choose? Regards -- Corrado Topi Global Climate Change Biodiversity Indicators Area 18,Department of Biology University of York, York, YO10 5YW, UK Phone: + 44 (0) 1904 328645, E-mail: [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] convert 3D polyline ZM to points
Dear all, Apologies for the beginners question. How can I convert 3D polyline ZM to points? And in next operation add to the atribute table column with elevation??? Thanks in advance. All the best Bohdan Horvath -- View this message in context: http://www.nabble.com/convert-3D-polyline-ZM-to-points-tp20838537p20838537.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] r.neighbors, wide filtering
Hi, For my research, I am testing a mesh denoising algorithm on topographic data. It smooths the surfaces much like using r.neighbors method=average or r.neighbors method=median, and, depending on settings, gives similar results to r.neighbors when size 5. The advantage of the algorithm is that it has some ability to preserve features. In cases where more significant smoothing is necessary (r.neighbors size 5) it is much better at preserving minimum and maximum elevations etc as it converges on a stable solution for the smoothed landscape. My question relates to understanding in which cases is it necessarily to smooth to such an extent? From what I have seen e.g. taking speckle out of SRTM DEMs, smoothing by such extremes removes a lot of useful information and results in unrealistic surfaces. Has anyone come across a situation/dataset or type of analysis where they need to smooth with r.neighbors (method=average/median, size 5)? I would be interested to know, and to see if this algorithm would be useful. Cheers John -- Dr John Stevenson Postdoctoral Research Associate School of Earth, Atmospheric and Environmental Sciences Williamson Building (Room 2.42) University of Manchester Manchester M13 9PL, UK tel. +44(0)161 306 6585; fax. +44(0)161 306 9361; [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Elevation profi le from intersecting shapefiles
Much progress! Micha Silver wrote: Set resolution to 10m. X 10m. with g.region -s -p res=10 Hamish_b wrote: Multiple displays would need multiple WIND files but the processing module (eg v.to.rast) wouldn't know which was the appropriate one to use. Thus computational region refers to what is stored in the mapset's WIND file. Moritz Lennert-2 wrote: You are aware that this means that the Contour.shp did not contain any projection info and that GRASS thus consideres it as unprojected ? Setting the resolution BEFORE converting to raster was the answer, thank you. I now see the contours in the raster map as well as in the original vector file. As for the null projection, thanks for pointing it out (I was not aware!) but since the purpose of the exercise was to create an elevation profile from tabular data perhaps it is not critical. So I went ahead with the original purpose, i.e. to create an elevation profile for the track. Micha Silver wrote: r.surf.contour to create an elevation surface from the rasterized contours r.profile to get the elevations along the tracks. So I entered: r.surf.contour [EMAIL PROTECTED] output=elevmap_raster --overwrite and few seconds later it completed its job without errors. Then went ahead with: r.profile -i [EMAIL PROTECTED] output=- null=* I followed the track with the left mouse button and a two column list of values was printed on stdout, the distance and the elevation. Success! My only remaining question is: Is there a way to use the track raster file to input the values instead of using the mouse, so that the process can be more or less automated? Thank you all for your great help. I'll write a summary and post it in the Wiki as an FAQ or short tutorial as suggested by Markus Neteler. grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- View this message in context: http://www.nabble.com/Elevation-profile-from-intersecting-shapefiles%E2%80%8F-tp20744104p20844940.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
