-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
In geocodable bc maker, handle addresses whose parcel and access points don't fit into the address fabric #224
Comments
An Anti-Unit Address is a unit address with its unit number and civic number interchanged. Anti-unit addresses account for many of the addresses whose access lines cross. A potentially useful way of detecting an anti-unit address during access point generation is to create an anti-unit address from a given reference address, compute its anti-accessPoint, form its anti-access line and compare it to the unit address' access line; is it longer? does it cross other access lines? Example forthcoming. |
Here is an example: In ADDRESS BC, there are the following reference unit addresses:
The access lines formed by these addresses are 1.5 km long and cross many other access lines in the neighbourhood.
the anti-access lines will likely be much shorter than the access lines and they likely won't cross other lines. This indicates the unit and civic numbers in the original addresses were swapped. If we can confirm these predictions, Geocodable BC Maker could choose to keep the anti-unit addresses and thus fix the original addresses instead of rejecting them. |
In the picture below are all the incorrect unit-addresses from 4787-101 1st St Courtenay to 4787-119 1st St Courtenay. In the parcel that has two parcelPoints, the one on the left is actually the correct supersite address of 4787 1st St Courtenay. The one on the right is the incorrect 109 1st St which should really be at the east end of 1st. |
It might be easier to generate access points and assign addresses to blocks in a series of waves: Wave 1: Civic number addresses; no unit addresses Wave 2: Unit addresses Wave 3: Parent civic addresses of orphaned unit addresses Each wave can have an access line QC step. In the first wave, there are far fewer access line crossings to compute and test since there are no units and most units share the same parcel point as their parents anyways. |
A single coordinate at the condo tower shown above (21 Dallas Rd) contains many coincident parcelPoints with lines extending to the associated accessPoints. A random sample of these addresses showed that the accessPoints were located in the expected area however the parcelPoints were not. For example:
1000 Fort St, Victoria parcelPoint - Coincident point at 21 Dallas road (condo tower). 1700 Bay St, Victoria parcelPoint - Coincident point at 21 Dallas road (condo tower). 1480 Dallas Rd, Victoria |
Unlike the Victoria example above, in this case we have coincident accessPoints that fan out to individual parcelPoints. The accessPoints are located just on Lougheed Hwy just above Como Lake Ave where the highway line changes from a single line to parallel lines. In this example, addresses were listed as being on the Lougheed Hwy.
925 Lougheed Hwy, Coquitlam, BC |
North Vancouver - Example #1: The image above shows several accessPoints at the exact same location which extend out to the respective parcelPoints. The accessPoints are placed at the same coordinate at a fork in the road between E 3rd St and 3rd St E. Examples:
419 3rd St E, North Vancouver, BC |
North Vancouver - Example #2 The accessPoints are placed at the same coordinate at the intersection of E 19th St and Grand Blvd in North Vancouver. From there lines extend to the respective parcelPoints. In this case the parcelPoints appear to be in the correct location, however the examples below are missing a streetDirection.
DRA: "Grand Blvd E" DRA: "Grand Blvd W" |
Courtenay - Example #1: The bulk of the points below are found within a gated community called 'Britannia Place' which has a number '3399' on the road beside the Britannia Place gate. In a similar pattern to other cases we see coincident accessPoints just south of the intersection of Crown Isle Drive and Malahat Drive from which there are lines to the corresponding parcelPoints. However, in this case some of the addresses in Britannia Place have both accessPoints and parcelPoints in the correct location, while others are found in the same location. Examples:
Correct accessPoint location: Incorrect accessPoint location: |
Courtenay - Example #2: Several coincident accessPoints at the intersection of 1st St and Urquhart Ave in Courtenay, BC. The corresponding parcelPoints (random sample below) are in the correct geographic locations, however, the homes were built on a private road that branches off of 1st St. A sign by the entrance reads '2787 Riverbend Lane'
For example: 103 1st St, Courtenay, BC |
Several coincident accessPoints at the intersection of Shorncliffe Rd and Jillian Place in Saanich, BC. The corresponding parcelPoints (random sample below) are in the correct locations. An interesting finding here is that there is a second parcelPoint for each with a "N" suffix as well as a second accessPoint in front of the house with a "N" suffix.
Expected location: Incorrect location (Shorncliffe Rd & Jillian Place) |
Several coincident accessPoints at the intersection of 2nd Ave and Moffat St in Prince George, BC. The corresponding parcelPoints (random sample below) are in the correct locations. An interesting finding here is that there is a second point for each address below with an "N" prefix as well as a second accessPoint in front of the house with a "N" prefix. Recommend checking in DRA to see where Moffat St turns into N Moffat St Examples:
385 Moffat St, Prince George, BC |
In this example, a cluster of accessPoints are found at the same coordinate on Green Lake Rd which point to the correct parcelPoint locations. However, the parcelPoints are up to 4km away on Green Lake Rd. Examples:
2735 Green Lake Rd, Oliver, BC |
Chris Hodgson commented on Feb 26, 2021: OOH, AAAH! This (access-line diagram -ed) is so useful. I should have done this when I was writing the BAARG. If I do any work on the BAARG in the future I will probably make it output this for comparison and testing. Do you still want me to try to add these to the OLS-Demo? It shouldn't be two hard, especially if you commit them to the ols-devkit repo gh_pages branch for me. That would probably make analysis easier even without all the changes Graeme requested (but he probably still wants that for analysis outside of the ols-demo app). Cheers, |
How about measuring the distance between a unit accessPoint and the unit's superSite accessPoint? Most of the time, the accessPoint of a building will be fine since there is no unit number to accidently get the civicNumber swapped with. By doing the buildings in the first wave, in the second wave this new test should reveal if an address has had its unit swapped with its civic number. I suggest we call the line between a unit accessPoint and its supersite accessPoint, a super-access-line. |
Further details added to the images above listing examples and findings thus far. Next step will be to examine the source data. |
What if we constrain our access line crossing metric to look for crossings involving one or more roads whose road type is at least Residential? In other words, ignore crossings with strata roads, etc. |
The current access point generation process is creating access points that are far from their parcel points. If you create access lines which are lines connecting access points to their parcel points, you will see long lines that cross other lines. Such crossing lines strongly suggest that the source address is invalid in some way (e.g., unit number and civic number swapped). Preliminary analysis indicates there could be up to 9,000 such addresses in the geocoder's latest reference address list (see #219) We would like to detect and reject such bad addresses in the future.
The text was updated successfully, but these errors were encountered: