Re: [GRASS-dev] [GRASS GIS] #2503: wxdigit: wrong undo redo
#2503: wxdigit: wrong undo redo -+-- Reporter: mlennert | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI| Version: svn-trunk Keywords: digitizer|Platform: Unspecified Cpu: Unspecified | -+-- Comment(by mlennert): Replying to [comment:5 mmetz]: Replying to [comment:4 mlennert]: Replying to [comment:3 mmetz]: Replying to [comment:2 mlennert]: There still is some confusion when one goes back one or two steps, then digitizes something else. The question is what should happen with the available redo steps if digitize something new after some undo steps. Eliminate the redo steps or insert the new changeset before the first redo step? This is handled by the wx digitizer, not the vector lib. I've tried three different programs (LibreOffice Writer, Inkscape and GIMP) and all discard these redo steps,i.e. when you do A, then B, then undo B, then do C, you cannot find B again. This seems to be the most intuitive behaviour to me. OK. When you then undo and redo again, the stack seems to be mixed between the different paths, sometimes leading to objects left on screen even when going all the way back to the last possible undo. It seems that a new changeset is appended after the last redo step if available, leading to a mix-up. Yes. Fixed in trunk r63341, please test. Much better ! There is still one issue I've come upon: when features are automatically modified from the form they are digitized in because of overlaps, the second original feature causing the overlap seems to be erased from the undo stack, meaning that it remains, even if you undo all the way to origin or if you close without saving. To reproduce, digitize a line and then a second line that crosses that line. The lines are correctly split at the intersection. If you then undo the second line remains in its original (unsplit) form. The same is true for two overlapping polygons or a line crossing a polygon. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2503#comment:6 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] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by huhabla): I full agree with Vaclav. However, the modification of GRASS was already performed, regardless the fact that we still discuss the renaming of rast, rast3d and vect options. This, as i already stated before, completely broke the temporal framework. It is not only a matter of renaming option names, the whole internal temporal data type system and handling of different map types was broken because of this. What to do now with temporal module names? Must t.rast.* modules be renamed into t.raster.*? Or t.rast3d.* modules into t.3draster.*? Someone tried to fix the framework by simply renaming rast3d into 3draster, but this did not solved the problem. The framework was still broken. Why was the testsuite not used to check these changes? Why do we have the test-framework anyway? Just a tiny hint: renaming the option n from v.random into npoints broke plenty of temporal vector module tests, since they are using PyGRASS to call v.random and PyGRASS can't handle abbreviations. I needed 5 hours to fix the temporal framework and i am pretty sure that i did not catch all issues that were introduced with the renaming. Putting GRASS in such broken a state without using the testuite to write and use tests or at least to verify the changes with existing tests is IMHO irresponsible. Especially if we plan to make a beta release. I am sorry for my harsh words, but i had to invest 5h for no good reason to keep on with my regular work. Replying to [comment:80 wenzeslaus]: Replying to [comment:79 glynn]: Replying to [comment:77 annakrat]: Replying to [comment:76 cmbarton]: Could it cause a problem somewhere down the line to have this term beginning with a number--e.g. If it is used to name a temp file or something? As I already said, it causes problems for Python because keyword parameter can't start with number. This is solvable by adding underscore and some special handling of this case, which is partially there already. It violates pep8. PEP8 is a style guide. There is no inherent reason why an argument name cannot start with an underscore. And we're not even talking about explicit arguments; such arguments will only ever be obtained via the **kwargs mechanism. The problem may come once you want to use parameter as an variable or member variable. In later case underscore would means private which is technique not limited to Python. I'm also afraid that this can hit us or somebody else in some other language or system. Almost nothing allows numbers at the beginning of identifiers. I also think that for 3D raster it is much more probable that you hit this issue. For example, how should I name variable in my script which holds 3D raster map name or its maximum? `_3draster_name`? `_3draster_max`? I can of course name my variables whatever I want but wouldn't we stick to `rast3d` or `raster3d` in the GRASS source code anyway? In fact, I think that this is why I chose to use a leading underscore rather than a trailing underscore. Still, I'd rather avoid having option names start with a digit. But unless we relax the ambiguity check, it wouldn't outweigh my preference to avoid using an option name which has a very common option name (rast or raster) as a prefix. I'm glad you are saying that. I think it is really important to state the priorities and motivations. If we just want backwards compatibility, then some special check in the parser can handle old short option names. And if we value the most backwards compatibility and short options, we probably should not not shorten at all in these special cases (type names). Perhaps it is useful to ask why we want short options. It is for manual typing? Well then we perhaps should use techniques used elsewhere. And we are actually partially doing it. There is IDE-like auto-complete in GUI, Python dir completed is implemented for PyGRASS module interface and of course Linux command line auto-completes module names. So why not to take it further and auto-complete also parameters and perhaps other things by implementing auto-complete for shell? Classic unix-like command line is anyway the only place where short options really matter if you consider the things above and also that you should not use shortened option names in scripts because
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by martinl): Replying to [comment:85 huhabla]: I needed 5 hours to fix the temporal framework and i am pretty sure that i did not catch all issues that were introduced with the renaming. sorry for that, *BUT* we were speaking about consolidation of parameters *MANY YEARS* ago! But *NOTHING* really *CHANGED* till now. I agree with you that we are too late with that but I still think that it made sense to do it. Putting GRASS in such broken a state without using the testuite to write and use tests or at least to verify the changes with existing tests is IMHO irresponsible. Especially if we plan to make a beta release. See my note above... -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:86 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] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by huhabla): Replying to [comment:86 martinl]: Replying to [comment:85 huhabla]: I needed 5 hours to fix the temporal framework and i am pretty sure that i did not catch all issues that were introduced with the renaming. sorry for that, *BUT* we were speaking about consolidation of parameters *MANY YEARS* ago! But *NOTHING* really *CHANGED* till now. I agree with you that we are too late with that but I still think that it made sense to do it. Putting GRASS in such broken a state without using the testuite to write and use tests or at least to verify the changes with existing tests is IMHO irresponsible. Especially if we plan to make a beta release. See my note above... Dear Martin, many thanks for all of your effort. I am not arguing about the sense of the changes. As i stated before i am fine with them. I simply have a problem how these changes are applied. We have a wonderful test suite that will help you to avoid breaking parts of GRASS. We should make use of it to avoid such a discussion. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:87 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] #2503: wxdigit: wrong undo redo
#2503: wxdigit: wrong undo redo -+-- Reporter: mlennert | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI| Version: svn-trunk Keywords: digitizer|Platform: Unspecified Cpu: Unspecified | -+-- Comment(by mmetz): Replying to [comment:6 mlennert]: There is still one issue I've come upon: when features are automatically modified from the form they are digitized in because of overlaps, the second original feature causing the overlap seems to be erased from the undo stack, meaning that it remains, even if you undo all the way to origin or if you close without saving. To reproduce, digitize a line and then a second line that crosses that line. The lines are correctly split at the intersection. If you then undo the second line remains in its original (unsplit) form. The same is true for two overlapping polygons or a line crossing a polygon. The list of updated lines as returned by the vector lib was incomplete. Fixed in r63349,50 (trunk, relbr70), please test. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2503#comment:7 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] #2506: g.rename fails to rename map when there is already map of the same name in PERMENENT
#2506: g.rename fails to rename map when there is already map of the same name
in
PERMENENT
-+--
Reporter: annakrat | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Default | Version: svn-trunk
Keywords: g.rename |Platform: Unspecified
Cpu: Unspecified |
-+--
In a mapset (different than PERMANENT) I run:
{{{
g.rename raster=mymap,elevation
WARNING: elevation already exists in mapset PERMANENT
}}}
It doesn't rename it. When I use overwrite, it works. Still it seems it's
a bug.
Also when I add there my current mapset, it fails, and I thought we
decided that current mapset should be supported when specifying output map
names.
{{{
g.rename raster=mymap,elevation@mycurrentmapset
WARNING: Illegal filename elevation@mycurrentmapset. Character @ not
allowed.
WARNING: elevation@mycurrentmapset is an illegal file name
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2506
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] Individual vector feature processing: v.clump?
Hi, for a calculation I need to loop over all vector features in a map in order to perform individually a computation. For that I cannot use the category information since it may be used as 1:n link. I wonder if a new v.clump command would make sense or the addition of a new method in v.category to simplify this task? Eventually I would implement the processing loop as a Python script. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2506: g.rename fails to rename map when there is already map of the same name in PERMENENT
#2506: g.rename fails to rename map when there is already map of the same name in PERMENENT -+-- Reporter: annakrat | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Default | Version: svn-trunk Keywords: g.rename |Platform: Unspecified Cpu: Unspecified | -+-- Comment(by martinl): The map is not renamed because G70 still uses abbreviated element names (ie. `rast`). `g.rename` silently fails because of source:grass/branches/releasebranch_7_0/lib/manage/list.c#L47 -- Ticket URL: http://trac.osgeo.org/grass/ticket/2506#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 GIS] #2506: g.rename fails to rename map when there is already map of the same name in PERMENENT
#2506: g.rename fails to rename map when there is already map of the same name in PERMENENT -+-- Reporter: annakrat | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Default | Version: svn-trunk Keywords: g.rename |Platform: Unspecified Cpu: Unspecified | -+-- Comment(by martinl): In GRASS 71 (trunk) it works. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2506#comment:2 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] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options |Platform: Unspecified
Cpu: Unspecified |
--+-
Comment(by martinl):
Replying to [comment:87 huhabla]:
many thanks for all of your effort.
personally I am not happy with these changes too. They should have been
done much more earlier, now it's very late. But still I think it's better
than not to do it at all. Anyway I am not happy about this situation.
I am not arguing about the sense of the changes. As i stated before i am
fine with them. I simply have a problem how these changes are applied. We
have a wonderful test suite that will help you to avoid breaking parts of
GRASS. We should make use of it to avoid such a discussion.
Let's try to focus on element list name. Under condition that we don't
want to use abbreviated names, what is your preference
{{{
raster3d*
volume
3draster
}}}
(*) Then we could modify parser to understand also `rast` and `rast3d`
with appropriate warning
{{{
g.list rast
WARNING: Element rast has been renamed raster. Please update your
script.
...
g.list rast3d
WARNING: Element rast3d has been renamed raster3d. Please update your
script.
...
}}}
What do you think?
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:88
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-SVN] r63227 - in grass/trunk/scripts: d.correlate d.out.file d.rast.leg d.redraw d.shadedmap d.to.rast d.vect.thematic d.what.rast d.what.vect
Vaclav Petras wrote: The issue is this: GRASS 7.1.svn (nc_spm_08_grass7):~ g.region rast=lsat7_2002_30 GRASS 7.1.svn (nc_spm_08_grass7):~ d.correlate map=lsat7_2002_30,lsat7_2002_40 ERROR: No graphics device selected. Use d.mon to select graphics device. Traceback (most recent call last): ... grass.exceptions.CalledModuleError: Module run None ['d.text', 'color=black', 'line=1', 'stdin=CORRELATION', 'size=4'] ended with error Process ended with non-zero return code 1. See errors in the (error) output. I can't reproduce the problem. And I'm not even sure how d.text can exit with a non-zero return code without printing any error message. I can reproduce it. Are you sure you don't have MONITOR or GRASS_RENDER_IMMEDIATE (or any other if it matters) set? I start GRASS session (without any special shell environment) and I get it. The error is the beginning, r.text is printed first (that's ERROR:... I think), then the error from the main process is printed (Traceback). Er, right; I got confused by the fact that the script changes used exactly the same error message as d.text (which is a leftover from 6.x). The issue has been fixed in r63361. The issue was first introduced in r46984 and incorrectly fixed in r46999. In GRASS 7, it isn't (or shouldn't have been) necessary to set GRASS_RENDER_IMMEDIATE. This variable only exists to choose a driver other than the default (cairo if supported, otherwise PNG). I think the solution is try-except or calling the function(s) with with secret `errors` parameter set to 'exit'. No. There's no point in catching exceptions if you aren't going to handle them. If we want to avoid the tracebacks, we should find a solution which works globally, not require each and every script to manually handle exceptions from each and every called module. -- 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] [GRASS GIS] #2503: wxdigit: wrong undo redo
#2503: wxdigit: wrong undo redo -+-- Reporter: mlennert | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI| Version: svn-trunk Keywords: digitizer|Platform: Unspecified Cpu: Unspecified | -+-- Comment(by mlennert): Replying to [comment:7 mmetz]: Replying to [comment:6 mlennert]: There is still one issue I've come upon: when features are automatically modified from the form they are digitized in because of overlaps, the second original feature causing the overlap seems to be erased from the undo stack, meaning that it remains, even if you undo all the way to origin or if you close without saving. To reproduce, digitize a line and then a second line that crosses that line. The lines are correctly split at the intersection. If you then undo the second line remains in its original (unsplit) form. The same is true for two overlapping polygons or a line crossing a polygon. The list of updated lines as returned by the vector lib was incomplete. Fixed in r63349,50 (trunk, relbr70), please test. Still not quite: [http://tomahawk.ulb.ac.be/moritz/wxdigit_undo_redo4.ogv]. If you need more explanation, I can write some, but right now I have to go. Moritz -- Ticket URL: https://trac.osgeo.org/grass/ticket/2503#comment:8 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] addons dependencies
On 01/12/14 18:07, Markus Neteler wrote: On Mon, Dec 1, 2014 at 4:18 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 28/11/14 23:41, Martin Landa wrote: ... please try out r63275. Martin v.in.wfs2 now runs (although it bails out because of the recent change in parameters (v.in.ogr dsn - input). I thought that this would be caught by the updated parser magic via lib/gis/renamed_options? Ah, v.in.ogr wasn't registered yet, so done in r63317 (and r63318 respectively). Please try again, Yes, now it works. Only weird thing: v.in.wfs2 url= http://geoserver.gis.irisnet.be/ows layers=urbis:URB_A_MZ output=urbis srs=31370 Downloading data from WFS server... Reprojecting data... Importing vector map into GRASS... WARNING: Please update the interface of the module: option dsn has been renamed to input For the user it is not clear where this warning comes from as dsn in not a parameter in v.in.wfs2. But this is true for all warnings of v.in.ogr in this module, so it is a different problem. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] addons dependencies
Hi, 2014-12-03 19:07 GMT+01:00 Moritz Lennert mlenn...@club.worldonline.be: v.in.wfs2 url= http://geoserver.gis.irisnet.be/ows layers=urbis:URB_A_MZ output=urbis srs=31370 Downloading data from WFS server... Reprojecting data... Importing vector map into GRASS... WARNING: Please update the interface of the module: option dsn has been renamed to input please try out r63362. WARNING: Please update the user interface of v.in.ogr: option dsn has been renamed to input Is it better? Martin -- 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
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by glynn): Replying to [comment:84 wenzeslaus]: As I said before, short options are mostly advantageous for unix-like command lines, so let's use what it used there, the Tab key auto-complete. We shouldn't rely upon this feature being available. And even when it is, it's not automatically better than abbreviation (e.g. completion is affected by latency, abbreviation isn't). -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:89 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] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options |Platform: Unspecified
Cpu: Unspecified |
--+-
Comment(by glynn):
Replying to [comment:88 martinl]:
Let's try to focus on element list name. Under condition that we don't
want to use abbreviated names, what is your preference
{{{
raster3d*
volume
3draster
}}}
My preference would be volume; the other two have issues. We can debate
forever about how significant those issues are, but volume avoids them
entirely.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:90
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] #2506: g.rename fails to rename map when there is already map of the same name in PERMENENT
#2506: g.rename fails to rename map when there is already map of the same name
in
PERMENENT
-+--
Reporter: annakrat | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Default | Version: svn-trunk
Keywords: g.rename |Platform: Unspecified
Cpu: Unspecified |
-+--
Comment(by wenzeslaus):
Replying to [comment:2 martinl]:
In GRASS 71 (trunk) it works.
Not for me with older trunk. I have r62726 (before any renaming) and I'm
getting:
{{{
r.mapcalc aaa = 1
100%
g.list rast mapset=.
aaa
g.rename rast=aaa,elevation
WARNING: elevation already exists in mapset PERMANENT
g.list rast mapset=.
aaa
g.rename rast=aaa,elevation --o
Rename raster aaa to elevation
g.list rast mapset=.
elevation
}}}
{{{
GRASS version: 7.1.svn
GRASS SVN Revision: 62726M
Build Date: 2014-11-18
Build Platform: x86_64-unknown-linux-gnu
GDAL/OGR: 1.10.1
PROJ.4: 4.8.0
GEOS: 3.4.2
SQLite: 3.8.2
Python: 2.7.6
wxPython: 2.8.12.1
Platform: Linux-3.13.0-40-generic-x86_64-with-Ubuntu-14.04-trusty
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2506#comment:3
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] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options |Platform: Unspecified
Cpu: Unspecified |
--+-
Comment(by wenzeslaus):
Replying to [comment:90 glynn]:
Replying to [comment:88 martinl]:
Let's try to focus on element list name. Under condition that we don't
want to use abbreviated names, what is your preference
{{{
raster3d*
volume
3draster
}}}
My preference would be volume; the other two have issues. We can
debate forever about how significant those issues are, but volume avoids
them entirely.
`volume` avoids issues with naming variables but creates issues when
talking with people. From my experience, volume is very confusing while 3D
raster (- `raster3d`) works because it is very explanatory and it is not
a [http://en.wikipedia.org/wiki/Homonym homonym]. Voxel seems not be an
option anymore but it is a term which people react to time to time because
it is at least clear that it is something special (not a
[http://en.wikipedia.org/wiki/Volume volume] in liters).
BTW, Wikipedia is not really helpful in deciding about
`volume`/`voxel`/`raster3d` but it links not really related
[http://skuld.bmsc.washington.edu/raster3d/raster3d.html Raster3D]
software ([http://en.wikipedia.org/wiki/Raster_graphics#External_links
Raster graphics]) and it talks about ''2D and 3D raster and vector'' when
it is describing a book
[http://en.wikipedia.org/wiki/Computer_Graphics:_Principles_and_Practice#Second_Edition
Computer Graphics: Principles and Practice] which is highly related.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:91
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] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options |Platform: Unspecified
Cpu: Unspecified |
--+-
Comment(by annakrat):
Replying to [comment:90 glynn]:
Replying to [comment:88 martinl]:
Let's try to focus on element list name. Under condition that we don't
want to use abbreviated names, what is your preference
{{{
raster3d*
volume
3draster
}}}
My preference would be volume; the other two have issues. We can
debate forever about how significant those issues are, but volume avoids
them entirely.
So if we decide for volume, do we plan to rename all modules like this? If
not, we should stay with raster3d. Otherwise it will get very confusing in
my opinion.
{{{
r3.info - vo.info
r.to.rast3- t.to.volume
}}}
I must say I am not particularly fond of vo.* modules, but maybe it's just
a matter of habit.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:92
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] sample vector temporal data
Hi devs, In r63363 I submitted an update of space time doc for several modules using the new temporal dataset. I'm going to make the new dataset available in the next days to test and comment it. Stay tuned ;-) -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options |Platform: Unspecified
Cpu: Unspecified |
--+-
Comment(by hcho):
Replying to [comment:90 glynn]:
Replying to [comment:88 martinl]:
Let's try to focus on element list name. Under condition that we don't
want to use abbreviated names, what is your preference
{{{
raster3d*
volume
3draster
}}}
My preference would be volume; the other two have issues. We can
debate forever about how significant those issues are, but volume avoids
them entirely.
+1 for volume (+2 for voxel) for the exact same reason.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:93
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] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by martinl): Replying to [comment:93 hcho]: +1 for volume (+2 for voxel) for the exact same reason. -1 for voxel, than we could rename 'raster' to 'pixel' ;-) I am still not sure we need to rename than all modules from `r3` to `vo`... -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:94 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] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by helena): Replying to [comment:94 martinl]: Replying to [comment:93 hcho]: +1 for volume (+2 for voxel) for the exact same reason. -1 for voxel, than we could rename 'raster' to 'pixel' ;-) I am still not sure we need to rename than all modules from `r3` to `vo`... so is there also an agreement to rename all r3.* commands to vo.* commands and changing all manuals accordingly? If yes, this will require several weeks of focused testing and reviews/updates of all grass7 related manuals, tutorials and scripts.I don't have a good solution for this issue but I am not a big fan of changing names unless it is absolutely necessary or leads to a major improvement. Reading through the discussion I am wondering whether anybody has done a solid research on what are the 3D rasters referred to in different disciplines and which term is closest to our users backgrounds or are all these three names that are being considered based on what each individual thinks is right? Which brings me to another point - is this being discussed on the users list as well? The users will be the ones most affected (and potentially confused) so why not get some feedback from them? -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:95 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] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by martinl): Replying to [comment:95 helena]: -1 for voxel, than we could rename 'raster' to 'pixel' ;-) I am still not sure we need to rename than all modules from `r3` to `vo`... so is there also an agreement to rename all r3.* commands to vo.* commands and changing all manuals accordingly? If yes, this will require several weeks of focused testing and not at all, personally I don't like to stick with shortened element names (rast, rast3d) just because it makes our life easier. Taking in account a real world it seems to me that the reasonable is to rename `rast - raster` and `rast3d - raster3d` and to modify the parser to understand also shortened element names. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:96 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] Individual vector feature processing: v.clump?
On Wed, Dec 3, 2014 at 5:51 PM, Markus Neteler nete...@osgeo.org wrote: Hi, for a calculation I need to loop over all vector features in a map in order to perform individually a computation. For that I cannot use the category information since it may be used as 1:n link. I wonder if a new v.clump command would make sense or the addition of a new method in v.category to simplify this task? Adding unique categories to a new layer for the features in question with v.category (take care of the type option) does not work in this case? Markus M Eventually I would implement the processing loop as a Python script. 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] [GRASS GIS] #2503: wxdigit: wrong undo redo
#2503: wxdigit: wrong undo redo -+-- Reporter: mlennert | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI| Version: svn-trunk Keywords: digitizer|Platform: Unspecified Cpu: Unspecified | -+-- Comment(by mmetz): Replying to [comment:8 mlennert]: Replying to [comment:7 mmetz]: The list of updated lines as returned by the vector lib was incomplete. Fixed in r63349,50 (trunk, relbr70), please test. Still not quite: [http://tomahawk.ulb.ac.be/moritz/wxdigit_undo_redo4.ogv]. If you need more explanation, I can write some, but right now I have to go. Got it. This bug (yet another one) should be fixed in r63364,5 (trunk only). -- Ticket URL: https://trac.osgeo.org/grass/ticket/2503#comment:9 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] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by cmbarton): Can raster_3D be better parsed in long and shortened form? Michael -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:97 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] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by annakrat): Replying to [comment:97 cmbarton]: Can raster_3D be better parsed in long and shortened form? It has the same issues as raster3d, still rast is ambiguous. You can shorten raster_3D to rast3d or r3 but you can't shorten raster. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:98 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] Individual vector feature processing: v.clump?
On Wed, Dec 3, 2014 at 9:47 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Wed, Dec 3, 2014 at 5:51 PM, Markus Neteler nete...@osgeo.org wrote: Hi, for a calculation I need to loop over all vector features in a map in order to perform individually a computation. For that I cannot use the category information since it may be used as 1:n link. I wonder if a new v.clump command would make sense or the addition of a new method in v.category to simplify this task? Adding unique categories to a new layer for the features in question with v.category (take care of the type option) does not work in this case? Likely it does (I am asking on behalf on another person not subscribed here). I wonder how to make it more obvious. And, if there is a best practice example written in Python/PyGRASS? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] addons dependencies
On Wed, Dec 3, 2014 at 7:17 PM, Martin Landa landa.mar...@gmail.com wrote: 2014-12-03 19:07 GMT+01:00 Moritz Lennert mlenn...@club.worldonline.be: v.in.wfs2 url= http://geoserver.gis.irisnet.be/ows layers=urbis:URB_A_MZ output=urbis srs=31370 Downloading data from WFS server... Reprojecting data... Importing vector map into GRASS... WARNING: Please update the interface of the module: option dsn has been renamed to input please try out r63362. WARNING: Please update the user interface of v.in.ogr: option dsn has been renamed to input To me that sounds a bit misleading since we don't need to update v.in.ogr. How about WARNING: Please update the usage of v.in.ogr: option dsn has been renamed to input ? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
