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 <[email protected]> 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
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-user

Reply via email to