Re: [GRASS-dev] [GRASS GIS] #3043: Change default color table

[GRASS GIS]

#3043: Change default color table
--+---
  Reporter:  wenzeslaus   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  blocker  |  Milestone:  7.2.0
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  r.colors, d.rast, rainbow
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by wenzeslaus):

 Replying to [comment:5 mlennert]:
 > I think that if we provide a default color table (here ''map'') of which
 we say that it is good (better than rainbow), we should make our criteria
 more explicit.

 Article on Gnuplotting (citing Moreland, 2009) lists these features for a
 default color table and I'm adding my notes in the nested lists:

 * The map yields images that are aesthetically pleasing
  * Although some people consider `rainbow` pretty or are simply used to
 it, my claim is that it is objectively worse because things which contain
 less colors or less styles in general is considered a better graphical
 design.
  * `grey` is OK but black and white is a bit boring and then there is the
 "show color feature" thing Markus mentioned in comment:2
  * In cartography black and white have usually special purpose (like text
 and its halo), so this excludes color tables which start or end with one
 of them.
  * The black-body radiation color tables which include or are similar to
 color tables like `sepia` in GRASS GIS, or `hot`, `inferno`, `plasma`, and
 `magma` in Matplotlib are often recommend, but I haven't seen them used
 that much. There might a actually a aesthetic reason for it. The Better
 Default Colormap for Matplotlib video suggests that the reason is that
 these don't have a green color in them. However, in general, I think they
 are nice. Gnuplot default is actually similar to `inferno`, `plasma`, or
 `magma`.
  * The cubehelix color tables are often regarded as "rotten melon",
 although some variations look nice and some are very much like `viridis`,
 `plasma`, and others. See seaborn and palettable for examples.
  * `inferno`, `plasma`, `magma`, and `viridis` were considered for
 Matplotlib and `viridis` was selected because it was the one most people
 liked. As mentioned above, it was likely visual because unlike others, it
 had green in (the measurable/theoretical features were similar with the
 other three).
 * The map has a maximal perceptual resolution
  * In comment:9 showed that our `rainbow` doesn't always have it. Some
 revised rainbow-like color tables may have it quite high.
 * Interference with the shading of 3D surfaces is minimal
  * This rules out the `grey` and also the ones which go from very low
 brightness (black) to very high brightness (white).
 * The map is not sensitive to vision deficiencies
  * Although there is many different color blindness variations and
 sometimes the percentages of affected people are relatively low, this is
 often a requirement and my guess is that, similarly to web design,
 everybody at the end benefits.
  * This rules out anything which contains red and green at the same time
 like `rainbow` or `gyr`.
  * This also likely rules out anything which does not look good when
 converted to gray scale as the intensity is probably the last thing which
 is preserved. (I would need to do more here.) However, there is the
 benefit of printing in gray scale without much loss.
 * The order of the colors should be intuitively the same for all people
  * I guess the usual issue here is who can name colors of rainbow in the
 right order? Additionally, does the color table include all colors or does
 it skip some?
  * This likely rules out anything with a lot of colors, so probably also
 the rainbow-like color tables which fix some of the classic rainbow color
 table problems.
  * Simpler color tables with one or two colors like `summer` from
 Matplotlib doesn't require any knowledge of order.
  * As the order of colors is not clear even few colors may create
 confusion. Exception might black-body radiation color tables where the
 order might be intuitive (but that might be just result of the brightness
 as discussed in the following point).
  * I think this is also where the diverging color tables like
 `differences` or `curvature` fail here as defaults because the choice of
 order of individual colors is arbitrary and the often pronounced middle
 would be unsuitable. However, !ParaView uses diverging blue-white-red as a
 default and there are is some literature which suggests them.
  * Brightness seems to be only generally accepted natural ordering. This
 is in favor of `grey` and all color tables which look like grey when
 printing in black and white. This is the case for cubehelix color tables
 and `inferno`, `plasma`, `magma`, and `viridis`.
 * The perceptual interpolation matches the underlying scalars of the map
  * (I would need to do more 

Re: [GRASS-dev] [GRASS GIS] #3017: support for background option for grid labels in d.grid

[GRASS GIS]

#3017: support for background option for grid labels in d.grid
--+---
  Reporter:  veroandreo   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.3.0
 Component:  Display  |Version:  unspecified
Resolution:   |   Keywords:  d.grid, gsoc2016, cartography
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by annakrat):

 Replying to [comment:8 veroandreo]:
 > Hi, I'm happy to have background option in d.grid :)
 >
 > I did a quick test and I attach an example below. I noted that when
 choosing white background for grid labels, I loose part of the map in the
 east (See no-transparency in fig 1 vs transparency in fig 2). So,
 background of labels seems to be a continuous white strip for Y
 coordinate, while it's fine for X coordinate.

 I can confirm this, the size of the background rectangle still needs
 fixing, the problem showed up only in latlon for me.
 >
 > On the other hand, grid lines overlap the white background of labels,
 while IMHO, label should always be in front.

 Yes, the horizontal labels are fine, just the vertical ones are below the
 grid lines.
 >
 > I personally don't like the border tickmarks of d.grid but when
 disabling them, labels remain aligned as if there were border tickmarks
 (last fig). Maybe they could be aligned more close to the border (if not
 against it) as in ps.map.
 >
 > And, would that be possible to also change font of labels?? :)
 >
 You can do that from GUI settings - you set display font for all d.*
 commands.

--
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] #3017: support for background option for grid labels in d.grid

[GRASS GIS]

#3017: support for background option for grid labels in d.grid
--+---
  Reporter:  veroandreo   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.3.0
 Component:  Display  |Version:  unspecified
Resolution:   |   Keywords:  d.grid, gsoc2016, cartography
   CPU:  Unspecified  |   Platform:  Unspecified
--+---
Changes (by veroandreo):

 * Attachment "d_grid_examples.png" added.

 d.grid testing transparency vs no-transparency and labels positioning

--
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] #3017: support for background option for grid labels in d.grid

[GRASS GIS]

#3017: support for background option for grid labels in d.grid
--+---
  Reporter:  veroandreo   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.3.0
 Component:  Display  |Version:  unspecified
Resolution:   |   Keywords:  d.grid, gsoc2016, cartography
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by veroandreo):

 Hi, I'm happy to have background option in d.grid :)

 I did a quick test and I attach an example below. I noted that when
 choosing white background for grid labels, I loose part of the map in the
 east (See no-transparency in fig 1 vs transparency in fig 2). So,
 background of labels seems to be a continuous white strip for Y
 coordinate, while it's fine for X coordinate.

 On the other hand, grid lines overlap the white background of labels,
 while IMHO, label should always be in front.

 I personally don't like the border tickmarks of d.grid but when disabling
 them, labels remain aligned as if there were border tickmarks (last fig).
 Maybe they could be aligned more close to the border (if not against it)
 as in ps.map.

 And, would that be possible to also change font of labels?? :)

--
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] #3052: Watts to MegaJoules/Day conversion issue

[GRASS GIS]

#3052: Watts to MegaJoules/Day conversion issue
-+-
 Reporter:  cholmes  |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:  7.0.5
Component:  Default  |Version:  unspecified
 Keywords:   |CPU:  Unspecified
 Platform:  All  |
-+-
 I think I may have found an error in a few files from the grass-ci repo.

 A few files:

 https://github.com/GRASS-GIS/grass-
 
ci/blob/f1a15d967611006e920b8dc2f191391e44392019/imagery/i.evapo.mh/mh_eto.c#L15
 https://github.com/GRASS-GIS/grass-
 
ci/blob/f1a15d967611006e920b8dc2f191391e44392019/imagery/i.evapo.mh/mh_original.c#L14
 https://github.com/GRASS-GIS/grass-
 
ci/blob/f1a15d967611006e920b8dc2f191391e44392019/imagery/i.evapo.mh/mh_samani.c#L14

 contain a line like:


 {{{
 ra = ra * (84600.0 * 1000.0);   /*convert W -> MJ/d */
 }}}


 I'm guessing the magic constant 84600 is intended to be the number of
 seconds in a day, which is actually 86400. Also, Watts * Seconds gives
 Joules. If you intend to get MegaJoules, you must divide by 1000, not
 multiply (but maybe the comment is just wrong, and you wanted
 milliJoules?).

--
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] #3043: Change default color table

[GRASS GIS]

#3043: Change default color table
--+---
  Reporter:  wenzeslaus   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  blocker  |  Milestone:  7.2.0
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  r.colors, d.rast, rainbow
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by wenzeslaus):

 Replying to [comment:5 mlennert]:
 > Generally, it seems to me that rainbow and bcyr provide greater
 contrasts.

 This might be true is some cases, or at least it seems this way. However,
 the opposite is true in the example I just posted which is a slightly
 titled plane with waves on it created using:

 {{{
 g.region cols=500 rows=300 n=-300 s=-600 w=0 e=500
 r.mapcalc "x = col() / 10 + 2 * cos(col() * 100)" && r.colors map=x
 color=grey
 }}}

 The waves are visible with `viridis` (first) and `gray` (last) but
 `rainbow` (second) shows them a lot in the middle while not at all in the
 green region. `bcyr` (third) shows waves on the sides but not so much in
 the middle, they seem to be completely lost in light blue and yellow
 regions.

 [[Image(col_plus_cos_col_viridis_rainbow_bcyr_gray_small.png)]]

 See more in work by [http://peterkovesi.com/projects/colourmaps/ Peter
 Kovesi] (Colour Maps with Uniform Perceptual Contrast).

 In some other cases `rainbow` overly emphasizes features or even creates
 (suggests) features which are not there. The example above doesn't show
 this except for the region between light and dark blue where the lines
 (waves) are much more prominent.

 It must be noted that a lot of color tables, even some rainbow-like ones
 when they are ''perceptually uniform'', can perform good in this test.

--
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] #3043: Change default color table

[GRASS GIS]

#3043: Change default color table
--+---
  Reporter:  wenzeslaus   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  blocker  |  Milestone:  7.2.0
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  r.colors, d.rast, rainbow
   CPU:  Unspecified  |   Platform:  Unspecified
--+---
Changes (by wenzeslaus):

 * Attachment "col_plus_cos_col_viridis_rainbow_bcyr_gray_small.png" added.

 Wave tilted surface represented with viridis, rainbow, bcyr and gray color
 tables

--
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] #3017: support for background option for grid labels in d.grid

[GRASS GIS]

#3017: support for background option for grid labels in d.grid
--+---
  Reporter:  veroandreo   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.3.0
 Component:  Display  |Version:  unspecified
Resolution:   |   Keywords:  d.grid, gsoc2016, cartography
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by annakrat):

 Replying to [comment:5 lazaa]:

 > I uploaded new patch with original whitespaces/tabs.
 >
 > I looked how it is done in d.text module. Now is the margin of the text
 box calculated from width and height of the text inside text box.
 >
 > Another problem is that if user uses flag -g or -w. The geographical
 grid isn't horizontal/vertical so the labels are a bit rotated. But I
 couldn't find any way how to rotate the text box for filling background. I
 attached an image.

 Thank you, I committed it. I don't think the rotation is a huge problem
 here for most cases. You could look at d.labels, it can do the rotation of
 the background. But I don't think you should focus on this now.

 More testing welcome.

--
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] #3017: support for background option for grid labels in d.grid

[GRASS GIS]

#3017: support for background option for grid labels in d.grid
--+---
  Reporter:  veroandreo   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.3.0
 Component:  Display  |Version:  unspecified
Resolution:   |   Keywords:  d.grid, gsoc2016, cartography
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by annakrat):

 In [changeset:"68542" 68542]:
 {{{
 #!CommitTicketReference repository="" revision="68542"
 d.grid: add bgcolor, see #3017, author Adam Laza
 }}}

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] GSoC 2016 - PyQt

[Ondřej Pešek]

Thanks, I'm going on that.


Bez
virů. www.avast.com

<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2016-05-30 9:14 GMT+02:00 Luca Delucchi :

> On 27 May 2016 at 23:27, Ondřej Pešek  wrote:
> >
> > Hi,
> >
>
> Hi Ondrej,
>
> > here is report of what I have done during this week in my GRASS
> >
> > GSoC Project:
> >
> > WEEK 1
> >
> > Designed basic GUI shuck. From XML is now automatically generated GUI
> with name, keywords and basic layouts (description, tabs, buttons).
> >
> > Code now works as a script with parameter - for example r.buffer (python
> forms.py r.buffer).
> >
> > Take a look at screenshots.
> >
>
> These look really a good starting point, please could you extend the
> README file adding how to test the code, for example dependencies and
> how to compile/use
>
> >
> > Best regards,
> > Ondrej
> >
>
>
> --
> ciao
> Luca
>
> www.lucadelu.org
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3017: support for background option for grid labels in d.grid

[GRASS GIS]

#3017: support for background option for grid labels in d.grid
--+---
  Reporter:  veroandreo   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.3.0
 Component:  Display  |Version:  unspecified
Resolution:   |   Keywords:  d.grid, gsoc2016, cartography
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by lazaa):

 Replying to [comment:4 annakrat]:
 > Replying to [comment:3 lazaa]:
 > > Replying to [comment:2 annakrat]:
 > > > Thanks for the patch, but I am getting weird results (see
 attachment). It's possible I might have done something wrong when applying
 the patch, because I needed to get rid of the whitespace changes. Could
 you please check this?
 > > >
 > > > Also `bg_color` should be probably changed to `bgcolor` to be
 compatible with all other modules having this option.
 > > >
 > > > Ideally please upload a new patch without the whitespace changes.
 > >
 > > OK, I will change it to {{{bgcolor}}}. I think the problem is not in
 whitespaces. The size of label background depends on the font size. I
 tested it on several font sizes and I got good results but obviously it
 doesn't work in general.
 >
 > It seems to change with zoom level, so I think you have to somehow
 convert between the pixel and geographic coordinates.


 I uploaded new patch with original whitespaces/tabs.

 I looked how it is done in d.text module. Now is the margin of the text
 box calculated from width and height of the text inside text box.

 Another problem is that if user uses flag -g or -w. The geographical grid
 isn't horizontal/vertical so the labels are a bit rotated. But I couldn't
 find any way how to rotate the text box for filling background. I attached
 an image.

--
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] #3017: support for background option for grid labels in d.grid

[GRASS GIS]

#3017: support for background option for grid labels in d.grid
--+---
  Reporter:  veroandreo   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.3.0
 Component:  Display  |Version:  unspecified
Resolution:   |   Keywords:  d.grid, gsoc2016, cartography
   CPU:  Unspecified  |   Platform:  Unspecified
--+---
Changes (by lazaa):

 * Attachment "map.png" added.

 geographical grid and non-rotated labels

--
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] #3017: support for background option for grid labels in d.grid

[GRASS GIS]

#3017: support for background option for grid labels in d.grid
--+---
  Reporter:  veroandreo   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.3.0
 Component:  Display  |Version:  unspecified
Resolution:   |   Keywords:  d.grid, gsoc2016, cartography
   CPU:  Unspecified  |   Platform:  Unspecified
--+---
Changes (by lazaa):

 * Attachment "d.grid2.diff" added.

 Updated patch with original whitespaces/tabs. Text box margin is
 calculated as a percentage of text width/height.

--
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] #3043: Change default color table

[GRASS GIS]

#3043: Change default color table
--+---
  Reporter:  wenzeslaus   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  blocker  |  Milestone:  7.2.0
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  r.colors, d.rast, rainbow
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by wenzeslaus):

 Replying to [comment:5 mlennert]:
 > Replying to [comment:4 wenzeslaus]:
 > > See the attachments to see how it behaves including gray scale print
 and simulated color blindness (I can share also the full resolution
 images).
 >
 > Without some kind of legend, it is difficult to understand what is what
 in your color_tables_overview...

 The legend is in the full size image (shared personally). The layout of
 images is the following. First 2x2 images are:

 || viridis || rainbow ||
 || grey || bcyr ||

 Next 2x2 to the right are the same with less RGB colors used for
 representation (as it happens in videos or GIFs). The next 2x2 to the
 right are the 4 original images in gray scale (as if printed on paper; it
 also shows how one perceives intensity of that image).

 || normal (2x2) || reduced colors (2x2) || gray scale (2x2) ||

 Next two rows are again the original 4 images in 2x2 layout with 3 color
 blindness variations  simulated by !ImageMagic.

 || protanope (2x2) || deuteranope (2x2) || tritanope (2x2) ||

 The same is repeated also for random surface created by r.surf.fractal and
 landclass96 categorical raster from the NC dataset (the first row is NC
 elevation raster).

 || elevation (4x6) ||
 || fractal (4x6) ||
 || landclass (4x6) ||

--
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] #3043: Change default color table

[GRASS GIS]

#3043: Change default color table
--+---
  Reporter:  wenzeslaus   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  blocker  |  Milestone:  7.2.0
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  r.colors, d.rast, rainbow
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by wenzeslaus):

 A search of the Internet yields many websites and blog posts dealing with
 rainbow color table and the message seems to be quite clear: avoid using
 it. See for example [https://eagereyes.org/basics/rainbow-color-map How
 The Rainbow Color Map Misleads].

 The issue with having it as a default is that it is a sign of an approval.
 Sometimes people even consider rainbow color table appealing which makes
 it even more dangerous default because "it is default selected by the
 smart software creators and I like it, so let's not change it."

--
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] #3043: Change default color table

[GRASS GIS]

#3043: Change default color table
--+---
  Reporter:  wenzeslaus   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  blocker  |  Milestone:  7.2.0
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  r.colors, d.rast, rainbow
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by wenzeslaus):

 Published papers about why rainbow color table is bad (incomplete list):

 * D. Borland and R. M. Taylor Ii, "Rainbow Color Map (Still) Considered
 Harmful," in IEEE Computer Graphics and Applications, vol. 27, no. 2, pp.
 14-17, March-April 2007. doi: 10.1109/MCG.2007.323435
 * Stauffer, Reto, et al. "Somewhere over the rainbow: how to make
 effective use of colors in meteorological visualizations." Bulletin of the
 American Meteorological Society 96.2 (2015): 203-216.
 * Rougier, Nicolas P., Michael Droettboom, and Philip E. Bourne. "Ten
 simple rules for better figures." PLOS Comput Biol 10.9 (2014): e1003833.

--
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] #3017: support for background option for grid labels in d.grid

[GRASS GIS]

#3017: support for background option for grid labels in d.grid
--+---
  Reporter:  veroandreo   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.3.0
 Component:  Display  |Version:  unspecified
Resolution:   |   Keywords:  d.grid, gsoc2016, cartography
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by annakrat):

 Replying to [comment:3 lazaa]:
 > Replying to [comment:2 annakrat]:
 > > Thanks for the patch, but I am getting weird results (see attachment).
 It's possible I might have done something wrong when applying the patch,
 because I needed to get rid of the whitespace changes. Could you please
 check this?
 > >
 > > Also `bg_color` should be probably changed to `bgcolor` to be
 compatible with all other modules having this option.
 > >
 > > Ideally please upload a new patch without the whitespace changes.
 >
 > OK, I will change it to {{{bgcolor}}}. I think the problem is not in
 whitespaces. The size of label background depends on the font size. I
 tested it on several font sizes and I got good results but obviously it
 doesn't work in general.

 It seems to change with zoom level, so I think you have to somehow convert
 between the pixel and geographic coordinates.

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] GRASS GSoC 2016 Additional Image Segmentation Algorithms for i.segment weekly report 0 and 1

[Yang, Bo (yangb2)]

Dear All,



Please see my weekly report 0 and 1 for GRASS GSoC 2016 Additional Image 
Segmentation Algorithms:

[0] 
https://trac.osgeo.org/grass/wiki/GSoC/2016/Additional_segmentation_algorithms/weekly_report



Thanks,

Bo Yang


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

Re: [GRASS-dev] [GRASS GIS] #3017: support for background option for grid labels in d.grid

[GRASS GIS]

#3017: support for background option for grid labels in d.grid
--+---
  Reporter:  veroandreo   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.3.0
 Component:  Display  |Version:  unspecified
Resolution:   |   Keywords:  d.grid, gsoc2016, cartography
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by lazaa):

 Replying to [comment:2 annakrat]:
 > Thanks for the patch, but I am getting weird results (see attachment).
 It's possible I might have done something wrong when applying the patch,
 because I needed to get rid of the whitespace changes. Could you please
 check this?
 >
 > Also `bg_color` should be probably changed to `bgcolor` to be compatible
 with all other modules having this option.
 >
 > Ideally please upload a new patch without the whitespace changes.

 OK, I will change it to {{{bgcolor}}}. I think the problem is not in
 whitespaces. The size of label background depends on the font size. I
 tested it on several font sizes and I got good results but obviously it
 doesn't work in general.

--
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] #3016: Add option to set scalebar length

[GRASS GIS]

#3016: Add option to set scalebar length
--+---
  Reporter:  annakrat |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.3.0
 Component:  Display  |Version:  unspecified
Resolution:   |   Keywords:  d.barscale, gsoc2016, cartography
   CPU:  Unspecified  |   Platform:  All
--+---

Comment (by annakrat):

 Replying to [comment:4 mlennert]:
 > All of Adam's patches concerning d.barscale give a lot of fails when
 trying to apply them to trunk. Maybe this is linked to the recent running
 of the indent script on the version in trunk ?

 I think so. He used indent script on his working copy, so he has a lot of
 whitespace changes. So I decided to commit the whitespace changes
 separately. Adam should upload the new patches just with the real code
 changes. I am not sure what's the best way to get rid of whitespace
 changes in a patch for now, probably apply it to older version of the file
 and create a new diff without whitespace or use meld.

--
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] #3016: Add option to set scalebar length

[GRASS GIS]

#3016: Add option to set scalebar length
--+---
  Reporter:  annakrat |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.3.0
 Component:  Display  |Version:  unspecified
Resolution:   |   Keywords:  d.barscale, gsoc2016, cartography
   CPU:  Unspecified  |   Platform:  All
--+---

Comment (by mlennert):

 All of Adam's patches concerning d.barscale give a lot of fails when
 trying to apply them to trunk. Maybe this is linked to the recent running
 of the indent script on the version in 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] #3046: Cannot set display font

[GRASS GIS]

#3046: Cannot set display font
--+--
  Reporter:  cmbarton |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  7.0.5
 Component:  wxGUI|Version:  7.0.4
Resolution:   |   Keywords:  display font
   CPU:  Unspecified  |   Platform:  MacOSX
--+--

Comment (by annakrat):

 In [changeset:"68535" 68535]:
 {{{
 #!CommitTicketReference repository="" revision="68535"
 wxGUI: use custom font dialog for output font on Mac, see #3046
 }}}

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [SoC]Week-1 WebGrass

[Rashad Kanavath]

On Mon, May 30, 2016 at 2:19 PM, Luca Delucchi  wrote:

> On 30 May 2016 at 14:15, Rashad Kanavath 
> wrote:
> > No.
> >
>
> ok,
>
> > I need to add it. Mayank will be working on other task this week. He is
> > right now on building layer manager
> >
>
> let us know when it will be ready to test, thanks
>

Sure. Will do.

>
> --
> ciao
> Luca
>
> www.lucadelu.org
>



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

Re: [GRASS-dev] [SoC]Week-1 WebGrass

[Rashad Kanavath]

No.

I need to add it. Mayank will be working on other task this week. He is
right now on building layer manager

On Mon, May 30, 2016 at 2:09 PM, Luca Delucchi  wrote:

> On 30 May 2016 at 14:06, Rashad Kanavath 
> wrote:
> >
> >
> > I think the cmake variable GRASS_DATA_DIR can be set to $HOME/grassdata.
> and
> > during
> > configure check if it is a valid dataset.
> >
>
> Is GRASS_DATA_DIR already there?
>
> >
> > using sample data is not for everyone. This is a cmake option which is
> OFF
> > by default.
>
> ok
>
> --
> ciao
> Luca
>
> www.lucadelu.org
>



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

Re: [GRASS-dev] [SoC]Week-1 WebGrass

[Luca Delucchi]

On 30 May 2016 at 14:06, Rashad Kanavath  wrote:
>
>
> I think the cmake variable GRASS_DATA_DIR can be set to $HOME/grassdata. and
> during
> configure check if it is a valid dataset.
>

Is GRASS_DATA_DIR already there?

>
> using sample data is not for everyone. This is a cmake option which is OFF
> by default.

ok

-- 
ciao
Luca

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

Re: [GRASS-dev] [SoC]Week-1 WebGrass

[Rashad Kanavath]

On Mon, May 30, 2016 at 1:56 PM, Luca Delucchi  wrote:

> On 30 May 2016 at 13:36, Rashad Kanavath 
> wrote:
> > Hello Luca,
> >
>
> Hi,
>
> > Thanks for testing.
> >
> > On Mon, May 30, 2016 at 12:14 PM, Luca Delucchi 
> > wrote:
> >>
> >> On 30 May 2016 at 11:09, Mayank Agrawal 
> >> wrote:
> >> >
> >> > Readme-
> >> >
> >> > in the webgrass folder https://github.com/rashadkm/webgrass
> >> >
> >> > mkdir build
> >> > cd build
> >> > cmake ..
> >> > make
> >> > sudo ./wgrass.wt --http-address=0.0.0.0 --http-port=8080 --docroot ../
> >> >
> >>
> >> I read it already, but it was not enough
> >>
> >> >
> >> > These are the dependencies which will be required beforehand. Install
> >> > them one by one.
> >> >
> >> > libwt-dev - C++ library and application server for web applications
> >> > [development]
> >> > libwtdbo-dev - Wt::Dbo ORM library for Wt [development]
> >> > libwtdbofirebird-dev - Firebird backend for Wt::Dbo [development]
> >> > libwtdbomysql-dev - MySQL/MariaDB backend for Wt::Dbo [development]
> >> > libwtdbopostgres-dev - PostgreSQL backend for Wt::Dbo [development]
> >> > libwtdbosqlite-dev - sqlite3 backend for Wt::Dbo [development]
> >> > libwtext-dev - additional widgets for Wt, based on ExtJS 2.0.x
> >> > [development]
> >> > libwtfcgi-dev - FastCGI connector library for Wt [development]
> >> > libwthttp-dev - HTTP(S) connector library for Wt [development]
> >> > libwttest-dev - test connector library for Wt [development]
> >> > libpugixml-dev
> >> >
> >>
> >> please add this in the readme file
> >>
> >> >
> >> > After this, do let me know with the error.
> >> >
> >>
> >>
> >> no error, now I'm able to run it but I cannot modify the grassdata
> >> directory, is it normal?
> >
> >
> > Yes and No!
> >
> > Yes it is expected that there is not user specific location-mapset upload
> > ready now.
> >
>
> you could set by default $HOME/grassdata (it is quite common to have a
> grassdata in our own $HOME)
>

I think the cmake variable GRASS_DATA_DIR can be set to $HOME/grassdata.
and during
configure check if it is a valid dataset.




> >
> > I will push a cmake configuration that downloads sample grass7 dataset.
> So
> > you can test it easily.
> >
>
> no please, no download sample dataset, should be better to set our
> grassdata in a cmake variable
>

using sample data is not for everyone. This is a cmake option which is OFF
by default.



>
>
> --
> ciao
> Luca
>
> www.lucadelu.org
>



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

Re: [GRASS-dev] [SoC]Week-1 WebGrass

[Luca Delucchi]

On 30 May 2016 at 13:36, Rashad Kanavath  wrote:
> Hello Luca,
>

Hi,

> Thanks for testing.
>
> On Mon, May 30, 2016 at 12:14 PM, Luca Delucchi 
> wrote:
>>
>> On 30 May 2016 at 11:09, Mayank Agrawal 
>> wrote:
>> >
>> > Readme-
>> >
>> > in the webgrass folder https://github.com/rashadkm/webgrass
>> >
>> > mkdir build
>> > cd build
>> > cmake ..
>> > make
>> > sudo ./wgrass.wt --http-address=0.0.0.0 --http-port=8080 --docroot ../
>> >
>>
>> I read it already, but it was not enough
>>
>> >
>> > These are the dependencies which will be required beforehand. Install
>> > them one by one.
>> >
>> > libwt-dev - C++ library and application server for web applications
>> > [development]
>> > libwtdbo-dev - Wt::Dbo ORM library for Wt [development]
>> > libwtdbofirebird-dev - Firebird backend for Wt::Dbo [development]
>> > libwtdbomysql-dev - MySQL/MariaDB backend for Wt::Dbo [development]
>> > libwtdbopostgres-dev - PostgreSQL backend for Wt::Dbo [development]
>> > libwtdbosqlite-dev - sqlite3 backend for Wt::Dbo [development]
>> > libwtext-dev - additional widgets for Wt, based on ExtJS 2.0.x
>> > [development]
>> > libwtfcgi-dev - FastCGI connector library for Wt [development]
>> > libwthttp-dev - HTTP(S) connector library for Wt [development]
>> > libwttest-dev - test connector library for Wt [development]
>> > libpugixml-dev
>> >
>>
>> please add this in the readme file
>>
>> >
>> > After this, do let me know with the error.
>> >
>>
>>
>> no error, now I'm able to run it but I cannot modify the grassdata
>> directory, is it normal?
>
>
> Yes and No!
>
> Yes it is expected that there is not user specific location-mapset upload
> ready now.
>

you could set by default $HOME/grassdata (it is quite common to have a
grassdata in our own $HOME)

>
> I will push a cmake configuration that downloads sample grass7 dataset. So
> you can test it easily.
>

no please, no download sample dataset, should be better to set our
grassdata in a cmake variable



-- 
ciao
Luca

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

Re: [GRASS-dev] [SoC]Week-1 WebGrass

[Rashad Kanavath]

Hello Luca,

Thanks for testing.

On Mon, May 30, 2016 at 12:14 PM, Luca Delucchi 
wrote:

> On 30 May 2016 at 11:09, Mayank Agrawal 
> wrote:
> >
> > Readme-
> >
> > in the webgrass folder https://github.com/rashadkm/webgrass
> >
> > mkdir build
> > cd build
> > cmake ..
> > make
> > sudo ./wgrass.wt --http-address=0.0.0.0 --http-port=8080 --docroot ../
> >
>
> I read it already, but it was not enough
>
> >
> > These are the dependencies which will be required beforehand. Install
> them one by one.
> >
> > libwt-dev - C++ library and application server for web applications
> [development]
> > libwtdbo-dev - Wt::Dbo ORM library for Wt [development]
> > libwtdbofirebird-dev - Firebird backend for Wt::Dbo [development]
> > libwtdbomysql-dev - MySQL/MariaDB backend for Wt::Dbo [development]
> > libwtdbopostgres-dev - PostgreSQL backend for Wt::Dbo [development]
> > libwtdbosqlite-dev - sqlite3 backend for Wt::Dbo [development]
> > libwtext-dev - additional widgets for Wt, based on ExtJS 2.0.x
> [development]
> > libwtfcgi-dev - FastCGI connector library for Wt [development]
> > libwthttp-dev - HTTP(S) connector library for Wt [development]
> > libwttest-dev - test connector library for Wt [development]
> > libpugixml-dev
> >
>
> please add this in the readme file
>
> >
> > After this, do let me know with the error.
> >
>
>
> no error, now I'm able to run it but I cannot modify the grassdata
> directory, is it normal?


Yes and No!

Yes it is expected that there is not user specific location-mapset upload
ready now.

But it is not normal that it will stay like that forever. I am the one who
asked mayank to fix it that way for now. Because unless we have the
authentication system ready where each user has access to some directory on
server that can have his/her own grass database. This stays normal.

Remember authentication is in the to be done part of proposal.

I will push a cmake configuration that downloads sample grass7 dataset. So
you can test it easily.


>
> --
> ciao
> Luca
>
> www.lucadelu.org
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>



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

Re: [GRASS-dev] [SoC]Week-1 WebGrass

[Luca Delucchi]

On 30 May 2016 at 11:09, Mayank Agrawal  wrote:
>
> Readme-
>
> in the webgrass folder https://github.com/rashadkm/webgrass
>
> mkdir build
> cd build
> cmake ..
> make
> sudo ./wgrass.wt --http-address=0.0.0.0 --http-port=8080 --docroot ../
>

I read it already, but it was not enough

>
> These are the dependencies which will be required beforehand. Install them 
> one by one.
>
> libwt-dev - C++ library and application server for web applications 
> [development]
> libwtdbo-dev - Wt::Dbo ORM library for Wt [development]
> libwtdbofirebird-dev - Firebird backend for Wt::Dbo [development]
> libwtdbomysql-dev - MySQL/MariaDB backend for Wt::Dbo [development]
> libwtdbopostgres-dev - PostgreSQL backend for Wt::Dbo [development]
> libwtdbosqlite-dev - sqlite3 backend for Wt::Dbo [development]
> libwtext-dev - additional widgets for Wt, based on ExtJS 2.0.x [development]
> libwtfcgi-dev - FastCGI connector library for Wt [development]
> libwthttp-dev - HTTP(S) connector library for Wt [development]
> libwttest-dev - test connector library for Wt [development]
> libpugixml-dev
>

please add this in the readme file

>
> After this, do let me know with the error.
>


no error, now I'm able to run it but I cannot modify the grassdata
directory, is it normal?


-- 
ciao
Luca

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

Re: [GRASS-dev] [SoC]Week-1 WebGrass

[Mayank Agrawal]

Readme-

in the webgrass folder https://github.com/rashadkm/webgrass

mkdir build
cd build
cmake ..
make
sudo ./wgrass.wt --http-address=0.0.0.0 --http-port=8080 --docroot ../


These are the dependencies which will be required beforehand. Install them
one by one.


   1. libwt-dev - C++ library and application server for web applications
   [development]
   2. libwtdbo-dev - Wt::Dbo ORM library for Wt [development]
   3. libwtdbofirebird-dev - Firebird backend for Wt::Dbo [development]
   4. libwtdbomysql-dev - MySQL/MariaDB backend for Wt::Dbo [development]
   5. libwtdbopostgres-dev - PostgreSQL backend for Wt::Dbo [development]
   6. libwtdbosqlite-dev - sqlite3 backend for Wt::Dbo [development]
   7. libwtext-dev - additional widgets for Wt, based on ExtJS 2.0.x
   [development]
   8. libwtfcgi-dev - FastCGI connector library for Wt [development]
   9. libwthttp-dev - HTTP(S) connector library for Wt [development]
   10. libwttest-dev - test connector library for Wt [development]
   11. libpugixml-dev


After this, do let me know with the error.

On Mon, May 30, 2016 at 12:40 PM, Luca Delucchi 
wrote:

> On 29 May 2016 at 22:29, Mayank Agrawal 
> wrote:
> >
> > Hi everyone,
> >
>
> Hi Mayank,
>
> > I am Mayank Agrawal and I am working on webgrass.
> >
> > my report for the week 1
> >
> > What did you get done this week?
> >
> > The first page of the MainUI of the Grass with all the submenus and
> menus.
> > parsing of the xml file for the menu.
> > restructuring the xml file for better understanding.
> > removing small errors like wrong paths given at different resources,
> routing of the pages
> >
> > see Commits .
> > Results hosted here .
> >
>
> please use plain text, otherwise during answer we will lost the links
>
> I tried to compile webgrass but it doesn't work for me, Could you
> extend the README file with dependencies, right now I'm stopped during
> configuration
>
>  CMAKE_BUILD_TYPE
>  CMAKE_INSTALL_PREFIX /usr/local
>  Wt_DBOPOSTGRES_DEBUG_LIBRARY /usr/lib/libwtdbopostgres.so
>  Wt_DBOPOSTGRES_LIBRARY   /usr/lib/libwtdbopostgres.so
>  Wt_DBOSQLITE3_DEBUG_LIBRARY  Wt_DBOSQLITE3_DEBUG_LIBRARY-NOTFOUND
>  Wt_DBOSQLITE3_LIBRARYWt_DBOSQLITE3_LIBRARY-NOTFOUND
>  Wt_DBO_DEBUG_LIBRARY /usr/lib/libwtdbo.so
>  Wt_DBO_LIBRARY   /usr/lib/libwtdbo.so
>  Wt_DEBUG_LIBRARY /usr/lib/libwt.so
>  Wt_EXT_DEBUG_LIBRARY Wt_EXT_DEBUG_LIBRARY-NOTFOUND
>  Wt_EXT_LIBRARY   Wt_EXT_LIBRARY-NOTFOUND
>  Wt_FCGI_DEBUG_LIBRARYWt_FCGI_DEBUG_LIBRARY-NOTFOUND
>  Wt_FCGI_LIBRARY  Wt_FCGI_LIBRARY-NOTFOUND
>  Wt_HTTP_DEBUG_LIBRARY/usr/lib/libwthttp.so
>  Wt_HTTP_LIBRARY  /usr/lib/libwthttp.so
>  Wt_INCLUDE_DIR   /usr/include
>  Wt_LIBRARY   /usr/lib/libwt.so
>
>
> >
> > Mayank Agrawal
> > Lab for Spatial Informatics
> > IIIT Hyderabad
> > Hyderabad
> >
>
>
> --
> ciao
> Luca
>
> www.lucadelu.org
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3043: Change default color table

[GRASS GIS]

#3043: Change default color table
--+---
  Reporter:  wenzeslaus   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  blocker  |  Milestone:  7.2.0
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  r.colors, d.rast, rainbow
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by mlennert):

 Replying to [comment:4 wenzeslaus]:
 > `viridis` is now available in trunk (try `r.colors`). This color table
 was developed for Matplotlib based on color properties and color
 perception and then it won the community voting. See the attachments to
 see how it behaves including gray scale print and simulated color
 blindness (I can share also the full resolution images).

 Without some kind of legend, it is difficult to understand what is what in
 your color_tables_overview... Generally, it seems to me that rainbow and
 bcyr provide greater contrasts.


 > Is anybody opposed to the change of default color table from `rainbow`
 to `viridis` in GRASS GIS for release 7.2?

 I would vote -0, i.e. I'm opposed to this change, but not enough to stop
 it if others all agree on it.

 I'm not convinced that viridis is better. More so, I think that if we
 provide a default color table of which we say that it is good (better than
 rainbow), we should make our criteria more explicit. Why do you find
 viridis good (better than other color tables) ? Just aesthetics ? What is
 good for matplotlib, might not be good for GRASS...

 More fundamentally, and to repeat myself: IMHO there is '''no''' good
 default color table. Color tables qualities are context and target
 dependent. I personally thus prefer not to pretend that we can provide a
 good color table by default.

 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] GSoC 2016 - PyQt

[Luca Delucchi]

On 27 May 2016 at 23:27, Ondřej Pešek  wrote:
>
> Hi,
>

Hi Ondrej,

> here is report of what I have done during this week in my GRASS
>
> GSoC Project:
>
> WEEK 1
>
> Designed basic GUI shuck. From XML is now automatically generated GUI with 
> name, keywords and basic layouts (description, tabs, buttons).
>
> Code now works as a script with parameter - for example r.buffer (python 
> forms.py r.buffer).
>
> Take a look at screenshots.
>

These look really a good starting point, please could you extend the
README file adding how to test the code, for example dependencies and
how to compile/use

>
> Best regards,
> Ondrej
>


-- 
ciao
Luca

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

Re: [GRASS-dev] [SoC]Week-1 WebGrass

[Luca Delucchi]

On 29 May 2016 at 22:29, Mayank Agrawal  wrote:
>
> Hi everyone,
>

Hi Mayank,

> I am Mayank Agrawal and I am working on webgrass.
>
> my report for the week 1
>
> What did you get done this week?
>
> The first page of the MainUI of the Grass with all the submenus and menus.
> parsing of the xml file for the menu.
> restructuring the xml file for better understanding.
> removing small errors like wrong paths given at different resources, routing 
> of the pages
>
> see Commits .
> Results hosted here .
>

please use plain text, otherwise during answer we will lost the links

I tried to compile webgrass but it doesn't work for me, Could you
extend the README file with dependencies, right now I'm stopped during
configuration

 CMAKE_BUILD_TYPE
 CMAKE_INSTALL_PREFIX /usr/local
 Wt_DBOPOSTGRES_DEBUG_LIBRARY /usr/lib/libwtdbopostgres.so
 Wt_DBOPOSTGRES_LIBRARY   /usr/lib/libwtdbopostgres.so
 Wt_DBOSQLITE3_DEBUG_LIBRARY  Wt_DBOSQLITE3_DEBUG_LIBRARY-NOTFOUND
 Wt_DBOSQLITE3_LIBRARYWt_DBOSQLITE3_LIBRARY-NOTFOUND
 Wt_DBO_DEBUG_LIBRARY /usr/lib/libwtdbo.so
 Wt_DBO_LIBRARY   /usr/lib/libwtdbo.so
 Wt_DEBUG_LIBRARY /usr/lib/libwt.so
 Wt_EXT_DEBUG_LIBRARY Wt_EXT_DEBUG_LIBRARY-NOTFOUND
 Wt_EXT_LIBRARY   Wt_EXT_LIBRARY-NOTFOUND
 Wt_FCGI_DEBUG_LIBRARYWt_FCGI_DEBUG_LIBRARY-NOTFOUND
 Wt_FCGI_LIBRARY  Wt_FCGI_LIBRARY-NOTFOUND
 Wt_HTTP_DEBUG_LIBRARY/usr/lib/libwthttp.so
 Wt_HTTP_LIBRARY  /usr/lib/libwthttp.so
 Wt_INCLUDE_DIR   /usr/include
 Wt_LIBRARY   /usr/lib/libwt.so


>
> Mayank Agrawal
> Lab for Spatial Informatics
> IIIT Hyderabad
> Hyderabad
>


-- 
ciao
Luca

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