Re: [GRASS-dev] [GRASS GIS] #2223: v.buffer flags -s and -c not working(?)
#2223: v.buffer flags -s and -c not working(?) --+- Reporter: jbrauner | Owner: grass-dev@… Type: defect | Status: reopened Priority: normal | Milestone: 7.0.0 Component: Vector |Version: svn-trunk Resolution: | Keywords: v.buffer CPU: Unspecified | Platform: All --+- Changes (by neteler): * status: closed = reopened * priority: critical = normal * resolution: wontfix = Comment: Replying to [comment:5 neteler]: The flags have been inactivated (i.e. present for backward compatibility) but have no effect when using GEOS. I wonder why -c wasn't removed. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2223#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
[GRASS-dev] Landsat 5TM pre-processing - histogram matching - problem
Hello, I'm totally new user of GRASS and of course I have some problems. I want to do the pre-processing of Landsat (5TM) images (for further band composite, classification and NDVI) and I was using the tips from http://grasswiki.osgeo.org/wiki/LANDSAT#Pre-Processing I did the i.landsat.toar I wanted to do the i.atcorr as well but I have no idea how to do this, the manual was not helpful for me, so I gave up. I did not do i.topo.corr because the land I'm working on is flat. And I really want to do "radiometrically normalise one approach via i.histo.match (in grass 7), also known as relative radiometric normalisation -- one approach is the histogram matching technique of two or more raster maps". I have fragments of original landsat images imported to GRASS and i.histo.match works with them without any problems. But there is a problem when I want to do this on images which I got after i.landsat.toar. The output images are monochromatic-one colour. I've used command i.histo.match input=_toar2@konfa,86_toar2@konfa (the input files are those which I got after i.landsat.toar) and then r.colors map=86_toar2.match@konfa color=grey. I thought that those steps from grasswiki should be done "step by step", so first i.landsat.toar, and then on the output files i.histo.match. Does anyone know how to do this in a proper/correct way? Best wishes Joan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] How to get Last changed string for a module's manual?
On Mon, May 4, 2015 at 12:08 PM, Nikos Alexandris n...@nikosalexandris.net wrote: Dear devs, how do we get a string like Last changed: $Date: 2014-12-01 17:21:35 +0200 (Mon, 01 Dec 2014) $ for a module's manual? Is this dynamically created or is it hardcoded? Both :) You can copy it from another manual page. Then, to get it updated by SVN, you need to define svn propset. this you can do with a helper script: sh ~/software/grass-addons/tools/module_svn_propset.sh yourfile or cd yourdir/ sh ~/software/grass-addons/tools/module_svn_propset.sh * hope this helps, Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] How to get Last changed string for a module's manual?
Nikos Alexandris wrote: Dear devs, how do we get a string like Last changed: $Date: 2014-12-01 17:21:35 +0200 (Mon, 01 Dec 2014) $ for a module's manual? Is this dynamically created or is it hardcoded? Markus Neteler: Both :) You can copy it from another manual page. Then, to get it updated by SVN, you need to define svn propset. this you can do with a helper script: sh ~/software/grass-addons/tools/module_svn_propset.sh yourfile or cd yourdir/ sh ~/software/grass-addons/tools/module_svn_propset.sh * hope this helps, A lot, thanks. How can I verify it actually updates the string? I did as per the instruction above, then `svn up` (necessary?), then re-compiled. Don't see an updated string though. Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] How to get Last changed string for a module's manual?
* Nikos Alexandris n...@nikosalexandris.net [2015-05-04 13:52:22 +0300]: Nikos Alexandris wrote: Dear devs, how do we get a string like Last changed: $Date: 2014-12-01 17:21:35 +0200 (Mon, 01 Dec 2014) $ for a module's manual? Is this dynamically created or is it hardcoded? Markus Neteler: Both :) You can copy it from another manual page. Then, to get it updated by SVN, you need to define svn propset. this you can do with a helper script: sh ~/software/grass-addons/tools/module_svn_propset.sh yourfile or cd yourdir/ sh ~/software/grass-addons/tools/module_svn_propset.sh * hope this helps, A lot, thanks. How can I verify it actually updates the string? I did as per the instruction above, then `svn up` (necessary?), then re-compiled. Don't see an updated string though. Oh man, maybe I meed to commit first... :-). Will re-check. Thanks, Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] How to get Last changed string for a module's manual?
On Mon, May 4, 2015 at 6:59 AM, Nikos Alexandris n...@nikosalexandris.net wrote: * Nikos Alexandris n...@nikosalexandris.net [2015-05-04 13:52:22 +0300]: Nikos Alexandris wrote: Dear devs, how do we get a string like Last changed: $Date: 2014-12-01 17:21:35 +0200 (Mon, 01 Dec 2014) quot; for a module's manual? Is this dynamically created or is it hardcoded? Markus Neteler: Both :) You can copy it from another manual page. Then, to get it updated by SVN, you need to define svn propset. this you can do with a helper script: sh ~/software/grass-addons/tools/module_svn_propset.sh yourfile or cd yourdir/ sh ~/software/grass-addons/tools/module_svn_propset.sh * hope this helps, A lot, thanks. How can I verify it actually updates the string? I did as per the instruction above, then `svn up` (necessary?), then re-compiled. Don't see an updated string though. Oh man, maybe I meed to commit first... :-). Will re-check. Yes, you need to commit first. FWIK, this feature (adding dates, versions, etc. to files) was very popular in the times of CVS and it have became quite controversial now, especially among those using Git. It is advantageous for manual pages because it adds the recent change to the file which would be otherwise hard to do manually. Doing this automatically on compile time wouldn’t be so straightforward because you can just compile from tar without svn (and thus having no idea about the versions, dates and authors). The disadvantages include tracking last change in documentation rather than algorithm and messy source code and diffs (especially unnecessary differences between branches). Thanks, 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] Landsat 5TM pre-processing - histogram matching - problem
On 04/05/15 11:28, joanna mardas wrote: Hello, I'm totally new user of GRASS and of course I have some problems. I want to do the pre-processing of Landsat (5TM) images (for further band composite, classification and NDVI) and I was using the tips from http://grasswiki.osgeo.org/wiki/LANDSAT#Pre-Processing I did the *i.landsat.toar* I wanted to do the i.atcorr as well but I have no idea how to do this, the manual was not helpful for me, so I gave up. I did not do i.topo.corr because the land I'm working on is flat. And I really want to do /radiometrically normalise → one approach via*i.histo.match* (in grass 7), also known as relative radiometric normalisation -- one approach is the histogram matching technique of two or more raster maps/. I have fragments of original landsat images imported to GRASS and i.histo.match works with them without any problems. But there is a problem when I want to do this on images which I got after i.landsat.toar. The output images are monochromatic-one colour. I've used command i.histo.match input=_toar2@konfa,86_toar2@konfa (the input files are those which I got after i.landsat.toar) and then r.colors map=86_toar2.match@konfa color=grey. I thought that those steps from grasswiki should be done step by step, so first i.landsat.toar, and then on the output files i.histo.match. Does anyone know how to do this in a proper/correct way? ISTR that i.histo.match works with integer imagerie, i.e. recoded to 0-255. Recode your toar images to that range with r.recode and try to run the result through i.histo.match to see if that helps. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Error reading null row 8 for MASK
Hello! I am running a loop with several r.mapcalc. I am using GRASS 7.1. The function stops with an error: ERROR: Error reading null row 8 for MASK I've noticed that* Paulo van Breugel, *had the same error but I didn't see the solution to it. Obviously it has something to do with the raster called MASK, created with r.mask before running the loop of multiple r.mapcalc. The code itself has no problem and is very simple and works just fine with the same list of images, but without running r.mask first. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Error reading null row 8 for MASK
On Mon, May 4, 2015 at 8:05 PM, Alba German albager...@gmail.com wrote: Hello! I am running a loop with several r.mapcalc. I am using GRASS 7.1. The function stops with an error: ERROR: Error reading null row 8 for MASK I've noticed that Paulo van Breugel, had the same error but I didn't see the solution to it. Obviously it has something to do with the raster called MASK, created with r.mask before running the loop of multiple r.mapcalc. The code itself has no problem and is very simple and works just fine with the same list of images, but without running r.mask first. Hi Alba, could you post that part of the code e.g. here http://pastebin.com/ ? It sounds like a race condition... Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Landsat 5TM pre-processing - histogram matching - problem
joanna mardas wrote:
Hello,
Hi Joanna,
I'm totally new user of GRASS and of course I have some problems. I want
to do the pre-processing of Landsat (5TM) images (for further band
composite, classification and NDVI) and I was using the tips from
http://grasswiki.osgeo.org/wiki/LANDSAT#Pre-Processing I did the
*i.landsat.toar* I wanted to do the i.atcorr as well but I have no idea
how to do this, the manual was not helpful for me, so I gave up. I did
not do i.topo.corr because the land I'm working on is flat.
I need some time to fix a python script which does that automatically
(see: https://github.com/NikosAlexandris/i.landsat.atcorr, currently
broken :-().
And I really want to do /radiometrically normalise → one approach
via*i.histo.match* (in grass 7), also known as relative radiometric
normalisation -- one approach is the histogram matching technique of two
or more raster maps/.
Another, simple approach, is described in:
Radiometric Use of QuickBird Imagery, Technical Note. 2005-11-07, by
Keith Krause.
It is in section 6 in the above mentioned document. I have a
half-written script for this... :-(
I have fragments of original landsat images
imported to GRASS and i.histo.match works with them without any
problems.
That is so because i.histo.match, as Moritz notes below, support for
8-bit raster data.
But there is a problem when I want to do this on images which
I got after i.landsat.toar. The output images are monochromatic-one
colour.
Each band is one single image. No matter its bitness, it is normal to
appear mono-chromatic -- its normal to apply a grey scale.
I've used command i.histo.match
input=_toar2@konfa,86_toar2@konfa (the input files are those which I got
after i.landsat.toar) and then r.colors map=86_toar2.match@konfa
color=grey. I thought that those steps from grasswiki should be done
step by step, so first i.landsat.toar, and then on the output files
i.histo.match.
Does anyone know how to do this in a proper/correct way?
I wrote this steps some time ago. And I still insist that the correct
way is to not use the Digital Numbers directly. Rather, convert to
reflectance, then do whatever you have to.
Moritz Lennert:
ISTR that i.histo.match works with integer imagerie, i.e. recoded to
0-255. Recode your toar images to that range with r.recode and try to
run the result through i.histo.match to see if that helps.
What I have done in the past,
# if Reflectance 1, set to 1000, else round and multiply by 1000
r.mapcalc --o TopoCorr_B_Trimmed_DOS1_ToCR_${Band_No}_${SCENE} = if(
TopoCorr.B.Trimmed.DOS1.ToCR.${Band_No}@${SCENE} 1, 1000, round( 1000 *
TopoCorr.B.Trimmed.DOS1.ToCR.${Band_No}@${SCENE} ) )
# histogram matching
...
# convert histo-matched images back to floating point: rescale to 0-1.0
r.mapcalc --o ${HistoMatchedMap} = ${HistoMatchedMap} / 1000.0
This came out after Markus Metz' advice, if I recall correctly. I would
add another advice (this one was from Yann Chemin): filter out water. I
think too, now, that i.histo.match will perform better.
Nikos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Landsat 5TM pre-processing - histogram matching - problem
joanna mardas wrote: I have fragments of original landsat images imported to GRASS and i.histo.match works with them without any problems. Nikos Alexandris : That is so because i.histo.match, as Moritz notes below, support for 8-bit raster data. Correction: support is there for integers, I think. So, not limited to 8-bit only. Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2349: CELL raster format: make ZLIB level 3 standard compression instead of RLE
#2349: CELL raster format: make ZLIB level 3 standard compression instead of RLE --+--- Reporter: neteler | Owner: grass-dev@… Type: enhancement | Status: new Priority: critical | Milestone: 7.1.0 Component: Raster |Version: svn-trunk Resolution: | Keywords: compression, r.compress, null CPU: Unspecified | Platform: All --+--- Changes (by glynn): * Attachment compressed_nulls.diff added. implement compressed nulls -- Ticket URL: https://trac.osgeo.org/grass/ticket/2349 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] Landsat 5TM pre-processing - histogram matching - problem
Hello!
You both are my heros! Thank you Moritz and Nikos!
r.recode worked :D I did i.histo.match on two test images and it looks fine. So now the rest of bands, and then band composite and supervised classification (I've found nice tutorial on youtube, so I'm gonna follow it, or I will try semi-automatic classification plugin for qgis).
Nikos, you've wrote "Each band is one single image. No matter its bitness, it is "normal" to appear "mono-chromatic" -- its "normal" to apply a grey scale." I know that grey scale is normal, but I didn't have, let's say "50 shades of grey" ;) but only one shade, one color-no scale of colors. Forunately, Moritz was right, thanks a lot! Now it looks normal.
And you wrote also that "the correct way is to not use the Digital Numbers directly. Rather, convert to reflectance, then do whatever you have to." So application of i.landsat.toar is correct, right?
Sorry for all stupid/basic questions but this is my first serious time with grass and landsat image processing.
Greetings
Joanna
Dnia 4-05-2015 o godz. 21:14 Nikos Alexandris napisał(a):
joanna mardas wrote:
Hello,
Hi Joanna,
I'm totally new user of GRASS and of course I have some problems. I want
to do the pre-processing of Landsat (5TM) images (for further band
composite, classification and NDVI) and I was using the tips from
http://grasswiki.osgeo.org/wiki/LANDSAT#Pre-Processing I did the
*i.landsat.toar* I wanted to do the i.atcorr as well but I have no idea
how to do this, the manual was not helpful for me, so I gave up. I did
not do i.topo.corr because the land I'm working on is flat.
I need some time to fix a python script which does that automatically
(see: https://github.com/NikosAlexandris/i.landsat.atcorr, currently
broken :-().
And I really want to do "/radiometrically normalise one approach
via*i.histo.match* (in grass 7), also known as relative radiometric
normalisation -- one approach is the histogram matching technique of two
or more raster maps/".
Another, simple approach, is described in:
"Radiometric Use of QuickBird Imagery, Technical Note." 2005-11-07, by
Keith Krause.
It is in section 6 in the above mentioned document. I have a
half-written script for this... :-(
I have fragments of original landsat images
imported to GRASS and i.histo.match works with them without any
problems.
That is so because i.histo.match, as Moritz notes below, support for
8-bit raster data.
But there is a problem when I want to do this on images which
I got after i.landsat.toar. The output images are monochromatic-one
colour.
Each band is one single image. No matter its bitness, it is "normal" to
appear "mono-chromatic" -- its "normal" to apply a grey scale.
I've used command i.histo.match
input=_toar2@konfa,86_toar2@konfa (the input files are those which I got
after i.landsat.toar) and then r.colors map=86_toar2.match@konfa
color=grey. I thought that those steps from grasswiki should be done
"step by step", so first i.landsat.toar, and then on the output files
i.histo.match.
Does anyone know how to do this in a proper/correct way?
I wrote this steps some time ago. And I still insist that the correct
way is to not use the Digital Numbers directly. Rather, convert to
reflectance, then do whatever you have to.
Moritz Lennert:
ISTR that i.histo.match works with integer imagerie, i.e. recoded to
0-255. Recode your toar images to that range with r.recode and try to
run the result through i.histo.match to see if that helps.
What I have done in the past,
# if Reflectance 1, set to 1000, else round and multiply by 1000
r.mapcalc --o "TopoCorr_B_Trimmed_DOS1_ToCR_${Band_No}_${SCENE} = if(
TopoCorr.B.Trimmed.DOS1.ToCR.${Band_No}@${SCENE} 1, 1000, round( 1000
* TopoCorr.B.Trimmed.DOS1.ToCR.${Band_No}@${SCENE} ) )"
# histogram matching
...
# convert histo-matched images back to floating point: rescale to 0-1.0
r.mapcalc --o "${HistoMatchedMap} = ${HistoMatchedMap} / 1000.0"
This came out after Markus Metz' advice, if I recall correctly. I would
add another advice (this one was from Yann Chemin): filter out water. I
think too, now, that i.histo.match will perform better.
Nikos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS7 GUI error on Fedora 22 (beta)
On Mon, May 4, 2015 at 10:55 PM, Pietro peter.z...@gmail.com wrote:
Dear All,
I'm trying to make a virtual machine with GRASS7 on Fedora 22 (only
...
but when I start GRASS I got this Error:
{{{
$ grass71
Fatal Error: Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1008,wx
containers,compatible with 2.8),
and wxPython used 3.0 (wchar_t,compiler with C++ ABI 1002,wx
containers,compatible with 2.8).
ERROR: Invalid return code from GUI startup script.
Please advise GRASS developers of this error.
Exiting...
}}}
I just tried the same using docker (for the procedure, see the comment here:
http://courses.neteler.org/fun-docker-grass-gis-software/#comment-1168 )
Essentially I get the same error.
Any ideas?
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] gdal/ogr 2.0 beta 1 available - grass gis ready?
fyi http://lists.osgeo.org/pipermail/gdal-dev/2015-May/041694.html is grass gis already ready for the next generation gdal/ogr? - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-ogr-2-0-beta-1-available-grass-gis-ready-tp5204079.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] GRASS7 GUI error on Fedora 22 (beta)
Dear All,
I'm trying to make a virtual machine with GRASS7 on Fedora 22 (only
grass64 is available so far), I didn't have any particular problem
configuring with:
{{{
./configure \
--with-cxx \
--with-gdal=/usr/bin/gdal-config \
--with-proj --with-proj-share=/usr/share/proj \
--with-sqlite \
--with-nls \
--with-wxwidgets=/usr/bin/wx-config \
--with-fftw \
--with-python=/usr/bin/python-config \
--with-freetype --with-freetype-includes=/usr/include/freetype2 \
--enable-largefile \
--without-odbc
}}}
and then compiling...
but when I start GRASS I got this Error:
{{{
$ grass71
Fatal Error: Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1008,wx
containers,compatible with 2.8),
and wxPython used 3.0 (wchar_t,compiler with C++ ABI 1002,wx
containers,compatible with 2.8).
ERROR: Invalid return code from GUI startup script.
Please advise GRASS developers of this error.
Exiting...
}}}
Any ideas?
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] gis.py:801: DeprecationWarning: classic int division
Nikos Alexandris wrote:
I just ran
python -Qwarn -tt -3
on a custom python script and the first line returned is
gis.py:801: DeprecationWarning: classic int division
Is this something that needs to be fixed?
That specific warning relates to code which is generated by ctypesgen
from system headers. Specifically, the definition of __sigset_t in
sigset.h:
# define _SIGSET_NWORDS (1024 / (8 * sizeof (unsigned long int)))
typedef struct
{
unsigned long int __val[_SIGSET_NWORDS];
} __sigset_t;
is translated to:
# /usr/include/bits/sigset.h: 30
class struct_anon_11(Structure):
pass
struct_anon_11.__slots__ = [
'__val',
]
struct_anon_11._fields_ = [
('__val', c_ulong * (1024 / (8 * sizeof(c_ulong,
]
__sigset_t = struct_anon_11 # /usr/include/bits/sigset.h: 30
The reason this is ending up in gis.py is for the definition of
jmp_buf which is used by G_fatal_longjmp().
As that function is (probably) unusable from Python, we could probably
just guard the declaration with #ifndef CTYPESGEN.
But that may not be the only such issue.
For compatibility with Python 3, we need to add
from __future__ import division
and use // for integer (truncating) division. But IIRC, that
requires Python 2.7. If GRASS still works with 2.6, it's not worth
abandonding support for it over this issue, given that there are
almost certainly far more significant issues with Python 3
compatibility (such as its insistence on coercing everything to
Unicode).
--
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] GRASS7 GUI error on Fedora 22 (beta)
On Mon, May 4, 2015 at 11:04 PM, Vaclav Petras wenzesl...@gmail.com wrote:
Nothing in particular, but you can try to `import wx` in Python command line
inside and outside of GRASS session to see what happens.
ok, I've tried with:
{{{
$ python -c import wx
Fatal Error: Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1008,wx
containers,compatible with 2.8),
and wxPython used 3.0 (wchar_t,compiler with C++ ABI 1002,wx
containers,compatible with 2.8).
Cancelled (core dump created)
}}}
Therefore it seems not a GRASS problem... but more a library/distribution one.
Do you know where this problem should be point out?
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
