Right of Way Addresses
Description
There are a number of AVS addresses that use a non-existent block lot (e.g. 0000-000?)
These address do have a valid street and street number.
These addresses are called "right of way addresses".
The ETL is currently rejecting these addresses (no matching block - lot).
The EAS application is designed to prevent addresses from being created outside a parcel boundary.
We were not planning on supporting this type of address until a later release.
DPW wants this feature as well.
Option 1 (increase scope)
Use a "right of way" polygon map layer to support this feature
There are a couple of challenges
- the "right of way" polygon layer is not maintained as is the parcel layer (can we automate?)
- we would have to write some additional ETL code - possibly non-trivial
Option 2 (maintain scope)
Defer loading these addresses from AVS until the next release.
I assume we would have to focus on this issue in the very next release.
EAS is missing some streets.
When anyone finds that streets are missing from EAS or are incorrect,
EAS users shall notify Marivic at DPW. Maravic will make the corrections
which should appear in EAS the following day.
no such street name - number is non-zero (SITUS TO BE ASSIGNED, UNKNOWN)
We can supply the correct street and street type.
Val, I assume that we should simply build the SQL for this...something like:
- update addresses set street_name = x, street_type = y, where id = z;
no such street name - number is zero (SITUS TO BE ASSIGNED, UNKNOWN)
Option 1
- create a dummy street record for the UNKNOWN street
- duplicates are not allowed, so we would have to create 0..N UNKNOWN
- we would provide update statements such as
- update addresses set number where id = x;
Option 2
We can programatically select a good approximation.
Details
- update addresses set number where id = x;
- query to get the street nearest the parcel centroid
- query to find the point on the street that is nearest the parcel centroid
- use that point and interpolation to choose the best address number
- no duplicates!
- spatial query to determine right/left side (then even/odd number)
- we would provide update statements such as
- update addresses set number, street, street_type where id = x;
Bear in mind here that this solution means at least 2 iterations of of the ETL process
First time through these addresses get excepted - and we generate the SQL.
The SQL is then applied to AVS.
On iteration 2 the rows are imported.
I like option 2 - seems likes a cleaner solution.
Amount of work for either option seems like about 2-3 days.
invalid street suffix
We agreed that in specific limited circumstances we would update street suffixes in AVS.
- e.g. Stanyan Blvd vs Stanyan St (nearest one is Blvd but AVS says St - we should choose BLVD)
- e.g. Broadway vs Broadway St (there is no Broadway St - only alternative is Broadway)
Link to Recorded Maps From APN
?
0 Comments