Re: [GRASS-dev] [GRASS GIS] #2116: r.kappa: call to r.stats fails if spaces in path
#2116: r.kappa: call to r.stats fails if spaces in path ---+ Reporter: mlennert | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.4 Component: Raster | Version: svn-releasebranch64 Keywords: r.kappa, path |Platform: Unspecified Cpu: Unspecified| ---+ Comment(by mlennert): Replying to [comment:3 hamish]: simple quoting fix committed in devbr6 relbr64 with r58111,2. it should be tested in wingrass before closing the ticket, see the i.smap help page for an example. Thanks a lot ! I hadn't applied the patch, yet, since you suggested G_vspawn_ex(), and I didn't find the time to look into that. Should that solution be preferred ? Should we maybe leave the ticket open as a reminder, or should we just say that if it works in windows we're happy with this quick fix for grass6 ? Moritz -- Ticket URL: https://trac.osgeo.org/grass/ticket/2116#comment:4 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2121: v.rast.stats: allow choice of statistics
#2121: v.rast.stats: allow choice of statistics
--+-
Reporter: mlennert | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal| Milestone: 7.0.0
Component: Vector| Version: svn-trunk
Keywords: v.rast.stats |Platform: Unspecified
Cpu: Unspecified |
--+-
It would be convenient if v.rast.stats allowed a choice of statistics that
one wants to upload to the attribute table. Currently, it creates 9
columns:
{{{
INTEGER|B5_n
DOUBLE PRECISION|B5_min
DOUBLE PRECISION|B5_max
DOUBLE PRECISION|B5_range
DOUBLE PRECISION|B5_mean
DOUBLE PRECISION|B5_stddev
DOUBLE PRECISION|B5_varianc
DOUBLE PRECISION|B5_cf_var
DOUBLE PRECISION|B5_sum
}}}
a series of which can actually be derived from others (mean, range, sttdev
|| variance, coefficient of variation), meaning that only 5 are really
needed (n, min, max, variance || stddev, sum).
So, at least we could limit the uploaded statistics to those 5, or even
allow choice of statistics through a parameter.
Moritz
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2121
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2121: v.rast.stats: allow choice of statistics
#2121: v.rast.stats: allow choice of statistics --+- Reporter: mlennert | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal| Milestone: 7.0.0 Component: Vector| Version: svn-trunk Keywords: v.rast.stats |Platform: Unspecified Cpu: Unspecified | --+- Comment(by mlennert): Trac didn't like my use of the pipe character as OR operator, so variance stddev should read variance OR stddev. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2121#comment:1 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2122: v.to.db: add eigenvalues of covariance matrix of coordinates
#2122: v.to.db: add eigenvalues of covariance matrix of coordinates -+-- Reporter: mlennert | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.0.0 Component: Vector | Version: svn-trunk Keywords: v.to.db eigenvalues |Platform: Unspecified Cpu: Unspecified | -+-- [Going on with my series of notes on what would be great to have in GRASS:] The eigenvalues of the covariance matrix of the coordinates of the vertices of a polygon represent the major and minor (+ medium in 3D) axes of an ellipse (ellipsoid in 3D) that approximates the polygon. These values can be used to approximate different variables in shape analysis (length, direction, asymmetry, etc). It would be great if v.to.db could calculate these values. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2122 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2123: v.to.db: allow upload of multiple variables at once
#2123: v.to.db: allow upload of multiple variables at once
-+--
Reporter: mlennert | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Vector | Version: svn-trunk
Keywords: v.to.db multiple operations |Platform: Unspecified
Cpu: Unspecified |
-+--
It would be convenient, if v.to.db could allow uploading multiple
variables in one run, i.e. something like this:
{{{
v.to.db mymap op=area,perimeter,compact,fd
col=area,perimeter,compactness,fractal_dim
}}}
Obviously, this would only work if all the chosen variables pertain to the
same feature type, so a check for that would be necessary.
Moritz
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2123
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Object-based image classification in GRASS
Moritz, Thanks heaps for the script. It's really is useful and will facilitate the adoption of i.segment. It certainly would be a nice addition to the wiki page. Unfortunately I can't comment too much on this, as my object-based classification projects are on hold, but I'll try to give that a shot sometime soon. It could also be interesting to try non-supervised approach using i.segment to limit the salt and pepper noise affecting such classifications. Cheers, Pierre 2013/10/31 Moritz Lennert mlenn...@club.worldonline.be: Hello, Based on the great work on i.segment by Eric and MarkusM, I've been trying to put up a complete workflow allowing object-based image classification in GRASS. Conclusion: it is possible with currently available tools, even though some components would be nice to have in addition. Attached you can find a simple shell script which shows all the steps I went through. I commented it extensively, so it hopefully is easy to understand. Some remarks: - This only works in GRASS 7. - It uses the v.class.mlpy addon module for classification, so that needs to be installed. Kudos to Vaclav for that module ! It currently only uses the DLDA classifier. The mlpy library offers many more, and I think it should be quite easy to add them. Obviously, one could also simply export the attribute table of the segments and of the training areas to csv files and use R to do the classification. - At the top of the script are a series of parameters that have to be defined before being able to use the script as such (but the script is more meant as a proof-of-concept than as a real script) - Many other variables could be calculated for the segments: other texture variables (possibly variables by segment, not as average of pixel-based variables, cf [1]), other shape variables (cf the new work of MarkusM on center lines and skeletons of polygons in v.voronoi), band indices, etc. It would be interesting to hear what most people find useful. - I do the step of digitizing training areas in the wxGUI digitizer using the attribute editing tool and filling in the 'class' attribute for those polygons I find representative. As already mentioned in previous discussions [2], I do think that it would be nice if we could have an attribute editing form that is independent of the vector digitizer. More generally, it would be great to get feedback from interested people on this approach to object-based image classification to see what we can do to make it better. Moritz [1] https://trac.osgeo.org/grass/ticket/2111 [2] http://lists.osgeo.org/pipermail/grass-dev/2013-February/062148.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Scientist Landcare Research, New Zealand ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2047: GRASS doesn't build on FreeBSD
#2047: GRASS doesn't build on FreeBSD -+-- Reporter: lbartoletti | Owner: grass-dev@… Type: defect | Status: new Priority: blocker | Milestone: 6.4.4 Component: Compiling| Version: svn-releasebranch64 Keywords: |Platform: Other Unix Cpu: x86-64 | -+-- Changes (by neteler): * version: 6.4.3 RCs = svn-releasebranch64 * milestone: 6.4.3 = 6.4.4 Comment: Could you try with a recent SVN snapshot? http://grass.osgeo.org/grass64/source/snapshot/ (I am not sure if this report is actually a blocker for 6.4.4) -- Ticket URL: https://trac.osgeo.org/grass/ticket/2047#comment:4 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2116: r.kappa: call to r.stats fails if spaces in path
#2116: r.kappa: call to r.stats fails if spaces in path ---+ Reporter: mlennert | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.4 Component: Raster | Version: svn-releasebranch64 Keywords: r.kappa, path |Platform: Unspecified Cpu: Unspecified| ---+ Comment(by glynn): Replying to [comment:4 mlennert]: I hadn't applied the patch, yet, since you suggested G_vspawn_ex(), and I didn't find the time to look into that. Should that solution be preferred ? The spawn functions are preferable (that's what r.kappa uses in 7.0), as they avoid the shell altogether. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2116#comment:5 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Object-based image classification in GRASS
Hi Moritz, I'm writing some modules (in python) to basically do the same thing. I'm trying to apply a Object-based classification for a quite big area (the region is more than 14 billions of cells). At the moment I'm working with a smaller area with only ~1 billions of cells, but it is still quite challenging. To speed-up the segmentation process I did the i.segment.hierarchical module [0]. that split the region in several tiles, compute the segment for each tile, patch all the tiles together and run a last time i segment using the patched map as a seed. for a region of 24k row for 48k cols it required less than two hour to run and patch all the tiles, and more than 5 hours to run the final i.segment over the patched map (using only 3 iterations!). From my experience I can say that the use v.to.db is terribly slow if you want to apply to a vector map with more than 2.7 Millions of areas. So I've develop a python function that compute the same values, but it is much faster that the v.to.db module, and should be possible to split the operation in several processes for further speed up... (It is still under testing). On Wednesday 30 Oct 2013 21:04:22 Moritz Lennert wrote: - It uses the v.class.mlpy addon module for classification, so that needs to be installed. Kudos to Vaclav for that module ! It currently only uses the DLDA classifier. The mlpy library offers many more, and I think it should be quite easy to add them. Obviously, one could also simply export the attribute table of the segments and of the training areas to csv files and use R to do the classification. I'm extended to use tree/k-NN/SVM Machine learning from MLPY [1] (I've used also Parzen, but the results were not good enough) and to work also with the scikit [2] classifiers. Scikit it seems to have a larger community and should be easier to install than MLPY, and last but not least it seems generally faster [3]. - Many other variables could be calculated for the segments: other texture variables (possibly variables by segment, not as average of pixel-based variables, cf [1]), other shape variables (cf the new work of MarkusM on center lines and skeletons of polygons in v.voronoi), band indices, etc. It would be interesting to hear what most people find useful. I'm working to add also a C function to the GRASS library to compute the barycentre and the a polar second moment of Area (or Moment of Inertia), that return a number that it is independent from the orientation and dimension. - I do the step of digitizing training areas in the wxGUI digitizer using the attribute editing tool and filling in the 'class' attribute for those polygons I find representative. As already mentioned in previous discussions [2], I do think that it would be nice if we could have an attribute editing form that is independent of the vector digitizer. I use the i.gui.class to generate the training vector map, and then use this map to select the training areas, and export the final results into a file (at the moment only csv and npy formats are supported). More generally, it would be great to get feedback from interested people on this approach to object-based image classification to see what we can do to make it better. I'm definitely interested on the topic! :-) Some days ago I've discussed with MarkusM, that may be I could do a GSoC next year to modify the i.segment module to automatically split the domain in tiles, run as a multiprocess, and then patch only the segments that are on the border of the tiles, this solution should be much faster than my actual solution[0]. Moreover we should consider to skip to transform the segments into vector to extract the shape parameters and extract shape and others parameters (mean, median, skewness, std, etc.) directly as last step before to free the memory from the segments structures, writing a csv/npy file. All the best. Pietro [0] https://github.com/zarch/i.segment.hierarchical [1] http://mlpy.sourceforge.net/ [2] http://scikit-learn.org/ [3] http://scikit-learn.org/ml-benchmarks/ ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] /lib/gis/area_poly1.c: algorithm poorly described, new comments for consideration please
Dear Dev list,
I hope this is the correct place to post a request for an update to two
comments in /lib/gis/area_poly1.c, and replace it with something more
informative.
My remarks are based on reading /lib/gis/area_poly1.c from
grass-7.0.svn_src_snapshot_2013_07_13.
This file has routines for computing areas of polygons on the ellipsoid. The
algorithm is hardly described, and it is not trivial to work out what is going
on. My comment addresses that deficiency.
Regards,
Richard Roger
1. The comment before the routine G_begin_ellipsoid_polygon_area reads:
* \brief Begin area calculations.
*
* This initializes the polygon area calculations for the
* ellipsoid with semi-major axis ia/i (in meters) and ellipsoid
* eccentricity squared ie2/i.
*
* \param a semi-major axis
* \param e2 ellipsoid eccentricity
For the comment to be self-consistent, the last line should be:
* \param e2 ellipsoid eccentricity squared
2.The comment before the routine G_ellipsoid_polygon_area describes briefly
what it
computes:
* bNote:/b This routine assumes grid lines on the connecting the
* vertices (as opposed to geodesics).
I find this comment less than useful. The method this routine implements for
computing area is
not one that I have been able to find explicitly in the literature, i.e., I did
not recognize the Qbar
function nor the QBarA, QbarB, etc., constants. As such, it is not at all
obvious just what area this
routine computes. With some work, I have been able to figure out what is going
on. I suggest
the Note be replaced with, e.g.,
* bNote:/b This routine computes the area of a polygon on the
* ellipsoid. The sides of the polygon are, in general, not geodesics.
* Each side is actually defined by a linear relationship between
* latitude and longitude, i.e., on a rectangular/equidistant
* cylindrical/Plate Carr{'e}e grid, the side would appear as a
* straight line. For two consecutive vertices of the polygon,
* (lat_1, long1) and (lat_2,long_2), the line joining them (i.e., the
* polygon's side) is defined by:
* lat_2 - lat_1
* lat = lat_1 + (long - long_1) * ---
* long_2 - long_1
* where long_1 long long_2. This is not a straight line on
* the ellipsoid.
* The values of QbarA, etc., are determined by the integration of
* the Q function. Into www.integral-calculator.com, paste this
* expression :
*
* sin(x)+ (2/3)e^2(sin(x))^3 + (3/5)e^4(sin(x))^5 + (4/7)e^6(sin(x))^7
*
* and you'll get their values. (Last checked 30 Oct 2013).
*
* This function correctly computes (within the limits of the series
* approximation) the area of a quadrilateral on the ellipsoid when
* two of its sides run along meridians and the other two sides run
* along parallels of latitude.
Dr. R. E. Roger| Senior Spatial Analyst
NSW Department of Primary Industries |NSW Office of Water
181 - 183 Anson Street| Orange NSW 2800 | PO Box 53 | Orange NSW 2800
T: 02 6363 8729 |F: 02 6361 3839 |E: richard.ro...@water.nsw.gov.au
W: www.water.nsw.gov.au ( http://www.trade.nsw.gov.au/ )
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
