[GRASS-user] Snap distance to clean imported map?
Importing a large (4.4G) vector map of wetlands takes a long time even on my 8-core/16-thread, 32G desktop. When it finally completed grass recommended re-importing with an additional 'snap' distance specified: Command line: > v.in.ogr in=OR_geodatabase_wetlands.gdb out=more_wetlands loc=geo_wetlands WARNING: Number of incorrect boundaries: 88544 - WARNING: The output contains topological errors: Unable to calculate a centroid for 329691 areas Number of incorrect boundaries: 88544 The input could be cleaned by snapping vertices to each other. Estimated range of snapping threshold: [1e-09, 1] Try to import again, snapping with 1e-05: 'snap=1e-05' In the past 1e-05 produced similar warnings. I'd like advice on two issues: 1) Is 1e-05 the most reasonable starting snap distance? (I assume it is a generic value but perhaps not for all maps.) If not, what would be a snap distance to use? 2) What would be a reasonable snap distance to stop re-importing when warnings continue to be displayed? TIA, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Organizing data over extensive areas [RESOLVED]
On Wed, 11 Sep 2019, Rich Shepard wrote: Is there a way to put a collection of locations in a single subdirectory, e.g., /data/grassdata/fishes/ and have grass know how to find them? Never mind, I figured it out. I wrote a script to reproject the map from each individual location's PERMANENT mapset to an existing location's biota mapset. When I have projects in other locations I can reproject from this core one to that of each individual project. Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Organizing data over extensive areas
I imported an OpenFileGDB containing the distributions of 14 species and runs of fish in the Columbia River Basin. Because one species has a different CRS than the others each layer needed to be separately imported into separate locations. This is inefficient and I would like to gather them in a directory, perhaps named 'fishes.' The issue is that collectively, the distributions cover most of Washington and Oregon along with bits of Canada, Idaho, Wyoming, Nevada, and California (drainage basin extents). So a projection covering all these areas will be different from the standard projections used by each state and British Columbia. Is there a way to put a collection of locations in a single subdirectory, e.g., /data/grassdata/fishes/ and have grass know how to find them? TIA, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Explain v.in.ogr error
Trying to import an ESRI FileGDB with 10m DEM for Oregon. I don't understand what I've done incorrectly and would appreciate learning from the grass command error message. Input file is OR_DEM_10M.gdb $ ogrinfo -al -so Geometry: Multi Polygon Feature Count: 1 Extent: (-106508955.00, -85400955.00) - (109133655.00, 130241655.00) Layer SRS WKT: PROJCS["NAD_1983_Oregon_Statewide_Lambert_Feet_Intl", GEOGCS["GCS_North_American_1983", DATUM["North_American_Datum_1983", SPHEROID["GRS_1980",6378137.0,298.257222101]], PRIMEM["Greenwich",0.0], UNIT["Degree",0.0174532925199433]], PROJECTION["Lambert_Conformal_Conic_2SP"], PARAMETER["False_Easting",1312335.958005249], PARAMETER["False_Northing",0.0], PARAMETER["Central_Meridian",-120.5], PARAMETER["Standard_Parallel_1",43.0], PARAMETER["Standard_Parallel_2",45.5], PARAMETER["Latitude_Of_Origin",41.75], UNIT["Foot",0.3048]] FID Column = OID Geometry Column = FOOTPRINT RASTER: Binary (0.0) FOOTPRINT_Length: Real (0.0) FOOTPRINT_Area: Real (0.0) Run error: v.in.ogr input=/data/grassdata/OR_DEM_10M.gdb output=dem10m Check if OGR layer contains polygons... Creating attribute table for layer ... WARNING: Column type (Ogr_ftype: 8) not supported (Ogr_fieldname: RASTER) Importing 1 features (OGR layer )... DBMI-SQLite driver error: Error in sqlite3_prepare(): table dem10m has 4 columns but 3 values were supplied DBMI-SQLite driver error: Error in sqlite3_prepare(): table dem10m has 4 columns but 3 values were supplied ERROR: Cannot insert new row for input layer : insert into dem10m values ( 1, 862570440, 4.65017352476121e+16 ) (Wed Sep 11 08:48:30 2019) Command finished (0 sec) Is the .gdb download corrupted? Regards, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] tiling and 'cliping' DEMs
On Wed, 11 Sep 2019, Nikos Alexandris wrote: If there is no need for a GDAL VRT, then, alternatively, link all tiles as pseudo-raster maps in GRASS GIS' data base, of course using `r.external`. Then, build a GRASS GIS virtual raster data set using `r.buildvrt`. Clipping or "extracting" parts of this VRT will expectedly work. Nikos, I've insufficient experience to know whether there is need for GDAL VRT. But I'll look closely at what you and Helmut advise and gain some experience. Many thanks, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] tiling and 'cliping' DEMs
On Tue, 10 Sep 2019, Helmut Kudrnovsky wrote: To save diskspace,, build a virtual raster with your tiles outside GRASS by GDAL's buildvrt, do r.external yourvirtual.vrt. No import is needed for raster calculations, r.external to link the virtual raster works nicely.. regarding to clip a raster to vector extent, there a several ways. One may be: g.region -a raster=yourraster vector=yourvector followed by a r.mask vector=yourvector then r.mapcal clippedraster=yourraster Helmut, This is exceptionally useful information. I've not looked closely at gdal and don't know all its capabilities. Perhaps this could be added to the Wiki as it's likely to be useful to others. I greatly appreciate the lesson. Best regards, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] tiling and 'cliping' DEMs
* Helmut Kudrnovsky [2019-09-10 20:12:09 -0700]: Rich Shepard wrote I am downloading and importing 1m LiDAR DEMs for a 667 mi^2 (1727.5 km^2) drainage basin. These are all in 7.5' topographic quad sections. The files take up a lot of disk space and memory when working with them. I assume that by careful setting of the region I can display the individual maps as a single map, and I can set a computational mask using the vector basin watershed (boundary). Is there way to 'clip' the DEM using the watershed map in the way that v.clip works with two vector maps? While the workstation has 32G RAM and 2T of disk space I would like to limit the DEM to the drainage basin itself and exclude all areas outside it. Looking at all the r.* modules in core and extensions none strikes me as the appropriate tool. I'm open to advice on working with huge raster files. Regards, Rich ___ grass-user mailing list grass-user@.osgeo https://lists.osgeo.org/mailman/listinfo/grass-user To save diskspace,, build a virtual raster with your tiles outside GRASS by GDAL's buildvrt, do r.external yourvirtual.vrt. No import is needed for raster calculations, r.external to link the virtual raster works nicely.. If there is no need for a GDAL VRT, then, alternatively, link all tiles as pseudo-raster maps in GRASS GIS' data base, of course using `r.external`. Then, build a GRASS GIS virtual raster data set using `r.buildvrt`. Clipping or "extracting" parts of this VRT will expectedly work. Nikos regarding to clip a raster to vector extent, there a several ways. One may be: g.region -a raster=yourraster vector=yourvector followed by a r.mask vector=yourvector then r.mapcal clippedraster=yourraster ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
