Rjf/map model

[robfitzgerald]

This PR includes the code changes to implement a first class map matching module for RouteE Compass as described in #244. Additionally, updates the frontier model as described in #129.

Status:

• a map module
  • designed to take references of objects containing geometries, no copy req'd
• edge rtree in map model
• storage for geometries in SearchApp
• wire in map module with SearchApp
• pass SearchApp to output plugins, read geometries from traversal output plugin
• pass MapModel to input plugins, or make map matching it's own full step before input processing, and use rtree lookup in map matching phase
• cleanup/remove old bits
• pass tests
  • speeds e2e test fails, app.run() returns no rows
• remove VertexRTree InputPlugin, migrate tests
• remove EdgeRTree InputPlugin, migrate tests
• add frontier model road class filtering to map model
• tests for MapInputType::process_origin + process_destination agreed to delay on this
• create issue to migrate tests for Traversal OutputPlugin into the MapModel file moved assets, agreed to delay
• fix deserialization of MapInputTypes in the [mapping] section

Closes #244.
Closes #129.

[nreinicke]

Nice work, this is looking great. I left a small comment about the proj dependency.

I also ran this against our open street map example and it failed with the error in the results request had error: required query field 'origin_vertex' not found. I tracked this down to the UUID output plugin that expects to find an origin vertex id but in our new defaults, we're using the edge oriented map model and only adding in edge id.

Eventually, it might be nice to allow the UUID output plugin to support edge uuid mapping in addition to the current vertex only behavior, but at a minimum, I'm wondering if we could remove the UUID output plugin from our default osm config and add in a quick check at the UUID output plugin process method to see if we're running an edge based search and return a better error.

Overall though, everything is running smoothly and it's great to see that we're only loading in our geometries once, great work!

[nreinicke]

Looks like this isn't being used currently. Having this in actually causes a build failure on my end (which could probably be resolved) but thinking we should remove it for now until we actually start doing CRS projections.

[robfitzgerald]

right. at the outset i was attempting to include the CRS processing that you referred to in our convo yesterday. i'll comment this out and we can come back around to this in the future, but i also had this problem on my m1 and so suspect we may want to make it an optional compass feature.

[robfitzgerald]

I'm wondering if we could remove the UUID output plugin from our default osm config and add in a quick check at the UUID output plugin process method to see if we're running an edge based search and return a better error

right, i thought i already removed it. it's removed now. as for returning a better error, i think instead we need to implement a better UUID plugin that never fails, has two optional input_file arguments for vertex and edge UUIDs, and then simply matches query fields to UUIDs where both field and lookup table exist. for now, it's just dangling there. i'll make an issue. ok, did it: #265.

[nreinicke]

That makes sense to me!