[GRASS-user] pdf maps
Is there any module in grass to read maps which are in PDF format to raster or vector. ArcGIS can read pdf files as raster maps. may i know the module is available in GRASS or GRASS-Addons repo. - Rashad ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] use of v.surf.rst on big datasets with low memory
Jean Roc wrote: > I'm trying to build a regional DEM based on a contour line > map (3D vector) using v.surf.rst but the process fails with > an memory allocation error when I set my region to a 50m > resolution. what does 'g.region -p' say? (config -> region -> display region) Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: Importing Dems with r.in.xyz
On 06/05/2010 09:45 AM, Hanlie Pretorius wrote: 2010/6/4, Micha Silver: On 06/04/2010 04:20 PM, Hanlie Pretorius wrote: Hi, I've been following the procedure at http://grass.osgeo.org/wiki/Import_XYZ to import DEMs into GRASS. It has worked for two DEMS, but I have a problem with the third one at the step where one "verifies that the number of rows in the ASCII file corresponds to the number of cells in the enlarged region". At this point, g.region reports 1146474 cells in the region, while I have 1146370 lines of coordinates in my file. Assuming you already did the "r.in.xyz -s ..." step to get and set your region to match the input data. So it looks like there are about 100 coordinates missing from the ASCII file. Maybe "holes" in the data? One way to work around this might be to import the point data as a 3D vector, then run the usual v.surf.rst interpolation. v.in.xyz -z in=ascii.txt out=elev_pts z=3 fs=, then g.region vect=elev_pts res= v.surf.rst elev_pts elev=dem layer=0 Thanks for the suggestion, Micha. I've tried the interpolation route before and found that the difference between the resulting interpolated surface and the original DEM was up to 7m. I want to use the DEMs for a flood application, so they need to be as accurate as possible. I wonder if playiing with the "tension" and "smooth" parameters would help? Higher tension (>40) means that the interpolation acts more like a rubber sheet, so each point influences a maller area, and smooth=0 means that the final dem must go exactly thru each point. I was thinking perhaps importing the points as vectors, converting them to raster and then doing a nearest neighbour or IDW interpolation to fill the gaps. At least then I'll be able to see where the gaps are and limit the interpolated pixels using a mask? Worth a try. But as you probably know, nearest neighbor won't take trends in the surface into account. IDW the same. And IDW usually gives worse terrain results than RST. The output of g.region is: - projection: 99 (Transverse Mercator) zone: 0 datum: ** unknown (default: WGS84) ** ellipsoid: wgs84 north: -49312.49 south: -74587.5 west: -3015862.5 east: -2987512.5 nsres: 25.0989 ewres: 25 rows: 1011 cols: 1134 cells: 1146474 - The first three and last three coordinates in my text file are: - -74575.00,-3015850.00,1548.83 -74575.00,-3015825.00,1548.33 -74575.00,-3015800.00,1547.50 . . . -49324.99,-2987575.01,1510.98 -49324.99,-2987550.01,1511.24 -49324.99,-2987525.01,1511.47 - Can someone help me to figure out what's going on? Thanks Hanlie ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user This mail was received via Mail-SeCure System. -- Micha Silver Arava Development Co. +972-52-3665918 http://www.surfaces.co.il This mail was received via Mail-SeCure System. -- Micha Silver Arava Development Co. +972-52-3665918 http://surfaces.co.il ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problem importing netCDF
Hanlie wrote:
> I'm using Win XP and GRASS 6.4RC6 to import a TRMM netCDF
> file using the command:
> -
> r.in.gdal -o input =c:/data/3B42.000202.0.6.nc output=test
> band=precipitation
> -
>
> and am getting the error:
> -
> G_set_window(): Illegal latitude for North
> -
>
> gdalinfo for the file outputs:
> -
> Driver: netCDF/Network Common Data Format
> Files: C:\data\3B42.000202.0.6.nc
>
>C:\data\3B42.000202.0.6.nc.aux.xml
> Size is 512, 512
> Coordinate System is `'
> Metadata:
> NC_GLOBAL#Conventions=CF-1.0
> Subdatasets:
>
> SUBDATASET_1_NAME=NETCDF:"C:\data\3B42.000202.0.6.nc":precipitation
> SUBDATASET_1_DESC=[400x1440] precipitation (32-bit
> floating-point)
>
> SUBDATASET_2_NAME=NETCDF:"C:\data\3B42.000202.0.6.nc":relativeError
> SUBDATASET_2_DESC=[400x1440] relativeError (32-bit
> floating-point)
> Corner Coordinates:
> Upper Left (0.0,0.0)
> Lower Left (0.0, 512.0)
> Upper Right ( 512.0,0.0)
> Lower Right ( 512.0, 512.0)
> Center ( 256.0, 256.0)
> -
in a lat-lon location you can no exceed 90 degrees North or 90 degrees
South.
Your data file has a coordinate system unknown to GDAL (empty) so it
tries to import it with 1 pixel = 1 degree, and gets upset with a coord
of 512 degrees north.
Newer versions of GRASS (6.5+?) have a flag in r.in.gdal to force the map
to fit into geographic space, then you can use r.region to fix the bounds
manually. If you look on the GRASS wiki's "MODIS" page I think you can
find some examples of how to fix this with gdal_translate. The general
idea is to use gdal_translate to extract a GeoTiff from the netCDF file
and set the coord system and geographic bounds, then import that GeoTiff
into GRASS.
> In Panoply (http://www.giss.nasa.gov/tools/panoply/), the
> information
> for the file displays as:
> -
> netcdf file:/C:/data/3B42.000202.0.6.nc {
> dimensions:
>lat = 400;
>lon = 1440;
> variables:
>float precipitation(lat=400, lon=1440);
> :long_name = "precipitation";
> :units = "mm hr-1";
> :_FillValue = -.9f; // float
>float relativeError(lat=400, lon=1440);
> :long_name = "relativeError";
> :units = "mm hr-1";
> :_FillValue = -.9f; // float
>float lat(lat=400);
> :standard_name = "latitude";
> :units = "degrees_north";
> :long_name = "latitude";
> :_CoordinateAxisType = "Lat";
>float lon(lon=1440);
> :standard_name = "longitude";
> :units = "degrees_east";
> :long_name = "longitude";
> :_CoordinateAxisType = "Lon";
>
> :Conventions = "CF-1.0";
> }
> -
>
> In the Panoply array display, the coordinates range from
> 49.875° to
> -49.875° (lattitude) and -179.875° to +179.875°
> longitude. These are
> coordinates for the centres of 0.25° grid cells.
>
> I have set my region according to the documentation for the
> dataset to:
> -
> projection: 3 (Latitude-Longitude)
> zone: 0
> datum: wgs84
> ellipsoid: wgs84
> north: 50N
> south: 50S
> west: 180W
> east: 180E
> nsres: 0:15
> ewres: 0:15
> rows: 400
> cols: 1440
> cells: 576000
> -
good luck,
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: Importing Dems with r.in.xyz
Hanlie wrote: > >> At this point, g.region reports 1146474 cells in the region, while I > >> have 1146370 lines of coordinates in my file. ... > > So it looks like there are about 100 coordinates missing from the ASCII > > ASCII file. 0.01% .. > Maybe "holes" in the data? perhaps this: https://trac.osgeo.org/grass/ticket/123 ?? > I was thinking perhaps importing the points as vectors, converting > them to raster and then doing a nearest neighbour or IDW interpolation > to fill the gaps. At least then I'll be able to see where the gaps are > and limit the interpolated pixels using a mask? No need to do anything different to find the missing pixels. Inspecting the output of r.univar with r.in.xyz's method=n maps can be very useful for troubleshooting. from the help page: Gridded data If data is known to be on a regular grid r.in.xyz can reconstruct the map perfectly as long as some care is taken to set up the region correctly and that the data's native map projection is used. A typical method would involve determining the grid resolution either by examining the data's associated documentation or by studying the text file. Next scan the data with r.in.xyz's -s (or -g) flag to find the input data's bounds. GRASS uses the cell-center raster convention where data points fall within the center of a cell, as opposed to the grid-node convention. Therefore you will need to grow the region out by half a cell in all directions beyond what the scan found in the file. After the region bounds and resolution are set cor- rectly with g.region, run r.in.xyz using the n method and verify that n=1 at all places. r.univar can help. Once you are confident that the region exactly matches the data proceed to run r.in.xyz using one of the mean, min, max, or median methods. With n=1 throughout, the result should be identical regardless of which of those methods are used. with the "n" map you might use r.mapcalc to extract the NULL cells as some value, then r.out.xyz or r.to.vect on th extracts to highlight where they are. Or maybe you get lucky with r.colors with "nv" set to bright magenta on the original data. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
