Re: re: [GRASS-user] Very high resolution topographic map of Europe: need help and advices: UPDATE
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 : > Hi Felix, > > On Sun, Aug 16, 2009 at 7:37 PM, Felix Schalck 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,
Re: [GRASS-user] GRASS flyers in Russian?
On Sat, Sep 12, 2009 at 8:24 PM, Ivan Shmakov wrote: > Are there any GRASS flyers in Russian? > > FWIW, I've made a translation of the one in the GRASS add-ons > section, and put it at: > > http://waterlily.ip.uusia.org/~ivan/doc-files/grassflyer-r35527/flyer1/ru/ > grassflyer.pdf > grassflyer.ps > grassflyer.tex > > There're still some weak spots, and probably a lot of typos, so > I hope that those who speak Russian could take a look at it. > > Software freedom day [1] seems like a good opportunity to give a > few of these flyers away. > > [1] http://softwarefreedomday.org/ Excellent! Here, for synchronization, a message which was sent by Astrid Emde recently to the OSGeo Marketing list: On Sat, Sep 12, 2009 at 9:51 AM, Astrid Emde wrote: > Hello marketing-group, > > we are preparing the OSGeo park on INTERGEO in Karlsruhe (Germany). Some > people worked on the OSGeo brochures and updated teh existing brochures > (english) and added new brochures in german language. > > To get them all at one place I commited the new and updated documents to > the osgeo-svn. > > have a look at: > https://svn.osgeo.org/osgeo/marketing/flyer/ > > I created a new directory for OpenOffice files (we set up the brochures > with OpenOffice) > * https://svn.osgeo.org/osgeo/marketing/flyer/project_brochures_odt/ > In the directory you find subdirectories for the languages > https://svn.osgeo.org/osgeo/marketing/flyer/project_brochures_odt/de > https://svn.osgeo.org/osgeo/marketing/flyer/project_brochures_odt/en > > In the directory "project_brochure_pdfs" I created a subdirectory "de" for > the pdfs which are in german language: > https://svn.osgeo.org/osgeo/marketing/flyer/project_brochure_pdfs/de/ > > Name convention for the file: > * I took the the english name and added _de > * like OSGeo_Brochures_QGIS_de.odt and OSGeo_Brochures_QGIS_de.pdf > > Sorry - that I did not discuss all this changes with the marketing group. > Feel free to change the structure. My purpose was, to get all the > documents together and don't have them spread all over. > > What do you think? > > Astrid > > ___ > Marketing mailing list > market...@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/marketing Perhaps efforts could be merged? Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] GRASS flyers in Russian?
Are there any GRASS flyers in Russian? FWIW, I've made a translation of the one in the GRASS add-ons section, and put it at: http://waterlily.ip.uusia.org/~ivan/doc-files/grassflyer-r35527/flyer1/ru/ grassflyer.pdf grassflyer.ps grassflyer.tex There're still some weak spots, and probably a lot of typos, so I hope that those who speak Russian could take a look at it. Software freedom day [1] seems like a good opportunity to give a few of these flyers away. [1] http://softwarefreedomday.org/ -- FSF associate member #7257 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.in.gdal error
Alexandre: > While trying to import ("r.in.gdal") an ESRI grid (.adf > downloaded from WorldClim) within a location created with > EPSG 4326 (WGS1984 lon lat), I get the following message > "G_set_window(): Illegal latitude for North" > Looking quickly into the list archive and in r.in.gdal > manual, I found this might come from a file with no > coordinate system. However, I checked this with ArcGis and > the file I try to import has the right datum and a prj.adf > along with the hdr.adf (the target file for r.in.gdal). > So what does that mean ? Can't GRASS read the prj.adf ? Or > is there something else ? > > Alex > > P.S.: if there is no solution I will try what is suggested > by the manual, even if I did not fully get what was > suggested yet... see http://grass.osgeo.org/wiki/GRASS_FAQ#Errors that is not so clear either*, but if you are using 6.4 probably the best solution is to use gdal_translate to convert the adf grid into a GeoTiff as an intermediary step, using the "-a_ullr -180 90 180 -90" option to tell it what the bounds are. I'd avoid the simple XY solution mentioned in the wiki if you already have hard numbers about what the bounds should be set to. [*] please help improve The important thing to check is that the gdalinfo program can see the bounds/projection settings. If GDAL can't figure out what they are there's little chance GRASS can. If you are using grass 6.5 or 7 you can just use the 'r.in.gdal -l' flag to force it, then r.region to fix it. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.in.gdal error
Good afternoon, While trying to import ("r.in.gdal") an ESRI grid (.adf downloaded from WorldClim) within a location created with EPSG 4326 (WGS1984 lon lat), I get the following message "G_set_window(): Illegal latitude for North" Looking quickly into the list archive and in r.in.gdal manual, I found this might come from a file with no coordinate system. However, I checked this with ArcGis and the file I try to import has the right datum and a prj.adf along with the hdr.adf (the target file for r.in.gdal). So what does that mean ? Can't GRASS read the prj.adf ? Or is there something else ? Alex P.S.: if there is no solution I will try what is suggested by the manual, even if I did not fully get what was suggested yet... -- Alexandre Villers PhD Student Team "Biodiversity" Centre d'Etudes Biologiques de Chizé-CNRS UPR1934 79360 Beauvoir sur Niort Phone +33 (0)5 49 09 96 13 Fax +33 (0)5 49 09 65 26 __ Information from ESET Mail Security, version of virus signature database 4419 (20090912) __ The message was checked by ESET Mail Security. http://www.eset.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] where is r.clim?
On Sat, Sep 12, 2009 at 12:30 AM, Wolf Bergenheim wrote: > Hello Jeff, > > I think that the r.clim module wasn't ever submitted to GRASs (I may > be wrong it was before my time). I was unable to find an email address > to Chiara Sboarina that would be fresh, however, I did find an article > from FOSS4G 2008 (pretty recent) that Chiara Sboarina was a co author > in. There was only one email address, but you can probably get in > touch with Chiara Sboarina through that contact: > http://conference.osgeo.org/index.php/foss4g/2008/paper/view/106/36 > > Another possible way could be to ask Markus Neteler (Cc:d), he might > know Chiara Sboarina. I am working now in the same place she was working some years ago :) Investigating off-list, will keep you informed. Best Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user