Re: [GRASS-user] v.net tools with polygons
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 m...@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 m...@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 mlenn...@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 * ___ grass-user mailing list
Re: [GRASS-user] v.net tools with polygons
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 m...@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 mlenn...@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 * ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.net tools with polygons
Hi Daniel The modeling approach I took used a combination of grass and postgis. I ran v.net.iso for every processing plant - or possible processing plant - and every farm centroid. At this point, I did not worry about capacity limitations of the plants - you can assume each is unconstrained. I then imported each v.net.iso output layer into a single results table in postgis, assigning the plant id as an additional field. Also in postgis I created a regular grid (hex grid specifically) and computed an average travel cost for each grid cell grouped by plant id. the reason for using a regular grid is that we can generate a cost value based on a consistent grid cell geometry, whereas v.net.iso breaks linestrings on the iso contours, and therefore line breaks vary for each v.net.iso output. To create a hybrid or least cost surface, you use a SQL min aggregate window function partitioned by grid cell id - from the grid table LEFT JOIN on results table. At this point, you can now start to consider the impact of capacity limitations, or you can add additional plant processing costs. I also do this in PostgreSQL/postgis because it's easy to consider new hybrid cost surfaces by adding additional non- transport costs and capacity limits, as well as a farm production value to the grid cells that contain the farm centroids.You can then use rank over() and case statements to assign grid cells to plants with the lowest cost up to the capacity limits of the plant. Agricultural production is generally seasonal, hence you can generate hybrid cost surfaces based on different crops, yields, output volumes etc without it affecting your unit travel costs. I find the economic modeling component easier in SQL than trying to do economic optimization in a GIS tool not designed for that. HTH Mark Sent from my iPhone On 4 Mar 2015, at 9:48 pm, Daniel Victoria daniel.victo...@gmail.com wrote: 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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.net tools with polygons
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 Thanks Daniel ___ 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] v.net tools with polygons
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 mlenn...@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 * ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.net tools with polygons
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 mlenn...@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 Thanks Daniel ___ 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] v.net tools with polygons
Hi list, I'm beginning to learn and use the 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? 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? Thanks Daniel ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
