Re: [GRASS-dev] [GRASS GIS] #2440: remove unused elements from g.list/g.remove
#2440: remove unused elements from g.list/g.remove +--- Reporter: annakrat| Owner: grass-dev@… Type: task| Status: new Priority: blocker | Milestone: 7.0.0 Component: LibGIS | Version: svn-releasebranch70 Keywords: elements, g.remove |Platform: All Cpu: Unspecified | +--- Comment(by martinl): Replying to [comment:11 martinl]: http://grass.osgeo.org/grass70/manuals/v.out.ascii.html If old version is requested, the output files from v.out.ascii is placed in the $LOCATION/$MAPSET/dig_ascii/ and $LOCATION/$MAPSET/dig_att directory. So, it stems from GRASS GIS 4 and older. Random citation: GRASS-Intergraph Data Conversion Guide by V Harmon - 1992, http://www.dtic.mil/get-tr-doc/pdf?AD=ADA251458 (p. 14) Less used nowadays :-) if it's only one usage I would still to vote for removing it from element list. What do you think? any option? -- Ticket URL: http://trac.osgeo.org/grass/ticket/2440#comment:12 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-PSC] RFC4 discussion call
Dear all, I went trough the document and it make perfectly sense to me. Just a minor comment is that we shall probably clearly specify who is responsible for the mentioned actions: call for soft, hard freeze etc. Basically who is responsible to recall all to the respect of the mentioned time-frame. Maxi Il giorno Wed Jan 07 2015 at 2:43:33 AM Scott Mitchell smi...@me.com ha scritto: Since I'm in there anyway editing a couple of minor grammatical fixes, I've deleted that sentence based on this latest exchange plus the fact that it makes sense to me. But I'm doing so in the comfort of knowing that my edits can be easily reverted, so don't hesitate if there's reason. On Jan 6, 2015, at 05:35, Moritz Lennert mlenn...@club.worldonline.be wrote: On 06/01/15 11:25, Martin Landa wrote: Hi all, 2014-12-30 0:29 GMT+01:00 Markus Neteler nete...@osgeo.org: I agree with Maris that no feedback should be interpreted as agreement. I would also agree with that. It would be reasonable also to set some deadline for discussion and then to propose voting. What do you think? http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure?action=diffversion=7old_version=6 I did cosmetics changes [1]. I found that a tbd is still there. I would suggest to simply delete this sentence. Creating extra branch for such purpose seems to be not necessary to me. Any opinion on that? +1 Moritz ___ grass-psc mailing list grass-...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc ___ grass-psc mailing list grass-...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2522: d.vect.thematic, d.thematic.area in GRASS 7.0
#2522: d.vect.thematic, d.thematic.area in GRASS 7.0 --+- Reporter: martinl | Owner: grass-dev@… Type: defect| Status: new Priority: blocker | Milestone: 7.0.0 Component: Display | Version: svn-trunk Keywords: d.vect.thematic, d.thematic.area |Platform: Unspecified Cpu: Unspecified | --+- Comment(by martinl): Replying to [ticket:2522 martinl]: * to move python script `d.vect.thematic` to addons I moved `d.vect.thematic` to addons as `d.vect.thematic2` in r63974:63975 * rename `d.thematic.area` to `d.thematic` or better `d.vect.thematic` (in this case to rename `d.vect.thematic` in addons to `d.vect.thematic2`) - any other name? done in r63976:63983. If no objection I will backported to relbr70. In the future to improve C module based on functionality of Python script. [...] -- Ticket URL: http://trac.osgeo.org/grass/ticket/2522#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
Re: [GRASS-dev] [GRASS-PSC] RFC4 discussion call
On Jan 7, 2015, at 4:20 PM, Markus Neteler wrote: On Wed, Jan 7, 2015 at 9:26 AM, Massimiliano Cannata massimiliano.cann...@supsi.ch wrote: Dear all, I went trough the document and it make perfectly sense to me. I agree. I updated its date now and expanded RC in the beginning. http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure Last doubts: * Step1: The Project manager (or if exists the Release manager) then collects reactions to decide whether there is sufficient support for this proposal. -- this sufficient is still a bit elastic. If one developer is against it, others in favour, it is fine to start? Leave it to democratical debates? Just to be sure. I changed to decide to and decides so it is more clear that it is at the discretion of the Project/Release manager to decide whether there is sufficient support. If Project manager cannot decide by himself (e.g. he/she is not sure), he/she can always call for a vote by PSC. Just a minor comment is that we shall probably clearly specify who is responsible for the mentioned actions: call for soft, hard freeze etc. That's the release manager. But I added that now (looks more dramatic than it is, trac doesn't highlight well this time).: http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure?action=diffversion=16old_version=13 ... makes sense? I made small language edits which did not change the meaning of the document and I agree with the document. Helena Markus ___ grass-psc mailing list grass-...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-PSC] RFC4 discussion call
On Tue, Jan 6, 2015 at 11:25 AM, Martin Landa landa.mar...@gmail.com wrote: I would also agree with that. It would be reasonable also to set some deadline for discussion and then to propose voting. What do you think? For this RFC? Yes. But I think we are pretty close now. I did cosmetics changes [1]. [1] http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure?action=diffversion=12old_version=7 Thanks I would suggest to simply delete this sentence. Creating extra branch for such purpose seems to be not necessary to me. Any opinion on that? I *fully* agree. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Tests down to 78% (from 84%), mostly PyGRASS
On Mon, Jan 5, 2015 at 4:15 PM, Martin Landa landa.mar...@gmail.com wrote: 2015-01-05 21:21 GMT+01:00 Markus Neteler nete...@osgeo.org: No problem. The only remaining thing which I don't understand how to fix it is this: File ./lib/gis/testsuite/gis_lib_env_test.py, line 31, in test_gisrc libgis.G__read_gisrc_env() AttributeError: 'module' object has no attribute 'G__read_gisrc_env' done in r63960 (and backported). Martin Thanks but the tests are failing with different error now: Traceback (most recent call last): File lib/python/pygrass/raster/testsuite/test_raster.py, line 6, in module from grass.pygrass.raster import RasterRow File etc/python/grass/pygrass/raster/__init__.py, line 24, in module from grass.pygrass.gis.region import Region File etc/python/grass/pygrass/gis/__init__.py, line 22, in module 'icon': libgis.G_ELEMENT_ICON, AttributeError: 'module' object has no attribute 'G_ELEMENT_ICON' http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-01-07-08-00/report_for_nc_spm_08_grass7_nc/testfiles.html 2015-01-07 03:01:42 63971 nc_spm_08_grass7 79% 99% -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ 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] Tests down to 78% (from 84%), mostly PyGRASS
Hi Vaclav, Il 07/gen/2015 16:11 Vaclav Petras wrote: Thanks but the tests are failing with different error now: Traceback (most recent call last): File lib/python/pygrass/raster/testsuite/test_raster.py, line 6, in module from grass.pygrass.raster import RasterRow File etc/python/grass/pygrass/raster/__init__.py, line 24, in module from grass.pygrass.gis.region import Region File etc/python/grass/pygrass/gis/__init__.py, line 22, in module 'icon': libgis.G_ELEMENT_ICON, AttributeError: 'module' object has no attribute 'G_ELEMENT_ICON' I saw the error this morning. Should be fixed in r63972. Pietro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-PSC] RFC4 discussion call
On Wed, Jan 7, 2015 at 9:26 AM, Massimiliano Cannata massimiliano.cann...@supsi.ch wrote: Dear all, I went trough the document and it make perfectly sense to me. I agree. I updated its date now and expanded RC in the beginning. http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure Last doubts: * Step1: The Project manager (or if exists the Release manager) then collects reactions to decide whether there is sufficient support for this proposal. -- this sufficient is still a bit elastic. If one developer is against it, others in favour, it is fine to start? Leave it to democratical debates? Just to be sure. Just a minor comment is that we shall probably clearly specify who is responsible for the mentioned actions: call for soft, hard freeze etc. That's the release manager. But I added that now (looks more dramatic than it is, trac doesn't highlight well this time).: http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure?action=diffversion=16old_version=13 ... makes sense? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-PSC] RFC4 discussion call
Hi, I read the document and support it, On Wed, Jan 7, 2015 at 10:20 PM, Markus Neteler nete...@osgeo.org wrote: Last doubts: * Step1: The Project manager (or if exists the Release manager) then collects reactions to decide whether there is sufficient support for this proposal. -- this sufficient is still a bit elastic. If one developer is against it, others in favour, it is fine to start? Leave it to democratical debates? Just to be sure. To me this makes sense, because it's a good thing that the release manager should have the chance to make a decision on a case by case basis. I'm more in favor of do-ocracy rather than democratical debate ;-) but it's just my opinion Just a minor comment is that we shall probably clearly specify who is responsible for the mentioned actions: call for soft, hard freeze etc. That's the release manager. But I added that now (looks more dramatic than it is, trac doesn't highlight well this time).: http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure?action=diffversion=16old_version=13 ... makes sense? +1 Thank you Margherita -- Best regards, Dr. Margherita DI LEO Scientific / technical project officer European Commission - DG JRC Institute for Environment and Sustainability (IES) Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-...@jrc.ec.europa.eu Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Is grass70b4 compiling on FreeBSD ?
Fábio Dias wrote: The files /usr/include/iconv.h and /usr/local/include/iconv.h are different. Does /usr/include/iconv.h contain the macros? #define iconv_open libiconv_open #define iconv libiconv #define iconv_close libiconv_close If not, it looks like it's now picking up some other iconv.h. According to this: https://www.freebsd.org/doc/en/books/porters-handbook/using-iconv.html FreeBSD 10-CURRENT and later has iconv in libc, so no additional libraries should be linked. But that will require the use of the system iconv.h rather than a libiconv iconv.h. I removed the local one, re-run ./configure (both iconv related messages: yes) and gmake. Same deal. No -liconv included on include/Make/Platform.make, same error when linking. I also removed the --with-includedir=local and added iconv.h from another dir: /configure --with-includes=~/ --with-postgres --with-pthread --with-gdal --with-includes=/usr/local/include --with-libs=/usr/local/lib --with-freetype-includes=/usr/local/include/freetype2 --with-readline --with-geos --with-wxwidgets --with-lapack --with-sqlite Same deal. It says yes for both iconv tests and doesn't link it. Can you show the actual compilation commands being used, specifically for parser_interface.c in lib/gis (that's where the lib/gis - iconv dependency comes from; lib/driver and lib/cairodriver also have iconv dependencies)? -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] point cloud analysis: new features
On Mon, Jan 5, 2015 at 12:17 PM, Benjamin Ducke bendu...@fastmail.fm
wrote:
On 04/01/15 23:00, Paulo van Breugel wrote:
Tried it out, and it works like a charm, great!
One question/request, would it be terribly difficult to add an option to
compute an user-defined number of clusters of equal size?
I think you are looking for a completely different algorithm
there. There are many clustering methods that will produce
exactly k clusters. But what do you mean by size: number of
points per cluster or spatial extent/area?
Yes, I was looking at something similar to what the function stratify in
the R spcosa package does: Methods for partitioning a spatial object into
compact strata by means of k-means. The objective function to minimize is
the mean squared shortest distance (MSSD). Optionally, the strata may be
forced to be of equal size. This facilitates field work in case of
stratified simple random sampling for composites. The key here is to
create as compact strata as possible, optionally of equal size (number of
points per cluster).
In both cases, I am not sure how you would reconcile the
two opposing goals: (A) find the actual cluster shapes,
(B) make the cluster shapes so that all clusters are of
equal size.
(please see also my comment to Markus below).
On Sun, Jan 4, 2015 at 9:02 PM, Markus Metz
markus.metz.gisw...@gmail.com mailto:markus.metz.gisw...@gmail.com
wrote:
Done in trunk r63952 as v.cluster. It is not a GRASS7 addon because
it
does not work with G7.0. At the moment it only identifies and labels
clusters. Connectivity graphs and cluster shapes are not implemented.
In future, I would like to add OPTICS because OPTICS can better
handle
different clusters with different densities.
Thanks Markus, this is excellent progress.
It seems to me that the approximation of cluster shapes from grouped
points is a generic problem that would best be solved with a separate
module. As long as the shapes are roughly convex, the existing v.hull
should work fine. For concave shapes, AFAIK things become messy because
common methods such as alpha shapes require the user to provide
threshold values.
Cheers,
Ben
Markus M
There is a reference implementation (albeit in Java) that you can
use to compare it with other clustering algorithms:
http://elki.dbs.ifi.lmu.de/
An implementation in C (that I have not tried) is here:
https://github.com/siddharth950/DBSCAN
The one drawback of DBSCAN is that it needs an efficient spatial
index to perform well -- and you have just taken care of that!
- point cloud thinning: a sample can be generated from a large
point
cloud by specifying a minimum distance between sample points. To
be
implemented.
The new k-d tree is now used by v.clean tool=snap
(Vect_snap_lines()),
reducing both memory consumption and processing time.
I would also like to point out that SAGA GIS is moving into
the same direction, i.e. more efficient processing of very
large point clouds. The latest release includes a number
of new point cloud tools. Perhaps it's worth a look.
Most importantly, SAGA GIS has introduced a new file format,
the SAGA Pointcloud (.spc) format. It is compact and yet
flexible enough for a variety of purposes. I recommend to
consider implementing import/export of this format in GRASS 7,
preferably not via v.in.ogr, to avoid the OGR model conversion
overhead.
If you think this would be an interesting option, then you can
find a summary on our tracker:
http://gvsigce.sourceforge.net/mantis/view.php?id=595
(we are going to implement .spc in gvSIG CE, as well).
Best wishes,
Ben
More technical:
the new k-d tree finds the exact nearest neighbor(s), not some
approximation. It supports up to 255 dimensions. It is dynamic,
i.e.
points can be inserted and removed at any time. It is balanced to
improve search performance. It provides k nearest neighbor search
(find k neighbors to a given coordinate) as well as radius or
distance
search (find all neighbors within radius, i.e. not farther away
than
radius to a given coordinate).
Markus M
___
grass-dev mailing list
grass-dev@lists.osgeo.org mailto:grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Dr. Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
Spatial technology for the masses, not the classes:
experience free and open source GIS at http://gvsigce.org
Re: [GRASS-dev] compile gdal with grass
Hi Martin, just recompiled GDAL against GRASS, and I can confirm it works. Thanks for the fix! On Mon, Jan 5, 2015 at 3:50 PM, Martin Landa landa.mar...@gmail.com wrote: Hi, 2015-01-05 15:32 GMT+01:00 Markus Neteler nete...@osgeo.org: On Mon, Jan 5, 2015 at 12:56 PM, Martin Landa landa.mar...@gmail.com wrote: ... these errors are related to the recent API changes in GRASS 7. I fixed that in gdal trunk [1] and later will do backport it to gdal 1.11 branch. done in r28291. To compile GDAL against GRASS you need at least GDAL 1.11 from svn branch [1]. Martin [1] http://svn.osgeo.org/gdal/branches/1.11/ -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
