Re: [GRASS-dev] i.segment gives different results in G72 and G73

2016-12-04 Thread Markus Metz 
On Sun, Dec 4, 2016 at 9:56 AM, Martin Landa  wrote:
>
> Running `i.segment` on the same data in G72 and G73 gives different
> results. Both commands should use the same method - G72 supports only
> 'region growing', G73 has this method as default one.

Both versions use the same method by default. However, the G73 version of
region growing in i.segment has been modified, it is now faster for larger
objects (larger thresholds). A side effect is that objects might differ
slightly between G72 and G73, but both results are correct in terms of the
concept of region growing. The reason for the difference is when finding
the most similar neighbor region, there can be several equally best
neighbors. Which one is selected is more or less chance, to be precise, the
order of visiting the neighbors, and this order of visiting changed.

Markus M

>
> Region:
>
> {{{
> north:  -1057730
> south:  -1058250
> west:   -713860
> east:   -712960
> nsres:  0.25
> ewres:  0.25
> rows:   2080
> cols:   3600
> cells:  7488000
> }}}
>
> Command:
>
> {{{
> i.segment group=seg output=seg1 threshold=0.01 --o
> }}}
>
> G72:
>
> {{{
> ...
> Segmentation converged after 8 iterations
> Writing out segment IDs...
> i.segment complete. Number of segments created: 4367082
> (Sun Dec  4 09:42:19 2016) Command finished (3 min 36 sec)
> }}}
>
> G73:
>
> {{{
> Segmentation converged after 14 iterations
> Assigning region IDs to remaining single-cell regions...
> Writing out segment IDs...
> i.segment complete. Number of segments created: 4359666
> }}}
>
> Segmentation performed in G73 gives slightly different results and
> takes longer time to finish.
>
> Thanks for clarification in advance, Martin
>
> --
> 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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3079: shapelib/DBF driver: re-sync to GDAL/OGR needed

2016-12-04 Thread GRASS GIS 
#3079: shapelib/DBF driver: re-sync to GDAL/OGR needed
--+---
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  task | Status:  new
  Priority:  major|  Milestone:  7.4.0
 Component:  Database |Version:  svn-trunk
Resolution:   |   Keywords:  dbf, shapelib
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by mmetz):

 Replying to [comment:4 rouault]:
 > I've just resync'ed shapelib CVS from GDAL and make various fixes to
 compile in standalone mode (likely similar to yours). See
 http://lists.maptools.org/pipermail/shapelib/2016-December/000627.html
 >
 > Looking at r69890, the following is incorrect:
 > {{{
 > +#define CPL_IGNORE_RET_VAL_INT(ret_val_int)return
 > }}}

 I noticed that too after comparing GDAL shapelib with standalone shapelib.
 CPL_IGNORE_RET_VAL_INT is used only once, so I have already replaced in
 r69892

 {{{
 CPL_IGNORE_RET_VAL_INT(DBFFlushRecord( psDBF ));
 }}}

 with
 {{{
 DBFFlushRecord( psDBF );
 }}}

 as in standalone shapelib. Thanks for reviewing the changes!

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [release planning] 7.2.0

2016-12-04 Thread Markus Neteler 
On Dec 3, 2016 6:00 PM, "Martin Landa"  wrote:
>
> Hi,
>
> it's one week GRASS 7.2.0RC2 has been released. It's time to think
> about 7.2.0 final release. I don't see any blocker [1], if no
> objection

... what about the NULL export in r.out.xyz? Currently it  looks like an
anomaly.

Markus

> I would vote for going ahead and release 7.2.0 in the
> beginning of the next week. Any comments?
>
> Thanks, Ma
>
> [1]
https://trac.osgeo.org/grass/query?status=new=assigned=reopened=blocker=critical=7.2.0=type=priority
>
> --
> 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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r70000 - grass/branches/releasebranch_7_0/lib/python/temporal

2016-12-04 Thread Martin Landa 
Hi Markus,

2016-12-04 23:53 GMT+01:00 Markus Neteler :
>> Author: martinl
>> Date: 2016-12-04 14:51:50 -0800 (Sun, 04 Dec 2016)
>> New Revision: 7
>
> Congrats Martin :)

let's hope that we will have soon r8 and GRASS 8 out ;-) Ma

-- 
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] [GRASS GIS] #3214: t.rast.mapcalc: TypeError: object of type 'NoneType' has no len()

2016-12-04 Thread GRASS GIS 
#3214: t.rast.mapcalc: TypeError: object of type 'NoneType' has no len()
--+-
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.2.0
 Component:  Temporal |Version:  svn-releasebranch72
Resolution:  fixed|   Keywords:  t.rast.mapcalc
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by martinl):

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


Comment:

 In [changeset:"70002" 70002]:
 {{{
 #!CommitTicketReference repository="" revision="70002"
 t.rast.mapcalc: TypeError: object of type 'NoneType' has no len() (fixes
 #3214)
 }}}

--
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] #3214: t.rast.mapcalc: TypeError: object of type 'NoneType' has no len()

2016-12-04 Thread GRASS GIS 
#3214: t.rast.mapcalc: TypeError: object of type 'NoneType' has no len()
--+-
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.0
 Component:  Temporal |Version:  svn-releasebranch72
Resolution:   |   Keywords:  t.rast.mapcalc
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by martinl):

 In [changeset:"70001" 70001]:
 {{{
 #!CommitTicketReference repository="" revision="70001"
 t.rast.mapcalc: TypeError: object of type 'NoneType' has no len() (see
 #3214)
 }}}

--
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-SVN] r70000 - grass/branches/releasebranch_7_0/lib/python/temporal

2016-12-04 Thread Markus Neteler 
On Dec 4, 2016 11:51 PM,  wrote:
>
> Author: martinl
> Date: 2016-12-04 14:51:50 -0800 (Sun, 04 Dec 2016)
> New Revision: 7

Congrats Martin :)

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

Re: [GRASS-dev] maps available in more mapsets in search path

2016-12-04 Thread Martin Landa 
Hi,

2016-11-30 13:17 GMT+01:00 Paulo van Breugel :
>> WARNING: 'cellhd/LT51910262011315KIS00_B7' was found in more mapsets
>> (also found in )
>> WARNING: Using 
>>
>> to important message. The it could be easily controlled by --quiet flag.

done in r69992 (trunk) and backported to relbr72 (r69993). Ma

-- 
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] [GRASS GIS] #3079: shapelib/DBF driver: re-sync to GDAL/OGR needed

2016-12-04 Thread GRASS GIS 
#3079: shapelib/DBF driver: re-sync to GDAL/OGR needed
--+---
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  task | Status:  new
  Priority:  major|  Milestone:  7.4.0
 Component:  Database |Version:  svn-trunk
Resolution:   |   Keywords:  dbf, shapelib
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by rouault):

 I've just resync'ed shapelib CVS from GDAL and make various fixes to
 compile in standalone mode (likely similar to yours). See
 http://lists.maptools.org/pipermail/shapelib/2016-December/000627.html

 Looking at r69890, the following is incorrect:
 {{{
 +#define CPL_IGNORE_RET_VAL_INT(ret_val_int)return
 }}}

 The purpose of this macro is to make the compiler not warn about the fact
 that we don't verify the return value of a function. The correct dummy
 implementation should be :
 {{{
 #define CPL_IGNORE_RET_VAL_INT(x) x
 }}}

 (see https://trac.osgeo.org/gdal/changeset/36680)

--
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] #3215: The eval of g.proj -g fails due to white space in projection name string

2016-12-04 Thread GRASS GIS 
#3215: The eval of g.proj -g fails due to white space in projection name string
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.0
 Component:  LibGIS   |Version:  svn-releasebranch70
Resolution:   |   Keywords:  g.proj
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by neteler):

 Works, thanks for the NRT patch :)

 According to lib/gis/units.c there might be some units like FOOT US and
 more.

--
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] #3215: The eval of g.proj -g fails due to white space in projection name string

2016-12-04 Thread GRASS GIS 
#3215: The eval of g.proj -g fails due to white space in projection name string
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.0
 Component:  LibGIS   |Version:  svn-releasebranch70
Resolution:   |   Keywords:  g.proj
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by martinl):

 Please try out attachment:g-proj-quote.diff, are there any other items
 which could contain spaces?

--
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] #3215: The eval of g.proj -g fails due to white space in projection name string

2016-12-04 Thread GRASS GIS 
#3215: The eval of g.proj -g fails due to white space in projection name string
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.0
 Component:  LibGIS   |Version:  svn-releasebranch70
Resolution:   |   Keywords:  g.proj
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by martinl):

 * Attachment "g-proj-quote.diff" added.


--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #3215: The eval of g.proj -g fails due to white space in projection name string

2016-12-04 Thread GRASS GIS 
#3215: The eval of g.proj -g fails due to white space in projection name string
-+-
 Reporter:  neteler  |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:  7.2.0
Component:  LibGIS   |Version:  svn-releasebranch70
 Keywords:  g.proj   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 Shell parsing of g.proj -g output fails:

 {{{
 # test case:
 GRASS 7.2.0svn (nc_spm_08_grass7):~ > g.proj -g
 name=Lambert Conformal Conic
 proj=lcc
 datum=nad83
 a=6378137.0
 es=0.006694380022900787
 lat_1=36.16
 lat_2=34.34
 lat_0=33.75
 lon_0=-79
 x_0=609601.22
 y_0=0
 no_defs=defined
 epsg=3358
 unit=Meter
 units=Meters
 meters=1


 eval `g.proj -g`
 bash: Conformal: command not found
 }}}

 Quoting of the "name" key of the proj4 struct is needed in
 general/g.proj/output.c but I don't know how to implement that properly.

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] i.segment gives different results in G72 and G73

2016-12-04 Thread Martin Landa 
Running `i.segment` on the same data in G72 and G73 gives different
results. Both commands should use the same method - G72 supports only
'region growing', G73 has this method as default one.

Region:

{{{
north:  -1057730
south:  -1058250
west:   -713860
east:   -712960
nsres:  0.25
ewres:  0.25
rows:   2080
cols:   3600
cells:  7488000
}}}

Command:

{{{
i.segment group=seg output=seg1 threshold=0.01 --o
}}}

G72:

{{{
...
Segmentation converged after 8 iterations
Writing out segment IDs...
i.segment complete. Number of segments created: 4367082
(Sun Dec  4 09:42:19 2016) Command finished (3 min 36 sec)
}}}

G73:

{{{
Segmentation converged after 14 iterations
Assigning region IDs to remaining single-cell regions...
Writing out segment IDs...
i.segment complete. Number of segments created: 4359666
}}}

Segmentation performed in G73 gives slightly different results and
takes longer time to finish.

Thanks for clarification in advance, Martin

-- 
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