http://permalink.gmane.org/gmane.comp.gis.grass.user hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.gis.grass.user/47606 <pre> this seems to be the one: "REGEEMY"   http://regima.dpi.inpe.br Restrictive license, no linux binary since 2006 and no source code to recompile it for 64bit, so I won't bother to add it to the wiki (but if it's super useful I don't mind), but seeing they haven't touched in in years maybe the authors could be convinced to set it free? Hamish _______________________________________________ grass-user mailing list grass-user&lt; at &gt;lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user </pre> Hamish 2013-06-20T02:57:54 http://permalink.gmane.org/gmane.comp.gis.grass.user/47605 <pre>Hello Adam, the '-fine', '-extra_fine', and '-ultra_fine' option specifies how much work the algorithm should invest to find the *initial* ground estimate that will get refined subsequently. As a rule of thumb you need a finer ground estimate the steeper your terrain. The option essentially defined how fine of a subgrid should be used to look for probable ground returns between the chosen step size. Each finer option quadruples the granularity of this subgrid (whose unrefined size is detmined by the step size). For very steep terrains extra fine is recommended but also for flat areas with subtle bumps in the ground the ultra fine setting can help to get better detail. For computing tree canopies, for example, in flat terrain the default granularity should be fine enough. Cheers, Martin On Jun 17, 2013, at 20:55, Adam Pryor &lt;adam&lt; at &gt;extro.com.au&gt; wrote: </pre> Martin Isenburg 2013-06-19T09:05:32 http://permalink.gmane.org/gmane.comp.gis.grass.user/47604 <pre>Hello Adam, currently lasclip seems to generate "empty" LAS/LAZ files when there is no overlap. It would be an easy feature to add a "remove file" operation once it becomes apparent the the produced file was empty. Can anyone think of a reason why we should keep the zero point files? Otherwise i will make what Adam suggests the default behaviour of lasclip in some future version ... Cheers, Martin &lt; at &gt;rapidlasso On Jun 17, 2013, at 21:16, Adam Pryor &lt;adam&lt; at &gt;extro.com.au&gt; wrote: </pre> Martin Isenburg 2013-06-19T09:10:58 http://permalink.gmane.org/gmane.comp.gis.grass.user/47603 <pre>Hello Adam, lasoverage is fully functional in the version that is online - except for the black diagonal lines that are added to the output raster. However, these only minimally affect your ability to judge the quality of the flight line alignment but let you evaluate the speed and efficiency of using LAStools for quality checking. The GPS time is not being used for lasoverlap. For lasoverlap it is important that an adequate step size is used and that the input contains correct populated point source ID fields. If the input is a set of flight lines this means that the option '-files_are_flightlines' needs to be set. Then there will be one single output raster. If the input are already tiled flightlines then each point must indicate which flight line it is from with a flight line unique point source ID. Then there will be one ouput raster per tile (unless '-merged' was specified). Any issues with lasoverlap are to be blamed either on user error or on poor documentation. (-: Regards, Martin PS: Also see </pre> Martin Isenburg 2013-06-19T08:55:37 http://permalink.gmane.org/gmane.comp.gis.grass.user/47602 <pre>Hello Adam, the tools for gridding parameters other than the elevation are las2dem/blast2dem for intensity, slope, and RGB and lasgrid for scan_angle, classification, intensity, return counts, etc ... the GUI shows you the possible options in the selection box. You can then create a BIL or ASC raster and visualize this with your favorite raster software or with lasview ... lasgrid -i lidar.laz ^ -lowest -abs_scan_angle ^ -step 1 ^ -o minscanangles.asc lasview -i minscanangles.asc ^ -color_by_elevation2 ^ -win 1200 900 ^ -points 5000000 cheers, martin &lt; at &gt;rapidlasso On Jun 17, 2013, at 20:43, Adam Pryor &lt;adam&lt; at &gt;extro.com.au&gt; wrote: </pre> Martin Isenburg 2013-06-19T09:22:16 http://permalink.gmane.org/gmane.comp.gis.grass.user/47601 <pre>Hi Miltinho, You could also try a software called regimy (or some other spelling). If I recall correctly, it was developed by some guys at inpe and it finds matching control points between a set of images. We have been using it for some old landsat images. Cheers Daniel On Jun 17, 2013 2:35 PM, "miltinhoastronauta ." &lt; miltinho.astronauta&lt; at &gt;gmail.com&gt; wrote: _______________________________________________ grass-user mailing list grass-user&lt; at &gt;lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user </pre> Daniel Victoria 2013-06-19T13:36:26 http://permalink.gmane.org/gmane.comp.gis.grass.user/47600 <pre>Hi, I used the software some time ago and it worked nicely. And as Johannes explained, the only data needed is the river network and the basin boundary. I'll try to translate the algorithm behind the software but I'm a bit confused by it so I could be doing a worse job then a google translator... 1) If a river segment is connected to the river network at only one point and the segment does not touch the basin boundary, those are the first order streams rivers and their flow direction can be defined from the unconnected end to the connected end 2) If the endpoint of a river segment touches other segments that have their flow directions determined and the flows converge, then: The flowdirection of the segment goes from the examined endpoint to the other end; You can calculate the stream order by looking at the stream orders of the segments that flow into the analyzed segment. If the segments that touch an endpoint does not have their flowdirection determined, then the flowdirection the analyzed endp</pre> Daniel Victoria 2013-06-19T00:09:14 http://permalink.gmane.org/gmane.comp.gis.grass.user/47598 <pre>Hello Charm, great question. Since you are expecting around 2 pulses per square meter and since you are using a step of 5 which equals 5m by 5m = 25 m^2 and since you are using the last only (or first only) retirn filter to count only one return per pulse you should expect to get values around 50 in the grid cells. You will get - possibly much - smaller values whenever the strip does not fully cover the grid cell. It is possible that just one pulse hits one corner of a grid cell. You will get - possibly much - larger values when the sampling on the ground gets condensed (but also streched out) because of strong pitch variations of a small aircraft in turbulences. But the more "systematic" larger values come from hardware that use a zig-zag scanner to scan. As the oszillating mirror slows down to change direction at the scan line edges you tend to get much much denser sampling there ... somewhat unrepresentative for the average sampling so it is important for zig zag scanners not to count the density of po</pre> Martin Isenburg 2013-06-18T20:37:54 http://permalink.gmane.org/gmane.comp.gis.grass.user/47597 <pre> this discussion group on LiDAR processing with LAStools tends to have plenty of interesting topics About this group: LAStools are a collection of highly-efficient, batch scriptable, multi-core command line tools (with GUI and ArcGIS toolbox) for processing LiDAR that is built upon LASlib (with LASzip). We announce new releases and discuss whatever of interest to those processing billions of LiDAR points. Accept this invitation: http://groups.google.com/group/lastools/sub?s=IIzkixQAAABgeCJzPKlh5pok34Hj0DmmGkaXaBZ9l455j8Ixb4EWdA&amp;hl=en Visit this group: http://groups.google.com/group/lastools?hl=en You can unsubscribe from this group using the following URL: http://groups.google.com/group/lastools/unsub?u=IIzkixQAAABgeCJzPKlh5pok34Hj0DmmGkaXaBZ9l455j8Ixb4EWdA&amp;hl=en If you feel that this message is abuse, please inform the Google Groups staff by using the URL below. http://groups.google.com/groups/abuse?direct=YQAAAIb6S2-cAAAA4EbiTJsAAADPQv5WpYF4_V1sH6WAqxO-tgcc8gU&amp;hl=en ___________________________</pre> Martin Isenburg (Google Groups 2013-06-18T20:53:22 http://permalink.gmane.org/gmane.comp.gis.grass.user/47596 <pre>1) Concerning the flow direction / network direction So far what I can understand from the html-manual, the only two input data is the map with the river network and a line or polygon file the defines the catchement. The flow direction within the network is then defined by the outflow point which is the only line of the river that touches or intersects with the catchment border. Unfortunately, neither I am a native Brasilian (which makes reading the manual difficult) nor I am able to read or understand the source code behind the model 2) Concerning the license It is licensed under GNU GPL: http://www.fgel.uerj.br/labgis/hydroflow/Help/helphydroflow.html?{D3EB24A2-0B1B-4CA1-B0C6-F05855A23C8D}.htm &lt; at &gt;Madi: No unfortunately I haven't tried HydroFlow yet. I first have to figure out how to compile it using qmake on my ubuntu machine. Concerning v.strahler: AFAIK also this module needs a DEM to identify flow direction, which is often not available when you have only the river vector. And of course HydroFlow also </pre> Johannes Radinger 2013-06-18T14:19:10 http://permalink.gmane.org/gmane.comp.gis.grass.user/47595 <pre>On Tue, Jun 18, 2013 at 1:52 PM, Johannes Radinger &lt;johannesradinger&lt; at &gt;gmail.com&gt; wrote: One bit of requirement information must be provided in addition to the shapefile: the outlet of a river network. If the lines of the shapefile follow drainage dirction, this is possible, because then per network only one line will go towards an end point. You could look at the description or source code if possible to find out how HydroFlow identifies the outlet of a river network. Markus M _______________________________________________ grass-user mailing list grass-user&lt; at &gt;lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user </pre> Markus Metz 2013-06-18T13:08:28 http://permalink.gmane.org/gmane.comp.gis.grass.user/47594 <pre>Hi Johannes! I tried that program like a year or more ago .. It worked well once you know howto do it .. It delivers it's one shapelib with it and can only do changes on shapefiles .. So it must be probably changed to a neutral dataset provider .. I was about to adapt it for QGIS but did not have any time until now to do so.. Probably in the future when I have more time to learn more cpp skills .. But as I said the program itself works well .. But is it really open source? I am not quite sure if there weren't any issues with the license that kept me away from porting it .. kind regards Werner On Tue, Jun 18, 2013 at 1:52 PM, Johannes Radinger &lt; johannesradinger&lt; at &gt;gmail.com&gt; wrote: _______________________________________________ grass-user mailing list grass-user&lt; at &gt;lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user </pre> Werner Macho 2013-06-18T12:39:49 http://permalink.gmane.org/gmane.comp.gis.grass.user/47593 <pre> </pre> Margherita Di Leo 2013-06-18T12:26:04 http://permalink.gmane.org/gmane.comp.gis.grass.user/47592 <pre>Hi Johannes, On Tue, Jun 18, 2013 at 1:52 PM, Johannes Radinger &lt; johannesradinger&lt; at &gt;gmail.com&gt; wrote: there is v.strahler http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6#v.strahler that calculates the Strahler order. I'm not aware of its status though, I remember some issues reported in ML but I didn't keep myself updated. Nice idea! Did you try it yourself? How's the outcome? cheers, madi </pre> Margherita Di Leo 2013-06-18T11:58:15 http://permalink.gmane.org/gmane.comp.gis.grass.user/47591 <pre>Hi, I found following interesting Brasilian program called HydroFlow: http://www.fgel.uerj.br/labgis/hydroflow/en/downloads_ingles.html This tools calculates the Stream order (e.g. Strahler, Shreve) based on a shapefile input of the river network and a shapefile that defines the border (catchment?). If I am informed correctly such a tool that does not require any form of a DEM (or accumulation map etc.) is not existing for GRASS yet. There are just two questions that appeared to me: 1) Has anyone installed and tried the programm already in Ubuntu/Linux? 2) The tool is licensed as open source. So, could such a algorithm also be implemented as a add-on to GRASS? I am not sure but I can imagine that this might be of interest also to other GRASS users!? /johannes _______________________________________________ grass-user mailing list grass-user&lt; at &gt;lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user </pre> Johannes Radinger 2013-06-18T11:52:43 http://permalink.gmane.org/gmane.comp.gis.grass.user/47590 <pre>Hellos, six new north arrow symbols to try out:   http://grasswiki.osgeo.org/wiki/IconSymbols#New I'm not toally happy with n_arrow5: I didn't figure a way to make a hole in the filled-arc, so the "N" is hardcoded to filled-with-white. (so you can't set inverse colors on that one. the big triangle in it is transparent btw) hmm, maybe I could leave a sliver to the outside space then mask over it with a polygon with no border color and background color matching the main body?  ... TBC Hamish _______________________________________________ grass-user mailing list grass-user&lt; at &gt;lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user </pre> Hamish 2013-06-18T10:20:02 http://permalink.gmane.org/gmane.comp.gis.grass.user/47589 <pre>Ivan: Adam wrote: Hamish: Adam: Hamish: I've just added a new r.surf.nnbathy dir in the grass7/raster addons, with symlinks back to the grass6 dir. I had to do each file individually instead of jus the dir since description.html needs to be renamed to [g.module].html. Svn stores it as a "link" file internally, and I believe a checkout on Windows will make a full copy of the files since there are no symlinks there. if it works it will be a nice temporary solution to avoid the extra maintenance overhead and divergence. Hamish _______________________________________________ grass-user mailing list grass-user&lt; at &gt;lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user </pre> Hamish 2013-06-18T09:06:55 http://permalink.gmane.org/gmane.comp.gis.grass.user/47588 <pre>I use it in Grass 7. it works. inviato da smartphone Il giorno 18/giu/2013 02:38, "Hamish" &lt;hamish_b&lt; at &gt;yahoo.com&gt; ha scritto: _______________________________________________ grass-user mailing list grass-user&lt; at &gt;lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user </pre> Ivan Marchesini 2013-06-18T06:43:27 http://permalink.gmane.org/gmane.comp.gis.grass.user/47587 <pre> I don't think there is a newer version, but there's a good chance that the GRASS 6 one still works. Give it a try and let us know! In general cloned code is to be avoided, and svn supports symlinking, so a possible solution for known working addons (scripts) is to symlink in the parent directory. Hopefully the build system is not too grumpy about mixed python and shell scripts. If it is we should come up with a solution to fix that. regards, Hamish _______________________________________________ grass-user mailing list grass-user&lt; at &gt;lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user </pre> Hamish 2013-06-17T21:51:52 http://permalink.gmane.org/gmane.comp.gis.grass.user/47586 <pre>Is r.surf.nnbathy compatible with GRASS 7.0? It doesn't seem to be listed on the GRASS7 Raster AddOns page. And, the install instructions that I have found all refer to GRASS 6. I have the nnbathy binary from 6 working fine. Can I just copy over the script and binary? Is there a new version? Thanks, </pre> Adam Dershowitz 2013-06-17T21:25:30 http://permalink.gmane.org/gmane.comp.gis.grass.user/47585 <pre> you need skip=1 or put a # in front of the first line, it's trying to parse the header line. style: since the stdin= option is a virtual one for grass.write_command(), consider putting it last. Hamish _______________________________________________ grass-user mailing list grass-user&lt; at &gt;lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user </pre> Hamish 2013-06-17T21:06:00 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.gis.grass.user