Vaclav Petras | 30 Sep 20:18 2014
Picon

Heading towards unified dataset

Hi,

at FOSS4G we were talking about the need of unified dataset, a GRASS location in our GRASS case, to enable easy writing of examples and also tests.

The location would have maps with unified names such as "elevation" and these names can be used in the examples and tests so that both examples and tests can, to certain extent, work in different locations. For examples in manual pages or other educational material, this would mean that it could be used better across more countries or areas. For tests, this would mean that different projection or data can be tested with the algorithms.

This has of course its limits, for example the result of statistical analysis would be different in different locations but the point is that the analysis can be done.

We already have NC (full) location and NC basic location. They have these raster maps in common:

elevation
elevation_shade
lakes

These maps are in NC basic:

basins
geology
landuse
soils

But in full NC they have different names:

basin_50K
geology_30m
landuse96_28m
soilsID

Of course the longer names have their reasoning in differences with similar raster maps in the same location but I would say that having unified names is more advantageous for teaching/test datasets then absolute clearness of names. This should be in metadata anyway.

One can also argue about the unified names themselves (e.g. elevation vs dtm or usage of underscore) but most of it is pretty clear since it has to be the most general names possible.

The names must be obviously in English. If somebody would like to have data in different language, derived dataset must be created. Perhaps it would be possible to provide some batch version of g.rename (but there are also attribute columns and others).

The last issue might be what if there is nothing in the area which can be part of the map or if dam or pond are lakes. But we can allow for some inaccuracies when creating a training dataset.

The other locations which can be unified are Piemonte and Spearfish.

So, what are the next steps? Decide about which maps to include and which names to use? Let's start from the NC basic location.

Raster maps

basins
elevation
elevation_shade
geology
lakes
landuse
soils

I'm not sure if geology and soils would be available in other locations, so we could leave out them. However, they are available for Spearfish and maybe for Piemonte (my Italian is not really usable).

Vector maps

boundary_region
boundary_state
census
elev_points
firestations
geology
geonames
hospitals
points_of_interest
railroads
roadsmajor
schools
streams
streets
zipcodes

We would need to have at at least one map for each type. I'm not sure what are the crucial ones and broadly available but it seems that training datasets are usually near some civilization, so roads or schools might be available. Buildings would be nice to have.

Attribute data, time series and 3D rasters and (real) 3D vectors are of course whole new level. So, I would start with rasters and (mostly 2D) vectors.

Vaclav
_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Helmut Kudrnovsky | 30 Sep 13:54 2014
Picon

g7 addon scripts not working with trunk due to command syntax/option differences

hi,

all g7 addon scripts which are using e.g. v.to.rast or g.remove are not
working due to command syntax differences.

e.g. in v.to.rast in trunk:

- option 'rows' removed
- instead option 'memory' added

e.g. in g.remove

- g.remove rast=soils (g7) -> g.remove -f type=rast pattern=soils (trunk)

any idea if these syntax differences between g7 and trunk will be backported
at any stage?

if not how to proceed with addon scripts which depend upon some changed
options/syntax?

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/g7-addon-scripts-not-working-with-trunk-due-to-command-syntax-option-differences-tp5164964.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
GRASS GIS | 30 Sep 09:48 2014

[GRASS GIS] #2438: Vect_get_line_type cannot handle line out of range

#2438: Vect_get_line_type cannot handle line out of range
-------------------------+--------------------------------------------------
 Reporter:  artegion     |       Owner:  grass-dev <at> …              
     Type:  defect       |      Status:  new                      
 Priority:  normal       |   Milestone:  6.4.5                    
Component:  LibVector    |     Version:  unspecified              
 Keywords:               |    Platform:  Unspecified              
      Cpu:  Unspecified  |  
-------------------------+--------------------------------------------------
 calling Vect_get_line_type with line out of range (i.e. line=0)
 Vect_line_alive returns -1 but Vect_get_line_type ignores it (not -1 is
 False just like not 1) -> access violation reading ....

 {{{
 >>> from grass.lib.vector import  Vect_line_alive
 >>> from grass.lib.vector import  Vect_get_line_type
 >>> from grass.pygrass vector import VectorTopo
 >>> a= VectorTopo('test')
 >>> a.open()
 >>> Vect_line_alive(a.c_mapinfo, 1)
 1
 >>> Vect_get_line_type(a.c_mapinfo, 1)
 1
 >>> Vect_line_alive(a.c_mapinfo, 0)
 -1
 >>> not Vect_line_alive(a.c_mapinfo, 0)
 False
 >>> Vect_get_line_type(a.c_mapinfo, 0)
 Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
 WindowsError: exception: access violation reading 0x736C0014
 >>>
 }}}

--

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2438>
GRASS GIS <http://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Markus Neteler | 30 Sep 09:15 2014

SVN trunk issue with g.list and g.remove (and solution)

Hi,

likely you will be affected by this recent issue:

Tree conflict on 'grass_trunk/general/g.list'
   > local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r
Resolved conflicted state of 'grass_trunk/general/g.list'
Tree conflict on 'grass_trunk/general/g.remove'
   > local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r

svn status | grep -v "^?"
D       general/g.list
D       general/g.list/Makefile
D       general/g.list/g.list.html
D       general/g.list/main.c
D       general/g.list/testsuite
D       general/g.list/testsuite/test_g_list.py
D       general/g.remove
D       general/g.remove/Makefile
D       general/g.remove/check_reclass.c
D       general/g.remove/g.remove.html
D       general/g.remove/main.c
D       general/g.remove/testsuite
D       general/g.remove/testsuite/test_g_remove.py

To solve that:

# clean
make distclean

# revert mess
svn -R revert general/g.list
svn -R revert general/g.remove

# update and check
svn up
svn status

I had to do this on all my SVN copies of trunk.

Markus
GRASS GIS | 29 Sep 21:34 2014

[GRASS GIS] #2437: order parameters in g.remove window

#2437: order parameters in g.remove window
-------------------------+--------------------------------------------------
 Reporter:  pvanbosgeo   |       Owner:  grass-dev <at> …              
     Type:  enhancement  |      Status:  new                      
 Priority:  normal       |   Milestone:  7.1.0                    
Component:  Default      |     Version:  unspecified              
 Keywords:  g.remove     |    Platform:  All                      
      Cpu:  Unspecified  |  
-------------------------+--------------------------------------------------
 On the 'required' tab of the g.remove function you first need to select
 the data type from a list. Below one need to type the map name search
 pattern.

 I have no clue if that is specific for my computer, but for the latter
 (the map name search pattern) I have to scroll down as the list of data
 types is longer then the height of the g.remove screen.

 I only ever need to select raster or vector (and I guess those are amongst
 the most used by the majority of users), so the scrolling to get to the
 bottom could be avoided by first being presented by the map name search
 pattern box and than the data type. For me that order makes more sense
 anyway, but that is just a personal preference.But having rsi problems,
 anything that could reduce the use of the mouse, however little, would be
 welcome (I know, I can use the command line more, and I try as much as
 possible).

--

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2437>
GRASS GIS <http://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Vaclav Petras | 29 Sep 15:34 2014
Picon

Trac syntax for verbatim, source code listings and pre-formatted text

I see often in Trac tickets something like this:

On Mon, Sep 29, 2014 at 9:00 AM, GRASS GIS <trac <at> osgeo.org> wrote:
 FEHLER: Feature type 64 is not supported[[BR]]
 NOTICE:  table "newcs_correct_pg_collect" does not exist, skipping[[BR]]
 KONTEXT:  SQL statement "DROP TABLE IF EXISTS
 public.newcs_correct_pg_collect RESTRICT"[[BR]]
 PL/pgSQL function dropgeometrytable(character varying,character
 varying,character varying) line 15 at EXECUTE statement[[BR]]
 [Inferior 1 (process 7881) exited with code 01][[BR]]

Each line of some program output or code is ended with [[BR]]. I think that it is much easier to use triple curly brackets:

{{{
some output or code
}}}

Why people are using this? An I missing something? It is just because they don't know about {{{ }}} or there is some Trac magic feature which automatically adds there [[BR]] to the end of copy-pasted text?

Adding [[BR]] manually seems to me as large amount of work, so I would like to make known that there is this {{{ }}} syntax in case that somebody does not know.

By the way, {{{ }}} works also for inline verbatim but using backticks (`text`) is usually simpler.

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
GRASS GIS | 28 Sep 23:34 2014

[GRASS GIS] #2436: v.out.postgis: Unsupported geometry type / Unable to write feature in vector map

#2436: v.out.postgis: Unsupported geometry type / Unable to write feature in
vector map
---------------------------+------------------------------------------------
 Reporter:  martin         |       Owner:  grass-dev <at> …              
     Type:  defect         |      Status:  new                      
 Priority:  normal         |   Milestone:                           
Component:  Vector         |     Version:  svn-trunk                
 Keywords:  v.out.postgis  |    Platform:  Linux                    
      Cpu:  x86-64         |  
---------------------------+------------------------------------------------
 This package:

   http://foxtrot.mgras.net/static/newcs_correct_collect.tbz


 contains a packed vector map plus a little text file.
 The top of the text file shows two commands to export the vector map into
 PostGIS (PostGIS geometry, no topology). The "v.out.ogr" works as
 promised but the "v.out.postgis" doesn't ....  and the bottom part of the
 text file contains the corresponding debug output.

--

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/2436>
GRASS GIS <http://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
GRASS GIS | 27 Sep 10:36 2014

[GRASS GIS] #2435: finish replacement of python api doxygen doc by sphinx

#2435: finish replacement of python api doxygen doc by sphinx
-------------------------------------+--------------------------------------
 Reporter:  martinl                  |       Owner:  grass-dev <at> …              
     Type:  defect                   |      Status:  new                      
 Priority:  major                    |   Milestone:  7.1.0                    
Component:  Docs                     |     Version:  unspecified              
 Keywords:  doxygen, python, sphinx  |    Platform:  Unspecified              
      Cpu:  Unspecified              |  
-------------------------------------+--------------------------------------
 Some content removed in r62097 is still waiting for Sphinx integration,
 namely:

  * source:grass/trunk/gui/wxpython/wxguitoolboxes.dox <at> 57001
  * source:grass/trunk/gui/wxpython/wxpythonlib.dox <at> 56035
  * source:grass/trunk/lib/python/imaging/imaginglib.dox <at> 58181
  * source:grass/trunk/lib/python/pydispatch/pydispatchlib.dox <at> 55394
  * source:grass/trunk/lib/python/pygrass/pygrasslib.dox <at> 60031
  * source:grass/trunk/lib/python/script/pythonlib.dox <at> 62015
  * source:grass/trunk/lib/python/temporal/pythontemporallib.dox <at> 58915

--

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2435>
GRASS GIS <http://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Luca Delucchi | 27 Sep 10:35 2014
Picon

Foss4g EU code sprint

Hi devs,
What do you think about a code sprint after Foss4g EU?
we could start on Saturday (one day code sprint should be already planned) and continue the days after.
We could also extend to others projects and replicate something like Vienna code sprint.

Cheers
Luca

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Vaclav Petras | 26 Sep 23:30 2014
Picon

Re: [GRASS-SVN] r62097 - in grass/trunk: . gui/wxpython include/Make lib/python/ctypes lib/python/imaging lib/python/pydispatch lib/python/pygrass lib/python/script lib/python/temporal


On Fri, Sep 26, 2014 at 2:57 PM, <svn_grass <at> osgeo.org> wrote:
Removed:
   grass/trunk/gui/wxpython/wxguitoolboxes.dox
   grass/trunk/gui/wxpython/wxpythonlib.dox
   grass/trunk/lib/python/imaging/imaginglib.dox
   grass/trunk/lib/python/pydispatch/pydispatchlib.dox
   grass/trunk/lib/python/pygrass/pygrasslib.dox
   grass/trunk/lib/python/script/pythonlib.dox
   grass/trunk/lib/python/temporal/pythontemporallib.dox

I absolutely agree with removal of GUI and Python from Doxygen, this was the goal. However, note that some of the .dox files you deleted were more than just mere list of functions and classes and they are not in Sphinx yet.

We also haven't figured out where to put the wxGUI docs. More importantly from where it should be linked. I think it is not the same as Python interface and it is not even the case of C API, we cannot guarantee a stable interface, although I would like to see that and we are already on the way.
_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
GRASS GIS | 26 Sep 22:45 2014

[GRASS GIS] #2434: v.surf.bspline

#2434: v.surf.bspline
-----------------------+----------------------------------------------------
 Reporter:  baharmon   |       Owner:  grass-dev <at> …              
     Type:  defect     |      Status:  new                      
 Priority:  normal     |   Milestone:  7.0.0                    
Component:  Raster     |     Version:  svn-trunk                
 Keywords:             |    Platform:  MSWindows 8              
      Cpu:  OSX/Intel  |  
-----------------------+----------------------------------------------------
 I got the following error with v.surf.bspline:

 {{{

 v.surf.bspline input=ground <at> lidar raster_output=lake_raleigh_dem_bspline
 ew_step=6 ns_step=6 method=bicubic lambda_i=0.02 memory=12000 --overwrite
 Initializing output...
 WARNING: Unable to rename null file
 'C:\Users\Brendan\Documents\grassdata/nc_spf/lidar/.tmp/unknown/3624.1' to
 'C:\Users\Brendan\Documents\grassdata/nc_spf/lidar/cell_misc/lake_raleigh_dem_bspline/null':
 Permission denied
 WARNING: Unable to rename cell file
 'C:\Users\Brendan\Documents\grassdata/nc_spf/lidar/.tmp/unknown/3624.0' to
 'C:\Users\Brendan\Documents\grassdata/nc_spf/lidar/fcell/lake_raleigh_dem_bspline':
 Permission denied
 WARNING: Unable to write quant rules: raster map
 <lake_raleigh_dem_bspline> is integer
 v.surf.bspline complete.

 }}}

--

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/2434>
GRASS GIS <http://grass.osgeo.org>

_______________________________________________
grass-dev mailing list
grass-dev <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Gmane