Re: [GRASS-user] DEM to DTM

[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
values. It exists methods to approximate the bare earth, but neither easy
nor accurate. Furthermore, the methods described in the literature seems
more designed for global correction that might not lead to adequate results
for detailed study in urban environment.

I actually have the same problem as you and in search of solutions.

Regards,
Laurent

El sept. 15, 2016 10:00 AM, "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 DTM from LiDAR maps, but I'm afraid it won't
> work in this case.
>
> So, how to derive a DTM from DEM in GRASS 7?
>
> Any answer would be appreciated.
>
> Jose
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] DEM to DTM

[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 DTM from LiDAR maps, but I'm afraid it won't
work in this case.
>
> So, how to derive a DTM from DEM in GRASS 7?
>
> Any answer would be appreciated.
>
> Jose
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user

Hola!!

http://ssrebelious.blogspot.co.uk/2013/03/dsm-to-dem-conversion.html?m=1

Espero te funcione el link anterior

Saludos

Eddison
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[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 test it with wxPython Phoenix (the new version of wxPython).
>
>
> Anna,
>
>   I don't have time now to install Phoenix and try it with GRASS. If no one
> else does the testing I'll do so as soon as I can.

It's on my TODO list as well, but I am not sure when I will get to it,
so it would be great if you can test it.

Thank you

>
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[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 to install Phoenix and try it with GRASS. If no one
else does the testing I'll do so as soon as I can.

Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[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 of the checkbox
> or spinner control. Is there a reason why the cursor changes?

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


>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Comment on 7.3svn GUI

[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
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[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 itself into the GRASS structure _location/mapset_ (see (1) 2.
Background: GRASS GIS Location structure).

to avoid messing up, keep your GRASS data in their structure and data
provided by others separate in their own directories on your disk.

for v.in.ogr/v.external there is no need to copy/move this data in the
_location/mapset_ structure; it can be imported/linked from anywhere on your
system.

(1) https://grass.osgeo.org/grass73/manuals/helptext.html



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Importing-data-in-atx-gdb-format-tp5285623p5286185.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[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 WKT string :
>>
>> [...]
>>UNIT["foot",0.3048,
>>AUTHORITY["EPSG","9002"]],
>>AXIS["X",EAST],
>>AXIS["Y",NORTH],
>>AUTHORITY["EPSG","2992"]]  <- here it is !
>
>
>   How do I access that from the list of file names in the subdirectory?

You can not access the EPSG code of the CRS from any file, instead you
need to use ogrinfo -al as you did previously.

Markus M
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[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
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[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"]],
   AXIS["X",EAST],
   AXIS["Y",NORTH],
   AUTHORITY["EPSG","2992"]]  <- here it is !


  How do I access that from the list of file names in the subdirectory?

Thanks,

Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[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 list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[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
'hwy_2015.gdb') into the new mapset. Then restarted grass.

  This is what I did with the previous data source in .gdb format.

Rich


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[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
> >  -> JP2KAK
> 
> Even,
> 
>Yep. ogrinfo reported it could not open the data source with any driver.
> And the GUI displayed no file name when I tried importing it with v.in.ogr.
> 
> > (Side note: metadata.xml is not something required in a file geodatabase,
> > so this is completely ignored by the driver. Must be something specific
> > to your data provider. The projection info used by the driver is stored
> > in one of the "system" .gdb tables)
> 
>I recognize this but wanted to see if there was a different EPSG code in
> the metadata.
> 
> > Do you get error messages ? Otherwise adding "--debug on" (double dash
> > before debug) to the ogrinfo command line might give extra messages.
> > Otherwise you could share the dataset or a link to it, and could have a
> > look.
> 
>First try:
> 
> $ ogrinfo --debug on -al -so .
> OGR: OGROpen(.) failed.
> OGR: OGROpen(.) failed.
> FAILURE:
> Unable to open datasource .' with the following drivers.
>-> ESRI Shapefile
>-> MapInfo File

Hum, '.' will only work if you work with GDAL compiled from today sources. You 
need to specify a directory name ending with .gdb

> etc.
> 
>Second try:
> 
> $ ogrinfo --debug on -al -so ~/data/grassdata/ODOT2014/hwynet_2015/

Same here: it doesn't end with .gdb

> OGR: OGROpen(/home/rshepard/data/grassdata/ODOT2014/hwynet_2015/) failed.
> OGR: OGROpen(/home/rshepard/data/grassdata/ODOT2014/hwynet_2015/) failed.
> FAILURE:
> Unable to open datasource
> /home/rshepard/data/grassdata/ODOT2014/hwynet_2015/' with the following
> drivers.
>-> ESRI Shapefile
>-> MapInfo File
> etc.
> 
>Will make a .tar.xz file of the source (that's about the smallest
> result) and send it off the list.

Try first with a directory ending with .gdb

> 
> Thanks,
> 
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[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 driver.
And the GUI displayed no file name when I tried importing it with v.in.ogr.


(Side note: metadata.xml is not something required in a file geodatabase,
so this is completely ignored by the driver. Must be something specific to
your data provider. The projection info used by the driver is stored in
one of the "system" .gdb tables)


  I recognize this but wanted to see if there was a different EPSG code in
the metadata.


Do you get error messages ? Otherwise adding "--debug on" (double dash
before debug) to the ogrinfo command line might give extra messages.
Otherwise you could share the dataset or a link to it, and could have a
look.


  First try:

$ ogrinfo --debug on -al -so .
OGR: OGROpen(.) failed.
OGR: OGROpen(.) failed.
FAILURE:
Unable to open datasource .' with the following drivers.
  -> ESRI Shapefile
  -> MapInfo File
etc.

  Second try:

$ ogrinfo --debug on -al -so ~/data/grassdata/ODOT2014/hwynet_2015/
OGR: OGROpen(/home/rshepard/data/grassdata/ODOT2014/hwynet_2015/) failed.
OGR: OGROpen(/home/rshepard/data/grassdata/ODOT2014/hwynet_2015/) failed.
FAILURE:
Unable to open datasource
/home/rshepard/data/grassdata/ODOT2014/hwynet_2015/' with the following
drivers.
  -> ESRI Shapefile
  -> MapInfo File
etc.

  Will make a .tar.xz file of the source (that's about the smallest result)
and send it off the list.

Thanks,

Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[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 mapset directory? 
or just v.in.ogr input=your_filegdb_data within a separate mapset?



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Importing-data-in-atx-gdb-format-tp5285623p5286172.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[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
> displayed from the source .gdb directory.
> 
>From the command line 'ogrinfo -al -so' fails; 

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

or 

INFO: Open of `foo.gdb'
  using driver `OpenFileGDB' successful.

but no layer are reported ?

>it cannot open any file
> regardless of type. Yet, the directory contains the same file names as the
> previous transportation map: *.atx, *.gdb*. The metadata.xml file has no
> EPSG number listed so I used the same 2992/mod 6 as with the other map.
> 
(Side note: metadata.xml is not something required in a file geodatabase, so 
this is completely ignored by the driver. Must be something specific to your 
data provider. The projection info used by the driver is stored in one of the 
"system" .gdb tables)

>Can someone suggest a diagnostic procedure to identify what's different
> with this data set?

Do you get error messages ? Otherwise adding "--debug on" (double dash before 
debug) to the ogrinfo command line might give extra messages. Otherwise you 
could share the dataset or a link to it, and could have a look.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[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
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 displayed from
the source .gdb directory.

  From the command line 'ogrinfo -al -so' fails; it cannot open any file
regardless of type. Yet, the directory contains the same file names as the
previous transportation map: *.atx, *.gdb*. The metadata.xml file has no
EPSG number listed so I used the same 2992/mod 6 as with the other map.

  Can someone suggest a diagnostic procedure to identify what's different
with this data set?

TIA,

Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[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
-PROJ_INFO-
name   : NAD_1983_HARN_StatePlane_Oregon_North_FIPS_3601_Feet_Intl
datum  : nad83harn
ellps  : grs80
proj   : lcc
lat_1  : 44.34
lat_2  : 46
lat_0  : 43.66
lon_0  : -120.5
x_0: 250
y_0: 0
no_defs: defined
-PROJ_UNITS
unit   : Foot
units  : Feet
meters : 0.3048

  The OpenFileGDB roads location report:

GRASS 7.3.svn (ODOT2014):~/data/grassdata/ODOT2014 > g.proj -pt
-PROJ_INFO-
name   : NAD83 / Oregon Lambert (ft)
datum  : nad83
ellps  : grs80
proj   : lcc
lat_1  : 43
lat_2  : 45.5
lat_0  : 41.75
lon_0  : -120.5
x_0: 39.984
y_0: 0
no_defs: defined
-PROJ_EPSG-
epsg   : 2992
-PROJ_UNITS
unit   : foot
units  : feet
meters : 0.3048

  And v.proj run from the project location has no complaints about
transforming projection data from the source location.

  The state is supposed to have a single projection so it's interesting to
learn that map sets from two different state agencies have slightly
different parameters.

  I don't mind testing in the corners of the development (trunk) branch.

Thanks to Even, Martin, and you for taking the time to patch things,

Rich

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] DEM to DTM

[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 from DEM in GRASS 7?

Any answer would be appreciated.

Jose
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[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 command line (without involving Python)? How did you
install r.denoise? Which version of GRASS GIS?


>
> any ideas to work around this situation?
>

Provide full path to the module instead of the name or modify your PATH
variable so that r.denoise is found? (Also check shebang and executable
permissions.)

The solution might be 1) rewrite r.denoise to Python and GRASS GIS 7, so it
can go into addons, or 2) take mdenoise code which is GPL >2 and port it to
GRASS.

Vaclav
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[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 to help! And at the end of the day you triggered several
improvements :-)

It is good that you don't give up here easily but try get things
solved. Overall, a win-win for all of us.

Best,
Markus

PS: Still, if you can, please test this fix in trunk since we plan to
backport the improved PROJ4 support mechanism at some point.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[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
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[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:


  Good information. I'll use 7.2svn now rather than 7.3svn. I'm sure this
will save me a lot of time and allow me to not clutter the list with
avoidable questions.

Thanks very much,

Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[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 automatic.


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.


  Now this is really good to know. Of course I then lose the coffee break
wating for the output. :-)

Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[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 +y_0=0 +no_defs +a=6378137 +rf=298.257222101
+nadgrids=/usr/share/proj/WO +to_meter=0.3048


GRASS 7.3.svn (nc_spm_08_grass7):~ > g.proj -pt epsg=2992 datumtrans=6
-PROJ_INFO-
name   : NAD83 / Oregon Lambert (ft)
datum  : nad83
ellps  : grs80
proj   : lcc
lat_1  : 43
lat_2  : 45.5
lat_0  : 41.75
lon_0  : -120.5
x_0: 39.984
y_0: 0
no_defs: defined
nadgrids   : WO
-PROJ_EPSG-
epsg   : 2992
-PROJ_UNITS
unit   : foot
units  : feet
meters : 0.3048

Seems we are back on track? Please update and let us know.

Markus
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[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 the OGR FileGDB & OpenFileGDB drivers for '.' as a 
valid dataset name (the resolved directory of '.' must still end up with .gdb)

> 
>Here's a summary of what I did so that others can gain from my learning
> and import a OFGDB data file on the first try.
> 
>0.  Run ogrinfo -al on the source directory and direct output to a text
> file. In my case it produced a 2.4G output file. Read from the top (less
> output.txt | less) the projection information, including the EPSG
> projection code.

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.

> 
>1.  With the data source in a temporary directory I started grass73 and
> created a new location: ODOT2014.gdb using the proper EPSG projection code
> (and sub-variety number) and a new mapset, data_source.gdb. Exited grass
> 
>2.  Copied (could have moved) all data files from their temporary
> directory to ~/data/grassdata/ODOT2014.gdb/data_source.gdb. Restarted
> grass.
> 
>3.  Using the GUI: File -> Import vector (v.in.ogr). Select source as
> Directory, format as OpenFileGDB, point to
> ~/data/grassdata/ODOT2014.gdb/data_source.gdb, and click the "Import"
> button.
> 
>4.  Make a pot of coffee. Return to computer and see all the roads
> (highways, roads, streets) in the state displayed in the Map Display
> window.
> 
> Many thanks again to everyone for your patience and helpful responses,
> 
> Rich
> 
> 
> 
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[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: 44.34
> lat_2: 46
> lat_0: 43.66
> lon_0: -120.5
> x_0: 250
> y_0: 0
> no_defs: defined
>
>
> The source location has these PROJ_INFO parameters defined in the
> metadata.xml with EPSG 2992:
>
> name: NAD83 / Oregon Lambert (ft)
> datum: nad83
> ellps: grs80
> proj: lcc
> lat_1: 43
> lat_2: 45.5
> lat_0: 41.75
> lon_0: -120.5
> x_0: 39.984
> y_0: 0
> no_defs: defined
> nadgrids: WO
>
>   When I imported this OFGDB source and selected epsg 2992 a window with 6
> flavors appeared. I selected #6: Washington/Oregon HARM adjustment.

yes, it would apply
nadgrids=WO

according to the list in the location manager selection window (I just
tried here with EPSG 2992).

> Apparently this was not used.

I checked:
- in GRASS GIS 7.2 is is used, should be ok:

g.proj -p

-PROJ_INFO-
name   : NAD83 / Oregon Lambert (ft)
datum  : nad83
ellps  : grs80
proj   : lcc
lat_1  : 43
lat_2  : 45.5
lat_0  : 41.75
lon_0  : -120.5
x_0: 39.984
y_0: 0
no_defs: defined
nadgrids   : WO
-PROJ_EPSG-
epsg   : 2992
-PROJ_UNITS
unit   : foot
units  : feet
meters : 0.3048

Question: do you use 7.2.svn?

- in trunk ("7.3") it is not used due to NAD file removal during the recent
code sprint upon long discussions with the GDAL maintainer Even Rouault (
https://trac.osgeo.org/grass/changeset/69211). Here it should use the
respective file through GDAL/PROJ4 since we don't want to keep our private
copies any longer.


>   From the target location/mapset I tried v.proj
> location=ODOT2014mapset=data_source.gdb input=state_roads_2014 (I renamed
> the long original name to this with g.rename.) and was told there
> was no projection conversion table available.

Sounds to me that you are using the trunk version of GRASS GIS?

>   Should I re-import the data and try to ensure that the HARM adjustment
is
> accepted, or is there a way of reprojecting the source to match the
target?

In the first place I would use GRASS GIS 7.2.svn since the NAD management
stuff in trunk is currently experimental.
It is a fairly complex beast. The idea is that GRASS no longer bothers
about NAD and just receives related info from GDAL/PROJ4. Seems not to be
complete yet (I'll update https://trac.osgeo.org/grass/ticket/2456
accordingly).

For now, here a cmd line way for GRASS GIS 7.2:

# create dummy location just in order to fetch the list
# of available datums for given EPSG code:
grass72 -c epsg:2992 ~/grassdata/dummy --exec g.proj -t epsg=2992
datumtrans=-1
Cleaning up temporary files...
Creating new GRASS GIS location/mapset...
Executing  ...
---
1
Used in whole nad83 region
towgs84=0.000,0.000,0.000
Default 3-Parameter Transformation (May not be optimum for older datums;
use this only if no more appropriate options are available.)
---
2
Used in Florida
nadgrids=FL
Transforms 'Old NAD83' to 'HPGN NAD83'
---
3
Used in Maryland
nadgrids=MD
Transforms 'Old NAD83' to 'HPGN NAD83'
---
4
Used in Tennessee
nadgrids=TN
Transforms 'Old NAD83' to 'HPGN NAD83'
---
5
Used in Wisconsin
nadgrids=WI
Transforms 'Old NAD83' to 'HPGN NAD83'
---
6
Used in Washington - Oregon
nadgrids=WO
Transforms 'Old NAD83' to 'HPGN NAD83'
Execution of  finished.
Cleaning up temporary files...


# now generate location using EPSG code and related datumtransform #6:
grass72 -c epsg:2992 ~/grassdata/oregon2992_nad83_WO --exec g.proj -t
epsg=2992 datumtrans=6 -p
Cleaning up temporary files...
Creating new GRASS GIS location/mapset...
Executing  ...
-PROJ_INFO-
name   : NAD83 / Oregon Lambert (ft)
datum  : nad83
ellps  : grs80
proj   : lcc
lat_1  : 43
lat_2  : 45.5
lat_0  : 41.75
lon_0  : -120.5
x_0: 39.984
y_0: 0
no_defs: defined
nadgrids   : WO
-PROJ_EPSG-
epsg   : 2992
-PROJ_UNITS
unit   : foot
units  : feet
meters : 0.3048
Execution of  finished.
Cleaning up temporary files...

# eventually start using the new location
grass72 ~/grassdata/oregon2992_nad83_WO/PERMANENT/


But! When entering this location and running
g.proj -p
still nadgrids is not listed any more... confusing.
Anyone with more insights here?

Markus
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

[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 this infomations.
> 
> the simpliest task is to ask your data provider for the correct EPSG code
> of their data.

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"]],
AXIS["X",EAST],
AXIS["Y",NORTH],
AUTHORITY["EPSG","2992"]]  <- here it is !

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user