Acella: non coincident parcel address problem

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;

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

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

Mike, 
I have requested a meeting with Hema...
Can we use a multipoint geometry?

Yes, we can use
multipoint.  I would have thought either multipoint or multipolygon were
definitely the way to go.  Realistically, Planning’s needs for addressing
are much simpler than DBI’s so either would work for us in Planning.  The
planners work almost exclusively with parcel numbers rather than
addresses.  Everything else being equal I would always prefer multipolygon
but I know Alton prefers multipoint.  I think we should go with whichever
works best for DBI.


 


Thanks, mike