[GRASS-user] v.net tools with polygons

[Mark Wynter]

Just recalling the v.net techniques I used on a mining project a year ago where we had to optimize the infrastructure build and operational logistics for over 2000 drill sites, feeding several downstream processing plants.

V.net.distance in reverse will do what you need if each trip is being made independently (farmers act as individual agents and cart their own goods to the processing plant).

If a transport haulage firm calls on multiple farms as part of the same trip, then traveling sales person might be relevant to your needs.

Situations may also arise where you need to use v.net.spanningtree or Steiner.  For example, if you need to build roads or pipelines connecting various facilities, or supply aggregation points, then this problem needs to be solved, before you apply v.net.distance, or v.net.iso which assume the network infrastructure is already built. 

If the network infrastructure is already built, and the agents act independently with no supply chain aggregation, then V.net.iso is an alternative to v.net.distance if all you need is the travel cost contours radiating out from the processing plants and not the route paths themselves. if you have numerous processing plants, you can run v.net.iso for each plant. Then you combine cost surfaces by taking the plant with the least cost value, giving you a minimum cost surface. 

With v.net.iso, your decision model doesn't  always have to assume the farmer will choose the plant with the lowest transport cost. It pays to keep each v.net.iso cost surface, because sometimes plants have capacity limitations - in which case agents may choose to incur a higher transport cost and still be profit maximizing.  the v.net.iso approach allows you to consider the economics of lots of different processing plant and network configuration scenarios without having to always re-run v.net.distance every time.

Sorry if this sounds overwhelming - but v.net should give you all the tools you need. It's a case of knowing what tool for what job.  My advice is to be really clear on your modeling assumptions that underlie each method.

Sing out if you want to test your methodology on me. Just email me..

- mark 

Sent from my iPhone

> On 4 Mar 2015, at 7:48 am, Mark Wynter <mark at dimensionaledge.com> wrote:
> 
> Hi Daniel, 
> 
> I've done something similar - I call it "off road routing", and uses a regular lattice of nodes and arcs. You can then constrain the off road "network" by closing arcs that cross major watercourses, fence lines or where the terrain or vegetation is non navigatable. For farms, I added paddock boundaries as rings, as well as gate nodes that constrain movement between paddocks. In essence you build a network topology that reflects the off-road aspect of your network.  Relevant to mining as well as agriculture.
> 
> 
>> 
>> Ok Moritz,
>> 
>> Thanks for the tips. I'll try to go the centroids way
>> 
>> Cheers
>> Daniel
>> 
>> On Tue, Mar 3, 2015 at 5:35 AM, Moritz Lennert <mlennert at club.worldonline.be
>>> wrote:
>> 
>>>> On 02/03/15 21:39, Daniel Victoria wrote:
>>>> 
>>>> Hi list,
>>>> 
>>>> I'm beginning to learn and use the v.net <http://v.net> tools in Grass
>>>> in order to evaluate the distance from several crop fields to a
>>>> processing plant.
>>>> 
>>>> I've successfully build the road network with the end nodes but now I'm
>>>> in doubt. My starting points in the analysis are crop fields, which are
>>>> polygons. So what is the best (or most common) practice?
>>>> 
>>>> 1) Use the field centroids as starting nodes?
>>>> 2) Add field polygon boundaries to the network and run v.net.distance
>>>> backwards (from mill to fields)?
>>>> 3) Some other option?
>>> 
>>> 
>>> I don't think that there is a best practice for this. It all depends on
>>> your application and the desired outcome. Do you want average time/distance
>>> from anywhere in the field to the plant ? Then probably the centroid is ok.
>>> Or do you want distance from the point of the field that is closest to the
>>> network ? Then you could get the coordinates of that point through
>>> v.distance (with upload=to_x,to_y) and use these points as nodes.
>>> 
>>> 
>>> 
>>> Also, if I'm to add the field boundaries to the network, how would I go
>>>> about it? Should I first v.patch the field with the roads layer and then
>>>> run v.net <http://v.net>?
>>> 
>>> Adding field boundaries still does not answer the question of where to put
>>> the start/stop point of your paths...
>>> 
>>> If you want to add them to the network then yes, patching would be the
>>> best option, AFAIK.
>>> 
>>> Moritz
>>> 
>>> *********