In data prep, create a Java app that generates service areas and nearest service centre for all feature types identified as service centres

@mraross commented on [Fri Apr 28 2017](https://github.com/bcgov/api-specs/issues/193)

Add support for nearest service centre in road network geocoder source file.

For each road segment in DRA, compute the nearest service centre for each feature type identified as a service centre (e.g., schools, hospitals).

Generate service area polygons for each feature type identified as a service centre.

Modify geocoder and router initialization functions to handle nearest service centres in road network source file.

---

@cmhodgson commented on [Tue May 02 2017](https://github.com/bcgov/api-specs/issues/193#issuecomment-298744356)

Rather than adding the data to the road network file, I would recommend creating a new file. This file would have a variable-length schema depending on the number of service area types that are defined. For each service center feature type, the file would contain the id of the closest service center (do they have IDs?), and the distance (along the road network) to it. The key identifier for the row would be the intersection id. So the schema fields would look something like:
intersection id, type1ClosestId, type1ClosestDistance, type2ClosestId, type2ClosestDistance....

We need to define the how the polygons are to be created. Can they overlap? Can they have gaps? Do they need to form a perfect coverage of the province? alpha-shapes cannot create a coverage. Can we separate the creation of the polygon layers out into a separate ticket? Without this aspect, the estimate for this ticket is reasonable. Depending on how we want to create the polygons (and do we really need them?) that part could be 2 weeks or more.

---

@mraross commented on [Tue May 02 2017](https://github.com/bcgov/api-specs/issues/193#issuecomment-298753210)

Perhaps a service area can be represented by just its road segment geometry? with this geometry, a client application can style and display it on a map using WMS or it can pull out the geometry and perform spatial analysis on it.

---

@mraross commented on [Tue May 02 2017](https://github.com/bcgov/api-specs/issues/193#issuecomment-298754259)

Agreed that creating a new file for nearestbyRoad data is better than adding this data to the existing file, especially since the router won't make use of this data at all. Since service centres are just occupants, every service centre has a unique occupant id.

---

@cmhodgson commented on [Tue May 02 2017](https://github.com/bcgov/api-specs/issues/193#issuecomment-298760179)

Using just the road segments to represent the "service area" would be straightforward. Another approach would be to apply the parcel polygons to their associated road segments and dissolve them grouped by nearest service center. This takes a bit more work (are the parcel polygons open?) but at least gets you polygons that you can do PIP on with site points.

---

@mraross commented on [Tue May 02 2017](https://github.com/bcgov/api-specs/issues/193#issuecomment-298796914)

Compute the following attributes for each service area:

1. service area population estimate
2. total distance of population to service centre
4. total road network length

Service area population estimates are aggregation of DRA block population estimates which can be sourced from StatsCan under an OGL license.

---

@cmhodgson commented on [Thu May 04 2017](https://github.com/bcgov/api-specs/issues/193#issuecomment-299229506)

If we are using the road segments as the "area", where are we putting the service area attributes? Would we collect each service area's lines into a multi-line (not great for rendering, similarly to large polygons)? Attach the attributes to each segment (a lot of repetition)?
Also, I assume that we would break blocks at points equidistant from the service provision locations; and then proportionately divide the block population estimates based on the relative length of the line in each service area.

---

@mraross commented on [Fri May 19 2017](https://github.com/bcgov/api-specs/issues/193#issuecomment-302826150)

Good point. We need a serviceAreas/{serviceCentreId} resource for service area properties. serviceCentreId is the occupantId of the occupant that represents the serviceCentre at the centre of the service area. So we need a service areas file as well.

---

@cmhodgson commented on [Tue May 30 2017](https://github.com/bcgov/api-specs/issues/193#issuecomment-305025486)

I think we make ServiceCentre a subclass of occupant with the additional service centre (area) properties (total network length, population estimate, etc.)
/geocoder/occupants/serviceAreas/{serviceType}/{serviceCentreId} will return all of the occupant properties as well as the additional service centre properties. Where there {serviceType} is specified by the tag used in GSR to identify the type of service offered by the centre.

We would also output two shapefiles (or equivalent) for each service type, one with all of the segments, broken up as necessary, with the serviceCenterIds attached to each segment, and the other with the service centre points, and associated attributes, these to be used in WMS/WFS services external to the geocoder.