...
| Code Block |
|---|
SELECT ab.base_address_num, ab.base_address_suffix, a.unit_num, sn.base_street_name, sn.street_type, p.blk_lot FROM address_base ab inner join addresses a on (ab.address_base_id = a.address_base_id) inner join streetnames sn on (ab.street_segment_id = sn.street_segment_id) inner join street_segments ss on (ab.street_segment_id = ss.street_segment_id) left outer join address_x_parcels axp on (axp.address_id = a.address_id) left outer join parcels p on (axp.parcel_id = p.parcel_id) WHERE 1 = 1 and sn.category = 'MAP' and ab.retire_tms is null and a.retire_tms is null and axp.retire_tms is null and not st_intersects(ab.geometry, p.geometry) order by ss.st_name, ss.st_type, ab.base_address_num, ab.base_address_suffix, a.unit_num; |
Questions
Does DBI have to support this kind of address?
Can we live with the Acella constraint of allowing only parcels to be part of an address if the parcel is spatially coincident?
Discussion
Paul McCullough
We were planning to adapt the existing EAS change notification process to feed address changes into the Acella GIS.
In doing so we would not have to stick with the exact model layed out in the XML file.
In fact, it may help to think about the Acella address data as a view (in the MVC sense) of the EAS address....
and perhaps the address point in Acella GIS is not the address base point but rather the parcel centroid.
Another possibility is for EAS to adopt a muli-point geometry for the base address.
Another other ideas?
Mike Wynn
Questions
Does DBI have to support this kind of address?
Can we live with the Acella constraint of allowing only parcels to be part of an address if the parcel is spatially coincident?
...
| Code Block |
|---|
From: Wynne, Mike [mailto:mike.wynne@sfgov.org]
Sent: Wednesday, October 17, 2012 4:58 PM
To: Paul Rose
Cc: Chinn, Alton
Subject: APO data...or mainly just the 'A'
Hi Paul, hope things are going well with you.
I’ve started working with Paul McCullough (at our Dept of
Technology). Paul manages the City’s Enterprise Addressing System
(EAS). He has worked closely with the Dept of Building Inspections to
create a live synching of addresses between EAS and DBIs permitting system.
I am now working with Paul to get something similar in place for the
Accela-GIS address data.
DBI’s current system allows some address related tasks that
I am sure we can’t replicate within the Accela software, but I just wanted to
confirm this before speaking with DBI. Incidentally, this may not be a
problem, I just want to be clear when we speak to them.
In their current system each address record includes a
latitude/longitude coordinate and a link to a list of associated parcels.
When they search for an address it will return the address, the lat/long
coordinate and also all of the associated parcels. There are over 3,000
addresses in the City’s address data where the address is linked to multiple,
disparate parcels (parcels which do not all lie under the lat/long point – e.g.
a row of adjacent parcels with a single address, or even and address linked to
multiple parcels scattered over a couple of blocks).
It seems to me that in Accela-GIS, for each property, we can
EITHER store the point geometry (based on the lat/long) OR the combined
geometries of the associated parcels. I believe that it is these
geometries that will define what data is returned to the Accela Automation user
after they have searched for an address (the parcels, owners, zoning,
environmental data, etc). The issue is that if we go for a point geometry I see
no way of returning any parcels that are not immediately below the point.
Whereas if we use the geometries of the associated parcels I see no way of
having addresses that lie outside any parcel (e.g. an address located in the
street – an address with no associated parcel). Can you confirm if this
is correct?
Thanks, Mike |
Paul Rose
| Code Block |
|---|
Mike,
I passed your questions/comments
on to Accela Engineering and received an initial response.
Our Standard XAPO for Accela GIS
will not be able to handle cases where an address point doesn’t intersect the
associated parcel geometry. For the additional logic needed to be able to
evaluate data and find/select parcels or address points that do not overlay
each other, a custom XAPO adapter would need to be developed.
If we end up going down that
road, additional analysis would be required and GIS data examples would need to
be provided so that an estimate could be done for the custom XAPO adapter.
If using our standard XAPO
adapter for AGIS, the end user would be presented with a list of address points
and or parcels and owners that intersect the selected object and the user would
have to select what other components of APO they want to pass back to Accela
Automation.
What Accela Automation stores
for GIS objects is normally the Parcel’s GIS unique ID and then the information
for Parcels, Addresses and Owners is stored as transactional data to the new
record. However, any GIS feature ID can be associated to an Accela Record, it
just is normally the Parcel ID.
Paul H. Rose
Senior Consultant
|