headers
Hamish | 1 Sep 2009 06:59
Picon
Favicon
Gravatar

Re: UTM values.

> > I have the following Long lat and UTM values from the
> > converters. Can you explain what you mean by "converters"?
> > 
> > 24.5N -2711052
> > 41E    -702655
> > 
> > 47N -5209532
> > 84E  -271930

Micha wrote:
> As you probably know, the two lon values above are in
> widely separated UTM zones. 41E is in zone UTM37N while 84E
> is in zone UTM 45N. These two UTM zones are actually two
> *different* projections - with different origins.

visual aid- see "UTM Zones" linked from here:
  http://grass.osgeo.org/wiki/Gis_Concepts#Map_projections

Hamish

_______________________________________________
grass-user mailing list
grass-user <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Permalink | Reply | 0 comments |
headers
Micha Silver | 1 Sep 2009 08:36
Picon
Favicon

Re: how to calculate area of voronoi polygons considering the boundary of the catchment

Hi Daljeet

daljeet wrote:

> Hi Micha,
>
> I could create isohyetal lines using the suggested steps:
>
>   
... clipped...
>
> Following are the doubts/questions
>
> 1. I saw the details of the raster created from v.surf.rst
>
>   
>> r.info rainraster
>>     
>
> zmin_data=0.000000, zmax_data=141.322000                                |
> zmin_int=-13.588332, zmax_int=52.589905 
>
> zmin_data and zmax_data seems to be correct but I do not understand 
> a) why the interpolated value zmin_int=-13.588332 is -ve
> b) and what is meaning of zmax_int equal to  52.58990
>   
If I understand correctly, the zmax_int and zmin_int are the max and min 
displacements of the interpolated values vs. the actual data points. The 
RST method creates an interpolation which does not usually go thru the 
actual data points, but rather "smooths" over them. These numbers show
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tim Holland | 1 Sep 2009 08:37
Picon

r.colors generates different colors than QGIS plugin when same rules used?


Hello List, 

I am trying to generate PNG files of a few different maps using r.colors,
d.rast, and the PNG driver.  

The images I get from this process end up being colored slightly differently
than when the equivalent images are generated in QGIS.  It is far more
convenient to use the PNG driver right in GRASS (because I can set a script
running and print out many images at once), but I prefer the color results I
get with QGIS.  

In GRASS, I am using

r.colors map=ForestChange rules=colorTable.file
d.mon start=PNG
d.rast map=ForestChange
d.mon stop=PNG 

with the rules file (colorTable.file) as follows using the rgb values for
each level:
-15 255 0	0
-0.5 255 240 180
0 white
0.5 180 230 130
15 0 70 0

(the idea with this particular rules file is to generate deforestation /
reforestation maps where zero change is shown as white, with beige-red
representing increasing levels of deforestation, and light green - dark
(Continue reading)

Permalink | Reply | 5 comments |
headers
Tim Holland | 1 Sep 2009 09:00
Picon

Re: r.colors generates different colors than QGIS plugin when same rules used?


Hello, 

Sorry for what is becoming a very long question (and perhaps too many
images).  

I put up two more images that are probably better at demonstrating what I'm
talking about.  They are zoomed in on the same section of the Landsat
composite, but with one image made in GRASS d.rast
(http://i1020.photobucket.com/albums/af326/timothyholland/HLB_brovey_GRASS_Zoom.jpg)
and the other in QGIS
(http://i1020.photobucket.com/albums/af326/timothyholland/HLB_brovey_QGIS_Zoom.jpg). 
Is the issue just that QGIS has greater color depth than GRASS d.rast or the
PNG driver?  That's what these look like.  Is there a way to get greater
color depth in GRASS?  

Thanks again, 
Tim

Tim Holland wrote:
> 
> Hello List, 
> 
> I am trying to generate PNG files of a few different maps using r.colors,
> d.rast, and the PNG driver.  
> 
> The images I get from this process end up being colored slightly
> differently than when the equivalent images are generated in QGIS.  It is
> far more convenient to use the PNG driver right in GRASS (because I can
> set a script running and print out many images at once), but I prefer the
(Continue reading)

Permalink | Reply | 2 comments |
headers
xavier garcia acosta | 1 Sep 2009 10:03
Picon
Favicon

RE: v.vol.rst error



> From: neteler <at> osgeo.org
> Date: Mon, 31 Aug 2009 22:42:05 +0200
> Subject: Re: [GRASS-user] v.vol.rst error
> To: epistacio <at> hotmail.com
> CC: grass-user <at> lists.osgeo.org
>
> On Mon, Aug 31, 2009 at 7:26 PM, xavier garcia
> acosta<epistacio <at> hotmail.com> wrote:
> > Hello all,
> >
> > I would like to use the v.vol.rst module but when I try to execute them from
> > the GRASS GUI this error text appears in the terminal:
> >
> > GRASS 6.4.0RC4 (costabrava):~ > *** buffer overflow detected ***: v.vol.rst
> > terminated
> > ======= Backtrace: =========
> > /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7792da8]
> > /lib/tls/i686/cmov/libc.so.6[0xb7790eb0]
> > /lib/tls/i686/cmov/libc.so.6[0xb77905a8]
> > /lib/tls/i686/cmov/libc.so.6(__overflow+0x53)[0xb7703683]
> > /lib/tls/i686/cmov/libc.so.6(__printf_fp+0x176e)[0xb76db26e]
> > /lib/tls/i686/cmov/libc.so.6(_IO_vfprintf+0x3ca)[0xb76d4bfa]
> > /lib/tls/i686/cmov/libc.so.6(__vsprintf_chk+0xa4)[0xb7790654]
> > /lib/tls/i686/cmov/libc.so.6(__sprintf_chk+0x2d)[0xb779059d]
> > v.vol.rst(main+0x176)[0x804c966]
> > /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb76ab775]
> > v.vol.rst[0x804bd71]
> > ======= Memory map: ========
> > 08048000-08056000 r-xp 00000000 08:06 347205
> > /usr/lib/grass64/bin/v.vol.rst
> > 08056000-08057000 r--p 0000d000 08:06 347205
> > /usr/lib/grass64/bin/v.vol.rst
> > 08057000-08058000 rw-p 0000e000 08:06 347205
> > /usr/lib/grass64/bin/v.vol.rst
> > 08a25000-08a46000 rw-p 08a25000 00:00 0          [heap]
> >
> > .......
> >
> >
> > Anybody know how to fix that?
> >
> > Pd: My GRASS version is GRASS 6.4.0RC4 (2009) runnig on UBUNTU 9.04
>
>
> I have used v.vol.rst in GRASS 6.4 for more than 22000 UTM maps
> without problems.
> Please tell use the parametes you used (idealy the command line), or,
> even better, an example to reproduce it with either Spearfish or the
> North Carolina
> data set. Which projection?
>
> Markus


The fact is that I had just tried to execute this module from the GRASS GUI, without include any parameter. Then I have tried execute the module in the terminal and the result is exactly the same, with or without parameters:

GRASS 6.4.0RC4 (costabrava):~ > v.vol.rst input=string [cellinp=dtm] [wcolumn=DIESPLUJA] [cellout=diespluja]
*** buffer overflow detected ***: v.vol.rst terminated
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb77d0da8]
/lib/tls/i686/cmov/libc.so.6[0xb77ceeb0]
/lib/tls/i686/cmov/libc.so.6[0xb77ce5a8]
/lib/tls/i686/cmov/libc.so.6(__overflow+0x53)[0xb7741683]
/lib/tls/i686/cmov/libc.so.6(__printf_fp+0x176e)[0xb771926e]
/lib/tls/i686/cmov/libc.so.6(_IO_vfprintf+0x3ca)[0xb7712bfa]
/lib/tls/i686/cmov/libc.so.6(__vsprintf_chk+0xa4)[0xb77ce654]
/lib/tls/i686/cmov/libc.so.6(__sprintf_chk+0x2d)[0xb77ce59d]
v.vol.rst(main+0x176)[0x804c966]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb76e9775]
v.vol.rst[0x804bd71]
======= Memory map: ========
08048000-08056000 r-xp 00000000 08:06 347205     /usr/lib/grass64/bin/v.vol.rst
08056000-08057000 r--p 0000d000 08:06 347205     /usr/lib/grass64/bin/v.vol.rst
08057000-08058000 rw-p 0000e000 08:06 347205     /usr/lib/grass64/bin/v.vol.rst
08efe000-08f1f000 rw-p 08efe000 00:00 0          [heap]
b5a1b000-b5a5a000 r--p 00000000 08:06 81613      /usr/lib/locale/ca_ES.utf8/LC_CTYPE
b5a5a000-b5a5e000 rw-p b5a5a000 00:00 0
b5a5e000-b5a61000 r-xp 0
........................................................................................................................................................

My projection is: 1 (UTM)
zone:       31
datum:      eur50

Xavier

Celebramos el 10º aniversario de Messenger. ¡Únete a la fiesta! 
_______________________________________________
grass-user mailing list
grass-user <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Permalink | Reply | 3 comments |
headers
Hamish | 1 Sep 2009 10:44
Picon
Favicon
Gravatar

Re: r.colors generates different colors than QGIS plugin when same rules used?

> Is the issue just that QGIS has greater color depth than GRASS d.rast
> or the PNG driver?  That's what these look like.  Is there a way to
> get greater color depth in GRASS?  

very wild guess: is the ForestChange map floating point? (does r.info
say CELL or FCELL/DCELL?)

if FCELL or DCELL try to convert it to CELL with
  r.mapcalc "ForestChange.int = round(ForestChange)"
  r.colors ...

and see if it looks better.

or if the other way,
  r.mapcalc ForestChange.float = ForestChange * 1.0"
  r.colors ...

but I seem to recall that FCELL/DCELL was the one that did downsampling
and you got smoother gradients with CELL maps.

?
Hamish

ps- nice to see that qgis gives you more coloring options these days,
can it load GRASS color tables and GMT .cpt files directly?

_______________________________________________
grass-user mailing list
grass-user <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Permalink | Reply | 1 comment |
headers
Marc-Antoine Nüssli | 1 Sep 2009 14:10
Favicon

Possible bug in v.edit

Dear Grass users,

I get a very strange result with v.edit. Here is the story:
 
I have imported a vector map from a postgres database and there are 3 overlapping areas. Then, I try to get the feature ids(not the category) of the overlapping areas by using (as the overlapping areas appear in layer 2 with cat=2):
v.edit map=test_shapes_newi layer=2 tool=select cats=2 type=centroid
Ans the result is:
----
29,27
Selecting features...
2 of 29 features selected from vector map <test_shapes_newi <at> PERMANENT>
v.edit complete.
---
Thus, only two features are selected... instead of 3....strange

Then, I tried to print the category(in layer 1) for all features using:
v.category input=test_shapes_new option="print"
and the result is:
---
4
6
7
2
1/2
1
1/3
3
5
3/5
---
So, we clearly see that 3 features have two categories in layer 1(and thus are overlapping), which is consistent with what is indicated by v.in.ogr (and also with what I can see when I display the map)

Then, if I get the ids of features with cat=1 in layer1:
v.edit map=test_shapes_newi layer=1  tool=select cats=1 type=centroid
I correctly get 3 ids...

But if I ask for the features with cat=3 in layer1:
v.edit map=test_shapes_newi layer=1  tool=select cats=3 type=centroid
I get only 2 ids:
---
29,27
Selecting features...
2 of 29 features selected from vector map <test_shapes_newi <at> PERMANENT>
v.edit complete.
----
which is clearly wrong if we compare with the list of categories printed above...

 
I really don't understand what is going wrong. The only reason I can think of is a bug in v.edit....
 

Below, I have pasted the testfile I used to produce these results. Please try to redo and tell me if you have the same problem. Moreover, if you look at the text file, we can clearly see that there are three features with two categories...
 

By the way, I take the opportunity to ask if someone knows an easy way to transform overlapping areas into simple areas. Basically, I just want to choose one of the two(or more) categories associated to an area and assign it as the only category for that area. And I don't care about which category is chosen among the 2 possible.
My data are the areas of countries and thus the overlaps I got are just because of some problems in the none-topological version of the data. So, I just need to assign randomly these overlaps to one of the neighbor area.
I tried v.clean tool=rmdupl but it does nothing at all...
Now, I am fighting with v.edit and I get the problem presented above...
So, if someone has an easy solution to this problem, I would very glad.
 
Thank you in advance!

 
Marc-Antoine Nüssli


----------START ASCII GRASS STANDARD FILE----------------------

ORGANIZATION:
DIGIT DATE:  
DIGIT NAME:   nuessli
MAP NAME:    
MAP DATE:     Tue Sep 01 13:01:32 2009
MAP SCALE:    1
OTHER INFO:  
ZONE:         0
MAP THRESH:   0.000000
VERTI:
B  5
 158          131        
 211          301        
 108          333        
 75           254        
 158          131        
B  5
 171.67467949 102.62660256
 182.29166667 94.41346154
 194.71153846 71.77724359
 191.30608974 72.17788462
 171.67467949 102.62660256
B  4
 116.20338236 147.39430963
 114.22292076 131.55061682
 121.15453637 135.51154003
 116.20338236 147.39430963
B  2
 62           77         
 98.3258427   111.53932584
B  2
 98.3258427   111.53932584
 123          135        
B  2
 43           77         
 62           77         
B  3
 62           77         
 69           77         
 98.3258427   111.53932584
B  6
 98.3258427   111.53932584
 114          130        
 115          150        
 66           259        
 35           265        
 43           77         
B  3
 158.08252615 122.19914762
 156          116        
 168.5464684  106.24163569
B  3
 168.5464684  106.24163569
 183          95         
 195          72         
B  3
 123          135        
 71           255        
 158.08252615 122.19914762
B  2
 158.08252615 122.19914762
 168.5464684  106.24163569
B  7
 168.5464684  106.24163569
 191          72         
 151          70         
 37           72         
 37           160        
 40           74         
 62           77         
B  3
 217          307        
 162          136        
 181.12359551 190.78651685
B  3
 181.12359551 190.78651685
 199          242        
 273.24466019 221.44466019
B  4
 273.24466019 221.44466019
 441          175        
 276          289        
 217          307        
B  4
 195          72         
 414          45         
 436          172        
 273.24466019 221.44466019
B  3
 273.24466019 221.44466019
 199          244        
 181.12359551 190.78651685
B  2
 181.12359551 190.78651685
 158.08252615 122.19914762
C  1 1
 144.59283467 243.00698455
 1     4        
C  1 1
 183.51855004 87.21392108
 1     6        
C  1 1
 116.96146785 138.87668756
 1     7        
C  1 1
 65.45911571  169.69098179
 1     2        
C  1 3
 80.70905903  93.08952149
 1     1        
 1     2        
 2     2        
C  1 1
 135.07702133 128.59957381
 1     1        
C  1 3
 161.92770396 113.80227654
 1     1        
 1     3        
 2     2        
C  1 1
 297.85655015 136.60482313
 1     3        
C  1 1
 275.17021301 221.55107616
 1     5        
C  1 3
 237.76816343 231.7223301
 1     3        
 1     5        
 2     2        

  

_______________________________________________
grass-user mailing list
grass-user <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Permalink | Reply | 1 comment |
headers
Martin Landa | 1 Sep 2009 14:25
Picon

Re: Possible bug in v.edit

Hi,

2009/9/1 Marc-Antoine Nüssli <marc-antoine.nuessli <at> euratlas.com>:

[...]

> But if I ask for the features with cat=3 in layer1:
> v.edit map=test_shapes_newi layer=1  tool=select cats=3 type=centroid
> I get only 2 ids:
> ---
> 29,27
> Selecting features...
> 2 of 29 features selected from vector map <test_shapes_newi <at> PERMANENT>
> v.edit complete.

which version of GRASS are you using? Testing GRASS 6.4

v.edit map=test layer=1  tool=select cats=3 type=centroid --q
26,27,29

Seems to be OK.

Martin

--

-- 
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
_______________________________________________
grass-user mailing list
grass-user <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Permalink | Reply | 0 comments |
headers
Hamish | 1 Sep 2009 14:42
X-Face
Picon
Favicon
Gravatar

FOSS4G 2009 Live-DVD and virtual machine, call for scripts

Hi all,

In preparation for the upcoming OSGeo conference in Sydney, build scripts
for free & open source software are being collected for inclusion on the
FOSS4G live DVD + virtual machine image.

The disc will be handed out to all conference delegates, and so is a
really nice showcase + exposure opportunity for your favourite GeoFOSS
project.

     http://wiki.osgeo.org/wiki/FOSS4G_2009_Press_Release_28

"""
The Easy steps to get your project on the FOSS4G Live DVD
Sydney, Australia. 23 August 2009. http://2009.foss4g.org

The Arramagong Live DVD, GISVM, and OSGeo Live-Demo projects are
collaborating to create a set of simple, automated install scripts for a
wide variety of Free and Open Source GIS projects, and we're calling on
each project to help us write a script for their software. Projects that
can write their install script this week will be included on The
Arramamgong Live DVD which will be given to all delegates at the FOSS4G
conference.

The scripts should cover the installation and configuration of each
project into a base Xubuntu 9.04 system. Separate scripts can optionally
cover data, demos and tutorials. As a bonus, these scripts are exactly
what packagers require to bundle your project into Debian and Ubuntu, so
you will be taking the first steps toward getting your project into a
Linux distribution.

The base version of the FOSS4G2009 GISVM/Arramagong Live DVD can be
trialled as a VMWare virtual machine and downloaded from:
http://download.osgeo.org/livedvd/Arramagong_GISVM_FOSS4G2009_alpha1.7z 

[...]
"""

Feature Freeze is in less than a week, but it is mostly trivial to
add packages already built for Debian/Ubuntu.

Scripts can both install the app and fetch + install + setup demo
user data. See here for some examples:
  https://trac.osgeo.org/osgeo/browser/livedvd/gisvm/trunk/bin/

I have already added scripts for GRASS[1], GpsDrive (+ OSM maps for
navigating around downtown Sydney)[2], and MB-System[3]. Other
contributions are streaming as well. (see above URL)

[1] GRASS GIS: 6.4rc including Spearfish + North Carolina sample
datasets.

[2] gpsdrive: Using a custom debuild for latest version as official
debian package for gpsdrive lags years(!) behind. Mapnik+PostGIS
support for auto tile generation is already build in, but a OSM/
PostGIS/SQL expert is needed to setup/extract just the Sydney area
from world coastlines.shp + australia.osm otherwise the dataset takes
up too much room on the disc to justify inclusion.  (help wanted)
I've got that PostGIS DB running locally for the whole of Australia,
it works nicely. Now that I have the GpsDrive+OSM projections issues
sorted out in GpsDrive SVN I'll patch in that bugfix & add the static
CBD map tiles to the OSGeo build "real soon now".

[3] mbsystem: not activated because I haven't figured out how to get it
to build/link with shared libraries yet. With static libs it takes
up 300mb, which is too much for the disc. (help wanted)

A volunteer to add a QGIS build script (and if at all possible QGIS<->
GRASS plugin) is badly needed! It would be a true shame to not include
that*; it is probably not so bad, see the gpsdrive build script for
automatic .deb package building from SVN using "debuild".
[*] just as it is a shame that that qgis still isn't officially packaged
for Debian/Ubuntu. (DebianGIS is recruiting for volunteers! We badly
need to find someone to take over PostGIS duties as well.)

A nice side effect of this is that for anything still unpackaged for
Debian/Ubuntu, we can use these as templates for a new package.
e.g. in DebianGIS SVN I've just added the beginnings of official MB-
System packaging:
  http://svn.debian.org/viewsvn/pkg-grass/packages/mbsystem/trunk/debian/
(help wanted here too:)

Also, it is my personal goal that these scripts can be worked into
a live-helper build structure for fully automated builds of both the
DebianGIS and OSGeo Live-Demo Live images using whatever ubuntu/debian
flavour/release/media you like:
  http://svn.debian.org/viewsvn/pkg-grass/packages/debian-gis/
  https://trac.osgeo.org/osgeo/browser/livedvd/live-helper/
With a good collection of build scripts this should be fairly easy.

regards & a big thanks to all helpers so far,
Hamish Bowman
Permalink | Reply | 0 comments |
headers
Marc-Antoine Nüssli | 1 Sep 2009 16:07
Favicon

Re: Possible bug in v.edit

Hi Martin,
 
Thank you for your quick reply!
 
That's really crazy that you got this result!!
I have tested with Grass 6.3 AND grass 6.4(the one on which I'm working on) and both gives the exact same (wrong) results!! I've done again the test right now to be sure but the result is always the same: only 2 features are returned by v.edit for cat=3/layer=1. I really don't understand what could be the problem.
 
Did you use any special parameter during the import (apart from setting the format to standard) ?
Personaly, I used the default values as they are set by the wxpython interface for wx.in.ascii...
 
The only other possibility that I can see is the OS. I'm currently testing on windows.
Are you also on windows or on Linux?!?
Tonight, I will test it on linux but it would be rather strange that it is the source of the problem...
 
Have you also tried to select from layer 2 ? (v.edit map=test layer=2  tool=select cats=2 type=centroid --q)
 
MA

-----Original Message-----
From: Martin Landa <landa.martin <at> gmail.com>
To: marc-antoine.nuessli <at> euratlas.com
Cc: grass-user <at> lists.osgeo.org
Date: Tue, 1 Sep 2009 14:25:39 +0200
Subject: Re: [GRASS-user] Possible bug in v.edit

Hi,

2009/9/1 Marc-Antoine Nüssli <marc-antoine.nuessli <at> euratlas.com>:

[...]

> But if I ask for the features with cat=3 in layer1:
> v.edit map=test_shapes_newi layer=1  tool=select cats=3 type=centroid
> I get only 2 ids:
> ---
> 29,27
> Selecting features...
> 2 of 29 features selected from vector map <test_shapes_newi <at> PERMANENT>
> v.edit complete.

which version of GRASS are you using? Testing GRASS 6.4

v.edit map=test layer=1  tool=select cats=3 type=centroid --q
26,27,29

Seems to be OK.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa 
_______________________________________________
grass-user mailing list
grass-user <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Permalink | Reply | 502 comments |

Gmane