Re: [GRASS-dev] Seeking advices for image segmentation algorithms and windows compile question

[Markus Neteler]

On May 12, 2016 6:34 AM, "Yang, Bo (yangb2)"  wrote:
...
> For the 32 bit version system the error:
> -
> GRASS GIS 7.1.svn r68419 compilation log
> --
> Started compilation: Wed, May 11, 2016  7:34:55 PM
> --
> Errors in:
> /usr/src/grass_trunk/lib/python/ctypes
> /usr/src/grass_trunk/display/d.grid
> /usr/src/grass_trunk/display/d.path
...
> /usr/src/grass_trunk/temporal/t.vect.univar
> --
> In case of errors please change into the directory with error and run
'make'.

... Did you try this?

> If you get multiple errors, you need to deal with them in the order they
> appear in the error log. If you get an error building a library, you will
> also get errors from anything which uses the library.

Please try as suggested.

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

Re: [GRASS-dev] Seeking advices for image segmentation algorithms and windows compile question

[Yang, Bo (yangb2)]

Hi Helmut,


Thanks for the help. Now I think I sort of solved the issue. Below are the 
updates:

1)
>could you do following steps to test if there is some interference with
>other python installation?

>- rename the ArcGIS python installation folder temporarily (e.g. Python27 ->
Yyypython27)

>- do the same with the anaconda python installation folder

>- try to start start again your self compiled winGRASS 7.1svn 

>- report back here if your self compiled winGRASS 7.1svn starts or not 

>- rename back the both folders

I did it. Even changed the python27 folders name, winGRASS 7.1svn can not start 
either, and it reported the same error. I think it not python's problem.

2)
>for a workaround see:

>https://trac.osgeo.org/grass/ticket/3011#comment:4

>and see 

>https://grass.osgeo.org/grass71/manuals/grass7.html

>howto start grass71 in text mode and then start the GUI:

>e.g. in the OSGeo4W-console:

C:\>grass71svn.bat -text C:\grassdata\test3035\data
C:\>g.gui wxpython


Thanks! I tried and both text mode and g.gui mode are able to start GRASS71svn 
without any issue. So I think I came across the exactly same situation reported 
in that ticket case.

3)
>ok, good to know that it compiles now. 

>for the error message, see 

>https://trac.osgeo.org/grass/ticket/3011

>I'll add your example to the ticket. 

>if you have another windows box without another python installation, try to
compile there until this ticket is solved.

Actually, I created 2 clean installed VM win7. One is win7 pro 64 bit, the 
other is win 7 pro 32bit (for the 64 bit system, I use 64bit version of Osgeo4w 
and msys, and vice versa). I follow the same tutorial. This time it's very 
clean system without any software installed. But neither can successfully built 
the GRASS 71svn.
For the 32 bit version system the error:
-
GRASS GIS 7.1.svn r68419 compilation log
--
Started compilation: Wed, May 11, 2016  7:34:55 PM
--
Errors in:
/usr/src/grass_trunk/lib/python/ctypes
/usr/src/grass_trunk/display/d.grid
/usr/src/grass_trunk/display/d.path
/usr/src/grass_trunk/display/d.vect
/usr/src/grass_trunk/display/d.vect.chart
/usr/src/grass_trunk/display/d.vect.thematic
/usr/src/grass_trunk/display/d.where
/usr/src/grass_trunk/general/g.copy
/usr/src/grass_trunk/general/g.findfile
/usr/src/grass_trunk/general/g.list
/usr/src/grass_trunk/general/g.proj
/usr/src/grass_trunk/general/g.region
/usr/src/grass_trunk/general/g.remove
/usr/src/grass_trunk/general/g.rename
/usr/src/grass_trunk/raster/r.carve
/usr/src/grass_trunk/raster/r.contour
/usr/src/grass_trunk/raster/r.cost
/usr/src/grass_trunk/raster/r.drain
/usr/src/grass_trunk/raster/r.external
/usr/src/grass_trunk/raster/r.external.out
/usr/src/grass_trunk/raster/r.flow
/usr/src/grass_trunk/raster/r.horizon
/usr/src/grass_trunk/raster/r.in.gdal
/usr/src/grass_trunk/raster/r.in.lidar
/usr/src/grass_trunk/raster/r.latlong
/usr/src/grass_trunk/raster/r.out.gdal
/usr/src/grass_trunk/raster/r.proj
/usr/src/grass_trunk/raster/r.random
/usr/src/grass_trunk/raster/r.reclass
/usr/src/grass_trunk/raster/r.region
/usr/src/grass_trunk/raster/r.resamp.bspline
/usr/src/grass_trunk/raster/r.resamp.rst
/usr/src/grass_trunk/raster/r.sim/r.sim.water
/usr/src/grass_trunk/raster/r.sim/r.sim.sediment
/usr/src/grass_trunk/raster/r.stream.extract
/usr/src/grass_trunk/raster/r.sun
/usr/src/grass_trunk/raster/r.sunhours
/usr/src/grass_trunk/raster/r.sunmask
/usr/src/grass_trunk/raster/r.to.vect
/usr/src/grass_trunk/raster/r.volume
/usr/src/grass_trunk/raster/r.walk
/usr/src/grass_trunk/raster/r.what
/usr/src/grass_trunk/raster3d/r3.flow
/usr/src/grass_trunk/raster3d/r3.in.lidar
/usr/src/grass_trunk/vector/v.buffer
/usr/src/grass_trunk/vector/v.build
/usr/src/grass_trunk/vector/v.build.polylines
/usr/src/grass_trunk/vector/v.category
/usr/src/grass_trunk/vector/v.class
/usr/src/grass_trunk/vector/v.clean
/usr/src/grass_trunk/vector/v.cluster
/usr/src/grass_trunk/vector/v.colors
/usr/src/grass_trunk/vector/v.colors.out
/usr/src/grass_trunk/vector/v.db.connect
/usr/src/grass_trunk/vector/v.db.select
/usr/src/grass_trunk/vector/v.decimate
/usr/src/grass_trunk/vector/v.delaunay
/usr/src/grass_trunk/vector/v.distance
/usr/src/grass_trunk/vector/v.drape
/usr/src/grass_trunk/vector/v.edit
/usr/src/grass_trunk/vector/v.extract
/usr/src/grass_trunk/vector/v.extrude
/usr/src/grass_trunk/vector/v.generalize
/usr/src/grass_trunk/vector/v.hull
/usr/src/grass_trunk/vector/v.info
/usr/src/grass_trunk/vector/v.in.ascii
/usr/src/grass_trunk/vector/v.in.db
/usr/src/grass_trunk/vector/v.in.dxf
/usr/src/grass_trunk/vector/v.in.region
/usr/src/grass_trunk/vector/v.kcv
/usr/src/grass_trunk/vector/v.kernel
/usr/src/grass_trunk/vector/v.label
/usr/src/grass_trunk/vector/v.lidar.correction
/usr/src/grass_trunk/vector/v.lidar.edgedetection
/usr/src/grass_trunk/vector/v.lidar.growing
/usr/src/grass_trunk/vector/v.lrs/v.lrs.create

Re: [GRASS-dev] Seeking advices for image segmentation algorithms and windows compile question

[Yang, Bo (yangb2)]

Hi Martin,

Nailed it! Thanks for asking.

Best,
Bo Yang

-Original Message-
From: Martin Landa [mailto:landa.mar...@gmail.com] 
Sent: Wednesday, May 11, 2016 5:32 AM
To: Yang, Bo (yangb2) 
Cc: grass-dev@lists.osgeo.org; Markus Metz 
Subject: Re: [GRASS-dev] Seeking advices for image segmentation algorithms and 
windows compile question

Hi,

2016-05-05 1:19 GMT+02:00 Yang, Bo (yangb2) :
> This is Bo Yang from the University of Cincinnati. I am working with 
> Moritz and Markus for the GSoC 2016 project-- Additional segmentation 
> algorithms for i.segment [0]. Currently, the i.segment module only 
> provides one

please link your page here [1]. Thanks, Martin

[1] https://trac.osgeo.org/grass/wiki/GSoC#a2016

> rem Set environmental variables
>
> rem
>
> call %OSGEO4W_ROOT%\bin\o4w_env.bat
>
> call %OSGEO4W_ROOT%\apps\grass\grass-7.1.svn\etc\env.bat
>
>
>
> rem
>
> rem Launch GRASS GIS
>
> rem
>
> "%GRASS_PYTHON%" "%GISBASE%\etc\grass71.py" %*
>
>
>
> rem
>
> rem Pause on error
>
> rem
>
> if %ERRORLEVEL% GEQ 1 pause
>
>
>
> [0] https://wiki.osgeo.org/wiki/GRASS_GSoC_2016_Segment_Algorithms
>
> [1] https://trac.osgeo.org/grass/wiki/CompileOnWindows
>
>
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev



--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] re-targeting of tickets

[Markus Neteler]

Hi devs,

I need trac help with this one:

On Tue, May 10, 2016 at 9:46 PM, Veronica Andreo
> Is it possible that you forgot to re-target tickets after 7.0.4 release?
...
> check here:
> https://trac.osgeo.org/grass/milestone/7.0.5
>
> you can see only 8 active tickets.. that's not very credible :-)

Yep!
I thought that I had retargeted them from 7.0.4 to 7.0.5 but actually
that's not true.
How to do that? I just cannot find it...

?
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3030: v. generalize fails to generalize polygons in a random manner

[GRASS GIS]

#3030: v. generalize fails to generalize polygons in a random manner
-+--
  Reporter:  dido|  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  major   |  Milestone:  7.0.5
 Component:  Vector  |Version:  7.0.4
Resolution:  |   Keywords:  v.generalize
   CPU:  x86-64  |   Platform:  MSWindows 7
-+--

Comment (by mmetz):

 Replying to [comment:10 dido]:
 > OK, I get what's breaking up generalization.
 >
 > Talking about test1.png - it's a piece of polygon boundary that's
 several hundred meters in length, unfortunately causing a self-
 intersection. Why v.generalize discards the whole polygon side that's
 several kilometers long but not the problematic sector only?

 Because implementing such a feature would slow down v.generalize
 considerably, it is already rather slow for complex vectors. Splicing in
 an original part of the boundary into the modified version could also
 cause quite a few other problems (no common vertex to start with), and
 topological correctness is not guaranteed. Note that boundaries and
 polygons are not the same.
 >
 > Actually in my first tryout the whole area was not fishnet'ed to
 5000x5000 m cells so  small problematic sectors resulted to tens and
 hundreds of kilometers of shoreline being not generalized at all, making
 the tool completely unpredictable in the output.

 As I suggested previously, try stepwise generalization, starting with a
 small threshold, then increasing the threshold and using the output of the
 previous run as input for the next run. In your case, a threshold of 120
 seems rather large considering the vertex density of the boundaries.

 I suggest to close the ticket as invalid because v.generalize correctly
 discards boundary modifications that would result in errors.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3030: v. generalize fails to generalize polygons in a random manner

[GRASS GIS]

#3030: v. generalize fails to generalize polygons in a random manner
-+--
  Reporter:  dido|  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  major   |  Milestone:  7.0.5
 Component:  Vector  |Version:  7.0.4
Resolution:  |   Keywords:  v.generalize
   CPU:  x86-64  |   Platform:  MSWindows 7
-+--

Comment (by dido):

 OK, I get what's breaking up generalization.

 Talking about test1.png - it's a piece of polygon boundary that's several
 hundred meters in length, unfortunately causing a self-intersection. Why
 v.generalize discards the whole polygon side that's several kilometers
 long but not the problematic sector only?

 Actually in my first tryout the whole area was not fishnet'ed to 5000x5000
 m cells so  small problematic sectors resulted to tens and hundreds of
 kilometers of shoreline being not generalized at all, making the tool
 completely unpredictable in the output.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Fwd: new trac anti-spam filter

[Markus Neteler]

On Tue, May 10, 2016 at 11:50 PM, Vaclav Petras  wrote:
> On Sat, May 7, 2016 at 7:19 PM, Markus Neteler  wrote:
>> > https://trac.osgeo.org/grass/timeline
>> >
>> Cleaned and Bayes filter better trained now.
>
> New spam wiki pages and they seems to contain text from:
...

Solved by visiting (as admin)
https://trac.osgeo.org/grass/admin/spamfilter/monitor

and confirming the already caught pages as "spam". So the blacklist in
the "BadContent" pages worked ok but (at time?) the just still shows
up unless treated properly in the "monitoring" page. That's all I know
due to lack of time to study the trac spamfilter plugin properly...

But any use can report spam (I think there is a new link in the upper
right corner).

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

Re: [GRASS-dev] [GRASS GIS] #3030: v. generalize fails to generalize polygons in a random manner

[GRASS GIS]

#3030: v. generalize fails to generalize polygons in a random manner
-+--
  Reporter:  dido|  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  major   |  Milestone:  7.0.5
 Component:  Vector  |Version:  7.0.4
Resolution:  |   Keywords:  v.generalize
   CPU:  x86-64  |   Platform:  MSWindows 7
-+--
Changes (by mmetz):

 * Attachment "topo_errors.zip" added.

 topological errors for v_generalize_test_polygons.zip

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3030: v. generalize fails to generalize polygons in a random manner

[GRASS GIS]

#3030: v. generalize fails to generalize polygons in a random manner
-+--
  Reporter:  dido|  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  major   |  Milestone:  7.0.5
 Component:  Vector  |Version:  7.0.4
Resolution:  |   Keywords:  v.generalize
   CPU:  x86-64  |   Platform:  MSWindows 7
-+--

Comment (by mmetz):

 Replying to [comment:8 dido]:
 > Hi,
 >
 > the reason why non-generalized polygons appear in the output is
 certainly clear. My point is that none of these polygons will be damaged
 due to generalization over-simplification, so I suspect a v.generalize
 algorithm problem here.
 >
 > As an example find attached 4 pairs of shapefiles that produce non-
 simplified polygons.

 I modified v.generalize a bit in my local copy to write out those modified
 boundaries that would damage topology. In each of your test cases.
 v.generalize is correct in not generalizing these boundaries. They would
 collapse to a point, intersect with themselves, intersect with another
 boundary, or produce a zero-size area. See screenshots in attached
 topo_errors.zip.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Added i.landsat8.swlst in grass-addons

[Blumentrath, Stefan]

Hi again,

I just pushed a new addon ("i.landsat8.qc") to addons svn.
i.landsat8.qc reclassifies Landsat8 QA band according to a user defined filter 
for bit pattern representing unacceptable quality pixels. It implements 
basically the procedure mentioned below...

Any feedback is welcome...

Kind regards,
Stefan

-Original Message-
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of 
Blumentrath, Stefan
Sent: 10. mai 2016 09:57
To: Nikos Alexandris ; Vaclav Petras 

Cc: grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] Added i.landsat8.swlst in grass-addons

Another issue I came across it that currently, a possibly existing user mask 
will be simply overwritten, while it might be more friendly to backup the user 
mask before and restore it after the module finished... However, in order to 
simplify the module a bit, an option might be to move the masking part out of 
the module, and probably write something like this: 
https://grass.osgeo.org/grass70/manuals/i.modis.qc.html for Landsat, if that 
does not exist yet(?). Seems you thought about it already?
Based on Markus tutorial 
(http://courses.neteler.org/processing-landsat8-data-in-grass-gis-7/#Applying_the_Landsat_8_Quality_Assessment_%28QA%29_Band)
 and the info here http://landsat.usgs.gov/qualityband.php that should be a 
quite doable job. If no landsat bitpattern module exists I might be able to 
volunteer...
The idea would be something like this: extract raster values from QA band, loop 
over those values, compare the bit pattern representation of the integer values 
with acceptable bit patterns defined by the user, add the result of the 
comparison to r.reclass rules, and finally reclassify the QA band...

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

Re: [GRASS-dev] [GRASS GIS] #3011: OSGeo4W-winGRASS71 r68376: starting wxgui fails

[GRASS GIS]

#3011: OSGeo4W-winGRASS71 r68376: starting wxgui fails
---+-
  Reporter:  hellik|  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  critical  |  Milestone:  7.0.5
 Component:  wxGUI |Version:  svn-trunk
Resolution:|   Keywords:
   CPU:  x86-64|   Platform:  MSWindows 7
---+-

Comment (by martinl):

 The error seems to be connected to the startup screen. It's strange both
 versions (7.0.4 and 7.1svn are build against the same version of wxPython)

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Seeking advices for image segmentation algorithms and windows compile question

[Martin Landa]

Hi,

2016-05-05 1:19 GMT+02:00 Yang, Bo (yangb2) :
> This is Bo Yang from the University of Cincinnati. I am working with Moritz
> and Markus for the GSoC 2016 project-- Additional segmentation algorithms
> for i.segment [0]. Currently, the i.segment module only provides one

please link your page here [1]. Thanks, Martin

[1] https://trac.osgeo.org/grass/wiki/GSoC#a2016

> rem Set environmental variables
>
> rem
>
> call %OSGEO4W_ROOT%\bin\o4w_env.bat
>
> call %OSGEO4W_ROOT%\apps\grass\grass-7.1.svn\etc\env.bat
>
>
>
> rem
>
> rem Launch GRASS GIS
>
> rem
>
> "%GRASS_PYTHON%" "%GISBASE%\etc\grass71.py" %*
>
>
>
> rem
>
> rem Pause on error
>
> rem
>
> if %ERRORLEVEL% GEQ 1 pause
>
>
>
> [0] https://wiki.osgeo.org/wiki/GRASS_GSoC_2016_Segment_Algorithms
>
> [1] https://trac.osgeo.org/grass/wiki/CompileOnWindows
>
>
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev



-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Seeking advices for image segmentation algorithms and windows compile question

[Helmut Kudrnovsky]

> Now on my desktop there are both shortcuts of "GRASS GIS 7.1.svn" and
"GRASS GIS 7.0.4". 
>Currently the GRASS GIS 7.0.4 can be normally started without any issue.
However, when start GRASS GIS >7.1.svn. the error below showed. 

for a workaround see:

https://trac.osgeo.org/grass/ticket/3011#comment:4

and see 

https://grass.osgeo.org/grass71/manuals/grass7.html

howto start grass71 in text mode and then start the GUI:

e.g. in the OSGeo4W-console:

C:\>grass71svn.bat -text C:\grassdata\test3035\data
C:\>g.gui wxpython





-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Seeking-advices-for-image-segmentation-algorithms-and-windows-compile-question-tp5264642p5265737.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

Re: [GRASS-dev] [GRASS GIS] #2766: GUI not able to create dropdown lists of columns for more than one map or table (was: it is not possible to set other column when working with v.db.join from gui)

[GRASS GIS]

#2766: GUI not able to create dropdown lists of columns for more than one map or
table
+--
  Reporter:  lfurtkevicova  |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:  7.2.0
 Component:  wxGUI  |Version:  7.0.1
Resolution: |   Keywords:  column lists
   CPU:  x86-64 |   Platform:  Linux
+--
Changes (by mlennert):

 * keywords:   => column lists
 * priority:  blocker => normal
 * component:  Database => wxGUI


Comment:

 Replying to [ticket:2766 lfurtkevicova]:
 > Problem with joinig database table to a vector map table using v.db.join
 from gui:
 > parameters `map`, `column` and `other_table` are OK, but it isn't
 possible to set `other_column`

 This is a more general problem than only in v.db.join (see column and
 to_column in v.distance or points_column option in v.vect.stats for
 example): whenever you need to specify columns in two different maps, the
 GUI cannot handle this. Only the columns of one map are in the list. I'm
 no expert in the GUI, but I imagine the G_OPT_DB_COLUMN standard parser
 option looks for columns in the map defined by G_OPT_V_MAP or
 G_OPT_V_INPUT, but it can only handle one defined in this way.

 This needs some fundamental solution in the wxgui, not a specific module.

 In any case, the does not render the module unusable, even in the GUI, as
 one can always type the column name.

 So, I'm downgrading this to normal and changing the title of the bug.

 Moritz

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3011: OSGeo4W-winGRASS71 r68376: starting wxgui fails

[GRASS GIS]

#3011: OSGeo4W-winGRASS71 r68376: starting wxgui fails
---+-
  Reporter:  hellik|  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  critical  |  Milestone:  7.0.5
 Component:  wxGUI |Version:  svn-trunk
Resolution:|   Keywords:
   CPU:  x86-64|   Platform:  MSWindows 7
---+-

Comment (by hellik):

 Replying to [comment:2 veroandreo]:
 > Hi Helli,
 >
 > I just updated grass71 from osgeo4w, so I have r68380, and no issues
 here. This is also a MSWindows 7 system. It all started normally. Also
 7.0.4 works fine.

 thanks for testing.

 tested here again: OSGeo4W-GRASS GIS 7.1.svn (r68418) still fails with the
 above mentioned error.

 OSGeo4W-GRASS GIS 7.0.4 works also fine here.

 another test in the OSGeo4W-console:

 {{{
 C:\>grass71svn.bat --text
 }}}

 it starts in the text mode without any error, then:

 {{{
 C:\>g.gui wxpython
 }}}

 and the GUI starts also without any error.

 any idea?

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3030: v. generalize fails to generalize polygons in a random manner

[GRASS GIS]

#3030: v. generalize fails to generalize polygons in a random manner
-+--
  Reporter:  dido|  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  major   |  Milestone:  7.0.5
 Component:  Vector  |Version:  7.0.4
Resolution:  |   Keywords:  v.generalize
   CPU:  x86-64  |   Platform:  MSWindows 7
-+--
Changes (by dido):

 * Attachment "v_generalize_test_polygons.zip" added.


--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3030: v. generalize fails to generalize polygons in a random manner

[GRASS GIS]

#3030: v. generalize fails to generalize polygons in a random manner
-+--
  Reporter:  dido|  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  major   |  Milestone:  7.0.5
 Component:  Vector  |Version:  7.0.4
Resolution:  |   Keywords:  v.generalize
   CPU:  x86-64  |   Platform:  MSWindows 7
-+--

Comment (by dido):

 Hi,

 the reason why non-generalized polygons appear in the output is certainly
 clear. My point is that none of these polygons will be damaged due to
 generalization over-simplification, so I suspect a v.generalize algorithm
 problem here.

 As an example find attached 4 pairs of shapefiles that produce non-
 simplified polygons.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2940: Compiling Grass-7.0.3 under FreeBSD: tplot directory (with log)

[GRASS GIS]

#2940: Compiling Grass-7.0.3 under FreeBSD: tplot directory (with log)
--+-
  Reporter:  pieside  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.4
 Component:  Default  |Version:  7.0.3
Resolution:   |   Keywords:  FreeBSD
   CPU:  x86-64   |   Platform:  Other Unix
--+-

Comment (by mmetz):

 Replying to [comment:3 glynn]:
 > Replying to [comment:2 pieside]:
 > > The problems seems to be an old friend:
 > >
 > {{{
 > /home/pierre/tmp/grass7/grass-7.0.3/dist.x86_64-unknown-
 freebsd10.2/lib/libgrass_gis.7.0.3.so: undefined reference to `libiconv'
 > }}}
 >
 > This usually means that it's including  from libiconv but
 linking against the system iconv (which may be part of libc).
 >
 > One way to solve issues with multiple library versions is to create
 "include" and "lib" directories, populate them with symlinks to the
 desired versions of the headers and libraries, and use --with-includes=
 and --with-libs= to put those directories at the front of the search path.

 You can also configure GRASS, then manually edit
 include/Make/Platform.make and set

 {{{
 ICONVLIB=
 }}}

 to

 {{{
 ICONVLIB= -liconv
 }}}

 Most of GRASS then compiles for me on FreeBSD 10.3 with both clang and
 gcc, with the exception of wxnviz and the temporal modules (problem with
 numpy + ctypes), but that is a different problem.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2980: r.watershed and max_slope_length

[GRASS GIS]

#2980: r.watershed and max_slope_length
+-
  Reporter:  mankoff|  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:  7.0.4
 Component:  Docs   |Version:  7.0.1
Resolution: |   Keywords:  r.watershed
   CPU:  OSX/Intel  |   Platform:  MacOSX
+-

Comment (by mmetz):

 Replying to [ticket:2980 mankoff]:
 > I'm not sure if this is a bug, but I think it might be. The
 {{{max_slope_length}}} seems to have no effect in the {{{r.watershed}}}
 program. Below is an example that should work on the NC data set. I'd
 expect there to be different accumulation maps based on setting
 {{{max_slope_length}}}, but they appear identical.

 The `max_slope_length` option only affects RUSLE outputs `length_slope`
 and `slope_steepness`. From the manual: "This input is used for the RUSLE
 calculations".

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2979: r.watershed: better documentation for 'drainage' w/ MFD

[GRASS GIS]

#2979: r.watershed: better documentation for 'drainage' w/ MFD
--+-
  Reporter:  mankoff  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.0.4
 Component:  Docs |Version:  unspecified
Resolution:   |   Keywords:  r.watershed
   CPU:  Unspecified  |   Platform:  All
--+-

Comment (by mmetz):

 Replying to [ticket:2979 mankoff]:
 > When using MFD, is the drainage direction the direction of maximum flow?
 This isn't explicitly stated in the documentation. What if there is equal
 drainage in two directions?

 Yes, for MFD drainage direction follows maximum flow. In case of equal
 flow in more than one direction, the first encountered is used. This could
 be refined by using the steepest slope in case of equal flow. However,
 with MFD chances are very small that several directions have equal flow.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2981: r.watershed & blocking

[GRASS GIS]

#2981: r.watershed & blocking
+-
  Reporter:  mankoff|  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:  7.0.4
 Component:  Raster |Version:  7.0.1
Resolution: |   Keywords:  r.watershed
   CPU:  OSX/Intel  |   Platform:  MacOSX
+-

Comment (by mmetz):

 Replying to [ticket:2981 mankoff]:
 > I'm not sure if this is a bug, but I think so. When I set the
 {{{blocking}} option to {{{r.watershed}}}, I see no difference in the
 accumulation map.

 The `blocking` option only affects RUSLE-related outputs `length_slope`
 and `slope_steepness`. Slope lengths are calculated from drainage paths
 through the terrain. Path tracing stops as soon as a blocking cell or a
 stream cell is encountered.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3030: v. generalize fails to generalize polygons in a random manner

[GRASS GIS]

#3030: v. generalize fails to generalize polygons in a random manner
-+--
  Reporter:  dido|  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  major   |  Milestone:  7.0.5
 Component:  Vector  |Version:  7.0.4
Resolution:  |   Keywords:  v.generalize
   CPU:  x86-64  |   Platform:  MSWindows 7
-+--

Comment (by mmetz):

 Replying to [comment:2 dido]:
 > Added attachments with generalized data over the original data, where
 the non-generalized polygons are well-visible.

 Area boundaries are not generalized if the modification would damage
 topology or if the boundaries would be over-generalized (zero-length
 boundaries). In your output, you see

 {{{
 Generalization (douglas)...
 Using threshold: 120 meters
 WARNING: 1953 boundaries were not modified because modification would
 damage topology
 WARNING: 1951 lines/boundaries were not modified due to over-
 simplification
 }}}

 That means the not generalized boundaries are not random, instead their
 generalization would cause errors, they should not be generalized and they
 are copied unmodified to the output. Try a smaller threshold or stepwise
 increase the threshold using the output of the previous simplification as
 input for the next simplification.

--
Ticket URL: 
GRASS GIS 

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