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

Laurent C. lrntct at gmail.com
Wed Oct 5 06:20:54 PDT 2016


Hi Sören,

Thanks for your answer. I did something similar and it works well under
Linux.
Making those hacks works with Windows seems to be a bit more complex,
though.

Regards,
Laurent

2016-09-24 4:35 GMT-05:00 Sören Gebbert <soerengebbert at googlemail.com>:
> 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 at 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. <lrntct at gmail.com>:
>>
>> 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 <hull>
>>
>> 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 <soerengebbert at googlemail.com>:
>> > 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. <lrntct at gmail.com>:
>> >>
>> >> 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 <hull>
>> >>
>> >> 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. <lrntct at gmail.com>:
>> >> > 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 easier option was possible.
>> >> >
>> >> > Regards,
>> >> > Laurent
>> >> >
>> >> > [1] https://trac.osgeo.org/grass/ticket/2424
>> >> > [2]
>> >> >
>> >> >
http://stackoverflow.com/questions/6543847/setting-ld-library-path-from-inside-python
>> >> >
>> >> >
>> >> > 2016-09-21 15:40 GMT-05:00 Sören Gebbert
>> >> > <soerengebbert at googlemail.com>:
>> >> >> Hi,
>> >> >> i think you have to put the GRASS libraries into your
>> >> >> LD_LIBRARY_PATH
>> >> >> so
>> >> >> that the python wrapper can access them.
>> >> >>
>> >> >> Best regards
>> >> >> Soeren
>> >> >>
>> >> >> 2016-09-21 20:37 GMT+02:00 Laurent C. <lrntct at gmail.com>:
>> >> >>>
>> >> >>> Hello all,
>> >> >>>
>> >> >>> I'm trying to adapt a python module in order for it to be run
>> >> >>> outside
>> >> >>> of
>> >> >>> GRASS.
>> >> >>> I followed the instructions from the wiki and
>> >> >>> lib/python/script/setup.py
>> >> >>>
>> >> >>> gsetup.init() run without error and I can list maps like in the
>> >> >>> example.
>> >> >>>
>> >> >>> However, when I try to import the temporal module, I receive this
>> >> >>> error:
>> >> >>>
>> >> >>> import grass.temporal as tgis
>> >> >>> File "/usr/lib/grass70/etc/python/grass/temporal/__init__.py",
line
>> >> >>> 1, in <module>
>> >> >>> from core import *
>> >> >>> File "/usr/lib/grass70/etc/python/grass/temporal/core.py", line
38,
>> >> >>> in <module>
>> >> >>> from c_libraries_interface import *
>> >> >>> File
>> >> >>>
>> >> >>>
"/usr/lib/grass70/etc/python/grass/temporal/c_libraries_interface.py",
>> >> >>> line 19, in <module>
>> >> >>> import grass.lib.gis as libgis
>> >> >>> File "/usr/lib/grass70/etc/python/grass/lib/gis.py", line 23, in
>> >> >>> <module>
>> >> >>> _libs["grass_gis.7.0.4"] = load_library("grass_gis.7.0.4")
>> >> >>> File "/usr/lib/grass70/etc/python/grass/lib/ctypes_loader.py",
line
>> >> >>> 55, in load_library
>> >> >>> return self.load(path)
>> >> >>> File "/usr/lib/grass70/etc/python/grass/lib/ctypes_loader.py",
line
>> >> >>> 71, in load
>> >> >>> raise ImportError,e
>> >> >>> ImportError: libgrass_datetime.7.0.4.so: cannot open shared object
>> >> >>> file: No such file or directory
>> >> >>>
>> >> >>>
>> >> >>> Did I forgot to set-up something or this is a bug?
>> >> >>>
>> >> >>> Cheers,
>> >> >>> Laurent
>> >> >>> _______________________________________________
>> >> >>> grass-dev mailing list
>> >> >>> grass-dev at lists.osgeo.org
>> >> >>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>> >> >>
>> >> >>
>> >
>> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20161005/2bf3f864/attachment.html>


More information about the grass-dev mailing list