Raphael Dumas

The `wys.stationary_signs` materialized view is sort of accounting for this over time by looking at the previously and subsequent `start_date` for any given sign (`api_id`) https://github.com/CityofToronto/bdit_data-sources/blob/b4cc5dbf4930d5957a87eb2745e16c363412198f/wys/api/sql/mat-view-stationary-signs.sql#L27-L31 This is then used...

Weirdly this issue came about not because of a sign being replaced, but actually a swapping of names between two signs on 2021-08-18 ```sql SELECT * FROM wys.locations NATURAL JOIN...

There should be a check on all signs when they have stopped producing data after 2 months.

Does this supersede #175 ?

Updated the 1st comment based on output from the Blue Tooth Blue Sky meeting

Per discussion with Mohan, think we can skip creating the crossover table between routes and analysis

Per @webgisgeek's investigation, it seems `route_point_id` pulled from `all_analyses` aren't actually unique for each detector, so we can't use the values from that table as unique identifiers for our detector-installations...

Following a discussions with Sarah I think we should have a `gis_core` schema for our core GIS layers and then the rest of the mess can stay in `gis`. ##...

This line needs to be updated with an `if not exists` https://github.com/CityofToronto/bdit_data-sources/blob/5f8197fba0966d28b3b7a74884e164c433adc358/gis/gccview/get_layer_gccview.py#L130 The preceding underscore can be removed. Also this is a sql injection vector.

Added [Loop Detector](https://insideto-gis.toronto.ca/arcgis/rest/services/cot_geospatial2/MapServer/46) to the list of `gis`