This set of remaining ETL issues has ramifications that go well beyond the ETL itself.
The Right of Way Address issue a a good example (details below).
With that in mind I think it is vitally important that we focus on this question...
what is the bare minimum set of features and data that we need to make a viable 1.1 release?
| Table of Contents |
|---|
...
service addresses
Description
There are a number of AVS addresses that use a non-existent block lot.
These are currently During the ETL to EAS these are generating exceptions of the type "no matching block - lot".
We are waiting for DBI to confirm how we can identify these addresses (e.g. lot = '000'?).
We expect that most of these addresses will have a valid street and street number.
These addresses are called We are calling these addresses service addresses.
Conceptually the exist in the "right of way addresses"" but we may not model them in geographic space that way.
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.
Other agencies such as DPW wants this (or similar) feature as well.
Option 1 (increase scope)
Use a "right of way" polygon map layer to support this feature
It appears that there will be 2 chucks chunks of work here.
First we will have to introduce the notion of a "service parcel".
The service parcel would be a citywide parcel with a unique block-lot (e.g. 0000-000) that would support service addresses at arbitrary locations - including the right of way.
The web application behavior may be imperfect in some edge cases (user adds an address in the middle of the bay) but this may not require any changes if the application behavior is reasonable.
I think this work will take less than a day.
The second challenge will be to write some additional ETL code - possibly non-trivial.
I think this work may take as many as 3 days.
...