Re: [GRASS-dev] Submitting rules: Commit messages
On 2 July 2014 23:10, Martin Landa landa.mar...@gmail.com wrote: Hi, Hi, an idea which could really help to a person who goes through svn logs and collects items for the news on trac. The commits which should go to the news could be marked by developers by special key, eg. `[news]` in the log message. What do you think? I like it, do you think to put [news] after the name of command/library modified or at the end of message? Martin -- 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] sphinx documentation for lib python
On 3 July 2014 17:08, Martin Landa landa.mar...@gmail.com wrote: Hi, HI, 2014-07-03 17:06 GMT+02:00 Martin Landa landa.mar...@gmail.com: sphinxdoc' please consider renaming this rule to `sphinxdocs` (similarly to `htmldocs` and friends - see include/Make/Docs.make). Martin ok, do you think it is better to have lib/python and gui/wxpython in the same Make rule or do you prefer two different? -- 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] Unify python GRASS defined exception in one common file
On 3 July 2014 17:35, Pietro peter.z...@gmail.com wrote:
Dear devs,
Hi,
What do you think if we unify all our custom exceptions in one common file?
Just to avoid code repetitions and help consistency.
Looking into the code I found the following custom exceptions:
{{{
$ grep --color=auto
--exclude-dir={.svn,.git,.OBJ,locale,dist.x86_64-unknown-linux-gnu}
-IrnE class\s\w+\(Exception\)\:
lib/python/pygrass/messages/__init__.py:21:class FatalError(Exception):
lib/python/pygrass/errors.py:11:class AbstractError(Exception):
lib/python/pygrass/errors.py:19:class ParameterError(Exception):
lib/python/pygrass/errors.py:23:class FlagError(Exception):
lib/python/pydispatch/errors.py:4:class DispatcherError(Exception):
lib/python/temporal/abstract_dataset.py:26:class
ImplementationError(Exception):
lib/python/temporal/temporal_algebra.py:655:class FatalError(Exception):
lib/python/ctypes/ctypesgencore/parser/lex.py:46:class LexError(Exception):
lib/python/ctypes/ctypesgencore/parser/yacc.py:87:class
YaccError(Exception): pass
lib/python/script/core.py:50:class ScriptError(Exception):
gui/wxpython/core/gcmd.py:156:class GException(Exception):
gui/wxpython/wxgui.py:86:class Usage(Exception):
}}}
Perhaps we could create a new file in grass.script.errors or
grass.script.exceptions, or outside script so something like
grass.errors or grass.exceptions.
Do you think it is a bad idea?
If it is possible without create problems I think it is a good idea...
Best regards
Pietro
--
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] sphinx documentation for lib python
Hi, 2014-07-04 8:50 GMT+02:00 Luca Delucchi lucadel...@gmail.com: ok, do you think it is better to have lib/python and gui/wxpython in the same Make rule or do you prefer two different? I have no strong opinion, one rule (`sphinxdocs`) seems to be enough for me. Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2356: r.stream.basisns uses more memory than given in memory option
#2356: r.stream.basisns uses more memory than given in memory option
-+--
Reporter: sbl | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.1.0
Component: Addons | Version: svn-trunk
Keywords: r.stream.basins, memory |Platform: Linux
Cpu: x86-64 |
-+--
Changes (by hamish):
* keywords: r.stream.basisns, memory = r.stream.basins, memory
* component: Raster = Addons
Comment:
were the input maps CELL, FCELL or DCELL?
fwiw here's the code,
{{{
opt_swapsize-description = _(Maximum memory used in memory swap mode
(MB));
opt_swapsize-answer = 300;
...
number_of_segs = (int)atof(opt_swapsize-answer);
number_of_segs = number_of_segs 32 ? (int)(32 / 0.12) : number_of_segs
/ 0.12;
}}}
if the stream_rast= option is used then two ram_create_map()s happen.
Likely the above number_of_segs isn't taking that into account.
did it work ok when you halved the memory= option?
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2356#comment:1
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2356: r.stream.basisns uses more memory than given in memory option
#2356: r.stream.basisns uses more memory than given in memory option -+-- Reporter: sbl | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.1.0 Component: Addons | Version: svn-trunk Keywords: r.stream.basins, memory |Platform: Linux Cpu: x86-64 | -+-- Comment(by hamish): I wrote: if the stream_rast= option is used then two ram_create_map()s happen. sorry, two seg_create_map() happen without stream_rast=, three if with it. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2356#comment:2 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2356: r.stream.basisns uses more memory than given in memory option
#2356: r.stream.basisns uses more memory than given in memory option -+-- Reporter: sbl | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.1.0 Component: Addons | Version: svn-trunk Keywords: r.stream.basins, memory |Platform: Linux Cpu: x86-64 | -+-- Comment(by sbl): Both input maps (dirs and streams) were generated by r.watershed and are CELL. r.stream.basins worked just fine when I set the memory option to ~1/7 of the available RAM. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2356#comment:3 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2356: r.stream.basisns uses more memory than given in memory option
#2356: r.stream.basisns uses more memory than given in memory option -+-- Reporter: sbl | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.1.0 Component: Addons | Version: svn-trunk Keywords: r.stream.basins, memory |Platform: Linux Cpu: x86-64 | -+-- Comment(by sbl): Both input maps had: Rows: 180752 Columns: 141312 The region followed exactly those maps (it was not changed after maps were generated with r.watershed). -- Ticket URL: https://trac.osgeo.org/grass/ticket/2356#comment:5 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] sphinx documentation for lib python
On 3 July 2014 17:08, Martin Landa landa.mar...@gmail.com wrote: Hi, Hi again please consider renaming this rule to `sphinxdocs` (similarly to `htmldocs` and friends - see include/Make/Docs.make). Martin I saw that the name in the main Makefile are something like htmldocs and htmldox, maybe we should rename it to htmlsphinx, mansphinx and maybe add htmlsphinx-single and latexsphinx? -- 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] [GRASS GIS] #2356: r.stream.basisns uses more memory than given in memory option
#2356: r.stream.basisns uses more memory than given in memory option
-+--
Reporter: sbl | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.1.0
Component: Addons | Version: svn-trunk
Keywords: r.stream.basins, memory |Platform: Linux
Cpu: x86-64 |
-+--
Comment(by hamish):
so for an unsegmented cell map, 180752 * 141312 * 4 bytes = ~97GB to hold
one whole map in ram.
r.stream.basins/io.h defines segments as 256x256, so for memory=1 (mb)
{{{
seg_create_map(map_dirs, SROWS, SCOLS, number_of_segs, CELL_TYPE);
}}}
we get
bytes = ~20.8GB, and needs that for each of the two or three open maps.
can you try r61149?
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2356#comment:6
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2356: r.stream.basisns uses more memory than given in memory option
#2356: r.stream.basisns uses more memory than given in memory option -+-- Reporter: sbl | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.1.0 Component: Addons | Version: svn-trunk Keywords: r.stream.basins, memory |Platform: Linux Cpu: x86-64 | -+-- Comment(by sbl): FYI, 20.8GB is exactly the amount of memory consumption for reading the input maps reported by the top command, when I ran r.stream.basins with memory=1. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2356#comment:7 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] compiling grass 7 - can't find gdal (but it is there)
OK, this seems to be solved with the latest update.. thanks :-) On Wed, Jul 2, 2014 at 8:41 PM, Paulo van Breugel p.vanbreu...@gmail.com wrote: Hi, I am trying to compile grass7 (revision 61123) on Ubuntu 14.04, but the configuring fails with: ... checking whether to use GDAL... yes checking for gdal-config... /usr/bin/gdal/bin/gdal-config configure: error: *** Unable to locate GDAL library. The path /usr/bin/gdal/bin/gdal-config is correct. In addition, I could configure and build an earlier grass revision without problems (this is actually the first time in a very long time the process already fails at configure). Since then nothing has changed in respect to gdal. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2356: r.stream.basisns uses more memory than given in memory option
#2356: r.stream.basisns uses more memory than given in memory option -+-- Reporter: sbl | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.1.0 Component: Addons | Version: svn-trunk Keywords: r.stream.basins, memory |Platform: Linux Cpu: x86-64 | -+-- Comment(by hamish): Replying to [comment:7 sbl]: FYI, 20.8GB is exactly the amount of memory consumption for reading the input maps reported by the top command, when I ran r.stream.basins with memory=1. ok, then the math works. :-) can someone familiar with this module give a 3rd party confirmation that the memory= option is now properly respected? thanks, Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/2356#comment:8 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS GIS 6.4.4 r.li modules
Martin wrote: r.li modules are not simply built on Windows [1]. Any idea why? Martin [1] http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/raster/Makefile#L132 yes, the old r.li.* daemon/worker system required unix sockets, and so would only work in the cygwin build. We never figured out how to properly support those natively on MS Windows. I believe in the new backported version of r.li those things are all removed now so it could have the conditional removed from the Makefile and the modules tested in a nightly WinGrass build. If it works I'd suggest a setup_6.4.4-2.exe release be prepared with an altered Makefile. The source code isn't touched so it wouldn't introduce any platform dependent behavior which would need a new point release, instead it would only reduce platform differences. Luca: I would thought that author of r.li.* updates checked also availability on Windows. that's all of us; especially big jobs need many testers to check all angles. regards, -- Hamish hamish.webm...@gmail.com . Thought I should join the Yahoo mail diaspora before 30 days worth of my emails got flushed from everyone's spam boxes never to be seen again. In the last weeks some have made it to the ML archives at least, if not to end recipients. Others seem to have just disappeared into /dev/null. It didn't help that the web interface had become an unusable gibberish of broken JavaScript and their IMAP would only transfer the oldest 4% of my inbox. . http://www.ietf.org/mail-archive/web/ietf/current/msg87153.html http://www.spamresource.com/2014/04/up-in-arms-about-yahoos-dmarc-policy.html http://wiki.list.org/pages/viewpage.action?pageId=17891458 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] using rand(x,y) in r.mapcalc (grass7)
On Thu, Jul 3, 2014 at 9:39 AM, Paulo van Breugel p.vanbreu...@gmail.com wrote: Just a quick additional question, how to set this GRASS_RND_SEED from within a python script (I want to add the option to set the seed with a seed parameter in my script, as suggested in the previous email). Concerning the question above, I found out how to do so. I used it in my r.random.weight script (in grass 7 addons svn). This script uses the rand() function in r.mapcalc. But rather than using the same seed (1), there is the option to set the seed, while as default the a time-dependent seed is set. I am sure there are better ways to do this, but it works. On Thu, Jul 3, 2014 at 8:55 AM, Paulo van Breugel p.vanbreu...@gmail.com wrote: On 03-07-14 03:43, Vaclav Petras wrote: On Wed, Jul 2, 2014 at 8:15 PM, Glynn Clements gl...@gclements.plus.com wrote: Shouldn't the seed not be generated on e.g, OS time, which would ensure that each run would give a different result? No. The reason is to provide reproducibility. Anyone running the same command with the same data should obtain the same result. It is certainly be good to be able to reproduce commands. However, I think in most (statistical) software the default / expected behaviour is to have a new automatically generated seed at each run. In R for example, if you have to explicitly specify the seed using the function set.seed(). I would think therefore what most users will expect a similar behaviour in GRASS. It would certainly be my personal preference to have the option to set the seed explicitly if you want reproducibility, but have it generated automatically otherwise. But that is just a personal preference. Does the reproducibility go behind one operating system, compiler or library? I don't think that the first random number is specified by the C language standard. If the results would be really reproducible it would be good for testing framework but I'm afraid that they are not (with my limited knowledge about the topic). If you want a different result each time, set GRASS_RND_SEED to a different value each time, e.g. GRASS_RND_SEED=`date +%N` r.mapcalc a = rand(0,100) [%N is the nanoseconds portion of the current time; this is a GNU extension.] Perhaps this can be explained like this in the manual page? A far better option would be to provide this as a normal parameter so it can be set from the gui interface or command line like any other variable. I've heard that this is not enough on powerful computers/clusters, that you have to use also PID because nanoseconds might be the same (I think I rememberer that it was nanoseconds not seconds). On a related note, it would be nice to be able to set the seed (I think there has been such a request before, but not sure about the answer at that time). GRASS_RND_SEED was the answer. I think there should be some possibility of randomization (auto-setting of seed) build-in the modules providing random(ized) results. Perhaps a flag which would turn it on. It can be also an option which would behave like GRASS_RND_SEED but would have one special value for auto-generating the seed. (GRASS_RND_SEED if present would override this option.) With the default value of the option we should ask a question what is actually the expected behavior of the module giving random results. Yes, that would be great. As for the default value, see my earlier argument. This would provide a nicer interface in Python, standard interface in command line, and possibility to set it in the GUI (which means possibility to set it for users which don't use command line.) Moreover, it would provide all users with the way of setting the random seen in the manner which we consider the best according to our knowledge. Agree. The way to set the seed now may not be understood by everybody and with all the work going into streamlining the GUI, this kind of fairly important options should also be available through the GUI Vaclav ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2358: Strange behaviour with v.net on GRASS GIS 7
#2358: Strange behaviour with v.net on GRASS GIS 7 -+-- Reporter: lluis| Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Vector | Version: svn-releasebranch70 Keywords: Ubuntu 14.04, v.net, attributes |Platform: Linux Cpu: x86-64 | -+-- Hi, I'm working with GRASS GIS 7.0.0svn (r59969) on Ubuntu 14.04 LTS and I'm experiencing a strange behaviour when using v.net. I have set of nodes that I want to connect to a collection of streets on a network. When I execute v.net streets points=libraries out=net op=connect thresh=150 on GRASS GIS 6.4.4, the new arc(s)/line(s) that connect the points to the network, inherit all the attributes (even the 'cat' value) of the pre-existing arcs. But, when I execute the same command on GRASS GIS 7.0.0 that expected behaviour doesn't take place. The new arc(s)/line(s) generated with GRASS 7 doesn't have attributes, a new cat value is generated for each new line but they doesn't appear on the attribute table... -- Ticket URL: https://trac.osgeo.org/grass/ticket/2358 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r61051 - grass/trunk/lib/init
Martin,
Please explain why we need this change. It breaks custom PS1 and aliases in
$HOME/.grass7/bashrc.
Thank you.
Huidae
On Sun, Jun 29, 2014 at 6:22 AM, svn_gr...@osgeo.org wrote:
Author: martinl
Date: 2014-06-29 03:22:23 -0700 (Sun, 29 Jun 2014)
New Revision: 61051
Modified:
grass/trunk/lib/init/grass.py
Log:
grass.py: do not override already set GRASS environmental variables
Modified: grass/trunk/lib/init/grass.py
===
--- grass/trunk/lib/init/grass.py 2014-06-29 10:07:13 UTC (rev 61050)
+++ grass/trunk/lib/init/grass.py 2014-06-29 10:22:23 UTC (rev 61051)
@@ -746,7 +746,17 @@
k, v = map(lambda x: x.strip(), line.strip().split(' ',
1)[1].split('=', 1))
except:
continue
-os.environ[k] = v
+
+evalue = os.getenv(k)
+if evalue:
+if k == 'GRASS_ADDON_PATH':
+os.environ[k] = evalue + os.pathsep + v
+else:
+warning(_(Environmental variable '%s' already set,
ignoring value '%s') % \
+(k, v))
+else:
+os.environ[k] = v
+
# Allow for mixed ISIS-GRASS Environment
if os.getenv('ISISROOT'):
isis = os.getenv('ISISROOT')
@@ -1131,8 +1141,14 @@
path = os.path.join(userhome, .grass.bashrc) # left for backward
compatibility
if os.access(path, os.R_OK):
f.write(readfile(path) + '\n')
-if os.access(grass_env_file, os.R_OK):
-f.write(readfile(grass_env_file) + '\n')
+for env in os.environ.keys():
+if env.startswith('GRASS'):
+val = os.environ[env]
+if ' ' in val:
+val = '%s' % val
+f.write('export %s=%s\n' % (env, val))
+#if os.access(grass_env_file, os.R_OK):
+#f.write(readfile(grass_env_file) + '\n')
f.write(export PATH=\%s\\n % os.getenv('PATH'))
f.write(export HOME=\%s\\n % userhome) # restore user home path
___
grass-commit mailing list
grass-com...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-commit
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r61051 - grass/trunk/lib/init
Also, csh_startup() still overrides already set environment variables.
if os.access(grass_env_file, os.R_OK):
f.write(readfile(grass_env_file) + '\n')
So we have $LOCATION/.bashrc, ~/.grass7/bashrc, and ~/.grass.bashrc. Do
they all have different purposes and are they documented clearly somewhere?
On Fri, Jul 4, 2014 at 3:02 PM, Huidae Cho gras...@gmail.com wrote:
Martin,
Please explain why we need this change. It breaks custom PS1 and aliases
in $HOME/.grass7/bashrc.
Thank you.
Huidae
On Sun, Jun 29, 2014 at 6:22 AM, svn_gr...@osgeo.org wrote:
Author: martinl
Date: 2014-06-29 03:22:23 -0700 (Sun, 29 Jun 2014)
New Revision: 61051
Modified:
grass/trunk/lib/init/grass.py
Log:
grass.py: do not override already set GRASS environmental variables
Modified: grass/trunk/lib/init/grass.py
===
--- grass/trunk/lib/init/grass.py 2014-06-29 10:07:13 UTC (rev
61050)
+++ grass/trunk/lib/init/grass.py 2014-06-29 10:22:23 UTC (rev
61051)
@@ -746,7 +746,17 @@
k, v = map(lambda x: x.strip(), line.strip().split(' ',
1)[1].split('=', 1))
except:
continue
-os.environ[k] = v
+
+evalue = os.getenv(k)
+if evalue:
+if k == 'GRASS_ADDON_PATH':
+os.environ[k] = evalue + os.pathsep + v
+else:
+warning(_(Environmental variable '%s' already set,
ignoring value '%s') % \
+(k, v))
+else:
+os.environ[k] = v
+
# Allow for mixed ISIS-GRASS Environment
if os.getenv('ISISROOT'):
isis = os.getenv('ISISROOT')
@@ -1131,8 +1141,14 @@
path = os.path.join(userhome, .grass.bashrc) # left for backward
compatibility
if os.access(path, os.R_OK):
f.write(readfile(path) + '\n')
-if os.access(grass_env_file, os.R_OK):
-f.write(readfile(grass_env_file) + '\n')
+for env in os.environ.keys():
+if env.startswith('GRASS'):
+val = os.environ[env]
+if ' ' in val:
+val = '%s' % val
+f.write('export %s=%s\n' % (env, val))
+#if os.access(grass_env_file, os.R_OK):
+#f.write(readfile(grass_env_file) + '\n')
f.write(export PATH=\%s\\n % os.getenv('PATH'))
f.write(export HOME=\%s\\n % userhome) # restore user home path
___
grass-commit mailing list
grass-com...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-commit
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [SoC] gsoc2014 grass metadata week 6
Hi Stefan, 2014-07-03 18:22 GMT+02:00 Blumentrath, Stefan stefan.blumentr...@nina.no: Hei Madi, Thanks for your clarification. Very interesting! I see I have to take a closer look on pycsw and it`s front-ends (as a possible alternative to GeoNetwork). The pycsw documentation [1] says that also pycsw Metadata repositories are set up with a database backend (SQLite, PostgreSQL, and even PostGIS support). However, integration with data portal solutions like e.g. GeoNode or Open Data Catalogue is unfortunately “read-only” meaning that meta-data can be only queried [2]. Would be nice if metadata from GRASS could somehow go directly into a geodata portal (and that the other way around e.g. people, keywords … could be fetched from there)… (BTW, in the proprietary world such a functionality requires yet another extension: https://www.geocat.net/bridge/) For organization with a geodata portal solution it is maybe possible to just sync pycsw`s DB with a DB from e.g. GeoNode or so, if one wants to have that consistent… If you allow me two more questions in this regard: Will pycsw become a dependency for GRASS (with metadata support)? Yes it is. Currently there are no packages for Debian. Pycsw has dependency on SQLalchemy, shapely and pyproj. I have info that debian package will probably be created during a few months. And will it be necessary, that pycsw runs on the same computer as GRASS (meaning also one pycsw for each GRASS installation) or could that somehow be centralized (in other words that GRASS connects to a central pycsw)? Yes of course, the pycsw is providing csw catalogue which can run on a local pc (localhost) or on a server. Our vision is to make an interface based on OWSLib and pycsw which produces essential functions like browsing based on filtering, harvesting and publishing metadata to csw catalogue. The user will be able to choose csw catalogue target like a localhost(probably SQLite) or catalogue on internet. This task will part of GSOC term and after... Thank you, Matej ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] gsoc2014 grass metadata week 7
Hi all, Below is my weekly report: *work done* - created gui generator from jinja template with conection to OWSLib. - this generator connects objects and loops from jinja with xml loaded by OWSLib. *work to be done in the next week* - to add functionality for reading ISO keywords - to implement functionality for saving edited metadata *blocks* a bit. Best, Matej ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
