Re: [GRASS-dev] [GRASS GIS] #3086: When reloading a workspace, maps do not fill the display area if larger than default initial Display area

[GRASS GIS]

#3086: When reloading a workspace, maps do not fill the display area if larger
than default initial Display area
--+-
  Reporter:  ychemin  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.3.0
 Component:  Display  |Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Linux
--+-
Changes (by ychemin):

 * Attachment "displayloadedfromgxwfiledoesnotfillentirearea.png" added.

 Map display loaded from a workspace .gxw file does not fill the entire
 display area

--
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] #3086: When reloading a workspace, maps do not fill the display area if larger than default initial Display area

[GRASS GIS]

#3086: When reloading a workspace, maps do not fill the display area if larger
than default initial Display area
-+-
 Reporter:  ychemin  |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:  7.3.0
Component:  Display  |Version:  svn-trunk
 Keywords:   |CPU:  Unspecified
 Platform:  Linux|
-+-
 When reloading a workspace from a .gxw file,

 if the display area in the gxw file is larger than the default initial
 area of a wx display (800x600?) then the map will not fill the whole
 display area.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] font size in d.legend

[Glynn Clements]

Paulo van Breugel wrote:

> I am creating some maps (png format) using the GRASS_RENDER_IMMEDIATE=cairo
> and d.* calls. I am setting width and height based on a final desired
> 300dpi for the output image (i.e., pixels =  # inch x 300).
> 
> However, the font size as can be set in e.g., d.legend is, I assume, based
> on the assumption that the output image has a DPI of 72. Is there any way
> to set the DPI of the output image?

For the cairo driver, I believe that the font size is the size of 1-em
in pixels (the cairo documentation says "user space units"; in the
absence of any additional transformations, I believe that this means
pixels).

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

Re: [GRASS-dev] [GRASS GIS] #2683: grass 7 doesn't start in text mode on CentOS 7

[GRASS GIS]

#2683: grass 7 doesn't start in text mode on CentOS 7
+-
  Reporter:  morenocomelli  |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:  7.0.5
 Component:  Startup|Version:  svn-trunk
Resolution: |   Keywords:  centos
   CPU:  Unspecified|   Platform:  Unspecified
+-

Comment (by wenzeslaus):

 In [changeset:"68797" 68797]:
 {{{
 #!CommitTicketReference repository="" revision="68797"
 init: advise user about --help and -c

 make messages shorter
 follows r68795, see #2683
 }}}

--
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] #3085: Batch import with import raster data tool does not recognize projection information

[GRASS GIS]

#3085: Batch import with import raster data tool does not recognize projection
information
--+-
  Reporter:  pvanbosgeo   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.5
 Component:  Default  |Version:  unspecified
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by annakrat):

 Should be fixed in r68796.

--
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] #2683: grass 7 doesn't start in text mode on CentOS 7

[GRASS GIS]

#2683: grass 7 doesn't start in text mode on CentOS 7
+-
  Reporter:  morenocomelli  |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:  7.0.5
 Component:  Startup|Version:  svn-trunk
Resolution: |   Keywords:  centos
   CPU:  Unspecified|   Platform:  Unspecified
+-
Changes (by neteler):

 * version:  7.0.0 => svn-trunk


Comment:

 Replying to [comment:17 rbarnes]:
 > Thanks. But I'm not sure how someone new to GRASS is supposed to know
 the foregoing. Perhaps by searching they will find this info here.

 Sure, the idea is to improve the message. Now (r68795) it reads:

 {{{
 grass73
 ERROR: Unable to start GRASS GIS. You have the choice to:
  - Launch the GRASS GIS interface with the '-gui' switch (`grass73 -gui`)
  - Launch GRASS GIS directly with path to the location/mapset as an
 argument (`grass73 /path/to/location/mapset`)
  - Create manually the GISRC file (/home/user/.grass7/rc)
 See also: https://grass.osgeo.org/grass73/manuals/helptext.html
 Exiting...
 }}}

 (manual page URL added).

 Any missing text from comment:16 should be added to that manual page.

 If this modified error message is ok, I'll backport it. Otherwise please
 suggest rephrasing.

--
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] #3085: Batch import with import raster data tool does not recognize projection information

[Paulo van Breugel]

On Wed, Jun 29, 2016 at 9:28 PM, GRASS GIS  wrote:

> #3085: Batch import with import raster data tool does not recognize
> projection
> information
> --+-
>   Reporter:  pvanbosgeo   |  Owner:  grass-dev@…
>   Type:  defect   | Status:  new
>   Priority:  normal   |  Milestone:  7.0.5
>  Component:  Default  |Version:  unspecified
> Resolution:   |   Keywords:
>CPU:  Unspecified  |   Platform:  Unspecified
> --+-
>
> Comment (by mlennert):
>
>  What exactly is the issue, here ?
>
>  I get the exact same window be it with one file or with a directory. It is
>  just an additional step to make you conscious about the fact that the
>  module will proceed with reprojecting the files. Just select the files you
>  are sure you want to import with reprojection and then proceed.
>

Sorry, my description might not have been clear. The Africlim data I refer
to above are in latlon, which I tried to import in a latlon location.
Importing one layer proceeds without problem (i.e., without the projection
window). Only when I try to import multiple layers using the directory
option I am presented with that projection window. But why reprojecting if
the projection of the layers matches that of the location (as evident from
the fact that one layer imports without need for reprojection).

In the example with the NC sample data set, I am exporting layers from the
location and importing them in the same location. This means the layers
should just import, without reprojection. When importing one layer (using
the file option) that is exactly what happens, the layer is imported. Like
above, only when importing multiple layers using the directory option, the
reprojection window is shown. Again, I see no reason why the layers should
be reprojected. The projection already matches that of the location
(obviously).




> --
> 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] #3085: Batch import with import raster data tool does not recognize projection information

[GRASS GIS]

#3085: Batch import with import raster data tool does not recognize projection
information
--+-
  Reporter:  pvanbosgeo   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.5
 Component:  Default  |Version:  unspecified
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mlennert):

 What exactly is the issue, here ?

 I get the exact same window be it with one file or with a directory. It is
 just an additional step to make you conscious about the fact that the
 module will proceed with reprojecting the files. Just select the files you
 are sure you want to import with reprojection and then proceed.

--
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] #3085: Batch import with import raster data tool does not recognize projection information

[GRASS GIS]

#3085: Batch import with import raster data tool does not recognize projection
information
--+-
  Reporter:  pvanbosgeo   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.5
 Component:  Default  |Version:  unspecified
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by pvanbosgeo):

 * Attachment "screenshot reprojection screen.png" added.

 Screenshot Reprojection screen that follows when trying to import layers
 from directory using the 'import raster data' tool

--
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] #3085: Batch import with import raster data tool does not recognize projection information

[GRASS GIS]

#3085: Batch import with import raster data tool does not recognize projection
information
-+-
 Reporter:  pvanbosgeo   |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:  7.0.5
Component:  Default  |Version:  unspecified
 Keywords:   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 Importing using the Import raster data (menu: file - import raster data -
 common formats import) works as advertised when importing a file. However,
 when trying to import a batch of rasters in a directory, the
 'reprojection' screen is shown, with the message that 'projection of
 following layers do not match with projection of current location
 (followed by a list of all layers in that directory).

 I have had this issue with layers from various data sets, including last
 data from the Africlim
 (https://grasswiki.osgeo.org/wiki/Global_datasets#Africlim_maps) data set,
 which are latlon (wgs84) layers with identical coordinate system header
 (using gdalinfo).

 To reproduce this, one can export the raster layers from the NC sample
 data set, and then import them all in once using the import raster data
 tool.


 {{{
 g.region raster=soils
 r.out.gdal input=soils output=/home/paulo/Desktop/test/soils.tif
 format=GTiff
 r.out.gdal input=landuse output=/home/paulo/Desktop/test/landuse.tif
 format=GTiff
 r.out.gdal input=geology output=/home/paulo/Desktop/test/geology.tif
 format=GTiff
 r.out.gdal input=elevation output=/home/paulo/Desktop/test/elevation.tif
 format=GTiff

 }}}

 Now, when importing them, the same warning is shown (see screenshot)

 I am running grass 7.3dev r68774 (but I have experienced the same with
 many previous revisions) on Ubuntu 14.04.

--
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] #2683: grass 7 doesn't start in text mode on CentOS 7

[GRASS GIS]

#2683: grass 7 doesn't start in text mode on CentOS 7
+-
  Reporter:  morenocomelli  |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:  7.0.5
 Component:  Startup|Version:  7.0.0
Resolution: |   Keywords:  centos
   CPU:  Unspecified|   Platform:  Unspecified
+-

Comment (by rbarnes):

 Thanks. But I'm not sure how someone new to GRASS is supposed to know the
 foregoing. Perhaps by searching they will find this info here.

--
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] #2871: lib/iostream/mm.cpp:Fails to build with GCC 6: declaration of ... has a different exception specifier

[GRASS GIS]

#2871: lib/iostream/mm.cpp:Fails to build with GCC 6: declaration of ... has a
different exception specifier
+-
  Reporter:  sebastic   |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  blocker|  Milestone:  7.2.0
 Component:  Compiling  |Version:  svn-releasebranch70
Resolution: |   Keywords:  iostream
   CPU:  All|   Platform:  Linux
+-
Changes (by martinl):

 * priority:  major => blocker


--
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] #2871: lib/iostream/mm.cpp:Fails to build with GCC 6: declaration of ... has a different exception specifier

[GRASS GIS]

#2871: lib/iostream/mm.cpp:Fails to build with GCC 6: declaration of ... has a
different exception specifier
+-
  Reporter:  sebastic   |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  major  |  Milestone:  7.2.0
 Component:  Compiling  |Version:  svn-releasebranch70
Resolution: |   Keywords:  iostream
   CPU:  All|   Platform:  Linux
+-

Comment (by sebastic):

 Replying to [comment:8 martinl]:
 > Downgrading the priority, GCC 6 is experimental version...

 The severity of the bugreport in Debian has been raised to Release
 Critical because the GCC maintainers intend to switch to GCC 6 for the
 upcoming stretch release.

 GRASS will be removed from testing (and upcoming stretch release) if this
 build failure with GCC 6 remains unfixed.

--
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] #3084: i.segment: allow more than 2147483647 cells (was: i.segment: notnullcells defined as long too limited)

[GRASS GIS]

#3084: i.segment: allow more than 2147483647 cells
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.2.0
 Component:  Imagery  |Version:  unspecified
Resolution:   |   Keywords:  i.segment variable type
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by mlennert):

 * milestone:  7.0.5 => 7.2.0
 * type:  defect => enhancement


Comment:

 Replying to [comment:1 mmetz]:
 > Replying to [ticket:3084 mlennert]:
 > > In iseg.h, notnullcells is defined as long. On Windows this has a
 range of –2147483648 through 2147483647.
 > >
 > > We are working on a region that has over 7 billion pixels and so the
 nonnullcells variable overflows, becomes negative and i.segment fails with
 "insufficient number of non-null cells".
 > >
 > > Two reflections:
 > > * Shouldn't this be unsigned ?
 > > * Maybe a long long would be safer, seeing that pixel numbers don't
 stop increasing.
 >
 > For nonnullcells, long long would be ok. But i.segment is not prepared
 to handle raster maps with more than 2147483647 cells, at least the region
 IDs would also need to be changed, or handled differently. Variables for
 region ID as well as the region ID output is 32 bit signed integer, so
 there will be another integer overflow, particularly because in the
 beginning each cell gets a unique region ID.

 Ok, so I'll retype the ticket to enhancement request and change the title
 to reflect the demand for i.segment to handle over 2147483647 cells. Other
 than changing variable types, does this entail any other changes ?

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3084: i.segment: notnullcells defined as long too limited

[GRASS GIS]

#3084: i.segment: notnullcells defined as long too limited
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.5
 Component:  Imagery  |Version:  unspecified
Resolution:   |   Keywords:  i.segment variable type
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mmetz):

 Replying to [ticket:3084 mlennert]:
 > In iseg.h, notnullcells is defined as long. On Windows this has a range
 of –2147483648 through 2147483647.
 >
 > We are working on a region that has over 7 billion pixels and so the
 nonnullcells variable overflows, becomes negative and i.segment fails with
 "insufficient number of non-null cells".
 >
 > Two reflections:
 > * Shouldn't this be unsigned ?
 > * Maybe a long long would be safer, seeing that pixel numbers don't stop
 increasing.

 For nonnullcells, long long would be ok. But i.segment is not prepared to
 handle raster maps with more than 2147483647 cells, at least the region
 IDs would also need to be changed, or handled differently. Variables for
 region ID as well as the region ID output is 32 bit signed integer, so
 there will be another integer overflow, particularly because in the
 beginning each cell gets a unique region ID.

--
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] #2045: r.to.vect: use less memory

[GRASS GIS]

#2045: r.to.vect: use less memory
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  closed
  Priority:  normal   |  Milestone:  7.0.5
 Component:  Raster   |Version:  svn-trunk
Resolution:  fixed|   Keywords:  r.to.vect
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mmetz):

 Replying to [comment:25 mlennert]:
 > Replying to [comment:20 mmetz]:
 > > Replying to [comment:19 mlennert]:
 > > >
 > > > Data and info provided via private mail.
 > >
 > > I have received the data, thanks!
 > >
 > > >
 > > > Previous posters have also reported that setting GRASS_VECTOR_LOWMEM
 didn't make much of a difference, so maybe the problem is there ?
 > >
 > > I don't think so. Without GRASS_VECTOR_LOWMEM, v.build needs about 26
 GB of RAM. With GRASS_VECTOR_LOWMEM, v.build needs about 11 GB of RAM
 >
 > A question that came up in a discussion with colleagues: could this
 memory need be determined before building topology and possibly check for
 enough available memory / warn the user ?

 Unfortunately not because the number of features is unknown when topology
 building starts. What could be done is counting primitives without
 building topology, then estimate memory requirements just for these
 primitives. The number of areas can not be estimated.

--
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] #2045: r.to.vect: use less memory

[GRASS GIS]

#2045: r.to.vect: use less memory
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  closed
  Priority:  normal   |  Milestone:  7.0.5
 Component:  Raster   |Version:  svn-trunk
Resolution:  fixed|   Keywords:  r.to.vect
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mlennert):

 Replying to [comment:20 mmetz]:
 > Replying to [comment:19 mlennert]:
 > >
 > > Data and info provided via private mail.
 >
 > I have received the data, thanks!
 >
 > >
 > > Previous posters have also reported that setting GRASS_VECTOR_LOWMEM
 didn't make much of a difference, so maybe the problem is there ?
 >
 > I don't think so. Without GRASS_VECTOR_LOWMEM, v.build needs about 26 GB
 of RAM. With GRASS_VECTOR_LOWMEM, v.build needs about 11 GB of RAM

 A question that came up in a discussion with colleagues: could this memory
 need be determined before building topology and possibly check for enough
 available memory / warn the user ?

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] vector legend implementation

[Moritz Lennert]

On 28/06/16 17:38, Anna Petrášová wrote:

On Sat, Jun 25, 2016 at 3:01 PM, Anna Petrášová  wrote:

On Sat, Jun 25, 2016 at 7:47 AM, Martin Landa  wrote:

Hi,

2016-06-23 19:49 GMT+02:00 Anna Petrášová :

I would like to get some feedback on the implementation of vector
legend which Adam will start working on soon as part of GSoC.

Basically, the implementation would be in Python using d.graph which
allows to draw shapes, symbols, lines and text.
The first implementation would solve only basic things.


are you sure that it will be enough? Wouldn't be better to start
writing this module in C?


Yes, you are right, d.graph is pretty powerful, but we will need some
low level display functions.




d.vect.legend (like t.vect.list)


We don't have any d.rast.legend (what about renaming d.legend?)


d.legend.vect (like v.what.rast)


+ d.legend.rast ?


I agree, d.legend.rast, d.legend.vect and d.legend could become a
wrapper for backwards compatibility. We also have d.rast.leg.

We can decide this later.

Anna


We have to decide how the d.vect commands will get translated into the
legend information. This is my a Vasek's suggestion:

d.vect commands will have a new option legend, which can be a) empty-
nothing happens, b) '-' will print legend information in the format I
mentioned above to stdout and c) path to file - will write (append)
the legend specification in that file. So the GUI will automatically
append the legend=-
to all d.vect commands and get the legend specification for that
particular layer. When drawing the legend, it will go through the
d.vect layers and put together the specifications into one file and
call d.legend.vect with that file. The advantage of letting d.vect
write the legend specification for itself is that d.vect has all the
necessary information and it could possibly allow to output even more
complicated legend specification (for example when the vector has
color table). The same would then work for d.vect.thematic.
d.vect would have to have other legend related options, for example
legend_label which would be optional. This is similar behavior to how
ps.map vector instructions work, you specify the label for legend
there as well, not in the legend instruction.

Users would be able to edit the resulting legend specification in
d.legend.vect directly, because it's just a text file with couple of
lines. We might need to design a special widget so that people can
just click and select symbol, change size etc.

Does that sound reasonable, could someone see any possible problems with that?


Sounds like a good solution to me.


Moritz


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