Re: [GRASS-dev] Grass SVN in Android, display issue
Markus N wrote: PS: Maybe it is useless to run GRASS on Android but maybe not.. :) Hamish B. Wrote: on-site field data entry tool swiss army knife. Highly Agree! I can see this being very useful. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] too many branches
+1 Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Helena Mitasova hmit...@ncsu.edu Sent by: grass-dev-boun...@lists.osgeo.org 08/22/2012 07:11 PM To GRASS developers list grass-dev@lists.osgeo.org cc Markus Metz markus.metz.gisw...@gmail.com Subject Re: [GRASS-dev] too many branches After reading through the entire discussion I think even Hamish would agree that there is a broad consensus that the number of branches needs to be reduced (as I read it, it should be grass64 and grass7) and the sooner it is done, the fewer problems and confusion there will be. It should also make it easier to test (I have 4 versions 6.4.2, 6.4.3, 6.5, 7.0 on my machine and to be honest, I am not sure what works in which version, but lately I have been using GRASS7 a lot so a release in near future would be welcome). Helena Helena Mitasova Associate Professor Department of Marine, Earth, and Atmospheric Sciences 2800 Faucette Drive, Rm. 1125 Jordan Hall North Carolina State University Raleigh, NC 27695-8208 hmit...@ncsu.edu All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.” On Aug 22, 2012, at 3:57 AM, Markus Metz wrote: Hi all, even the GRASS website [0] gets confused about all those branches. GRASS 6.4.3, the next stable release, is currently hidden under GRASS 6.4.2, current stable. Therefore there should be 4, not 3 sections: 6.4.2, 6.4.3, 6.5, 7.0. This is however IMHO too much, confusing for users and a maintenance burden for developers. The purpose of the existence of 6.5 is not clear to me, particularly since it is pretty much identical to 6.4.3. Using 6.5 as testbed for backporting does not make sense to me, I would prefer to use the current releasebranch as testbed for backporting (higher quality, hopefully, and faster bug fixing). IMHO, it would make maintenance much easier if one of 6.4 and 6.5 would go rather sooner than later. Markus M [0] http://grass.osgeo.org/download/software.php ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Proposal for setting up of new locations in wxGUI
I like it. It saves a step. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Markus Neteler nete...@osgeo.org Sent by: grass-dev-boun...@lists.osgeo.org 08/16/2012 10:56 AM To GRASS developers list grass-dev@lists.osgeo.org cc Subject [GRASS-dev] Proposal for setting up of new locations in wxGUI Hi, I would like to suggest a modification (even for G6) for the Location Wizard: When defining a new location from an existing dataset (like SHAPE or GeoTIFF with proper metadata), it creates the location and then brings you back to the original startup screen, then you can login into GRASS. But.. no maps there. So (new) users will be confused. Change proposal: Before reaching the startup screen again, ask if to import the map which has been used for creating the location. Yes: do it; no: return to startup screen. What do you think? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] limits of r.patch
Margherita, You may be running into the open file limit for linux. http://www.cyberciti.biz/faq/linux-increase-the-maximum-number-of-open-files/ , although 1573 files seems a bit low.I generally batch my r.patch'ing in groups of 120 or so with a python script , then go back and r.patch the results. It works well if the file names are related to the file locations. See ugly python script below where elevation grid data with the temp_grid tiles were named by the x coordinate were patched together ( yes, I know you can do this better now with direct python calls to grass:-)): # grass_tile_merge.py import os,string,re,glob grdarr=['D2370','D2371','d2371','d2372','D2372','D2373'] for grdarrlist in grdarr: gtarr=['0','1','2','3','4','5','6','7','8','9'] for gtarrl in gtarr: gtarrb=['0','1','2','3','4','5','6','7','8','9'] for gtarrl2 in gtarrb: gtarrc=['0','1','2','3','4','5','6','7','8','9'] for gtarrl3 in gtarrc: grdstr= gtemp=temp_+grdarrlist+gtarrl+gtarrl2+gtarrl3 #print grpitem greplist=/imagery/grass/ncstpftlidar_83/newdem/fcell/+grdarrlist+gtarrl+gtarrl2+gtarrl3+*_ras grdlist=glob.glob(greplist) # creates a list of those grid files for t1 in grdlist: t1base=os.path.basename(t1) grdstr=grdstr+t1base+, #grdarr.append(t1base) grdstr=grdstr[:-1] print grdstr regtite=g.region rast=%s%(grdstr) os.system(regtite) patchgrp=r.patch input=%s output=%s%(grdstr,gtemp) print patchgrp os.system(patchgrp) #http://grass.fbk.eu/grass64/manuals/html64_user/r.patch.html Hope this helps. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Margherita Di Leo dileomargher...@gmail.com Sent by: grass-dev-boun...@lists.osgeo.org 07/13/2012 11:27 AM To grass-dev@lists.osgeo.org cc Subject [GRASS-dev] limits of r.patch Hi All, I probably am requiring too much, but this is just for sharing an experience. I've just imported in GRASS 1573 ASTER GDEM tiles, using r.external, and everything seemed to be OK. Then I ran: GRASS 6.4.3svn (ASTER_GDEM):~ r.patch in=`g.mlist pat=AST* sep=,` out=aster_gdem ERROR 1: TIFFOpen:/forest/ASTER-GDEM/Dem_lzw/ASTGTM_N45E010_dem_lzw.tif: Too many open files WARNING: Unable to open raster map ASTGTM_N45E011_dem_lzw.tif@PERMANENT ERROR: One or more input raster maps not found I'm on Red Hat Enterprise Linux Server Rel. 6.3, RAM 16 GB. Cheers, -- Dr. Margherita Di Leo ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] reducing screen clutter
So long as this does not impair my ability to process the same command for multiple data layers in multiple ways simultaneously. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. -grass-dev-boun...@lists.osgeo.org wrote: - To: GRASS developers grass-developers grass-dev@lists.osgeo.org From: Michael Barton michael.bar...@asu.edu Sent by: grass-dev-boun...@lists.osgeo.org Date: 05/24/2012 05:19AM Subject: [GRASS-dev] reducing screen clutter Periodically, there are complaints about 'screen clutter' with GRASS. I realized yesterday that a big cause of this is that each time a module is called, a new instance of its dialog opens. So if you use v.buffer but don't close the dialog, and then call v.buffer again GRASS opens a second v.buffer dialog...and a third and a fourth, etc. So there seems to be the need to have the wxPython parser module to just bring the window for a module to the front if it is already open instead of opening another instance. Sounds simple but is probably somewhat complicated of course. But it would help the clutter problem a great deal. Michael _ C. Michael Barton Visiting Scientist, Integrated Science Program National Center for Atmospheric Research University Consortium for Atmospheric Research 303-497-2889 (voice) Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Problem with new GRASS installation on MAC OSX Lion
Hi Folks, I 've been in contact with a potential new user of GRASS is running OSX Lion. He has freshly installed the frameworks GRASS and then QGIS ( in that order, all downloaded today) . When he starts GRASS , he gets a small window that says Applescript Error Terminal got an error : Can't get window 1. (-1728). If the user starts QGIS first, then GRASS will start normally. Anything obvious occur to folks before diving in further? Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.series and r.series.interpol
Sea surface temps from satellite imagery to try to account for cloudy days? Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Thomas Adams thomas.ad...@noaa.gov Sent by: grass-dev-boun...@lists.osgeo.org 12/30/2011 10:35 AM To Sören Gebbert soerengebb...@googlemail.com cc GRASS developers list grass-dev@lists.osgeo.org Subject Re: [GRASS-dev] r.series and r.series.interpol Sören, This is very interesting -- I think I may have an immediate application for these modules... Best to you in 2012 and thank you for your development activities! Regards, Tom 2011/12/30 Sören Gebbert soerengebb...@googlemail.com Dear all, just for your information. I have added a new option to r.series to specify a weighting factor to each map in a series. Weighting is needed to aggregate overlapping/containing interval time series correctly in case of average and sum operations. The new temporal modules tr.aggregate and tr.aggregate.ds need this option. Furthermore i have added a new module (r.series.interpol) to interpolate raster map series located temporal or spatial in between existing raster maps. This module is still under development and implements currently only simple linear interpolation in a normalized interval. I plan to implement step-wise linear interpolation[1] and natural cubic spline interpolation[2]. Because of the large amount of files related to the unit and regression tests located in the modules directory, we should use a dedicated one. Hence, i will move successively all files related to testing into new directories named test located in the module directories. Best regards and happy new year 2012 Soeren [1] http://en.wikipedia.org/wiki/Interpolation#Linear_interpolation [2] http://en.wikipedia.org/wiki/Spline_interpolation ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Thomas E Adams National Weather Service Ohio River Forecast Center 1901 South State Route 134 Wilmington, OH 45177 EMAIL: thomas.ad...@noaa.gov VOICE: 937-383-0528 FAX: 937-383-0033 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] FDCC standards for US government computers
Hi Folks, Apologies to the Windows dev folks for not posting these earlier. Here are the links to the Federal Desktop Core Configuration guidelines ( mandatory for US federal government computers using Windows XP and Vista. I think Win 7 is still in the pipe ) for secure desktop computing. http://nvd.nist.gov/fdcc/index.cfm http://nvd.nist.gov/fdcc/download_fdcc.cfm Main things to remember, 1) application does not require administrative access to run. 2) application does not use system directories( i.e. Windows or Program Files) for user data/ temp files. Sorry if this is redundant information. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] export question
You could try r.out.xyz for each layer , then join the columns . http://grass.fbk.eu/grass64/manuals/html64_user/r.out.xyz.html Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. sarthakahuja sarthakah...@gmail.com Sent by: grass-dev-boun...@lists.osgeo.org 09/09/2011 03:37 PM To grass-dev@lists.osgeo.org cc Subject [GRASS-dev] export question I am trying to export an image to an excel file having lat, long, rgb values for all the points on the image. Does anyone know where I should look, have some idea...any help would be greatly appreciated -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/export-question-tp6777072p6777072.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] where to store GRASS settings: GISRC and wx settings
I am using 6.5 for some work, but I can easily move to 6.4 or 7 , depending on the project. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Markus Neteler nete...@osgeo.org Sent by: grass-dev-boun...@lists.osgeo.org 08/31/2011 03:13 AM To Markus Metz markus.metz.gisw...@googlemail.com cc GRASS developers list grass-dev@lists.osgeo.org Subject Re: [GRASS-dev] where to store GRASS settings: GISRC and wx settings On Wed, Aug 31, 2011 at 9:02 AM, Markus Metz markus.metz.gisw...@googlemail.com wrote: Glynn Clements wrote: Personally, I'd just kill the 6.5 branch. If something is too major to go into 6.4.x, it should be reserved for 7.0. +1 I am also not quite sure about the need of the 6.5 branch? For me it is sufficient to have 6.4 as production system and 7 as experimental system. Honestly, who's *using* it as a user? Because: yes, it can (could?) be branch to be used for testing but I actually don't know anyone who really uses 6.5 for work. Please tell us if you use 6.5 for work to understand if this branch is really needed. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] R.terraflow on massive grids
Markus Metz markus.metz.gisw...@googlemail.com 08/15/2011 06:28 AM To doug_newc...@fws.gov cc grass-dev@lists.osgeo.org Subject Re: [GRASS-dev] R.terraflow on massive grids doug_newc...@fws.gov wrote: Hi Folks, I have an fcell grid of elevations for the state of North Carolina (51000 rows 133000 columns 678300 cells) . I tried to run r.terraflow in GRASS7 ( 8/8/2011 svn snapshot) and ran into the dimension limits. So I patched them according to Glynn's email , http://www.osgeo.org/pipermail/grass-user/2004-February/024722.html and tried again ( Would it be better to change the dimension variable to int instead of short int?) . This time my Streams file builds to about 26 GB and then r.terraflow bombs with : MFD flow direction D8CUT=99986991104.00 Memory size: 808.00M (847249408) bytes Memory manager registering memory in MM_IGNORE_MEMORY_EXCEEDED mode. r.terraflow: grass2str.h:145: AMI_STREAMT* cell2stream(char*, elevation_type, long int*) [with T = float, elevation_type = float]: Assertion `nrows * ncols == str-stream_len()' failed. The memory size is interesting, because I'm giving it 8GB of RAM out of 16 GB in the command. Note that the memory manager of the iostream lib used by r.terraflow can only handle up to 2047 MB of RAM because the memory option in MB is internally converted to Byte and stored as int, thus the max recognized value is 2^31 - 1 Byte. Markus M This appears to be kind of like pulling on a corner of a spiderweb. :-) Should the limit to memory be indicated in the gui? Would there be any benefit to other parts of GRASS in bumping up this memory limit? I can see the reason on 32 bit windows XP, but that is starting to go away. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] R.terraflow on massive grids
Hi Folks, I have an fcell grid of elevations for the state of North Carolina (51000 rows 133000 columns 678300 cells) . I tried to run r.terraflow in GRASS7 ( 8/8/2011 svn snapshot) and ran into the dimension limits. So I patched them according to Glynn's email , http://www.osgeo.org/pipermail/grass-user/2004-February/024722.html and tried again ( Would it be better to change the dimension variable to int instead of short int?) . This time my Streams file builds to about 26 GB and then r.terraflow bombs with : MFD flow direction D8CUT=99986991104.00 Memory size: 808.00M (847249408) bytes Memory manager registering memory in MM_IGNORE_MEMORY_EXCEEDED mode. r.terraflow: grass2str.h:145: AMI_STREAMT* cell2stream(char*, elevation_type, long int*) [with T = float, elevation_type = float]: Assertion `nrows * ncols == str-stream_len()' failed. The memory size is interesting, because I'm giving it 8GB of RAM out of 16 GB in the command. The temp directory has about 900GB of space, so it has plenty of room . The box is 64 bit Ubuntu 11.04 related to ? http://trac.osgeo.org/grass/ticket/1006 I can run it again in verbose mode when I get home tonight. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Fw: r.sun at a landscape scale
Hi folks, Just forwarding the conversation to add to the record. Doug - Forwarded by Doug Newcomb/R4/FWS/DOI on 07/27/2011 09:23 AM - Doug Newcomb newcomb@gmail.com 04/29/2011 09:15 AM To Doug Newcomb doug_newc...@fws.gov cc Subject Fwd: Re: r.sun at a landscape scale Original Message Subject: Re: r.sun at a landscape scale Date: Tue, 26 Apr 2011 01:16:05 -0700 (PDT) From: Hamish hamis...@yahoo.com To: Doug Newcomb newcomb@gmail.com Hi Doug, Contacting you from the home email. Work webmail non-functional. If you recall the 60ft canopy height layer I created for the state of North Carolina, I've been using that canopy height layer as a base elevation layer for calculating total global solar irradiation for a 60ft grid for the state of north carolina. I have created slope and aspect layers, as well as r.horizon layers at 8 45 degree increments starting at 0 ( East) and going counter-clockwise. I left the albedo and linke options at the defaults. I have calculated the global solar irradiation for all 365 days using these parameters. After a number of tests (see below), I'm of the opinion that the pre-made slope, aspect, lat, lon, and r.horizon maps are either no faster, or introduce such inaccuracies as to be not worth the trouble. In particular I question the usefulness of r.horizon maps: the sun is in a slightly different place on the compass each morning, and the overhead of keeping/loading 360 horizon maps is more than just recalculating it on the fly (and on the fly you get the exact value, not a nearby estimate). Also, having 360 starting r.horizons limits you to 1 degree precision. I value accuracy over processing time (I'm happy to wait a week for an answer if I know the model setup is good), so take with that grain of salt. So I like to use step=0.05 instead of the default step=0.5 even though it takes 10 times longer. I would like to sharpen the accuracy of the calculations by creating grid layers of the linke turbulence similar to how you do it in your python script. My efforts seem to be complicated by the landscape approach I have taken, which includes calculations in coastal plain, piedmont, and mountain areas which have a mixture of urban and rural land uses. I've been to the helioclim http://www.helioclim.net/linke/index.html and and soda http://www.soda-is.com/eng/services/climat_free_eng.php#climatCielClair web sites to try to get more exact estimates on the linke turbulence, but the best they can do is monthly estimates at 5 arc second resolution . Perhaps I want too much :-) for me the Soda linke DB wasn't too useful, AFAIU it's rather elevation dependent and I'm modeling light in fjords with 1000m vertical cliff faces.. their spatial elevation model resolution was just too coarse for me. what we did instead was to pick at each model point (~1 deg) for each month, and then use v.surf.rst to make an interpolated linke map from those. I'm not sure if 5 arc-sec data was available then, or if that was just a reinterpolation from a coarser grid so we ignored it..? I suppose for each position you could uncomment the couple of lines at the bottom of the linke month-day interpolation python script which gives the full year's worth of linkie values, and use the collection of those to make 365 v.surf.rst linkie coverage maps. ? you could also mix and match mountainous and urban values that way. In any event, my thought was to try to take the global monthly estimate tifs, georeference them and pull them into grass. Chop out the NC areas and reproject them into the same workspace as the canopy height data. Take the monthly values as the mid month values and interpolate to 365 days and use those calculations as the basis for the linke turbulence input to calculation. Does that seem like a reasonable approach to you? currently r.series doesn't support linear interpolation extractions, I suppose something could be whipped together using r.mapcalc's graph() linear interpolation, maybe hack that to do cubic interpolations too? BtW, how much does it speed things up to have a lat and long layers in the input? I don't think by much at all, maybe a few percent, at the risk of user error. read through: https://trac.osgeo.org/grass/ticket/498 and http://grass.osgeo.org/wiki/r.sun If you have a new graphics card you can vastly speed it up by using Seth's GPU version: http://grass.osgeo.org/wiki/R.sun#OpenCL (which I still need to work on merging into trunk) Seth wrote: The OpenCL version of r.sun runs over 20x faster than the original version on my machine (2.26 GHz Mac Pro vs. GeForce GTX 285). However, it is hampered by the low memory on your GPU, so you may need to partition your raster. Just some performance fyi, running the r.sun analysis in 1 chunk (n=1) takes about 4 hours and requires about 16 GB of RAM. running a calculation in 8 chunks (n=8) knocks
Re: [GRASS-dev] check out GIS on iOS
On Thu, Jul 21, 2011 at 03:21, Helena Mitasova hmit...@ncsu.edu wrote: Michael, all that may be needed is to be able to run GRASS on-line - there have been several projects for that already. Yes, we had once a GRASSLinks server, nicely working... See also here: http://grass.osgeo.org/start.html Of course the modern way is: http://grass.osgeo.org/wiki/WPS Markus Neteler said I just realized that there is www.gapserve.ncsu.edu/segap/segap biodiversity website that is running GRASS for some of its operations Helena, how do you know that? I would be happy to see GRASS mentioned there... I helped them set up the initial Linux box with GRASS. They have come a long way since then. I'll mention the WPS option to them , as well as mentioning GRASS :-) . Last I chatted with them, they were also looking at the new raster functionality in PostGIS, as well. Doug ... I am wondering whether we have links to webGIS sites running GRASS - I did not find anything on the GRASS website but I might have missed it, Here it is: http://grass.osgeo.org/wiki/Applications Markus Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Markus Neteler nete...@osgeo.org Sent by: grass-dev-boun...@lists.osgeo.org 07/21/2011 04:23 AM To Helena Mitasova hmit...@ncsu.edu cc Michael Barton michael.bar...@asu.edu, GRASS developers list grass-dev@lists.osgeo.org, Thomas Adams thomas.ad...@noaa.gov Subject Re: [GRASS-dev] check out GIS on iOS I just realized that there is www.gapserve.ncsu.edu/segap/segap biodiversity website that is running GRASS for some of its operations Helena, how do you know that? I would be happy to see GRASS mentioned there... ... I am wondering whether we have links to webGIS sites running GRASS - I did not find anything on the GRASS website but I might have missed it, Here it is: http://grass.osgeo.org/wiki/Applications Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Segmentation fault using v.in.lidar
Pierre, I think the main issue with doing *.las would be that although LAS data is coming in tiled but is also available as overlapping swaths. I imagine to impliment the option for multiple las files you would need to build an internal index of the footprint of each input las file that tells r.in.lidar and v.in.lidar which file(s) to draw the input las data from to create the output. In the case of r.in.lidar, you would need to specify which files to simultaneously open to gather the point values to calculate the statistics that are the value of the output cell. You would need something like the way gdaltindex builds a polygon shape file from a list of input georeferenced images. ( Now if I only had some skill with C to throw together some code :-( ) In the short term, use the las2las command from liblas.org to merge your .las files into a single las file and then process the one file. You will have to watch out for the 4 billion point limit that is currently in the LAS file format, but for most folks that's not an issue. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Pierre Roudier pierre.roud...@gmail.com Sent by: grass-dev-boun...@lists.osgeo.org 07/13/2011 03:05 AM To Markus Metz markus.metz.gisw...@googlemail.com cc grass-dev grass-dev@lists.osgeo.org Subject Re: [GRASS-dev] Segmentation fault using v.in.lidar Thanks for the quick answer Markus, That would be a nice feature to add though. A lot of the LAS files are coming tiled, and it'd be nice to be able to do something like: v.in.lidar in=*.las out=test_input_lidar -trb or v.in.lidar in=zone_32_*.las out=test_input_lidar -trb to import a special subset of LAS files. I've very few coding abilities, so this is just meant as another line on the wishlist ;) Thanks heaps for your work on *.in.lidar, it is working well otherwise, Pierre 2011/7/13 Markus Metz markus.metz.gisw...@googlemail.com: On Wed, Jul 13, 2011 at 2:08 AM, Pierre Roudier pierre.roud...@gmail.com wrote: Hi, I've been trying to use v.in.lidar. It yields good results on one LAS file, but I get a segfault when trying it on several files: v.in.lidar in=BD32_1610.las,BD32_1611.las out=test_input_lidar -trb Segmentation fault v.in.lidar in=BD32_161*.las out=test_input_lidar -trb Segmentation fault Am I missing something, or is it a bug? v.in.lidar takes only one input file at a time. Markus M -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 7 vector topology format changed
The new format offers new possibilities for the v.surf.* modules because it is now possible to build (parts of the) topology even for massive point clouds which in turn makes it possible to quickly perform spatial queries with very low memory consumption (a very few MB) Markus, By massive point clouds, do you mean greater than 4 Billion points? A good long weekend for testing at home :-) Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [Liblas-devel] Re: [GRASS-dev] grass7: problem --with-liblas
It worked fine for me last night compiling with the last weekly ( 6-18-11) svn snapshot for grass 7.0, I'll poke it a bit more tomorrow. I'll need to make some bigger files to test the speed. :-) Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Howard Butler hobu@gmail.com 06/22/2011 12:57 PM To doug_newc...@fws.gov cc Markus Metz markus.metz.gisw...@googlemail.com, grass-dev@lists.osgeo.org, liblas-de...@lists.osgeo.org Subject Re: [Liblas-devel] Re: [GRASS-dev] grass7: problem --with-liblas Doug, I think I have this one smashed. http://trac.liblas.org/ticket/231 It will be released in libLAS 1.7.0. If you have the ability to pull down a copy of the hg version http://hg.liblas.org/main/archive/tip.tar.gz and test, I'd appreciate it. Also, it should be much, much faster for medium-to-large sized files. http://hg.liblas.org/main/archive/tip.tar.gz Howard On Jun 13, 2011, at 11:45 AM, doug_newc...@fws.gov wrote: Hi Folks, Glynn's suggested hack to liblas-config below to work around the issue in cmake allowed me to compile grass7 with liblas support over the weekend on Ubuntu 11.04 x64. I have not read any las files yet to see if it actaully worked :-) , hopefully tonight I'll get a chance. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Markus Metz markus.metz.gisw...@googlemail.com Sent by: grass-dev-boun...@lists.osgeo.org 06/01/2011 03:21 AM To Glynn Clements gl...@gclements.plus.com cc Martin Landa landa.mar...@gmail.com, GRASS developers list liblas-de...@lists.osgeo.org Subject Re: [GRASS-dev] grass7: problem --with-liblas On Tue, May 31, 2011 at 11:34 PM, Glynn Clements gl...@gclements.plus.com wrote: Markus Metz wrote: Is this optimized; and ;debug; now a problem of GRASS or of libLAS? libLAS. Although it / be an issue with CMake's FindBoost module (search for optimized in FindBoost.cmake). This seems to be a bug in cmake 2.8.4, not present in cmake 2.8.2. I just updated cmake from 2.8.2 to 2.8.4 and now get the same problem. Or the syntax in liblas-config.in is wrong. I suggest to hack liblas-config and replace the offending line LIBS=-L$libdir -llas -llas_c -L/usr/lib optimized;/usr/lib/libboost_program_options-mt-1_42.so;debug;/usr/lib/libboost_program_options-mt.so with LIBS=-L$libdir -llas -llas_c -L/usr/lib /usr/lib/libboost_program_options-mt.so or LIBS=-L$libdir -llas -llas_c -L/usr/lib64 /usr/lib64/libboost_program_options-mt.so BTW, what version of libLAS are you using? I'm using the libLAS-1.6.1 source package: $ ls -l libLAS-* -rw-r--r-- 1 glynn root 7817956 May 30 18:49 libLAS-1.6.1.tar.gz $ md5sum libLAS-* 2ce4f36f267c2f25bfc99c3f00e9cbd3 libLAS-1.6.1.tar.gz -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ Liblas-devel mailing list liblas-de...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/liblas-devel ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [Liblas-devel] Re: [GRASS-dev] grass7: problem --with-liblas
Howard, I'll try to look at it tonight. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Howard Butler hobu@gmail.com Sent by: liblas-devel-boun...@lists.osgeo.org 06/22/2011 12:57 PM To doug_newc...@fws.gov cc Markus Metz markus.metz.gisw...@googlemail.com, grass-dev@lists.osgeo.org, liblas-de...@lists.osgeo.org Subject Re: [Liblas-devel] Re: [GRASS-dev] grass7: problem --with-liblas Doug, I think I have this one smashed. http://trac.liblas.org/ticket/231 It will be released in libLAS 1.7.0. If you have the ability to pull down a copy of the hg version http://hg.liblas.org/main/archive/tip.tar.gz and test, I'd appreciate it. Also, it should be much, much faster for medium-to-large sized files. http://hg.liblas.org/main/archive/tip.tar.gz Howard On Jun 13, 2011, at 11:45 AM, doug_newc...@fws.gov wrote: Hi Folks, Glynn's suggested hack to liblas-config below to work around the issue in cmake allowed me to compile grass7 with liblas support over the weekend on Ubuntu 11.04 x64. I have not read any las files yet to see if it actaully worked :-) , hopefully tonight I'll get a chance. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Markus Metz markus.metz.gisw...@googlemail.com Sent by: grass-dev-boun...@lists.osgeo.org 06/01/2011 03:21 AM To Glynn Clements gl...@gclements.plus.com cc Martin Landa landa.mar...@gmail.com, GRASS developers list liblas-de...@lists.osgeo.org Subject Re: [GRASS-dev] grass7: problem --with-liblas On Tue, May 31, 2011 at 11:34 PM, Glynn Clements gl...@gclements.plus.com wrote: Markus Metz wrote: Is this optimized; and ;debug; now a problem of GRASS or of libLAS? libLAS. Although it / be an issue with CMake's FindBoost module (search for optimized in FindBoost.cmake). This seems to be a bug in cmake 2.8.4, not present in cmake 2.8.2. I just updated cmake from 2.8.2 to 2.8.4 and now get the same problem. Or the syntax in liblas-config.in is wrong. I suggest to hack liblas-config and replace the offending line LIBS=-L$libdir -llas -llas_c -L/usr/lib optimized;/usr/lib/libboost_program_options-mt-1_42.so;debug;/usr/lib/libboost_program_options-mt.so with LIBS=-L$libdir -llas -llas_c -L/usr/lib /usr/lib/libboost_program_options-mt.so or LIBS=-L$libdir -llas -llas_c -L/usr/lib64 /usr/lib64/libboost_program_options-mt.so BTW, what version of libLAS are you using? I'm using the libLAS-1.6.1 source package: $ ls -l libLAS-* -rw-r--r-- 1 glynn root 7817956 May 30 18:49 libLAS-1.6.1.tar.gz $ md5sum libLAS-* 2ce4f36f267c2f25bfc99c3f00e9cbd3 libLAS-1.6.1.tar.gz -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ Liblas-devel mailing list liblas-de...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/liblas-devel ___ Liblas-devel mailing list liblas-de...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/liblas-devel ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass7: problem --with-liblas
Hi Folks, Glynn's suggested hack to liblas-config below to work around the issue in cmake allowed me to compile grass7 with liblas support over the weekend on Ubuntu 11.04 x64. I have not read any las files yet to see if it actaully worked :-) , hopefully tonight I'll get a chance. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Markus Metz markus.metz.gisw...@googlemail.com Sent by: grass-dev-boun...@lists.osgeo.org 06/01/2011 03:21 AM To Glynn Clements gl...@gclements.plus.com cc Martin Landa landa.mar...@gmail.com, GRASS developers list liblas-de...@lists.osgeo.org Subject Re: [GRASS-dev] grass7: problem --with-liblas On Tue, May 31, 2011 at 11:34 PM, Glynn Clements gl...@gclements.plus.com wrote: Markus Metz wrote: Is this optimized; and ;debug; now a problem of GRASS or of libLAS? libLAS. Although it / be an issue with CMake's FindBoost module (search for optimized in FindBoost.cmake). This seems to be a bug in cmake 2.8.4, not present in cmake 2.8.2. I just updated cmake from 2.8.2 to 2.8.4 and now get the same problem. Or the syntax in liblas-config.in is wrong. I suggest to hack liblas-config and replace the offending line LIBS=-L$libdir -llas -llas_c -L/usr/lib optimized;/usr/lib/libboost_program_options-mt-1_42.so;debug;/usr/lib/libboost_program_options-mt.so with LIBS=-L$libdir -llas -llas_c -L/usr/lib /usr/lib/libboost_program_options-mt.so or LIBS=-L$libdir -llas -llas_c -L/usr/lib64 /usr/lib64/libboost_program_options-mt.so BTW, what version of libLAS are you using? I'm using the libLAS-1.6.1 source package: $ ls -l libLAS-* -rw-r--r-- 1 glynn root 7817956 May 30 18:49 libLAS-1.6.1.tar.gz $ md5sum libLAS-* 2ce4f36f267c2f25bfc99c3f00e9cbd3 libLAS-1.6.1.tar.gz -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] ] LiDAR LAS import - filter on import?
Markus,
Were you planning on adding filtering options by return number on
v.in.lidar? It occurs to me that you could speed things up by only
processing the subset of the data that you want to use. I could see it
being a useful thing to create a vector layer composed only of 1st returns
( top of canopy/buildings) Selecting only last returns is useful, as well
as selecting points that are neither first nor last returns .
I've been primarily working with aggregate las files that I have
dumped to text ( via liblas las2txt ) and then parse via python for
first, middle, and last returns. I have not taken the time to learn C
yet, but perhaps the logic of these simple python programs would be useful
.
The following is the python script I use to separate the last returns.
-
import struct,os,string,re,binascii,glob
infile = raw_input(Enter the aggregate lidar filename: )
outfil = raw_input(Enter the ASCII output filename for the Lidar Data: )
intxt=open(infile,'r')
outtxt=open(outfil,'w')
while 1:
lasline=intxt.readline()
lasinfo=lasline.split(',')
if (len(lasinfo)) 5:break
numreturns=int(lasinfo[4])
returnnum=int(lasinfo[5])
# In the data input file for this instance, the number of returns
# is the fifth column, and the return number is the sixth column (
x=1,y=2,z=3,intensity=4).
# If the value of these colums is equal, it should be the last return.
if ( numreturns==returnnum):
outtxt.write(lasline)
intxt.close()
outtxt.close()
For parsing the first returns, substitute if (returnnum==1):
Here is the python script I use to separate out the middle returns.
---
import struct,os,string,re,binascii,glob
infile = raw_input(Enter the aggregate lidar filename: )
outfil = raw_input(Enter the ASCII output filename for the Lidar Data: )
intxt=open(infile,'r')
outtxt=open(outfil,'w')
while 1:
lasline=intxt.readline()
lasinfo=lasline.split(',')
if (len(lasinfo)) 5:break
numreturns=int(lasinfo[4])
returnnum=int(lasinfo[5])
# In the data input file for this instance, the number of returns
# is the fifth column, and the return number is the sixth column (
x=1,y=2,z=3,intensity=4).
# If the value of these colums is equal, it should be the last return,
so skip that entry
# If the return number is 1 , skip that value. All other values are
middle canopy values,which is what we want.
if ( numreturns==returnnum): continue
if (returnnum==1):continue
outtxt.write(lasline)
intxt.close()
outtxt.close()
--
I really appreciate your adding lidar data classifications from the
standard into the program. I haven't actually seen any lidar data with
classifications yet, but I have hope for the future :-).
As a bit of background , I'm taking the last returns and then running
r.in.xyz to create a raster with the intensities as the z values to get
relative soil moistures, and looking at points that are neither first nor
last returns as a possible measure of vegetation density. It works great
for large datasets( 4 billion points) , but I'm feeling the need for
more point analysis.
Doug
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-
The opinions I express are my own and are not representative of the
official policy of the U.S.Fish and Wildlife Service or Dept. of the
Interior. Life is too short for undocumented, proprietary data formats.
Markus Metz markus.metz.gisw...@googlemail.com
Sent by: grass-dev-boun...@lists.osgeo.org
06/03/2011 02:20 AM
To
Hamish hamis...@yahoo.com
cc
GRASS developers list grass-dev@lists.osgeo.org
Subject
[GRASS-dev] Re: [GRASS-user] LiDAR LAS import
Hamish wrote:
Markus Metz wrote:
[snip]
v.in.lidar is a notch faster than las2txt | v.in.ascii. And
easier to use...
I'm not too surprised the speed difference is not so huge, as
unix pipes are very efficient. but the easier to use thing is
very important.. both las2txt and v.in.ascii are a bundle of
command line switches to get right.
Speed comparisons:
# sample las file with 1,287,775 points
# with table and topology
...
real6m34.430s
...
real6m13.823s
...
# without table, with topology
...
real1m53.578s
...
real1m44.876s
I take it that without topology it runs in just seconds?
Update: no attribute table, no topology
time las2txt -i
Re: [GRASS-dev] ] LiDAR LAS import - filter on import?
Markus,
Were you planning on adding filtering options by return number
on v.in.lidar? It occurs to me that you could speed things up by only
processing the subset of the data that you want to use. I could see it
being a useful thing to create a vector layer composed only of 1st returns
( top of canopy/buildings) Selecting only last returns is useful, as well
as selecting points that are neither first nor last returns .
Yes, I was thinking of such filter options, they would be very easy and
straightforward to implement, something like v.in.lidar
returns=[all,first,last,middle]. Currently there is only spatial
filtering available.
Excellent!
I was also thinking about an option to select columns to be imported as
attributes, equivalent to the las2txt --parse option, but could not yet
come up with a user-friendly solution: flags don't work because too many
and conflicting with existing flags, a parse option very much like the one
of las2txt is too cryptic. I think I will settle for something like
v.in.lidar attributes=coords,classes,color,egde,angle,return,nreturns,...
where the attributes option takes none, one or multiple answers
Sounds good. That would have the advantage of standardizing the lidar
attibute names for future lidar point processing modules in GRASS
Markus M
Doug
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-
The opinions I express are my own and are not representative of the
official policy of the U.S.Fish and Wildlife Service or Dept. of the
Interior. Life is too short for undocumented, proprietary data formats.
Markus Metz markus.metz.gisw...@googlemail.com
06/03/2011 10:36 AM
To
doug_newc...@fws.gov
cc
GRASS developers list grass-dev@lists.osgeo.org
Subject
Re: [GRASS-dev] ] LiDAR LAS import - filter on import?
On Fri, Jun 3, 2011 at 3:30 PM, doug_newc...@fws.gov wrote:
Markus,
Were you planning on adding filtering options by return number on
v.in.lidar? It occurs to me that you could speed things up by only
processing the subset of the data that you want to use. I could see it
being a useful thing to create a vector layer composed only of 1st returns
( top of canopy/buildings) Selecting only last returns is useful, as well
as selecting points that are neither first nor last returns .
Yes, I was thinking of such filter options, they would be very easy and
straightforward to implement, something like v.in.lidar
returns=[all,first,last,middle]. Currently there is only spatial filtering
available.
I was also thinking about an option to select columns to be imported as
attributes, equivalent to the las2txt --parse option, but could not yet
come up with a user-friendly solution: flags don't work because too many
and conflicting with existing flags, a parse option very much like the one
of las2txt is too cryptic. I think I will settle for something like
v.in.lidar attributes=coords,classes,color,egde,angle,return,nreturns,...
where the attributes option takes none, one or multiple answers
Markus M
I've been primarily working with aggregate las files that I have
dumped to text ( via liblas las2txt ) and then parse via python for
first, middle, and last returns. I have not taken the time to learn C
yet, but perhaps the logic of these simple python programs would be useful
.
The following is the python script I use to separate the last returns.
-
import struct,os,string,re,binascii,glob
infile = raw_input(Enter the aggregate lidar filename: )
outfil = raw_input(Enter the ASCII output filename for the Lidar Data:
)
intxt=open(infile,'r')
outtxt=open(outfil,'w')
while 1:
lasline=intxt.readline()
lasinfo=lasline.split(',')
if (len(lasinfo)) 5:break
numreturns=int(lasinfo[4])
returnnum=int(lasinfo[5])
# In the data input file for this instance, the number of returns
# is the fifth column, and the return number is the sixth column (
x=1,y=2,z=3,intensity=4).
# If the value of these colums is equal, it should be the last return.
if ( numreturns==returnnum):
outtxt.write(lasline)
intxt.close()
outtxt.close()
For parsing the first returns, substitute if (returnnum==1):
Here is the python script I use to separate out the middle returns.
---
import struct,os,string,re,binascii,glob
infile = raw_input(Enter the aggregate lidar filename: )
outfil = raw_input(Enter the ASCII output filename for the Lidar Data:
Re: [GRASS-dev] LiDAR LAS import
Yes Thank you Markus! Since you are using liblas 1.6.1 , I assume that this command can read the losslessly compressed .laz format? Will try soon. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Markus Metz markus.metz.gisw...@googlemail.com Sent by: grass-dev-boun...@lists.osgeo.org 05/25/2011 05:31 AM To grass-user grass-u...@lists.osgeo.org, GRASS developers list grass-dev@lists.osgeo.org cc Subject [GRASS-dev] LiDAR LAS import Hi all, GRASS 7 has a new module v.in.lidar for importing LiDAR LAS files (*.las or *.laz). The LAS file format is commonly used for storing LiDAR point clouds, but is unfortunately not supported by OGR. v.in.lidar uses the libLAS library [0] and is only compiled if the libLAS library is present. I chose to use the library instead of writing a custom LAS reading interface because the current LAS library version 1.6.1 is stable, supports LAS file versions 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, each of which can store LiDAR points in up to 5 different point formats. The user and the interface do not need to know the file version and point format of a given file, all that is conveniently handled by the libLAS library in the background. The library has Large File Support (LFS) and is well tested on different platforms, also with different endian-ness. This functionality is not that easy to replicate. You will need to get the libLAS library and configure GRASS 7 with --with-liblas in order to have the module available. Please test! Markus M [0] http://www.liblas.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Problem running wxpython GUI
What flavor of Linux are you running? Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Thomas Adams thomas.ad...@noaa.gov Sent by: grass-dev-boun...@lists.osgeo.org 05/10/2011 03:20 AM To grass-user grass-u...@lists.osgeo.org, GRASS developers list grass-dev@lists.osgeo.org cc Subject [GRASS-dev] Problem running wxpython GUI All: I have built GRASS 6.4.1 on Linux with the following ./configure: ./configure --with-sqlite --with-postgres --with-tcltk-libs=/usr/local/tcltk-8.4.11/lib --with-tcltk-includes=/usr/local/tcltk-8.4.11/include --with-gdal=/usr/local/bin/gdal-config --with-libs=/usr/local/lib --with-includes=/usr/local/include --with-python=/usr/local/python-awips-2.5.1/bin/python-config --with-wxwidgets=/usr/local/bin/wx-config The tcltk GUI works perfectly fine, but when I try g.gui wxpython, I get: GRASS 6.4.1 (sref):w ERROR: wxGUI requires wxPython. No module named wxversion I'm using wxPython 2.8.12… I've googled wxGUI requires wxPython and No module named wxversion and have not found much that was helpful. Any suggestions? Maybe --with-wxwidgets=/usr/local/bin/wx-config is wrong?? Tom -- Thomas E Adams National Weather Service Ohio River Forecast Center 1901 South State Route 134 Wilmington, OH 45177 EMAIL: thomas.ad...@noaa.gov VOICE: 937-383-0528 FAX: 937-383-0033 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] How many points in a point layer and v.surf.bspline questions
Large file support does not help here because 8.5 billion points exceeds the number of supported features in GRASS vectors which is about 2 billion (2,147,483,647 to be precise). I'll chop the inputfile into sections less than 2 billion then. Is there any reason that the 2 billion limit on GRASS vectors cannot be raised? ( variable change vs types of variable and lots of ugly fixes in various places?) If it's something simple, I can play with it, but I'm not a C programmer :-(. The limit can be raised, but, unfortunately, this is not simple, because portability across platforms must be maintained. It boils down to the problem that it is not simple to have a portable 64 bit integer type on at least Linux, Mac, Windows, both 32 bit and 64 bit architectures. I would like to have a portable 64 bit integer type for grass 7 though... I see GRASS7 in my future :-) In the short term, Can this limit be gotten around by putting the data in Postgresql/Postgis/Spatialite and using v.external or v.db.connect for the inputpoints for v.surf.bspline? Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Markus Metz markus.metz.gisw...@googlemail.com 01/04/2011 04:43 AM To doug_newc...@fws.gov cc grass-dev@lists.osgeo.org, Markus Neteler nete...@osgeo.org Subject Re: [GRASS-dev] How many points in a point layer and v.surf.bspline questions On Mon, Jan 3, 2011 at 4:01 PM, doug_newc...@fws.gov wrote: Markus M., Large file support does not help here because 8.5 billion points exceeds the number of supported features in GRASS vectors which is about 2 billion (2,147,483,647 to be precise). I'll chop the inputfile into sections less than 2 billion then. Is there any reason that the 2 billion limit on GRASS vectors cannot be raised? ( variable change vs types of variable and lots of ugly fixes in various places?) If it's something simple, I can play with it, but I'm not a C programmer :-(. The limit can be raised, but, unfortunately, this is not simple, because portability across platforms must be maintained. It boils down to the problem that it is not simple to have a portable 64 bit integer type on at least Linux, Mac, Windows, both 32 bit and 64 bit architectures. I would like to have a portable 64 bit integer type for grass 7 though... Markus M Further on, a region with 6.8 billion cells is a bit large since the interpolated raster will be held in memory which would require about 50 GB RAM (that could be fixed for v.surf.bspline by keeping intermediate data on disk). I know some folks with computers with 64GB+ of RAM, so that is not an insurmountable issue. However, it would probably be better to go the intermediate route. No idea where the request for 18446744071812941729 * 8 bytes comes from, this is astronomical. That was my reaction. Perhaps the computer was screaming in pain.:-) Apart from that, spline steps of 40 seem ok, since the point distance is 5 m or less, spline steps of 20 would also be ok. The larger the spline steps, the smoother the resulting surface. Smoothing is also controlled through lambda. Thanks for the insight, I will need to change my approach to minimize the smoothing. Doug Markus M Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Markus Metz markus.metz.gisw...@googlemail.com 01/03/2011 09:13 AM To Markus Neteler nete...@osgeo.org cc doug_newc...@fws.gov, grass-dev@lists.osgeo.org Subject Re: [GRASS-dev] How many points in a point layer and v.surf.bspline questions On Mon, Jan 3, 2011 at 2:57 PM, Markus Neteler nete...@osgeo.org wrote: hi Doug, On Mon, Jan 3, 2011 at 2:26 PM, doug_newc...@fws.gov wrote: Hi Folks, I aggregated all of the bare earth lidar points for the state of North Carolina into a single file Imported all 8.5 billion points for NC into one point layer with no topology. I was sort of curious to see if I could generate a seamless 20 ft elevation grid for the State of North Carolina from a single data layerusing bspline and tried the following command: GRASS 6.5.svn (ncstpft_nad83):~ v.surf.bspline input=all_nc_be_pts2 raster=all_nc_be_20ft_bspline sie=40 sin=40 layer=0 WARNING: Coor files of vector map all_nc_be_p...@statewide is larger than it should be
[GRASS-dev] How many points in a point layer and v.surf.bspline questions
Hi Folks, I aggregated all of the bare earth lidar points for the state of North Carolina into a single file Imported all 8.5 billion points for NC into one point layer with no topology. I was sort of curious to see if I could generate a seamless 20 ft elevation grid for the State of North Carolina from a single data layerusing bspline and tried the following command: GRASS 6.5.svn (ncstpft_nad83):~ v.surf.bspline input=all_nc_be_pts2 raster=all_nc_be_20ft_bspline sie=40 sin=40 layer=0 WARNING: Coor files of vector map all_nc_be_p...@statewide is larger than it should be (158913789952 bytes excess) Cells for raster map all_nc_be_20ft_bspline will be interpolated ERROR: G_calloc: unable to allocate 18446744071812941729 * 8 bytes of memory at dalloc.c:66 This was for a region with the following settings: projection: 99 (Lambert Conformal Conic) - North Carolina State Plane Feet NAD83 zone: 0 datum: nad83 ellipsoid: grs80 north: 105 south: 3 west: 40 east: 306 nsres: 20 ewres: 20 rows: 51000 cols: 133000 cells: 678300 I then zoomed into the northeast corner of the state and set the region to : north: 1047363 south: 795102 west: 2505067 east: 3007693 nsres: 20.7928 ewres: 20.00023875 rows: 12613 cols: 25131 cells: 316977303 and tried again for this area GRASS 6.5.svn (ncstpft_nad83):~ v.surf.bspline input=all_nc_be_pts2 raster=ne_nc_be_20ft_bspline sie=40 sin=40 layer=0 WARNING: Coor files of vector map all_nc_be_p...@statewide is larger than it should be (158913789952 bytes excess) Cells for raster map ne_nc_be_20ft_bspline will be interpolated subregion 1 of 5459 I killed that one and set the sin and sie to 400 rather than 40 . This dropped the regions down to 66. GRASS 6.5.svn (ncstpft_nad83):~ v.surf.bspline input=all_nc_be_pts2 raster=ne_nc_be_20ft_bspline sie=400 sin=400 layer=0 WARNING: Coor files of vector map all_nc_be_p...@statewide is larger than it should be (158913789952 bytes excess) Cells for raster map ne_nc_be_20ft_bspline will be interpolated subregion 1 of 66 This is about halfway done, so I should see the results in another 1.5 days or so. I have two questions. First, is there a problem with importing large point datasets that is being highlighted by the warning? I did notice that the size of the coords and hist files did not match for the point data set. Second, is about v.surf.bspline and sin and sie. I have seen in the documentation that the sie an sin needs to be twice as large as the spacing between points as a good starting point. The density of the lidar data sets that make up this ground point layer varies between 1m and 5 m . Obviously, making sin and sie larger reduces the number of subregions, but how does that affect the accuracy of the surface generated? If I'm trying to generate a 20ft grid, is using sin and sie options of 400 absurd? ( I.E., It works faster but the results are less accurate) The version of GRASS used was the weekly snapshot from 12/25/2010. The computer has a 1.6 GHz Xeon quad-core cpu with 16 GB RAM. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] How many points in a point layer and v.surf.bspline questions
Markus M., Large file support does not help here because 8.5 billion points exceeds the number of supported features in GRASS vectors which is about 2 billion (2,147,483,647 to be precise). I'll chop the inputfile into sections less than 2 billion then. Is there any reason that the 2 billion limit on GRASS vectors cannot be raised? ( variable change vs types of variable and lots of ugly fixes in various places?) If it's something simple, I can play with it, but I'm not a C programmer :-(. Further on, a region with 6.8 billion cells is a bit large since the interpolated raster will be held in memory which would require about 50 GB RAM (that could be fixed for v.surf.bspline by keeping intermediate data on disk). I know some folks with computers with 64GB+ of RAM, so that is not an insurmountable issue. However, it would probably be better to go the intermediate route. No idea where the request for 18446744071812941729 * 8 bytes comes from, this is astronomical. That was my reaction. Perhaps the computer was screaming in pain.:-) Apart from that, spline steps of 40 seem ok, since the point distance is 5 m or less, spline steps of 20 would also be ok. The larger the spline steps, the smoother the resulting surface. Smoothing is also controlled through lambda. Thanks for the insight, I will need to change my approach to minimize the smoothing. Doug Markus M Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Markus Metz markus.metz.gisw...@googlemail.com 01/03/2011 09:13 AM To Markus Neteler nete...@osgeo.org cc doug_newc...@fws.gov, grass-dev@lists.osgeo.org Subject Re: [GRASS-dev] How many points in a point layer and v.surf.bspline questions On Mon, Jan 3, 2011 at 2:57 PM, Markus Neteler nete...@osgeo.org wrote: hi Doug, On Mon, Jan 3, 2011 at 2:26 PM, doug_newc...@fws.gov wrote: Hi Folks, I aggregated all of the bare earth lidar points for the state of North Carolina into a single file Imported all 8.5 billion points for NC into one point layer with no topology. I was sort of curious to see if I could generate a seamless 20 ft elevation grid for the State of North Carolina from a single data layerusing bspline and tried the following command: GRASS 6.5.svn (ncstpft_nad83):~ v.surf.bspline input=all_nc_be_pts2 raster=all_nc_be_20ft_bspline sie=40 sin=40 layer=0 WARNING: Coor files of vector map all_nc_be_p...@statewide is larger than it should be (158913789952 bytes excess) Cells for raster map all_nc_be_20ft_bspline will be interpolated ERROR: G_calloc: unable to allocate 18446744071812941729 * 8 bytes of memory at dalloc.c:66 you are hitting the limits :) I dunno if large file support helps, but for vector data it is only available in GRASS 7 to my knowledge. Large file support does not help here because 8.5 billion points exceeds the number of supported features in GRASS vectors which is about 2 billion (2,147,483,647 to be precise). Further on, a region with 6.8 billion cells is a bit large since the interpolated raster will be held in memory which would require about 50 GB RAM (that could be fixed for v.surf.bspline by keeping intermediate data on disk). No idea where the request for 18446744071812941729 * 8 bytes comes from, this is astronomical. Apart from that, spline steps of 40 seem ok, since the point distance is 5 m or less, spline steps of 20 would also be ok. The larger the spline steps, the smoother the resulting surface. Smoothing is also controlled through lambda. Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] G65/7 ctypes compilation problem on Enterprise Linux
According to Distrowatch , http://distrowatch.com/table.php?distribution=redhat , Red Hat 6 has Python 2.6.2. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. -grass-dev-boun...@lists.osgeo.org wrote: - To: Markus Neteler nete...@osgeo.org From: Helena Mitasova hmit...@unity.ncsu.edu Sent by: grass-dev-boun...@lists.osgeo.org Date: 08/18/2010 04:11PM cc: GRASS developers list grass-dev@lists.osgeo.org Subject: Re: [GRASS-dev] G65/7 ctypes compilation problem on Enterprise Linux Markus, this is the same problem here - the problem is with python2.4 that is used as default and that does not include ctypes so you need to make symlink in grass to make sure it looks for python2.6 (which I have also installed) or there may be some other solution - You cannot remove python2.4 because it is used for system management. I did not have time to get it fully resolved yet. The problem should go away with the next release of RHEL which is in beta and should use python 2.6 (I think), Helena On Aug 18, 2010, at 3:40 PM, Markus Neteler wrote: Hi, since Helena mentioned a problem on enterprise Linux, I tried to compile 6.5 on Scientific Linux, a RHEL derivate. Indeed, I get this problem: make[1]: Entering directory `/home/neteler/software/grass65_release/lib/python/ctypes' GISRC=/home/neteler/software/grass65_release/dist.x86_64-unknown-linux-gnu/demolocation/.grassrc65 GISBASE=/home/neteler/software/grass65_release/dist.x86_64-unknown-linux-gnu PATH=/home/neteler/software/grass65_release/dist.x86_64-unknown-linux-gnu/bin:$PATH PYTHONPATH= LD_LIBRARY_PATH=/home/neteler/software/grass65_release/dist.x86_64-unknown-linux-gnu/bin:/home/neteler/software/grass65_release/dist.x86_64-unknown-linux-gnu/lib::/home/neteler/binaries/lib/ LC_ALL=C ./ctypesgen.py --cpp gcc -E -DPACKAGE=\grasslibs\ -DPACKAGE=\grasslibs\ -I/home/neteler/software/grass65_release/dist.x86_64-unknown-linux-gnu/include -lgrass_datetime /home/neteler/software/grass65_release/dist.x86_64-unknown-linux-gnu/include/grass/datetime.h /home/neteler/software/grass65_release/dist.x86_64-unknown-linux-gnu/include/grass/P_datetime.h -o date.py Traceback (most recent call last): File ./ctypesgen.py, line 36, in ? import ctypesgencore File /home/neteler/software/grass65_release/lib/python/ctypes/ctypesgencore/__init__.py, line 51, in ? import parser File /home/neteler/software/grass65_release/lib/python/ctypes/ctypesgencore/parser/__init__.py, line 17, in ? from datacollectingparser import DataCollectingParser File /home/neteler/software/grass65_release/lib/python/ctypes/ctypesgencore/parser/datacollectingparser.py, line 10, in ? import ctypesparser File /home/neteler/software/grass65_release/lib/python/ctypes/ctypesgencore/parser/ctypesparser.py, line 15, in ? from cparser import * File /home/neteler/software/grass65_release/lib/python/ctypes/ctypesgencore/parser/cparser.py, line 19, in ? import preprocessor File /home/neteler/software/grass65_release/lib/python/ctypes/ctypesgencore/parser/preprocessor.py, line 14, in ? import ctypes ImportError: No module named ctypes make[1]: *** [date.py] Error 1 make[1]: Leaving directory `/home/neteler/software/grass65_release/lib/python/ctypes' make: *** [default] Error 2 I also tried on GRASS 7, same thing. SciLin 5.2 provides python2.4. A fix would be appreciated. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [SoC] gdalwarp OpenCL Performance (Week 9)
Seth Wrote: Once I get some appropriate 4+ band imagery, I'll be making some tweaks for the CPU code to use SSE also. Debugging OpenCL is hell, but it's pretty powerful versatile once you get it running. (Looks like I have some 6-band imagery, I know what I'm doing today...) Many States are being flown with 4 Band NAIP this summer. North Carolina NAIP was flown in 4 Band last year and the tiffs are now available. I'm not sure if they are available for download yet, but if you indicate areas of interest in NC ( perhaps coincident with the NC GRASS sample data set) , something could be arranged. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [SoC] Parallelization of Raster and Vector modules
Jordan, I've dealt with ERDAS Imagine files larger than 10 GB on a regular basis. I have occasionally tried to reproject and merge all of the 1 m NAIP imagery tiles for North Carolina into 1 BigTIFF 500GB with gdal. Any parallelizaion work for open source geospatial tools would be welcome :-). So you tried to do that? Does that mean you failed or is the system still processing it? :-P I kid, but that is a very large file... it's bigger than my current desktop's hard drive. Jordan, It would be a shame to leave those multicore 64 bit processors with multi-terabyte hard drives with nothing to challange them. Just think of me as part of the hardware entertainment committee. :-) The process ran overnight and finished, I just have not gotten to phase 2 of that particular project, chopping the resulting image into overlapping DOQQ - size images. I was going to go back and change the projection method slightly, hopefully to make it more accurate. If you're looking for big images to play with, go to http://datagateway.nrcs.usda.gov/ and select a naip county mosaic of imagery. The mosaic comes as a MrSid format file, but once you uncompress it ( I suggest using gdal's nearblack utility ) to ERDAS Imagine format, the resulting image will probably be in the multi-gigbyte range per county. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. Jordan Neumeyer jordan.neume...@mines.sdsmt.edu Sent by: grass-dev-boun...@lists.osgeo.org 04/08/2010 01:09 AM To doug_newc...@fws.gov cc GRASS developers list grass-dev@lists.osgeo.org Subject Re: [GRASS-dev] [SoC] Parallelization of Raster and Vector modules Thanks guys for putting that into perspective. On Mon, Apr 5, 2010 at 6:38 PM, doug_newc...@fws.gov wrote: Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. -grass-dev-boun...@lists.osgeo.org wrote: - To: Jordan Neumeyer jordan.neume...@mines.sdsmt.edu From: Markus Neteler nete...@osgeo.org Sent by: grass-dev-boun...@lists.osgeo.org Date: 04/05/2010 04:06AM cc: GRASS developers list grass-dev@lists.osgeo.org Subject: Re: [GRASS-dev] [SoC] Parallelization of Raster and Vector modules On Sun, Apr 4, 2010 at 3:22 AM, Jordan Neumeyer jordan.neume...@mines.sdsmt.edu wrote: I didn't realize how big the data set could be. What's biggest map you've seen? Our provincial DEM is a 3.5GB Geotiff which is of 48800x58000 size. Another file which I recently had to import was a 4GB Geotiff with 21550 bands. Finally, in remote sensing, you can quickly generate quickly files in the multi-GB range. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ~Jordan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [SoC] Parallelization of Raster and Vector modules
Jordan, I've dealt with ERDAS Imagine files larger than 10 GB on a regular basis. I have occasionally tried to reproject and merge all of the 1 m NAIP imagery tiles for North Carolina into 1 BigTIFF 500GB with gdal. Any parallelizaion work for open source geospatial tools would be welcome :-). Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. -grass-dev-boun...@lists.osgeo.org wrote: - To: Jordan Neumeyer jordan.neume...@mines.sdsmt.edu From: Markus Neteler nete...@osgeo.org Sent by: grass-dev-boun...@lists.osgeo.org Date: 04/05/2010 04:06AM cc: GRASS developers list grass-dev@lists.osgeo.org Subject: Re: [GRASS-dev] [SoC] Parallelization of Raster and Vector modules On Sun, Apr 4, 2010 at 3:22 AM, Jordan Neumeyer jordan.neume...@mines.sdsmt.edu wrote: I didn't realize how big the data set could be. What's biggest map you've seen? Our provincial DEM is a 3.5GB Geotiff which is of 48800x58000 size. Another file which I recently had to import was a 4GB Geotiff with 21550 bands. Finally, in remote sensing, you can quickly generate quickly files in the multi-GB range. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS GIS] #908: No Font Definition File, windows xp
Hamish, Many government organizations that use Windows are going to LUA, http://technet.microsoft.com/en-us/library/cc700846.aspx Least-privileged User Account environments for most users. Having a normal user need to do anything as an administrator to run a program is almost a show-stopper for deployment in these environments. So, I wholeheartedly applaud anything that can be done to make GRASS run well under Windows without any administrative access. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. -grass-dev-boun...@lists.osgeo.org wrote: - To: undisclosed-recipients:; From: GRASS GIS Sent by: grass-dev-boun...@lists.osgeo.org Date: 02/05/2010 03:41AM Subject: [GRASS-dev] Re: [GRASS GIS] #908: No Font Definition File, windows xp #908: No Font Definition File, windows xp ---+ Reporter: voncasec | Owner: grass-...@lists.osgeo.org Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Installation | Version: svn-releasebranch64 Resolution: | Keywords: v.label.sa, g.mkfontcap, wingrass Platform: MSWindows XP | Cpu: Unspecified ---+ Comment (by hamish): ... but for be benefit of users without admin rights on the system it should probably happen as part of the installer. maybe for GRASS 7 we should first check for it in ~/.grass7/fontcap, and if not found there look for it in $(ETC)/fontcap? Hamish -- Ticket URL: GRASS GIS ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] vector libs: file based spatial index
the biggest lidar file used that I know about is Doug's 379GB dataset (14.5 billion points). Frightening. The above dataset was for two watersheds collected in 2001, the larger of the two watersheds is 9000 square miles . I've recently been working with newer lidar data ( 2007) from a single county with an area of 744 sq. miles ( Craven county, North Carolina, USA) . This county had lidar flown at a submeter posting ( 0.7m? as a guess). The aggregated ASCII x,y,z,intensity file that I created ( for processing using r.in.xyz) from the input las files for that single county was 80 GB . I guess my point is that lidar datasets are getting quite massive. If we are going to be working with the lidar data as point data in the GRASS vector framework, go with the most scalable options. Scalability in working with large data sets is a huge benefit in using GRASS over other solutions. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of Interior. Life is too short for undocumented, proprietary data formats. Markus GRASS markus.metz.gisw o...@googlemail.co To mHamish hamis...@yahoo.com Sent by: cc grass-dev-bounces GRASS devel @lists.osgeo.org grass-dev@lists.osgeo.org Subject Re: [GRASS-dev] vector libs: file 06/25/2009 03:21 based spatial index AM Hamish wrote: Moritz wrote: The largest file I have used is about 125000 areas with a topo file weighing 42M, so taking your worst estimation, this would mean around 200MB of spatial index, which is still largely acceptable for me. lidar and swath bathymetry data will easily have millions of points, and as time goes on this will only expand. I seem to recall that one of Radim's big disappointments was that the need to handle this technology/ data density only really became apparent just when GRASS's new vector engine was nearing completion. With some earlier notice it could have been designed to scale better. Still, there is much tuning which can be done with the present model to reduce the memory overheads, etc. Yes. As an example, for a 2D point dataset, the topo file should be about 4 times as large as the coor file, same for the spatial index. This is because each x,y coordinate pair is stored 3 times in the topo file, plus some other information that is for points not needed, e.g. area/isle to the left and to the right, start node and end node (start node = end node for points/centroids). Each x,y coordinate pair is stored 2 times in the spatial index (rectangle of size zero with N S E W and N = S, E = W). I see some potential for cleaning up. FWIW the sites type (now vector points) in GRASS 4/5 scales well, just as much as you can fit in the text file. (not sure if fseeks are 64bit- proof there, probably not) I guess that was without topo? the biggest lidar file used that I know about is Doug's 379GB dataset (14.5 billion points). Frightening. you might look at libLAS (for lidar data -- an OSGeo semi-affiliated project: http://liblas.org/ It is my understanding that Howard is currently adding spatial index support in the development version. You might check out his approach. Will do. I have been, and still am ignorant of what advantage a spatial index gives you for point data. ... interested to learn why topology would be useful for points-only data. Strictly speaking, topology and spatial index are two different things, you could have a spatial index without topo. I can also not see the usefulness of topology for point data. A spatial index may be useful to extract a subset (v.select), but in this case you could just as well go through the points in the coor file, read one at a time and select the ones that fall into the study area. Should be slower than with a spatial index but
Re: [GRASS-dev] Re: [SoC] Proposal for wxGUI layout modifications
it is nice to keep a module gui open so you can tweak one parameter and run it again. it is nice to keep a couple open and switch between them if you are doing something on a multi-processor machine (if doing so within a single mapset, at your own responsibility and risk that the computation region etc is not changed of course :) for that reason you might want to have e.g. 3 r.in.xyz's running at the same time, each crunching along on a different statistical method. This is something that I do a lot and is extremely valuable when simultaneously bulk processing multiple return Lidar data for different statistics. Please keep this feature of the gui! Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of Interior. Life is too short for undocumented, proprietary data formats. Hamish hamis...@yahoo.c omTo Sent by: Martin Landa grass-dev-bounces landa.mar...@gmail.com, Michael @lists.osgeo.org Barton michael.bar...@asu.edu cc grass-dev@lists.osgeo.org, 04/14/2009 11:31 s...@lists.osgeo.org PMSubject [GRASS-dev] Re: [SoC] Proposal for wxGUI layout modifications Michael Barton wrote: Actually, I think what (I hope) was envisioned was not a true MDI--which has lost considerable popularity--but attaching the layer manager to the display window. Ideally, this could be done by docking or undocking. That said, Markus and I had some offline discussions about this since he was the proposer, in response to some user comments and his own experiences. The main complaint is having too many windows open in GRASS. After some talking about it, the real problem may not lie primarily with the layer manager/display windows but with all the module windows which a lot of people don't realize that you can set to close automatically when you push OK. Some possible solutions to this would include having all modules open in a single window with tabs or modally in a single window or modally in a window attached to the layer manager to keep down clutter. By focusing a bit much on the initial display configuration of a couple of other GIS programs (ArcGIS and QGIS, but not in a lot of others by the way), we may have missed the real cause of the perceived screen clutter. Anyway, it's something to think about. [we should probably move this to the grass-dev ML] Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev inline: graycol.gifinline: pic16105.gifinline: ecblank.gif___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] call for volunteers - urgent need for Windows Vista binaries
Jachym, I have to echo what Michael is saying about the Windows installer. In a government enterprise environment, I doubt the present osgeo installation format would be accepted. A stand-alone msi package would be better. Another question with the osgeo installer, would the installation of the support libraries/utilites ( python, gdal, etc.) conflict with an existing installation of ArcGIS and it's libraries? I'm trying to get folks who already use ArcGIS to try doing some things in GRASS. The combination of an unfamiliar installation package and conflicts with their existing software would increase the resistance to initial use. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of Interior. Life is too short for undocumented, proprietary data formats. Michael Barton michael.bar...@a su.eduTo Sent by: Jachym Cepicky grass-dev-bounces jachym.cepi...@gmail.com @lists.osgeo.org cc grass-user grass-user grass-u...@lists.osgeo.org, GRASS 03/27/2009 02:18 developers list AMgrass-dev@lists.osgeo.org Subject Re: [GRASS-dev] call for volunteers - urgent need for Windows Vista binaries On Mar 26, 2009, at 10:21 PM, Jachym Cepicky wrote: hi, just small note: On Thu, Mar 26, 2009 at 12:21:55PM -0700, Michael Barton wrote: Marco Pasetti made a very nice Windows installer for 6.3 last year, but is unable to continue this work. Other folks in OSGEO have created OSGEO4W with a number of packages. However, GRASS is in the 'advanced' section--and it is not clear what libraries need to be downloaded with it--and it cannot be installed stand-alone. the osgeo4w installer is just fine, only thing is missing is, that GRASS should appear in the 'basic' section as well (should not be that complicated) and all depandances are fixed. than the installation is IMHO enough straight forward and easy. jachym Jachym, The osgeo4w installer does not work well with Vista. The binary seems to have been compiled for XP and so various modules fail when GRASS installed is installed in this way on Vista. There needs to be a Vista version of the installer Also, while the osteo4w installer is nice for individual installs, it is problematic for institutional lab installs, where IT managers want to have stand alone apps that they can test, install, and remove rather than a suite of apps in a package installer format. It's the same problem I've face with the Cygwin version when trying to use GRASS in university classroom labs. It would help to have the option to install a package as stand alone. Michael ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev inline: graycol.gifinline: pic09503.gifinline: ecblank.gif___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
