Re: [GRASS-user] DEM to DTM

2016-09-15 Thread Laurent C.
Hello José, There is basically three global DEM freely available: - Aster DEM, which is agreed to be garbage - SRTM, which is the reference - the newly released ALOS DEM, which seems to be the best quality of all 3. They are surface models, so trees and buildings are affecting the altitude

Re: [GRASS-user] DEM to DTM

2016-09-15 Thread Eddison Araya
El 15/9/2016 9:00 a. m., "José Anderson" escribió: > > Dear all, > > I'm in need to start a study in a urban area in which the DTM ( https://en.wikipedia.org/wiki/Digital_elevation_model) is to be obtained from a DEM (SRTM or ASTER). > > I've seen GRASS7 can provide

Re: [GRASS-user] Comment on 7.3svn GUI

2016-09-15 Thread Anna Petrášová
On Thu, Sep 15, 2016 at 10:26 PM, Rich Shepard wrote: > On Thu, 15 Sep 2016, Anna Petrášová wrote: > >> I found out that it's the wx.aui docking widget, which causes the change >> in cursor for all the widgets. I am not sure what to do about it, it would >> be good to

Re: [GRASS-user] Comment on 7.3svn GUI

2016-09-15 Thread Rich Shepard
On Thu, 15 Sep 2016, Anna Petrášová wrote: I found out that it's the wx.aui docking widget, which causes the change in cursor for all the widgets. I am not sure what to do about it, it would be good to test it with wxPython Phoenix (the new version of wxPython). Anna, I don't have time now

Re: [GRASS-user] Comment on 7.3svn GUI

2016-09-15 Thread Anna Petrášová
On Thu, Sep 15, 2016 at 5:13 PM, Rich Shepard wrote: > When the mouse/trackball pointer is over a checkbox and similar controls > the shape changes from an arrow to a small, open box with short arrows from > the upper left and lower right corners. This blocks viewing

[GRASS-user] Comment on 7.3svn GUI

2016-09-15 Thread Rich Shepard
When the mouse/trackball pointer is over a checkbox and similar controls the shape changes from an arrow to a small, open box with short arrows from the upper left and lower right corners. This blocks viewing of the checkbox or spinner control. Is there a reason why the cursor changes? Rich

Re: [GRASS-user] Importing data in .atx/.gdb format [RESOLVED ... REALLY!]

2016-09-15 Thread Helmut Kudrnovsky
> In the ODOT2014 location I created an empty mapset called 'hwy_2015.gdb'. >Exited grass. Moved the contents of the downloaded source file (also called >'hwy_2015.gdb') into the new mapset. Then restarted grass. AFAIK it's not recommended to move/copy any foreign stuff not created by GRASS

Re: [GRASS-user] Importing data in .atx/.gdb format

2016-09-15 Thread Markus Metz
On Thu, Sep 15, 2016 at 8:34 PM, Rich Shepard wrote: > On Thu, 15 Sep 2016, Even Rouault wrote: > >> No need for that. The EPSG code (there are several ones in a WKT strig, >> but the main one, the one that applies to the top-level "node") is always >> at the end of the

Re: [GRASS-user] Importing data in .atx/.gdb format [RESOLVED ... REALLY!]

2016-09-15 Thread Rich Shepard
On Thu, 15 Sep 2016, Rich Shepard wrote: Ah, shoot! I thought I put the extension on the subdirectory name. Did so the first time but not when I moved it elsewhere. Renamed the subdirectory and, of course, that resolved the issue. Again, my apologies, Rich

Re: [GRASS-user] Importing data in .atx/.gdb format

2016-09-15 Thread Rich Shepard
On Thu, 15 Sep 2016, Even Rouault wrote: No need for that. The EPSG code (there are several ones in a WKT strig, but the main one, the one that applies to the top-level "node") is always at the end of the WKT string : [...] UNIT["foot",0.3048, AUTHORITY["EPSG","9002"]],

Re: [GRASS-user] Importing data in .atx/.gdb format [RESOLVED ... REALLY!]

2016-09-15 Thread Rich Shepard
On Thu, 15 Sep 2016, Even Rouault wrote: Same here: it doesn't end with .gdb Ah, shoot! I thought I put the extension on the subdirectory name. Did so the first time but not when I moved it elsewhere. Mea culpa! Rich ___ grass-user mailing

Re: [GRASS-user] Importing data in .atx/.gdb format [RESOLVED ... REALLY!]

2016-09-15 Thread Rich Shepard
On Thu, 15 Sep 2016, Helmut Kudrnovsky wrote: what do you mean by "let grass create a new mapset, moved the source files there"? Helmut, In the ODOT2014 location I created an empty mapset called 'hwy_2015.gdb'. Exited grass. Moved the contents of the downloaded source file (also called

Re: [GRASS-user] Importing data in .atx/.gdb format [RESOLVED ... REALLY!]

2016-09-15 Thread Even Rouault
Le jeudi 15 septembre 2016 20:22:01, Rich Shepard a écrit : > On Thu, 15 Sep 2016, Even Rouault wrote: > > What do you exactly mean by "fail" ? Does it report something like > > > > FAILURE: > > Unable to open datasource `foo.gdb' with the following drivers. > > > > -> PCIDSK > > -> netCDF > >

Re: [GRASS-user] Importing data in .atx/.gdb format [RESOLVED ... REALLY!]

2016-09-15 Thread Rich Shepard
On Thu, 15 Sep 2016, Even Rouault wrote: What do you exactly mean by "fail" ? Does it report something like FAILURE: Unable to open datasource `foo.gdb' with the following drivers. -> PCIDSK -> netCDF -> JP2KAK Even, Yep. ogrinfo reported it could not open the data source with any

Re: [GRASS-user] Importing data in .atx/.gdb format [RESOLVED ... REALLY!]

2016-09-15 Thread Helmut Kudrnovsky
>The location is the same as the previous map so I let grass >create a new mapset, moved the source files there, restarted grass, and was >told there was no layers selected. what do you mean by "let grass create a new mapset, moved the source files there"? moving the filegdb directory to a

Re: [GRASS-user] Importing data in .atx/.gdb format [RESOLVED ... REALLY!]

2016-09-15 Thread Even Rouault
>I just tried to import a different transportation map in OpenFileGDB > without success. The location is the same as the previous map so I let > grass create a new mapset, moved the source files there, restarted grass, > and was told there was no layers selected. That's because none were >

Re: [GRASS-user] Importing data in .atx/.gdb format [RESOLVED ... REALLY!]

2016-09-15 Thread Rich Shepard
On Thu, 15 Sep 2016, Even Rouault wrote: You can use ogrinfo -al -so (-so means Summary Only) to avoid listing the features and get only projection info, feature count and field definitions. Will save you a few gigabytes. I just tried to import a different transportation map in OpenFileGDB

Re: [GRASS-user] v.proj fails: no shift table [FIXED]

2016-09-15 Thread Rich Shepard
On Thu, 15 Sep 2016, Markus Neteler wrote: Seems we are back on track? Please update and let us know. Markus, Yes, we're back on the tracks. My project's location report: GRASS 7.3.svn ~/projects/oregon//data/features > g.proj -pt

[GRASS-user] DEM to DTM

2016-09-15 Thread José Anderson
Dear all, I'm in need to start a study in a urban area in which the DTM ( https://en.wikipedia.org/wiki/Digital_elevation_model) is to be obtained from a DEM (SRTM or ASTER). I've seen GRASS7 can provide DTM from LiDAR maps, but I'm afraid it won't work in this case. So, how to derive a DTM

Re: [GRASS-user] r.denoise inside python script

2016-09-15 Thread Vaclav Petras
Hi Carlos, On Tue, Sep 13, 2016 at 2:04 PM, Carlos Grohmann wrote: > I'm trying to run r.denoise from a python script but I'm getting some > errors (below). Apparently this is about using pipe to redirect outputs > (r.denoise is a bash script). > What you get in the

Re: [GRASS-user] v.proj fails: no shift table

2016-09-15 Thread Markus Neteler
On Thu, Sep 15, 2016 at 3:00 PM, Rich Shepard wrote: > On Thu, 15 Sep 2016, Markus Neteler wrote: > >> Martin fixed it just now in trunk (7.3.svn) in r69494. > > > Markus, > > I am always impressed and grateful to the responsiveness of OSS > developers. We are happy

Re: [GRASS-user] v.proj fails: no shift table

2016-09-15 Thread Rich Shepard
On Thu, 15 Sep 2016, Markus Neteler wrote: Martin fixed it just now in trunk (7.3.svn) in r69494. Markus, I am always impressed and grateful to the responsiveness of OSS developers. Thank you both, Rich ___ grass-user mailing list

Re: [GRASS-user] v.proj fails: no shift table

2016-09-15 Thread Rich Shepard
On Thu, 15 Sep 2016, Markus Neteler wrote: Sounds to me that you are using the trunk version of GRASS GIS? Markus, Yes, I did use 'trunk' and expected to hit a speed bump some time. So, I should have dropped back to 7.2svn before writing. For now, here a cmd line way for GRASS GIS 7.2:

Re: [GRASS-user] Importing data in .atx/.gdb format [RESOLVED ... REALLY!]

2016-09-15 Thread Rich Shepard
On Thu, 15 Sep 2016, Even Rouault wrote: I've just added support in the OGR FileGDB & OpenFileGDB drivers for '.' as a valid dataset name (the resolved directory of '.' must still end up with .gdb) Even, Thank you. For some of us ... me, at least ... using '.' to represent the pwd is

Re: [GRASS-user] v.proj fails: no shift table

2016-09-15 Thread Markus Neteler
Rich, Martin fixed it just now in trunk (7.3.svn) in r69494. Now it looks like this on my Fedora box: # (long line broken here on purpose) GRASS 7.3.svn (nc_spm_08_grass7):~ > g.proj -jft epsg=2992 datumtrans=6 +proj=lcc +lat_1=43 +lat_2=45.5 +lat_0=41.75 +lon_0=-120.5 +x_0=39.984

Re: [GRASS-user] Importing data in .atx/.gdb format [RESOLVED ... REALLY!]

2016-09-15 Thread Even Rouault
Le mercredi 14 septembre 2016 23:47:57, Rich Shepard a écrit : > On Wed, 14 Sep 2016, Helmut Kudrnovsky wrote: > > "." is this really your directory which holds the filegdb data? > > Helmut, > >Bash recognizes this as cwd (current working directory). However, ... I've just added support in

Re: [GRASS-user] v.proj fails: no shift table

2016-09-15 Thread Markus Neteler
On Thu, Sep 15, 2016 at 1:02 AM, Rich Shepard wrote: > The target location has these PROJ_INFO parameters defined in a Shapefile > *.prj: > > name: NAD_1983_HARN_StatePlane_Oregon_North_FIPS_3601_Feet_Intl > datum: nad83harn > ellps: grs80 > proj: lcc > lat_1:

Re: [GRASS-user] Importing data in .atx/.gdb format

2016-09-15 Thread Even Rouault
Le mercredi 14 septembre 2016 23:56:40, Helmut Kudrnovsky a écrit : > >PROJCS["NAD83 / Oregon Lambert (ft)", > > > >GEOGCS["NAD83", > > > >DATUM["North_American_Datum_1983", > > > > SPHEROID["GRS 1980", > > you have to find the correct EPSG code related to