[GRASS-dev] gdal-grass plugin or support in gdal for GRASS 7

[Paulo van Breugel]

What is the status / plans / time line for support in gdal, directly or 
through the gdal-grass plugin, for GRASS 7 vector layers? I had seen 
some emails on building gdal with GRASS 7 support with some success, but 
can't find those emails nor any further news.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2298: r.stream.order hack= generates order 1 single pixels

[GRASS GIS]

#2298: r.stream.order hack= generates order 1 single pixels
+---
 Reporter:  hcho|   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  major   |   Milestone:  7.1.0
Component:  Raster  | Version:  svn-trunk
 Keywords:  r.stream.order  |Platform:  Linux
  Cpu:  x86-64  |  
+---

Comment(by hellik):

 Replying to [hcho]:
 > Unfortunately, accumulation map didn't help. I got the same result.
 Maybe, flow direction map is still used for calculating orders? and
 accumulation map is optional for doing something else...?

 what about your region settings? the region and resolution should be
 aligned to the DEM, e.g. g.region -a rast=yourDEM align=yourDEM.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] G_units_to_meters_factor renamed to G_meters_to_units_factor?

[Huidae Cho]

Maybe, it's just me?

G_units_to_meters_factor returns a factor that converts meters to units by
multiplication as opposed to the name and description. For example,
G_units_to_meters_factor(U_KILOMETERS) returns 0.001, not 1000. Multiplying
1 km by 0.001 to get 0.001 meters?

G_database_units_to_meters_factor returns a correct factor that actually
converts to meters by multiplication. If a database unit is foot, it
returns 0.3048, not 3.28, which G_units_to_meters_factor returns.

v.to.db is one of the modules that calls G_units_to_meters_factor, and
multiplies meters by this units-to-meters factor to get a user specified
unit.

The name of this function is confusing and misleading. If I'm not wrong, I
suggest to rename this function to G_meters_to_units_factor.

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

[GRASS-dev] [GRASS GIS] #2300: v.out.ogr: spatialite support not working

[GRASS GIS]

#2300: v.out.ogr: spatialite support not working
---+
 Reporter:  hamish |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  critical   |   Milestone:  6.4.4
Component:  Vector | Version:  svn-trunk
 Keywords:  v.out.ogr, spatialite  |Platform:  Linux
  Cpu:  x86-64 |  
---+
 Hi, as noted on the grass-users ML,
  http://lists.osgeo.org/pipermail/grass-user/2014-May/070328.html

 I'm not able to get Spatialite export working from v.out.ogr. Seen on both
 GRASS 6.x and latest trunk for debian/wheezy.

 Loading the mapset into the qgis grass toolbox on the same machine and
 saving from there works, so I think the system libraries are all ok (gdal
 1.9.0).

 for my test I'm trying the usgsgages vector map from the North Carolina
 dataset. I've tried roadsmajor type=line and census_wake2000 type=area and
 they give the same trouble.

 {{{
 v.out.ogr in=usgsgages dsn=usgsgages.sqlite \
format=SQLite type=point dsco='SPATIALITE=yes'
 }}}


 the error, reported for each point is:

 {{{
 ERROR 1: sqlite3_step() failed:
   usgsgages.GEOMETRY violates Geometry constraint [geom-type or SRID not
 allowed] (19)
 }}}

 In trunk it seems to be happening on line 128 of v.in.ogr's export_lines.c
 (~788 in main.c for devbr6):
 {{{
   OGR_L_CreateFeature(Ogr_layer, Ogr_feature);
 }}}

 api ref:
 http://www.gdal.org/ogr/ogr__api_8h.html#a301d319111285a47fe6cda6e079214f8


 MarkusN pulled up some hints from the gdal ML:
  http://lists.osgeo.org/pipermail/gdal-dev/2013-May/036148.html [[BR]]
  http://lists.osgeo.org/pipermail/gdal-dev/2013-May/036152.html


 where Even wrote:
 > The driver takes responsibility of assigning the SRID automatically from
 > the layer SRS. So the error is likely due to an attempt of inserting a
 > geometry whose type doesn't match the layer geometry type. Spatialite
 > is really strict on that: POLYGON != MULTIPOLYGON, and (perhaps I'm not
 > sure) 2D != 2.5D

 In the gdal-dev thread the solution was to pick the correct one
 of OGR_G_SetPoint() vs. OGR_G_SetPoint_2D(), maybe that helps here?


 the code seems suitably pointy, even if it is embedded in the "lines" part
 of the code, but I wonder if 2D vs 3D definition is causing trouble?
 Converting usgsgages to a 3D points map didn't help.

 {{{
 else if ((type == GV_POINT) ||
  ((type == GV_CENTROID) && (otype & GV_CENTROID))) {

 Ogr_geometry = OGR_G_CreateGeometry(wkbPoint);
 OGR_G_AddPoint(Ogr_geometry, Points->x[0], Points->y[0],
Points->z[0]);
 }
 }}}


 from the partially created sqlite file created by v.out.ogr here's the
 creation log:
 {{{
 $ echo "SELECT * from spatialite_history;" | sqlite3 usgsgages4.sqlite
 1|spatial_ref_sys||table successfully created|2014-05-19
 23:14:31|1|3.7.13|3.0.0-beta
 2|geometry_columns||table successfully created|2014-05-19
 23:14:31|2|3.7.13|3.0.0-beta
 3|spatial_ref_sys||table successfully populated|2014-05-19
 23:14:32|3|3.7.13|3.0.0-beta
 4|usgsgages|GEOMETRY|Geometry [POINT,XY,SRID=40004] successfully
 created|2014-05-19 23:14:33|3.7.13|3.0.0-beta
 5|usgsgages|GEOMETRY|R*Tree Spatial Index successfully created|2014-05-19
 23:14:34|3.7.13|3.0.0-beta
 }}}


 One thing I notice is that SRID 40004 is a custom one added at the
 end of the spatial_ref_sys table, after four other custom ones from
 Italy. I'm not sure if that is relevant or not.


 thanks,
 Hamish

-- 
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] #2298: r.stream.order hack= generates order 1 single pixels

[GRASS GIS]

#2298: r.stream.order hack= generates order 1 single pixels
+---
 Reporter:  hcho|   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  major   |   Milestone:  7.1.0
Component:  Raster  | Version:  svn-trunk
 Keywords:  r.stream.order  |Platform:  Linux
  Cpu:  x86-64  |  
+---

Comment(by hcho):

 Unfortunately, accumulation map didn't help. I got the same result. Maybe,
 flow direction map is still used for calculating orders? and accumulation
 map is optional for doing something else...?

-- 
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] #2298: r.stream.order hack= generates order 1 single pixels

[GRASS GIS]

#2298: r.stream.order hack= generates order 1 single pixels
+---
 Reporter:  hcho|   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  major   |   Milestone:  7.1.0
Component:  Raster  | Version:  svn-trunk
 Keywords:  r.stream.order  |Platform:  Linux
  Cpu:  x86-64  |  
+---

Comment(by hellik):

 Replying to [comment:2 hcho]:
 > I used the following command:
 > {{{
 > r.stream.order stream_rast=streams direction=drain hack=streamshack
 > }}}
 >
 > I didn't try it with the accumulation map, but it shouldn't make a
 difference in theory, I think?

 in all my tests I've used r.stream.order with an accumulation map and the
 results seemed to be ok.

 >
 > IMO, I got this problem because my streams raster has the single pixel
 tributary and the module cannot handle it properly. If I try with the
 accumulation map, it should work correctly because the accumulation map
 covers the entire region. I'll try and let you know.

 yes, please test with an accumulation map and report the results. the
 region should be large enough to cover all accumulation.

 maybe accumulation map should be marked as required for calculation for
 the r.stream.*.

 any helpful additions for the manual are welcome!

 thanks.

-- 
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] r60304 - grass/trunk/raster/r.colors

[Huidae Cho]

Hi Hamish,

I'll check the script.

Thank you!
Huidae


On Mon, May 19, 2014 at 12:59 AM, Hamish  wrote:

> Huidae Cho wrote:
> > I didn't do much backporting till now. I think it's time to read
> > that wiki page. Thanks!
>
> Hi,
>
> handy tip:
>
> In svn/grass-addons/tools/ there are some backporting scripts, the
> relevant one here is svn7merge.
>
> to backport from trunk cd to the top relbr70 dir and after "svn up"
> type "svn7merge REVNUM" where revnum is the number of the commit to
> trunk you want to backport. then svn diff & commit.
> all very quick.
>
> occasionally you have to do "svn propdel svn:mergeinfo ." to get rid of
> some unwanted tags, but as long as you don't do a 'svn commit' from the
> top of the source tree it's harmless.
>
>
> regards
>
> --
> Hamish 
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2250: d.text unsupported from command line

[GRASS GIS]

#2250: d.text unsupported from command line
-+--
  Reporter:  veroandreo  |   Owner:  grass-dev@…  
  Type:  defect  |  Status:  closed   
  Priority:  normal  |   Milestone:  7.0.0
 Component:  wxGUI   | Version:  svn-releasebranch70  
Resolution:  fixed   |Keywords:  d.text   
  Platform:  Linux   | Cpu:  x86-64   
-+--
Changes (by neteler):

  * status:  new => closed
  * version:  unspecified => svn-releasebranch70
  * resolution:  => fixed
  * milestone:  7.1.0 => 7.0.0


-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] G7: r.neighbors changes data type from CELL to DCELL

[Blumentrath, Stefan]

>r60346 implements the following logic:

>For any aggregate, there are 2 factors affecting the output type:

>1. Whether the input map is integer or floating-point.
>2. Whether the weighted or unweighted version of the aggregate is used.

Out of curiosity, could this logic also be applied to r.resamp.stats?
Or did this module already receive a similar solution?

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

Re: [GRASS-dev] [GRASS GIS] #2298: r.stream.order hack= generates order 1 single pixels

[GRASS GIS]

#2298: r.stream.order hack= generates order 1 single pixels
+---
 Reporter:  hcho|   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  major   |   Milestone:  7.1.0
Component:  Raster  | Version:  svn-trunk
 Keywords:  r.stream.order  |Platform:  Linux
  Cpu:  x86-64  |  
+---

Comment(by hcho):

 I used the following command:
 {{{
 r.stream.order stream_rast=streams direction=drain hack=streamshack
 }}}

 I didn't try it with the accumulation map, but it shouldn't make a
 difference in theory, I think?

 IMO, I got this problem because my streams raster has the single pixel
 tributary and the module cannot handle it properly. If I try with the
 accumulation map, it should work correctly because the accumulation map
 covers the entire region. I'll try and let you know.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [cmbarton.wikidot.com] Contact via Wikidot.com

[Michael Barton]

This is a weird error. I built these binaries against OS X 10.7 and am sure 
that they work with Mavericks (10.9). But I only have Mavericks. So I'm copying 
some of the GRASS developers in the hopes that someone else can test. 

Michael

On May 19, 2014, at 1:13 AM, Wikidot.com  wrote:

> 
> Form data:
> 
> First name, last name:
> John Payne
> 
> Organization/Company:
> Wildlife Conservation Society
> 
> Country:
> Mongolia
> 
> Email:
> jcpa...@uw.edu
> 
> Your message (5000 character max):
> Hi Michael, I just tried installing both of the binaries for Grass 7 
> (7.0.beta2 and 7.1) on a new Mac (OS X 10.8.5), and got a message both times 
> saying something like "Wrong operating system" (I since successfully 
> installed 6.4, but I really need some of the new features of 7).  It wasn't 
> clear to me from your release notes whether the binaries only worked for 
> Mavericks.  Thanks,  John
> 
> 
> 

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

Re: [GRASS-dev] [GRASS GIS] #2120: wxgui: encoding errors

[GRASS GIS]

#2120: wxgui: encoding errors
-+--
 Reporter:  mlennert |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:  6.4.4
Component:  wxGUI| Version:  svn-releasebranch64  
 Keywords:  locale encoding  |Platform:  All  
  Cpu:  All  |  
-+--

Comment(by hcho):

 For our records, we still have this bug in 7 trunk.

-- 
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] #2120: wxgui: encoding errors

[GRASS GIS]

#2120: wxgui: encoding errors
-+--
 Reporter:  mlennert |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:  6.4.4
Component:  wxGUI| Version:  svn-releasebranch64  
 Keywords:  locale encoding  |Platform:  All  
  Cpu:  All  |  
-+--
Changes (by hcho):

  * priority:  normal => major
  * platform:  Unspecified => All
  * cpu:  Unspecified => All


Comment:

 There seems to be a real fix other than changing the default encoding.
 Hopefully your explanation is helpful to the wxGUI devs for fixing the bug
 in the correct way.

 Meanwhile the users who are bothered by the issue, including me, can work
 around it by creating usercustomize.py.

 Also I would say this is major or even blocker?, not normal because some
 functionalities are not working at all because of this issue. It's not
 simply an annoyance.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] G7: r.neighbors changes data type from CELL to DCELL

[Martin Landa]

2014-05-19 15:08 GMT+02:00 Glynn Clements :
> r60346 implements the following logic:
>
> For any aggregate, there are 2 factors affecting the output type:
>
> 1. Whether the input map is integer or floating-point.
> 2. Whether the weighted or unweighted version of the aggregate is used.
>
> These combine to create 4 possibilities:
>
> typeinteger   integer   float float
> weightednoyes   noyes
>
> average float float float float
> median  [1]   [1]   float float
> modeinteger   integer   [2]   [2]
> minimum integer   integer   float float
> maximum integer   integer   float float
> range   integer   integer   float float
> stddev  float float float float
> sum integer   float float float
> count   integer   float integer   float
> variancefloat float float float
> diversity   integer   integer   integer   integer
> interspersion   integer   integer   integer   integer
> quart1  [1]   [1]   float float
> quart3  [1]   [1]   float float
> perc90  [1]   [1]   float float
> quantile[1]   [1]   float float
>
> [1] For integer input, quantiles may produce float results from
> interpolating between adjacent values.
>
> [2] Calculating the mode of floating-point data is essentially
> meaningless.
>
> With the current aggregates, there are 5 cases:
>
> 1. Output is always float: average, variance, stddev, quantiles (with
> interpolation).
>
> 2. Output is always integer: diversity, interspersion.
>
> 3. Output is integer if unweighted, float if weighted: count.
>
> 4. Output matches input: minimum, maximum, range, mode (subject to
> note 2 above), quantiles (without interpolation).
>
> 5. Output is integer for integer input and unweighted aggregate,
> otherwise float: sum.

would be nice to put to the manual I guess. Martin

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

Re: [GRASS-dev] [GRASS-SVN] r60310 - in grass/branches/releasebranch_7_0: . raster/r.colors

[Huidae Cho]

Does that mean it's better to commit mergeinfo to avoid duplicate merges by
mistake? I think since this is metadata, it shouldn't affect the source
tree.
On May 19, 2014 8:13 AM, "Glynn Clements"  wrote:

>
> Martin Landa wrote:
>
> > >> please for the next time exclude svn:mergeinfo from backport commit
> > >
> > > Why?
> >
> > it was common practice till now (for those devs how do backporting).
> > It's minor issue for me, I have no strong option (I was used to
> > exclude this svn prop as not useful).
>
> "svn merge" uses that information to avoid applying the same changes
> twice.
>
> --
> Glynn Clements 
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #576: i.pca fails to center data prior to analysis

[GRASS GIS]

#576: i.pca fails to center data prior to analysis
--+-
  Reporter:  nikos|   Owner:  grass-dev@…   
  
  Type:  defect   |  Status:  closed
  
  Priority:  normal   |   Milestone:  6.4.4 
  
 Component:  Raster   | Version:  svn-develbranch6  
  
Resolution:  fixed|Keywords:  i.pca, data centering, prcomp(), R, 
eigenvectors
  Platform:  Unspecified  | Cpu:  Unspecified   
  
--+-
Changes (by nikos):

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


Comment:

 I confirm that this works fine now (GRASS 6.4.4svn (2014) / Revision:
 50937), ie:

 `i.pca input=mod07_b2,mod07_b6,mod07_b7 rescale=0,0 out=pca_mod_b267_2014`

 gives

 {{{
 PC1 778244.03 (-0.4372,-0.7210,-0.5376) [79.20%]
 PC2 192494.58 (-0.8310, 0.0953, 0.5481) [19.59%]
 PC3  11876.45 ( 0.3439,-0.6863, 0.6408) [ 1.21%]
 }}}

 which is essentially identical to R's equivalent action via

 `prcomp(mod07_b267, center=TRUE, scale=FALSE)`

 which in turn gives


 {{{
 Standard deviations:
 [1] 882.1814 438.7420 108.9791

 Rotation:
PC1 PC2PC3
 mod07_b2 0.4372107  0.83099407 -0.3439413
 mod07_b6 0.7210155 -0.09527873  0.6863371
 mod07_b7 0.5375718 -0.54806096 -0.6408165
 }}}

 Just for clarity/completeness, R reports: 1) column-wise and b) the
 "square roots of the eigenvalues", which in this case match GRASS' i.pca
 reported eigenvalues. Some R code:


 {{{
 > ev <- c ( 778244.03, 192494.58, 11876.45) # GRASS-reported eigenvalues
 > sapply(ev, sqrt)
 [1] 882.1814 438.7420 108.9791
 }}}

-- 
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] #2298: r.stream.order hack= generates order 1 single pixels

[GRASS GIS]

#2298: r.stream.order hack= generates order 1 single pixels
+---
 Reporter:  hcho|   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  major   |   Milestone:  7.1.0
Component:  Raster  | Version:  svn-trunk
 Keywords:  r.stream.order  |Platform:  Linux
  Cpu:  x86-64  |  
+---

Comment(by hellik):

 Replying to [ticket:2298 hcho]:
 > Running r.stream.order hack= assigns to single pixel tributaries order 1
 instead of 2. I believe that any tributaries should get assigned order >=
 2 and the main stream gets 1.
 >
 > I'm attaching screenshots of a streams and output hack raster maps. In
 the streams map, the blue and green streams merge and flow into the gray
 one. The gray stream has a small one pixel tributary coming in (center
 lowest pixel) and this pixel becomes an order 1 (yellow) in the hack
 output. I think this pixel should become 2 (green) because it's a
 tributary to the gray main stream. I have a lot these single pixel
 dangling tributaries and simply selecting order 1 doesn't make a nice
 looking single polyline representing the main stream.
 >
 > Or maybe, I'm misunderstanding something in the Hack's order algorithm?

 please provide the command producing this result.

 are you using the optional?

  accumulation=name
 Name of input accumulation raster map

 if not, can you rerun r.stream.order with using accumulation raster map?

 thanks.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] #2031: G_legal_filename() cleanup patch for GRASS 6

[Markus Neteler]

On Mon, May 19, 2014 at 2:25 PM, Hamish  wrote:
> Well, I don't like being the sole gatekeeper,

But your wording is exactly like this.

> Having said that, if people find backporting to 6 is too much of a pain,

I guess I am among those who have done most of the backports in the
past 10-15 years.
It is a pain and it needs to be done. And so we did.

> I note a revert needed in devbr6 where a number of features-in-testing
> (64 bit support, stat() checks in libgis, ...) recently got blown away
> by a mass backwards-sync with relbr64.

Do you refer to r.li? It was completely broken. Adding parallel
support to completely broken tools does not help.

> For sure I play it a bit too conservatively some times, and unadvertised
> devil's advocate others, and it is noted that this slows down releases,
> which frustrates and drops motivation in others too.

Yes. It especially drives away our users.

> fwiw I felt that going into the recent code sprint we were ready for
> 6.4.4rc1, r.li was the last thing to solve. And now we're not.

Well, a VERY few people contributed in the past weeks to 6.4. Please
be fair to attribute the "we" to those who have been investing hours
of their time. Just see the ChangeLog for names.

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

Re: [GRASS-dev] G7: r.neighbors changes data type from CELL to DCELL

[Glynn Clements]

Markus Neteler wrote:

> >> 1) "quantile=0.5" creeps into the history:
> >>
> >> r.info landuse96_28m_mode7x7
> >> ...
> >>  |r.neighbors input="landuse96_28m" output="landuse96_28m_mode7x7" 
> >> met\   |
> >>  |hod="mode" size=3 quantile=0.5
> >>
> >> --> quantile=0.5 should not be there (even if ignored).
> >
> > Remove the line:
> >
> > parm.quantile->answer = "0.5";
> >
> > Optionally change:
> >
> > out->quantile = (parm.quantile->answer && parm.quantile->answers[i])
> > ? atof(parm.quantile->answers[i])
> > : 0;
> >
> > to default to 0.5 rather than 0.
> >
> > But given that we already a distinct "median" method, using
> > "quantile=0.5" is largely redundant.
> 
> ... mmh, not sure what to change.

Fixed in r60345.

> >> 2) The method=mode does not preserve CELL (likewise in r.series).

Note that the same issue applies to minimum, maximum, range, and
(unweighted) sum.

> This is a bit over my programming skills.
> But the broken "mode" operator is a critical issue.
> 
> Help (=svn commits) welcome,

r60346 implements the following logic:

For any aggregate, there are 2 factors affecting the output type:

1. Whether the input map is integer or floating-point.
2. Whether the weighted or unweighted version of the aggregate is used.

These combine to create 4 possibilities:

typeinteger   integer   float float
weightednoyes   noyes
  
average float float float float
median  [1]   [1]   float float
modeinteger   integer   [2]   [2]
minimum integer   integer   float float
maximum integer   integer   float float
range   integer   integer   float float
stddev  float float float float
sum integer   float float float
count   integer   float integer   float
variancefloat float float float
diversity   integer   integer   integer   integer
interspersion   integer   integer   integer   integer
quart1  [1]   [1]   float float
quart3  [1]   [1]   float float
perc90  [1]   [1]   float float
quantile[1]   [1]   float float

[1] For integer input, quantiles may produce float results from
interpolating between adjacent values.

[2] Calculating the mode of floating-point data is essentially
meaningless.

With the current aggregates, there are 5 cases:

1. Output is always float: average, variance, stddev, quantiles (with
interpolation).

2. Output is always integer: diversity, interspersion.

3. Output is integer if unweighted, float if weighted: count.

4. Output matches input: minimum, maximum, range, mode (subject to
note 2 above), quantiles (without interpolation).

5. Output is integer for integer input and unweighted aggregate,
otherwise float: sum.

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

Re: [GRASS-dev] #2031: G_legal_filename() cleanup patch for GRASS 6

[Hamish]

Mortiz wrote:
> How about my proposal from a few weeks ago: Nobody commits to
> grass64release, only to grass6dev, and Hamish is the official
> maintainer of grass64release and decides what can be backported ?
>
> This obviously can only work if Hamish has the time, so that 6.4.4
> is not stalled for lack of manpower.


Well, I don't like being the sole gatekeeper, both for community and
logistical reasons. I am happy and pleased for everyone to backport, as
long as we can all be working from the same ideas about where we are in
a freeze and what our expectations for it are. Which is primarily (and
luckily) a solvable communication problem, and not a structural,
technical, or personality one.

Having said that, if people find backporting to 6 is too much of a pain,
simply leave a ticket open with the next release as the target version
and a request to backport and I'll try to take of it for them, in
$unknown time.

Through bitter experience and brown bags I'm now really strict with
myself about committing anything, no matter how innocent looking, to the
release branch. What has been driving me nuts is spending all these
hours carefully testing and trying to spend a lot of energy on attention
to detail, and to then observe other developers just come through with a
bulldozer and commit stuff haphazard all over the garden I'd just spent
so many hours cleaning up. If all that time ends up in a hole, why
bother?

I note a revert needed in devbr6 where a number of features-in-testing
(64 bit support, stat() checks in libgis, ...) recently got blown away
by a mass backwards-sync with relbr64. I can't tell you how demotivating
it is to have all those hours of work ignored and removed. Now I have to
spend even more hours putting them back by hand, because I doubt any one
else would care enough about devbr6 to fix it. This is not fun, and if
it is not fun I have to remind myself what I'm doing here. So in the
last weeks instead of working or even thinking about that stuff I have
concentrated on what I really do enjoy, the creative outlet aspect of
coding. Having to be the guy who says "no" all the time really eats into
my enjoyment of working in a team, I hate it, it's not a healthy way to
be.

For sure I play it a bit too conservatively some times, and unadvertised
devil's advocate others, and it is noted that this slows down releases,
which frustrates and drops motivation in others too. But I'm ok with not
having to be right all the time about where the right balance is since I
can relax knowing everyone is doing what they consider to be best and
positive, and they are really smart and often right about it. And it is
frustrating to me too for the releases to take so long, especially since
I know some of it is me saying "no" but not having the extra time to do
the review and edits to help solve the issues, many of which are of my
own making.


It's a classic question I don't have an answer to: we can use the time
just before a release as a huge community motivator to get all the last
minute bugs fixed and all the last minute things people wanted to see in
before the next release. But at the same time it's the absolute worst
time to make changes which can't have time for testing. So how to
harness all that energy without breaking anything by accident?

My personal strategy has been to divert non-critical things in to
release+1, then soon after release go through the devbr and backport it
all. Yes it slips a release which may be many months apart, but I treat
it like AGU meetings: you can't be everywhere and do everything at once,
so it's ok, do what you can and enjoy it guilt free.

Then there are things like the parallelized shell scripts in devbr6
which are wonderful and seem to be working fine, but I've not backported
them because I don't know the answer to allow SIGINT to also kill the
subprocesses. From the command line with `top` and maybe gkrellm running
as a cpu/process monitor it's pretty obvious they are still going. But
from my testing of the msys/bash background& a series of jobs + `wait`
strategy with the wxGUI on MS Windows (it works!) that if you forget to
change the computational region away from 1 meter, as is easy to do
there, the r.univar job is going to take hours. So after a while on 1%
done you press the "stop" button in the module's gui window but the
children keep going in the background. Probably most Windows users
wouldn't notice that, only that the machine got slow. So I don't have
an answer to that problem and thus the new code remains waiting in
devbr6. (I'd note parallelized python scripts in grass7, which by
structural necessity of python only support multi-processes not
multi-thread, have the same exact problem..)



Martin:
> from my personal experience I would say that than we will probably
> never release any new GRASS 6 version. ;-)

fwiw I felt that going into the recent code sprint we were ready for
6.4.4rc1, r.li was the last thing to solve. And now we're not. If we're
ever goi

Re: [GRASS-dev] [GRASS GIS] #1856: wxGUI with LANG=pl_PL.utf8 throws "'ascii' codec can't decode byte"

[Glynn Clements]

Huidae Cho wrote:

> Can you be more specific?

See my response to #2120:

https://trac.osgeo.org/grass/ticket/2120#comment:10

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

Re: [GRASS-dev] [GRASS-SVN] r60310 - in grass/branches/releasebranch_7_0: . raster/r.colors

[Glynn Clements]

Martin Landa wrote:

> >> please for the next time exclude svn:mergeinfo from backport commit
> >
> > Why?
> 
> it was common practice till now (for those devs how do backporting).
> It's minor issue for me, I have no strong option (I was used to
> exclude this svn prop as not useful).

"svn merge" uses that information to avoid applying the same changes
twice.

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

Re: [GRASS-dev] MBTiles format export tool (halfway)

[Hamish]

Hamish wrote:
> If it is useful to anyone I've just written an addon module which will
> let you export a grass raster map as a TMS tileset and uDig mapurl
> file ready to be copied into Geopaparazzi, which will then convert it
> to the MBTiles sqlite web tile database format. MBTiles is used for
> Tilemill and other web tile softwares to avoid 2^n number of tiny
> tiles clogging up your filesystem, handle deduplication, and other
> nice things. GDAL support (read-only) since 1.10.
> 
> Relying on Geopaparazzi on Android to do the final conversion then
> copying back the results is a bit awkward/slow, so I'd enjoy to see
> the addon module create the MBTiles sqlite db directly. It looks
> pretty straight forward, but sadly my SQL foo is lacking.
> 
> ( https://github.com/mapbox/mbtiles-spec/blob/master/1.2/spec.md )

[correction 1.2 is unreleased, use spec v1.1]

> once that is working the idea is to buy the co-author a beer and
> rename the module to r.out.mbtiles.

ok, I was able to add a flag to (experimentally) export MBTiles
databases directly as long as sqlite3 is installed. Both gdalinfo 1.10
and qgis2 seem to be happy with it. It could still use improvement by
replacing the image blobs with an index number view and having another
table for storing the unique images. That way all ocean/wasteland tiles
only need to be stored once in the database and the file can be quite a
bit smaller. For well-cropped aerial imagery and satellite data I guess
we wouldn't have much repeated data, but for categorical CELL maps it
could help things a lot.

If anyone wants to help with the fancy SQL views and ID lookup table I
can provide as an example a sqlite db of the North Carolina soilsID
raster converted by Geopaparazzi's TMS import background job. I'm
afraid that much really is beyond my SQL.


regards,

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

Re: [GRASS-dev] [GRASS-PSC] [GRASS GIS] #2031: G_legal_filename() cleanup patch for GRASS 6

[Martin Landa]

Hi,

2014-05-19 9:50 GMT+02:00 Moritz Lennert :

[...]

> How about my proposal from a few weeks ago: Nobody commits to
> grass64release, only to grass6dev, and Hamish is the official maintainer of
> grass64release and decides what can be backported ?
>
> This obviously can only work if Hamish has the time, so that 6.4.4 is not
> stalled for lack of manpower.

from my personal experience I would say that than we will probably
never release any new GRASS 6 version. ;-)

Martin

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

Re: [GRASS-dev] [GRASS GIS] #2031: G_legal_filename() cleanup patch for GRASS 6

[Moritz Lennert]

On 19/05/14 05:30, GRASS GIS wrote:


  And again, even if this were a valid candidate for G6, backporting stuff
  directly to 6.4 without going into devbr6 for at least light/any testing
  first, especially anything which touches core libgis, especially a time
  right before RC release, is incredibly risky for anything which is not a
  critical bug fix, and not an environment I can justify contributing my
  time to.


  sorry if I'm grumpy, but I'm at the end of my rope about this.

  regards,
  Hamish


How about my proposal from a few weeks ago: Nobody commits to 
grass64release, only to grass6dev, and Hamish is the official maintainer 
of grass64release and decides what can be backported ?


This obviously can only work if Hamish has the time, so that 6.4.4 is 
not stalled for lack of manpower.


Moritz

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

Re: [GRASS-dev] GRASS created geotiff do not properly load into PostGIS (raster2pgsql)

[Blumentrath, Stefan]

Hi again,

Just to leave a note in case others encounter the same problem and read this 
thread:

1)  It seems the problem occurs only with rasters in double or floating 
point precision (a test with integer (Int16) rasters worked fine). However, 
other integer types may cause problems too: see 
http://trac.osgeo.org/gdal/browser/trunk/gdal/gcore/gdalrasterband.cpp, where 
the CPLIsNan function handles NaN explicitly for some data types (see also: 
http://osgeo-org.1560.x6.nabble.com/gdal-dev-GDALSetRasterNoDataValue-and-NaN-td4996633.html).

2)  GDAL handles NaN without problems, at least on Linux and Windows (I 
have no Mac for testing).

In any case, I reopened a relevant ticket on this issue which I found in 
PostGIS trac: http://trac.osgeo.org/postgis/ticket/828

Cheers
Stefan

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