Re: [GRASS-dev] [GRASS GIS] #1889: wxPy loc'n wiz: don't auto-launch into PERMANENT
#1889: wxPy loc'n wiz: don't auto-launch into PERMANENT -+-- Reporter: hamish | Owner: grass-dev@… Type: defect | Status: new Priority: blocker | Milestone: 6.4.3 Component: wxGUI| Version: 6.4.3 RCs Keywords: location wizard |Platform: Unspecified Cpu: x86-64 | -+-- Changes (by marisn): * platform: MSWindows 7 = Unspecified Comment: Hamish, You were faster today. I would also suggest to go back to previous behaviour when user was taken back to start page. It's possible to preselect new location and PERMANENT mapset to save clicks, but it is also giving ability to create more mapsets and work in one of them. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1889#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] #335: export floats and doubles with correct precision
#335: export floats and doubles with correct precision ---+ Reporter: hamish | Owner: grass-dev@… Type: task | Status: new Priority: critical | Milestone: 6.4.4 Component: Default| Version: svn-develbranch6 Keywords: precision |Platform: All Cpu: All| ---+ Comment(by hamish): Replying to [comment:21 mmetz]: Glynn: Binary to text conversions must use %.9g (float) and %.17g (double) in order to preserve fp values in a binary-decimal-binary round-trip, e.g. r.out.ascii followed by r.in.ascii. take care that preserving b-d-b round trip ,on a single platform, is not the only task or consideration. For the r.out.ascii + r.in.ascii round trip it may well be appropriate, but while conceding that point I'd argue that r.*.bin or r.*.mat would be a better choice in those cases. %.15,7g was chosen because it's perfectly reproducible and doesn't introduce useless .0001 crap into the data files which G_trim_decimal() can't handle. For things like r.univar, r.info, and v.db.select the output is at least in part for human consumption; there's no practical need to expose the FP noise. The main thing for us to focus on I think is all the remaining lossy %f and meaningless %.56f type stuff in the code, not splitting hairs over preserving quanta finer than GRASS_EPSILON. wrt lib/gis/color_write.c, look closely you'll see there is a +/- GRASS_EPSILON adjustment on the range to ensure that the rounding exceeds the range, and so you shouldn't ever get white spots at the peaks and pits. best, Hamish (this is something I hope python cleans up with 3.0) -- Ticket URL: http://trac.osgeo.org/grass/ticket/335#comment:23 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] question about new query
On 19/02/13 09:44, Martin Landa wrote: Hi, 2013/2/19 Anna Kratochvílovákratocha...@gmail.com: [...] the previous system allows to change attributes by querying which is in my opinion wrong behavior (#1608). Currently, you can change the attributes in the attribute manager and in the digitizer. I agree that it is less convenient than before. So the query dialog could on request display Attribute Manager with dialog for editing record or DisplayAttributesDialog? I would agree with Anna. Attributes should be editable only in specific mode (in digitizer) or by specialized tool (attribute table manager). I agree that editable attributes should not be the default, but I've also always found unelegant to have to activate digitization (and so the possibility of accidentally changing the map features) just in order to be able to change an attribute. Also, the possibility to click on an object to change its attributes is IMHO a basic feature any GIS should have, and having to identify the object in the attribute manager through other means (e.g. SQL search) is not the same. Why not go back to the old way of offering both options: default is dialog without editing (valid for both vector and raster), but also an option for vector map querying with editable fields ? Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1889: wxPy loc'n wiz: don't auto-launch into PERMANENT
#1889: wxPy loc'n wiz: don't auto-launch into PERMANENT -+-- Reporter: hamish | Owner: grass-dev@… Type: defect | Status: new Priority: blocker | Milestone: 6.4.3 Component: wxGUI| Version: 6.4.3 RCs Keywords: location wizard |Platform: Unspecified Cpu: x86-64 | -+-- Comment(by annakrat): When I create new location, I usually want to import data first. So launching in PERMANENT seems to be reasonable from this point of view. Replying to [ticket:1889 hamish]: Perhaps this came in with the code to automatically import the georeferenced map you created a new location from? (and that one should ask you first, e.g. the geofile may be massive and you don't want to import it) It asks. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1889#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] #1829: Allow user to override MAPSET ownership check
#1829: Allow user to override MAPSET ownership check
-+--
Reporter: marisn | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: minor| Milestone: 7.0.0
Component: Startup | Version: svn-trunk
Keywords: |Platform: Unspecified
Cpu: Unspecified |
-+--
Comment(by wenzeslaus):
{{{
os.environ['GRASS_SKIP_MAPSET_OWNER_CHECK'] = '1'
}}}
This works. I've just tried this in Python. It was very helpful, by the
way.
However, I don't know how to support this in GUI.
1) It is env variable not gisenv variable, so it is per-process. GUI
cannot set it for command line. Two solutions:
* set the variable on grass start-up (the safe way, but still, I don't
know how to transfer the wxGUI settings to start-up script)
* change this to gisenv variable (consequences?)
2) Where to put the check in the GUI?
3) Do we even need to support this in GUI (it is a very special thing)?
Can we close this ticket as fixed now?
--
Ticket URL: http://trac.osgeo.org/grass/ticket/1829#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] #1889: wxPy loc'n wiz: don't auto-launch into PERMANENT
#1889: wxPy loc'n wiz: don't auto-launch into PERMANENT -+-- Reporter: hamish | Owner: grass-dev@… Type: defect | Status: new Priority: blocker | Milestone: 6.4.3 Component: wxGUI| Version: 6.4.3 RCs Keywords: location wizard |Platform: Unspecified Cpu: x86-64 | -+-- Comment(by hamish): When I create new location, I usually want to import data first. perhaps, but that's not a decision that should be made for someone else. Guiding people to use PERMANENT as their working mapset by default is not good, and that far outweighs any one-off convenience + is dysfunctional in a multi-user/team setting. e.g. the geofile may be massive and you don't want to import it It asks. ok, thanks. best, Hamish -- Ticket URL: http://trac.osgeo.org/grass/ticket/1889#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] #1829: Allow user to override MAPSET ownership check
#1829: Allow user to override MAPSET ownership check -+-- Reporter: marisn | Owner: grass-dev@… Type: enhancement | Status: new Priority: minor| Milestone: 7.0.0 Component: Startup | Version: svn-trunk Keywords: |Platform: Unspecified Cpu: Unspecified | -+-- Comment(by martinl): Replying to [comment:2 wenzeslaus]: However, I don't know how to support this in GUI. 1) It is env variable not gisenv variable, so it is per-process. GUI cannot set it for command line. Two solutions: * set the variable on grass start-up (the safe way, but still, I don't know how to transfer the wxGUI settings to start-up script) * change this to gisenv variable (consequences?) I could comment it in the sense how it's done for `GRASS_ADDON_PATH` variable (menu: File-Launch script). If the script is not in the path, the GUI updates loaded environmental variable (`os.environ['GRASS_ADDON_PATH']=`) and updates `.grass7/basrc` (or `GRASS7\env.bat` on MS Windows). This file is loaded by the initialization script. Drawback: if you quit GUI and launch it again, the variable is lost - you need to restart GRASS (launch initialization script which loads `bashrc` or `env.bat` file). -- Ticket URL: http://trac.osgeo.org/grass/ticket/1829#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] #1554: wxGUI Cartographic Composer: preview broken on Windows
#1554: wxGUI Cartographic Composer: preview broken on Windows +--- Reporter: martinl | Owner: grass-dev@… Type: defect | Status: new Priority: critical| Milestone: 6.4.3 Component: wxGUI | Version: unspecified Keywords: cartographic composer, psmap, wingrass |Platform: MSWindows XP Cpu: Unspecified | +--- Comment(by hamish): Replying to [comment:20 annakrat]: I added a message (r55118) which is shown in the statusbar when switching to preview tab. It might be enough? Feel free to improve the message if it sounds strange. yes, that works very nicely, thank you. the text is right next to the tab you click so you're already looking at it. The message doesn't sound strange, just concise. I think it's fine. cheers, Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/1554#comment:21 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] #1829: Allow user to override MAPSET ownership check
#1829: Allow user to override MAPSET ownership check -+-- Reporter: marisn | Owner: grass-dev@… Type: enhancement | Status: new Priority: minor| Milestone: 7.0.0 Component: Startup | Version: svn-trunk Keywords: |Platform: Unspecified Cpu: Unspecified | -+-- Comment(by hamish): (a bit off-topic, but for anyone who didn't know these non-obvious points already it's worth repeating) [ n.b. 1) in GRASS 6 GRASS_ADDON_PATH needs to be set in ~/.bashrc not ~/.grass.bashrc since .grass.bashrc is run last, after the PATH and everything else is already set up. GRASS_HTML_BROWSER is another in the same situation, see `grass64 --help` for the full list. n.b. 2) the script needs to be in the path for g.parser to function correctly. Compiled C modules don't need to be in the path though. ] -- Ticket URL: https://trac.osgeo.org/grass/ticket/1829#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] #1829: Allow user to override MAPSET ownership check
#1829: Allow user to override MAPSET ownership check -+-- Reporter: marisn | Owner: grass-dev@… Type: enhancement | Status: new Priority: minor| Milestone: 7.0.0 Component: Startup | Version: svn-trunk Keywords: |Platform: Unspecified Cpu: Unspecified | -+-- Comment(by martinl): Replying to [comment:4 hamish]: n.b. 1) in GRASS 6 GRASS_ADDON_PATH needs to be set in ~/.bashrc not ~/.grass.bashrc since .grass.bashrc is run last, after the PATH and everything else is already set up. GRASS_HTML_BROWSER is another in the same situation, see `grass64 --help` for the full list. this is not true for G7 -- Ticket URL: https://trac.osgeo.org/grass/ticket/1829#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
[GRASS-dev] On (Landsat) imagery naming patterns
Greetings to the dev-list. I successfully tested i.histo.match, by feeding it with 12 Landsat scenes (working on identical bands, different Path/Row tiles) in one go. It works and I really enjoy it. However, there is some problem: i.histo.match wont accept the . character as part of the image/raster map names. This is an SQL restriction (thanks Luca D for the quick help) as the module utilises sqlite internally for the calculations. Although I am familiar with this restriction, due to pressing deadlines, I overlooked that point while designing my workflow and decided to go for a specific naming pattern for all Landsat scenes at each (pre-)processing step (working currently on 25+ tiles, for summer and winter that cover the entire Greek territory). In addition, the respective manuals for modules like i.landsat.toar, i.landsat.acca, i.topo.corr hold in their examples/descriptions (thus, someone can easily interpret that these modules encourage the use of) names like B., B.toar, toar.5, et.c. I certainly like to keep, while on intermediate processing steps, long names whose parts are separated by either the underscore character ( _ ) or the dot character ( . ). This is, from my point of view, an inconsistency which adds-up some confusion -- especially to new users who will try/need to use i.histo.match at some point. As changing the module or adding internally a solution will add complexity, I guess it is better to adhere to some kind of strict naming rules/patterns in the manuals' examples, in the wiki and elsewhere? In time I will try to propose new wording and examples for all Landsat related modules/manuals I have used/read. GRASS has (almost) everything required for a perfect Landsat processing work-flow. This small inconsistency breaks the harmony :-). Best, N signature.asc Description: This is a digitally signed message part. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1806: interrupting a command with CTRL+c closes wxGUI
#1806: interrupting a command with CTRL+c closes wxGUI --+- Reporter: msieczka | Owner: grass-dev@… Type: defect | Status: closed Priority: critical | Milestone: 6.4.3 Component: wxGUI| Version: 6.4.3 RCs Resolution: fixed|Keywords: Platform: MSWindows 7 | Cpu: x86-64 --+- Changes (by msieczka): * status: new = closed * resolution: = fixed Comment: pressing ctrl-C at the rxvt command prompt, or in the gui window? MSYS command prompt. I guess the scenario is the user trying to copy some text to the clipboard? It was the user trying to interrupt a GRASS command started on the MSYS command line. I can't reproduce this on Window7 with yesterday's nightly 6.4.3svn build. Confirmed. Closing ticket, not knowing what the fix was though. -- Ticket URL: https://trac.osgeo.org/grass/ticket/1806#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
[GRASS-dev] On i.histo.match (Re: On (Landsat) imagery naming patterns)
On Wednesday 20 of February 2013 13:31:07 Nikos Alexandris wrote: Greetings to the dev-list. I successfully tested i.histo.match, by feeding it with 12 Landsat scenes (working on identical bands, different Path/Row tiles) in one go. It works and I really enjoy it. Could it be that histo-matching works nicely only on 0-255 ranges but doesn't play nice in ranges 0-1.0? Integers only? For example, when feeding images ranging from 0-1.0 (all Landsat bands 3) with the optional parameter max=1, many of the histo-matched images are flatten to 1. I will try to recode 0-1.0 images to 0-255 and repeat the histo-matching process. Best, Nikos signature.asc Description: This is a digitally signed message part. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] On i.histo.match (Re: On (Landsat) imagery naming patterns)
On Wed, Feb 20, 2013 at 3:27 PM, Nikos Alexandris n...@nikosalexandris.net wrote: On Wednesday 20 of February 2013 13:31:07 Nikos Alexandris wrote: Greetings to the dev-list. I successfully tested i.histo.match, by feeding it with 12 Landsat scenes (working on identical bands, different Path/Row tiles) in one go. It works and I really enjoy it. Could it be that histo-matching works nicely only on 0-255 ranges but doesn't play nice in ranges 0-1.0? Integers only? Yes, integers only. The i.histo.match script forces input raster values to integers. But it might not be restricted to the 0-255 range. For example, when feeding images ranging from 0-1.0 (all Landsat bands 3) with the optional parameter max=1, many of the histo-matched images are flatten to 1. I will try to recode 0-1.0 images to 0-255 and repeat the histo-matching process. For rescaling to 0-1000, you could try something like r.mapcalc bandX_int = round(1000 * bandX) HTH, Markus M Best, Nikos ___ 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] On i.histo.match (Re: On (Landsat) imagery naming patterns)
Nikos Alexandris: Greetings to the dev-list. I successfully tested i.histo.match, by feeding it with 12 Landsat scenes (working on identical bands, different Path/Row tiles) in one go. It works and I really enjoy it. Nikos A: Could it be that histo-matching works nicely only on 0-255 ranges but doesn't play nice in ranges 0-1.0? Integers only? Markus Metz wrote: Yes, integers only. The i.histo.match script forces input raster values to integers. But it might not be restricted to the 0-255 range. ( Oh how nice it would be to do the tranformation internally :-) ) For example, when feeding images ranging from 0-1.0 (all Landsat bands 3) with the optional parameter max=1, many of the histo-matched images are flatten to 1. I will try to recode 0-1.0 images to 0-255 and repeat the histo-matching process. For rescaling to 0-1000, you could try something like r.mapcalc bandX_int = round(1000 * bandX) Nice! But I wonder why round-ing is required? I want to jump back afterwards (i.e. divide by 1000 the histo-matched images). Rounding does not hurt much, does it? Thank you Markus, Nikos signature.asc Description: This is a digitally signed message part. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] On i.histo.match (Re: On (Landsat) imagery naming patterns)
On Wed, Feb 20, 2013 at 4:19 PM, Nikos Alexandris n...@nikosalexandris.net wrote: Nikos Alexandris: Markus Metz wrote: For rescaling to 0-1000, you could try something like r.mapcalc bandX_int = round(1000 * bandX) Nice! But I wonder why round-ing is required? rounding is not required, just a bit more accurate than truncating with int(1000 * bandX). Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] On i.histo.match (Re: On (Landsat) imagery naming patterns)
MM: For rescaling to 0-1000, you could try something like r.mapcalc bandX_int = round(1000 * bandX) NA: Nice! But I wonder why round-ing is required? MM: rounding is not required, just a bit more accurate than truncating with int(1000 * bandX). Great Wizard, thnx :-) N ps- note-to-self: add this in Wiki when writing about histogram matching of Landsat reflectances. signature.asc Description: This is a digitally signed message part. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1784: wingrass6.4.3svn: raster3d problems
#1784: wingrass6.4.3svn: raster3d problems
--+-
Reporter: hellik| Owner: grass-dev@…
Type: defect| Status: new
Priority: critical | Milestone: 6.4.3
Component: Raster3D | Version: 6.4.3 RCs
Keywords:|Platform: MSWindows 7
Cpu: x86-64|
--+-
Comment(by hellik):
Replying to [comment:4 neteler]:
Please try r55120 in GRASS 7 (may be backported to G6:
lib/g3d/g3dwindowio.c if working)
tested with
{{{
System Info
GRASS version: 7.0.svn
GRASS SVN Revision: 55121
Build Date: 2013-02-20
GIS Library Revision: 52468 (2012-07-27)
GDAL/OGR: 1.9.2
PROJ.4: 4.8.0
GEOS: 3.3.6dev
SQLite: 3.7.10
Python: 2.7.2
wxPython: 2.8.12.1
Platform: Windows-7-6.1.7601-SP1 (OSGeo4W)
}}}
{{{
r3.info map=precip3d.500z50@PERMANENT
WARNING: You are using an old raster3d data format, the vertical unit is
undefined. Please use r3.support to define the vertical unit to avoid this
warning.
++
| Layer:precip3d.500z50@PERMANENT Date: ??
|
| Mapset: PERMANENT Login of Creator: ??
|
| Location: slovakia3d
|
| DataBase: C:\grassdata
|
| Title:??
|
| Units:none
|
| Vertical unit: (null)
|
| Timestamp: none
|
||
|
|
| Type of Map: 3d cell Number of Categories: 0
|
| Data Type:DCELL
|
| Rows: 510
|
| Columns: 890
|
| Depths: 6
|
| Total Cells: 2723400
|
| Total size: 6728954 Bytes
|
| Number of tiles: 7168
|
| Mean tile size: 938 Bytes
|
| Tile size in memory: 4096 Bytes
|
| Number of tiles in x, y and z: 112, 64, 1
|
| Dimension of a tile in x, y, z: 8, 8, 8
|
|
|
|Projection: x,y (zone 0)
|
|N:553S:5275000 Res: 500
|
|E:4631000W:4186000 Res: 500
|
|T: 3000B: 0 Res: 500
|
| Range of data: min = 525.45690918 max = 1801.44433594
|
|
|
++
(Wed Feb 20 17:14:56 2013) Command finished (0 sec)
}}}
{{{
g.region -p rast3d=precip3d.500z50@PERMANENT
projection: 0 (x,y)
zone: 0
north: 553
south: 5275000
west: 4186000
east: 4631000
nsres: 500
ewres: 500
rows: 510
cols: 890
cells: 453900
(Wed Feb 20 17:16:45 2013) Command finished (0 sec)
}}}
seems to work with this revision in G7.
backport?
thanks
Helmut
--
Ticket URL: http://trac.osgeo.org/grass/ticket/1784#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] question about new query
Good point that I forgot to mention about the attribute manager. It takes several steps to get from a vector feature that you can see on a map to a place where you can edit its attributes. But maybe editing could be routed through attribute manager tools rather than query tools, with a separate menu/display entry? One wish for the query tools is that there is an option for the query results to accumulate in the window the way they did in the console so that you can see and save the results of multiple mouse queries. Thanks Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Feb 20, 2013, at 2:03 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 19/02/13 09:44, Martin Landa wrote: Hi, 2013/2/19 Anna Kratochvílovákratocha...@gmail.com: [...] the previous system allows to change attributes by querying which is in my opinion wrong behavior (#1608). Currently, you can change the attributes in the attribute manager and in the digitizer. I agree that it is less convenient than before. So the query dialog could on request display Attribute Manager with dialog for editing record or DisplayAttributesDialog? I would agree with Anna. Attributes should be editable only in specific mode (in digitizer) or by specialized tool (attribute table manager). I agree that editable attributes should not be the default, but I've also always found unelegant to have to activate digitization (and so the possibility of accidentally changing the map features) just in order to be able to change an attribute. Also, the possibility to click on an object to change its attributes is IMHO a basic feature any GIS should have, and having to identify the object in the attribute manager through other means (e.g. SQL search) is not the same. Why not go back to the old way of offering both options: default is dialog without editing (valid for both vector and raster), but also an option for vector map querying with editable fields ? Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] On (Landsat) imagery naming patterns
Hmmm g.rename originalnname with newname (sed substitute . with _ in originalname) I agree this additional step is less elegant in the work flow Y On Feb 20, 2013 12:31 PM, Nikos Alexandris n...@nikosalexandris.net wrote: Greetings to the dev-list. I successfully tested i.histo.match, by feeding it with 12 Landsat scenes (working on identical bands, different Path/Row tiles) in one go. It works and I really enjoy it. However, there is some problem: i.histo.match wont accept the . character as part of the image/raster map names. This is an SQL restriction (thanks Luca D for the quick help) as the module utilises sqlite internally for the calculations. Although I am familiar with this restriction, due to pressing deadlines, I overlooked that point while designing my workflow and decided to go for a specific naming pattern for all Landsat scenes at each (pre-)processing step (working currently on 25+ tiles, for summer and winter that cover the entire Greek territory). In addition, the respective manuals for modules like i.landsat.toar, i.landsat.acca, i.topo.corr hold in their examples/descriptions (thus, someone can easily interpret that these modules encourage the use of) names like B., B.toar, toar.5, et.c. I certainly like to keep, while on intermediate processing steps, long names whose parts are separated by either the underscore character ( _ ) or the dot character ( . ). This is, from my point of view, an inconsistency which adds-up some confusion -- especially to new users who will try/need to use i.histo.match at some point. As changing the module or adding internally a solution will add complexity, I guess it is better to adhere to some kind of strict naming rules/patterns in the manuals' examples, in the wiki and elsewhere? In time I will try to propose new wording and examples for all Landsat related modules/manuals I have used/read. GRASS has (almost) everything required for a perfect Landsat processing work-flow. This small inconsistency breaks the harmony :-). Best, N ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] On (Landsat) imagery naming patterns
On Wednesday 20 of February 2013 23:23:31 Yann Chemin wrote: Hmmm g.rename originalnname with newname (sed substitute . with _ in originalname) I agree this additional step is less elegant in the work flow Y Hi Yann. This is, of course, what I did/do for now. I can't change my naming pattern now anyway. But I think as a long-term goal, the modules should follow homogeneous naming conventions, as much as possible. For the records, I use(d) in a script tr . _ as I have placed the . as a separator everywhere. I hope this is not dangerous. Best regards, Nikos signature.asc Description: This is a digitally signed message part. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] On (Landsat) imagery naming patterns
Nikos wrote: This is, of course, what I did/do for now. I can't change my naming pattern now anyway. But I think as a long-term goal, the modules should follow homogeneous naming conventions, as much as possible. It should be easy to make i.histo.match.py do name cleansing and then back to the orginal, internally. It could make a table/ dictionary of map names vs. img_1, img_2, ... safe column names then work with the safe names. Make the program[mer] do the hard work, not the end user.. :) best, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1784: wingrass6.4.3svn: raster3d problems
#1784: wingrass6.4.3svn: raster3d problems --+- Reporter: hellik| Owner: grass-dev@… Type: defect| Status: new Priority: critical | Milestone: 6.4.3 Component: Raster3D | Version: 6.4.3 RCs Keywords:|Platform: MSWindows 7 Cpu: x86-64| --+- Comment(by neteler): Excellent. Backported to 6.4 and 6.5 in r55135 and r55136: please test also there. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1784#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 6.4.3RC2 released
Hi, 2013/2/13 Martin Landa landa.mar...@gmail.com: Hi, 2013/2/3 Martin Landa landa.mar...@gmail.com: since it's more than a month ago now, what about another another RC or release? agreed. After RC3 should come ideally final release. sorry for bringing this issue back. We have 2 RCs released, RC2 is almost 2(!) month old. I don't see any blocker in trac [1], even nothing noted on the dev's wiki [2]. Is there any blocker, if so please collect them in trac or at least note them on trac page [2]. good, now the situation is much more clear (4 blockers reported by Hamish within last few days). I hope that it's not forbidden that also the reporter can fix the bug ;-) Would be the ideal situation. At least we are much more far from RC3/final that we were in the last week. Unfortunately my time is very limited now (can do something, but not so much), so I hope that someone will work on these blockers in some way ... Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] On (Landsat) imagery naming patterns
Nikos wrote: This is, of course, what I did/do for now. I can't change my naming pattern now anyway. But I think as a long-term goal, the modules should follow homogeneous naming conventions, as much as possible. Hamish wrote: It should be easy to make i.histo.match.py do name cleansing and then back to the orginal, internally. It could make a table/ dictionary of map names vs. img_1, img_2, ... safe column names then work with the safe names. Make the program[mer] do the hard work, not the end user.. :) ( note-to-self: maybe that would be (another) good exercise for me (later, on March)? ) Note, i.histo.match itself adds a user-defined suffix which _always_ begins with a . :-) thnx, Nikos signature.asc Description: This is a digitally signed message part. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
