[GRASS-dev] Still Failing: GRASS-GIS/grass-ci#1892 (master - 59b87f0)

2017-01-26 Thread Travis CI 
Build Update for GRASS-GIS/grass-ci
-

Build: #1892
Status: Still Failing

Duration: 1 hour, 53 minutes, and 58 seconds
Commit: 59b87f0 (master)
Author: Markus Neteler
Message: r.in.bin manual: cleanup (contributed by veroandreo)

git-svn-id: https://svn.osgeo.org/grass/grass/trunk@70438 
15284696-431f-4ddb-bdfa-cd5b030d7da7

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/8f322671692a...59b87f039608

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/195704045

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.clean threshold value unit for 'prune'

2017-01-26 Thread Markus Neteler 
On Thu, Jan 26, 2017 at 2:38 PM, Markus Metz
 wrote:
...
> It's a bug in the code [0], the algorithm is not working properly. There is
> v.generalize, therefore I recommend to remove the prune tool from v.clean.

Maybe keep (for consistency) and replace the functionality with an
G_fatal_error() pointing the user to v.generalize?

markusN

> Markus M
>
> [0]
> https://trac.osgeo.org/grass/browser/grass/trunk/lib/vector/diglib/prune.c
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] vector layer contains error not detected by v.build nor cleaned in v.clean

2017-01-26 Thread Markus Neteler 
On Thu, Jan 26, 2017 at 10:28 AM, Paulo van Breugel
 wrote:
> That did help me to get rid of many of the reported errors, thanks!

Could you please write a small text for the manual page and send to me?
thanks!

markusN
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Reviewing GSoC 2017 page

2017-01-26 Thread Vaclav Petras 
On Wed, Jan 25, 2017 at 6:35 PM, Blumentrath, Stefan <
stefan.blumentr...@nina.no> wrote:

> I took the liberty to add one on “tools for generating unit tests from
> examples in module manuals”. Not sure if that is feasible or out of scope.
> Please feel free to remove it if you don`t find it suitable (I can`t mentor
> it anyway).
>

It is valid, but there is a lot of details which need to be considered
(would need to be addressed in the proposal). There is some post to mailing
list discussing some of those.


>
>
> Regarding:
>
> https://trac.osgeo.org/grass/wiki/GSoC/2017#Additionalfunctionalityforrunn
> ingGRASSGISmodulesinJupyterNotebook
>
> (which I also very much like to see become reality, esp. a function like
> “initGRASS()” from rgrass7)
>

Can you please be specific about differences between rgrass7 initGRASS()
and grass.script.setup.init()? It would be good to collect them.

https://grass.osgeo.org/grass70/manuals/libpython/script.html#module-script.setup

Here is an example from action where it is simplified (and not that robust)
but adds some other useful things:

https://github.com/wenzeslaus/geospatial-modeling-course-jupyter/blob/master/notebooks/buffers_cost.ipynb

Other thing to mention is that an ultimate solution may involve creating a
package separate from GRASS GIS (like rgrass7) and more importantly
changing the way GRASS GIS is installed and distributed (see e.g. ticket
for PyGRASS outside of GRASS session).


> I have the question if that by chance is supposed to be related to last
> years GSoC on a WebGUI for GRASS (see: https://trac.osgeo.org/grass/
> wiki/GSoC/2016/WebGrass).
>

Not directly related. Jupyter Notebook is independent and with some
additions of interactive maps it could be used as a web interface for
advanced or Python aware users. It can be used even now, but for
visualization, you need to deal with d.* commands (which is fine in general
but not for zooming, panning, ...) or you need to plug in other solution
for visualization (like MapServer reading from GRASS GIS Database). There
might be some code sharing between (some/any) web GRASS and Jupyter on the
side of Python API or JavaScript map display (if applicable).


>
>
> In order to be really useful, WebGRASS would need a console, and here
> Jupyter was already mentioned as an option.
>

For this part it is really just thing of WebGRASS, nothing to be done on
Jupyter site.


> In addition the WebUI struggled quite a bit with renderinig… So will this
> proposal be complementary?
>

I don't know what specifically you mean, but I guess it will be a struggle
for Jupyer as well.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.clean threshold value unit for 'prune'

2017-01-26 Thread Paulo van Breugel 



On 26-01-17 14:38, Markus Metz wrote:



On Thu, Jan 26, 2017 at 11:15 AM, Paulo van Breugel 
mailto:p.vanbreu...@gmail.com>> wrote:

>
>
>
> On 26-01-17 11:03, Markus Metz wrote:
>
>
>
> On Thu, Jan 26, 2017 at 10:51 AM, Paulo van Breugel 
mailto:p.vanbreu...@gmail.com>> wrote:

> >
> > Hi
> >
> > I am using the v.clean tool with the option "prune". According to 
the manual, threshold values have to be in map units. I am using this 
with a latlon map with vertices as close as 0.0001 degrees. However, 
v.clean only removes vertices at threshold values of about 50 or up. 
This seems to suggest that the tools assumes threshold values are in 
meters?

>
> The prune tool of v.clean never really worked. Please use 
v.generalize instead.

>
>
> OK, will do. Still the question remains whether this is a bug, an 
error in the manual page (i.e., threshold values are not in mapping 
units, but in meters like for the rmarea) , or I am doing something 
wrong (note that it seems to work fine if one assumed threshold values 
have to be in meters). If a bug or error in the manual page, I can 
create a ticket.


It's a bug in the code [0], the algorithm is not working properly. 
There is v.generalize, therefore I recommend to remove the prune tool 
from v.clean.

+1 if it doesn't work properly and it is a won't fix better to remove


Markus M

[0] 
https://trac.osgeo.org/grass/browser/grass/trunk/lib/vector/diglib/prune.c

>
>
>
> Markus M
>
> >
> > Best wishes,
> >
> > Paulo
> >
> > ___
> > grass-dev mailing list
> > grass-dev@lists.osgeo.org 
> > https://lists.osgeo.org/mailman/listinfo/grass-dev
>
>


___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev


___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] i.superpixels.slic ( was: #3142 Implementing SLIC image segmentation)

2017-01-26 Thread Markus Metz 
On Thu, Jan 26, 2017 at 3:18 PM, Markus Metz 
wrote:
>
>
>
> On Mon, Jan 23, 2017 at 11:19 AM, Rashad Kanavath <
mohammedrasha...@gmail.com> wrote:
> >
> >
> >
> > On Mon, Jan 23, 2017 at 9:22 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:
> >>
> >> Hi Rashad,
> >>
> >> On 22/01/17 11:00, Rashad Kanavath wrote:
> >>>
> >>> I fixed all the points from last mail.
> >>
> >>
> >> Wonderful !
> >>
> >> It seems that you missed one point (see in the ticket #3142/#3247).
> >>
> >> Thank you so much for this great job !
> >
> >
> > Thanks. Sorry that I missed it. I will push a fix for both and update
the tracker too.
>
> I found time to review the code and discovered a few more issues:
>
> L210
>   pdata  = G_malloc (sizeof (int) * group_ref.nfiles);
> must be
>   pdata  = G_malloc (sizeof (int *) * group_ref.nfiles);

L301
  kseeds  = G_malloc (sizeof (int) * group_ref.nfiles);
must be
  kseeds  = G_malloc (sizeof (double *) * group_ref.nfiles);

L340
  sigma  = G_malloc (sizeof (int) * group_ref.nfiles);
must be
  sigma  = G_malloc (sizeof (double *) * group_ref.nfiles);

>
> L232
> pdata[nf][index] = ((int *) i_band)[col];
> works only if the input is CELL_TYPE
> i_band should be *DCELL, pdata should be ***DCELL such that L232 becomes
> pdata[row][col][nf] = i_band[col];
> the remaining code needs to be updated for changes in pdata
>
> L468
> no need to allocate and free a new row buffer for each output row
>
> in SLIC_EnforceLabelConnectivity()
> allocating sizeof(int) * nrows * ncols) for both xvec and yvec can cause
OOM errors. Superpixels should be much smaller, thus dynamic reallocation
would be better.
>
> L586
> this is the wrong place to update numlabels, better do
> numlabels = SLIC_EnforceLabelConnectivity()
> in main() L457
>
> NULL handling must be implemented
> cells where any input band is NULL must be skipped.
> Initializing seeds must be changed at L323-327 to avoid initializazion
with NULLs
>
> A few variables are allocated as vectors even though they hold some info
about each cell. They should be allocated as matrices. E.g. klabels is
currently accessed as klabels[row * ncols + col], better would be
klabels[row][col]. Equivalent for pdata and distvec. This change will make
it easier to use the segment library for managing temporary data.
>
> The spatial and spectral distances are currently not comparable, the
rather cryptic compactness parameter needs to be used to make them
comparable and determine the weight for the spatial and spectral distances.
It would be easier to understand if the spatial and spectral distances are
separately scaled such that each is in the range [0, 1]. This is already
done in i.segment and also described in the SLIC paper in formula 2.
Compactness could then be changed to be the weight for spatial distance
with default 0.5. Values > 0.5 would favour the spatial distance and cause
more compact superpixels while values < 0.5 would favour spectral distance
and cause less compact but spectrally more homogeneous superpixels.
>
> The option to perturb seeds could be useful to get more robust initial
seeds. A similar mechanism could also be used to find a non-NULL cell as
initial seed location.
>
> Currently the module has an option to specify the desired number of
superpixels. That makes comparison of the results for the same input but
different computational regions difficult. Instead of the number of
superpixels, the average superpixel size could be an input option, that
would make results comparable.
>
> Markus M
>
> >
> >
> >>
> >> Moritz
> >>
> >>
> >>
> >>>
> >>> On Fri, Jan 6, 2017 at 9:28 AM, Markus Metz
> >>> mailto:markus.metz.gisw...@gmail.com>>
> >>> wrote:
> >>>
> >>>
> >>>
> >>> On Tue, Dec 27, 2016 at 9:05 PM, Rashad Kanavath
> >>> mailto:mohammedrasha...@gmail.com>>
wrote:
> >>>
> >>>
> >>>
> >>> I had pushed a updated version of code:
> >>>
> >>> Done:
> >>> 1. input is a imagery group from i.group (handles all raster
in
> >>> the group)
> >>> 2. removed rgb2lab conversion
> >>> 3. implementation of id output map
> >>> 4. replaced  fmin with MIN and MAX macro
> >>> 5. compactness is a new option to module? (default is 20 from
paper)
> >>>
> >>> Wonderful, thanks!
> >>>
> >>>
> >>> TODO:
> >>> 1. add option for SLICO
> >>> 2. use segment library to avoid memory limitation when reading
> >>> raster data
> >>>
> >>> Hope this works now. Let me know If I missed something else.
> >>>
> >>> Code clean-up:
> >>> - please use tools/grass_indent.sh
> >>> - move variable declarations to the beginning of a code block
> >>> - convert C++ style comments to C style comments
> >>> - line 155
> >>>   int sz = nrows * ncols;
> >>>
> >>> can cause integer overflow. Use off_t (large raster maps can only
be
> >>> handled with LFS, i.e. off_t being a 64bit integer).
> >>>
> >>> - fix L157: must be
> >>>

Re: [GRASS-dev] Next events workshop

2017-01-26 Thread Vaclav Petras 
On Thu, Jan 26, 2017 at 4:51 AM, Luca Delucchi  wrote:

> > Please, let me know if you want to collaborate on this or other workshop
> or
> > you have some topics you would like to see covered.
> >
>
> maybe we could also submit a Intro course, I could do that
>


Sure, my group was also thinking about intro workshop as an alternative.

I think at this point we can move the FOSS4G Boston conversation to private
to figure out the specifics. But if somebody else wants to join the
efforts, just write here.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Next events workshop

2017-01-26 Thread Giuseppe Amatulli 
Hi,
I'm Working in USA east-coast, only 3 hour from Boston, so definitely
Boston.
Best Giuseppe

On 26 January 2017 at 04:51, Luca Delucchi  wrote:

> On 25 January 2017 at 15:45, Vaclav Petras  wrote:
> > I plan to submit a workshop for FOSS4G 2017 in Boston. GRASS and lidar
> > related.
> >
>
> cool
>
> > Please, let me know if you want to collaborate on this or other workshop
> or
> > you have some topics you would like to see covered.
> >
>
> maybe we could also submit a Intro course, I could do that
>
> > Vaclav
> >
>
>
> --
> ciao
> Luca
>
> www.lucadelu.org
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Giuseppe Amatulli, Ph.D.

Research scientist at
Yale School of Forestry & Environmental Studies
Yale Center for Research Computing
Center for Science and Social Science Information
New Haven, 06511
Teaching: http://spatial-ecology.org
Work:  https://environment.yale.edu/profile/giuseppe-amatulli/
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] i.superpixels.slic ( was: #3142 Implementing SLIC image segmentation)

2017-01-26 Thread Markus Metz 
On Mon, Jan 23, 2017 at 11:19 AM, Rashad Kanavath <
mohammedrasha...@gmail.com> wrote:
>
>
>
> On Mon, Jan 23, 2017 at 9:22 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:
>>
>> Hi Rashad,
>>
>> On 22/01/17 11:00, Rashad Kanavath wrote:
>>>
>>> I fixed all the points from last mail.
>>
>>
>> Wonderful !
>>
>> It seems that you missed one point (see in the ticket #3142/#3247).
>>
>> Thank you so much for this great job !
>
>
> Thanks. Sorry that I missed it. I will push a fix for both and update the
tracker too.

I found time to review the code and discovered a few more issues:

L210
  pdata  = G_malloc (sizeof (int) * group_ref.nfiles);
must be
  pdata  = G_malloc (sizeof (int *) * group_ref.nfiles);

L232
pdata[nf][index] = ((int *) i_band)[col];
works only if the input is CELL_TYPE
i_band should be *DCELL, pdata should be ***DCELL such that L232 becomes
pdata[row][col][nf] = i_band[col];
the remaining code needs to be updated for changes in pdata

L468
no need to allocate and free a new row buffer for each output row

in SLIC_EnforceLabelConnectivity()
allocating sizeof(int) * nrows * ncols) for both xvec and yvec can cause
OOM errors. Superpixels should be much smaller, thus dynamic reallocation
would be better.

L586
this is the wrong place to update numlabels, better do
numlabels = SLIC_EnforceLabelConnectivity()
in main() L457

NULL handling must be implemented
cells where any input band is NULL must be skipped.
Initializing seeds must be changed at L323-327 to avoid initializazion with
NULLs

A few variables are allocated as vectors even though they hold some info
about each cell. They should be allocated as matrices. E.g. klabels is
currently accessed as klabels[row * ncols + col], better would be
klabels[row][col]. Equivalent for pdata and distvec. This change will make
it easier to use the segment library for managing temporary data.

The spatial and spectral distances are currently not comparable, the rather
cryptic compactness parameter needs to be used to make them comparable and
determine the weight for the spatial and spectral distances. It would be
easier to understand if the spatial and spectral distances are separately
scaled such that each is in the range [0, 1]. This is already done in
i.segment and also described in the SLIC paper in formula 2. Compactness
could then be changed to be the weight for spatial distance with default
0.5. Values > 0.5 would favour the spatial distance and cause more compact
superpixels while values < 0.5 would favour spectral distance and cause
less compact but spectrally more homogeneous superpixels.

The option to perturb seeds could be useful to get more robust initial
seeds. A similar mechanism could also be used to find a non-NULL cell as
initial seed location.

Currently the module has an option to specify the desired number of
superpixels. That makes comparison of the results for the same input but
different computational regions difficult. Instead of the number of
superpixels, the average superpixel size could be an input option, that
would make results comparable.

Markus M

>
>
>>
>> Moritz
>>
>>
>>
>>>
>>> On Fri, Jan 6, 2017 at 9:28 AM, Markus Metz
>>> mailto:markus.metz.gisw...@gmail.com>>
>>> wrote:
>>>
>>>
>>>
>>> On Tue, Dec 27, 2016 at 9:05 PM, Rashad Kanavath
>>> mailto:mohammedrasha...@gmail.com>>
wrote:
>>>
>>>
>>>
>>> I had pushed a updated version of code:
>>>
>>> Done:
>>> 1. input is a imagery group from i.group (handles all raster in
>>> the group)
>>> 2. removed rgb2lab conversion
>>> 3. implementation of id output map
>>> 4. replaced  fmin with MIN and MAX macro
>>> 5. compactness is a new option to module? (default is 20 from
paper)
>>>
>>> Wonderful, thanks!
>>>
>>>
>>> TODO:
>>> 1. add option for SLICO
>>> 2. use segment library to avoid memory limitation when reading
>>> raster data
>>>
>>> Hope this works now. Let me know If I missed something else.
>>>
>>> Code clean-up:
>>> - please use tools/grass_indent.sh
>>> - move variable declarations to the beginning of a code block
>>> - convert C++ style comments to C style comments
>>> - line 155
>>>   int sz = nrows * ncols;
>>>
>>> can cause integer overflow. Use off_t (large raster maps can only be
>>> handled with LFS, i.e. off_t being a 64bit integer).
>>>
>>> - fix L157: must be
>>>   int **pdata;
>>>
>>>   pdata = G_malloc(sizeof(int) * group_ref.nfiles);
>>>
>>> - Lines 317,318 are correct, line 320 is wrong
>>>
>>>
>>> And...
>>>
>>> Happy New Year to all :-)
>>>
>>> Happy new year to you too!
>>>
>>> Markus M
>>>
>>>
>>>
>>> On Thu, Dec 22, 2016 at 10:12 AM, Markus Neteler
>>> mailto:nete...@osgeo.org>> wrote:
>>>
>>> On Thu, Dec 22, 2016 at 12:01 AM, Markus Metz
>>> >> > wrote:
>>

Re: [GRASS-dev] v.clean threshold value unit for 'prune'

2017-01-26 Thread Markus Metz 
On Thu, Jan 26, 2017 at 11:15 AM, Paulo van Breugel 
wrote:
>
>
>
> On 26-01-17 11:03, Markus Metz wrote:
>
>
>
> On Thu, Jan 26, 2017 at 10:51 AM, Paulo van Breugel <
p.vanbreu...@gmail.com> wrote:
> >
> > Hi
> >
> > I am using the v.clean tool with the option "prune". According to the
manual, threshold values have to be in map units. I am using this with a
latlon map with vertices as close as 0.0001 degrees. However, v.clean only
removes vertices at threshold values of about 50 or up. This seems to
suggest that the tools assumes threshold values are in meters?
>
> The prune tool of v.clean never really worked. Please use v.generalize
instead.
>
>
> OK, will do. Still the question remains whether this is a bug, an error
in the manual page (i.e., threshold values are not in mapping units, but in
meters like for the rmarea) , or I am doing something wrong (note that it
seems to work fine if one assumed threshold values have to be in meters).
If a bug or error in the manual page, I can create a ticket.

It's a bug in the code [0], the algorithm is not working properly. There is
v.generalize, therefore I recommend to remove the prune tool from v.clean.

Markus M

[0]
https://trac.osgeo.org/grass/browser/grass/trunk/lib/vector/diglib/prune.c
>
>
>
> Markus M
>
> >
> > Best wishes,
> >
> > Paulo
> >
> > ___
> > grass-dev mailing list
> > grass-dev@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-dev
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Still Failing: GRASS-GIS/grass-ci#1891 (master - 8f32267)

2017-01-26 Thread Travis CI 
Build Update for GRASS-GIS/grass-ci
-

Build: #1891
Status: Still Failing

Duration: 11 minutes and 41 seconds
Commit: 8f32267 (master)
Author: Markus Neteler
Message: i18N: hopefully fixed Korean plural form (checked with 'make verify')

git-svn-id: https://svn.osgeo.org/grass/grass/trunk@70435 
15284696-431f-4ddb-bdfa-cd5b030d7da7

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/ffba3096c331...8f322671692a

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/195517939

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3247: i.superpixels.slic fails when region larger than 500x500 pix (on Win7)

2017-01-26 Thread GRASS GIS 
#3247: i.superpixels.slic fails when region larger than 500x500 pix (on Win7)
--+
  Reporter:  tgrippa  |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.0.6
 Component:  Imagery  |Version:  unspecified
Resolution:  fixed|   Keywords:  i.superpixels.slic
   CPU:  Unspecified  |   Platform:  MSWindows 7
--+

Comment (by mlennert):

 For now I've committed (r70434) just the fix for the segmentation fault,
 not the rest of the patch, so that others can work with the module.

 Please test (AFAIK for Windows users you will have to wait until tomorrow
 to get the binary compiled) and tell us if we can close this ticket.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3247: i.superpixels.slic fails when region larger than 500x500 pix (on Win7)

2017-01-26 Thread GRASS GIS 
#3247: i.superpixels.slic fails when region larger than 500x500 pix (on Win7)
--+
  Reporter:  tgrippa  |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.0.6
 Component:  Imagery  |Version:  unspecified
Resolution:  fixed|   Keywords:  i.superpixels.slic
   CPU:  Unspecified  |   Platform:  MSWindows 7
--+
Changes (by mlennert):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"70434" 70434]:
 {{{
 #!CommitTicketReference repository="" revision="70434"
 i.superpixels.slic: allocate on the heap, not the stack (fixes #3247)
 }}}

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] trac problem when posting a ticket: no space left on device

2017-01-26 Thread Markus Neteler 
On Thu, Jan 26, 2017 at 10:51 AM, Markus Neteler  wrote:
> On Thu, Jan 26, 2017 at 9:07 AM, Markus Metz
>  wrote:
>> On Thu, Jan 26, 2017 at 8:57 AM, Moritz Lennert
>>  wrote:
>>>
>>> Trying to post a new ticket to trac, I got the following error:
...
>> svn is also no longer working because of a full disk on the svn server
>
...
> https://trac.osgeo.org/osgeo/ticket/1857

Problem solved by strk!

markusN
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.clean threshold value unit for 'prune'

2017-01-26 Thread Paulo van Breugel 



On 26-01-17 11:03, Markus Metz wrote:



On Thu, Jan 26, 2017 at 10:51 AM, Paulo van Breugel 
mailto:p.vanbreu...@gmail.com>> wrote:

>
> Hi
>
> I am using the v.clean tool with the option "prune". According to 
the manual, threshold values have to be in map units. I am using this 
with a latlon map with vertices as close as 0.0001 degrees. However, 
v.clean only removes vertices at threshold values of about 50 or up. 
This seems to suggest that the tools assumes threshold values are in 
meters?


The prune tool of v.clean never really worked. Please use v.generalize 
instead.


OK, will do. Still the question remains whether this is a bug, an error 
in the manual page (i.e., threshold values are not in mapping units, but 
in meters like for the rmarea) , or I am doing something wrong (note 
that it seems to work fine if one assumed threshold values have to be in 
meters). If a bug or error in the manual page, I can create a ticket.





Markus M

>
> Best wishes,
>
> Paulo
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org 
> https://lists.osgeo.org/mailman/listinfo/grass-dev



___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.clean threshold value unit for 'prune'

2017-01-26 Thread Markus Metz 
On Thu, Jan 26, 2017 at 10:51 AM, Paulo van Breugel 
wrote:
>
> Hi
>
> I am using the v.clean tool with the option "prune". According to the
manual, threshold values have to be in map units. I am using this with a
latlon map with vertices as close as 0.0001 degrees. However, v.clean only
removes vertices at threshold values of about 50 or up. This seems to
suggest that the tools assumes threshold values are in meters?

The prune tool of v.clean never really worked. Please use v.generalize
instead.

Markus M

>
> Best wishes,
>
> Paulo
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] v.clean threshold value unit for 'prune'

2017-01-26 Thread Paulo van Breugel 

Hi

I am using the v.clean tool with the option "prune". According to the 
manual, threshold values have to be in map units. I am using this with a 
latlon map with vertices as close as 0.0001 degrees. However, v.clean 
only removes vertices at threshold values of about 50 or up. This seems 
to suggest that the tools assumes threshold values are in meters?


Best wishes,

Paulo

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Next events workshop

2017-01-26 Thread Luca Delucchi 
On 25 January 2017 at 15:45, Vaclav Petras  wrote:
> I plan to submit a workshop for FOSS4G 2017 in Boston. GRASS and lidar
> related.
>

cool

> Please, let me know if you want to collaborate on this or other workshop or
> you have some topics you would like to see covered.
>

maybe we could also submit a Intro course, I could do that

> Vaclav
>


-- 
ciao
Luca

www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] trac problem when posting a ticket: no space left on device

2017-01-26 Thread Markus Neteler 
On Thu, Jan 26, 2017 at 9:07 AM, Markus Metz
 wrote:
> On Thu, Jan 26, 2017 at 8:57 AM, Moritz Lennert
>  wrote:
>>
>> Trying to post a new ticket to trac, I got the following error:
>>
>> ***
>>  Trac detected an internal error:
>>
>> OperationalError: could not extend file "base/16400/76283": No space left
>> on device
>> HINT:  Check free disk space.
>> ***
>
> svn is also no longer working because of a full disk on the svn server

I have emergency freed 2GB. The disk full issue is currently tracked here:

https://trac.osgeo.org/osgeo/ticket/1857

markusN
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Next events workshop

2017-01-26 Thread Luca Delucchi 
On 25 January 2017 at 10:56, Veronica Andreo  wrote:
> Ciao Luca, all :)
>

Ciao,

>
> I would like to offer a TGRASS workshop in FOSS4G EU in Paris, basically to
> demostrate the use of tgrass. However, it might also be a good idea to offer
> first an introduction to grass gis... otherwise, it might be too much,
> especially for newcommers (that I learnt in FOSS4G Argentina last year)...
> So, maybe 2 workshops: intro to grass and then, tgrass (with some catchy
> title).
>
> What do you think? Anyone interested?
>

I'm interested in both.. see if others are interested to join us

> cheers,
> Vero
>


-- 
ciao
Luca

www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] vector layer contains error not detected by v.build nor cleaned in v.clean

2017-01-26 Thread Paulo van Breugel 



On 26-01-17 08:40, Markus Metz wrote:



On Wed, Jan 25, 2017 at 5:19 PM, Paulo van Breugel 
mailto:p.vanbreu...@gmail.com>> wrote:

>
>
>
> On 25-01-17 16:57, Markus Metz wrote:
>
>
>
> On Wed, Jan 25, 2017 at 12:31 PM, Paulo van Breugel 
mailto:p.vanbreu...@gmail.com>> wrote:

> >
> > Dear all,
> >
> > I have a vector layer which I cleaned up using v.clean. It all 
appears to be fine, but when trying to export using the libkml in 
v.out.ogr and the type=area option, I am getting the warning and error 
messages like below:

> >
> > Warning 1: Ring Self-intersection at or near point
> > 88.100626640406631 27.668444701473838
> > ERROR 6: Invalid polygon
> > Warning 1: Ring Self-intersection at or near point
> >
> > In the resulting kml file, some of the polygons are missing. If I 
use the kml output in v.out.ogr, I am not getting any warnings, but 
similarly, some of the polygons are missing.

> >
> > When I import the layer in Spatialite and check the geometries I 
am getting similar warnings / error messages, e.g.,:

> >
> > 27 Ring Self-intersection at or near point 82.397900772562522 
29.707213605319616

> >
> >
> > How can I identify and clean these issues in GRASS? Checking for 
topological errors with v.build does not result in any error, and I 
tried the various tools in v.clean to no avail.

>
> Did you try
> v.clean -c type=boundary tool=rmsa,break,rmdangle threshold=0,0,-1
> ?
>
> Yes, I tried
>
> Also try v.build -e
>
>
> Tried that too, it does not report any error.
>
> Generally where the boundaries of two polygons with the same 
category touch each other by one point (illustrated below), Spatialite 
and QGIS (both using geos) seem to report an error for that point.

>
> +-+   +
> | | /   \
> |  A  |+  A  +
> | | \   /
> +-+   +
>
OK. In some cases, the vertex is not exactly on the line but just 
slightly off. It depends on how floating point precision is handled if 
this is regarded as an intersection or not. If GRASS assumes a smaller 
floating point precision error than GEOS, GRASS treats it as no 
intersection while GEOS might recognize an intersection. A solution 
could be to snap boundaries with a very small threshold.

That did help me to get rid of many of the reported errors, thanks!



Just a guess.

Markus M

>
> I am not sure yet if that is what is causing the problem (missing 
polygons) when exporting to kml. I am cleaning a layer now for export. 
Will report how that worked out.

>
> Markus M
>
> >
> > Paulo
> > ___
> > grass-dev mailing list
> > grass-dev@lists.osgeo.org 
> > https://lists.osgeo.org/mailman/listinfo/grass-dev
>
>


___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] trac problem when posting a ticket: no space left on device

2017-01-26 Thread Markus Metz 
On Thu, Jan 26, 2017 at 8:57 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:
>
> Trying to post a new ticket to trac, I got the following error:
>
> ***
>  Trac detected an internal error:
>
> OperationalError: could not extend file "base/16400/76283": No space left
on device
> HINT:  Check free disk space.
> ***

svn is also no longer working because of a full disk on the svn server

Markus M

>
> Don't know if this specific to the GRASS trac or not.
>
> Moritz
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev