[GRASS-user] kml file reading on grass:
i want to read kml files using grass62 is it possiblethen what is the command to read kml files using grass. pls helpme -- bharath.s ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] High resolution dem
Hello all, many thanks for your comments. Just to clarify what I want to do: I have a contour map with 5m contours. I want to create a DEM from it using v.surf.rst, since r.surf.contour fails to do the job correctly. Since I can't do the whole map at once with v.surf.rst due to too high memory usage my plan was to create DEMs from subsets of the region and patch them together afterwards. But due to the nature of the algo used by v.surf.rst the border cells from neighboring (sub)DEMs do not match well. So I am searching for a solution how I can eliminate these differences at the border. My plan was to use some overlapping and r.mapcalc to create some kind of average calculation for the overlapping parts to get a smooth transition for the DEMs. John, your approach looks promising. The only thing that makes me wonder is the usage of r.patch, since it takes always the values from the first raster in the patch list and therefor it cannot average out any differences, at least not from my understanding ... but I will investigate further. Hopefully I find some time on monday to illustrate my method and problem a little bit better with some images. Many thanks so far for all the answers Frank -- From: Nick Cahill ndcah...@wisc.edu Sent: Thursday, February 25, 2010 3:40 PM To: GRASS user list grass-user@lists.osgeo.org Subject: Re: [GRASS-user] High resolution dem Dear all, Just to refer to a previous question - when I have had to make relatively high resolution DEMs (much smaller than yours, only 5000 x 3000 cells), I found it most effective to use Arc/Info to create a TIN from contour lines and points, then rasterize that and import the raster into GRASS, rather than having GRASS interpolate from contours. I was never able to get the parameters right in *.surf.rst, and processing times were very long. Arc/Info does the job very quickly and effectively, and doesn't end up with overshoots and depressions, which were a problem for me. I wish this were an option in GRASS. I would also like to be able to work with other vector-based surface models in GRASS. Nick Cahill Dept of Art History UW-Madison On Feb 25, 2010, at 5:11 AM, John Tate wrote: Hi Frank, Not sure this will help, as I am slightly unsure what you are attempting, but you may be able to apply what I did to create a DEM from tiles. I interpolated my 70 1km tiles with v.surf.rst by interpolating a 1050x1050 cell area (1.05kmsq). I cropped with g.region and r.mapcalc to 1020X1020 (incase of any artefacts - trees are bad for that), and then patched (r.patch) them all together. The patching should average out any differences. I then cropped out each 1km tile (1000x1000). This was done so that the 1km tiles could be combined for specific areas by different people (e.g. only a 4kmsq area for academic 'a' or a 6kmsq area 2km away for academic 'b'). Anyway, from what I understand of your scenario, a hole in a DEM to insert another DEM, create at least a 20 cell overlap for both datasets and r.patch. Hope this helps John On Thursday 25 February 2010 08:45:37 Frank Broniewski wrote: Hello, I am trying to create a high resolution dem from contour lines Until now all my tries where not successful. At first I tried r.surf.contour, but since my interpolation region is not rectangular and the contours are not evenly distributed (rough terrain), the result was unfortunately not usable ( but it took around 7 days to compute, that alone was already impressive ;) ) My contour map is a combinatin of a national contour line map (5m vert. resolution) and contours from SRTM with 20m vert. resolution. I created a hole in the srtm contours for the national contour map and patched both together to avoid large gaps with no height values (mostly for r.surf.contour) My region is 17.000 x 13.000 cells wide (5m horiz. resolution). So my current approach is to use small regions (2000 x 2000) to calculate small subsets of the dem. Because of the algo used by v.surf.rst to create the dem the neighboring tiles do have different height values calculated at the borders. So it was not possible to just create the tiles and patch them together. My next approach used an overlapping of 20 cells for each tile and a moving window average to calculate the mean of the overlapping tiles. The result was quite good, but the moving window approach resulted in null values where one tile ended and the other started (similar to the slope and aspect maps, where there is a 1 cell null border around the map in comparison to the input dem). Unfortunately I was not able to remove the null values satisfactorily. r.fillnulls fails because of the large region, and r.resamp.rst does the job not very well. The stripes are still visible, though filled with values. When calculating a derivate from the dem, like aspect, the errors from filling null values are quite obvious. So to make my
Re: [GRASS-user] kml file reading on grass:
On Fri, Feb 26, 2010 at 9:32 AM, bharath s bharath.set...@gmail.com wrote: i want to read kml files using grass62 is it possiblethen what is the command to read kml files using grass. pls helpme You can use v.in.ogr for this *if* your OGR installation has been compiled with libexpat support. See also http://www.gdal.org/ogr/drv_kml.html for details. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Warning message while using r.in.gdal
2010/2/25 António Rocha antonio.ro...@deimos.com.pt: Hi all I have Location/Mapset with this characteristics: g.region -p projection: 3 (Latitude-Longitude) zone: 0 datum: wgs84 ellipsoid: wgs84 I'm I'm trying to import a file with the following geographic characteristics (using gdalinfo): Driver: GTiff/GeoTIFF Files: euro_area_latlong.tif Size is 1721, 595 Coordinate System is: GEOGCS[WGS 84, DATUM[unknown, SPHEROID[unnamed,6378137,298.2572235629972]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433]] When I do r.in.gdal, to import this file, I get the following Warning: Datum unknown not recognised by GRASS and no parameters found Projection of input dataset and current location appear to match please post the output of gdalinfo euro_area_latlong.tif It imports but it wasn't suppose to get this error since i'm using the same coordinate/projection system. How can I avoid this? Should I add more information to destination_projection when I warped that file? Either the metadata in euro_area_latlong.tif are read correctly by GDAL or a definition is missing or the metadata are incorrect in the file. From the gdalinfo output we may understand more... Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] bug or buffer for polygons impossible ?
Yvan Paillé wrote: I try to create a buffer around a polygon with the following commande: v.buffer input=... output= distance=10 This creates the buffer visible in the following picture: http://dl.lyon.cemagref.fr/get?k=yQnyOaVULt3QQmOSSVa Why is the buffer not uniform? (Regarding the upper left corner, one corner misses). http://dl.lyon.cemagref.fr/get?k=IF0oiMFkqyVC9L9SCeA http://dl.lyon.cemagref.fr/get?k=zCtzYAQDCXMYdz6TUoE http://dl.lyon.cemagref.fr/get?k=IWMhOGONCrDQevnMRck Other errors... Is this a bug in the v.buffer function, or do I try to use the buffer function on polygons, which is not possible? I'm working on WinGRASS 6.4. Many thanks for any help! it's a bug. see https://trac.osgeo.org/grass/ticket/90 usually the effect is minor but maybe it is much worse on MS Windows?? (I haven't tried) Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] unable to read kml file in grass:
hello iam working on grass64 ubuntu... i want to import kml files to grass i tried v.in.ogr but i got error showing that: Unable to open data source /home/bharath/water.kml please help me -- bharath.s ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] unable to read kml file in grass:
On Fri, Feb 26, 2010 at 2:54 PM, bharath s bharath.set...@gmail.com wrote: hello iam working on grass64 ubuntu... i want to import kml files to grass i tried v.in.ogr but i got error showing that: Unable to open data source /home/bharath/water.kml please help me Does ogr2ogr --formats list KML as supported format? If not, it has to be recompiled with libexpat support. For this, please contact the Ubuntu package maintainer for GDAl-OGR: https://launchpad.net/~ubuntugis/+archive/ubuntugis-unstable Once it is present in OGR (so, ogr2ogr etc), then also v.in.ogr will be able to read it. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: LAS to DEM
Thank you! -- View this message in context: http://n2.nabble.com/LAS-to-DEM-tp4633147p4639451.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
Fwd: [GRASS-user] Apply a segmentation to derive objects
You are absolutely right :) My mistake. SMAP is a segmentation algorithm. But my idea was not to use SMAP as a classification but use a Segmentation process and only then a Supervides Classification. Or if Use SMAP I'm doing both things in this order? Thanks Markus Nikos On Mon, Jan 18, 2010 at 11:22 PM, Markus Neteler nete...@osgeo.org wrote: On Mon, Jan 18, 2010 at 6:30 PM, Nikos Dumakis nikosdu1...@gmail.com wrote: Greetings all I've been following GRASS-user discussion related with pos-classigfication, classification, aggregation and so on. But, while I was readingh those emails I figured that I will need to perform, before classification, an image segmentation to derive objects. You don't need to perform a segmentation before doing classification but i.smap is doing it in a combined way. Can anyone give me a clue abvout that because in GRASS book, I only founded Image segmentation related with processing large quantities of vectorial data (DEM's). (DEMs are raster data) What you need to do is to prepare the statistics with i.gensigset. See radiometric geometric supervised in http://grass.osgeo.org/wiki/Image_classification (The book is explaining that as well) Hope this helps, Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Warning message while using r.in.gdal
Hi Markus Here goes the gdalinfo euro_latlon.tif output: Driver: GTiff/GeoTIFF Files: Desktop/euro_area_latlong.tif Size is 1721, 595 Coordinate System is: GEOGCS[WGS 84, DATUM[unknown, SPHEROID[unnamed,6378137,298.2572235629972]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433]] Origin = (-36.828910669041655,74.067423529421049) Pixel Size = (0.066529120923939,-0.066529120923939) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( -36.8289107, 74.0674235) ( 36d49'44.08W, 74d 4'2.72N) Lower Left ( -36.8289107, 34.4825966) ( 36d49'44.08W, 34d28'57.35N) Upper Right ( 77.6677064, 74.0674235) ( 77d40'3.74E, 74d 4'2.72N) Lower Right ( 77.6677064, 34.4825966) ( 77d40'3.74E, 34d28'57.35N) Center ( 20.4193979, 54.2750101) ( 20d25'9.83E, 54d16'30.04N) Band 1 Block=1721x2 Type=Int16, ColorInterp=Gray Hope this helps Markus Neteler wrote: 2010/2/25 António Rocha antonio.ro...@deimos.com.pt: Hi all I have Location/Mapset with this characteristics: g.region -p projection: 3 (Latitude-Longitude) zone: 0 datum: wgs84 ellipsoid: wgs84 I'm I'm trying to import a file with the following geographic characteristics (using gdalinfo): Driver: GTiff/GeoTIFF Files: euro_area_latlong.tif Size is 1721, 595 Coordinate System is: GEOGCS[WGS 84, DATUM[unknown, SPHEROID[unnamed,6378137,298.2572235629972]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433]] When I do r.in.gdal, to import this file, I get the following Warning: Datum unknown not recognised by GRASS and no parameters found Projection of input dataset and current location appear to match please post the output of gdalinfo euro_area_latlong.tif It imports but it wasn't suppose to get this error since i'm using the same coordinate/projection system. How can I avoid this? Should I add more information to destination_projection when I warped that file? Either the metadata in euro_area_latlong.tif are read correctly by GDAL or a definition is missing or the metadata are incorrect in the file. From the gdalinfo output we may understand more... Markus __ Information from ESET NOD32 Antivirus, version of virus signature database 4896 (20100225) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 4898 (20100226) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Warning message while using r.in.gdal
2010/2/26 António Rocha antonio.ro...@deimos.com.pt: Hi Markus Here goes the gdalinfo euro_latlon.tif output: Driver: GTiff/GeoTIFF Files: Desktop/euro_area_latlong.tif Size is 1721, 595 Coordinate System is: GEOGCS[WGS 84, DATUM[unknown, SPHEROID[unnamed,6378137,298.2572235629972]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433]] Origin = (-36.828910669041655,74.067423529421049) Pixel Size = (0.066529120923939,-0.066529120923939) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( -36.8289107, 74.0674235) ( 36d49'44.08W, 74d 4'2.72N) Lower Left ( -36.8289107, 34.4825966) ( 36d49'44.08W, 34d28'57.35N) Upper Right ( 77.6677064, 74.0674235) ( 77d40'3.74E, 74d 4'2.72N) Lower Right ( 77.6677064, 34.4825966) ( 77d40'3.74E, 34d28'57.35N) Center ( 20.4193979, 54.2750101) ( 20d25'9.83E, 54d16'30.04N) Band 1 Block=1721x2 Type=Int16, ColorInterp=Gray Hope this helps yes and no: garbage in - garbage out... Apparently the metadata aren't properly stored in the file (what should be there?). Since GRASS cannot guess them, it remains unknown. If you *know* the correct metadata, you can assign them to the GeoTIFF file with gdal_translate -a_srs epsg: geotiff_bad.tif geotiff_good.tif r.in.gdal geotiff_good.tif out=geotiff_good cheers, Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Problem with r.xtent installation
Good Morning, I have a problem trying to install r.xtent addon on GRASS GIS 6.4.0rc5 on Kubuntu 9.10 64bit installed through UbuntuGIS unstable repository (grass and grass-dev). I tried through GEM but either 'gem64' or 'gem' return to command not found; GEM appear in my computer in /usr/lib/grass64/etc/gem but only with the subdirectory /skeleton. I have tried to compile downloading by svn r.xtent in /usr/lib/grass64 with the command sudo make MODULE_TOPDIR=/usr/lib/grass64 but it usually fails because several library are not present in the new made folder /build/buildd. Can someone help me? Best Simone ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] unable to read kml file in grass:
Hello I'm working on gras64 ubuntu too, it has kml support! leonaro Hardtke Markus Neteler escribió: On Fri, Feb 26, 2010 at 2:54 PM, bharath s bharath.set...@gmail.com wrote: hello iam working on grass64 ubuntu... i want to import kml files to grass i tried v.in.ogr but i got error showing that: Unable to open data source /home/bharath/water.kml please help me Does ogr2ogr --formats list KML as supported format? If not, it has to be recompiled with libexpat support. For this, please contact the Ubuntu package maintainer for GDAl-OGR: https://launchpad.net/~ubuntugis/+archive/ubuntugis-unstable Once it is present in OGR (so, ogr2ogr etc), then also v.in.ogr will be able to read it. Markus ___ 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
[GRASS-user] ps.map: Area Fill Color Transparency
Using the vareas section of ps.map, is it possible to specify transparency in the fcolor specification? Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] HTML manuals languages
Markus Neteler wrote: As I said last time, first we need to determine whether: 1. A single set of manual pages are installed, for a single language, or: 2. Multiple languages are installed, in which case how are the files named and in which directories are they stored? My suggestion some years ago was: - naming scheme: description|module_ISO.html - put files alongside the description|module.html files - prefer existing description|module_ISO.html files in the installed docs/html/ directory over the english one while having in the header or footer the link to the english page Also, if a translated manual page doesn't exist, the English version would presumably be used, but should the --html-description header be generated in English or in the selected language? IMHO in the selected language to have as much as possible available in that language (btw, the Japanese team translated almost all .po files in one month!). So you want something like: for each module: generate non-localised --interface-description header (with LC_ALL=C) generate $GISBASE/docs/html/module.html from module.html and the non-localised header for each language in desired languages: generate --interface-description header for that language if module_lang.html exists: generate $GISBASE/docs/html/module_lang.html from module_lang.html and the localised header else: generate $GISBASE/docs/html/module_lang.html from module.html and the localised header ? What about the (nroff) manual pages? As for links between manual pages: The generated headers don't contain any links. The only links are those put there by the author of the module.html file. Authors of localised module.html files can put links to the localised versions of other files if they exist. However: if a semi-localised HTML file is generated by combining the localised header with the English module.html, any links will refer to the English version even if a localised or semi-localised version exists. An alternative approach would be to put localised and semi-localised versions of HTML files in a separate directory, i.e. $GISBASE/docs/html/lang/module.html. As the See Also links are relative, they will always refer to the (semi-) localised version in the same directory. The alternative would be to process the HTML files to re-write any links to point to the localised version, which means writing the code to do it (as well as recognising any links which shouldn't be re-written). -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] ps.map: Area Fill Color Transparency
Rich Shepard wrote: Using the vareas section of ps.map, is it possible to specify transparency in the fcolor specification? fcolor none should result in the areas be unfilled. If you want translucency, PostScript doesn't support that. However, you can use the pat option to specify a pattern. Varying the pwidth option should affect the effective opacity of the fill. -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] ps.map: Area Fill Color Transparency
On Fri, 26 Feb 2010, Glynn Clements wrote: fcolor none should result in the areas be unfilled. It does. If you want translucency, PostScript doesn't support that. Oh, that's right. Slipped my mind. However, you can use the pat option to specify a pattern. Varying the pwidth option should affect the effective opacity of the fill. I will figure that one out. Thanks, Glynn, Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] [r.resample] null values for min and max range of data values
On Thu, Feb 25, 2010 at 9:21 AM, baobazz baob...@hotmail.fr wrote: ... (welcome!)... Initially, I wanted to vectorize an image After having imported it, I tried to thin it through the r.thin command. But the image produced being too big, it caused errors on my computer. What kind of error exactly? You seem to use Windows, which version of GRASS? To solve my problem, I decided to reduce my location resolution: res=2, then that of my raster with r.resample... The problem is that my resampled raster output is empty. When typing r.info raster.resampled, I get: r.info raster.resampled2 ... | Type of Map: raster Number of Categories: 0 | Data Type: CELL | Rows: 500 | Columns: 500 | Total Cells: 25 | Projection: Lambert Conformal Conic | N: 6133000 S: 6132000 Res: 2 | E: 1235000 W: 1234000 Res: 2 | Range of data: min = NULL max = NULL ... | r.in.gdal input=C:/tests/GRASS/rasterToVect/BDP_08_1234_6134_010_L9\ | 3.tif output=raster ... What is strange is the null range of data... Yes, no good. The r.info for my raster input, not resampled is: r.info raster6133_2 ... | Rows: 1 | Columns: 1 | Total Cells: 1 (same position) | Range of data: min = 0 max = 1 One thing I don't understand: Why do you use r.in.gdal after r.resample? Please outline the workflow to be better able to help you. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Warning message while using r.in.gdal
António Rocha wrote: Hi all I have Location/Mapset with this characteristics: g.region -p projection: 3 (Latitude-Longitude) zone: 0 datum: wgs84 ellipsoid: wgs84 I'm I'm trying to import a file with the following geographic characteristics (using gdalinfo): Driver: GTiff/GeoTIFF Files: euro_area_latlong.tif Size is 1721, 595 Coordinate System is: GEOGCS[WGS 84, DATUM[unknown, SPHEROID[unnamed,6378137,298.2572235629972]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433]] When I do r.in.gdal, to import this file, I get the following Warning: Datum unknown not recognised by GRASS and no parameters found Projection of input dataset and current location appear to match It imports but it wasn't suppose to get this error since i'm using the same coordinate/projection system. No, because datum unkown does not match datum wgs84 and speroid (ellipsoid) unnamed does not match ellipsoid wgs84 although SPHEROID[unnamed,6378137,298.2572235629972]] describes ellipsoid wgs84. If you can confirm that the datum of the raster to be imported is indeed wgs84, everything should be all right, otherwise set up a new location with the CRS of the raster to be imported. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] ps.map: Error Using Fill Patterns
In an input file to ps.map I have a vareas section with this: vareas house_basin pat $GISBASE/etc/paint/patterns/diag_down6.eps fcolor magenta end The module runs, but when I try to display the map using gv I get the raster displayed, but no vector maps. The following error is displayed in a separate window: Error: /rangecheck in --makepattern-- Operand stack: --dict:7/7(L)-- --nostringval-- false --dict:7/8(L)-- --nostringval-- Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1905 1 3 %oparray_pop 1904 1 3 %oparray_pop 1888 1 3 %oparray_pop 1771 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- 1854 2 3 %oparray_pop --nostringval-- Dictionary stack: --dict:1156/1684(ro)(G)-- --dict:0/20(G)-- --dict:115/200(L)-- Current allocation mode is local Last OS error: 2 Current file position is 62506913 GPL Ghostscript 8.63: Unrecoverable error, exit code 1 Ideas appreciated in how to resolve this. Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] ps.map: Error Using Fill Patterns
On Fri, 26 Feb 2010, Rich Shepard wrote: Ideas appreciated in how to resolve this. Permissions not correct in /usr/local/grass-6.4svn/. Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] ps.map: Error Using Fill Patterns
On Fri, 26 Feb 2010, Rich Shepard wrote: Permissions not correct in /usr/local/grass-6.4svn/. What should the perms be? Here's the error: can't open eps file $GISBASE/etc/paint/patterns/diag_up6.eps But, from within grass64 I can successfully 'less $GISBASE/etc/paint/patterns/diag_up6.eps' Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Using d.shadedmap with ps.map
I am having difficulties getting nviz to produce quality maps (version 6.4svn). Using d.shadedmap and annotating with The GIMP produces a fine product. Is there a way to incorporate the capabilities of d.shadedmap within a ps.map script? The display command drapes a raster over a shaded relief raster while the latter seems to only overlay vector maps on a single raster map. Despite reading the nviz tutorial and manual several times I still cannot get the north arrow, legends, or other annotations to produce sufficiently high quality output. Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] ps.map: Error Using Fill Patterns
Rich Shepard wrote: Here's the error: can't open eps file $GISBASE/etc/paint/patterns/diag_up6.eps But, from within grass64 I can successfully 'less $GISBASE/etc/paint/patterns/diag_up6.eps' by the time it gets to that error message, the $GISBASE should have been expanded to the full path, but for some reason it hasn't been. Shell variables only work from the shell, so if you get ps.map instructions from an input file you need the full path. On the other hand if you do: ps.map out=test.ps EOF ... pattern $GISBASE/etc/paint/... ... EOF shell variables are ok get expanded. BUT, this is a PITA for version/machine portability of instruction files so r_vareas.c scans the filename string for $GISBASE and expands it to G_gisbase() if needed. For some reason in yours it gets past that expansion somehow. I'm not sure why but the quick fix is to just spell out the full path to the file and not use the variable. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Using d.shadedmap with ps.map
Rich Shepard wrote: I am having difficulties getting nviz to produce quality maps (version 6.4svn). Using d.shadedmap and annotating with The GIMP produces a fine product. nviz elev=dem color=landsat ? Is there a way to incorporate the capabilities of d.shadedmap within a ps.map script? see the ps.output addon program for one way. otherwise with ps.map you have to compose with d.shademap, then use 'd.out.file format=geotiff' with desired rows,cols and then r.in.gdal the composite image back in. then you can use it with ps.map. The display command drapes a raster over a shaded relief raster while the latter seems to only overlay vector maps on a single raster map. d.shademap only runs with 2 rasters (but you can overlay other d.* commands too). ps.map limits you to a single raster map, or RGB 3-raster group. nviz will let you load multiple rasters. in addition, most Surface Attributes for each map can be another raster map. (I've sort of lost track of which module(s) this question is about) Despite reading the nviz tutorial and manual several times I still cannot get the north arrow, legends, or other annotations to produce sufficiently high quality output. you can't get them to work at all? or e.g. the Arrow falls on top of the word North etc. they are generally functional, but are still rather clunky to use. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
