[GRASS-user] Re: grass-user Digest, Vol 39, Issue 14

Richard Chirgwin rchirgwin at ozemail.com.au
Sat Jul 4 17:53:02 EDT 2009


grass-user-request at lists.osgeo.org wrote:
> Send grass-user mailing list submissions to
> 	grass-user at lists.osgeo.org
>
> To 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 at lists.osgeo.org
>
> You can reach the person managing the list at
> 	grass-user-owner at lists.osgeo.org
>
> When 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 at yahoo.com>
> Subject: Re: [GRASS-user] reprojecting ASTER_GDEM r.proj "Error
> 	writing	segment file"
> To: grass-user at lists.osgeo.org,	Nikos Alexandris
> 	<nikos.alexandris at felis.uni-freiburg.de>
> Message-ID: <153027.67559.qm at web110009.mail.gq1.yahoo.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> Nikos 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 at yahoo.com>
> Subject: Re: [GRASS-user] reprojecting ASTER_GDEM r.proj "Error
> 	writing	segment file"
> To: grass-user at lists.osgeo.org,	Nikos Alexandris
> 	<nikos.alexandris at felis.uni-freiburg.de>
> Message-ID: <794440.84524.qm at web110004.mail.gq1.yahoo.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> Hamish:
>   
>> 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 at felis.uni-freiburg.de>
> Subject: Re: [GRASS-user] reprojecting ASTER_GDEM r.proj "Error
> 	writing	segment file"
> To: Hamish <hamish_b at yahoo.com>
> Cc: grass-user at lists.osgeo.org
> Message-ID: <1246672233.16710.19.camel at vertical>
> Content-Type: text/plain
>
>
> Nikos:
>   
>>>> 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:      780712992
>
>
>   
>> e2fsck?
>>     
>
> I though linux is taking care of that :-)
>
>
>   
>> filesystem 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 at carto.net>
> Subject: [GRASS-user] Re: [Qgis-user] Re: [OSGeo-Discuss] augmenting
> 	donations
> To: OSGeo Discussions <discuss at lists.osgeo.org>
> Cc: grass-user <grass-user at lists.osgeo.org>,	qgis-user
> 	<qgis-user at lists.osgeo.org>
> Message-ID: <4A4F0C0C.30904 at carto.net>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi 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 project
>
> I 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.php
>>
>> Also small donations are welcome.
>>
>> Best
>> Markus
>>
>> On Fri, Jul 3, 2009 at 11:59 AM, Paolo Cavallini<cavallini at 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 at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/discuss
>>>
>>>     
>>>       
>> _______________________________________________
>> Qgis-user mailing list
>> Qgis-user at 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 at gmx.net>
> Subject: [GRASS-user] v.db.connect additional attribut table
> To: GRASS_USER_LIST <grass-user at lists.osgeo.org>
> Message-ID: <4A4F7761.8030401 at gmx.net>
> Content-Type: text/plain; charset=ISO-8859-15
>
> Dear 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 column
>
> UPDATE 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_layer2
>
>
>
> I 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      36277
>
> Layer/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       8543
>
> Thanks for any help!
>
> Falko
>
>
> ------------------------------
>
> _______________________________________________
> grass-user mailing list
> grass-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
>
> End of grass-user Digest, Vol 39, Issue 14
> ******************************************
>
>   



More information about the grass-user mailing list