Re: [GRASS-user] r.contour contour wrap
just FYI. I am (was?) using 7.6 and had errors with r.contour outputs (linux mint). Output lines would be broken in areas there was good DEM data. The lines had large gaps between some isolines where other software could make clean contour from the DEM. I downloaded and compiled 7.7 and works great. On Thu, May 3, 2018 at 4:29 PM Markus Neteler wrote: > On Thu, May 3, 2018 at 10:17 PM, Markus Metz > wrote: > > On Tue, May 1, 2018 at 9:57 PM, Markus Metz < > markus.metz.gisw...@gmail.com> > > wrote: > ... > > Thanks for providing test data! There was indeed a bug in r.contour, > fixed > > in trunk r72668. Is it OK to backport the bugix to GRASS 7.4 and 7.2? > > ... in terms of backport policy definitely yes. > > markusN > ___ > grass-user mailing list > grass-user@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.watershed
Hi. I just used the tutorials from this page https://grasswiki.osgeo.org/ > wiki/Creating_watersheds to extract the stream network - however it could > be more accurate so was wondering is r.terraflow a better option for me. I > was using r.watershed originally > I've found r.watershed to be the most accurate, for our work. We've field verified the streams and its really solid data. I like that r.watershed doesnt alter the terrain since the LiDAR point data captures terrain nuances so well. Mark > Do you know why sink filling is needed for r.terraflow and not for > r.watershed? > > Thanks. > > On Wed, Dec 6, 2017 at 11:42 AM, Marco Alicera > wrote: > >> How did you add culverts?! >> Such a great question and I also wonder how you did. Short ago I knew >> about Itzï and its ability to do it with SWMM >> http://itzi.readthedocs.io/en/latest/tutorial.html#culvert-modelling. >> Looking forward to testing it >> -- >> Marco >> >> 2017-12-06 9:24 GMT+01:00 Shane Carey : >> >>> Hi Mark, >>> >>> Thanks for your reply! Sounds great. >>> How did you add culverts or other artificial flow control features to >>> achieve water flowing through roads? >>> >>> I have a rivers layer and I compared it the streams I've obtained from >>> r.watershed and r.watershed appears to not match these streams (which were >>> accurately digitised) and I was wondering if I had a better resolution DTM >>> would it solve this problem? >>> >>> Also, why is sink filling needed for terraflow and not watershed? >>> >>> Thanks for your help :-) >>> >>> On Máirt 5 Noll 2017 at 23:43, Mark Seibel wrote: >>> >>>> Hi Shane. >>>> >>>> I'm happy to report that I've modeled overland water flow with >>>> r.watershed for over a quarter million acres, consisting of several large >>>> project sites, at 1 meter DEM resolution. The data source was LiDAR >>>> points to make the DEMs. >>>> >>>> At this resolution, it becomes necessary to add culverts, or other >>>> artificial flow control features, to achieve water flowing through a road. >>>> Otherwise, water is routed along roads until a lowest point is reached for >>>> crossing. >>>> >>>> I also use r.terraflow outputs as ancillary data to help drop in >>>> culvert locations and help provide guidance in problem areas. >>>> >>>> My geographic area is central Florida, which is very flat and full of >>>> topographic depressions known as wetlands. These depressions interrupt the >>>> stream network continuity in reality, but r.watershed does a fantastic job >>>> making a continuous drainage network model, especially in these difficult >>>> areas. >>>> >>>> Happy Modeling! >>>> >>>> Mark >>>> >>>> On Tue, Dec 5, 2017, 3:49 PM Shane Carey wrote: >>>> >>>>> Hi, >>>>> >>>>> I am trying to extract river network from a 5m DEM with some success >>>>> using r.watershed. Has anyone tested this algorithm on high resolution >>>>> LiDAR data for example - 1meter DTM and what kind of results have they >>>>> obtained? >>>>> >>>>> Thanks >>>>> >>>>> -- >>>>> Le gach dea ghui, >>>>> *Shane Carey* >>>>> *GIS and Data Solutions Consultant* >>>>> >>>> ___ >>>>> grass-user mailing list >>>>> grass-user@lists.osgeo.org >>>>> https://lists.osgeo.org/mailman/listinfo/grass-user >>>> >>>> -- >>> Le gach dea ghui, >>> *Shane Carey* >>> *GIS and Data Solutions Consultant* >>> >>> ___ >>> grass-user mailing list >>> grass-user@lists.osgeo.org >>> https://lists.osgeo.org/mailman/listinfo/grass-user >>> >> >> > > > -- > Le gach dea ghui, > *Shane Carey* > *GIS and Data Solutions Consultant* > ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.watershed
Hi Shane. How did you add culverts or other artificial flow control features to achieve water flowing through roads? Culverts can be added by digitizing the connection points (line) across the road from high accumulation to high accumulation on the other side of the road. It can be a long iterative process, that can be encapsulated in a script. I've wondered if machine learning could be used to automate what seems to be such repetitive and easy culvert connections. > > Also, why is sink filling needed for terraflow and not watershed? > > I am not into the code, but I know r.watershed use different code to produce different model results. r.watersheed seeks the lowest points in the terrain, thus internal sinks get modeled with exit points rather than internally drained. On the other hand, r.terraflow hydrologically fills the terrain, then models flow accumulation. The results are similar, but the differences can be used to add another check on reality from another model; especially in really flat, depressional terrains. Mark > Thanks for your help :-) > > On Máirt 5 Noll 2017 at 23:43, Mark Seibel wrote: > >> Hi Shane. >> >> I'm happy to report that I've modeled overland water flow with >> r.watershed for over a quarter million acres, consisting of several large >> project sites, at 1 meter DEM resolution. The data source was LiDAR >> points to make the DEMs. >> >> At this resolution, it becomes necessary to add culverts, or other >> artificial flow control features, to achieve water flowing through a road. >> Otherwise, water is routed along roads until a lowest point is reached for >> crossing. >> >> I also use r.terraflow outputs as ancillary data to help drop in culvert >> locations and help provide guidance in problem areas. >> >> My geographic area is central Florida, which is very flat and full of >> topographic depressions known as wetlands. These depressions interrupt the >> stream network continuity in reality, but r.watershed does a fantastic job >> making a continuous drainage network model, especially in these difficult >> areas. >> >> Happy Modeling! >> >> Mark >> >> On Tue, Dec 5, 2017, 3:49 PM Shane Carey wrote: >> >>> Hi, >>> >>> I am trying to extract river network from a 5m DEM with some success >>> using r.watershed. Has anyone tested this algorithm on high resolution >>> LiDAR data for example - 1meter DTM and what kind of results have they >>> obtained? >>> >>> Thanks >>> >>> -- >>> Le gach dea ghui, >>> *Shane Carey* >>> *GIS and Data Solutions Consultant* >>> >> ___ >>> grass-user mailing list >>> grass-user@lists.osgeo.org >>> https://lists.osgeo.org/mailman/listinfo/grass-user >> >> -- > Le gach dea ghui, > *Shane Carey* > *GIS and Data Solutions Consultant* > ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.watershed
Hi Shane. I'm happy to report that I've modeled overland water flow with r.watershed for over a quarter million acres, consisting of several large project sites, at 1 meter DEM resolution. The data source was LiDAR points to make the DEMs. At this resolution, it becomes necessary to add culverts, or other artificial flow control features, to achieve water flowing through a road. Otherwise, water is routed along roads until a lowest point is reached for crossing. I also use r.terraflow outputs as ancillary data to help drop in culvert locations and help provide guidance in problem areas. My geographic area is central Florida, which is very flat and full of topographic depressions known as wetlands. These depressions interrupt the stream network continuity in reality, but r.watershed does a fantastic job making a continuous drainage network model, especially in these difficult areas. Happy Modeling! Mark On Tue, Dec 5, 2017, 3:49 PM Shane Carey wrote: > Hi, > > I am trying to extract river network from a 5m DEM with some success using > r.watershed. Has anyone tested this algorithm on high resolution LiDAR data > for example - 1meter DTM and what kind of results have they obtained? > > Thanks > > -- > Le gach dea ghui, > *Shane Carey* > *GIS and Data Solutions Consultant* > ___ > grass-user mailing list > grass-user@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Projection conflict with new project
> > Hi Rich. > > GRASS LOCATION PROJ_INFO is: > name: Dominica 1945 > ellps: clark80 > proj: ll > towgs84: 725,685,536,0,0,0,0 > no_defs: defined > > Import dataset PROJ_INFO is: > name: NAD_1983_HARN_StatePlane_Washington_South_FIPS_4602_Feet > datum: nad83harn > ellps: grs80 > proj: lcc > Location is set to lat/long while import data is projected Lambert conformal conic? Mark ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Change value of cells in raster map
Hi. I'm trying various v.db.* modules to change values in the two vector maps, > then I can recreate the vector maps from these and each will have the > desired value. So far no success, but I'll keep trying. > Start editing the vector, then click "update/display attributes" button, then click the appropriate centroid and change the value in the vector table. Mark ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Change value of cells in raster map
Hi. >What I fail to see is the appropriate module to modify an existing map > by > changing the value in each cell. Please point me in the right direction. > Maybe if-then statements with mapcalc are applicable to the situation. outputRaster=if(EXPRESSION,true,false) Mark ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] g.region and terraflow
Hi. Not sure if this is part of the problem, but the g.region " -a " switch will align the raster and should get rid of the non-square (rectangular) cells. Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Change units in location
Hi. > I'd like advice and suggestions on how to accommodate this need with > the existing location, mapsets, and vector/raster maps. Alternatively, if a > new location needs to be created how I would specify its parameters. > > The location's projection is static (AFAIK). If you create a new projection, you can project data into the new location with units of meters. EPSG 2838 is oregon north nad83/harn with horizontal units of meters. http://spatialreference.org/ref/epsg/2838/ Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Guidance wanted working with LiDAR data
> > Hi. > > > What modules are appropriate for these data to model flow paths to the > culvert inflow? Flow accumulation can be modeled with r.watershed or r.terraflow, with the former as a preference for drainage networks. r.stream.extract will vectorize the drainage network. > Or, should I convert the raster or vector files to a > different type? > The above mentioned modules (r.watershed/r.terraflow) work on continuous raster DEMs. Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Need help in r.lake
Hi. How can I assign multiple "water level" paramter for different lakes in the single rater map. Is there any functionality in GRASS GIS to support this analysis? For each lake, keep adjusting the 'fill to' elevation until it overflows. Then reduce the elevation slightly to have the lake full before overflowing. Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.contour failing?
> > I cannot get r.contour working. It always takes a lot of CPU, then >> crashes. Anyone has more joy? >> grass 7.0.1-2 from Debian sid. >> > > > I just used this yesterday without issue, but with 7.1. Are the region > settings correct and/or the increment between contours levels? > Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass71_trunk: error on access gui
Removed install directory and all is good. Thanks for the help =D Mark On Mon, Oct 5, 2015 at 4:06 AM, Eugenio Trumpy wrote: > Thank you very much Martin, > now I can access the gui. > It was my mistake since I didn't delete the real target directory > (/usr/local/grass71..) > I did it and now everything goes fine. > > Best > > Eugenio > > > > Date: Mon, 5 Oct 2015 09:59:39 +0200 > > Subject: Re: [GRASS-user] grass71_trunk: error on access gui > > From: landa.mar...@gmail.com > > To: frippe12...@hotmail.com > > CC: nete...@osgeo.org; grass-user@lists.osgeo.org > > > > > Hi, > > > > 2015-10-05 9:52 GMT+02:00 Eugenio Trumpy : > > > which grass71 > > > /usr/local/bin/grass71 > > > > > > isn't it? > > > > it doesn't really help. Try to delete target directory first before > > installing, so > > > > sudo rm -rf /usr/local/grass-7.1.svn > > > > then > > > > cd /path/to/grass_trunk > > make distclean > > svn up > > ./configure ... > > make > > sudo make install > > > > I hope it helps. Ma > > > > > Subject: RE: [GRASS-user] grass71_trunk: error on access gui > > > From: nete...@osgeo.org > > > To: frippe12...@hotmail.com > > > CC: grass-user@lists.osgeo.org; mlenn...@club.worldonline.be > > > > > > > > > > > > On Oct 2, 2015 4:44 PM, "Eugenio Trumpy" > wrote: > > > > > >> > > >> Starting grass71 I have the choice of the location and mapset, > > >> then it crash with the highlighted errors. > > > > > > Perhaps you start a wrong start script? > > > Check with > > > > > > which grass71 > > > > > > Markus > > > > > > > > > ___ > > > grass-user mailing list > > > grass-user@lists.osgeo.org > > > http://lists.osgeo.org/mailman/listinfo/grass-user > > > > > > > > -- > > Martin Landa > > http://geo.fsv.cvut.cz/gwiki/Landa > > http://gismentors.cz/mentors/landa > > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass71_trunk: error on access gui
I was (am) having the same issue and started with fresh svn. Had same catalog error. I ended up using the Ubuntu grass71-daily package on Mint. Still can't get qgis to display grass vectors and rasters though with qgis 2.10 and grass71. Mark On Fri, Oct 2, 2015, 2:03 PM Markus Neteler wrote: > > On Oct 2, 2015 4:44 PM, "Eugenio Trumpy" wrote: > > > > > > > Starting grass71 I have the choice of the location and mapset, > > then it crash with the highlighted errors. > > Perhaps you start a wrong start script? > Check with > > which grass71 > > Markus > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.vol.dem - inverted on Y axis with vtk output
I'm running grass 7.1 on Linux. Installed the r.vol.dem add-on. When I save output to a .vtk file for paraview from r.vol.dem, the data gets inverted around the Y axis when I view it in Paraview. If I export from r.vol.dem to an ASCII text file, then import with v.in.ascii to points, then export the points to .vtk format (v.out.vtk), the shape is oriented correctly on the Y axis. Can anyone confirm that output from r.vol.dem to .vtk file inverts the Y axis? Or perhaps I am missing something obvious? Thanks, Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] DTM/DEM to TIN
Hi. > I can't find tools to generate TINs, given a certain amount of tolerance, > which preserve significative locations (like those obtained by TPI for > example) and shapes (in a morphonetric sense) > Does the v.triangle add-on accomplish the goal? https://raw.githubusercontent.com/amuriy/GRASS-scripts/a7df12d996abfe6461f509fce6feb6c869af2d5e/v.triangle Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] New GRASS 7 addon: v.lidar.mcc
Thanks for this contribution. I look forward to trying this when I have time. Mark On Wed, Sep 24, 2014 at 3:49 AM, Blumentrath, Stefan < stefan.blumentr...@nina.no> wrote: > Dear all, > > > Today I uploaded a new GRASS 7 addon to SVN. > > The Python-script „v.lidar.mcc“ aims at removing vegetation returns from > LiDAR point-clouds. It is a modified implementation if Evans & Hudak`s > (2007) multiscale curvature classification (mcc) algorith. > > Compared to the original, the GRASS module has a few more options (useer > can define also spline steps, number of scale domains, and convergence > threshold). I am not sure if terrain interpolation method in v.outlier > (which v.lidar.mcc uses) does match exactly the thin-plate interpolation > that Evans & Hudak used. > > > When I find the time I will compare results and performance to the > original mcc-tool... I hope the manual is understandable and I would be > happy about feedback... > > > Cheers > > Stefan > > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.profile
Thanks for the help! Logged an update. Mark On Thu, Jul 3, 2014 at 9:31 AM, Vaclav Petras wrote: > > > > On Thu, Jul 3, 2014 at 8:10 AM, Mark Seibel wrote: > >> >>> This is a long standing problem (for me anyway) - see thread from 2012 >>> https://www.mail-archive.com/grass-dev@lists.osgeo.org/msg26480.html >>> >>> >> How can I determine if this is an active ticket, so I can create one if >> need be? >> >> > Search through GRASS Trac instance, i.e. this website: > > http://trac.osgeo.org/grass/ > > Simple search: > > http://trac.osgeo.org/grass/search > > Advanced search (aka Custom query): > > trac.osgeo.org/grass/query > > However, in your case you know the ticket number (usually prefixed with > #), so search for it (#1787) or just add the number to the end of the URL: > > http://trac.osgeo.org/grass/ticket/1787 > > Also, if you found an email with the ticket (copy of ticket message was > sent to mailing list), you should find a link to the ticket at the bottom > of the message. > > The ticket status is in parentheses after the ticket number. > > If the ticket is older without activity, you may want to write there that > you are also affected and specify your system and other related details. > > You need OSGeo ID to be able to login to the GRASS Trac and create and > modify tickets. > > http://www.osgeo.org/osgeo_userid > > Vaclav > > Thanks >> Mark >> >> >> ___ >> grass-user mailing list >> grass-user@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-user >> > > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.profile
> > > This is a long standing problem (for me anyway) - see thread from 2012 > https://www.mail-archive.com/grass-dev@lists.osgeo.org/msg26480.html > > How can I determine if this is an active ticket, so I can create one if need be? Thanks Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.profile
Thanks. I'll have to come up with a creative solution. The best solution would have been for the US to adopt the metric system back in the 70s, but there's some saying about spilt milk. Mark On Wed, Jul 2, 2014 at 1:07 PM, wrote: > > Mark Seibel wrote: > > When using r.profile interactively in a location using horizontal and > > vertical units of meters, the output profile is correct. My transect is > > about 800 meters long. > > > > When using r.profile interactively in a location using horizontal and > > vertical units of feet, the Y axis (raster elevation values) displays > > values correctly. However, the X axis stops plotting at 800 *feet* but > > puts the endpoint 'triangle' of the profile at the correct distance on > the > > X axis at around 2600 feet. Essentially, it squishes the plot to fit > > between 0 and 800 when it should be between 0 and around 2600. > > > > I notice that when I measure distances, the display also outputs the > units > > in meters, but the values are in feet. Seems like a related issue. > > > > Where do I change this so that units are correct as feet? I've tried > > setting the EPSG code in Settings-->Preferences-->Projection Tab to 2882 > > with the proj.4 string inserted, but it still treats the horizontal units > > as if they were meters and not feet when measuring or profiling the > surface. > > > > Tried r.profile in GRASS 6.4 and 7.1 on Linux Mint with same results. > > > > Thanks, > > Mark > > This is a long standing problem (for me anyway) - see thread from 2012 > https://www.mail-archive.com/grass-dev@lists.osgeo.org/msg26480.html > I still have the problem but have learned to adapt … I upgrade the csv > output to the appropriate scales in GNU Octave and replot… bit of a pain > but it works. > Interesting that you are experiencing this on a Linux system - others > reported the problem not replicated on Linux back in 2012. > > Stu > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.profile
When using r.profile interactively in a location using horizontal and vertical units of meters, the output profile is correct. My transect is about 800 meters long. When using r.profile interactively in a location using horizontal and vertical units of feet, the Y axis (raster elevation values) displays values correctly. However, the X axis stops plotting at 800 *feet* but puts the endpoint 'triangle' of the profile at the correct distance on the X axis at around 2600 feet. Essentially, it squishes the plot to fit between 0 and 800 when it should be between 0 and around 2600. I notice that when I measure distances, the display also outputs the units in meters, but the values are in feet. Seems like a related issue. Where do I change this so that units are correct as feet? I've tried setting the EPSG code in Settings-->Preferences-->Projection Tab to 2882 with the proj.4 string inserted, but it still treats the horizontal units as if they were meters and not feet when measuring or profiling the surface. Tried r.profile in GRASS 6.4 and 7.1 on Linux Mint with same results. Thanks, Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.surf.contour (again)
> Thanks for the tip, I will try the add-on. Any idea what is causing the > distortion in the maps? It would interest me if it is a resolution issue > or the data itself > It's a function of the contour lines and interpolator.Contour lines are poor input for building DEMs because they have high density of input points along the line with no data between them. When the distance is too large some interpolator create sharp angle artifacts in the process. Other interpolators smooth the transition areas better. Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.surf.contour (again)
Hi. > Well I am willing to give it a second try and now I wonder what I can > do better. Increase resolution? Leave out some contour lines? > > To speed up the process to see if the results are desirable, you could increase the resolution and try the add-on r.surf.nnbathy. Then decrease resolution if necessary and applicable. Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Topo to Raster
Hi. > > Using contour lines as input, I have found the r.surf.nnbathy module to > > perform very well. > > Previously, contour lines created by land surveying provided more > detail than available DEMs. Nowadays (since SRTM of 2001), DEMs > provide more detail than contour lines and contour lines are usually > derived from a DEM. Therefore creating a DEM from contour lines which > if in doubt have been created using a DEM is no longer recommended, > rather use any DEM instead. > > I certainly agree that contour lines are poor quality input data, however, for situations involving conceptual reclamation, contours are used to build the post-development DEM. This still allows for (albeit generalized) conceptual modeling of the drainage areas for reclaimed streams and drainage areas, and allows for pre/post development analysis of drainage areas (as it is understood the contours are conceptual, not as-built). Nice to know that GRASS has modules that can cope with contour data, and still produce adequate and reliable results. Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Topo to Raster
> > Hi. > > is it possible in GRASS to perform something similar to "Topo to > Raster" as known in ArcGIS [1]? > > [1] > http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//009z007m00.htm Are there specific inputs of the "topo to raster" tool that are of importance for your application? Using contour lines as input, I have found the r.surf.nnbathy module to perform very well. For (LiDAR) point data, my preference is v.surf.rst. The "topo to raster" tool alters the DEM by filling sinks. The arcgis approach alters the DEM so that their flow routing tool doesnt stop in every sink. My preference is to use the data as close to original source as possible, and let the superb GRASS flow and routing algorithms handle routing through the sinks automatically. If one wanted to mimic the arcgis method of filling sinks after interpolating, one could run iterations of r.fill.dir to make it depression-less. This isnt necessary with the hydrologic tools in GRASS because the r.watershed algorithm is intelligent enough to keep seeking the next lowest location the DEM. Add in the fact that r.watershed has MFD, and GRASS quickly surpasses the ESRI hydrologic toolset offerings. HTH, Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] how to import e00 data
Hi. this is what I have: > > PRJ 2 > ProjectionGEOGRAPHIC > ~ > ZunitsNO > ~ > Units DD > ~ > Spheroid CLARKE1866 > ~ > Xshift0.00 > ~ > Yshift0.00 > ~ > > Looks like the ESPG code is 4302 try a location with EPSG: 4008 # Unknown datum based upon the Clarke 1866 ellipsoid <4008> +proj=longlat +ellps=clrk66 +no_defs <> 4302 is Trinidad? # Trinidad 1903 <4302> Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] converting LAT/LON shape file to X/Y shape file
Hi. > I would like to know if there is a way to convert a shapefile defined with Lat/Lon into a shapefile defined with X and Y. One could setup a lat/long location and an xy location and project from one to another in GRASS. Alternatively, one can use gdal's ogr2ogr command to reproject the shapefile at the command line outside of GRASS, if the goal is to simply reproject a shapefile. Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] DEM creation from aerial photography
Hi. If all I've got is raw (ie, unrectified) aerial photography & sufficient > ground control points, what is the process for creating a DEM (assuming > it's possible with GRASS)? Are you looking to georeference an aerial image? Or create a Digital Elevation Model? Each is a different, specific task. Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] image fusion in grasss 6.4.2
Hi, > How can I do image fusion in grass gis 6.4.2? One can use the r.his module and the r.composite module. For example, to make a shaded and colorized DEM: r.his h_map= i_map= r_map=terrain.red g_map=terrain.green b_map=terrain.blue Then to make a composite raster: r.composite red=terrain.red green=terrain.green blue=terrain.blue levels=32 output=shaded_color_DEM Hope that helps get things rolling in the right direction. Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] OpenCL GPU acceleration build support now available in trunk
> fyi we have just added OpenCL GPU (graphics card) support to the build system > for GRASS 7. This is really exciting. Thanks to all who made this happen. Looking forward to seeing how and where it will be implemented. Excellent work. Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Processing LiDAR data in GRASS GIS
Hi, > v.in.ascii input=b29_3.txt output=b29_3 fs=space z=3 You could skip the attribute table by using this command and make 3D points and not build topology: v.in.ascii -z -t -b input=text_file.xyz output=surface_points fs=space z=3 > g.region vect=b29_3 -p The -a flag aligns the region. Was the resolution set prior? If the resolution was not set, you can do this with: g.region vect=b29_3 -ap res= It stated that I have to show in which column of the attribute > table are Z values in order to execute the command. The v.surf.rst module produces very nice results and allows usage of the 3D points (-z). Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass on linux
On Thu, Apr 18, 2013 at 10:54 AM, BLANDENIER Lucien < lucien.blanden...@unine.ch> wrote: > > I'm actually using grass on Window but I would like to migrate to Linux. > Which distribution do you suggest for a new Linux user? I like the Mint > distribution but there is not the latest grass version (only the 6.4.1). > Hi. I had used Ubuntu for several years, but recently changed to Linux Mint. So far, I am very happy with the decision. Like other's had mentioned, Linux Mint can use Ubuntu repositories so you can get all the latest goodies from UbuntuGIS (https://wiki.ubuntu.com/UbuntuGIS). The UbuntuGIS "unstable" is not as it may sound; it has packages which technically may be labeled unstable, but they are not necessarily unstable software packages to where you have software crashes. Others can add insight, but my experience with the "unstable" PPA has been very good. As a new Linux user, I recommend using the binary packages. Compiling from source can be frustrating and time consuming if not having done it many times before. It is definitely worth learning how to compile software on Linux, however, the fastest way to get up and running with GRASS GIS (and other GIS packages) on Linux is using the binaries. Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] R.basin - feet?
Following-up to my earlier post... > I'm working in coord system feet and DEM units feet. > > I ran r.basin on a stream basin, and I noticed that it reports the basin > max/min elevation in meters, however, the values are really feet. > > Has anyone done this with units of feet? I see the program do feet/meter > conversion when running, but maybe that is just for the coord system units. > (?) > I realize this only applies to a fraction of participants, but maybe it would help someone. I noticed language in the r.sim.sediment and r.sim.water modules which mention that the horizontal units are converted to meters. It also states that the elevation needs to be in meters. Using coordinate system of feet, but DEM units of meters for r.basin, I verified that at least two parameters are correctly calculated: Stream length and basin elevations. If I use DEM units of feet, it reports that the elevations are in meters, but the values are actually feet. Please note I have not confirmed the findings in the actual source code, just from some quick observations of the module output. Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] R.basin - feet?
Hi all. Im working in coord system feet and DEM units feet. I ran r.basin on a stream basin, and I noticed that it reports the basin max/min elevation in meters, however, the values are really feet. Has anyone done this with units of feet? I see the program do feet/meter conversion when running, but maybe that is just for the coord system units. (?) Does this mean I need the coord sys amd DEM units in meters, or just the DEM units as meters? Much thanks, Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] [Qgis-user] DEM values extraction
On Wed, Dec 19, 2012 at 8:52 AM, Mark Seibel wrote: > On Wed, Dec 19, 2012 at 8:19 AM, hersala wrote: > >> Dear users: >> Can someone give me a hint about how I can extract (using a polygon .shp) >> height values from a DEM >> > > Hi. You can try this module. > http://grass.osgeo.org/grass64/manuals/v.rast.stats.html > > Mark > My bad. I thought it was the grass-user list. Need more coffee to wake up! Apologies Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] [Qgis-user] DEM values extraction
On Wed, Dec 19, 2012 at 8:19 AM, hersala wrote: > Dear users: > Can someone give me a hint about how I can extract (using a polygon .shp) > height values from a DEM > Hi. You can try this module. http://grass.osgeo.org/grass64/manuals/v.rast.stats.html Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Why Does Re-projection Increase Disk Space Used? [UPDATE]
Hi. On Wed, Mar 14, 2012 at 11:33 AM, Rich Shepard wrote: > On Wed, 14 Mar 2012, Rich Shepard wrote: > > Related question: if they're no longer needed, why doesn't grass remove > them from the hard drive? > If you exit GRASS does it purge them? Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] extract drainage in the right direction
Hi, On Tue, Jan 24, 2012 at 1:24 PM, Marcello Benigno < benigno.marce...@gmail.com> wrote: > Hi All, > > There is some methodology where it is possible extract the drainage > network and maintain the correct graph orientation? > Regrettably, I cant say for sure, but I would be surprised if the vector stream/drainage network output from r.stream.extract did not orientate vector directions downstream properly. http://grass.osgeo.org/wiki/GRASS_AddOns#r.stream.extract Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS GISDBASE and unison syncronization
Hi, On Wed, Jan 18, 2012 at 1:43 PM, Kirk Wythers wrote: > > On Jan 18, 2012, at 12:21 PM, Martin Landa wrote: > > yes, GISDBASE can be mounted remotely eg. via sshfs... > > > Martin > > > > There you have it then. No need to keep anything synchronized. Just one > file system (regular backups of course!), and no need to devote god know > how much disk space to two copies of GISDBASE. > > > This is very interesting. Typically I do this because my home machine is a 64bit workhorse, and the other work machine is a 32bit dog. So I do intensive CPU processing (lidar filtering, DEM construction, watershed analysis) on the higher-powered machine, using all local, faster hardware and 64bit OS. If I left the GISDBASE at work on the 32 bit system, I would think the 64bit machine would not be at optimal performance working with data over a DSL connection back to a 32bit old machine with far lower performing hardware. (?) For quick sessions I see sshfs as a nice solutions, but for situations where the data is being processed for hours and hours, it seems an optimal to run it all local on the 64bit fast machine. (?) Nice to learn about the sshfs. Thanks for the tip! Mark Any info would be helpful to understand the pros and cons, since I'm not a hardware guy. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS GISDBASE and unison syncronization
Hi, On Wed, Jan 18, 2012 at 12:20 PM, Stephen Sefick wrote: > All, > > I would like to keep two databases in sync between two computers (my > laptop and my work desktop). I will be modifying files on both machines. > I am running GRASS 6.3svn on Ubuntu LTS 10.04.03. I am using unison > 2.32.52. I have noticed that the .bashrc and .bashhistory files are being > synced everytime that a change a file and then use unison. I have also > noticed that unison used a shortcut to copying a cidx file from another > vector instead of from the vector that was new to the other machine. > > Will these things outlined above cause any problems? Are there better > solutions? I'm not sure if this is a better solution, or the advantages of each one, but I regularly use rsync to synchronize GRASS locations & mapsets between workstations between work and home. It has never caused me any grief, just joy. I've been using this approach for years without issues (that I'm aware of at least). Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.fillnulls for large area
The region is almost a billion cells - see g.region -p output below - but about 40% of that region is ocean areas with no DEM data. Maybe apply a raster mask over the ocean area? Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] runoff map
> > I want to generate a runoff map starting from elevation map and annual > rainfall…is there a tool in GRASS? > > Some of these modules may be of assistance: http://grass.fbk.eu/grass64/manuals/html64_user/r.terraflow.html http://grass.fbk.eu/grass64/manuals/html64_user/r.watershed.html A more sophisticated module addressing rainfall events over spatially variable terrain, with associated output depths and flow velocities: http://grass.fbk.eu/grass64/manuals/html64_user/r.sim.water.html Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: r.stream.extract with external flow accumulation maps
> I believe that the flow accumulation grid was produced using ArcHydro. I put > the link to the data set that I am using below if anyone wants to try it > out. Hi. Not sure if this is the issue, but I recall this from the manual. " accumulation Input map, optional: Accumulation values of the provided accumulation map are used and not calculated from the input elevation map. If accumulation is given, elevation must be exactly the same map used to calculate accumulation. If accumulation was calculated with r.terraflow, the filled elevation output of r.terraflow must be used. Further on, the current region's resolution should be identical to the accumulation map. Flow direction is first calculated from elevation and then adjusted to accumulation. It is not necessary to provide accumulation as the number of cells, it can also be (adjusted) total contributing area in square meters or any other unit. " Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] faster than v.rast.stats
There is an add-on v.rast.stats2 which is stated to be faster. I encountered and reported a bug a while ago on it, but I believe it was fixed. Mark On Jun 21, 2011 10:03 AM, "Frederico Mestre" wrote: > Hello, > > > > I'm trying to retrieve some statistics from several rasters, based on > overlaying vectors. > > > > I'm using v.rast.stats but it is very slow. Is there another way? > > > > I read something about Starspan, a software that does this same thing > faster, but I can,t find it to download. > > > > Can anybody help? > > > > Frederico Mestre ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.rast.stats2 bug?
I just checked out v.rast.stats2 (Feb.28) and when I run it I get the
following error.
Do I need to file a ticket, or am I missing something obvious? While
it says 'done', the table is unpopulated.
awk: {printf "\nUPDATE acoe_jd SET dist_n
awk: ^ unterminated string
sed: couldn't write 176 items to stdout: Broken pipe
Restoring previous MASK...
Statistics calculated from raster map
and uploaded to attribute table of vector map .
Done.
Much thanks,
Mark
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] overlap to vector maps
> I have 2 vector maps, one represents a grid and the other is delimited > figure. > I wanted to know the fraction of the figure overlaps each cell. > Is is possible to do this without converting both maps to raster? v.overlay--> http://grass.fbk.eu/gdp/html_grass64/v.overlay.html The output file would have the spatial intersection of both vector maps. Then uploading the areas from the geometry to the database (v.to.db) would populate the values for the intersected areas. Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.stream.* for grass7 major update
> I committed changes in next version of r.stream for grass7 (available via > svn-add-ons) > There are lots of changes to older version of grass6 Just a note to say thanks for this fantastic contribution. I've had great success in using the r.stream.* modules (and MFD routing outputs in r.watershed). These are really an incredible set of tools. I've been using GRASS 6.5. For one analysis, we need to determine wetland proximity and elevation to streams and outlets "as the water flows", and not "as the crow flies" under a significant nexus study. r.stream.distance got the job done with amazing results. For the same project, the stream ordering (strahler) worked very well also. I am anxious to try the other r.stream modules I have not used yet in 6.5, and also to see the enhancements in 7.0. I was looking for an excuse to post a "thank you", and thought this reply to be on topic :) Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] postgis back-end
I was thinking that I > would use postgis, but I need to know if it will be possible to > simultaneously use ArcGIS and GRASS (depending on purpose and > preference) with one postgis back-end I have not tested this, however, it seems to enable ArcGIS to communicate with postGIS. I saw a screenshot of ARC 9.3 connected to postGIS. ZigGIS version 3.0 is said to return to OSS. http://www.obtusesoft.com/ Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] 2 questions about usage of g.region
There is some very good documentation on Python and GRASS. I hope this helps. http://grass.osgeo.org/wiki/GRASS_and_Python Mark On Thu, Feb 3, 2011 at 9:57 AM, katrin eggert wrote: > Thanks Micha and Hermann for your feedback. > Just one very last question: in a Python script how can I make an variabel > to equal to an image spatial resolution? (I mean, How can I retrieve an > image spatial resolution)? > THanks > Best regards, > Kat > > 2011/2/3 Micha Silver >> >> katrin eggert wrote: >> >> HEy >> >> I have three questions: >> 1- Is it possible to define active region spatial resolution by selecting >> an image instead of putting values? >> >> Using a grass raster, yes. g.region rast= >> >> >> 2- What is done with -a flag? >> >> If you have , i.e. a resolution of 5 meters and the E-W extent is 99 >> meters, then with the -a flag the region will be reset to 100 m. Without the >> -a flag, the resolution will be recalculated so that it fits into the >> extents. So in the above case, without -a, the E-W res will be changed to >> 4.95 >> >> >> 3- Just to confirm this, when an image is imported with r.in.gdal it is >> kept with its original resolution right? it only gets the active region >> spatial resolution when I process it right (e.g. mapcalc or somethingg) >> >> >> AFAIK, yes. >> >> >> Thanks >> Kat >> This mail was received via Mail-SeCure System. >> >> >> ___ >> grass-user mailing list >> grass-user@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-user >> >> This mail was received via Mail-SeCure System. >> >> >> > > > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Using Access .mdb Files
> I don't see an obvious v.in. appropriate for .mdb files. What > should I use for this? Any idea how many feature classes are in the geodatabase? Would it be possible to ask BLM to export the feature classes out as shapefiles? Just an idea... Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: Problem with Lidar Tools
On Tue, Dec 7, 2010 at 7:53 PM, benmarillier wrote: > > Hi All, > > I am having similar problems to Kaipi in regards to the v.lidar.growing > stage of LiDAR processing. I'm running GRASS 6.4.0 on Windows. My dataset is > a 1km by 1km tile of LiDAR with a point spacing of about 1.5 points/m2, so a > total of about 1.5 million in the area of interest. > > Thus far I've imported the points with v.in.ascii, split into the first > returns and last returns. I interpreted these two classes as follows (please > correct me if I'm wrong)... > > First returns: all first returns, including single returns where only one > return has been received. > Last returns: all single returns, and the last return where multiple returns > have been received. > > Then I removed outliers as per the micro-tutorial on the GRASS wiki. > > Next I ran v.lidar.edgedetection on the last returns with the default > parameters. > > This resulted in a reasonable looking classification of edge (2), not-edge > (1) and uncertain (3). The edges of the buildings and trees are quite well > defined, as shown in the image below, so far so good... > > ...however, when I run v.lidar.growing (default parameters), the output I > get is exactly the same as the edgedetection output. The points are > classified identically into 1, 2 and 3, and there appears to have been no > change in the classification. I've tried varying the growing parameters, and > changing the region resolution, but the output is always the same. > > I've trawled through the forums to no avail, so any advice would be greatly > appreciated. > > Thanks, > Ben Hi. Is this urban, rural, or mixed land use? Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Two Generic Questions
> 2.) Are there any potential gotcha's in downloading and using Google Earth > images with GRASS? For #2, I cant speak from a technical aspect, but I came across this information about usage: "...However, you cannot sell these to others, provide them as part of a service, or use them in a commercial product such as a book or TV show without first getting a rights clearance from Google." http://earth.google.com/support/bin/answer.py?hl=en&answer=21422 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Clip/Extract Rasters using a vector
Would you please post your command syntax, and associated error? Mark "Andrew Lewin" wrote: >Hi John and Mark, > >I am getting a syntax error when I type in either of your statements. To be >clear, I am using Mac Snow Leopard in the Terminal program (bash). > >Cheers, > >Andrew > >Andrew Lewin >andrew.le...@sympatico.ca > >President >Coastal/Marine Spatial Ecologist >Spatial-Conserve Incorporated > >Associate >C-FOAM (Canadian Fisheries, Oceans and Aquaculture Management Group) >Telfer School of Management, University of Ottawa > > > > > > > >On 2010-09-16, at 12:22 PM, John C. Tull wrote: > >> Correct me if I am wrong, but for step 3, you can simply use an equality >> statement, i.e., echo clippedRaster=NA_temperature | r.mapcalc'. This >> shortens things a little further. >> >> Regards, >> John >> >> On Sep 16, 2010, at 8:41 AM, Mark Seibel wrote: >> >>> Surely there is a more elegant way... >>> >>> 1) Convert the vector you wish to use as a clipper to a raster. >>> 2) Set the raster mask to be the raster clipper (the converted vector). >>> 3) Use map calculator to perform some non-data altering operation, but >>> get the mask to do its thing (eg. echo 'clippedRaster=NA_temperature + >>> 0 | r.mapcalc'). >>> >>> Mark >>> >>> On Thu, Sep 16, 2010 at 10:52 AM, Andrew Lewin >>> wrote: >>>> Dear Listers, >>>> I would like to clip or extract a raster using a vector file; however, I >>>> can't seem to find the command to do this in GRASS 6.4 ORC6. The raster >>>> file is an interpolated file of temperature for North America. The raster >>>> file extends beyond the North America boundaries. I would like to clip the >>>> raster file to the North American boundaries, but I cannot find the command >>>> to do so. >>>> I would appreciate any help possible. >>>> Thank You, >>>> Andrew >>>> Andrew Lewin >>>> andrew.le...@sympatico.ca >>>> >>>> President >>>> Coastal/Marine Spatial Ecologist >>>> Spatial-Conserve Incorporated >>>> Associate >>>> C-FOAM (Canadian Fisheries, Oceans and Aquaculture Management Group) >>>> Telfer School of Management, University of Ottawa >>>> >>>> >>>> >>>> >>>> >>>> >>>> ___ >>>> grass-user mailing list >>>> grass-user@lists.osgeo.org >>>> http://lists.osgeo.org/mailman/listinfo/grass-user >>>> >>>> >>> ___ >>> grass-user mailing list >>> grass-user@lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/grass-user >> >> > -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Clip/Extract Rasters using a vector
Surely there is a more elegant way... 1) Convert the vector you wish to use as a clipper to a raster. 2) Set the raster mask to be the raster clipper (the converted vector). 3) Use map calculator to perform some non-data altering operation, but get the mask to do its thing (eg. echo 'clippedRaster=NA_temperature + 0 | r.mapcalc'). Mark On Thu, Sep 16, 2010 at 10:52 AM, Andrew Lewin wrote: > Dear Listers, > I would like to clip or extract a raster using a vector file; however, I > can't seem to find the command to do this in GRASS 6.4 ORC6. The raster > file is an interpolated file of temperature for North America. The raster > file extends beyond the North America boundaries. I would like to clip the > raster file to the North American boundaries, but I cannot find the command > to do so. > I would appreciate any help possible. > Thank You, > Andrew > Andrew Lewin > andrew.le...@sympatico.ca > > President > Coastal/Marine Spatial Ecologist > Spatial-Conserve Incorporated > Associate > C-FOAM (Canadian Fisheries, Oceans and Aquaculture Management Group) > Telfer School of Management, University of Ottawa > > > > > > > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Raster: r.report vs r.info
Maybe your region computation area needs set to the extent of the data? It looks like it is only one cell with south and west being 0, and north and east being 1. Mark On Fri, Aug 27, 2010 at 12:11 PM, Andrew Lewin wrote: > Hi Everyone, > I am having trouble with creating categories for a raster map (floating > point). > I used r.reclass to create a category for my raster (temperature values; > floating point). I thought I successfully added categories but when I ran > r.report there are no categories; however, when I run r.info for the raster > it shows that I have two categories. > Can anyone give me a hand with this problem? The results of the r.report > and r.info are below: > r.report: > GRASS 6.4.0RC6 (MacrophytesGIS):~/grass/MacrophytesGIS/PERMANENT > r.report > mynatemp4reclass > 100% > +-+ > | RASTER MAP CATEGORY REPORT > | > |LOCATION: MacrophytesGIS Fri Aug 27 12:00:05 > 2010| > |-| > | north: 1N east: 1E > | > |REGION south: 0 west: 0 > | > | res: 1 res: 1 > | > |-| > |MASK:none > | > |-| > |MAP: Reclass of mynatemp4 in PERMANENT (mynatemp4reclass in PERMANENT) > | > |-| > | Category Information > | > |#|description > | > |-| > |*|no data > | > +-+ > r.info: > GRASS 6.4.0RC6 (MacrophytesGIS):~/grass/MacrophytesGIS/PERMANENT > r.info > mynatemp4reclass > ++ > | Layer: mynatemp4reclass Date: Thu Aug 26 15:25:18 2010 > | > | Mapset: PERMANENT Login of Creator: andrewlewin > | > | Location: MacrophytesGIS > | > | DataBase: /Users/andrewlewin/grass > | > | Title: Reclass of mynatemp4 in PERMANENT ( mynatemp4reclass ) > | > | Timestamp: none > | > || > | > | > | Type of Map: reclass Number of Categories: 2 > | > | Data Type: CELL > | > | Rows: 251 > | > | Columns: 434 > | > | Total Cells: 108934 > | > | Projection: Latitude-Longitude > | > | N: 82:39:08.872N S: 14:28:55.128N Res: 0:16:17.744 > | > | E: 52:28:47.899422W W: 170:21:08.795422W Res: 0:16:17.744 > | > | Range of data: min = 1 max = 2 > | > | > | > | Data Source: > | > | Reclassified map based on: > | > | Map [mynatemp4] in mapset [PERMANENT] > | > | > | > | Data Description: > | > | generated by r.reclass > | > | > | > | > | > || > | Reclassification of [mynatemp4] in mapset [PERMANENT] > | > | > | > | Category Original categories > | > | > | > | 1 -20--1 > | > | 2 0-29 > | > ++ > > Cheers, > Andrew > Andrew Lewin > andrew.le...@sympatico.ca > Founder of Oceans and Coasts Blog > President > Coastal/Marine Spatial Ecologist > Spatial-Conserve Incorporated > Associate > C-FOAM (Canadian Fisheries, Oceans and Aquaculture Management Group) > Telfer School of Management, University of Ottawa > > > > > > > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] speeding up v.overlay
Using the v.select module first to limit the number of features clipped often helps speed up the intersection process. Mark On Mon, Aug 23, 2010 at 8:45 AM, Stuart Gralton wrote: > Hello Everyone, > > I am trying to use v.overlay to clip contour lines for a specific area. The > contour lines were imported into GRASS from a shapefile which is about 33Mb. > The query was as follows: > > v.overlay ainput=contour atype=line binput=boundingbox output=contour_clip > operator=and > > The operation took 16 hours to complete, which seems excessive. Is there > anything that I can do to speed things up? > > I am aware of v.split, v.select, v.clean as suggestions from other posts as > ways of increasing performance. Unfortunately none of these helped me very > much: > > v.split seems to drop the attribute table (but it has amazing effects on > performance). > v.select helps a little, but due to the nature of the data, not many > features are removed. > v.clean did not have any effect. The data is from the government, and is > already of high quality. > > > Is there anything that I am missing? Or is there any way to preserve the > attribute table when using v.split? > > Thanks in advance, > Stuart > > > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS Python functions
Thank you for your time in detail in the explanations. I sincerely appreciate it. That helps immensely. I dream to one day contribute some code. Thank you. Mark "Glynn Clements" wrote: > >Mark Seibel wrote: > >> I'm unclear about the difference between some of these library >> functions, and when they are applicable. >> >> Specifically: >> Uses for read, feed and pipe commands, as well as start and exec command. >> >> I've read the page which gives the explanations, but am having a >> hard time seeing which ones are applicable for certain tasks. >> >> I've been using a lot of subprocess calls, and these seem cleaner.(?) > >All of the *_command functions use make_command to construct a command >line for a program which uses the GRASS parser. Most of them then pass >that command line to subprocess.Popen() via start_command(), except >for exec_command() which uses os.execvpe(). > >[To be precise, they use grass.Popen(), which just calls >subprocess.Popen() with shell=True on Windows and shell=False >otherwise. On Windows, you need to use shell=True to be able to >execute scripts (including batch files); shell=False only works with >binary executables.] > >start_command() separates the arguments into those which >subprocess.Popen() understands and the rest. The rest are passed to >make_command() to construct a command line which is passed as the >"args" parameter to subprocess.Popen(). > >IOW, start_command() is a GRASS-oriented interface to >subprocess.Popen(). It should be suitable for any situation where you >would use subprocess.Popen() to execute a normal GRASS command (one >which uses the GRASS parser, which is almost all of them; the main >exception is r.mapcalc in 6.x). > >Most of the others are convenience wrappers around start_command(), >for common use cases. > >run_command() calls the wait() method on the process, so it doesn't >return until the command has finished, and returns the command's exit >code. Similar to system(). > >pipe_command() calls start_command() with stdout=PIPE and returns the >process object. You can use the process' .stdout member to read the >command's stdout. Similar to popen(..., "r"). > >feed_command() calls start_command() with stdin=PIPE and returns the >process object. You can use the process' .stdin member to write to the >command's stdout. Similar to popen(..., "w") > >read_command() calls pipe_command(), reads the data from the command's >stdout, and returns it as a string. Similar to `backticks` in the >shell. > >write_command() calls feed_command(), sends the string specified by >the "stdin" argument to the command's stdin, waits for the command to >finish and returns its exit code. Similar to "echo ... | command". > >parse_command() calls read_command() and parses its output as >key-value pairs. Useful for obtaining information from g.region, >g.proj, r.info, etc. > >exec_command() doesn't use start_command() but os.execvpe(). This >causes the specified command to replace the current program (i.e. the >Python script), so exec_command() never returns. Similar to bash's >"exec" command. This can be useful if the script is a "wrapper" around >a single command, where you construct the command line and execute the >command as the final step. > >If you have any other questions, you might want to look at the code >($GISBASE/etc/python/grass/script/core.py). Most of these functions >are only a few lines long. > >-- >Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] GRASS Python functions
Hi list! I'm unclear about the difference between some of these library functions, and when they are applicable. Specifically: Uses for read, feed and pipe commands, as well as start and exec command. I've read the page which gives the explanations, but am having a hard time seeing which ones are applicable for certain tasks. I've been using a lot of subprocess calls, and these seem cleaner.(?) Much thanks, Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.stream.extract Montgomery
> What is good guidance for where to set the threshold? Try using some already existing data for mapped streams, such as the national hydrography dataset. You can adjust the threshold of the accumulation until your modeled output is close to already mapped features. I don't see the -b flag for r.watershed > 6.4svn checkout (probably a week ago) in the man pages. I think the -b option starts in version 7 (?) I said > realistic because you can set the threshold to 1 for a 1m res dem. > There are lines that don't even look like streams all over the place. Threshold relates to the accumulation of upgradient cells. Its usually a larger number in the thousands to 10s of thousands (at least from my data/experience). > Is it possible to extract streams with the landscape (Mongomery) as a > guide for the threshold? Try without altering the montgomery exponent and see how well it matches known features. Mark > > On Thu, Aug 5, 2010 at 9:35 AM, Jarek Jasiewicz wrote: >> stephen sefick pisze: >>> >>> I would like to use the Montgomery method to extract streams (exp~2 >>> from the paper). What should the threshold value be? And in general >>> what should the threshold value be? I am working in the southeastern >>> coastal plain (USA), which is characterized by low gradient (if this >>> helps). >> >> for flat areas Montgomery's method is not a good option. Generally that >> method was created and tested on areas with gradient > 5%. >>> >>> I am using 1m resolution LIDAR data. I would like to extract >>> the most realistic map of streams that I can. >> >> Chmmm... what you mean realistic? Maybe use existing stream network will be >> the best solution? >> For coastal plains where is no real vallyes the r.watershed's treeshold with >> -b option seems to be best option >>> >>> I am also trying to >>> track down the inttermitance perminance threshold. Any guidance would >>> be greatly appreciated. >>> kindest regards, >>> >>> >> >> > > > > -- > Stephen Sefick > > | Auburn University | > | Department of Biological Sciences | > | 331 Funchess Hall | > | Auburn, Alabama | > | 36849 | > |___| > | sas0...@auburn.edu | > | http://www.auburn.edu/~sas0025 | > |___| > > Let's not spend our time and resources thinking about things that are > so little or so large that all they really do for us is puff us up and > make us feel like gods. We are mammals, and have not exhausted the > annoying little problems of being mammals. > > -K. Mullis > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Arc Binary coverages- arggg!
How did you obtain the coverage? They are typically distributed as e00 files, which when imported create a directory for the geometry and an info directory for the attributes. Mark On Wed, Jul 14, 2010 at 9:20 AM, stephen sefick wrote: > I don't have an info directory. I tried using v.in.ogr to no avail. > So, I downloaded the nation hydrography dataset and now I am trying to > find out projection information. > thanks, > > STephen > > On Tue, Jul 13, 2010 at 8:10 AM, Mark Seibel wrote: >> Much to my delight, v.in.ogr reads the binary arc coverages. I copied >> over the directory (which is the coverage name) and the info directory >> to a place on the Linux machine which has GRASS installed. (not sure >> if the 'info' directory is needed, but it did preserve attributes). >> >> For the OGR datasource name, I pointed it to the "arc.adf" file, and >> it imported the coverage as a GRASS vector with points, lines and >> polygon features. Attributes also preserved. >> >> Please let me know if you have any issues with this. First time I >> tried this, and great to know it can read the binary coverages. >> >> Mark >> >> On Mon, Jul 12, 2010 at 8:02 PM, Mark Seibel wrote: >>> That's what I figured. Then I am fairly sure this is what you're >>> after, http://grass.osgeo.org/grass64/manuals/html64_user/v.in.ogr.html. >>> Arc Vector coverages are stored in 2 directories. One for geometry >>> (the directory is the name of the coverage) and the database is >>> contained in an 'info' directory. The examples below are not clear to >>> me how it addresses this, but it does state it will do it. I could >>> try some testing tomorrow if not figured out by then. >>> >>> # Arc Coverage >>> We import the Arcs and Label points, the module takes care to build areas: >>> >>> v.in.ogr dsn=gemeinden layer=LAB,ARC type=centroid,boundary output=mymap >>> >>> >>> # E00 file (see also v.in.e00) >>> First we have to convert the E00 file to an Arc Coverage with >>> 'avcimport' (AVCE00 tools, use e00conv first in case that avcimport >>> fails): >>> >>> avcimport e00file coverage >>> v.in.ogr dsn=coverage layer=LAB,ARC type=centroid,boundary output=mymap >>> >>> All the best. >>> Mark >>> >>> On Mon, Jul 12, 2010 at 7:47 PM, stephen sefick wrote: >>>> Vector Coverages. >>>> >>>> On Mon, Jul 12, 2010 at 6:41 PM, Mark Seibel wrote: >>>>> Are these vector coverages or raster datasets? >>>>> >>>>> Mark >>>>> >>>>> On Jul 12, 2010, at 6:08 PM, stephen sefick wrote: >>>>> >>>>>> I have a couple of files that are in this format... >>>>>> >>>>>> aat.adf arx.adf dbltic.adf metadata.xml prj.adf txx.adf >>>>>> arc.adf dblbnd.adf log par.adf txt.adf >>>>>> >>>>>> they are arc binary data correct. Is there anyway I can use these >>>>>> with GRASS or QGIS? >>>>>> >>>>>> -- >>>>>> Stephen Sefick >>>>>> >>>>>> | Auburn University | >>>>>> | Department of Biological Sciences | >>>>>> | 331 Funchess Hall | >>>>>> | Auburn, Alabama | >>>>>> | 36849 | >>>>>> |___| >>>>>> | sas0...@auburn.edu | >>>>>> | http://www.auburn.edu/~sas0025 | >>>>>> |___| >>>>>> >>>>>> Let's not spend our time and resources thinking about things that are >>>>>> so little or so large that all they really do for us is puff us up and >>>>>> make us feel like gods. We are mammals, and have not exhausted the >>>>>> annoying little problems of being mammals. >>>>>> >>>>>> -K. Mullis >>>>>> ___ >>>>>> grass-user mailing list >>>>>> grass-user@lists.osgeo.org >>>>>> http://lists.osgeo.org/mailman/listinf
Re: [GRASS-user] Projection String I can not figure out
How about # NAD83 <4269> +proj=longlat +ellps=GRS80 +datum=NAD83 +no_defs no_defs <> ? Mark On Wed, Jul 14, 2010 at 9:19 AM, stephen sefick wrote: > GEOGCS["GCS_North_American_1983",DATUM["D_North_American_1983",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.017453292519943295]] > > This is the projection string from a shp file from the USGS national > hydrography dataset. I would like to reproject this into another > format, but I don't know exactly what proj4 definitions to use for > this to make it work... Any help would be greatly appreciated. > kindest regards, > > -- > Stephen Sefick > > | Auburn University | > | Department of Biological Sciences | > | 331 Funchess Hall | > | Auburn, Alabama | > | 36849 | > |___| > | sas0...@auburn.edu | > | http://www.auburn.edu/~sas0025 | > |___| > > Let's not spend our time and resources thinking about things that are > so little or so large that all they really do for us is puff us up and > make us feel like gods. We are mammals, and have not exhausted the > annoying little problems of being mammals. > > -K. Mullis > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Arc Binary coverages- arggg!
Much to my delight, v.in.ogr reads the binary arc coverages. I copied over the directory (which is the coverage name) and the info directory to a place on the Linux machine which has GRASS installed. (not sure if the 'info' directory is needed, but it did preserve attributes). For the OGR datasource name, I pointed it to the "arc.adf" file, and it imported the coverage as a GRASS vector with points, lines and polygon features. Attributes also preserved. Please let me know if you have any issues with this. First time I tried this, and great to know it can read the binary coverages. Mark On Mon, Jul 12, 2010 at 8:02 PM, Mark Seibel wrote: > That's what I figured. Then I am fairly sure this is what you're > after, http://grass.osgeo.org/grass64/manuals/html64_user/v.in.ogr.html. > Arc Vector coverages are stored in 2 directories. One for geometry > (the directory is the name of the coverage) and the database is > contained in an 'info' directory. The examples below are not clear to > me how it addresses this, but it does state it will do it. I could > try some testing tomorrow if not figured out by then. > > # Arc Coverage > We import the Arcs and Label points, the module takes care to build areas: > > v.in.ogr dsn=gemeinden layer=LAB,ARC type=centroid,boundary output=mymap > > > # E00 file (see also v.in.e00) > First we have to convert the E00 file to an Arc Coverage with > 'avcimport' (AVCE00 tools, use e00conv first in case that avcimport > fails): > > avcimport e00file coverage > v.in.ogr dsn=coverage layer=LAB,ARC type=centroid,boundary output=mymap > > All the best. > Mark > > On Mon, Jul 12, 2010 at 7:47 PM, stephen sefick wrote: >> Vector Coverages. >> >> On Mon, Jul 12, 2010 at 6:41 PM, Mark Seibel wrote: >>> Are these vector coverages or raster datasets? >>> >>> Mark >>> >>> On Jul 12, 2010, at 6:08 PM, stephen sefick wrote: >>> >>>> I have a couple of files that are in this format... >>>> >>>> aat.adf arx.adf dbltic.adf metadata.xml prj.adf txx.adf >>>> arc.adf dblbnd.adf log par.adf txt.adf >>>> >>>> they are arc binary data correct. Is there anyway I can use these >>>> with GRASS or QGIS? >>>> >>>> -- >>>> Stephen Sefick >>>> >>>> | Auburn University | >>>> | Department of Biological Sciences | >>>> | 331 Funchess Hall | >>>> | Auburn, Alabama | >>>> | 36849 | >>>> |___| >>>> | sas0...@auburn.edu | >>>> | http://www.auburn.edu/~sas0025 | >>>> |___| >>>> >>>> Let's not spend our time and resources thinking about things that are >>>> so little or so large that all they really do for us is puff us up and >>>> make us feel like gods. We are mammals, and have not exhausted the >>>> annoying little problems of being mammals. >>>> >>>> -K. Mullis >>>> ___ >>>> grass-user mailing list >>>> grass-user@lists.osgeo.org >>>> http://lists.osgeo.org/mailman/listinfo/grass-user >>> >> >> >> >> -- >> Stephen Sefick >> >> | Auburn University | >> | Department of Biological Sciences | >> | 331 Funchess Hall | >> | Auburn, Alabama | >> | 36849 | >> |___| >> | sas0...@auburn.edu | >> | http://www.auburn.edu/~sas0025 | >> |___| >> >> Let's not spend our time and resources thinking about things that are >> so little or so large that all they really do for us is puff us up and >> make us feel like gods. We are mammals, and have not exhausted the >> annoying little problems of being mammals. >> >> -K. Mullis >> > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Arc Binary coverages- arggg!
That's what I figured. Then I am fairly sure this is what you're after, http://grass.osgeo.org/grass64/manuals/html64_user/v.in.ogr.html. Arc Vector coverages are stored in 2 directories. One for geometry (the directory is the name of the coverage) and the database is contained in an 'info' directory. The examples below are not clear to me how it addresses this, but it does state it will do it. I could try some testing tomorrow if not figured out by then. # Arc Coverage We import the Arcs and Label points, the module takes care to build areas: v.in.ogr dsn=gemeinden layer=LAB,ARC type=centroid,boundary output=mymap # E00 file (see also v.in.e00) First we have to convert the E00 file to an Arc Coverage with 'avcimport' (AVCE00 tools, use e00conv first in case that avcimport fails): avcimport e00file coverage v.in.ogr dsn=coverage layer=LAB,ARC type=centroid,boundary output=mymap All the best. Mark On Mon, Jul 12, 2010 at 7:47 PM, stephen sefick wrote: > Vector Coverages. > > On Mon, Jul 12, 2010 at 6:41 PM, Mark Seibel wrote: >> Are these vector coverages or raster datasets? >> >> Mark >> >> On Jul 12, 2010, at 6:08 PM, stephen sefick wrote: >> >>> I have a couple of files that are in this format... >>> >>> aat.adf arx.adf dbltic.adf metadata.xml prj.adf txx.adf >>> arc.adf dblbnd.adf log par.adf txt.adf >>> >>> they are arc binary data correct. Is there anyway I can use these >>> with GRASS or QGIS? >>> >>> -- >>> Stephen Sefick >>> >>> | Auburn University | >>> | Department of Biological Sciences | >>> | 331 Funchess Hall | >>> | Auburn, Alabama | >>> | 36849 | >>> |___| >>> | sas0...@auburn.edu | >>> | http://www.auburn.edu/~sas0025 | >>> |___| >>> >>> Let's not spend our time and resources thinking about things that are >>> so little or so large that all they really do for us is puff us up and >>> make us feel like gods. We are mammals, and have not exhausted the >>> annoying little problems of being mammals. >>> >>> -K. Mullis >>> ___ >>> grass-user mailing list >>> grass-user@lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/grass-user >> > > > > -- > Stephen Sefick > > | Auburn University | > | Department of Biological Sciences | > | 331 Funchess Hall | > | Auburn, Alabama | > | 36849 | > |___| > | sas0...@auburn.edu | > | http://www.auburn.edu/~sas0025 | > |___| > > Let's not spend our time and resources thinking about things that are > so little or so large that all they really do for us is puff us up and > make us feel like gods. We are mammals, and have not exhausted the > annoying little problems of being mammals. > > -K. Mullis > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Arc Binary coverages- arggg!
Are these vector coverages or raster datasets? Mark On Jul 12, 2010, at 6:08 PM, stephen sefick wrote: I have a couple of files that are in this format... aat.adf arx.adf dbltic.adf metadata.xml prj.adf txx.adf arc.adf dblbnd.adf log par.adf txt.adf they are arc binary data correct. Is there anyway I can use these with GRASS or QGIS? -- Stephen Sefick | Auburn University | | Department of Biological Sciences | | 331 Funchess Hall | | Auburn, Alabama | | 36849| |___| | sas0...@auburn.edu | | http://www.auburn.edu/~sas0025 | |___| Let's not spend our time and resources thinking about things that are so little or so large that all they really do for us is puff us up and make us feel like gods. We are mammals, and have not exhausted the annoying little problems of being mammals. -K. Mullis ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Arc Binary coverages- arggg!
I have not used this, but this page indicates v.in.ogr can handle arc coverages. (example section, a little more than half way down). http://grass.osgeo.org/grass64/manuals/html64_user/v.in.ogr.html Apologies in advance for lack of specifics. Mark On Jul 12, 2010, at 6:08 PM, stephen sefick wrote: I have a couple of files that are in this format... aat.adf arx.adf dbltic.adf metadata.xml prj.adf txx.adf arc.adf dblbnd.adf log par.adf txt.adf they are arc binary data correct. Is there anyway I can use these with GRASS or QGIS? -- Stephen Sefick | Auburn University | | Department of Biological Sciences | | 331 Funchess Hall | | Auburn, Alabama | | 36849| |___| | sas0...@auburn.edu | | http://www.auburn.edu/~sas0025 | |___| Let's not spend our time and resources thinking about things that are so little or so large that all they really do for us is puff us up and make us feel like gods. We are mammals, and have not exhausted the annoying little problems of being mammals. -K. Mullis ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Channel Sinuosity Implemented in GRASS?
I came across this when looking previously at v.to.db. I noticed there is an option to upload line sinuosity. I haven't tried it, but I'd be curious to know if it solves your problem. Using "option = sinuous" ? http://grass.itc.it/grass64/manuals/html64_user/v.to.db.html Mark On Fri, Jul 9, 2010 at 10:24 AM, stephen sefick wrote: > All: > I would like to calculate channel sinuosity on many streams that I > have an upstream and downstream GPS point. Is there such a module in > GRASS? I am trying to avoid doing this by hand. > kindest regards, > > -- > Stephen Sefick > > | Auburn University | > | Department of Biological Sciences | > | 331 Funchess Hall | > | Auburn, Alabama | > | 36849 | > |___| > | sas0...@auburn.edu | > | http://www.auburn.edu/~sas0025 | > |___| > > Let's not spend our time and resources thinking about things that are > so little or so large that all they really do for us is puff us up and > make us feel like gods. We are mammals, and have not exhausted the > annoying little problems of being mammals. > > -K. Mullis > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: python pipe output for v.lidar.edgedetection -e
Self updating It looks like the point estimate outputs for that module go to stderr, which can be captured nicely. Mark On Thu, Jul 1, 2010 at 2:01 PM, Mark Seibel wrote: > I've been using this as a resource, > http://grass.osgeo.org/wiki/GRASS_and_Python , which has been great. > I'm just starting to get into Python and GRASS. > > I have had success with the grass.pipe_command and grass.read_command > for 'r.stats' and 'g.region -g'. > > However, when I try to get the point estimate value output (which goes > to the terminal) from the v.lidar.edgedetection module into a > variable, it is without success, as it does not put any data in the > variable. I'm looking to get the mean point distance output from this > module. the command being used is, "v.lidar.edgedetection -e > --overwrite input=points_all output=estimate see=5 sen=5 lambda_g=.01 > tgh=6 tgl=3 theta_g=.26 lambda_r=2" > > Is there anything different or particular about this lidar command, > compared to the examples from the GRASS_and_Python wiki? > > Thanks to all. > Mark > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] python pipe output for v.lidar.edgedetection -e
I've been using this as a resource, http://grass.osgeo.org/wiki/GRASS_and_Python , which has been great. I'm just starting to get into Python and GRASS. I have had success with the grass.pipe_command and grass.read_command for 'r.stats' and 'g.region -g'. However, when I try to get the point estimate value output (which goes to the terminal) from the v.lidar.edgedetection module into a variable, it is without success, as it does not put any data in the variable. I'm looking to get the mean point distance output from this module. the command being used is, "v.lidar.edgedetection -e --overwrite input=points_all output=estimate see=5 sen=5 lambda_g=.01 tgh=6 tgl=3 theta_g=.26 lambda_r=2" Is there anything different or particular about this lidar command, compared to the examples from the GRASS_and_Python wiki? Thanks to all. Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Retrieve pixel resolution using Python Script
If you use gdalinfo on an image, it will output the "Pixel Size". Hope that helps. Mark 2010/6/28 António Rocha : > Greetings > > I'm trying to retrieve an image (not yet imported to GRASS) pixel resolution > through a Python Script but so far i was unable to figure out a method to do > this. Is this possible? I have used g.proj to retrieve its projection and > datum but not the Pixel resolution. > THanks for your help > > Best regards, > Antonio R. > > > __ Information from ESET NOD32 Antivirus, version of virus signature > database 5234 (20100628) __ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Import, project
> 2) how to import+project a e00-rasterfile into the same database (containing > rasterpoints 1kmx1km, each with one scalar property) This solution may not help if ESRI software is inaccessible, but perhaps the maintainer of the .e00 data can do this conversion for you. I verified it does work (I cant locate how to import a raster .e00). The raster ascii .e00 uses different formatting than an export from ArcToolbox using "Raster to ASCII". I imported a raster .e00 in ArcToolbox to an arc/info GRID, then exported it to an ASCII file with the ArcCatalog tool "Raster to ASCII". This exported raster ASCII data can be directly imported into GRASS with the r.in.arc module. I also noticed that if you tail the last portion of the raster .e00 file ($ tail -n 50 someFile.e00), you can see the projection definition information, which helps to setup the right location in GRASS for importing. Note: you will only see the definition if a user applied the definition. Apologies in advance for a non-open source solution, but I hope can help if there are no other options. Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] LiDAR Data?
This is a great resource. http://grass.osgeo.org/wiki/LIDAR#Micro-tutorial Mark On Wed, Jun 9, 2010 at 6:14 PM, Rich Shepard wrote: > I thought that I could use LiDAR data within grass, but the 6.4 r.in.gdal > man page does not include that format. Is this the wrong module for these > data? > > There are two topographic quadrangle files that cover the project drainage > basin, and the data DVDs cost $200 each. I want to make high resolution DEMs > of the project basin and try to determine flood elevations for different > storm events from those. According to the data source, "All data are format > specific to ESRI GIS format. Data must be viewed using specialty software > capable of viewing .shp, geotif, and ESRI grid formats." > > I suppose that r.in.gdal will import the .shp files. I've not worked with > geotif or ESRI grid formats so any experiences of you folks with these > formats and LiDAR data will be much appreciated. > > Thanks, > > Rich > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.lidar.growing - rasterized step
In the v.lidar.growing manual, it mentions how double pulses are considered, "The classification categories from v.lidar.edgedetection are now rasterized." Does this use region cell size, r is it all handled behind the scenes independently? Thanks for any feedback. Mark ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
