Re: [GRASS-user] nad grids storage
Dear grass devs and users, sorry for digging up this pretty old topic. It was about the end of my initial message, see bellow (perhaps should I have opened a ticket for it) The question was : is it possible to add the french nad grid to grids provided by default in grass directories ? Everytime I completely rebuild grass (after a make distclean) I have to manually copy the ntf_r93.gsb file into /usr/local/grass-XX.svn/etc/proj/nad/ It would be nice that grass sources included this nad grid ; here in France it is fundamental whenever you need to switch between various geodetic systems (ntf and rgf93). Bye, Vincent. Le jeudi 21 février 2013 à 18:28 +0100, Vincent Bain a écrit : Hi, while discussing with S. Turek about r.in.wms coping with french projection systems, I tested a dataset within grass70. Used to working with grass64 I store the french nadgrid (ntf_r93.gsb) in /usr/share/proj/ directory, making a symlink here: /usr/lib/grass64/etc/nad/ On my local system I noticed for grass70 the grid is taken into account if stored here: /usr/local/grass-7.0.svn/etc/proj/nad/ I am wondering : - if these multiple locations for a single file are necessary; - if they are correct for each version of grass I use; - if it is worth adding the french grid to grids provided by default in grass. Vincent. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] area spanning several UTM zones and dbf driver error
Hello all- I am trying to create a shapefile out of google earth of an area which spans two UTM zones, while setting the map limits, I should use lat lon instead of UTM coordinates, right? However when I am trying to load the shapefile I get the message DBF: driver error, could not create a table. thanks in advance Sonali -- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] [GRASS-dev] nad grids storage
On Sun, Aug 18, 2013 at 10:55 AM, Vincent Bain b...@toraval.fr wrote: Dear grass devs and users, sorry for digging up this pretty old topic. It was about the end of my initial message, see bellow (perhaps should I have opened a ticket for it) Yes, perhaps that's needed. The question was : is it possible to add the french nad grid to grids provided by default in grass directories ? Everytime I completely rebuild grass (after a make distclean) I have to manually copy the ntf_r93.gsb file into /usr/local/grass-XX.svn/etc/proj/nad/ The file comes with PROJ.4 - on my Fedora box here: /usr/share/proj/ntf_r93.gsb We should figure out why it isn't used in your case. I observe that we still have the unsolved issue of using our private copy of these files: [neteler@oboe proj]$ ls -la WO* -rw-r--r--. 1 neteler gis 14111 Nov 25 2008 WO.lla [neteler@oboe proj]$ ls -la /usr/share/proj/WO* -rw-r--r--. 1 root root 2 Feb 17 18:27 /usr/share/proj/WO [neteler@oboe proj]$ file WO* WO.lla: ASCII text [neteler@oboe proj]$ file /usr/share/proj/WO* /usr/share/proj/WO: data ... but with the date of 2008 and no more updates since then. I remember discussions about this some years ago. Due to changes in PROJ.4 we could no longer simply copy over the files. Now, it is time to revisit the mechanism and get rid of these copied files in favour of using those from PROJ.4. Thoughts? Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] area spanning several UTM zones and dbf driver error
On Sun, Aug 18, 2013 at 5:46 PM, Sonali Saha saha...@gmail.com wrote: Hello all- I am trying to create a shapefile out of google earth What is the projection of the SHAPE file? of an area which spans two UTM zones, while setting the map limits, I should use lat lon instead of UTM coordinates, right? Well, you can use only one UTM zone at a time. But there are other metric projections available which have a large extent. For example: in Europe, the EU LAEA (EPSG 3035) is commonly used. However when I am trying to load the shapefile I get the message DBF: driver error, could not create a table. Please copy the commands and error messages as they appear. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Opening a shape file in GRASS 6.4.3
Hi, I tried your data with GRASS 7: # create location from SHP file: grass70 -c Meghalay.shp grassdata/Meghalay # import, here the final working command line: v.in.ogr Meghalay.shp out=Meghalay snap=100 Given that such severe snapping was needed (snapping is in map units, here: meters), you will need to redo the conversion from KML since the geometry in the SHAPE file is broken as the others indicated. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] SRTM r.watershed at multiple scales
On Fri, Aug 16, 2013 at 6:51 PM, jencor808 jencor...@gmail.com wrote: Hello all~ I'm working with SRTM data and trying to produce watershed maps in Honduras. For most of the country, the threshold seems to work great at 10, but this is not the case on the shore - those watersheds are neglected likely due to their smaller scale. Does anyone have experience merging multiple scales? Does this make sense? I'd rather not reduce my threshold or the whole country because those watersheds seem too small. As an aside, what do people think about using SRTM for watershed mapping in the first place - given it is a surface model and not a DEM. While I cannot help you too much with your first question, you may take a look at Metz, M., Mitasova, H., and Harmon, R. S., 2011: Efficient extraction of drainage networks from massive, radar-based elevation models with least cost path search, Hydrol. Earth Syst. Sci., 15, 667-678, doi:10.5194/hess-15-667-2011 http://www.hydrol-earth-syst-sci.net/15/667/2011/hess-15-667-2011.html Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] [GRASS-dev] nad grids storage
Hello Markus, thank you for the information, all in all, IIUC this is basically a question of integrity of register files. It sounds better that grass relies on PROJ.4 updates to handle the correct files. In my case PROJ.4 also provides the grid in /usr/share/proj, but it seems not to be enough. When a projection is supposed to use the grid (i.e. between two distinct geodetic systems), it is simply ignored if absent from /usr/local/grass-XX.svn/etc/proj/nad/ This happens on correctly defined projection systems, for example I have a location named L2e (Lambert II étendu), whith this PROJ_INFO file : name: Lambert Conformal Conic proj: lcc ellps: clark80IGN lat_1: 46.8 lat_0: 46.8 lon_0: 0 k_0: 0.99987742 x_0: 60 y_0: 220 towgs84: -168,-60,320,0,0,0,0 pm: paris no_defs: defined nadgrids:ntf_r93.gsb,null On the other hand, I use a custom script to retrieve raster data from the IGN wmts server. It is based on cs2cs and gdal_translate commands : I noticed the issue is the same. Bye, Vincent Le dimanche 18 août 2013 à 23:59 +0200, Markus Neteler a écrit : On Sun, Aug 18, 2013 at 10:55 AM, Vincent Bain b...@toraval.fr wrote: Dear grass devs and users, sorry for digging up this pretty old topic. It was about the end of my initial message, see bellow (perhaps should I have opened a ticket for it) Yes, perhaps that's needed. The question was : is it possible to add the french nad grid to grids provided by default in grass directories ? Everytime I completely rebuild grass (after a make distclean) I have to manually copy the ntf_r93.gsb file into /usr/local/grass-XX.svn/etc/proj/nad/ The file comes with PROJ.4 - on my Fedora box here: /usr/share/proj/ntf_r93.gsb We should figure out why it isn't used in your case. I observe that we still have the unsolved issue of using our private copy of these files: [neteler@oboe proj]$ ls -la WO* -rw-r--r--. 1 neteler gis 14111 Nov 25 2008 WO.lla [neteler@oboe proj]$ ls -la /usr/share/proj/WO* -rw-r--r--. 1 root root 2 Feb 17 18:27 /usr/share/proj/WO [neteler@oboe proj]$ file WO* WO.lla: ASCII text [neteler@oboe proj]$ file /usr/share/proj/WO* /usr/share/proj/WO: data ... but with the date of 2008 and no more updates since then. I remember discussions about this some years ago. Due to changes in PROJ.4 we could no longer simply copy over the files. Now, it is time to revisit the mechanism and get rid of these copied files in favour of using those from PROJ.4. Thoughts? Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
