See also: https://grasswiki.osgeo.org/wiki/Location_and_Mapsets
There you find a detailed description of how to link mapsets...
-Original Message-
From: grass-user-boun...@lists.osgeo.org
[mailto:grass-user-boun...@lists.osgeo.org] On Behalf Of Dylan Beaudette
Sent: 8. oktober 2015 00:50
Hi Dylan,
Yes, r.external and r.external.out works pretty well with TGIS. Here is a
discussion in this regards I had mainly with Sören…
https://lists.osgeo.org/pipermail/grass-user/2013-December/069377.html
I have used r.external/r.external.out in TGIS for a while (with compressed
GeoTiffs, btw
On Oct 7, 2015 10:36 PM, "Vaclav Petras" wrote:
> On Wed, Oct 7, 2015 at 2:28 PM, Markus Neteler wrote:
> > Please read manual or source code.
>
> I should probably do that, but the message should encourage user to read
the manual. The current message is not informing about the the problem.
Look
On Wed, Oct 7, 2015 at 3:39 PM, Glynn Clements wrote:
>
>
> Dylan Beaudette wrote:
>
> > It has been a while, but glad to be back on GRASS-user.
> >
> > I am working on a project that involves a significant storage dilemma: try
> > and fit most of the files into a 500 Gb SSD for blazing-fast I/O,
Dylan Beaudette wrote:
> It has been a while, but glad to be back on GRASS-user.
>
> I am working on a project that involves a significant storage dilemma: try
> and fit most of the files into a 500 Gb SSD for blazing-fast I/O, or fall
> back to a standard but higher capacity disk drive.
>
> Wo
The use of r.external makes a lot of sense when dealing with very large
files. Does the use of "external" files work as expected in all of the new
t.* modules?
Thanks,
Dylan
On Wed, Oct 7, 2015 at 12:09 PM, Markus Neteler wrote:
> On Wed, Oct 7, 2015 at 12:55 PM, Blumentrath, Stefan
> wrote:
>
Hi,
It has been a while, but glad to be back on GRASS-user.
I am working on a project that involves a significant storage dilemma: try
and fit most of the files into a 500 Gb SSD for blazing-fast I/O, or fall
back to a standard but higher capacity disk drive.
Would it be possible to store "deriv
I'm sorry Markus. I'm just trying to do a thorough code review.
On Wed, Oct 7, 2015 at 2:28 PM, Markus Neteler wrote:
>
> On Wed, Oct 7, 2015 at 7:07 PM, Vaclav Petras
wrote:
> > On Wed, Oct 7, 2015 at 11:50 AM, Markus Neteler
wrote:
> ...
> > However, here again, even when I leave aside the di
On Wed, Oct 7, 2015 at 12:55 PM, Blumentrath, Stefan
wrote:
...
> My suggestion is to not use PostGIS for big rasters, unless you have to,
> because you want to use the data in a specific application for example.
Note r.external and r.external.out of GRASS GIS 7 for avoiding data duplication:
ht
It is especially good news that GRASS compiles in El Capitan. I cannot use
HomeBrew for binaries for distributions, but this means that I should be able
to compile it after upgrading. Nonetheless, I’ll do at least one more binary
compiled under Yosemite.
Michael
C. Michael
On Wed, Oct 7, 2015 at 7:07 PM, Vaclav Petras wrote:
> On Wed, Oct 7, 2015 at 11:50 AM, Markus Neteler wrote:
...
> However, here again, even when I leave aside the discussion above, there is
> a typo:
>
> G_warning(_("Input vector map <%s> is 3D"), opt.from->answer);
> G_warning(_("Input vector
On Wed, Oct 7, 2015 at 8:17 PM, Maris Nartiss wrote:
> Second error indicates on a misconfigured system.
> Add to ~/.bash_profile:
> export LC_ALL=en_US.UTF-8
> export LANG=en_US.UTF-8
>
> https://coderwall.com/p/-k_93g/mac-os-x-valueerror-unknown-locale-utf-8-in-python
It is also here:
https://
On Wed, Oct 7, 2015 at 11:50 AM, Markus Neteler wrote:
>
> On Wed, Oct 7, 2015 at 3:47 PM, Vaclav Petras
wrote:
> > On Wed, Oct 7, 2015 at 4:19 AM, Markus Neteler
wrote:
> > Why it is a warning and not a message?
>
> Because due to the bug it doesn't work.
> once the bug is fixed, we can "downgr
On Wed, Oct 7, 2015 at 3:47 PM, Vaclav Petras wrote:
> On Wed, Oct 7, 2015 at 4:19 AM, Markus Neteler wrote:
> Why it is a warning and not a message?
Because due to the bug it doesn't work.
once the bug is fixed, we can "downgrade" to a message or even remove it.
> Does the message really expla
On Wed, Oct 7, 2015 at 4:32 AM, Moritz Lennert wrote:
> Of course
>> https://trac.osgeo.org/grass/ticket/2734
>> remains - will you submit that change?
>>
>
> I have the feeling that the second proposed solution, i.e. "introduce a 2D
> version of the Vect_point_in_box function which checks x and
Ops! My bad! Sorry...
Thanks Sören for clarifying this issue...
---
#2735: t.rast.mapcalc input problem
--+
Reporter: leohardtke | Owner: grass-dev@…
Type: defect | Status: reopened
Priority: normal | Milestone: 7.0
On Wed, Oct 7, 2015 at 4:19 AM, Markus Neteler wrote:
>
> On Mon, Sep 7, 2015 at 8:14 AM, Markus Neteler wrote:
> > On Sep 7, 2015 3:58 AM, "Anna Petrášová" wrote:
> > ...
> >
> >> it took me a while to figure out the problem, but it's because your
> >> samples are 3D and the stand vector is not
Hi Lorenzo,
My suggestion is to not use PostGIS for big rasters, unless you have to,
because you want to use the data in a specific application for example.
Loading raster to PG is a performace killer if you want to analyse the raster
in GRASS (if that is possible at all)…
You can have the vect
Hello everyone,
I not very expert in this field and searching on the web didn't clarify my
dubs.
I wanted to store a raster DEM and some vectors map in to an external DB,
GRASS will use the DEM in order to calculate various raster map of solar
radiation and need to store the again in the external
Hi Radim,
Personally, I do not rely on the buttons in the toolbar, so I have no
objections to remove them from the toolbar.
Consistent UI (comparable to Processing) seems an appropriate priority...
Just some ideas for possible solutions:
"Show Region button" might go into the "Region tab" in the
We are discussing possible UI cleanup related also to GRASS:
https://hub.qgis.org/issues/13537
Questions for plugin users:
- Can be open/new/close items removed from the toolbar? There is a
possibility to open mapset from browser and close it from tools dock
widget and there are menu items for al
After updating,
wxpython not working here but tcltk still works (grass 6.4 from kyngchaos), see
below for results with 7.1
Launching 'wxpython' GUI in the background, please wait ...
Traceback (most recent call last):
File "/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/wxgui.py", line
On 07/10/15 10:19, Markus Neteler wrote:
On Mon, Sep 7, 2015 at 8:14 AM, Markus Neteler wrote:
On Sep 7, 2015 3:58 AM, "Anna Petrášová" wrote:
...
it took me a while to figure out the problem, but it's because your
samples are 3D and the stand vector is not.
We just got here into the same
Michael Barton writes:
> But it was never clear what was and was not working. We have this
> working fine in Yosemite. So far, you are the only ones to report a
> problem with Yosemite. The problem we are reporting now is that it was
> running on Yosemite and not running on El Capitan. Maybe that
On Mon, Sep 7, 2015 at 8:14 AM, Markus Neteler wrote:
> On Sep 7, 2015 3:58 AM, "Anna Petrášová" wrote:
> ...
>
>> it took me a while to figure out the problem, but it's because your
>> samples are 3D and the stand vector is not.
We just got here into the same "trap".
>> If you convert the samp
Hi Stefan
I see the problem, but have no solution for the organization in GRASS.
Concerning PostgreSQL- our data are in different schemas, to allow for
access of all within our SQL-code. Example: One schema for initial data
and others for processed data or different Versions. Views are used to
26 matches
Mail list logo
