[GRASS-user] v.net tools with polygons

[Daniel Victoria]

Hi Mark,

Thanks for your tips. The use of a regular lattice is very interesting. But
I won't need anything that fancy so v.net.iso will most likely fill my
needs. I'm particularly interested in what you said about capacity
limitations and transport costs. How would you go about modeling that?
Change the node costs?

Thanks
Daniel

On Wed, Mar 4, 2015 at 8:03 AM, Mark Wynter <mark at dimensionaledge.com>
wrote:

> 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
> >>>
> >>> *********
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20150304/9726e65c/attachment.html>