Re: [GRASS-user] Datum not recognized by Grass

2019-12-10 Thread Markus Metz
Within GRASS:

g.proj epsg=2932 -p
-PROJ_INFO-
name   : QND95 / Qatar National Grid
ellps  : international
proj   : tmerc
lat_0  : 24.45
lon_0  : 51.21667
k  : 0.9
x_0: 20
y_0: 30
towgs84:
-119.4248,-303.65872,-11.00061,1.164298,0.174458,1.096259,3.657065
no_defs: defined
-PROJ_EPSG-
epsg   : 2932
-PROJ_UNITS
unit   : meter
units  : meters
meters : 1

looks fine.

Outside GRASS, using projinfo from PROJ 6.2.1:
projinfo -o PROJ -s EPSG:2932 -t EPSG:4326
Candidate operations found: 1
-
Operation n°1:

unknown id, Inverse of Qatar National Grid + QND95 to WGS 84 (1), 0 m,
Qatar - onshore

PROJ string:
+proj=pipeline
+step +inv +proj=tmerc +lat_0=24.45 +lon_0=51.21667 +k=0.9
+x_0=20 +y_0=30 +ellps=intl
+step +proj=push +v_3 +step +proj=cart +ellps=intl
+step +proj=helmert +x=-119.4248 +y=-303.65872 +z=-11.00061 +rx=1.164298
+ry=0.174458 +rz=1.096259 +s=3.657065 +convention=position_vector
+step +inv +proj=cart +ellps=WGS84 +step +proj=pop +v_3
+step +proj=unitconvert +xy_in=rad +xy_out=deg +step
+proj=axisswap +order=2,1

Datum transformation happens with +proj=helmert which is the same as the
towgs84 parameters in GRASS. This does not matter, GRASS does not use these
parameters for reprojection, it relies on PROJ to select an appropriate
datum transformation depending on the source and target CRS.

Markus M

On Mon, Dec 9, 2019 at 10:15 PM Markus Metz 
wrote:

>
>
> On Wed, Dec 4, 2019 at 12:23 PM Zoltan Szecsei 
> wrote:
> >
> > Hi Helmut,
> > Thanks for your comments.
> >
> > I installed everything with OSGeo4W64, and QGIS get the EPSG:2932 but
> > Grass not.
> >
> > Perhaps I have a PATH or some other setting problem?
> > Perhaps let me know what search paths Grass uses for proj4, and what
> > proj files and locations I should scan for.
>
> In this case where the EPSG code is known, there is no need to do anything
> but to ignore the warning. GRASS will use the EPSG code if available and
> passes it to PROJ when it comes to reprojection.
>
> Markus M
>
> >
> > Regards,
> > Zoltan
> >
> > On 2019/12/04 01:30, Helmut Kudrnovsky wrote:
> > >> ignore the warning and use GRASS with PROJ6, granted that authority
> name
> > > (e.g. EPSG) and authority code (e.g. 2932) are known for both CRS's in
> case
> > > of reprojection
> > >
> > > this issue is already by GRASS with PROJ6, see
> > >
> > > 
> > > GRASS version: 7.8.1
> > > Code revision: c865432c9
> > > Build date: 2019-11-10
> > > Build platform: x86_64-w64-mingw32
> > > GDAL: 3.0.2
> > > PROJ: 6.2.1  <=
> > > GEOS: 3.8.0
> > > SQLite: 3.29.0
> > > Python: 3.7.0
> > > wxPython: 4.0.7
> > > Platform: Windows-10-10.0.18362-SP0 (OSGeo4W)
> > > 
> > >
> > > and the output from the underlying PROJ: 6.2.1
> > >
> > > 
> > > C:\>projinfo EPSG:2932 -o PROJ,WKT2_2018
> > > PROJ.4 string:
> > > +proj=tmerc +lat_0=24.45 +lon_0=51.21667 +k=0.9 +x_0=20
> > > +y_0=30 +ellps=intl
> > >
> +towgs84=-119.4248,-303.65872,-11.00061,1.164298,0.174458,1.096259,3.657065
> > > +units=m +no_defs +type=crs
> > >
> > > WKT2_2018 string:
> > > PROJCRS["QND95 / Qatar National Grid",
> > >  BASEGEOGCRS["QND95",
> > >  DATUM["Qatar National Datum 1995",
> > >  ELLIPSOID["International 1924",6378388,297,
> > >  LENGTHUNIT["metre",1]]],
> > >  PRIMEM["Greenwich",0,
> > >  ANGLEUNIT["degree",0.0174532925199433]],
> > >  ID["EPSG",4614]],
> > >  CONVERSION["Qatar National Grid",
> > >  METHOD["Transverse Mercator",
> > >  ID["EPSG",9807]],
> > >  PARAMETER["Latitude of natural origin",24.45,
> > >  ANGLEUNIT["degree",0.0174532925199433],
> > >  ID["EPSG",8801]],
> > >  PARAMETER["Longitude of natural origin",51.21667,
> > >  ANGLEUNIT["degree",0.0174532925199433],
> > >  ID["EPSG",8802]],
> > >  PARAMETER["Scale factor at natural origin",0.9,
> > >  SCALEUNIT["unity",1],
> > >  ID["EPSG",8805]],
> > >  PARAMETER["False easting",20,
> > >  LENGTHUNIT["metre",1],
> > >  ID["EPSG",8806]],
> > >  PARAMETER["False northing",30,
> > >  LENGTHUNIT["metre",1],
> > >  ID["EPSG",8807]]],
> > >  CS[Cartesian,2],
> > >  AXIS["(E)",east,
> > >  ORDER[1],
> > >  LENGTHUNIT["metre",1]],
> > >  AXIS["(N)",north,
> > >  ORDER[2],
> > >  LENGTHUNIT["metre",1]],
> > >  USAGE[
> > >  SCOPE["unknown"],
> > >  AREA["Qatar - onshore"],
> > >  BBOX[24.55,50.69,26.2,51.68]],
> > >  

Re: [GRASS-user] compute path with a maximum slope

2019-12-10 Thread Stefan Blumentrath
Hi,

you can either try r.walk (https://grass.osgeo.org/grass78/manuals/r.walk.html) 
and modify variable according to Your threshold or you set slope values above 
your maximum to NULL (e.g. r.mapcalc 
expression="slope_below_max=if(slope>37.5,null(),slope)") and then use r.cost 
(https://grass.osgeo.org/grass78/manuals/r.cost.html, NULL ("NoData") are not 
traversed by the algorithm).

Cheers,
Stefan
GRASS GIS manual: r.walk
DESCRIPTION r.walk computes anisotropic cumulative cost of moving between 
different geographic locations on an input elevation raster map whose cell 
category values represent elevation combined with an input raster map layer 
whose cell values represent friction cost.. r.walk outputs 1) a raster map 
showing the lowest cumulative cost (time) of moving between each cell and the 
user-specified ...
grass.osgeo.org


Fra: grass-user  på vegne av 
li...@lazygranch.com 
Sendt: tirsdag 10. desember 2019 10:34
Til: grass-user@lists.osgeo.org 
Emne: [GRASS-user] compute path with a maximum slope

I have a DEM in grass using a proj that is in UTM. Viewshed, slope, etc
work fine. What I want to do is have grass compute a path between two
points such that the slope doesn't exceed a maximum value. I don't care
about the path length.

I suspect there is some guide on the internet for this problem, but
just can't compose the right question for a search engine. A link would
be appreciated. If not, some basic guidance would be helpful.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] compute path with a maximum slope

2019-12-10 Thread Ken Mankoff
r.cost generates paths. Set high cost to traverse cells with high slopes?

  -k.

Please excuse brevity. Sent from tiny pocket computer with non-haptic
feedback keyboard.

On Tue, Dec 10, 2019, 10:41 li...@lazygranch.com 
wrote:

> I have a DEM in grass using a proj that is in UTM. Viewshed, slope, etc
> work fine. What I want to do is have grass compute a path between two
> points such that the slope doesn't exceed a maximum value. I don't care
> about the path length.
>
> I suspect there is some guide on the internet for this problem, but
> just can't compose the right question for a search engine. A link would
> be appreciated. If not, some basic guidance would be helpful.
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] compute path with a maximum slope

2019-12-10 Thread li...@lazygranch.com
I have a DEM in grass using a proj that is in UTM. Viewshed, slope, etc
work fine. What I want to do is have grass compute a path between two
points such that the slope doesn't exceed a maximum value. I don't care
about the path length. 

I suspect there is some guide on the internet for this problem, but
just can't compose the right question for a search engine. A link would
be appreciated. If not, some basic guidance would be helpful.  
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user