Seen this: https://bitbucket.org/huhabla/open-graas?
Cheers
Stefan
Von: grass-dev [grass-dev-boun...@lists.osgeo.org] im Auftrag von Maris Nartiss
[maris@gmail.com]
Gesendet: Donnerstag, 25. Mai 2017 09:42
An: Pietro
Cc: GRASS developers list
Betreff:
Hi,
To me this looks like checkinstall is failing caus not all required
metainformation is given.
See: https://manpages.debian.org/jessie/checkinstall/checkinstall.8.en.html
Try specifying amongst others - -pkgversion
Hope that helps...
Cheers
Stefan
To: Blumentrath, Stefan <stefan.blumentr...@nina.no>; Luca Delucchi
<lucadel...@gmail.com>
Cc: GRASS-dev <grass-dev@lists.osgeo.org>; Manan Singh <mananpa...@gmail.com>
Subject: Re: [GRASS-dev] Introduction for GSoC 2017
Hi Stefan,
the first throw is there in SVN, just update an
n Wed, Mar 29, 2017 at 5:30 AM, Markus Neteler
<nete...@osgeo.org<mailto:nete...@osgeo.org>> wrote:
On Wed, Mar 29, 2017 at 9:42 AM, Luca Delucchi
<lucadel...@gmail.com<mailto:lucadel...@gmail.com>> wrote:
> On 29 March 2017 at 08:58, Blumentrath, Stefan
> <stefan.blume
> I would like to have something similar to r.modis for sentinel data... :-)
Sentinel (or more general Copernicus) data could be a very good case as it
comes - in contrast to many other open data - with a dedicated and stabe API
for downloading:
Maybe enough (best) to handle it in the manual?
Meaning, add that information to the notes?
Users can avoid that lines/boundaries are broken by running v.dissolve in
advance if needed?
Cheers
Stefan
___
grass-dev mailing list
Hi Zeke,
I cannot offer to mentor your project, but I could make some shell scripts
available for you, that turn publicly available data into GRASS Locations and
mapsets.
It is not really much, but depending on the approach you choose they might be a
helpful startingpoint.
BTW. comparable
ngh <mananpa...@gmail.com>;
Blumentrath, Stefan <stefan.blumentr...@nina.no>
Subject: Re: [GRASS-dev] Introduction for GSoC 2017
Hi all,
I have added to SVN trunk one of the two missing gui modules of i.ortho.photo
recently: g.gui.iphoto2image at the command line launches it. All other modules
Hi,
Could also porting (competition) of the i.ortho.photo modules (and here
especially the missing GUI modules around it) to GRASS 7 become scope of this
GSoC idea?
Workflows from GRASS 6 could be improved a bit in that context quite a bit too,
e.g.:
- Having both image and target
...@lists.osgeo.org] On Behalf Of
Blumentrath, Stefan
Sent: mandag 6. mars 2017 15.57
To: Vincent Bain <b...@toraval.fr>
Cc: GRASS developers list (grass-dev@lists.osgeo.org)
<grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] r.in.gdal and xargs
I can parallelize on a higher level, so i can set
Thanks Vincent for your swift reply.
In principle the pipe to xargs works, as 99% of the data is imported properly.
And also in the case were I get roors, the command is started properly...
Thus, I suspect that r.in.gdal can have issues when run in parallel; or the
creation of temp files, in
Dear all,
I am trying to import time series data using a combination of xargs an r.in
gdal:
cat current_datasets_age.txt | awk -v U="myunits" -v N="name" '{ print
"r.in.gdal input=$1 ".bil output=" $2 "_tmp title=\"" N " in " U " at " $3 "\"
--o --q -o\0"}' | xargs -P 10 -I {} -0 bash -c {}
Hi,
If you are n latest GRASS 7.2.1svn, maybe you hit this one:
https://trac.osgeo.org/grass/ticket/3270
Cheers
Stefan
-Original Message-
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Paulo
van Breugel
Sent: torsdag 2. februar 2017 08.20
To: Vincent Bain
Thanks, quite some interesting GSoC ideas.
I took the liberty to add one on “tools for generating unit tests from examples
in module manuals”. Not sure if that is feasible or out of scope. Please feel
free to remove it if you don`t find it suitable (I can`t mentor it anyway).
Regarding:
]
Sent: onsdag 25. januar 2017 21.18
To: Luca Delucchi <lucadel...@gmail.com>
Cc: Blumentrath, Stefan <stefan.blumentr...@nina.no>;
carlos.grohm...@gmail.com; grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] [GRASS GIS] #3269: r.roughness.vector: bug in rescale
formula
Hi,
There seem
Hi,
Another related question: There are now two AddOns for this purpose:
r.roughness.vector (last changed 2 years ago)
and from 2016: r.vector.ruggedness
Both basically calculate the same metric(s), though they have their differences
and both have their pros:
r.roughness.vector offers more
Hi Nikos/devs,
Currently, I am Co-supervising a student who is using i.landsat8.swlst module
for his bachelor thesis.
During that work we stumbled upon some minor issues where we would like to
propose some changes in the module:
- The k-flag does the opposite of what the description
ta (points) in PostGIS...
Cheers
Stefan
-Original Message-
From: Martin Landa [mailto:landa.mar...@gmail.com]
Sent: lørdag 14. januar 2017 17.06
To: Blumentrath, Stefan <stefan.blumentr...@nina.no>
Cc: GRASS developers list (grass-dev@lists.osgeo.org)
<grass-dev@lists.osgeo.org>
S
Forgot to ask: could this go into the release branch none the less (you
recently changed milestone to 7.4)?
-Original Message-
From: Martin Landa [mailto:landa.mar...@gmail.com]
Sent: lørdag 14. januar 2017 17.06
To: Blumentrath, Stefan <stefan.blumentr...@nina.no>
Cc: GRASS deve
Hi Martin,
Thanks for the hint. Will do so...
Cheers
Stefan
-Original Message-
From: Martin Landa [mailto:landa.mar...@gmail.com]
Sent: onsdag 11. januar 2017 11.26
To: Blumentrath, Stefan <stefan.blumentr...@nina.no>
Cc: GRASS developers list (grass-dev@lists.osgeo.org)
<
: mandag 9. januar 2017 18.17
To: Blumentrath, Stefan <stefan.blumentr...@nina.no>
Cc: GRASS developers list (grass-dev@lists.osgeo.org)
<grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] v.external: ID confusion
Hi Stefan,
2017-01-09 16:42 GMT+01:00 Blumentrath, Stefan <stefan.blum
connection properly after the module
finishes... Or are there other possible explanations?
Where should I look to find the source of the issue?
Ciao,
Stefan
-Original Message-
From: Martin Landa [mailto:landa.mar...@gmail.com]
Sent: tirsdag 10. januar 2017 15.39
To: Blumentrath, Stefan
...
Segmentation fault (core dumped)
Ciao,
Stefan
-Original Message-
From: Martin Landa [mailto:landa.mar...@gmail.com]
Sent: tirsdag 10. januar 2017 12.40
To: Blumentrath, Stefan <stefan.blumentr...@nina.no>
Cc: GRASS developers list (grass-dev@lists.osgeo.org)
<grass-dev@lists.osgeo.org
Hi again,
Is there any reason that v.what.rast requires topology level 2? "r.what" works
without topology...
Cheers
Stefan
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hi,
I tried to link a PG table to GRASS for point sampling using v.external (in
GRASS 7.0.6).
With that linked layer (which is not in public schema and has column "point_id"
as primary key) I get a lot of:
WARNING: No record for category in table
when I use v.what.rast on that
Hi,
I had some trouble with r.stream.basins which labeled all basins created with
points option as -1.
After some investigation I found out that the problem was that my vector points
map only had categories on layer 2.
After transferring the categories to layer 1 everything worked fine. During
Depends what you are planing to do in more detail. But maybe the pygrass Vector
or VectorTopo module could be of help...
https://grass.osgeo.org/grass70/manuals/libpython/pygrass_vector.html
Cheers
Stefan
Von: grass-dev [grass-dev-boun...@lists.osgeo.org]
Hei,
What about something like this (example converts from UTM33 to WGS84 and
creates ):
r.stats -gn1 INPUTMAP | cs2cs -E -f "%.6f" +proj=utm +no_defs +zone=33
+a=6378137 +rf=298.257222101 +towgs84=0.000,0.000,0.000 +to_meter=1 +to
+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs | tr '\t' ' '
-Original Message-
From: Moritz Lennert [mailto:mlenn...@club.worldonline.be]
Sent: torsdag 1. desember 2016 00.01
>>
>>BTW, I think several modules would benefit from a -b do not build
>>topology...
>Which other modules are you thinking about?
>Moritz
All modules which produce
limited to SLD v1.0.0.
The produced SLDs validate without issues in GeoServer, but further testing is
very welcome...
Mvh
Stefan
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of
Blumentrath, Stefan
Sent: 21. november 2016 14:07
To: GRASS developers list (grass-dev
Hi,
In order to get some of my data properly from GRASS into GeoNode (which is
based on GeoServer) I would like to also export the GRASS color tables into
SLD, so I can import them to GeoServer too.
I found the r.colors.out_sld AddOn
is fetched from:
https://trac.osgeo.org/grass/wiki/Release/7.2.0-News
Cheers
Stefan
-Original Message-
From: Anna Petrášová [mailto:kratocha...@gmail.com]
Sent: 30. september 2016 00:12
To: Blumentrath, Stefan <stefan.blumentr...@nina.no>
Cc: GRASS developers list (grass-dev@lists.osg
-Original Message-
From: Moritz Lennert [mailto:mlenn...@club.worldonline.be]
Sent: 21. oktober 2016 11:30
>> However, it seems that for raster maps more special characters are
>> legal and also v.in.ogr uses layer names from the original data
>> source which can cause conflicts in SQL DB
Yes, but in vector maps starting with a number or having a "." in the name is
not allowed. Also SQL keywords are excluded...
See: https://grass.osgeo.org/programming7/legal__vname_8c_source.html
So, the same logic may be used to check column names (I guess that is what
Markus intended).
Hi again,
Interesting discussion!
With my user and amateur addon-developer perspective I would conclude that:
- we all agree that tests/unittests are very useful even if not "the silver
bullet"
- things one does in "unittests" might also partly be done in the code of the
module (e.g. check for
Agreed with Paulo.
My impression is that new users rely on the menu to explore the software and
its modules...
From: Paulo van Breugel [mailto:p.vanbreu...@gmail.com]
Sent: 7. oktober 2016 13:35
To: Moritz Lennert <mlenn...@club.worldonline.be>; Blumentrath, Stefan
<stefan.blumentr..
eward" for an addon
developer, thus it might be an incentive to e.g. add tests, documentation ...
- it might also help to motivate / involve more devs to contribute to core
development?
Cheers
Stefan
-Original Message-
From: Moritz Lennert [mailto:mlenn...@club.worldonline.be]
S
Stefan
-Original Message-
From: Anna Petrášová [mailto:kratocha...@gmail.com]
Sent: 6. oktober 2016 00:11
To: Blumentrath, Stefan <stefan.blumentr...@nina.no>
Cc: GRASS developers list (grass-dev@lists.osgeo.org)
<grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev]
Hi,
In the context of https://trac.osgeo.org/grass/ticket/3057 I just tested
g.gui.tplot from GRASS 7.2 (r68908) on a STRDS and got the following error
message:
Traceback (most recent call last):
File "/usr/local/grass-7.2.svn/scripts/g.gui.tplot", line
130, in
main()
File
Sounds fair enough as requirements for new core modules. “Maintainable code”
would in praxis mean “the module has undergone a code review by a core
developer”?
Those requirements would add to Markus requirement of “maturity”, which I would
interpret like “the module has been tested in praxis
Hi,
This discussion is actually a bit old, but maybe it is not too late to consider
adding selected addons to trunk?
>From my personal user point of view the r.streams.* modules and r.geomorphon
>are indeed top candidates for inclusion in core!
However, also:
i.segment.hierarchical (though
to create a new patch for that if you like...
Cheers
Stefan
-Original Message-
From: Anna Petrášová [mailto:kratocha...@gmail.com]
Sent: 29. september 2016 15:20
To: Blumentrath, Stefan <stefan.blumentr...@nina.no>
Cc: GRASS developers list (grass-dev@lists.osgeo.org)
<
Hi,
It seems that t.connect and t.rast.what have not been added to the GUI (both in
G73 and G72)!
Please find attached a patch where I tried to add them. Hope that is the proper
way.
I placed t.connect under temporal, but it might be better suited under
Database, don't now...
Cheers
Stefan
Hi,
I have been struggling with similar issues and solved them by writing a
GRASS_BATCH_JOB script that I execute in parallel in different mapsets.
Thus, the approach Markus and Sören sketch looks very useful to me (even for
people who are not on HPC).
Do you have more options / flags in mind
Hei Laurent,
What about using the --exec magic from > GRASS 7.2?
https://grass.osgeo.org/grass72/manuals/grass7.html#batch-jobs-with-the-exec-interface
(or the GRASS_BATCH_JOB solution)?
Cheers
Stefan
-Original Message-
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On
Hei Laurent,
Not sure about python, but in bash you have to add this:
#For the temporal modules
export TGISDB_DRIVER=sqlite
export TGISDB_DATABASE=$MYGISDBASE/$MYLOC/PERMANENT/tgis/sqlite.db
to your script in order to make TGIS work when using GRASS modules withot
starting GRASS explicitly...
-Original Message-
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of
Blumentrath, Stefan
Sent: 18. september 2016 23:29
To: Helmut Kudrnovsky <hel...@web.de>; grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] v.in.pygbif addon: Manual does not build
Thanks
Thanks Helmut, Vaclav, Markus for your support.
Should be fixed now (by moving the import to "dev main()").
I would have liked to do it earlier but we had a failure on the server where I
had the code...
Kind regards,
Stefan
-Original Message-
From: grass-dev
Thanks Martin,
Would be great if you could forward the mail, as I am not on that ml...
Cheers
Stefan
-Original Message-
From: Martin Landa [mailto:landa.mar...@gmail.com]
Sent: 16. september 2016 14:18
To: Blumentrath, Stefan <stefan.blumentr...@nina.no>
Cc: GRASS developer
Hei Martin,
Do you have any chance to influence the naming of the PPAs?
As recently also discussed on the QGIS mailinglist, packages from a repository
named "unstable" can get blocked by system administrators (who not necessarily
will take the time to try to understand what is behind all
Hei,
Does anyone have an idea why the v.in.pygbif addon-manual does not build? I
managed to install it through g.extension and it works fine.
The pygbif library is a dependency of v.in.pygbif. Therefore, I tried to align
dependency handling (import) with the working solution in v.class.mlpy as
Hei Sören,
I ran into this recently too, with lots of “Busy SQLite” warnings, when I tried
to modify two or more vector maps in parallel.
So the work you are planning to do would be very much appreciated.
However, in order to not break existing modules like v.db.join, queries across
SQLite DBs
Hi devs,
I am trying to access the Bbox of my current region in pygrass (GRASS 7.0.4),
following examples here:
https://grass.osgeo.org/grass70/manuals/libpython/pygrass.gis.html#module-pygrass.gis.region.
Unfortunately, "north" returns always 1, for some reason I do not understand...
This is
Dear Code-sprinters (and others),
Thanks for the awesome event and the great time in Bonn!
It was really exciting and a lot of fun working together with all of you. The
experience definitely - more than - compensated travel costs and conference fee!
With the kind support from Lucca and Vero,
Hi,
As a side note:
The shell script output of v.db.connect is not “parsable” like in g.region
(n=...) either.
However, it is well formatted as a kind of table output...
Cheers
Stefan
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Jachym
Cepicky
Sent: 22. august
Hi Mayank,
Thanks for WebGRASS! I am glad we can test it and thanks also for fixing the
compilation issue so fast!
For me it would be absolutely OK that www-users cannot browse the whole server
for GRASS DBs. And that all WebGRASS users are forced to work in one DB might
be almost a pluss -
Hi,
At the moment I am fixing and quality checking relatively larger vector
datasets with some 100k areas, of which some are quite complex (sea area /
coast line). That requires visual inspection of the data and thus repeated
rendering at different scales.
In this context I am struggling with
Hei,
In the light of the ongoing GSoC projects (esp. Web-GRASS) and recent questions
regarding python syntax for GRASS commands, I was wondering what you think
about the idea to offer the option to copy the command from the GUI (using the
"Copy"-button) in other syntax than command line (e.g.
Already possible. See: https://grass.osgeo.org/grass70/manuals/grass7.html
Von: grass-dev [grass-dev-boun...@lists.osgeo.org] im Auftrag von GRASS GIS
[t...@osgeo.org]
Gesendet: Freitag, 10. Juni 2016 19:40
Betreff: [GRASS-dev] [GRASS GIS] #3060: Create
> Side question: do the parser rules include flags ? I thought they were only
> available for options.
Actually, I have no idea. I just checked the add-ons I wrote, and saw that I
only used them for options. I was not aware of this limitation...
Thanks for pointing that out...
Cheers
Stefan
Hei,
And thanks for your work on the PyQT-GSoC project!
When it comes to possible GUI improvements, I am wondering if it would be
feasible to take e.g. parser rules into account by means of either
a) generating widgets depending on parser rules (if e.g. two flags are
mutually exclusive,
Hei Mayank and Rashad,
And thanks for this very cool GSoC project!
Do you take some inspiration from RStudio Server? We use it and are quite happy
with it. Nice features there are (for my taste) the editor, the console and
git/svn integration? And also GRASS is most sexy with the command line
is welcome...
Kind regards,
Stefan
-Original Message-
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of
Blumentrath, Stefan
Sent: 10. mai 2016 09:57
To: Nikos Alexandris <nikos.alexand...@unige.ch>; Vaclav Petras
<wenzesl...@gmail.com>
Cc: grass-dev@lists
ked as it should...
Kind regards,
Stefan
-Original Message-
From: Nikos Alexandris [mailto:nikos.alexand...@unige.ch]
Sent: 9. mai 2016 16:31
To: Vaclav Petras <wenzesl...@gmail.com>
Cc: Nikos Alexandris <n...@nikosalexandris.net>; Blumentrath, Stefan
<stefan.
Dear Nikos,
I just tested your i.landsat8.swlst module. Cool stuff!
During my experiments I ran into one issue and identified some (minor) room for
speed-ups (mainly replacing g.copy with g.rename). I did not do a full code
review but made some suggestions in a pull request on github. I
Hi,
Seems a bit like an edge case with shell scripts on Windows...
Anyway, what about using a script to do the replacement?
Something like (did not test the details):
scripts=$(ls OSGeo4W/apps/grass/grass-7.0.3/scripts/*.py | sed 's/.\{4\}$//')
cp MY_OLD_GRASS_6_SCRIPT.sh
Hi,
A user perspective on this discussion:
I would be very, very keen on:
- this: https://trac.osgeo.org/grass/ticket/2579 (as well as the simple python
import that is under development) and
- this: https://grasswiki.osgeo.org/wiki/ISO/INSPIRE_Metadata_Support and
- this:
Hei,
I had similar issues recently.
Just now I tested again (fresh code for both GRASS 71 and AddOns) and the
metadata tools seem to work.
However, I get still get an error message on compile:
[...]
GISRC=/usr/local/grass-7.1.svn/demolocation/.grassrc71
GISBASE=/usr/local/grass-7.1.svn
Hi,
That might be a reasons to think about a general, unified option regarding
integer, floating point or double output.
Markus`s solution in r.bioclim could be very useful in other modules too. Esp.
those that produce a lot of data and default to double. Here I think e.g. about
r.sun which
...@gmail.com]
Sent: 17. februar 2016 13:39
To: Blumentrath, Stefan <stefan.blumentr...@nina.no>; Matej Krejci
<matejkre...@gmail.com>
Cc: GRASS developers list <grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] grass addons metadata temporary not available
Hi,
2016-02-17 13:33 GMT+
Hei Martin,
Thanks for your work on the wx.metadata installation.
Do you by chance have any idea what the reason might be that it does not work
for me?
See:
http://osgeo-org.1560.x6.nabble.com/problem-installing-wx-metadata-from-g-extension-tp5244519p5249845.html
Or how I might solve the issue
Hi,
I tried building from source after installing the dependencies listed here:
https://grasswiki.osgeo.org/wiki/ISO/INSPIRE_Metadata_Support#Requirements_and_installation
plus python-reportlabs.
But I get an error for g.gui.metadata saying
“Traceback (most recent call last):
File
Hi,
I am looking into PostgreSQL as an alternative for SQLite at the moment.
However I am missing an option to make PostgreSQL the default DB backend for
all users on a Server installation of GRASS GIS. The db.connect manual says
connection parameters are stored in the mapset`s VAR file. Did I
Agreed.
Such a “main” tab maight also be helpful to generate the GUI of the
QGIS-GRASS-Plugin more automatically so that module updates can be passed more
easily to QGIS. I contributed to update of the module files (.qgm) which aimed
exactly at reducing complexity (though some modules got
Hi Sören,
Thanks for your reply.
I shall think about a temporal DB and how it might be used in order to interact
with TGRASS...
The GRASS data explorer for QGIS looks indeed cool...
Cheers
Stefan
___
grass-dev mailing list
grass-dev@lists.osgeo.org
Hi devs,
The TGRASS concept is a great enhancement to GRASS which already proved it`s
usefulness for my daily work with raster data in many cases. Now I am
discovering the vector part of it. If I understand correctly, the concept for
vector data is identically to the raster part, namely using
Hi Martin,
Thanks for following this up. I am travelling at the moment. Shall try it once
I am back...
Cheers
Stefan
-Original Message-
From: Martin Landa [mailto:landa.mar...@gmail.com]
Sent: 28. oktober 2015 23:46
To: Blumentrath, Stefan <stefan.blumentr...@nina.no>
Cc: Pau
Hei Vero,
Did you go through the advanced install in OSGeo4W? There you should have the
“qgis-grass-plugin7” (and probably also necessary “qgis-grass-plugin-common”)
available.
For the shell issue you can have a look here:
https://lists.osgeo.org/pipermail/grass-dev/2014-October/071294.html
Hi again,
The following threads can possibly be additional sources for inspiration:
http://www.qgis.nl/2014/04/22/qgis-in-de-klas-onder-windows/?lang=en
https://lists.osgeo.org/pipermail/qgis-user/2015-February/030837.html
http://linfiniti.com/2011/05/building-custom-qgis-installers-for-windows/
t.S_IEXEC)
# start module
os.system(startcmd)
os.remove(s.name<http://s.name>)
Let me know if this works under Windows too.
Michel
On 10/12/2015 12:55 PM, Blumentrath, Stefan wrote:
Hi again,
Now I found out that the parser section in the inner python script was not
formated pr
Hi,
I would like to fill:
#% options:
and
#% answer
in a parser option for a python script dynamically. In particular I want to
have tickboxes for available mapsets in the module GUI...
Meaning something like this (but less complex / not interactive):
or GRASS_ADDON_BASE variable.
It was neither possible to run the script using grass.run_command() (on
Windows).
Cheers
Stefan
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of
Blumentrath, Stefan
Sent: 12. oktober 2015 11:36
To: GRASS developers list (grass-dev@lists.osgeo.org)
<gr
Hi Martin,
Thanks for your patience.
Here is my shell output:
GRASS 7.1.svn (ETRS_32N):~/data_maintenance > env | grep GIS
GISRC=/tmp/grass7-stefan-19203/gisrc
GISBASE=/usr/local/grass-7.1.svn
GIS_LOCK=19203
GRASS 7.1.svn (ETRS_32N):~/data_maintenance > env | grep GRASS
GRASS_PYTHON=python
Hi,
What about a flag for checking if all polygon categories are present in the
raster version of the vector map, and giving a warning if that is not the case.
That will take more time but makes output more reliable.
Maybe one can - in case of non-rasterized polygons/lines - edit the raster
>From my experience the need for internationalization varies very much and
>depends on a lot of things (one of them is culture and exposure to foreign
>esp. English language).
Here in Norway, I guess no one would really miss a translation to Norwegian, as
e.g. kids-TV, movies in the Cinema, and
Cool! I am inn (if nothing unpredictable happens)!
I could also imagine to work on something like the "GRASS GIS locations created
from public data" idea for GSoC 2014/2015:
https://trac.osgeo.org/grass/wiki/GSoC/2015
Cheers
Stefan
-Original Message-
From:
be different from what he or she expects)!?
Anyway, if you consider it a useful feature I will open a ticket …
Cheers
Stefan
From: Anna Petrášová [mailto:kratocha...@gmail.com]
Sent: 10. september 2015 15:44
To: Blumentrath, Stefan <stefan.blumentr...@nina.no>
Cc: GRASS developers list (gra
Hi,
For the QGIS-GRASS-plugin update Radim, Pedro, Andrew and me were discussion
how to implement multiple selections for map input in the UI in QGIS.
In this context I was thinking that the ability to use wildcards would be
really handy for GRASS newcomers. People who are not afraid of the
Hi Michael,
The second sentence you cite from the manual seems indeed a bit imprecise.
It should probably say something like:
“The extent of all resulting raster maps is taken from the settings of the
current region (which may be different from the extent of the input raster
map). The
of Europe (and
INSPIRE compliant)…
Anyway, the first glimpse I got from g.gui.metadata looked promising! Thanks
for your work on that!
Cheers
Stefan
From: Matej Krejci [mailto:matejkre...@gmail.com]
Sent: 25. august 2015 08:39
To: Blumentrath, Stefan stefan.blumentr...@nina.no
Cc: GRASS-dev grass-dev
[mailto:matejkre...@gmail.com]
Sent: 21. august 2015 14:43
To: Blumentrath, Stefan stefan.blumentr...@nina.no
Cc: GRASS-dev grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] g.gui.metadata and wxgui addons in GRASS 7.1
Dear Stefan,
Thanks for bug report. I have done few changes(r65990) which should help
Hi,
I just tried to install g.gui.metadata addon with limited success.
No AddOn appears under wxGUI when I run g.extension from the GUI (while e.g.
raster addons do show up). Is this probably do to the path in the AddOn repo
(which starts with gui and not wxGUI). All other tree elements in
Hi Anita,
For more sophisticated network analysis I tend to use igraph:
http://igraph.org/
It is quite easy to understand, well documented, efficient and supports also
calculation of line graphs. It comes with both Python and R APIs.
Usually I feed graphs into it from GRASS (v.net) or PostGIS. I
Dear all,
I tried to extract a river network from a huge DEM:
rows: 180752
cols: 141312
cells: 25542426624
r.watershed (in an older revision of GRASS 7) had no problem with the DEM and
created raster streams very nicely. However, I could not convert them to vector
because
Hi,
I just tried to compile the GDAL-GRASS-plugin 1.11.2 against GRASS 7.0.1 (the
release branch).
It seems that there are some issues with the configure /configure.in file in
the plugin
There .7.0.svn is hard coded in the library links (while the stable release
puts the libraries in a
To: Markus Neteler
Cc: Blumentrath, Stefan; gdal-dev (gdal-...@lists.osgeo.org); GRASS developers
list (grass-dev@lists.osgeo.org)
Subject: Re: [gdal-dev] [GRASS-dev] GDAL-GRASS-plugin 1.11.2
2015-03-30 18:16 GMT+02:00 Markus Neteler nete...@osgeo.org:
The path changed between G6 and G7, it should
Hei Markus,
Assuming you have no attributes for those lines, what about the following
procedure:
1) Turning all to closed line strings into areas in a first step (v.centroids)
and then
2) use some v.to.db (sides option) in order to distinguish inner and outer
boundaries, in other words those
Hei Markus,
Not sure I fully understood you problem...
I guess you don`t have a grouping variable (e.g. a lake ID) for the contour
lines? If you had one, you could probably extract the outer lines based on the
attribute table (get max depth by lake (or min depth, depending on how it is
Hi,
I am struggling with the performance of SQLite (I think), esp. when I use it in
a python loop executed in parallel processes (using xargs) .
I am analyzing characteristics of a relatively large number (270k) of
overlapping lake catchments which were generated in GRASS and now are stored in
Good to hear.
As for the “GRASS GIS locations created from public data” idea, I might be able
to provide some shell scripts to start with and I guess many others have
something similar too. A central question there would be likely licensing of
the data which is not always clear I am afraid?!
1 - 100 of 183 matches
Mail list logo
