Re: [GRASS-dev] [GRASS GIS] #2476: vector digitizer crashing with _breakLineAtIntersection

[GRASS GIS]

#2476: vector digitizer crashing with _breakLineAtIntersection
-+--
 Reporter:  annakrat |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  vdigit   |Platform:  Linux
  Cpu:  Unspecified  |  
-+--

Comment(by annakrat):

 Replying to [comment:2 mmetz]:
 > Replying to [comment:1 mmetz]:
 > > You would need to get areas on each side before breaking the line, but
 the vector lib might only be able to build areas after the new line was
 broken. I would suggest to break the line only after trying to attach
 centroids.
 >
 > Fixed in r63077.

 Thanks, it's not crashing any more. But when I draw a line over an area,
 so that it breaks, I get this error:

 {{{
 Traceback (most recent call last):
   File "/home/anna/dev/grass/trunk1/dist.x86_64-unknown-
 linux-gnu/gui/wxpython/mapwin/buffered.py", line 1248, in
 MouseActions

 self.OnRightUp(event)
   File "/home/anna/dev/grass/trunk1/dist.x86_64-unknown-
 linux-gnu/gui/wxpython/mapwin/buffered.py", line 1485, in
 OnRightUp

 self._onRightUp(event)
   File "/home/anna/dev/grass/trunk1/dist.x86_64-unknown-
 linux-gnu/gui/wxpython/vdigit/mapwindow.py", line 935, in
 _onRightUp

 (UserSettings.Get(group = 'vdigit', key = "category", subkey
 = 'value'), )
 IndexError
 :
 list index out of range
 }}}

 It seems to be related to the fix, list 'fids' is empty, but I couldn't
 see what's wrong.

-- 
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] #2454: wxgui: list of db columns only becomes available after entering layer number by hand

[GRASS GIS]

#2454: wxgui: list of db columns only becomes available after entering layer
number by hand
--+-
 Reporter:  mlennert  |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  wxGUI | Version:  unspecified  
 Keywords:  columns list  |Platform:  Linux
  Cpu:  Unspecified   |  
--+-

Comment(by annakrat):

 Could you try r63173? I tried to fix this problem for wxPython 3. But I
 didn't have the problem for 2.8, so I still don't know why it's not
 working for you.

-- 
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] #2501: r.out.gdal -t creates offset values in raster table for integer grids with values beginning with 1

[GRASS GIS]

#2501: r.out.gdal -t creates offset values in raster table for integer grids 
with
values beginning with 1
---+
  Reporter:  dnewcomb  |   Owner:  grass-dev@… 
  Type:  defect|  Status:  closed  
  Priority:  normal|   Milestone:  7.0.0   
 Component:  Default   | Version:  svn-releasebranch70 
Resolution:  wontfix   |Keywords:  r.out.gdal table attribute alignment
  Platform:  Linux | Cpu:  x86-64  
---+

Comment(by dnewcomb):

 Replying to [comment:2 mmetz]:
 > Replying to [ticket:2501 dnewcomb]:
 > > Exporting integer grids with values starting with 1 using r.out.gdal
 -t results in a raster attribute table with vertically shifted values in
 the last 3 columns.
 >
 > In your example, the output is shifted in the first 2 columns. The last
 3 columns are correct. What software did you use? The faulty fields `OID`
 and `value` are added by this software.
 >
 > Here is an example using the NC sample dataset:
 >
 > {{{
 > g.region -p rast=landclass96
 > r.out.gdal in=landclass96 out=landclass96.tif -t
 > }}}
 >
 > This creates a GeoTIFF with an associated file landclass96.tif.aux.xml
 holding the attribute table. The fields and first entry of this attribute
 table are
 > {{{
 > min, max, label
 > 1, 1, developed
 > }}}
 > all fine.
 >
 > According to `gdalinfo landclass96.tif`, the fields and first entry of
 this attribute table are
 > {{{
 > min, max, label
 > 1, 1, developed
 > }}}
 > all fine.
 >
 > Exporting landclass96 in Erdas Imagine format (`format=HFA`), there is
 no associated .xml file.
 >
 > According to `gdalinfo landclass96.img`, the fields and first entry of
 this attribute table are now
 > {{{
 > Red, Green, Blue, min, max, Class_Names
 > 0, 0, 0, 0, 1, 1, developed
 > }}}
 >
 > this is wrong, a bug in GDAL.
 >
 > If GDAL itself is not able to correctly reproduce raster attribute
 tables created by itself, other software does not really have a chance to
 read raster attribute tables ay provided by GDAL. Further on, it seems
 that some other software further modifies the raster attribute table:
 >
 > It seems that raster attribute tables created by GDAL are not widely
 supported, if yes, errors might be introduced.
 >
 > Closing as wontfix because this is a problem of GDAL and GIS software
 other than GRASS.

 I'll check with the gdal list.
 BTW,I'm running GRASS 70 with gdal 1.11.1, and when I run r.out.gdal -t, I
 get associated .xml files with both .tif and .img formats.

-- 
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] #2501: r.out.gdal -t creates offset values in raster table for integer grids with values beginning with 1

[GRASS GIS]

#2501: r.out.gdal -t creates offset values in raster table for integer grids 
with
values beginning with 1
---+
  Reporter:  dnewcomb  |   Owner:  grass-dev@… 
  Type:  defect|  Status:  closed  
  Priority:  normal|   Milestone:  7.0.0   
 Component:  Default   | Version:  svn-releasebranch70 
Resolution:  wontfix   |Keywords:  r.out.gdal table attribute alignment
  Platform:  Linux | Cpu:  x86-64  
---+

Comment(by dnewcomb):

 Software used to read the raster table was ArcGIS 10.2.2

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] sample vector temporal data

[Luca Delucchi]

On 26 November 2014 at 21:31, Anna Petrášová  wrote:
>
> Anyway, we have a lot of options... We have to decide for one.

yes, the proposal are:

- shoreline ocean
- contour from precip and/or temp
- contour from LIDAR

so?

>
> do we have any? We would have to have a timeseries of points for a str3ds.
>

if I understand well we already have, the precip_30ynormals_3d we
could extract layer for each months

> Anna


-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] sample vector temporal data

[Luca Delucchi]

On 26 November 2014 at 21:10, Markus Neteler  wrote:
>
> But polygons would be better for zonal statistics.
>

As Anna wrote we need points, but we should have both. Maybe
census_wake2000 or nc_state?

>
> Markus

-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] sample vector temporal data

[Luca Delucchi]

On 26 November 2014 at 21:02, Helena Mitasova  wrote:
>
>
> Anna is right - in fact these are the stations which were used to create the 
> rasterized climate time series so there is no need to create
> virtual weather stations - we already have the real ones. We can get more 
> complete data for these stations if needed
> - all have at least temperature and precipitation on daily basis going back 
> several decades.

Perfect

>
> we can ask our colleagues for some 3D atmospheric data or the ocean 
> temperature or salinity data,

atmospheric data or the ocean temperature could be really interesting,
could you ask?

>
> Helena
>

-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] sample vector temporal data

[Luca Delucchi]

On 26 November 2014 at 20:22, Anna Petrášová  wrote:
>
>
> yes, but there are no NC towns as points in the standard dataset. You could
> use  precip_30ynormals@PERMANENT which are the meteorology stations, which
> probably doesn't make much sense since but maybe it's still good for the
> dataset.
>

Ok, I saw them

>
> Helena suggests here to select a smaller, dynamic area (some cape for
> example) and also provide a DEM and ortho for that area (elev_lid792 is not
> coastal) to get some context. I am not sure about this dataset, if it's
> really needed, because I don't know what kind of temporal vector analysis we
> could show in the manual. It could be a good dataset to show how to create
> animations. If we decide to do it, I can help you with this part.
>
> Another option is to derive contours from the temperature/precipitation
> dataset. The advantage is that's easier to prepare.
>

as you prefer, for me it is the same...

>
> Anna
>


-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] sample vector temporal data

[Markus Neteler]

On Wed, Nov 26, 2014 at 9:31 PM, Anna Petrášová  wrote:
> On Wed, Nov 26, 2014 at 3:10 PM, Markus Neteler  wrote:
>> On Wed, Nov 26, 2014 at 8:22 PM, Anna Petrášová 
>> > Do we have any temporal data for 3d raster? I don't think we necessarily
>> > have to create this dataset.
>>
>> 3D point soil data would suffice...
>
> do we have any? We would have to have a timeseries of points for a str3ds.

Perhaps from SSURGO Soil Map Coverage

and/or

http://websoilsurvey.sc.egov.usda.gov/App/HomePage.htm

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

Re: [GRASS-dev] check on GRASS revision number

[Markus Neteler]

On Wed, Nov 26, 2014 at 8:13 PM, Michael Barton  wrote:
> For any version of GRASS for which there is any reasonable development, all
> binary extensions will be out of date as soon as the first update is made.


No - as mentioned *only* is the libgis API is changed.

Example: see the frequency of 6.4:
http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/lib/gis?order=date&desc=1

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

Re: [GRASS-dev] sample vector temporal data

[Anna Petrášová]

On Wed, Nov 26, 2014 at 3:10 PM, Markus Neteler  wrote:

> On Wed, Nov 26, 2014 at 8:22 PM, Anna Petrášová 
> wrote:
> ...
> > yes, but there are no NC towns as points in the standard dataset.
>
> There is a (small) geonames layer in the standard NC dataset which we
> could add (updated).
> But polygons would be better for zonal statistics.
>

I think we need points for t.vect.what.strds, t.vect.observe.strds.


>
> ...
> > Helena suggests here to select a smaller, dynamic area (some cape for
> > example) and also provide a DEM and ortho for that area (elev_lid792 is
> not
> > coastal) to get some context. I am not sure about this dataset, if it's
> > really needed, because I don't know what kind of temporal vector
> analysis we
> > could show in the manual.
>
> Derive contour lines from the LiDAR time series?
> Another option is to enrich it with vectorized NLCD time series:
>
> http://www.mrlc.gov/finddata.php
> - National Land Cover Database 2011 (NLCD2011)
> - National Land Cover Database 2006 (NLCD2006)
> - National Land Cover Database 2001 (NLCD2001)
> - National Land Cover Dataset 1992 (NLCD1992)
>

I remember one student had problem with some of these older datasets. I
haven't tried myself.
Anyway, we have a lot of options... We have to decide for one.

>
>
> > Do we have any temporal data for 3d raster? I don't think we necessarily
> > have to create this dataset.
>
> 3D point soil data would suffice...
>

do we have any? We would have to have a timeseries of points for a str3ds.

Anna

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

Re: [GRASS-dev] [GRASS GIS] #2501: r.out.gdal -t creates offset values in raster table for integer grids with values beginning with 1

[GRASS GIS]

#2501: r.out.gdal -t creates offset values in raster table for integer grids 
with
values beginning with 1
---+
  Reporter:  dnewcomb  |   Owner:  grass-dev@… 
  Type:  defect|  Status:  closed  
  Priority:  normal|   Milestone:  7.0.0   
 Component:  Default   | Version:  svn-releasebranch70 
Resolution:  wontfix   |Keywords:  r.out.gdal table attribute alignment
  Platform:  Linux | Cpu:  x86-64  
---+
Changes (by mmetz):

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


Comment:

 Replying to [ticket:2501 dnewcomb]:
 > Exporting integer grids with values starting with 1 using r.out.gdal -t
 results in a raster attribute table with vertically shifted values in the
 last 3 columns.

 In your example, the output is shifted in the first 2 columns. The last 3
 columns are correct. What software did you use? The faulty fields `OID`
 and `value` are added by this software.

 Here is an example using the NC sample dataset:

 {{{
 g.region -p rast=landclass96
 r.out.gdal in=landclass96 out=landclass96.tif -t
 }}}

 This creates a GeoTIFF with an associated file landclass96.tif.aux.xml
 holding the attribute table. The fields and first entry of this attribute
 table are
 {{{
 min, max, label
 1, 1, developed
 }}}
 all fine.

 According to `gdalinfo landclass96.tif`, the fields and first entry of
 this attribute table are
 {{{
 min, max, label
 1, 1, developed
 }}}
 all fine.

 Exporting landclass96 in Erdas Imagine format (`format=HFA`), there is no
 associated .xml file.

 According to `gdalinfo landclass96.img`, the fields and first entry of
 this attribute table are now
 {{{
 Red, Green, Blue, min, max, Class_Names
 0, 0, 0, 0, 1, 1, developed
 }}}

 this is wrong, a bug in GDAL.

 If GDAL itself is not able to correctly reproduce raster attribute tables
 created by itself, other software does not really have a chance to read
 raster attribute tables ay provided by GDAL. Further on, it seems that
 some other software further modifies the raster attribute table:

 It seems that raster attribute tables created by GDAL are not widely
 supported, if yes, errors might be introduced.

 Closing as wontfix because this is a problem of GDAL and GIS software
 other than GRASS.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] temporal framework currently not working on windows

[Anna Petrášová]

I just realized temporal framework doesn't work with recent GRASS 70
version on Windows:
t.list or t.create give me:

Traceback (most recent call last):
  File "", line 1, in 
  File "C:\GRASS70\GRASS GIS
7.0.0svn\Python27\lib\multiprocessing\forking.py", line 380,
in main
prepare(preparation_data)
  File "C:\GRASS70\GRASS GIS
7.0.0svn\Python27\lib\multiprocessing\forking.py", line 495,
in prepare
'__parents_main__', file, path_name, etc
  File "C:\GRASS70\GRASS GIS 7.0.0svn\scripts\t.create.py",
line 60, in 
import grass.temporal as tgis
  File "C:\GRASS70\GRASS GIS
7.0.0svn\etc\python\grass\temporal\__init__.py", line 29, in

from temporal_vector_algebra import *
  File "C:\GRASS70\GRASS GIS 7.0.0svn\etc\python\grass\tempo
ral\temporal_vector_algebra.py", line 422, in 
import grass.pygrass.modules as pygrass
  File "C:\GRASS70\GRASS GIS
7.0.0svn\etc\python\grass\pygrass\modules\__init__.py", line
2, in 
from grass.pygrass.modules.interface import Module,
ParallelModuleQueue
  File "C:\GRASS70\GRASS GIS 7.0.0svn\etc\python\grass\pygra
ss\modules\interface\__init__.py", line 9, in 
from grass.pygrass.modules.interface import module
  File "C:\GRASS70\GRASS GIS 7.0.0svn\etc\python\grass\pygra
ss\modules\interface\module.py", line 188, in 
class Module(object):
  File "C:\GRASS70\GRASS GIS 7.0.0svn\etc\python\grass\pygra
ss\modules\interface\module.py", line 591, in Module
@mdebug(1, extra=_get_bash)
  File "C:\GRASS70\GRASS GIS 7.0.0svn\etc\python\grass\pygra
ss\modules\interface\module.py", line 36, in mdebug
msgr = get_msgr()
  File "C:\GRASS70\GRASS GIS
7.0.0svn\etc\python\grass\pygrass\messages\__init__.py",
line 352, in get_msgr
_instance[0] = Messenger(*args, **kwargs)
  File "C:\GRASS70\GRASS GIS
7.0.0svn\etc\python\grass\pygrass\messages\__init__.py",
line 175, in __init__
self.start_server()
  File "C:\GRASS70\GRASS GIS
7.0.0svn\etc\python\grass\pygrass\messages\__init__.py",
line 185, in start_server
self.server.start()
  File "C:\GRASS70\GRASS GIS
7.0.0svn\Python27\lib\multiprocessing\process.py", line 130,
in start
self._popen = Popen(self)
  File "C:\GRASS70\GRASS GIS
7.0.0svn\Python27\lib\multiprocessing\forking.py", line 258,
in __init__
cmd = get_command_line() + [rhandle]
  File "C:\GRASS70\GRASS GIS
7.0.0svn\Python27\lib\multiprocessing\forking.py", line 358,
in get_command_line
is not going to be frozen to produce a Windows
executable.''')
RuntimeError:
Attempt to start a new process before the
current process
has finished its bootstrapping phase.
This probably means that you are on Windows and
you have
forgotten to use the proper idiom in the main
module:
if __name__ == '__main__':
freeze_support()
...
The "freeze_support()" line can be omitted if
the program
is not going to be frozen to produce a Windows
executable.

I tested with the most recent build and a user reports the same problem
with r62706.

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

Re: [GRASS-dev] sample vector temporal data

[Markus Neteler]

On Wed, Nov 26, 2014 at 8:22 PM, Anna Petrášová  wrote:
...
> yes, but there are no NC towns as points in the standard dataset.

There is a (small) geonames layer in the standard NC dataset which we
could add (updated).
But polygons would be better for zonal statistics.

...
> Helena suggests here to select a smaller, dynamic area (some cape for
> example) and also provide a DEM and ortho for that area (elev_lid792 is not
> coastal) to get some context. I am not sure about this dataset, if it's
> really needed, because I don't know what kind of temporal vector analysis we
> could show in the manual.

Derive contour lines from the LiDAR time series?
Another option is to enrich it with vectorized NLCD time series:

http://www.mrlc.gov/finddata.php
- National Land Cover Database 2011 (NLCD2011)
- National Land Cover Database 2006 (NLCD2006)
- National Land Cover Database 2001 (NLCD2001)
- National Land Cover Dataset 1992 (NLCD1992)


> Do we have any temporal data for 3d raster? I don't think we necessarily
> have to create this dataset.

3D point soil data would suffice...

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

Re: [GRASS-dev] sample vector temporal data

[Helena Mitasova]

On Nov 26, 2014, at 2:22 PM, Anna Petrášová wrote:
> On Wed, Nov 26, 2014 at 12:10 PM, Luca Delucchi  wrote:
> On 8 October 2014 at 03:21, Anna Petrášová  wrote:
> 
> > as you know we need to decide which data are we going to use for t.vect.*
> > examples. One possibility is to use oceanfront shorelines of North Carolina,
> > we can get this data easily from here:
> >
> > http://portal.ncdenr.org/web/cm/download-spatial-data-maps-oceanfront
> >
> > It includes these years, interval data in case of older data, and instance
> > data from the past years:
> > 1849 - 1873, 1925 - 1946, 1933 - 1952, 1940 - 1962, 1970 - 1988, 1997, 1998,
> > 2003, 2004, 2009
> >
> > The advantage is that the data is public and basically ready to use. If we
> > decide to use it, should we include the entire NC shoreline or just some
> > detail (look at the attachment)?
> >
> > In addition, we can also create a vector time-series where the geometry is
> > not changing, just the attribute changes (derived from the climate data for
> > example).
> >
> > Any thoughts on this?
> >
> 
> After some weeks without any comments I think we could proceed to
> create the dataset.
> 
> > By the way, the climate dataset seems to be fine, we got the confirmation we
> > can use it, it is not subject to the PRISM licence since it was interpolated
> > at NC State Climate Office.
> >
> 
> I would like to work on it and on temporal documentation in the next
> two days, so what do you think about this plan starting from the
> sample data for the temporal workshop [0]?
> - remove some years from climate_2000_2012 data, for example keep no
> more that 5 years, because right know the location is a little bit
> heavy (about 700MB) and for documentation 5 years should be fine.
> 
> I agree.
>  
> - create vector for static temporal dataset from towns querying the
> rasters in climate_2000_2012 to create something like virtual weather
> stations
> 
> yes, but there are no NC towns as points in the standard dataset. You could 
> use  precip_30ynormals@PERMANENT which are the meteorology stations, which 
> probably doesn't make much sense since but maybe it's still good for the 
> dataset. 

Anna is right - in fact these are the stations which were used to create the 
rasterized climate time series so there is no need to create 
virtual weather stations - we already have the real ones. We can get more 
complete data for these stations if needed 
- all have at least temperature and precipitation on daily basis going back 
several decades. 
> 
> - add the shoreline ocean data, maybe in a new mapset
> 
> Helena suggests here to select a smaller, dynamic area (some cape for 
> example) and also provide a DEM and ortho for that area (elev_lid792 is not 
> coastal) to get some context. I am not sure about this dataset, if it's 
> really needed, because I don't know what kind of temporal vector analysis we 
> could show in the manual. It could be a good dataset to show how to create 
> animations. If we decide to do it, I can help you with this part.
> 
> Another option is to derive contours from the temperature/precipitation 
> dataset. The advantage is that's easier to prepare.
> 
> - create at least one temporal dataset for each type (strds, str3ds, stvds)
> 
> Do we have any temporal data for 3d raster? I don't think we necessarily have 
> to create this dataset.

we can ask our colleagues for some 3D atmospheric data or the ocean temperature 
or salinity data,
but it would take us some time to get to this. We also have some good 
interpolated 3D/4D soil data but they are not public
at this point.

Helena

> 
> Anna 
> 
> - update the temporal documentation according the new dataset.
> 
> what do you think?
> 
> Helena in her answer was speaking about orthophoto and DEM for the
> shoreline ocean data, are this data already inside the location
> (elev_lid792_1m,elev_state_500m,ortho_t792_1m) ?
> 
> > Anna
> >
> 
> [0] http://fatra.cnr.ncsu.edu/temporal-grass-workshop/
> 
> --
> ciao
> Luca
> 
> http://gis.cri.fmach.it/delucchi/
> www.lucadelu.org
> 
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev

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

Re: [GRASS-dev] [GRASS GIS] #2439: g.gui.iclass crashes

[GRASS GIS]

#2439: g.gui.iclass crashes
---+
 Reporter:  madi   |   Owner:  grass-dev@…  

 Type:  defect |  Status:  new  

 Priority:  blocker|   Milestone:  7.1.0

Component:  wxGUI  | Version:  svn-trunk

 Keywords:  g.gui.iclass, classification, imagery  |Platform:  Linux

  Cpu:  x86-64 |  
---+

Comment(by mmetz):

 Replying to [comment:10 annakrat]:
 > See possible duplicate #2476.

 worksforme as of r63077. Please 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] #2501: r.out.gdal -t creates offset values in raster table for integer grids with values beginning with 1

[GRASS GIS]

#2501: r.out.gdal -t creates offset values in raster table for integer grids 
with
values beginning with 1
--+-
 Reporter:  dnewcomb  |   Owner:  grass-dev@…   
   
 Type:  defect|  Status:  new   
   
 Priority:  normal|   Milestone:  7.0.0 
   
Component:  Default   | Version:  
svn-releasebranch70  
 Keywords:  r.out.gdal table attribute alignment  |Platform:  Linux 
   
  Cpu:  x86-64|  
--+-

Comment(by dnewcomb):

 Sorry, example tables in a more readable format[[BR]]


 Expected Table:[[BR]]

 OID Value MIN MAX CLASS[[BR]]
 11 1   1  flat [[BR]]
 22 2   2  summit [[BR]]
 33 3   3  ridge [[BR]]
 44 4   4  shoulder [[BR]]
 55 5   5  spur
 [[BR]][[BR]]

 Current table:[[BR]][[BR]]


 OID Value MIN MAX CLASS [[BR]]
 00 1   1  flat [[BR]]
 11 2   2  summit [[BR]]
 22 3   3  ridge [[BR]]
 33 4   4  shoulder [[BR]]
 44 5   5  spur [[BR]]
 55 0   0  ERROR
 [[BR]]
 [[BR]]

 Hacked table:[[BR]][[BR]]

 OID Value MIN MAX CLASS [[BR]]
 0000   [[BR]]
 1111  flat [[BR]]
 2222  summit [[BR]]
 3333  ridge [[BR]]
 4444  shoulder [[BR]]
 5555  spur

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] sample vector temporal data

[Anna Petrášová]

On Wed, Nov 26, 2014 at 12:10 PM, Luca Delucchi 
wrote:

> On 8 October 2014 at 03:21, Anna Petrášová  wrote:
> > Hi,
> >
>
> Hi,
>
> > as you know we need to decide which data are we going to use for t.vect.*
> > examples. One possibility is to use oceanfront shorelines of North
> Carolina,
> > we can get this data easily from here:
> >
> > http://portal.ncdenr.org/web/cm/download-spatial-data-maps-oceanfront
> >
> > It includes these years, interval data in case of older data, and
> instance
> > data from the past years:
> > 1849 - 1873, 1925 - 1946, 1933 - 1952, 1940 - 1962, 1970 - 1988, 1997,
> 1998,
> > 2003, 2004, 2009
> >
> > The advantage is that the data is public and basically ready to use. If
> we
> > decide to use it, should we include the entire NC shoreline or just some
> > detail (look at the attachment)?
> >
> > In addition, we can also create a vector time-series where the geometry
> is
> > not changing, just the attribute changes (derived from the climate data
> for
> > example).
> >
> > Any thoughts on this?
> >
>
> After some weeks without any comments I think we could proceed to
> create the dataset.
>
> > By the way, the climate dataset seems to be fine, we got the
> confirmation we
> > can use it, it is not subject to the PRISM licence since it was
> interpolated
> > at NC State Climate Office.
> >
>
> I would like to work on it and on temporal documentation in the next
> two days, so what do you think about this plan starting from the
> sample data for the temporal workshop [0]?
> - remove some years from climate_2000_2012 data, for example keep no
> more that 5 years, because right know the location is a little bit
> heavy (about 700MB) and for documentation 5 years should be fine.
>

I agree.


> - create vector for static temporal dataset from towns querying the
> rasters in climate_2000_2012 to create something like virtual weather
> stations
>

yes, but there are no NC towns as points in the standard dataset. You could
use  precip_30ynormals@PERMANENT which are the meteorology stations, which
probably doesn't make much sense since but maybe it's still good for the
dataset.

- add the shoreline ocean data, maybe in a new mapset
>

Helena suggests here to select a smaller, dynamic area (some cape for
example) and also provide a DEM and ortho for that area (elev_lid792 is not
coastal) to get some context. I am not sure about this dataset, if it's
really needed, because I don't know what kind of temporal vector analysis
we could show in the manual. It could be a good dataset to show how to
create animations. If we decide to do it, I can help you with this part.

Another option is to derive contours from the temperature/precipitation
dataset. The advantage is that's easier to prepare.

- create at least one temporal dataset for each type (strds, str3ds, stvds)
>

Do we have any temporal data for 3d raster? I don't think we necessarily
have to create this dataset.

Anna

- update the temporal documentation according the new dataset.
>
> what do you think?
>
> Helena in her answer was speaking about orthophoto and DEM for the
> shoreline ocean data, are this data already inside the location
> (elev_lid792_1m,elev_state_500m,ortho_t792_1m) ?
>
> > Anna
> >
>
> [0] http://fatra.cnr.ncsu.edu/temporal-grass-workshop/
>
> --
> ciao
> Luca
>
> http://gis.cri.fmach.it/delucchi/
> www.lucadelu.org
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] check on GRASS revision number

[Michael Barton]

For any version of GRASS for which there is any reasonable development, all 
binary extensions will be out of date as soon as the first update is made. So 
they all will need to be recompiled. Why do we need to do this? Most will work 
fine without recompiling.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu















On Nov 26, 2014, at 12:10 PM, Markus Neteler 
mailto:nete...@osgeo.org>> wrote:


On Nov 26, 2014 8:02 PM, "Michael Barton" 
mailto:michael.bar...@asu.edu>> wrote:
>
> Will this be the case for all extensions built against a revision of current 
> - 1?

Today yes, due to an API change in libgis.

> If so, then there is no point in installing any binary module.

Why?

As soon as G7 is stable these changes will unlikely or at least only very 
rarely occur.

Markus

> Michael
> 
> C. Michael Barton
> Director, Center for Social Dynamics & Complexity
> Professor of Anthropology, School of Human Evolution & Social Change
> Head, Graduate Faculty in Complex Adaptive Systems Science
> Arizona State University
>
> voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
> fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
> www: http://www.public.asu.edu/~cmbarton, 
> http://csdc.asu.edu
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Nov 26, 2014, at 11:51 AM, Martin Landa 
> mailto:landa.mar...@gmail.com>> wrote:
>
> > Hi,
> >
> > 2014-11-26 19:32 GMT+01:00 Michael Barton 
> > mailto:michael.bar...@asu.edu>>:
> >> ERROR: Module built against version $Revision: 61095 $ but trying to use
> >>   version $Revision: 62364 $. You need to rebuild GRASS GIS or
> >>   untangle multiple installations.
> >
> > you need to rebuild extension
> >
> > g.extension.all ope=rebuild
> >
> > Martin
> >
> > --
> > Martin Landa
> > http://geo.fsv.cvut.cz/gwiki/Landa
> > http://gismentors.eu/mentors/landa
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev

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

Re: [GRASS-dev] check on GRASS revision number

[Markus Neteler]

On Nov 26, 2014 8:02 PM, "Michael Barton"  wrote:
>
> Will this be the case for all extensions built against a revision of
current - 1?

Today yes, due to an API change in libgis.

> If so, then there is no point in installing any binary module.

Why?

As soon as G7 is stable these changes will unlikely or at least only very
rarely occur.

Markus

> Michael
> 
> C. Michael Barton
> Director, Center for Social Dynamics & Complexity
> Professor of Anthropology, School of Human Evolution & Social Change
> Head, Graduate Faculty in Complex Adaptive Systems Science
> Arizona State University
>
> voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
> fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Nov 26, 2014, at 11:51 AM, Martin Landa  wrote:
>
> > Hi,
> >
> > 2014-11-26 19:32 GMT+01:00 Michael Barton :
> >> ERROR: Module built against version $Revision: 61095 $ but trying to
use
> >>   version $Revision: 62364 $. You need to rebuild GRASS GIS or
> >>   untangle multiple installations.
> >
> > you need to rebuild extension
> >
> > g.extension.all ope=rebuild
> >
> > Martin
> >
> > --
> > Martin Landa
> > http://geo.fsv.cvut.cz/gwiki/Landa
> > http://gismentors.eu/mentors/landa
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1242: vector fills and line widths not displaying in latlon regions

[GRASS GIS]

#1242: vector fills and line widths not displaying in latlon regions
-+--
 Reporter:  cmbarton |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  critical |   Milestone:  7.0.0
Component:  Display  | Version:  svn-trunk
 Keywords:  vector, display, d.vect  |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by cmbarton):

 But did you try dragging the north arrow to the left to see if there is a
 duplicate? See the attached screenshot from version 62850.

 Michael

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] check on GRASS revision number

[Michael Barton]

Will this be the case for all extensions built against a revision of current - 
1? 

If so, then there is no point in installing any binary module.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity 
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu















On Nov 26, 2014, at 11:51 AM, Martin Landa  wrote:

> Hi,
> 
> 2014-11-26 19:32 GMT+01:00 Michael Barton :
>> ERROR: Module built against version $Revision: 61095 $ but trying to use
>>   version $Revision: 62364 $. You need to rebuild GRASS GIS or
>>   untangle multiple installations.
> 
> you need to rebuild extension
> 
> g.extension.all ope=rebuild
> 
> Martin
> 
> -- 
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.eu/mentors/landa

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

[GRASS-dev] [GRASS GIS] #2501: r.out.gdal -t creates offset values in raster table for integer grids with values beginning with 1

[GRASS GIS]

#2501: r.out.gdal -t creates offset values in raster table for integer grids 
with
values beginning with 1
--+-
 Reporter:  dnewcomb  |   Owner:  grass-dev@…   
   
 Type:  defect|  Status:  new   
   
 Priority:  normal|   Milestone:  7.0.0 
   
Component:  Default   | Version:  
svn-releasebranch70  
 Keywords:  r.out.gdal table attribute alignment  |Platform:  Linux 
   
  Cpu:  x86-64|  
--+-
 Exporting integer grids with values starting with 1 using r.out.gdal -t
 results in a raster attribute table with vertically shifted values in the
 last 3 columns.
 For example, if you have a raster with values of 1 to 5 with associated
 classes, you would expect a table that looks like this:
 OID Value MIN MAX CLASS
 1 11   1   flat
 2 22   2   summit
 3 33   3   ridge
 4 44   4   shoulder
 5 55   5   spur

 ( Should the OID start with 0?, not sure )

 In the current version of the software, the output table looks like this:
 OID Value MIN  MAX CLASS
 00 11flat
 11 22summit
 22 33ridge
 33 44shoulder
 44 55spur
 55 00ERROR

 See http://lists.osgeo.org/pipermail/grass-dev/2014-November/072021.html,

 The issue seems to be in lines 73 - 78 in r.out.gdal/attr.c:

 if (maptype == CELL_TYPE) {
   for (i = 0; i < cats.ncats; i++) {
 label = Rast_get_ith_c_cat(&cats, i, &CellMin, &CellMax);
 GDALRATSetValueAsInt(hrat, i, 0, CellMin);
 GDALRATSetValueAsInt(hrat, i, 1, CellMax);
 GDALRATSetValueAsString(hrat, i, 2, label);

 With this current ugly hack I've got has the values aligned with the
 classes again, but there is an extra OID 0 line with 0 or blank values for
 the fields at the beginning of the table.

 if (maptype == CELL_TYPE) {
   for (i = 0; i < cats.ncats-1; i++) {
 label = Rast_get_ith_c_cat(&cats, i, &CellMin, &CellMax);
 GDALRATSetValueAsInt(hrat, i+1, 0, CellMin);
 GDALRATSetValueAsInt(hrat, i+1, 1, CellMax);
 GDALRATSetValueAsString(hrat, i+1, 2, label);

 Sample output to this hack would be:
 OID Value MIN MAX CLASS
 0 00   0
 1 11   1   flat
 2 22   2   summit
 3 33   3   ridge
 4 44   4   shoulder
 5 55   5   spur

 This does not look quite right.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] check on GRASS revision number

[Martin Landa]

Hi,

2014-11-26 19:32 GMT+01:00 Michael Barton :
> ERROR: Module built against version $Revision: 61095 $ but trying to use
>version $Revision: 62364 $. You need to rebuild GRASS GIS or
>untangle multiple installations.

you need to rebuild extension

g.extension.all ope=rebuild

Martin

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

Re: [GRASS-dev] [GRASS GIS] #580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run

[GRASS GIS]

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---+
  Reporter:  hamish|   Owner:  grass-dev@…  
  Type:  defect|  Status:  reopened 
  Priority:  blocker   |   Milestone:  7.0.0
 Component:  wxGUI | Version:  svn-trunk
Resolution:|Keywords:  wingrass 
  Platform:  MSWindows XP  | Cpu:  Unspecified  
---+

Comment(by martinl):

 Replying to [comment:59 martinl]:

 > right, thanks, it helped, see r62955-6.

 r62055 produces for GUI scripts (`d.rast3d` and `d.wms`) the BAT files.
 But when adding a new 3D raster map to the GUI it seems that instead of
 BAT file is launched PY file. I removed PY from PATHEXT in r63160, but it
 had no effect. Is there any way how to force launching BAT wrappers
 instead of PY scripts? Or it must be placed in different directories?

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] check on GRASS revision number

[Michael Barton]

In the new trunk GRASS 7.1, I’m running into an error check like the following:

GRASS 7.1.svn (Penaguila):~ > r.flip &
[1] 76586
ERROR: Module built against version $Revision: 61095 $ but trying to use
   version $Revision: 62364 $. You need to rebuild GRASS GIS or
   untangle multiple installations.
[1]+  Exit 1  r.flip


There is some value to this, but it may create more problems than it solves. As 
a test of what is happening to missing addons path, I installed from the GRASS 
7 extensions library the module r.flip. While it is possible that r.flip will 
not work with revision 62364, many modules built for other revisions of the 
same GRASS version WILL work with a newer version. This is especially true with 
a lot of development work going on.

 A binary module is almost guaranteed to be built with a revision that predates 
the current one. Perhaps a warning is warranted but to prevent this from 
running seems extreme.

Michael



C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu















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

Re: [GRASS-dev] G7: turning manual page examples into test cases

[Moskovitz, Bob@DOC]

This almost sound like the PostGIS Garden Test: 
http://trac.osgeo.org/postgis/wiki/DevWikiGardenTest


Robert Moskovitz
California Geological Survey
Seismic Hazards Zonation Program

CONFIDENTIALITY NOTICE: This communication is intended only for the use of the 
individual or entity to which it is addressed. This message contains 
information from the State of California, California Geological Survey, which 
may be privileged, confidential and exempt from disclosure under applicable 
law, including the Electronic Communications Privacy Act. If the reader of this 
communication is not the intended recipient, you are hereby notified that any 
dissemination, distribution, or copying of this communication is strictly 
prohibited.



-Original Message-
From: grass-dev-boun...@lists.osgeo.org 
[mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Markus Neteler
Sent: Wednesday, November 26, 2014 7:45 AM
To: GRASS developers list
Subject: [GRASS-dev] G7: turning manual page examples into test cases

Hi,

in the recent past I added a series of examples to various manual
pages. Most of them might qualify for (basic) testing of the
respective command.
Since it is a bit time consuming to write these standard tests
manually, would there be a chance to develop a test case generator
e.g. driven by a template?

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

Re: [GRASS-dev] sample vector temporal data

[Moritz Lennert]

On 26/11/14 18:10, Luca Delucchi wrote:

On 8 October 2014 at 03:21, Anna Petrášová  wrote:

Hi,



Hi,


as you know we need to decide which data are we going to use for t.vect.*
examples. One possibility is to use oceanfront shorelines of North Carolina,
we can get this data easily from here:

http://portal.ncdenr.org/web/cm/download-spatial-data-maps-oceanfront

It includes these years, interval data in case of older data, and instance
data from the past years:
1849 - 1873, 1925 - 1946, 1933 - 1952, 1940 - 1962, 1970 - 1988, 1997, 1998,
2003, 2004, 2009

The advantage is that the data is public and basically ready to use. If we
decide to use it, should we include the entire NC shoreline or just some
detail (look at the attachment)?

In addition, we can also create a vector time-series where the geometry is
not changing, just the attribute changes (derived from the climate data for
example).

Any thoughts on this?



After some weeks without any comments I think we could proceed to
create the dataset.


By the way, the climate dataset seems to be fine, we got the confirmation we
can use it, it is not subject to the PRISM licence since it was interpolated
at NC State Climate Office.



I would like to work on it and on temporal documentation in the next
two days, so what do you think about this plan starting from the
sample data for the temporal workshop [0]?
- remove some years from climate_2000_2012 data, for example keep no
more that 5 years, because right know the location is a little bit
heavy (about 700MB) and for documentation 5 years should be fine.


+1


- create vector for static temporal dataset from towns querying the
rasters in climate_2000_2012 to create something like virtual weather
stations


Not sure what you mean by static temporal dataset ? Why do we need this 
in addition to the below shoreline data ?



- add the shoreline ocean data, maybe in a new mapset


+1, including for separate mapset


- create at least one temporal dataset for each type (strds, str3ds, stvds)


+1, but as you say yourself, be careful about mapset size !


- update the temporal documentation according the new dataset.
what do you think?


Sounds good to me.

Thanks a lot for taking care of this !

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

Re: [GRASS-dev] [GRASS GIS] #580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run

[GRASS GIS]

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---+
  Reporter:  hamish|   Owner:  grass-dev@…  
  Type:  defect|  Status:  reopened 
  Priority:  blocker   |   Milestone:  7.0.0
 Component:  wxGUI | Version:  svn-trunk
Resolution:|Keywords:  wingrass 
  Platform:  MSWindows XP  | Cpu:  Unspecified  
---+

Comment(by martinl):

 Replying to [comment:57 martinl]:
 > Replying to [comment:55 hellik]:
 > > suggest to close the ticket as scripts are now working in winGRASS. at
 least downgrading priority if ticket should stay open.
 >
 > before that we need to fix makefiles to produce also bat files from
 `g.gui.*` modules and GUI scripts (see my comment above).

 done in r62956, but it's not working - attempt to launch `g.gui.animation`
 from cmdline:

 {{{
 C:\>Traceback (most recent call last):
   File "", line 1, in 
   File "C:\OSGEO4~1\apps\Python27\lib\multiprocessing\forking.py", line
 381, in
 main
 self = load(from_parent)
   File "C:\OSGEO4~1\apps\Python27\lib\pickle.py", line 1378, in load
 return Unpickler(file).load()
   File "C:\OSGEO4~1\apps\Python27\lib\pickle.py", line 858, in load
 dispatch[key](self)
   File "C:\OSGEO4~1\apps\Python27\lib\pickle.py", line 1090, in
 load_global
 klass = self.find_class(module, name)
   File "C:\OSGEO4~1\apps\Python27\lib\pickle.py", line 1124, in find_class
 __import__(module)
   File
 "C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\temporal\__init__.
 py", line 28, in 
 from temporal_algebra import *
   File
 "C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\temporal\temporal_
 algebra.py", line 450, in 
 import grass.pygrass.modules as pymod
   File
 "C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\pygrass\modules\__
 init__.py", line 2, in 
 from grass.pygrass.modules.interface import Module,
 ParallelModuleQueue
   File
 "C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\pygrass\modules\in
 terface\__init__.py", line 9, in 
 from grass.pygrass.modules.interface import module
   File
 "C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\pygrass\modules\in
 terface\module.py", line 297, in 
 class Module(object):
   File
 "C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\pygrass\modules\in
 terface\module.py", line 700, in Module
 @mdebug(1, extra=_get_bash)
   File
 "C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\pygrass\modules\in
 terface\module.py", line 36, in mdebug
 msgr = get_msgr()
   File
 "C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\pygrass\messages\_
 _init__.py", line 352, in get_msgr
 _instance[0] = Messenger(*args, **kwargs)
   File
 "C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\pygrass\messages\_
 _init__.py", line 175, in __init__
 self.start_server()
   File
 "C:\OSGEO4~1\apps\grass\grass-7.1.svn\etc\python\grass\pygrass\messages\_
 _init__.py", line 185, in start_server
 self.server.start()
   File "C:\OSGEO4~1\apps\Python27\lib\multiprocessing\process.py", line
 130, in
 start
 self._popen = Popen(self)
   File "C:\OSGEO4~1\apps\Python27\lib\multiprocessing\forking.py", line
 258, in
 __init__
 cmd = get_command_line() + [rhandle]
   File "C:\OSGEO4~1\apps\Python27\lib\multiprocessing\forking.py", line
 358, in
 get_command_line
 is not going to be frozen to produce a Windows executable.''')
 RuntimeError:
 Attempt to start a new process before the current process
 has finished its bootstrapping phase.
 }}}

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] sample vector temporal data

[Luca Delucchi]

On 8 October 2014 at 03:21, Anna Petrášová  wrote:
> Hi,
>

Hi,

> as you know we need to decide which data are we going to use for t.vect.*
> examples. One possibility is to use oceanfront shorelines of North Carolina,
> we can get this data easily from here:
>
> http://portal.ncdenr.org/web/cm/download-spatial-data-maps-oceanfront
>
> It includes these years, interval data in case of older data, and instance
> data from the past years:
> 1849 - 1873, 1925 - 1946, 1933 - 1952, 1940 - 1962, 1970 - 1988, 1997, 1998,
> 2003, 2004, 2009
>
> The advantage is that the data is public and basically ready to use. If we
> decide to use it, should we include the entire NC shoreline or just some
> detail (look at the attachment)?
>
> In addition, we can also create a vector time-series where the geometry is
> not changing, just the attribute changes (derived from the climate data for
> example).
>
> Any thoughts on this?
>

After some weeks without any comments I think we could proceed to
create the dataset.

> By the way, the climate dataset seems to be fine, we got the confirmation we
> can use it, it is not subject to the PRISM licence since it was interpolated
> at NC State Climate Office.
>

I would like to work on it and on temporal documentation in the next
two days, so what do you think about this plan starting from the
sample data for the temporal workshop [0]?
- remove some years from climate_2000_2012 data, for example keep no
more that 5 years, because right know the location is a little bit
heavy (about 700MB) and for documentation 5 years should be fine.
- create vector for static temporal dataset from towns querying the
rasters in climate_2000_2012 to create something like virtual weather
stations
- add the shoreline ocean data, maybe in a new mapset
- create at least one temporal dataset for each type (strds, str3ds, stvds)
- update the temporal documentation according the new dataset.

what do you think?

Helena in her answer was speaking about orthophoto and DEM for the
shoreline ocean data, are this data already inside the location
(elev_lid792_1m,elev_state_500m,ortho_t792_1m) ?

> Anna
>

[0] http://fatra.cnr.ncsu.edu/temporal-grass-workshop/

-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] planning grass 7.0.0beta4

[Vaclav Petras]

On Wed, Nov 26, 2014 at 8:33 AM, Markus Neteler  wrote:

> > It would be great if we could automatically test all the changes that
> > i have introduced in the release branch using the testsuite.
>
> Do you mean "online" on a server?


I believe Soeren means by running the tests (in any way) as opposed to
running some commands manually. There is no point in waiting for some
server to run the tests the next day when you can run them yourself before
the commit.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] test scripts in the path

[Vaclav Petras]

On Wed, Nov 26, 2014 at 11:07 AM, Martin Landa 
wrote:

> Hi,
>
> is it need to have such script in the path?
>
> test.r3flowtest.raster3d.lib
>
>
Honestly, I don't know.

This is one of the issues why I'm hesitating to backport the testing. I'm
not sure how much this was discussed on mailing list so far; we had some
discussions with Soeren; there should be something on the GSoC wiki (search
e.g. for MS Windows):

http://trac.osgeo.org/grass/wiki/GSoC/2014/TestingFrameworkForGRASS
http://trac.osgeo.org/grass/wiki/GSoC/2014/TestingFrameworkForGRASS#TestingonMSWindows

The main problem is that these are not scripts but binaries, so you need to
get them compiled somehow. This could be (relatively) easy on Linux but
impossible for users on MS Windows.

Vaclav

Martin
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.eu/mentors/landa
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] g.list sorting and mapset issues

[Markus Neteler]

hi,

the updated g.list in G7 still has two issues:

1) when identical map names exist in the current and an/other
mapset(s), the @mapset should be always printed (even if current):

GRASS 7.1.svn (nc_spm_08_grass7):~ > g.list rast | grep
lsat5_1987_div__pielou_size_5
lsat5_1987_div__pielou_size_5.0
lsat5_1987_div__pielou_size_5.0@landsat


2) The default output should be sorted:

GRASS 7.1.svn (nc_spm_08_grass7):~ > g.list rast
...
lsat7_2002_61
lsat7_2002_62
lsat7_2002_70
lsat7_2002_80
ncmask_500m
ortho_2001_t792_1m
roadsmajor
slope
soilsID
soils_Kfactor
streams_derived
towns
urban
zipcodes
zipcodes_dbl
lsat5_1987_10
lsat5_1987_20
lsat5_1987_30
--> unsorted (in fact, likely sorted by mapset but then concatenated).

That needs to be changed here:

g.list/main.c, line 343
for (j = 0; (mapset = G_get_mapset_name(j)); j++)
make_list(fp, elem, mapset, separator, flag.type->answer,
  flag.mapset->answer, use_region ? &window : NULL);

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

Re: [GRASS-dev] G7: turning manual page examples into test cases

[Vaclav Petras]

On Wed, Nov 26, 2014 at 10:44 AM, Markus Neteler  wrote:

> Hi,
>
> in the recent past I added a series of examples to various manual
> pages. Most of them might qualify for (basic) testing of the
> respective command.
>

I totally agree. I have the same idea in my mind for some time and I would
really like to see use it but I had no time to implement it.

For basic functionality can be implemented quite simply since the testing
framework supports bash/sh files. You extract the code from the manual page
into a .sh file, put all these files into proper  directories (the are more
options what proper is), and then you can run test running script on this
directory structure instead of the source code. However, this approach will
not work on MS Windows but there are some possible adjustments (for
example, different language tabs and/or (limited) automatic conversion [1]).

What is the challenge and what requires some thinking is how to test the
results and what to do with d.* commands. Not test the results and remove
d.* commands seems like a good option for start.

This would be a nice analogy to Python doctest which also points us towards
the fact that main purpose of this (and doctest) should be testing of
documentation rather then using documentation for testing (or instead of
testing). In other words, I think that purpose of this is to find out if
the examples are still valid (modules and options exist and map names are
not wrong). As a bonus this will test if the module starts and in some
cases it might test if the expected maps were created.


> Since it is a bit time consuming to write these standard tests
> manually, would there be a chance to develop a test case generator
> e.g. driven by a template?
>
> Can you tell more about your idea? It seems much more advanced than the
basic approach I'm suggesting.

Thanks for bringing this up,
Vashek

[1] http://fatra.cnr.ncsu.edu/temporal-grass-workshop/

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

Re: [GRASS-dev] [GRASS-SVN] r62026 - in grass/trunk: display/d.info include/defs lib/display

[Markus Neteler]

On Thu, Sep 18, 2014 at 12:43 AM,   wrote:
> Author: glynn
> Date: 2014-09-17 15:43:22 -0700 (Wed, 17 Sep 2014)
> New Revision: 62026
>
> Modified:
>grass/trunk/display/d.info/main.c
>grass/trunk/include/defs/display.h
>grass/trunk/lib/display/r_raster.c
>grass/trunk/lib/display/setup.c
> Log:
> Change handling of display frame, graphical clip window
>  Replace D_get_window with D_get_frame
>  Add D_get_clip_window, D_set_clip_window
>  Add D_set_clip_window_to_map_window, D_set_clip_window_to_screen_window
>  Store initial frame size within display library
>  Change D_setup* functions to set graphical clip window
>

Should this be backported to relbr7?

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

[GRASS-dev] test scripts in the path

[Martin Landa]

Hi,

is it need to have such script in the path?

test.r3flowtest.raster3d.lib

Martin

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

[GRASS-dev] G7: turning manual page examples into test cases

[Markus Neteler]

Hi,

in the recent past I added a series of examples to various manual
pages. Most of them might qualify for (basic) testing of the
respective command.
Since it is a bit time consuming to write these standard tests
manually, would there be a chance to develop a test case generator
e.g. driven by a template?

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

Re: [GRASS-dev] planning grass 7.0.0beta4

[Anna Petrášová]

On Wed, Nov 26, 2014 at 8:48 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> On 26/11/14 14:33, Markus Neteler wrote:
>
>> On Sun, Nov 23, 2014 at 12:54 AM, Sören Gebbert
>>  wrote:
>>
>>> Backport done in r62858 - r62867.
>>> I hope everything works fine.
>>>
>>
>> Great, thanks for your efforts!
>>
>>  It would be great if we could automatically test all the changes that
>>> i have introduced in the release branch using the testsuite.
>>>
>>
>> Do you mean "online" on a server?
>>
>>  A "make distclean" is needed.
>>>
>>
>> Martin is currently going through the parameters for
>> http://trac.osgeo.org/grass/ticket/2409
>>
>> Then we might be ready for beta4 by end of this week.
>>
>
> I still think that #2439 (and its duplicate #2476) is an almost blocker.
> Digitization is a fundamental tool and these crashes render it almost
> unusable for the normal(uninformed) user.
>
> Anyone out there with sufficient knowlege of GUI and vector code to check
> this ?


I tried but failed, I don't understand the vector library structures
enough. As far as I remember, I identified the place where it crashes, if
that helps. So probably either Martin or Markus Metz would be able to fix
it.

Anna


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

Re: [GRASS-dev] [GRASS GIS] #2476: vector digitizer crashing with _breakLineAtIntersection

[GRASS GIS]

#2476: vector digitizer crashing with _breakLineAtIntersection
-+--
 Reporter:  annakrat |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  vdigit   |Platform:  Linux
  Cpu:  Unspecified  |  
-+--

Comment(by mmetz):

 Replying to [comment:1 mmetz]:
 > Replying to [ticket:2476 annakrat]:
 > > Crashing happens in
 
[http://trac.osgeo.org/grass/browser/grass/trunk/lib/vector/Vlib/level_two.c#L356
 level_two.c] in wxdigit.py in _addFeature. Without the line, the area
 closes without problem, so maybe _breakLineAtIntersection is where
 something goes wrong.
 >
 > The problem is in
 
[https://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/vdigit/wxdigit.py#L1772
 wxdigit.py] in _addFeature: the line is broken, afterwards the digitizer
 tries to get the areas for this line. But this line no longer exists
 because it has been broken into new lines -> crash.
 >
 > You would need to get areas on each side before breaking the line, but
 the vector lib might only be able to build areas after the new line was
 broken. I would suggest to break the line only after trying to attach
 centroids.

 Fixed in r63077.

-- 
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] #2476: vector digitizer crashing with _breakLineAtIntersection

[GRASS GIS]

#2476: vector digitizer crashing with _breakLineAtIntersection
-+--
 Reporter:  annakrat |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  vdigit   |Platform:  Linux
  Cpu:  Unspecified  |  
-+--

Comment(by mmetz):

 Replying to [ticket:2476 annakrat]:
 > Crashing happens in
 
[http://trac.osgeo.org/grass/browser/grass/trunk/lib/vector/Vlib/level_two.c#L356
 level_two.c] in wxdigit.py in _addFeature. Without the line, the area
 closes without problem, so maybe _breakLineAtIntersection is where
 something goes wrong.

 The problem is in
 
[https://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/vdigit/wxdigit.py#L1772
 wxdigit.py] in _addFeature: the line is broken, afterwards the digitizer
 tries to get the areas for this line. But this line no longer exists
 because it has been broken into new lines -> crash.

 You would need to get areas on each side before breaking the line, but the
 vector lib might only be able to build areas after the new line was
 broken. I would suggest to break the line only after trying to attach
 centroids.

-- 
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] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by annakrat):

 Replying to [comment:30 glynn]:
 > Replying to [comment:27 annakrat]:
 > > I will change r.colors options (raster -> rast, volume -> rast3d)
 unless someone is against, sometime soon.
 >
 > "raster" shouldn't be abbreviated. "volume" should probably be
 "raster_3d" (for which "raster3d" and "rast3d" are accepted
 abbreviations).

 I don't like "raster_3d". If we rename "rast" to "raster", which seems
 reasonable, I would go with "raster3d", even though you can't shorten 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] #2256: No projection for web service layer

[GRASS GIS]

#2256: No projection for web service layer
+---
 Reporter:  martinl |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  major   |   Milestone:  7.0.0
Component:  Default | Version:  svn-trunk
 Keywords:  wxGUI, web service  |Platform:  Unspecified  
  Cpu:  Unspecified |  
+---

Comment(by martinl):

 Seems to be fixed in r62980. Tested in wxGUI, seems to work. Please
 backport it to G70 before closing this ticket.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] On i.atcorr support for WorldView2, QB2

[Nikos Alexandris]

Is there anyone willing to check ticket #2059 out? [0]

I am attaching an `R` session through which I obtained the numbers fed 
to `create_iwave.py` for the template creation.


Is there, perhaps, important to keep the band-width order (instead of 
the band numbering in delivered products)? Maybe Nikos Ves' approach is 
right for Landsat8 [1] which follows the band-width order (and not the 
official band designation) works (for me) correctly.


Nikos A

[0] ?
[1] # Data scrapped from 

band.1 <- c( 1.93924e-06, 3.33156e-06, 3.2732e-06, 2.78199e-06, 1.7488e-06, 
3.34801e-06,3.55785e-06, 4.38919e-06, 2.94112e-06, 6.21317e-06, 5.37163e-06, 
5.00497e-06,7.41645e-06, 1.35004e-05, 4.53797e-05, 0.000173069, 0.000634651, 
0.00341498,0.0274284, 0.132903, 0.355988, 0.59258, 0.700719, 
0.739625,0.765307, 0.787842, 0.817088, 0.838687, 0.86178, 0.883513,0.905055, 
0.917072, 0.927208, 0.947658, 0.965088, 0.979304,0.985921, 0.989094, 0.997236, 
0.974613, 0.85394, 0.588032,0.281577, 0.0805215, 0.00894615, 0.00133307, 
0.0003609, 0.000145392,7.12168e-05, 3.80253e-05, 1.15412e-05, 9.59192e-06, 
5.14417e-06, 1.11808e-05,1.09998e-05, 1.07851e-05, 9.08862e-06, 1.0105e-05, 
1.17289e-05, 6.3851e-06,1.30646e-06, 1.3751e-06, 8.62503e-07, 6.19172e-07, 
7.02247e-07, 8.87865e-07,9.3924e-07, 1.11657e-06, 9.84522e-07, 7.45006e-07, 
8.99363e-07, 1.24448e-06,3.62747e-06, 1.27768e-06, 4.00518e-07, 5.21386e-07, 
2.69075e-07, 4.85233e-07,3.69503e-07, 1.25632e-05, 0.00014168, 2.39565e-06, 
3.06503e-07, 2.7473e-07,5.19969e-07, 4.87974e-07, 2.69412e-07, 3.10803e-07, 
6.51482e-08, 1.769e-10,2.06764e-07, 1.56239e-06, 1.71434e-06, 3.76485e-07, 
9.78272e-08, 1.07281e-07,5.25843e-07, 2.86289e-06, 4.49334e-06, 2.7912e-06, 
9.77366e-07, 1.65592e-06,1.25872e-06, 1.35006e-06, 2.26827e-06, 3.08804e-06, 
6.08055e-06, 1.15782e-05,1.00862e-05, 5.55949e-06, 3.85934e-06, 3.17286e-06, 
2.67182e-06, 3.11772e-06,2.48961e-06, 2.56662e-06, 2.69687e-06, 2.66657e-06, 
2.49631e-06, 2.07413e-06,2.21763e-06, 1.82216e-06, 1.73999e-06, 1.79846e-06, 
1.78097e-06, 2.08078e-06,2.41026e-06, 2.95564e-06, 4.37817e-06, 9.26286e-06, 
1.71525e-05, 1.63404e-05,7.76378e-06, 4.20687e-06, 4.36152e-06, 4.1979e-06, 
3.60385e-06, 4.21227e-06,6.61165e-06, 1.85337e-05, 2.63714e-05, 1.23596e-05, 
8.08582e-06, 7.62016e-06,8.54114e-06, 9.63216e-06, 1.21937e-05, 2.92224e-05, 
9.75796e-05, 9.35745e-05,3.33406e-05, 2.37882e-05, 2.9829e-05, 4.42465e-05, 
6.68887e-05, 0.000152608,0.000422651, 0.000256325, 6.52584e-05, 4.13991e-05, 
5.7842e-05, 0.000264601,0.000711195, 0.000441052, 8.93762e-05, 3.04976e-05, 
1.31372e-05, 8.13006e-06,5.95634e-06, 5.94402e-06, 6.95574e-06, 1.12493e-05, 
1.93408e-05, 3.30614e-05,5.526e-05, 0.000106194, 0.000246237, 0.000245793, 
0.000116183, 6.90781e-05,0.000121558, 0.00012478, 0.000160506, 0.000195856, 
0.000163724, 0.000116846,9.27976e-05, 7.97493e-05, 7.30327e-05, 6.2535e-05, 
7.15964e-05, 6.92402e-05,6.98667e-05, 7.20625e-05, 5.92742e-05, 4.73751e-05, 
5.11686e-05, 3.8765e-05,2.87346e-05, 2.82287e-05, 4.23112e-05, 2.84265e-05, 
2.76262e-05, 3.13753e-05,3.20692e-05, 2.54603e-05, 1.55049e-05, 1.67992e-05, 
1.51677e-05, 1.72863e-05,1.82755e-05, 1.62912e-05, 1.63329e-05, 2.11384e-05, 
1.68083e-05, 1.32225e-05,9.90909e-06, 9.57385e-06, 9.22475e-06, 1.59785e-05, 
1.89273e-05, 1.94756e-05,1.68079e-05, 1.52813e-05, 1.45048e-05, 1.12089e-05, 
9.50048e-06, 7.40732e-06,6.16214e-06, 4.66982e-06, 4.04122e-06, 3.96966e-06, 
3.02326e-06, 3.30965e-06,2.53001e-06, 3.00426e-06, 3.01337e-06, 3.36385e-06, 
3.56402e-06, 4.18688e-06,4.12602e-06, 5.01737e-06, 5.44329e-06, 5.985e-06, 
5.40637e-06, 6.44899e-06,5.42357e-06, 4.91412e-06, 4.3504e-06, 3.89253e-06, 
3.67736e-06, 4.08168e-06,3.85234e-06, 3.99802e-06, 4.60479e-06, 5.29422e-06, 
4.87849e-06, 4.55674e-06,4.24992e-06, 3.52154e-06, 3.22953e-06, 2.58855e-06, 
2.42857e-06, 2.34923e-06,2.36014e-06, 2.33549e-06, 2.55772e-06, 3.03473e-06, 
3.14355e-06, 3.65574e-06,3.70734e-06, 3.68159e-06, 3.81222e-06, 3.35656e-06, 
3.062e-06, 2.69374e-06,2.45185e-06, 2.09096e-06, 1.87615e-06, 1.59947e-06, 
1.51572e-06, 1.47543e-06,1.5459e-06, 1.6819e-06, 1.89924e-06, 2.46062e-06, 
2.89706e-06, 3.43049e-06,4.07493e-06, 4.31785e-06, 4.56185e-06, 4.84605e-06, 
4.70059e-06, 5.04519e-06,5.03717e-06, 5.58133e-06, 5.772e-06, 6.2806e-06, 
6.83109e-06, 7.80214e-06,8.13898e-06 )

band.2 <- c ( 7.50196e-07, 3.64689e-07, 3.0422e-07, 2.19926e-07, 2.95025e-07, 
1.36813e-07,2.46454e-07, 3.07665e-07, 4.35207e-07, 4.54783e-07, 4.0e-07, 
4.6799e-07,4.30817e-07, 3.21329e-07, 5.14891e-07, 5.88871e-07, 7.24472e-07, 
5.19291e-07,5.83071e-07, 7.385e-07, 2.80484e-06, 2.40132e-06, 1.65424e-06, 
1.01535e-06,2.56678e-06, 6.15462e-06, 1.34813e-05, 2.75384e-05, 4.11764e-05, 
5.15236e-05,7.01286e-05, 0.000133268, 0.000337419, 0.000957927, 0.00227712, 
0.00543291,0.0197821, 0.0818229, 0.2452, 0.50

Re: [GRASS-dev] [GRASS GIS] #2305: i.atcorr landsat8 support

[Nick Ves]

The band follow that order (if i remember correcty) because they are
ordered by ascending wavelength since its the same scema the other
sensors follow.

No reason not to change the order if its needed

On Tue, Nov 25, 2014 at 7:10 PM, GRASS GIS  wrote:
> #2305: i.atcorr landsat8 support
> --+-
>   Reporter:  vesnikos |   Owner:  grass-dev@…
>   Type:  enhancement  |  Status:  closed
>   Priority:  normal   |   Milestone:  7.0.0
>  Component:  Imagery  | Version:  svn-trunk
> Resolution:  fixed|Keywords:  Landsat, i.atcorr
>   Platform:  Linux| Cpu:  x86-64
> --+-
>
> Comment(by neteler):
>
>  Replying to [comment:7 nikosa]:
>  > While scripting an i.landsat.atcorr module, wouldn't it be "ok" to keep
>  the official order of Landsat's 8 band_designation?
>
>  Yes, would make more sense.
>
>  > Currently, in i.atcorr the order is:
>  >
>  > 1: 115, 2: 116, 3: 117, 4: 118, 8: 119, 5: 120, 9: 121, 6: 122, 7: 123
>  >
>  > Why not:
>  >
>  > 1: 115, 2: 116, 3: 117, 4: 118, 5: 119, 6: 120, 7: 121, 8: 122, 9: 123
>  >
>  > ?
>
>  I guess that's how the original patch was provided. Can you manage to
>  prepare a patch for the modification?
>
> --
> 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] #2500: r.surf.idw vs. r.surf.idw2

[GRASS GIS]

#2500: r.surf.idw vs. r.surf.idw2
-+--
 Reporter:  martinl  |   Owner:  grass-dev@…  
 Type:  task |  Status:  new  
 Priority:  blocker  |   Milestone:  7.0.0
Component:  Default  | Version:  svn-trunk
 Keywords:   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--
 Do we need the both modules in G7?

  * could they be merged?
  * or one of them moved to addons

 Are there other candidates which could be moved to addons?

-- 
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] #2059: WorldView2 relative spectral response data for i.atcorr

[GRASS GIS]

#2059: WorldView2 relative spectral response data for i.atcorr
--+-
 Reporter:  nikosa|   Owner:  grass-dev@…  
 Type:  enhancement   |  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Imagery   | Version:  svn-trunk
 Keywords:  i.atcorr, worldview2  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by nikosa):

 Replying to [comment:17 neteler]:
 > Replying to [comment:16 nikosa]:
 > > The data seem to be wrong. I updated (again), see attached file (next
 post).
 >
 > Which post?

 File attached in the previous msg:
 http://trac.osgeo.org/grass/attachment/ticket/2059/worldview2_cpp_template.txt

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] planning grass 7.0.0beta4

[Moritz Lennert]

On 26/11/14 14:33, Markus Neteler wrote:

On Sun, Nov 23, 2014 at 12:54 AM, Sören Gebbert
 wrote:

Backport done in r62858 - r62867.
I hope everything works fine.


Great, thanks for your efforts!


It would be great if we could automatically test all the changes that
i have introduced in the release branch using the testsuite.


Do you mean "online" on a server?


A "make distclean" is needed.


Martin is currently going through the parameters for
http://trac.osgeo.org/grass/ticket/2409

Then we might be ready for beta4 by end of this week.


I still think that #2439 (and its duplicate #2476) is an almost blocker. 
Digitization is a fundamental tool and these crashes render it almost 
unusable for the normal(uninformed) user.


Anyone out there with sufficient knowlege of GUI and vector code to 
check this ?


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

Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by martinl):

 Replying to [comment:39 mlennert]:

 > > "raster" shouldn't be abbreviated.
 >
 > +1
 >
 > The problem is obviously more the inconsistency between modules than one
 choice over the other, but I would also plead for unabbreviated keys
 (unless absolutely infeasible).

 right, this means to update `element_list`, see eg. inconsistency in

 {{{
 g.findfile -l
 List of available elements:
   rast  (raster map(s))
   rast3d(3D raster map(s))
   vect  (vector map(s))
   oldvect   (old (GRASS 5.0) vector map(s))
   asciivect (ASCII vector map(s))
   labels(paint label file(s))
   region(region definition(s))
   region3d  (3D region definition(s))
   group (imagery group(s))
 }}}

 {{{
 g.findfile element=vector
 }}}

 will not work...

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] planning grass 7.0.0beta4

[Markus Neteler]

On Sun, Nov 23, 2014 at 12:54 AM, Sören Gebbert
 wrote:
> Backport done in r62858 - r62867.
> I hope everything works fine.

Great, thanks for your efforts!

> It would be great if we could automatically test all the changes that
> i have introduced in the release branch using the testsuite.

Do you mean "online" on a server?

> A "make distclean" is needed.

Martin is currently going through the parameters for
http://trac.osgeo.org/grass/ticket/2409

Then we might be ready for beta4 by end of this week.

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

Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by mlennert):

 Replying to [comment:30 glynn]:
 > Replying to [comment:27 annakrat]:
 > > I will change r.colors options (raster -> rast, volume -> rast3d)
 unless someone is against, sometime soon.
 >
 > "raster" shouldn't be abbreviated.

 +1

 The problem is obviously more the inconsistency between modules than one
 choice over the other, but I would also plead for unabbreviated keys
 (unless absolutely infeasible).

 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] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by martinl):

 Replying to [comment:19 wenzeslaus]:
 > Replying to [comment:18 martinl]:
 > > related to attachment:prefix_to_basename.diff
 > >
 > > I don't fully understand why to define key 'output' for basename
 options. I thought that `G_OPT_BASENAME_OUTPUT` will have default key like
 'basename_output' or 'output_basename' (better for backward
 compatibility). Similarly `G_OPT_BASENAME_INPUT` 'input_basename'.
 >
 > Currently, it seems to me that the current option naming policy is to
 use input or output regardless of type. So input can be raster for one
 module but vector or imagery group for another. Basename is just another
 item in the list of possible types/meanings.

 OK, done in r62966

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Export of integer raster from GRASS 70 with raster attribute table shifts classes

[Markus Metz]

Newcomb, Doug wrote:
> Hi Folks,
>
> I was running r.geomorphon,
> http://grass.osgeo.org/grass70/manuals/addons/r.geomorphon.html, to generate
> a landscape integer grid.  I decided to share the output with a colleague
> running ArcGIS.  I exported with the raster attribute table option to HFA (
> img , int16 ) format and passed it along.  He noticed something in the
> attribute table that was a bit odd.
>
> The the output values for r.geomorphon are integer values from 1 -10 .  The
> output .img file
> had the following in the following output for gdalinfo ( see below)
>
>
>
> As you can see below, a 0 value was added to the color table and the
> class_names start at 0 and not at 1 ( i.e, flat=0, but flat should equal 1)
> .  The pixel values do not change, the class names in the
> GDALRasterAttributeTable  are are associated  with a lower pixel value
> (shifted down one value.1--->0 and so on)

the fields in the attribute table as reported by GDAL are

Red, Green, Blue, Opacity, min, max, Class_Names

the first entry is
0, 0, 0, 0, 1, 1, flat

the pixel value 1 has the correct label "flat", but the color rule is wrong.

Looking at the Color Table (RGB with 11 entries) as reported by GDAL,
the first two entries are

0: 0,0,0,0
1: 220,220,220,255

this is correct, but different from the attribute table reported by
GDAL. The attribute table has thus correct labels but wrong colors.
The attribute table as created by GRASS contains in this case only
pixel values and labels, because it difficult to merge labels and
color rules. In GRASS, color rules and category labels are completely
separate, you can e.g. have 10 labels and 20 color rules. GDAL failed
to merge labels and color rules.

Markus M

>
> Exporting via r.out.gdal to the same file format without a raster attribute
> table or a color table gave a raster with values of 1-10.
>
> running gdal 1.11.1 on ubuntu  12.04 with GRASS 7.0 snapshot 2014_10_25.
>
> Not sure if it's a  grass or gdal issue
>
> gdalinfo output:
>
> ---
>
> Driver: HFA/Erdas Imagine Images (.img)
> Files: NED_SoApp_forms_cell25.img
>NED_SoApp_forms_cell25.img.aux.xml
> Size is 22854, 12004
> Coordinate System is:
> GEOGCS["GCS_WGS_1984",
> DATUM["WGS_1984",
> SPHEROID["WGS_84",6378137,298.257223563]],
> PRIMEM["Greenwich",0],
> UNIT["Degree",0.017453292519943295]]
> Origin = (-86.094722219722215,37.8480502)
> Pixel Size = (0.0002802,-0.0002801)
> Corner Coordinates:
> Upper Left  ( -86.0947222,  37.8480556) ( 86d 5'41.00"W, 37d50'53.00"N)
> Lower Left  ( -86.0947222,  34.5136111) ( 86d 5'41.00"W, 34d30'49.00"N)
> Upper Right ( -79.7463889,  37.8480556) ( 79d44'47.00"W, 37d50'53.00"N)
> Lower Right ( -79.7463889,  34.5136111) ( 79d44'47.00"W, 34d30'49.00"N)
> Center  ( -82.9205556,  36.1808333) ( 82d55'14.00"W, 36d10'51.00"N)
> Band 1 Block=64x64 Type=Int16, ColorInterp=Palette
>   Description = Layer_1
>   NoData Value=-32768
>   Metadata:
> COLOR_TABLE_RULE_RGB_0=1.00e+00 1.00e+00 220 220 220 220 220 220
> COLOR_TABLE_RULE_RGB_10=1.10e+01 1.10e+01 255 0 255 255 0 255
> COLOR_TABLE_RULE_RGB_1=2.00e+00 2.00e+00 56 0 0 56 0 0
> COLOR_TABLE_RULE_RGB_2=3.00e+00 3.00e+00 200 0 0 200 0 0
> COLOR_TABLE_RULE_RGB_3=4.00e+00 4.00e+00 255 80 20 255 80 20
> COLOR_TABLE_RULE_RGB_4=5.00e+00 5.00e+00 250 210 60 250 210 60
> COLOR_TABLE_RULE_RGB_5=6.00e+00 6.00e+00 255 255 60 255 255 60
> COLOR_TABLE_RULE_RGB_6=7.00e+00 7.00e+00 180 230 20 180 230 20
> COLOR_TABLE_RULE_RGB_7=8.00e+00 8.00e+00 60 250 150 60 250 150
> COLOR_TABLE_RULE_RGB_8=9.00e+00 9.00e+00 0 0 255 0 0 255
> COLOR_TABLE_RULE_RGB_9=1.00e+01 1.00e+01 0 0 56 0 0 56
> COLOR_TABLE_RULES_COUNT=11
> Generated_with=GRASS GIS 7.0.0svn
> LAYER_TYPE=athematic
>   Image Structure Metadata:
> COMPRESSION=RLE
>   Color Table (RGB with 11 entries)
> 0: 0,0,0,0
> 1: 220,220,220,255
> 2: 56,0,0,255
> 3: 200,0,0,255
> 4: 255,80,20,255
> 5: 250,210,60,255
> 6: 255,255,60,255
> 7: 180,230,20,255
> 8: 60,250,150,255
> 9: 0,0,255,255
>10: 0,0,56,255
> 
>   
> Red
> 0
> 6
>   
>   
> Green
> 0
> 7
>   
>   
> Blue
> 0
> 8
>   
>   
> Opacity
> 0
> 9
>   
>   
> min
> 0
> 0
>   
>   
> max
> 0
> 0
>   
>   
> Class_Names
> 2
> 2
>   
>   
> 0
> 0
> 0
> 0
> 1
> 1
> flat
>   
>   
> 220
> 220
> 220
> 255
> 2
> 2
> summit
>   
>   
> 56
> 0
> 0
> 255
> 3
> 3
> ridge
>   
>   
> 200
> 0
> 0
> 255
> 4
> 4
> shoulder
>   
>   
> 255
> 80
> 20
> 255
> 5
> 5
> spur
>   
>   
> 250
> 210
> 60
> 255
> 6
>

Re: [GRASS-dev] [GRASS GIS] #580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run

[GRASS GIS]

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---+
  Reporter:  hamish|   Owner:  grass-dev@…  
  Type:  defect|  Status:  reopened 
  Priority:  blocker   |   Milestone:  7.0.0
 Component:  wxGUI | Version:  svn-trunk
Resolution:|Keywords:  wingrass 
  Platform:  MSWindows XP  | Cpu:  Unspecified  
---+

Comment(by martinl):

 Replying to [comment:58 glynn]:

 > What is "$(%)" supposed to be? The stem of a pattern rule (the part
 which matches the "%" in the target) is available via "$*".

 right, thanks, it helped, see r62955-6.

-- 
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] #2272: Improve consistency in random generator usage

[GRASS GIS]

#2272: Improve  consistency in random generator usage
-+--
 Reporter:  neteler  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:  7.0.0
Component:  Default  | Version:  svn-releasebranch70  
 Keywords:  random   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by neteler):

 By chance I found

 raster/simwe/simlib/random.c

 /*  uniform random number generator (combined type) */

 Should that be replaced as well (how)?

-- 
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] #1242: vector fills and line widths not displaying in latlon regions

[GRASS GIS]

#1242: vector fills and line widths not displaying in latlon regions
-+--
 Reporter:  cmbarton |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  critical |   Milestone:  7.0.0
Component:  Display  | Version:  svn-trunk
 Keywords:  vector, display, d.vect  |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by lucadelu):

 Replying to [comment:7 cmbarton]:
 > Are the north arrows working? Last time I checked, they are still
 rendering as multiples. I have not tested this update from yesterday
 however.
 >
 > Michael

 Yes, everything is working for me. Please see the attachment

-- 
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] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by martinl):

 Replying to [comment:33 annakrat]:
 > Replying to [comment:31 glynn]:
 > > Another possibility with regards to abbreviating compound words would
 be to use an upper-case letter (rather than a specific character, such as
 the single quote in the previous example), so backGround_color would work
 like back_ground_color but arguably isn't quite as ugly. Similarly,
 "columnS" doesn't seem as bad as column_s.
 >
 > Please don't do that. GRASS suffers from "too many ways to do the same
 thing", let's not make it worse.

 I would agree with Anna.

-- 
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] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by martinl):

 Replying to [comment:31 glynn]:
 > Except: d.vect currently has both bgcolor= (label background color) and
 bcolor= (label border colour). If these were changed to background_color
 and border_color, bcolor would be rejected as ambiguous.

 It has been already renamed to `label_bgcolor` and `label_bcolor` in
 r62945.

 > Another possibility with regards to abbreviating compound words would be
 to use an upper-case letter (rather than a specific character, such as the
 single quote in the previous example), so backGround_color would work like
 back_ground_color but arguably isn't quite as ugly. Similarly, "columnS"
 doesn't seem as bad as column_s.

 I thought we have a rule not to use uppercase in key names. I would
 personally keep it.

-- 
Ticket URL: 
GRASS GIS 

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