Re: [GRASS-user] High resolution dem
Yesterday I received a note off list which pointed me to an error I made when calculated the elevation If you used r.mapcalc, make sure to divide by 10.0 and not 10 in order to get DCELL output, otherwise the result will be integer with terraces, as in the aspect map, particularly on 5m horizontal resolution. Now I have a nice aspect map :-) What would be the best approach to calculate a dtm for a contour map where large parts miss elevation data? I 've uploaded an example on our server: http://www.gis-hosting.lu/static/img/grass/no_contours.png Since the algorythm from r.surf.contour takes much longer when there are large gaps or no elevation information is present, there should be soem kind of solution. My idea is to take elevation data from srtm or aster data and create contours from that data and patch it into the finer contour map. Any other ideas? Many thanks Frank Am 04.08.2010 09:53, schrieb Frank Broniewski: Hi, Hamish:Feb 28, 2010; 03:15am Re: High resolution dem I am curious to know what the problem with r.surf.contour was. Usually it does a great job as long as you take a moment to work around the integer and NULL/0 issues. Sorry that I quitted this discussion so silently, but I had to drop this and could not persue the issue further. Sometimes I really could use a 48h day :-) Of course my problems are still present. To take the thread up again, I want to answer to Hamish's question about my problems with r.surf.contour first: DEM interpolation seems to work nice, but when you start deriving maps, especially the aspect map looks simply not right ;-) I've uploaded some example images on our server, so that you can see what I mean: http://www.gis-hosting.lu/static/img/grass/contours5m.png http://www.gis-hosting.lu/static/img/grass/dtm5m.png http://www.gis-hosting.lu/static/img/grass/dtm3d.png http://www.gis-hosting.lu/static/img/grass/expo5m.png The data source is a shape file with contour lines with 5 meters interval. Conversion to raster went well and the pixel values match the height values for the contours. Before using the raster map, I multiplied the map with 10, just like it is mentioned in the wiki. Interpolation took approx. 5 minutes. The region is 10,000m * 10,000m wide and has a 5m resolution. Before deriving the aspect map, I divided the elevation map by 10 to gain real height values again ... Now I wonder what could cause the gaps in the aspect map - since the terrain model itself looks OK to me ... Many thanks Frank -- Frank BRONIEWSKI METRICO s.à r.l. géomètres technologies d'information géographique rue des Romains 36 L-5433 NIEDERDONVEN tél.: +352 26 74 94 - 28 fax.: +352 26 74 94 99 http://www.metrico.lu ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] 1-page grass overview
Hi, for the upcoming FOSS4G conference[1] we have put together a live dvd[2] with GRASS and a whole bunch of other OSGeo software, about 40 FOSS geo projects are participating in all. It would be great if folks could read through the 1-page overview doc[3] for GRASS (made with reStructured Text and Sphinx if you wondered), and the 5 minute quickstart tutorial[4]. A full list of project docs on the disc is interesting to look through as well.[5] Also if anyone is really keen they can download an ISO of the DVD[6] and test that it actually works. I've already discovered that the new QGIS 1.5 grass plugin doesn't like the user not owning the PERMANENT mapset, even if it's not the one being used. Test results to the OSGeo wiki[7] and bugs to the osgeo bug trac'er[8] please (including doc bugs; set component as LiveDVD). it goes to the printers next week. [1] http://2010.foss4g.org [2] http://live.osgeo.org [3] http://download.osgeo.org/livedvd/4.0-rc6/osgeolive-docs/overview/grass_overview.html [4] http://download.osgeo.org/livedvd/4.0-rc6/osgeolive-docs/quickstart/grass_quickstart.html [5] http://download.osgeo.org/livedvd/4.0-rc6/osgeolive-docs/overview/overview.html [6] http://download.osgeo.org/livedvd/4.0-rc6/ [7] http://wiki.osgeo.org/wiki/Live_GIS_Disc_Testing [8] https://trac.osgeo.org/osgeo/report/10 thanks, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Cluster whit area?
(apologies for interfering...)
Etienne wrote:
> Hi Dylan and everybody
> I'm come back. I have past this week on R for uderstand what you do in
> http://casoilresource.lawr.ucdavis.edu/drupal/node/340
> Now it's great for R but... I don't understand how make a loop in grass
> in the web site we can read
>
> for x in `seq 1 5`
> do v.extract --o in=bclust where="cluster=$x" out=bclust_$x
> v.hull --o in=bclust_$x out=bclust_hull_$x
> d.vect bclust_hull_$x type=boundary fcol=none width=2 col=white
> d.vect bclust icon=basic/box fcol=black col=black size=6
> done
>
> but I have an error and I dont understand very well how work the loop?
> My message error is
>
> Sorry <1> is not a valid option
> Sorry <5> is not a valid option
Try out like this:
for x in `seq 1 5`; do
v.extract --o in=bclust where="cluster="${x}"" out=bclust_"${x}"
v.hull --o in=bclust_"${x}" out=bclust_hull_"${x}"
d.vect bclust_hull_"${x}" type=boundary fcol=none width=2 col=white
d.vect bclust icon=basic/box fcol=black col=black size=6
done
By the way, I remember reading expert comment in the list that using "${x}" is
rather a good idea.
Cheers, Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Cluster whit area?
Hi Dylan and everybody I'm come back. I have past this week on R for uderstand what you do in http://casoilresource.lawr.ucdavis.edu/drupal/node/340 Now it's great for R but... I don't understand how make a loop in grass in the web site we can read for x in `seq 1 5` do v.extract --o in=bclust where="cluster=$x" out=bclust_$x v.hull --o in=bclust_$x out=bclust_hull_$x d.vect bclust_hull_$x type=boundary fcol=none width=2 col=white d.vect bclust icon=basic/box fcol=black col=black size=6 done but I have an error and I dont understand very well how work the loop? My message error is Sorry <1> is not a valid option Sorry <5> is not a valid option Thank you ;-) -- Cordialement Etienne DELAY Deust "Webmaster et gest. d'intranet" (IDSkype : etienne.delay.tic) Master IUP "valorisation du patrimoine et aménagement du territoire" ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: Installing r.area
LeeDaniel wrote: > Its value is used to initialise a few other variables, which need to > > be changed when building without the source tree: > > > > ARCH_DISTDIR = $(GRASS_HOME)/dist.$(ARCH) > > ARCH_BINDIR = $(GRASS_HOME)/bin.$(ARCH) > > ERRORLOG= $(GRASS_HOME)/error.log > > > > If you're building against an installed version, ARCH_DISTDIR should > > be set to the installation directory (e.g. /usr/local/grass-6.4.0RC6), > > ARCH_BINDIR shouldn't matter, and ERRORLOG can be set to any absolute > > filename. > Alright. I took out the variable $ARCH_DISTDIR and replaced it with > /opt/grass/. So the three lines the GRASS dirs are now: > RUN_GISBASE = > /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu This should also be /opt/grass (or wherever GRASS is installed). > Alright. Tried it out by navigating into the folder with r.area. Here are > the results: > gcc -I/dist.i686-pc-linux-gnu/include It would appear that any change to ARCH_DISTDIR was incorrect. The above is what you would get if you left ARCH_DISTDIR = $(GRASS_HOME)/dist.$(ARCH) but GRASS_HOME was unset. > main.c:19:23: schwerwiegender Fehler: grass/gis.h: Datei oder Verzeichnis > nicht gefunden > Kompilierung beendet. If you're going to post build output to the mailing list, run: export LC_ALL=C in the shell before running "make". -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Error when trying to "show attribute data" on a Mac
I'm trying to view attribute data for a vector file in the sample North Carolina data using the GUI. My steps: In the GIS Manager, 1. Click the Add Vector Layer button in the toolbar 2. Click the Show attribute data in the settings pane below. The Output window shows the following error: Bad file descriptor: dup r dbmi: Protocol error Unable to start driver Am I doing something wrong? How do I view attribute data? Is there a dbf issue on the Mac? -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Error-when-trying-to-show-attribute-data-on-a-Mac-tp5373484p5373484.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: Vector attribute query errors on a Mac
Thank you! -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Vector-attribute-query-errors-on-a-Mac-tp5365200p5373451.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: Installing r.area
Alright, I gave it another shot...
GRASS_HOME is the location of the GRASS source tree. If you don't have
> the GRASS source tree, it should be unset.
>
Okay, I turned it off by putting "#" in front of it. Now the line looks like
this:
# GRASS dirs
# GRASS_HOME = /usr/src/packages/BUILD/grass-6.4.0RC6
Its value is used to initialise a few other variables, which need to
> be changed when building without the source tree:
>
> ARCH_DISTDIR = $(GRASS_HOME)/dist.$(ARCH)
> ARCH_BINDIR = $(GRASS_HOME)/bin.$(ARCH)
> ERRORLOG= $(GRASS_HOME)/error.log
>
> If you're building against an installed version, ARCH_DISTDIR should
> be set to the installation directory (e.g. /usr/local/grass-6.4.0RC6),
> ARCH_BINDIR shouldn't matter, and ERRORLOG can be set to any absolute
> filename.
Alright. I took out the variable $ARCH_DISTDIR and replaced it with
/opt/grass/. So the three lines the GRASS dirs are now:
# GRASS dirs
# GRASS_HOME = /usr/src/packages/BUILD/grass-6.4.0RC6
RUN_GISBASE =
/usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu
RUN_GISRC =
/opt/grass/demolocation/.grassrc${GRASS_VERSION_MAJOR}${GRASS_VERSION_MINOR}
Also, you need to override MODULE_TOPDIR on the command line, e.g.:
make MODULE_TOPDIR=/usr/local/grass-6.4.0RC6
This is used to locate the *.make files, so setting in those files
won't work.
Alright. Tried it out by navigating into the folder with r.area. Here are
the results:
l...@pc19384:~/r.area> sudo make MODULE_TOPDIR=/opt/grass/
mkdir -p /bin.i686-pc-linux-gnu
mkdir -p /dist.i686-pc-linux-gnu/include/grass
mkdir -p /dist.i686-pc-linux-gnu/lib
mkdir -p /dist.i686-pc-linux-gnu/bin
mkdir -p /dist.i686-pc-linux-gnu/etc
mkdir -p /dist.i686-pc-linux-gnu/driver
mkdir -p /dist.i686-pc-linux-gnu/driver/db
mkdir -p /dist.i686-pc-linux-gnu/fonts
gcc -I/dist.i686-pc-linux-gnu/include -O2 -DPACKAGE=\""grassmods"\"
-I/dist.i686-pc-linux-gnu/include -o OBJ.i686-pc-linux-gnu/main.o -c main.c
main.c:19:23: schwerwiegender Fehler: grass/gis.h: Datei oder Verzeichnis
nicht gefunden
Kompilierung beendet.
make: *** [OBJ.i686-pc-linux-gnu/main.o] Fehler 1
Unfortunately no improvement. Oh man...
The depressed
Daniel
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/Installing-r-area-tp5340139p5372689.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: Installing r.area
LeeDaniel wrote: > > wrong path (.../BUILD/... is wrong and needs to be /opt/...). > > > > Or you do it yourself... AFAIK, it is in your case in > > /opt/grass/include/Make/Platform.make > > Alright, I think I understood what to do. I edited > /opt/grass/include/Make/Platform.make (made a backup) and changed these two > lines from: > # GRASS dirs > GRASS_HOME = /usr/src/packages/BUILD/grass-6.4.0RC6 > RUN_GISBASE = > /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu > > to: > # GRASS dirs > GRASS_HOME = /opt/grass > RUN_GISBASE = /opt/grass/dist.i686-pc-linux-gnu GRASS_HOME is the location of the GRASS source tree. If you don't have the GRASS source tree, it should be unset. Its value is used to initialise a few other variables, which need to be changed when building without the source tree: ARCH_DISTDIR= $(GRASS_HOME)/dist.$(ARCH) ARCH_BINDIR = $(GRASS_HOME)/bin.$(ARCH) ERRORLOG= $(GRASS_HOME)/error.log If you're building against an installed version, ARCH_DISTDIR should be set to the installation directory (e.g. /usr/local/grass-6.4.0RC6), ARCH_BINDIR shouldn't matter, and ERRORLOG can be set to any absolute filename. Also, you need to override MODULE_TOPDIR on the command line, e.g.: make MODULE_TOPDIR=/usr/local/grass-6.4.0RC6 This is used to locate the *.make files, so setting in those files won't work. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: Feed and manipulate the result of "v.distance -pa" in python
For your task the use of lists and the split tool may help.
The different lines have are seperated by a '\n' (which is interpreted as a
new line). After splitting the string into a line list you can make a loop
each item of this list. Something like this:
output='7839|16\n7839|17\n7839|22\n7839|23\n7839|24'
seccond_column_list=[]
max_value=0
line_list=output.split('\n')
for line in line_list:
columns=line.split('|')
seccond_column_list.append(float(columns[1]))
max_value=max(seccond_column_list)
print seccond_column_list
print max_value
I may missunderstood your question but I hope this helps.
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/Feed-and-manipulate-the-result-of-v-distance-pa-in-python-tp5371195p5372457.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: Filling Null values in a MODIS image
Hanlie Pretorius wrote: > > Thanks for all the replies. I first tried finding the NULLS using > r.mapcalc, and it turns out that the NULLS are the cells in the GRASS > region (rectangular), but outside my study region (irregular > geographical border). I was under the misconception that g.region set > to a raster file functions like a mask. > Only the N S E W bounds, no irregular border, a MASK would be required here. > About the r.neighbors procedure, why is it necessary to follow with > r.patch? Surely the result of r.neighbors will be without NULLS? That depends on the moving window size and the size of NULL areas. If all cells in a moving window are NULL, the result should also be NULL. Patching makes sense only for time series of data like temperature or vegetation indices. For land cover type, patching with different years might not be desired. > I did > find, though, that r.neighbours resulted in raster with extended > borders compared to the original, which makes sense. One would then > have to clip it again to the study area. Or use a mask of the original > area before running r.patch? Before doing any analysis or processing, I would set the region to the raster including its resolution, create a MASK for the study area maybe with a buffer around, zoom to the MASK with g.region zoom=MASK, just to be sure align again the region to the raster resolution with g.region align=modis_land_cover_type1_2001_primary, only now start processing. In this particular case, the most conservative solution would probably be to reclassify all NULL cells as unclassified (there should be a category value for unclassified). Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: Filling Null values in a MODIS image
2010/8/4, Hamish : > Hanlie wrote: >> | Rows: 11957 >> | Columns: 6277 > ... >> I have tried to see the NULLS by displaying everything in >> white, except for NULLS displayed in red, but I didn't see >> anything. >> >> Does anyone know how I can find out if there are actually >> NULL value and where they are? > > try zooming in. Unless you have a 12000x7000 monitor, some cells will be > hidden. > > extract with r.mapcalc and buffer with r.buffer if they are still hard to > find. > Thanks for all the replies. I first tried finding the NULLS using r.mapcalc, and it turns out that the NULLS are the cells in the GRASS region (rectangular), but outside my study region (irregular geographical border). I was under the misconception that g.region set to a raster file functions like a mask. About the r.neighbors procedure, why is it necessary to follow with r.patch? Surely the result of r.neighbors will be without NULLS? I did find, though, that r.neighbours resulted in raster with extended borders compared to the original, which makes sense. One would then have to clip it again to the study area. Or use a mask of the original area before running r.patch? Hanlie ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: Installing r.area
This will never work unless the OpenSuse packager fixes the > wrong path (.../BUILD/... is wrong and needs to be /opt/...). > > Or you do it yourself... AFAIK, it is in your case in > /opt/grass/include/Make/Platform.make Alright, I think I understood what to do. I edited /opt/grass/include/Make/Platform.make (made a backup) and changed these two lines from: # GRASS dirs GRASS_HOME = /usr/src/packages/BUILD/grass-6.4.0RC6 RUN_GISBASE = /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu to: # GRASS dirs GRASS_HOME = /opt/grass RUN_GISBASE = /opt/grass/dist.i686-pc-linux-gnu But this still happens: l...@pc19384:~/r.area> make Makefile:11: ../../include/Make/Module.make: Datei oder Verzeichnis nicht gefunden make: *** Keine Regel, um »../../include/Make/Module.make« zu erstellen. Schluss. l...@pc19384:~/r.area> make MODULE_TOPDIR=/opt/grass/ gcc -I/opt/grass/dist.i686-pc-linux-gnu/include -O2 -DPACKAGE=\""grassmods"\" -I/opt/grass/dist.i686-pc-linux-gnu/include -o OBJ.i686-pc-linux-gnu/main.o -c main.c main.c:19:23: schwerwiegender Fehler: grass/gis.h: Datei oder Verzeichnis nicht gefunden Kompilierung beendet. make: *** [OBJ.i686-pc-linux-gnu/main.o] Fehler 1 Did I do something wrong? Thanks a bunch! Daniel -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Installing-r-area-tp5340139p5372018.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] GRASS vs OpenJump
Hi all , I recently viewed OpenJump application written in JAVA which is also a GIS software but have less features when compared to GRASS GIS. What my plan is to contribute modules of GRASS GIS written in C/Python to OpenJump written in Java. Does osgeo or any grass developers have any objection in copying the code (mean the idea of making modules) to other OpenSource software like OpenJump. I do not mean of copying the whole code as same to java. What is my part of contribution is porting C/C++/Python code to Java and making some hacks on source code. I also want to know why OpenJump was not accepted by osgeo. Any sugeestion and comments are really welcomed.. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Feed and manipulate the result of "v.distance -pa" in python
Nikos Alexandris wrote:
> I need to convert the following bash-one-liner:
>
> v.distance --q -pa from=ref_points to=coi_points upload=cat \
> column=anycol | cut -d"|" -f2 | sort -nu | tail -1
>
> into python.
>
> My unsolved problem is that "v.distance -pa" returns for
> example thousands of
> lines in the following format:
> ...
> 7839|16
> 7839|17
> 7839|22
> 7839|23
> 7839|24
>
> Reading the main command in python is not the problem
> (although I am a bit
> confused between grass.pipe, grass.feed, grass.read). Are
> there any examples
> (scripts in grass trunk maybe?) to follow in order to split
> the output, keep
> the second "column", sort and keep the maximum? Actually
> the "split" is what
> worries me most. I 've been looking for quite some time to
> find something that
> gives me a strait answer but no luck yet.
try v.rast.stats.py: cats.append(line.rstrip('\r\n').split(';')[0])
that splits on ";" as the sep, and takes the first entry (column counting
starts at 0 not 1 here)
so for you: line.split('|')[1]
no idea about sorting, but you may be able to program a loop which
starts out empty and only updates if the line's dmax is bigger that the
one stored in the overall variable's, or if the variable is empty (for
the first).
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Filling Null values in a MODIS image
Hanlie wrote: > | Rows: 11957 > | Columns: 6277 ... > I have tried to see the NULLS by displaying everything in > white, except for NULLS displayed in red, but I didn't see > anything. > > Does anyone know how I can find out if there are actually > NULL value and where they are? try zooming in. Unless you have a 12000x7000 monitor, some cells will be hidden. extract with r.mapcalc and buffer with r.buffer if they are still hard to find. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Filling Null values in a MODIS image
Hanlie wrote: > I have a MODIS land cover image that contains NULL values > according to r.univar: > - > r.univar map=modis_land_cover_type1_2001_prim...@permanent > total null and non-null cells: 41884 > total null cells: 17145 > - > > So, I tried to fill it with r.fillnulls and I get the > following: (as suggested by http://grass.osgeo.org/wiki/MODIS#Removing_holes http://grass.osgeo.org/wiki/AVHRR#Removing_holes ) Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Error while creating vectorial file in WinGRASS
Kim wrote: > Hi there >Regarding Hamish suggestion "You need to run db.connect to select a > database backend to use first. (There is no VAR file in the mapset > yet) > The thing is: I have been using an WinGRASS6.4 binary version where I > didn't need to do anything else. Just create Vector by doing this. So, > my question is, why was this disabled? Or is it some error that only > occurs in this release? the GUI is making the assumption that the mapset will already have a database link. I don't know when that started. This usually happens for you when you first create a map in the mapset which uses a database table. Modules should create that for you if it is needed, but some do not and so the GRASS startup script for unix was changed to automatically set the default if it wasn't set already. The Windows startup script does not set the default DB for you (in the mapset's "VAR" file) apparently. (see bug #7) Perhaps if you start "GRASS with MSys" the unix startup script might be used and then it might work from that mapset?? (not sure) > About > > hopefully fixed & ready for testing in 6.5svn r42988 (v.edit). > Will it be available for 6.4 in Windows? I am not totally happy with that work-around, once we decide on the correct solution it will of course be backported to 6.4. GRASS 6.5 and 7 are for experimenting to find the best solution, which is the stage this is currently at. regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Error while creating vectorial file in WinGRASS
Hi there
Regarding Hamish suggestion "
You need to run db.connect to select a database backend to use
first. (There is no VAR file in the mapset yet)
The thing is: I have been using an WinGRASS6.4 binary version where I didn't
need to do anything else. Just create Vector by doing this. So, my question
is, why was this disabled? Or is it some error that only occurs in this
release?
About
hopefully fixed & ready for testing in 6.5svn r42988 (v.edit).
Will it be available for 6.4 in Windows?
Thanks
Kim
2010/8/4 Markus Metz
> Hamish wrote:
> > Hamish wrote:
> >> You need to run db.connect to select a database backend to
> >> use first. (There is no VAR file in the mapset yet)
> >
> > hopefully fixed & ready for testing in 6.5svn r42988 (v.edit).
> >
> >
> > devs:
> > maybe do this for 'v.in.ascii -e' and 'v.digit -n' too?
> > or move this into Vect_open_new() ?
>
> Not to Vect_open_new(), a GRASS vector does not need to have a DB
> connection, this is optional.
>
> Markus M
>
>
> ... but I'm not totally
> > convinced that's the right place for it either; the mapset may
> > come from an earlier version of GRASS. perhaps db.execute
> > instead of exiting with an error.
> >
> >
> > #include
> > ...
> > if (! db_get_default_driver_name() ) {
> > G_message(_("Creating new DB connection based on default mapset
> settings..."));
> > db_set_default_connection();
> > }
> >
> >
> > see bug #7 http://trac.osgeo.org/grass/ticket/7
> >
> >
> > Hamish
> >
> >
> >
> >
> >
> > ___
> > grass-user mailing list
> > grass-user@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/grass-user
> >
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Filling Null values in a MODIS image
Apart from the region resolution, it's land cover classes, r.fillnulls will produce nonsense data: floating point. Rather use r.neighbors with a modal filter, patch the original with the filtered map, that would replace NULLs with the most common surrounding land cover type. Markus M Hanlie Pretorius wrote: > Hi, > > I have a MODIS land cover image that contains NULL values according to > r.univar: > - > r.univar map=modis_land_cover_type1_2001_prim...@permanent > total null and non-null cells: 41884 > total null cells: 17145 > - > > So, I tried to fill it with r.fillnulls and I get the following: > - > r.fillnulls input=mcd12q1.a2001001.005_land_cover_ty...@permanent > output=MCD12Q1.A2001001.005_land_cover_type1_filled > Locating and isolating NULL areas... > Reading input raster map ... > Writing output raster map ... > Creating interpolation points... > Extracting points... > Building topology for vector map ... > Registering primitives... > 0 primitives registered > 0 vertices registered > Building areas... > 0 areas built > 0 isles built > Attaching islands... > Attaching centroids... > Number of nodes: 0 > Number of primitives: 0 > Number of points: 0 > Number of lines: 0 > Number of boundaries: 0 > Number of centroids: 0 > Number of areas: 0 > Number of isles: 0 > r.to.vect complete. > Interpolating 0 points > Not sufficient points to interpolate. Maybe no hole(s) to fill in the > current map region? > Removing raster > Removing raster > Removing raster > Removing raster > Raster map not found > nothing removed > Removing vector > (Wed Aug 4 10:18:22 2010) Command finished (0 sec) > - > > Output of g.region -p: > - > g.region -p rast=modis_land_cover_type1_2001_prim...@permanent res=0.00423094 > projection: 3 (Latitude-Longitude) > zone: 0 > datum: wgs84 > ellipsoid: wgs84 > north: 27:19:08.833466S > south: 28:30:53.475952S > west: 28:03:57.840271E > east: 28:41:37.727966E > nsres: 0:00:15.210751 > ewres: 0:00:15.269511 > rows: 283 > cols: 148 > cells: 41884 > - > > Output of r.info: > - > r.info map=modis_land_cover_type1_2001_prim...@permanent > ++ > | Layer: modis_land_cover_type1_2001_p Date: Thu Jul 29 15:17:55 2010 > | Mapset: PERMANENT Login of Creator: hanlie > | Location: world_wgs84 > | DataBase: /media/0847147784/grassdata > | Title: ( MCD12Q1.A2001001.005_land_cover_type1 ) > | Timestamp: none > | > | > | Type of Map: raster Number of Categories: 14 > | Data Type: CELL > | Rows: 11957 > | Columns: 6277 > | Total Cells: 75054089 > | Projection: Latitude-Longitude > | N: 27:19:08.833466S S: 28:30:53.475952S Res: 0:00:00.36001 > | E: 28:41:37.727966E W: 28:03:57.840271E Res: 0:00:00.36002 > | Range of data: min = 1 max = 14 > | > | Data Description: > | generated by r.in.gdal > | > | Comments: > | r.in.gdal input="F:\Hanlie\UCT\M.Sc\Data\modis\MOD12Q1\MCD12Q1.A2001\ > | 001.h20v11.005.2009342153812_land_cover_type1.tif" output="MCD12Q1.A\ > | 2001001.005_land_cover_type1" > | > ++ > > > I have tried to see the NULLS by displaying everything in white, > except for NULLS displayed in red, but I didn't see anything. > > Does anyone know how I can find out if there are actually NULL value > and where they are? > > Thanks > Hanlie > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] High resolution dem
Hi, Hamish:Feb 28, 2010; 03:15am Re: High resolution dem I am curious to know what the problem with r.surf.contour was. Usually it does a great job as long as you take a moment to work around the integer and NULL/0 issues. Sorry that I quitted this discussion so silently, but I had to drop this and could not persue the issue further. Sometimes I really could use a 48h day :-) Of course my problems are still present. To take the thread up again, I want to answer to Hamish's question about my problems with r.surf.contour first: DEM interpolation seems to work nice, but when you start deriving maps, especially the aspect map looks simply not right ;-) I've uploaded some example images on our server, so that you can see what I mean: http://www.gis-hosting.lu/static/img/grass/contours5m.png http://www.gis-hosting.lu/static/img/grass/dtm5m.png http://www.gis-hosting.lu/static/img/grass/dtm3d.png http://www.gis-hosting.lu/static/img/grass/expo5m.png The data source is a shape file with contour lines with 5 meters interval. Conversion to raster went well and the pixel values match the height values for the contours. Before using the raster map, I multiplied the map with 10, just like it is mentioned in the wiki. Interpolation took approx. 5 minutes. The region is 10,000m * 10,000m wide and has a 5m resolution. Before deriving the aspect map, I divided the elevation map by 10 to gain real height values again ... Now I wonder what could cause the gaps in the aspect map - since the terrain model itself looks OK to me ... Many thanks Frank -- Frank BRONIEWSKI METRICO s.à r.l. géomètres technologies d'information géographique rue des Romains 36 L-5433 NIEDERDONVEN tél.: +352 26 74 94 - 28 fax.: +352 26 74 94 99 http://www.metrico.lu ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Filling Null values in a MODIS image
Hanlie Pretorius wrote: > Hi, > > I have a MODIS land cover image that contains NULL values according to > r.univar: > - > r.univar map=modis_land_cover_type1_2001_prim...@permanent > total null and non-null cells: 41884 > total null cells: 17145 > - > > So, I tried to fill it with r.fillnulls > - ... > > Output of g.region -p: > - > nsres: 0:00:15.210751 > ewres: 0:00:15.269511 > - > > Output of r.info: > - > r.info map=modis_land_cover_type1_2001_prim...@permanent > Res: 0:00:00.36001 > Res: 0:00:00.36002 Adjust the resolution of the current region to the MODIS image, either g.region rast=modis_land_cover_type1_2001_prim...@permanent or g.region align=modis_land_cover_type1_2001_prim...@permanent if you want to work with custom bounds. That should do the trick Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Filling Null values in a MODIS image
Hi, I have a MODIS land cover image that contains NULL values according to r.univar: - r.univar map=modis_land_cover_type1_2001_prim...@permanent total null and non-null cells: 41884 total null cells: 17145 - So, I tried to fill it with r.fillnulls and I get the following: - r.fillnulls input=mcd12q1.a2001001.005_land_cover_ty...@permanent output=MCD12Q1.A2001001.005_land_cover_type1_filled Locating and isolating NULL areas... Reading input raster map ... Writing output raster map ... Creating interpolation points... Extracting points... Building topology for vector map ... Registering primitives... 0 primitives registered 0 vertices registered Building areas... 0 areas built 0 isles built Attaching islands... Attaching centroids... Number of nodes: 0 Number of primitives: 0 Number of points: 0 Number of lines: 0 Number of boundaries: 0 Number of centroids: 0 Number of areas: 0 Number of isles: 0 r.to.vect complete. Interpolating 0 points Not sufficient points to interpolate. Maybe no hole(s) to fill in the current map region? Removing raster Removing raster Removing raster Removing raster Raster map not found nothing removed Removing vector (Wed Aug 4 10:18:22 2010) Command finished (0 sec) - Output of g.region -p: - g.region -p rast=modis_land_cover_type1_2001_prim...@permanent res=0.00423094 projection: 3 (Latitude-Longitude) zone: 0 datum: wgs84 ellipsoid: wgs84 north: 27:19:08.833466S south: 28:30:53.475952S west: 28:03:57.840271E east: 28:41:37.727966E nsres: 0:00:15.210751 ewres: 0:00:15.269511 rows: 283 cols: 148 cells: 41884 - Output of r.info: - r.info map=modis_land_cover_type1_2001_prim...@permanent ++ | Layer:modis_land_cover_type1_2001_p Date: Thu Jul 29 15:17:55 2010 | Mapset: PERMANENT Login of Creator: hanlie | Location: world_wgs84 | DataBase: /media/0847147784/grassdata | Title: ( MCD12Q1.A2001001.005_land_cover_type1 ) | Timestamp: none | | | Type of Map: raster Number of Categories: 14 | Data Type:CELL | Rows: 11957 | Columns: 6277 | Total Cells: 75054089 |Projection: Latitude-Longitude |N: 27:19:08.833466SS: 28:30:53.475952S Res: 0:00:00.36001 |E: 28:41:37.727966EW: 28:03:57.840271E Res: 0:00:00.36002 | Range of data:min = 1 max = 14 | | Data Description: |generated by r.in.gdal | | Comments: |r.in.gdal input="F:\Hanlie\UCT\M.Sc\Data\modis\MOD12Q1\MCD12Q1.A2001\ |001.h20v11.005.2009342153812_land_cover_type1.tif" output="MCD12Q1.A\ |2001001.005_land_cover_type1" | ++ I have tried to see the NULLS by displaying everything in white, except for NULLS displayed in red, but I didn't see anything. Does anyone know how I can find out if there are actually NULL value and where they are? Thanks Hanlie ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Error while creating vectorial file in WinGRASS
Hamish wrote:
> Hamish wrote:
>> You need to run db.connect to select a database backend to
>> use first. (There is no VAR file in the mapset yet)
>
> hopefully fixed & ready for testing in 6.5svn r42988 (v.edit).
>
>
> devs:
> maybe do this for 'v.in.ascii -e' and 'v.digit -n' too?
> or move this into Vect_open_new() ?
Not to Vect_open_new(), a GRASS vector does not need to have a DB
connection, this is optional.
Markus M
... but I'm not totally
> convinced that's the right place for it either; the mapset may
> come from an earlier version of GRASS. perhaps db.execute
> instead of exiting with an error.
>
>
> #include
> ...
> if (! db_get_default_driver_name() ) {
> G_message(_("Creating new DB connection based on default mapset
> settings..."));
> db_set_default_connection();
> }
>
>
> see bug #7 http://trac.osgeo.org/grass/ticket/7
>
>
> Hamish
>
>
>
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Error while creating vectorial file in WinGRASS
Hamish wrote:
> You need to run db.connect to select a database backend to
> use first. (There is no VAR file in the mapset yet)
hopefully fixed & ready for testing in 6.5svn r42988 (v.edit).
devs:
maybe do this for 'v.in.ascii -e' and 'v.digit -n' too?
or move this into Vect_open_new() ? ... but I'm not totally
convinced that's the right place for it either; the mapset may
come from an earlier version of GRASS. perhaps db.execute
instead of exiting with an error.
#include
...
if (! db_get_default_driver_name() ) {
G_message(_("Creating new DB connection based on default mapset
settings..."));
db_set_default_connection();
}
see bug #7 http://trac.osgeo.org/grass/ticket/7
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Distance-weighted focal functions?
Dylan Beaudette pisze: Hi, After hacking together some R + r.mapcalc code, I started to wonder about how hard it would be to add distance-weighting to r.neighbors... Specifically, the focal distance-weighted mean difference. An example of what I was trying to accomplish can be found here: http://casoilresource.lawr.ucdavis.edu/drupal/node/937 Surely there is a more elegant solution using r.mfilter.fp, or the like... Cheers, Dylan It shoud not be difficult. See solution in r.convergence in ADD-ONS J. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
