in geocoder, add serviceCentres/nearestByRoad resource

[mraross]

Assessors at BC Assessment need to know the occupants nearby that would affect a property's value (e.g., railyard, school, firehall).

This will require the implementation of the roadVoronoi resource in the route planner.
Input parameters should include accessPoint which will be snapped to the nearest road but should be where the driveway hits the road.

[cmhodgson]

I'm not too sure how you visualize this working. The geocoder has the occupants, the router has the roads. You could implement this right now by calling:

geocoder/occupants/within?center=<property location>&distance=<maximum distance of concern> 

and then call

router/distance/betweenPairs?fromPoints=<propertyLocation>&toPoints=<the points returned in the occupants query>

This is literally 5 to 10 lines of JavaScript on the client side. If we speed up betweenPairs by using the "marching outward" algorithm then this would work fantastically for even large numbers of nearby occupants. The client would even have the flexibility to use different distances for different occupant types (tags) by just adding tags to the first query and doing it a few times. Maybe it only matters if you are within 500m of a coffee shop, but 5km of a sewage treatment plant ;)

[mraross]

The flaw in your plan is that there are road network layouts in which occupants/within will not return all the needed occupants for step 2 (think city with a river running through it). This is what we discovered in the ACDF and why we abandoned the two-step plan (aka the unholy mixing of metrics). I will be adding a roadVoronoi enhancement to the route planner soon which will explain how nearestByRoad can work with no failure cases.

[mraross]

All nearestByRoad computations should be done offline during route/address data prep. This will work with our current monthly update cycle but certainly won't work if we have daily road, address, and occupant updates.

[cmhodgson]

I assume you mean this to work as the inverse of the occupant service area boundary - this works as long as the service areas are purely distance-based. If the service areas are calculated using the population in some way, they we need multiple different kinds of "service areas" pre-computed and stored, per segment. If you have many occupant types this can get to be a lot of memory, and a lot of calculation (off-line so I suppose not a real concern).

[mraross]

They wouldn't be population based but you do raise an interesting option to support both fastest and shortest metrics. I guess we should ask clients if they had to pick one metric, what would it be.

[mraross]

Issue moved to bcgov/ols-geocoder #51 via ZenHub