Transportation Services

[qjhart]

The current transportation stub passes destination as a [longituge,latitude] pair, and an array of sources as [[lon,lat],[lon,lat]. The response is geojson, as an (array?) for linestring geojson features including a distance as a property.

I suggest the transportation function passes in a src geojson object, a destination geojson object, and a set of json options. The results is a geojson featureCollection of the transportation network used, including the paths traveled on it, and a separate geojson featureCollection of the paths traveled. This could also be a single FeatureCollection with feature types differentiated by there use. Features should include an identifier.

A source and destination can also be a geometry collection, in which case identifiers are calculated for the points and destinations. The IDs are MD5 calculations of the geometries. Features without id's are considered to be simple geometries, and their ID's calculated the same way.

The service takes the centroid of all sources and destinations, so the client should think about doing that before sending.

Input:

{
"destination": {
    "type": "FeatureCollection",
    "features": [
        {
            "type": "Feature",
            "geometry": {
                "type": "Point",
                "coordinates": [-123,46.72]
            },
            "properties": {
                "id":"centraila",
                "name": "Centrailia"
            }
        }]
},
"source": {
    "type": "FeatureCollection",
    "features": [
        {
            "type": "Feature",
            "geometry": {
                "type": "Point",
                "coordinates": [-122.5,46.5]
            },
            "properties": {
                "id":"farm1",
                "name": "Farm1"
            }
        }]
},
"options": {
   "costs":{
      "diesel_per_gal": 2.14,
      "labor_per_hour":32.16
   }
}

For the output, the id's are calculated in a similar manner, the MD5 of the geometries are used for the id's of the paths. The source and destination match the input data. Similarly, the id's for the features in the network are MD5's of the geometry of the features as well.

Output:

{"paths":{
    "type": "FeatureCollection",
    "features": [
        {
            "type": "Feature",
            "geometry": {
                "type": "LineString",
                "coordinates": [[-122,46.5],[-123,46.72]]
            },
            "properties": {
                "id":"farm1-centrailia",
                "source":"farm1",
                "destination": "centraila",
                "time_traveled": 1.2,
                "distance_traveled": 45.5,
                "cost": 23.00,
                "path":[r1,r4,r5,r6]
            }
        }]
},
"network":{
    "type": "FeatureCollection",
    "features": [
        {
            "type": "Feature",
            "geometry": {
                "type": "LineString",
                "coordinates": [[-122,46.5],[..],[..],[...][-123,46.72]]
            },
            "properties": {
                "id":"r1",
                "distance": 1.2,
                "time": 45.5,
                "cost": 23.00,
                "capacity":40,
                "connections":[[r0,r3],[r2,r5]],
                "paths":["farm1-centrailia","BRFISYB"]          
            }
        }]
}

This allows a client to add new paths incrementally. The id's for the paths and network will be constant from one call to the next.

[qjhart]

1. Why is the word 'file' in here? Do you mean request and response format?

Updated description to eliminate file

1. I think we should try and limit the request payload size as much as possible (for that matter the response too). Supplying params as: sources={id: [lat,lng]}, destination=lat/lng, and options={}, we can save a lot of network bandwidth.

Don't see a huge savings on the inputs for that, esp. w.r.t using the GeometryCollection as decided above. I guess I do see a savings in output, but then I'm less excited about not using geojson for that complex response. Protocol Buffers :)

1. ID's. Aren't the source lat,lng a unique id?

Using the GeometryCollection, they would be. I prefer the put those through the MD5 blender, just so they match paths as well. I threw in the FeatureCollection, predominantly so a client wouldn't have to check that no points had matching coordinates. I would assume we'd use the GeometryCollection method, so I don't mind starting with that.

1. Agree with with sending response network as single geojson FeatureCollection object. And like using id, based strategy path lookup. As for the individual routes, can't these just be expressed by the properties object in your 'path' collection above?

The current proposal has two FeatureCollections. Both are reasonable. I assumed options could include, paths=false; network=true, which is way i made them separate. The reason to not put the route in the 'paths' column is for a few reasons.

1. You can compute capacities and densities by adding up the individual paths traveled by walking the path array in the paths response.
2. This works with incremental calls to the service, as the path identifiers don't change, so you can get
3. You don't have to traverse the path to accomplish that.
4. You can actually have a more featureful client, for example updating costs with changes to the fuel or labor, since you know how to cost each component.

Follow ups. What datasets and software are you looking to use to create this service?

[qjhart]

Comments updated above.

For the datasets, I plan to use the BTS transportation atlas. Specifically, the Freight Analysis Framework FAF data.

For software, pgrouting, part of postgresql. Previously I did this by adding extra nodes to that routing table, don't think we want to do that this time around.

[qjhart]

Quick overview of the previous FAF based version of the pgRouting.

• Vertices We uploaded the entire FAF database, then we selected the start and end points of every linestring. These became the vertices of the routing network. These were added in with a serial primary key, and we joined on the actual point location.
• Edges Next, we added edges by calculating a number of different costs, we had miles traveled, hours, and then two different costs, bale and liquid.
• Costs We use the INL biorefinery study for our travel costs. This model uses labor and fuel as inputs. We could rewrite this in plv8
• Extra In our model, we created special route stubs in order to be able to use ArcGIS's routing system. These include the loading and unloading costs. These can no longer be prebuilt, and we need to figure out a better method for that. The issus is that we would add new nodes to the closest road segment to the county, and connect to there. That is no longer an option, so, for every site, we may need to find the closest road, and then find both endpoints, and calculate from both sides, and then combine with the stub for our distance traveled.

[jrmerz]

@qjhart

Couple first pass questions. First, you say pgRouting is used, but I don't see any pgr_ methods in the SQL. Second, what role is ArcGIS playing in this? Is there a ArcGIS Server, NAServer service in this picture somewhere?

[jrmerz]

Started a script for importing osm road data into pgrouting 113739a0e366ab949066a3529b668dd22ba21957. It uses this:http://osm2po.de/

pull and run

cd transportation
./import.sh

Will grab 4 states, build a topology for the osm data, merge and place results in data/ahb. The import script will stand up a little service so you can test out the data. in /data/ahb there will be the final .sql file.

[qjhart]

Justin needs to get an update on what the transportation cost will really be.