Re: [GRASS-dev] [GRASS GIS] #3257: Do not require ctypes for compilation in temporal modules

[GRASS GIS]

#3257: Do not require ctypes for compilation in temporal modules
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.1
 Component:  Temporal|Version:  unspecified
Resolution:  |   Keywords:  ctypes, compilation, build,
 |  homebrew, brew, conda, macos, osx,
   CPU:  |  v.what.strds, t.create
  Unspecified|   Platform:  All
-+-

Comment (by neteler):

 Backport this...?

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Color tables/rules now use standardized color parsing

[Markus Neteler]

On Thu, Oct 20, 2016 at 12:20 AM, Vaclav Petras  wrote:
> Dear all,
>
> in r69708, I've changed the implementation of parsing color rules to use the
> G_str_to_color() function instead of a custom mechanism. This, in connection
> with r69683, adds the possibility to use HTML (CSS) style of hexadecimal
> colors with leading hash.
>
> So, now you can do:
>
> r.colors elevation rules=- < 0% #D24926
> 100% #FCE36D
> EOF
>
> Where it gets little tricky is that hash is used to comment a line in color
> rules/color table format. A comment is now implemented as a line where first
> character is hash, so there is no interference. We just need to keep it that
> way.
>
> The comments (# ...) are actually not documented in r.colors manual.

I just tested it with a soil map, great job!

> Same goes also for the syntax with space as a separator instead of colon. Now 
> we
> also support ; and , as separators (because that's what G_str_to_color()
> supports). The hash syntax keeps tradition and it is undocumented as well
> for now (but there is a test!).

Perhaps worthwhile to mention it in the manual?

thanks
Markus

> Best,
> Vaclav
>
>
> r69708 https://trac.osgeo.org/grass/changeset/69708
> r69683 https://trac.osgeo.org/grass/changeset/69683
> Specify color as #RRGGBB
> https://lists.osgeo.org/pipermail/grass-dev/2016-October/082662.html
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Reviewing GSoC 2017 page

[massimo di stefano]

For web grass the ideal is to have a dedicated rendering system, based on GRASS 
data read by C++ in a buffer and rendered to html5 canvas or webgl directly. 
there is a gitter page if anyone is interested on web grass and want discuss 
its further development. 

For the jupyter notebook IMHO the easiest way to interact with grass, is to use 
a js framework as canvas and load images by converting grass data to jpeg or to 
 tiled images (ipyleaflet or cesiumpy are good options) I use gdal2tiles and 
gdaldem to generate ipyleaflet friendly images. 

The cons of this, as Rashad said, is that the grass data gets copied server 
side and will not be “in sync” in case the raster map is subject to some 
processing .. to keep the maps up-to-date I generate an sha-ash code for each 
raster and I connect it to a refresh button (ipywidgets) to regenerate the 
tiles or jpeg if the linked raster has changed.

The mapserver option introduce one more dependency … which can maybe annoying, 
but avoid to copy data by loading grass raster linked directly to the grass 
data  from a map file (needs goal-grass plugin)

I use the “js" method in a pyqt gui application loading leaflet and cesium in a 
qtwebengine, for personal use it works quite well .. but is hackish and 
suboptimal …

Massimo.


On Feb 3, 2017, at 2:14 PM, Margherita Di Leo  wrote:
> 
> 
> 
> On Thu, Jan 26, 2017 at 6:37 PM, Vaclav Petras  > wrote:
> 
> [...]
> 
> Not directly related. Jupyter Notebook is independent and with some additions 
> of interactive maps it could be used as a web interface for advanced or 
> Python aware users. It can be used even now, but for visualization, you need 
> to deal with d.* commands (which is fine in general but not for zooming, 
> panning, ...) or you need to plug in other solution for visualization (like 
> MapServer reading from GRASS GIS Database). There might be some code sharing 
> between (some/any) web GRASS and Jupyter on the side of Python API or 
> JavaScript map display (if applicable).
>  
> 
> See: https://github.com/SylvainCorlay/ipyleaflet 
> 
> 
> -- 
> Margherita Di Leo
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev

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

Re: [GRASS-dev] [GRASS GIS] #3286: Add Line_height as a valid attribute in v.to.db

[GRASS GIS]

#3286: Add Line_height as a valid attribute in v.to.db
--+---
  Reporter:  geografik|  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.2.1
 Component:  Database |Version:  7.2.0
Resolution:   |   Keywords:  Line_height, v.in.db, kml
   CPU:  All  |   Platform:  All
--+---
Description changed by martinl:

Old description:

> Imported kml files that include elevation data are structured generally
> as shown below in GRASS (this is an example of a contour line):
>
> east, north: -79.7630759471, 39.0874586371
> DBT@corH:
>  Type: Line
>  Id: 885
>  Length: 275.746
>  Line_height: 698.602997
>  Layer: 1
>  Category: 885
>  Driver: sqlite
>  Database: /Users/sesMacBook/grassdata/KML/corH/sqlite/sqlite.db
>  Table: DBT
>  Key_column: cat
>  Attributes:
>cat: 885
>cat_: 885
>tessellate: -1
>extrude: -1
>visibility: -1
>
> Elevation data is maintained in the Line_height field which is not a
> recognized attribute, and therefor precludes any further use of these
> data in GRASS - beyond simple display and labling.  3D analysis, for
> example, is not possible.  The suggested improvement to v.to.db would add
> Line_height to the list of attributes considered in this module so that
> the elevation data could become part of the recognized feature attributes
> and be useful in other modules.

New description:

 Imported kml files that include elevation data are structured generally as
 shown below in GRASS (this is an example of a contour line):

 {{{
 east, north: -79.7630759471, 39.0874586371
 DBT@corH:
  Type: Line
  Id: 885
  Length: 275.746
  Line_height: 698.602997
  Layer: 1
  Category: 885
  Driver: sqlite
  Database: /Users/sesMacBook/grassdata/KML/corH/sqlite/sqlite.db
  Table: DBT
  Key_column: cat
  Attributes:
cat: 885
cat_: 885
tessellate: -1
extrude: -1
visibility: -1
 }}}

 Elevation data is maintained in the Line_height field which is not a
 recognized attribute, and therefor precludes any further use of these data
 in GRASS - beyond simple display and labling.  3D analysis, for example,
 is not possible.  The suggested improvement to v.to.db would add
 Line_height to the list of attributes considered in this module so that
 the elevation data could become part of the recognized feature attributes
 and be useful in other modules.

--

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3286: Add Line_height as a valid attribute in v.to.db

[GRASS GIS]

#3286: Add Line_height as a valid attribute in v.to.db
--+---
  Reporter:  geografik|  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.2.1
 Component:  Database |Version:  7.2.0
Resolution:   |   Keywords:  Line_height, v.in.db, kml
   CPU:  All  |   Platform:  All
--+---

Comment (by mlennert):

 Replying to [ticket:3286 geografik]:
 > Imported kml files that include elevation data are structured generally
 as shown below in GRASS (this is an example of a contour line):
 >
 > east, north: -79.7630759471, 39.0874586371
 > DBT@corH:
 >  Type: Line
 >  Id: 885
 >  Length: 275.746
 >  Line_height: 698.602997
 >  Layer: 1
 >  Category: 885
 >  Driver: sqlite
 >  Database: /Users/sesMacBook/grassdata/KML/corH/sqlite/sqlite.db
 >  Table: DBT
 >  Key_column: cat
 >  Attributes:
 >cat: 885
 >cat_: 885
 >tessellate: -1
 >extrude: -1
 >visibility: -1
 >
 > Elevation data is maintained in the Line_height field which is not a
 recognized attribute, and therefor precludes any further use of these data
 in GRASS - beyond simple display and labling.  3D analysis, for example,
 is not possible.  The suggested improvement to v.to.db would add
 Line_height to the list of attributes considered in this module so that
 the elevation data could become part of the recognized feature attributes
 and be useful in other modules.


 Actually, Line_height is not a "field" in the data. v.what calculates the
 minimum and the maximum height of all the vertices of a line and either
 outputs both, or, if they are equal, only one value.

 The question this raises, therefore, is: which "height" is the most
 relevant for a line ? Should it be the mean height of all vertices ?
 Should v.to.db provide lheight_min, lheight_mean and lheight_max ?

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #3286: Add Line_height as a valid attribute in v.to.db

[GRASS GIS]

#3286: Add Line_height as a valid attribute in v.to.db
---+-
 Reporter:  geografik  |  Owner:  grass-dev@…
 Type:  enhancement| Status:  new
 Priority:  normal |  Milestone:  7.2.1
Component:  Database   |Version:  7.2.0
 Keywords:  Line_height, v.in.db, kml  |CPU:  All
 Platform:  All|
---+-
 Imported kml files that include elevation data are structured generally as
 shown below in GRASS (this is an example of a contour line):

 east, north: -79.7630759471, 39.0874586371
 DBT@corH:
  Type: Line
  Id: 885
  Length: 275.746
  Line_height: 698.602997
  Layer: 1
  Category: 885
  Driver: sqlite
  Database: /Users/sesMacBook/grassdata/KML/corH/sqlite/sqlite.db
  Table: DBT
  Key_column: cat
  Attributes:
cat: 885
cat_: 885
tessellate: -1
extrude: -1
visibility: -1

 Elevation data is maintained in the Line_height field which is not a
 recognized attribute, and therefor precludes any further use of these data
 in GRASS - beyond simple display and labling.  3D analysis, for example,
 is not possible.  The suggested improvement to v.to.db would add
 Line_height to the list of attributes considered in this module so that
 the elevation data could become part of the recognized feature attributes
 and be useful in other modules.

--
Ticket URL: 
GRASS GIS 

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