Re: [GRASS-user] r.lake: understanding variable 'water_level'

2016-10-06 Thread Rich Shepard

On Thu, 6 Oct 2016, Anna Petrášová wrote:


I am not exactly sure what are you asking, but water_level is the absolute
level of the water, not relative height above the elevation of the seed.
If you want to use the relative height, user r.what to query the elevation
of the seed and add it to your relative height.


Anna,

  That's exactly the insight I need and did not get from reading the manual
page. Thanks very much.

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

Re: [GRASS-user] r.lake: understanding variable 'water_level'

2016-10-06 Thread Anna Petrášová
On Thu, Oct 6, 2016 at 6:59 PM, Rich Shepard  wrote:
>   The elevation map (be_metric) has minimum and maximum elevations of 45.17
> and 51.32 m. This command:
>
> r.lake elev=be_metric water=50 lake=pop coord=2295821.12321,175257.829078
> --overwrite
>
> produces the output map with this commentary:
>
> Lake depth from 0.00 to 4.833561 (specified water level is taken as
> zero)
> Lake area 357082.807803 square meters
> Lake volume 409786.922884 cubic meters
> Volume is correct only if lake depth (terrain raster map) is in meters
>
>   My interest is in a specific, much smaller area. However, when I re-run
> the command with much smaller water_level values there is no output:
>
> r.lake elev=be_metric water=0.01 lake=pop coord=2295821.12321,175257.829078
> --overwrite
>  100%
> ERROR: Given water level at seed point is below earth surface. Increase
>water level or move seed point.
>
> r.lake elev=be_metric water=0.1 lake=pop coord=2295821.12321,175257.829078
> --overwrite
>  100%
> ERROR: Given water level at seed point is below earth surface. Increase
>water level or move seed point.
>
>   If the entire 36 sq. km. is covered with water when water_level is set to
> 50 (just below maximum elevation), yet input values of 0.01 and 0.01 are
> underground, how do I specify small elevations above that of the 'dam' which
> is at an elevation of approximately 48.25m?

I am not exactly sure what are you asking, but water_level is the
absolute level of the water, not relative height above the elevation
of the seed. If you want to use the relative height, user r.what to
query the elevation of the seed and add it to your relative height.

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

Re: [GRASS-user] r.contour: levels vs step

2016-10-06 Thread Rich Shepard

On Thu, 6 Oct 2016, Stuart Edwards wrote:


yes . not always as pretty as you would like but gets the job done


  Always willing to accomodate when I can. :-)

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

[GRASS-user] r.lake: understanding variable 'water_level'

2016-10-06 Thread Rich Shepard

  The elevation map (be_metric) has minimum and maximum elevations of 45.17
and 51.32 m. This command:

r.lake elev=be_metric water=50 lake=pop coord=2295821.12321,175257.829078
--overwrite

produces the output map with this commentary:

Lake depth from 0.00 to 4.833561 (specified water level is taken as
zero)
Lake area 357082.807803 square meters
Lake volume 409786.922884 cubic meters
Volume is correct only if lake depth (terrain raster map) is in meters

  My interest is in a specific, much smaller area. However, when I re-run
the command with much smaller water_level values there is no output:

r.lake elev=be_metric water=0.01 lake=pop coord=2295821.12321,175257.829078
--overwrite
 100%
ERROR: Given water level at seed point is below earth surface. Increase
   water level or move seed point.

r.lake elev=be_metric water=0.1 lake=pop coord=2295821.12321,175257.829078
--overwrite
 100%
ERROR: Given water level at seed point is below earth surface. Increase
   water level or move seed point.

  If the entire 36 sq. km. is covered with water when water_level is set to
50 (just below maximum elevation), yet input values of 0.01 and 0.01 are
underground, how do I specify small elevations above that of the 'dam' which
is at an elevation of approximately 48.25m?

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

Re: [GRASS-user] DEM re-projection: change elevation units

2016-10-06 Thread Rich Shepard

On Thu, 6 Oct 2016, Stuart Edwards wrote:


probably something along the lines (in mapcalc) :
dem_m = dem_ft * 1200/3937
where dem_m is the map you want and dem_ft is the dem with the elevations in ft.


Stu,

  That's another approach. What I did is
r.mapcalc 'be_metric = be_cropped * 0.3048'

Thanks,

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

Re: [GRASS-user] DEM re-projection: change elevation units [RESOLVED]

2016-10-06 Thread Rich Shepard

On Thu, 6 Oct 2016, Rich Shepard wrote:


 Is there a script that runs r.mapcalc on all cells and converts each
elevation from feet to meters? Or, is there a different approach.


  Got it. Haven't used r.mapcalc in years so I re-read the entire page and
learned how to do the job.

Thanks, Helmut and Johannes,

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

Re: [GRASS-user] DEM re-projection: change elevation units

2016-10-06 Thread Helmut Kudrnovsky
Rich Shepard wrote
> The source DEM has projection units in feet and both geographic
> coordinates and elevations are in those units. Re-projecting these data to
> the metric equivalent transforms the x, y coordinates from feet to meters
> but leaves the elevations in feet.
> 
>Is there a script that runs r.mapcalc on all cells and converts each
> elevation from feet to meters? Or, is there a different approach.
> 
>I need the same units for x, y, and z values.
> 
> TIA,
> 
> Rich
> 
> ___
> grass-user mailing list

> grass-user@.osgeo

> http://lists.osgeo.org/mailman/listinfo/grass-user

international feet (0.3048 meters = 1 foot) or survey feet (1200 / 3937
meters = 1 foot).

?



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/DEM-re-projection-change-elevation-units-tp5289666p5289675.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] v.net.alloc having difficulty with specific dataset

2016-10-06 Thread Markus Metz
On Wed, Oct 5, 2016 at 3:05 AM, Sam Snellings  wrote:
> Markus,
>
> Thank you for the suggestions. I ran the following commands nine times on
> the data, with thresholds .0001, 0.01, 0.001,
> 0.1, 0.01, 0.1, 1, 10, and 100. Let me know if I'm not going small
> enough.
>
> v.clean --overwrite input=roads output=roads_snap -c tool=snap thresh=[see
> above]
> v.net --overwrite input=roads_snap points=schools output=network
> operation=connect thresh=1000
> v.net.alloc --overwrite input=network output=network_allocation ccats=1-2
>
> I did not get a complete allocation of road segments from any of them, and
> as far as I can tell it got stuck at the same vertices on each run.
>
> I will email you a link to the data off-list, thanks for taking a look.

thanks for providing a link to the data! The problem is that the roads
are 3D with z coordinates not matching at the end of a road segment
and the beginning of another road segment. The solution is to import
roads as a 2D vector with v.in.ogr -2. 2D snapping with v.clean
tool=snap thresh =1 might be helpful.

Markus M

>
> -Sam
>
> On Tue, Oct 4, 2016 at 3:53 PM, Markus Metz 
> wrote:
>>
>> On Tue, Oct 4, 2016 at 5:09 PM, Sam Snellings 
>> wrote:
>> > I've been running some trials through v.net.alloc using town road
>> > networks
>> > as the arc layer and schools as the node layer. I have one set of
>> > roads/schools that breezes through v.net.alloc without issue (Town 1),
>> > while
>> > another one only allocates the first few arcs connected to each school
>> > and
>> > leaves the rest of the network unallocated (Town 2). There is probably a
>> > problem with the data from Town 2, but I can't figure out what it is.
>> > Does
>> > this issue sound familiar to anyone?
>> >
>> > I am using the GUI. I load each pair of shapefiles into GRASS and then
>> > run
>> > the following statements (I only import two school points to simplify).
>> > The
>> > two towns are pulled right from the state-wide GIS office, but the towns
>> > are
>> > in different states (ie - different agencies provide the data).
>> >
>> You do not need this for v.net.alloc:
>> > v.net input=roads output=road_nodes operation=nodes
>> it will create a point for every node, the first point will have
>> cat=1, the second cat=2 which collides with the points you want to
>> attach
>>
>> > v.net input=road_nodes points=schools output=network operation=connect
>> > thresh=1000
>>
>> rather use
>> v.net input=roads points=schools output=network operation=connect
>> thresh=1000
>>
>> > v.net.alloc input=network output=network_allocation ccats=1-2
>>
>> the real problem is probably a data problem: roads are not properly
>> connected, i.e. the end of one road does not match the beginning of
>> another road. Try v.clean input=roads output=roads_snap -c tool=snap
>> with a very small threshold. This kind of error is quite common with
>> shapefiles (not a fault of the shapefile format but of the software
>> used to create the shapefiles).
>>
>> >
>> > Thanks in advance for any advice, I can also email images/data if that
>> > would
>> > be helpful.
>>
>> If v.clean -c tool=snap does not help, (links to) original data of the
>> schools and road network for Town 2 would be helpful (data please only
>> off-list).
>>
>> Markus M
>
>
>
> ___
> 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] DEM re-projection: change elevation units

2016-10-06 Thread Rich Shepard

  The source DEM has projection units in feet and both geographic
coordinates and elevations are in those units. Re-projecting these data to
the metric equivalent transforms the x, y coordinates from feet to meters
but leaves the elevations in feet.

  Is there a script that runs r.mapcalc on all cells and converts each
elevation from feet to meters? Or, is there a different approach.

  I need the same units for x, y, and z values.

TIA,

Rich

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

Re: [GRASS-user] r.contour: levels vs step

2016-10-06 Thread Rich Shepard

On Thu, 6 Oct 2016, Markus Neteler wrote:


Please consider to write a small text snippet to be added to the manual
page explaining the levels in an example (based in the North Carolina
sample dataset).


Markus,

  OK. I'll do this.

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

Re: [GRASS-user] r.contour: levels vs step

2016-10-06 Thread Markus Neteler
On Thu, Oct 6, 2016 at 7:38 PM, Rich Shepard  wrote:
> On Thu, 6 Oct 2016, Stuart Edwards wrote:
>
>> Step will create all the contours in the dem at the 'step' interval (e.g.
>> 2 ft will produce 20,22,24,26 etc) Levels will create them just where you
>> specify e.g. 45, 50, 55, 60, 70, 80 etc.
>
>
> Stu,
>
>   That's what I thought. So for the same intervals there's no difference
> between the two.

Please consider to write a small text snippet to be added to the
manual page explaining the levels in an example (based in the North
Carolina sample dataset).

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

Re: [GRASS-user] r.contour: levels vs step

2016-10-06 Thread Rich Shepard

On Thu, 6 Oct 2016, Stuart Edwards wrote:


Step will create all the contours in the dem at the 'step' interval (e.g.
2 ft will produce 20,22,24,26 etc) Levels will create them just where you
specify e.g. 45, 50, 55, 60, 70, 80 etc.


Stu,

  That's what I thought. So for the same intervals there's no difference
between the two.

Thanks,

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

[GRASS-user] r.contour: levels vs step

2016-10-06 Thread Rich Shepard

  The r.contour manual page has no example using levels rather than step.
Under what circumstances would levels be preferred to step? Do they produce
equivalent outputs?

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

Re: [GRASS-user] grass-user Digest, Vol 126, Issue 13

2016-10-06 Thread Rich Shepard

On Wed, 5 Oct 2016, alassane toure wrote:


What is the best way to uninstall the newer gdal 2.1.0 version to install
an old gdal version that worked with my code? I installed the newer version
by compilation as opposed to a binary install...may be that might help.


Alassane,

  Since you did not install it using your distribution's package management
tools you'll need to do this by hand. This work flow will do the job, but it
takes time:

  1. Uninstall your distribution's gdal. This leaves only the 2.2.x version.

  2. From the root directory (/), as root (or sudo) run
find . -name gdal
This will find all files with 'gdal' in their name.

  3. Again as the superuser, cd to each directory and remove that gdal file.

  4. Re-install the distribution's gdal-2.1.x.

HTH,

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

[GRASS-user] Auto-detection of GCP for rectifying image

2016-10-06 Thread Johannes Radinger
Hi GRASS users!

I have an image of a small object (e.g. photograph of blue square 15x5cm)
which I want to automatically georeference. In addition, the image contains
6 points where I know the exact coordinates, i.e. these points can be use
as ground control points (GCP) for rectifying the image. This is basically
a experimental setup, and I could use different colors or shapes for the
GCP; the image itself will then be rather a photograph of a fish on a white
background than a blue square; I just want to test with a simpler setup
before.

However, as I want to automatize the step of rectifying/georeferencing I am
looking for a way to autodetect these six points in the image. I am
thinking of tools like pattern/face recognition that are able to autodetect
objects (e.g. eyes, points etc.) and extract their position (coordinates)
within that image. I assume these coordinates together with their "true"
position could then be used for rectifying the picture using e.g. i.rectify.

Has anyone done this or a similar exercise before and can recommend tools
and approaches to auto-detect GCP from an image?

Any hints are welcome!

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