Re: [GRASS-dev] [GRASS GIS] #3149: Adding database information to v.info metadata output

2016-09-24 Thread GRASS GIS 
#3149: Adding database information to v.info metadata output
--+--
  Reporter:  huhabla  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.2.0
 Component:  Default  |Version:  svn-releasebranch72
Resolution:   |   Keywords:  vector, info, v.info
   CPU:  Unspecified  |   Platform:  Unspecified
--+--

Comment (by wenzeslaus):

 Replying to [comment:8 mmetz]:
 > ...your approach can not handle multiple connections.

 This is a common problem which was not yet addressed well. One solution is
 to use something like this:

 {{{
 db_linked_layers=1,2
 attribute_layer_1_layer_name=test_vinfo_with_db_3d
 
attribute_layer_1_database=/home/user/g/LL/user/vector/test_vinfo_with_db_3d/sqlite.db
 attribute_layer_1_database_driver=sqlite
 ...
 attribute_layer_2_layer_name=...
 }}}

 The naming should be improved but the idea is similar to OSM tagging:

 {{{
 emergency=fire_hydrant
 fire_hydrant:type=underground
 fire_hydrant:diameter=1
 ...
 }}}

 Alternative and more universal approach is using JSON as in case of
 G7:v.what. Something like this:

 {{{
 ...
 "dblinks": [
 {
 "number": 1,
 "name": "test_vinfo_with_db_3d",
 "database": "/home/user/g/LL/user/vector/test_vinfo_with_db...",
 ...
 {
 ]
 ...
 }}}

 Also comapre:

 {{{
 g.extension -g
 g.search.modules gradient -j
 }}}

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Broken: GRASS-GIS/grass-ci#1581 (master - a974fbb)

2016-09-24 Thread Travis CI 
Build Update for GRASS-GIS/grass-ci
-

Build: #1581
Status: Broken

Duration: 8 minutes and 34 seconds
Commit: a974fbb (master)
Author: Markus Metz
Message: v.edit tool=merge: improve iteration over list of lines, handle 
zero-length lines

git-svn-id: https://svn.osgeo.org/grass/grass/trunk@69569 
15284696-431f-4ddb-bdfa-cd5b030d7da7

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/11022dda08a1...a974fbb01b96

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/162508104

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

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

[GRASS-dev] wingrass temporary down

2016-09-24 Thread Martin Landa 
Hi all,

wingrass.fsv.cvut.cz is temporary down due to network changes in CTU
network. Should be back on Monday. Martin

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

Re: [GRASS-dev] 7.0.5 release planning

2016-09-24 Thread Martin Landa 
Hi,

2016-09-18 16:21 GMT+02:00 Martin Landa :
> cool, count with my support please. Ma

since RC2 has been released on Sunday 18/9, the final release 7.0.5
should be out ~tomorrow. Any objections? @MarkusM: is there anything
waiting to be backported regarding your recent fixes?

Thanks for collaboration, Martin

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

Re: [GRASS-dev] Working with TGIS without starting GRASS explicitly

2016-09-24 Thread Sören Gebbert 
Hi Laurent,
i have attached a Python script that shows the handling of tgis.init() in a
subprocess in case location and mapsets change using grass72.
The following output was generated with this script, it seems to work on my
system:

soeren@knecht:~$ python test_tgis.py
New envrionment: {u'MAPSET': u'PERMANENT', u'GISDBASE':
u'/home/soeren/grassdata', u'LOCATION_NAME': u'nc_spm_08_grass7'}
TGIS init:
database: /home/soeren/grassdata
location: nc_spm_08_grass7
mapset: PERMANENT
New envrionment: {u'MAPSET': u'user1', u'GISDBASE':
u'/home/soeren/grassdata', u'LOCATION_NAME': u'nc_spm_08_grass7'}
TGIS init:
database: /home/soeren/grassdata
location: nc_spm_08_grass7
mapset: user1
New envrionment: {u'MAPSET': u'PERMANENT', u'GISDBASE':
u'/home/soeren/grassdata', u'LOCATION_NAME': u'nc_spm_08'}
TGIS init:
database: /home/soeren/grassdata
location: nc_spm_08
mapset: PERMANENT
New envrionment: {u'MAPSET': u'user1', u'GISDBASE':
u'/home/soeren/grassdata', u'LOCATION_NAME': u'nc_spm_08'}
TGIS init:
database: /home/soeren/grassdata
location: nc_spm_08
mapset: user1


Best regards
Soeren


2016-09-24 5:32 GMT+02:00 Laurent C. :

> Hi Sören,
>
> I followed you suggestion and now each simulation run in its own process
> using the multiprocessing library. It works well, thanks.
> However, there was indeed something strange going on:
> The new mapset, location and accessible mapsets were set properly, as seen
> by the output of g.mapset and g.mapsets
> However, the output of ciface.available_mapsets() and therefore
> core.get_available_temporal_mapsets() were not updated after the first
> simulation, so tgis.init() were failing, not seeing the new current mapset
> in its own list of available mapsets.
>
> Below was the output of the software:
>
> g.mapset -p
> swashes_1d_1000m
> g.mapsets -p
> Accessible mapsets:
> swashes_1d_1000m PERMANENT
> ciface.available_mapsets()
> ['swashes_1d_1000m', 'PERMANENT']
> get_available_temporal_mapsets()
> {'swashes_1d_1000m': ('sqlite', '/home/laurent/grassdata/
> flood_test/swashes_1d_1000m/tgis/sqlite.db')}
> Starting simulation for configuration file macdo1000.ini...
> [...]
> g.mapset -p
> hull
> g.mapsets -p
> Accessible mapsets:
> hull PERMANENT hull_rain
> ciface.available_mapsets()
> ['swashes_1d_1000m', 'PERMANENT']
> get_available_temporal_mapsets()
> {'swashes_1d_1000m': ('sqlite', '/home/laurent/grassdata/
> flood_test/swashes_1d_1000m/tgis/sqlite.db')}
> ERROR: Unable to execute sql statement. There is no temporal database
> connection defined for mapset 
>
> It seems that tgis.init() is not doing what it is supposed to, according
> to the documentation:
>
> "Re-run this function in case the following GRASS variables change while
> the process runs:
> - MAPSET
> - LOCATION_NAME
> - GISDBASE
> - TGIS_DISABLE_MAPSET_CHECK
> - TGIS_DISABLE_TIMESTAMP_WRITE
> "
>
> Thanks again.
>
> Regards,
> Laurent
>
> 2016-09-22 13:52 GMT-05:00 Sören Gebbert :
> > Hi Laurent,
> > the temporal framework was neither tested nor designed to work in a
> script
> > that changes the location while running. I would suggest to run the
> temporal
> > framework related code in a subprocess that is created each time the
> > location or mapset changes. Unfortunately i have no other suggestion.
> >
> > However, have you tested your code with grass 7.2 or 7.3? Many
> improvements
> > have been implement in the recent version that would be beneficial to
> use.
> >
> > Best regards
> > Soeren
> >
> > 2016-09-22 2:47 GMT+02:00 Laurent C. :
> >>
> >> Hello all,
> >>
> >> I've ran into another related issue.
> >> One of the goal of running the software outside of GRASS shell is to
> >> batch process simulations in various Locations/mapsets.
> >>
> >> I set the GRASS session for each case. The simulation works well for
> >> the first case.
> >> However when starting the second case, tgis.init() fails with the
> >> following error:
> >>
> >> ERROR: Unable to execute sql statement. There is no temporal database
> >> connection defined for mapset 
> >>
> >> The mapset and location are properly set.
> >> If this case is run first, it works well and it's the second one that
> >> fail.
> >> Running t.connect -c between two cases does not solve the problem.
> >> Actually, t.connect -p shows the correct connection parameters, but
> >> tgis.init() still fails.
> >>
> >> Regards,
> >> Laurent
> >>
> >>
> >> 2016-09-21 18:27 GMT-05:00 Laurent C. :
> >> > Hi Sören,
> >> >
> >> > Setting LD_LIBRARY_PATH is working, thanks. But it cannot be set at
> >> > run-time, which is not very user-friendly.
> >> > I guess this issue is related to the ticket 2424 [1].
> >> >
> >> > I managed to get it work at run-time by restarting the program with
> >> > sys.execv() after setting the path [2], but I find it a bit ugly and
> >> > quite verbose to be multi-platform.
> >> >
> >> > It would be great if an