grass-user-request@lists.osgeo.org wrote:
Send grass-user mailing list submissions to
grass-user@lists.osgeo.orgTo subscribe or unsubscribe via the World Wide Web, visit
http://lists.osgeo.org/mailman/listinfo/grass-user
or, via email, send a message with subject or body 'help' to
grass-user-request@lists.osgeo.orgYou can reach the person managing the list at
grass-user-owner@lists.osgeo.orgWhen replying, please edit your Subject line so it is more specific
than "Re: Contents of grass-user digest..."Today's Topics:
1. Re: reprojecting ASTER_GDEM r.proj "Error writing segment
file" (Hamish)
2. Re: reprojecting ASTER_GDEM r.proj "Error writing segment
file" (Hamish)
3. Re: reprojecting ASTER_GDEM r.proj "Error writing segment
file" (Nikos Alexandris)
4. Re: [Qgis-user] Re: [OSGeo-Discuss] augmenting donations
(Andreas Neumann)
5. v.db.connect additional attribut table (Falko Engel)----------------------------------------------------------------------
Message: 1
Date: Fri, 3 Jul 2009 18:39:45 -0700 (PDT)
From: Hamish <hamish_b@yahoo.com>
Subject: Re: [GRASS-user] reprojecting ASTER_GDEM r.proj "Error
writing segment file"
To: grass-user@lists.osgeo.org, Nikos Alexandris
<nikos.alexandris@felis.uni-freiburg.de>
Message-ID: <153027.67559.qm@web110009.mail.gq1.yahoo.com>
Content-Type: text/plain; charset=us-asciiNikos wrote:
Allocating memory and reading input map...
ERROR: Error writing segment file
....
--%<---
Allocating memory and reading input map...
100%
Projecting...
WARNING: map [ASTGTM_N41E025_dem] - unable to write row 0
ERROR: Failed writing raster map <ASTGTM_N41E025_dem>
row 0
--%<---
I don't know the cause of your problem, but just to point out
the new 'r.proj memory=' option if you had not noticed it yet.
Maybe that could give some clues. How big is the region?e2fsck?
filesystem permissions problems?Hamish
------------------------------
Message: 2
Date: Fri, 3 Jul 2009 18:43:07 -0700 (PDT)
From: Hamish <hamish_b@yahoo.com>
Subject: Re: [GRASS-user] reprojecting ASTER_GDEM r.proj "Error
writing segment file"
To: grass-user@lists.osgeo.org, Nikos Alexandris
<nikos.alexandris@felis.uni-freiburg.de>
Message-ID: <794440.84524.qm@web110004.mail.gq1.yahoo.com>
Content-Type: text/plain; charset=us-asciiHamish:
How big is the region?
Nikos already wrote:
Input:
Cols: 39601 (39601)
Rows: 28801 (28801)
...Output:
Cols: 32473 (32473)
Rows: 29734 (29735)
try the r.proj memory= option.Hamish
------------------------------
Message: 3
Date: Sat, 04 Jul 2009 03:50:33 +0200
From: Nikos Alexandris <nikos.alexandris@felis.uni-freiburg.de>
Subject: Re: [GRASS-user] reprojecting ASTER_GDEM r.proj "Error
writing segment file"
To: Hamish <hamish_b@yahoo.com>
Cc: grass-user@lists.osgeo.org
Message-ID: <1246672233.16710.19.camel@vertical>
Content-Type: text/plainNikos:
Allocating memory and reading input map...
ERROR: Error writing segment file
....
--%<---
Allocating memory and reading input map...
100%
Projecting...
WARNING: map [ASTGTM_N41E025_dem] - unable to write row 0
ERROR: Failed writing raster map <ASTGTM_N41E025_dem>
row 0
--%<---
Hamish:
I don't know the cause of your problem, but just to point out
the new 'r.proj memory=' option if you had not noticed it yet.
Maybe that could give some clues. How big is the region?
Yes, the region is eXtremely BIG (greek raster grid at 30m == 51 aster
gdem tiles):rows: 25848
cols: 30204
cells: 780712992e2fsck?
I though linux is taking care of thatfilesystem permissions problems?
I am convinced that it's not a permission(s) problem since the
one-tile-at-a-time re-projection worked (read last post in "my"
monologue-thread. It failed with a very high resolution and other apps
running at the same time.------------------------------
Message: 4
Date: Sat, 04 Jul 2009 10:00:12 +0200
From: Andreas Neumann <a.neumann@carto.net>
Subject: [GRASS-user] Re: [Qgis-user] Re: [OSGeo-Discuss] augmenting
donations
To: OSGeo Discussions <discuss@lists.osgeo.org>
Cc: grass-user <grass-user@lists.osgeo.org>, qgis-user
<qgis-user@lists.osgeo.org>
Message-ID: <4A4F0C0C.30904@carto.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowedHi all,
I would like to discuss the sponsoring issue a little bit. For GIS managers that are not in direct charge of their budgets but need to discuss/approve their budget with their bosses/supervisors, I can say that:
* It is relatively easy to raise money for development work of concrete features that are to be implemented - bosses usually see a direct value out of this - and they are already used to pay non-open-source corporations for their specific development efforts anyway
* it is harder to raise money for bug-fixing - managers are often used to pay subscription fees or support contracts to commercial vendors, but usually aren't used to paying money to fix bugs
* it is very hard to justify donations - as bosses usually don't understand the open-source model fully - and often don't see their responsibilities as a user of an open-source projectI am just trying to help you guys to understand how government agencies or companies often work (exceptions are always possible). It is important to educate managers regarding the open-source development model. They are just not used to it and at the first glimpse they can find it strange - even if it is to their advantage.
One may discuss if QGIS/GRASS (or other projects) could offer yearly support contracts. It may help to raise additional money in some cases. It is important to distinguish such contracts from their fully commercial counterparts. Customers shouldn't be forced into paying those fees/contracts - but they may fell better with paying them. Probably, such contracts, would have to be done by individual companies - or could the steering board coordinate such activities?
Many managers in government agencies don't want to be held responsible in case things go wrong - and in case of using open-source software they are fully responsible about their decisions, whereas with commercial software they can always blame their commercial vendor (even if the contracts are always in favor of the software vendor and includes very limited liability of the vendor). At least in Switzerland I know that many GIS managers are thinking this way. They often want to at least share their responsibility with an external company.
Just my two cents,
Andreas
Markus Neteler wrote:
Thanks a lot to GFOSS.it! And to the folks managing the donations.
To remember:
http://www.qgis.org/sponsorship.html
http://grass.osgeo.org/donation.phpAlso small donations are welcome.
Best
MarkusOn Fri, Jul 3, 2009 at 11:59 AM, Paolo Cavallini<cavallini@faunalia.it> wrote:
Hi all.
At GFOSS.it, we just decided to increase the donations we receive on
behalf of projects that adhered to the microdonation initiative
(currently GRASS and QGIS), by adding one euro from our budget to every
euro donated. I hope this will be appreciated.
So now your donations have now more effect for the well being of the
projects. Of course, other projects are welcome to join in.
All the best.
--
Paolo Cavallini: http://www.faunalia.it/pc
_______________________________________________
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss_______________________________________________
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user
------------------------------Message: 5
Date: Sat, 04 Jul 2009 17:38:09 +0200
From: Falko Engel <falko_e@gmx.net>
Subject: [GRASS-user] v.db.connect additional attribut table
To: GRASS_USER_LIST <grass-user@lists.osgeo.org>
Message-ID: <4A4F7761.8030401@gmx.net>
Content-Type: text/plain; charset=ISO-8859-15Dear List,
I am still running into problems with connecting an additional attribute
table to an existing map.
I am using postgres to store all tables in. This is my setup: GRASS 6.4
RC5, Suse 11.1, and Postgresql 8.3.7.I have a polygon (area, centroid) map containing my whole study area.
There are about 10000 polygones in this map.
In an additional table with about 300 rows I have extra information for
some of the posygones of the original geometry.In the map's original attribute table there is a colum with an
identifier that is also used in the additional table. It is in string
format.
I think this is your problem, Falko. The column indexing a Grass-GIS table must be numeric.
Try this:
v.db.addtable <map name> <newtable> layer=2
Then,
v.db.select <map name>
If it's working, you'll get the category column.
Then you add columns and populate them as required.
Richard
Can someone tell me how I can connect the table to the map as a second
layer?Heres what I already did:
# Reclass cats of map according to identifier column
v.reclass input=map output=map_reclass column=identifier# Using SQL
------------------------------------------------------------------
# Update an integer column "table_id" in the new table with the cat
values of the map according to the identifier columnUPDATE new_table
SET table_id = map_reclass.cat
FROM map_reclass
WHERE new_table.identifier = map_reclass.identifier
#
-------------------------------------------------------------------------------------------v.db.connect -o map=map_reclass key=table_id layer=2 table=new_table
v.category map_reclass option=add layer=2 output=map_reclass_layer2I am sure there is something wrong because I can't work with layer 2
after this operation.v.category input=map_reclass_layer2 option=report
Layer/Tabelle: 2/map_reclass_layer2_2
Typ Anzahl Min Max
Punkt 0 0 0
Linie 0 0 0
Grenze 26072 1 26072
Zentroid 10205 26073 36277
Fläche 0 0 0
Alle 36277 1 36277Layer/Tabelle: 1/map_reclass_layer2_1
Typ Anzahl Min Max
Punkt 0 0 0
Linie 0 0 0
Grenze 0 0 0
Zentroid 10115 1 8543
Fläche 0 0 0
Alle 10115 1 8543Thanks for any help!
Falko
------------------------------
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-userEnd of grass-user Digest, Vol 39, Issue 14
******************************************