Thanks you vezry much for your link, Benjamin. The data seems very promising ... if only I could read it properly ! How do you import ArcGIS Geodatabase tiles into GRASS ?
Thanks for you help and your patience, Felix 2009/9/13 Benjamin Ducke <[email protected]>: > There is some very good hydrodata here: > > http://ccm.jrc.ec.europa.eu/php/index.php?action=view&id=24# > > Two drawbacks: > - non-commercial use only (see license text) > - comes as ArcGIS Geodatabase file (yuck!) > > Version 1 used to be shapefiles, maybe it's still available. > > Ben > > Felix Schalck wrote: >> Dear All-who-may-be-intersted, >> >> First, I'd like to apologize for the delay: lots of stuff prevented me >> from working on the map. I've got some spared time now, and the map >> isn't finished yet - so I'm back into buisiness! >> Secondly, I'd like to thank you Markus, for the great script you sent >> me: it worked withouth a hitch, and I have now a single big shapefile >> to work on. And sorry for the last message: it was a misclick. >> >> Then comes the map: basically, even though the last replies provided >> my with some valuable advices, I'm still stuck with bathymetry - >> rivers and coastlines. >> >> 1. For the bathymetry, I finally took ETOPO1 data, which gives me >> another nice raster, although of much lower resolution (1' compared to >> the 3" topographic raster from SRTM DEM). So the plan is to cut off >> all the land data from the ETOPO1 raster along the coastlines, to keep >> only the sea aeras and than paste this reduced raster onto the main >> SRTM topographic raster of greater resolution. Can this step be >> automated ? (eg: is there a tool to do the job ?) Of course, should >> raster-merge be to complicated, there is always the other option, >> which is to export pngs first, and paste the pngs together; but in >> both cases, the bathymetric raster has to be cut. >> >> 2. Rivers and coastlines are a real pain. >> a. I could import a big pasted SWBD shapefile thanks to Markus script, >> but the cleaning process of the import command takes days, and gets >> somehow stuck within the brigdge removing phase. Result is an >> uncomplete vector map, lacking centroids, which can't be further >> processed by v.generalize for smoothing (the command dies saying there >> is an error in input data), but can be displayed with v.display. >> Another problem are all the square borders left around former SWBD >> tiles in water aeras; can they be removed ? Or do I have to manually >> edit the (huge) vector map ? >> >> b. Then come the rivers: the (somehow corrupted) SWBD vector map shows >> only coastlines, smaller closed waterbodies and - although only >> partially - larger rivers. I somehow have to complete the river data, >> and try following methods: >> -r.watershed command in grass, to compute the rivers from DEM data. >> This command just dies during the memory allocation process (KILL >> signal) because the map is too huge for my system. I tried with >> differend -m parameters, but the command always askes for up to 10gb >> virtual memory the kernel won't be able to provide. I guess I would >> have to work on smaller pieces of the map, set with g.region, and >> paste the results together, but this is another time consuming option. >> -VMAP0 data import works, but the result is quite disappointing. The >> secondary rivers network seems quite good, but this datased is unable >> to fix the uncomplete major rivers from the SWBD dataset. For an >> instance, by showing both layers (SWBD + VMAP0) on the monitor, I get >> all smaller rivers flowing into the rhine, while the rhine itself >> remains divided into several un-joined segments. >> -OSM(openstreetmap) data is a bit confusing. First it is divided along >> countries, so you have to dowload and paste lots of different files. >> Than the" Waterway" shapefile is quite poor. And finally the "natural" >> shapefile comes with nice river data, but also a lot of confusing >> data, like forest aeras. This need some sort of filtering, but I don't >> know at all how to do this. >> >> c. Of course, if someone knows better river datasets (scale approching >> 3", complete, easy to use), I would be happy to try them. >> >> Voila. Even though a lot more problems arise during each step >> (resolution has become another one, for an instance), I hope this >> project will see an end soon. >> Thanks for your help and your patience, >> >> Felix >> >> 2009/8/17 Markus Neteler <[email protected]>: >>> Hi Felix, >>> >>> On Sun, Aug 16, 2009 at 7:37 PM, Felix Schalck<[email protected]> >>> wrote: >>> ... >>>> a - Importing the vectors from SWBD is no problem, tough It would be >>>> nice to have the 200+ NASA shapefiles merged BEFORE importing a new >>>> layer in GRASS. Is this possible with ogr2ogr ? >>> Merge of two SHAPE files 'file1.shp' and 'file2.shp' into a new file >>> 'file_merged.shp' is performed like this: >>> >>> # note order "out", then "in": >>> ogr2ogr file_merged.shp file1.shp >>> ogr2ogr -update -append file_merged.shp file2.shp -nln file_merged file2 >>> >>> The second command is opening file_merged.shp in update mode, and >>> trying to find existing layers and append the features being copied. >>> The -nln option sets the name of the layer to be copied to. >>> >>> Attached a script to do as many as you want. >>> >>>> b - The big problem are coastlines and waterbodies (+main rivers): >>>> somehow I have to show them on the topographic map, which gdalwarp has >>>> filled out with -32768 values in nodata-waterzones. So either I cut >>>> waterbodies out of the topographic raster along the vectors, or I >>>> somehow have GRASS compute me all waterbodies from the vector layer, >>>> fill them with a nice blue and create a raster which can be pasted >>>> over the topographic raster to get the final map. It seems doable >>>> with mapcalc, but frankly, I do not know at all how to proceed. Any >>>> help here would be greatly appreciated. >>> Not sure, but set -32768 to NULL (no data) with r.null? >>> Then use r.colors (nv to set color for NULL): >>> http://grass.osgeo.org/grass64/manuals/html64_user/r.colors.html >>> >>> cheers >>> Markus >>> >> _______________________________________________ >> grass-user mailing list >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/grass-user >> >> > > > -- > Benjamin Ducke > Senior Applications Support and Development Officer > > Oxford Archaeological Unit Limited > Janus House > Osney Mead > OX2 0ES > Oxford, U.K. > > Tel: +44 (0)1865 263 800 (switchboard) > Tel: +44 (0)1865 980 758 (direct) > Fax :+44 (0)1865 793 496 > [email protected] > > > > > ------ > Files attached to this email may be in ISO 26300 format (OASIS Open Document > Format). If you have difficulty opening them, please visit > http://iso26300.info for more information. > > _______________________________________________ > grass-user mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-user > _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
