Attendees
Paul and Jeff met with Brian Smith, Alton Chin and Mike Wynne.
What We Disucssed
Paul and Jeff presented some options for the next enhancements to EAS (see below).
City Planning expressed interest in the mail-merge functionality, and would be willing to work collaboratively with Paul to develop the functionality. There are 2 types of mail notifications activties. One is done in house at Planning, happens about once a month, and requires about 30 miniutes of developer/analyst time (about $50/hour). The other is outsourced to the Radius company. Radius charges land developers $195 per job, uses data from the city itself, and the results are usually satisfactory but sometimes are quite poor and require a redo. Brian would like to bring this work in house noting that it is a revenue stream and we could improve data quality with this process.
Alton was interested in a replacement for the Assessor addresses that currently bring over and run through transformations. Jeff said he would work with Alton to provide that replacement for him based on the EAS data.
Brian mentioned the Citydex application (like Rolodex) and wanted to know if it makes sense add a module to EAS that does what Citydex is supposed to do (todo: get links to docs or reqs). He also mentioned that some other folks at DT had been working on it with Daniel Homsey. We subsequently talked with Richard Isen at DT about the state of the Citydex application. He said that while some data has been collected there is no real application and the effort has stalled. Here is an email from David Geller explaining the state of the Citydex project as of Jan 27 2012.
Hi Paul,
I asked Richard and he assured me that the project was not dead but he also mentioned that it may have some issues based on the project sponsor.
I am not sure how much background you want on the project and realize that I can only give a historical perspective.
The project started as a request from the City Administrator’s Office to the Innovation Office in Department of Technology to help find a software product that will allow the sharing of contacts between departments. Contacts would be neighborhood groups, other organizations (business, churches, etc.), and individuals. The goal was to create a database that would allow a single view of the contact’s main information such as Name, maybe address, maybe phone, maybe email, related associations and Interests. The vision was then for each department to store individual metadata on the contact. The contact would have the ability to change their main information and each department could change their stored metadata on the contact.
When this project kicked off, it was stated in the proposal that:
• Application content will be maintained by GSA.
• The online database will require a partial FTE to maintain after delivery
And
• Funding by Members of the Working Group
The funding was to be used to hire consultants that would manipulate the open source product named CiviCRM to fit our usecase. The fact that the funding was never secured meant that I continued to work on a proof of concept but a final product would likely never come to fruition.
As you know I have l left the innovation team and have handed off the project to Phebe Wang and Richard Isen. I don’t believe there has been much progress on the project and I have reiterated to them that the project’s success is contingent on it being funded. As far as I know, that has not occurred.
–
Dave Geller
Business Analyst
Security Services - Dept. of Technology
City & County of San Francisco
o: 415.581.3985 | Google IM: david.geller@sfgov.org
Action Items
Jeff and Paul will provide Alton with an EAS derived replacement for the Assessor data - by Feb 15?
Jeff and Paul will take this information with them to meetings with other EAS stakeholders - to occur by the end of February.
We all need discuss (and debate) whether a Citydex module belongs in EAS - conclude debate by Feb 8?
Proposed Enhancements
http://code.google.com/p/eas/issues/detail?id=460
Enhance the address change notification messaging to notify an arbitrary list of clients when changes occur. This would provide subscribers real time updates to their local addressing system. For example, DBI is required to notify the Fire Department when addresses change. This is currently done manually by DBI and would be automated with this enhancement.
http://code.google.com/p/eas/issues/detail?id=405
Make it easy to discover the block and lot number from the map.
http://code.google.com/p/eas/issues/detail?id=168
Add aerial imagery to the map.
http://code.google.com/p/eas/issues/detail?id=217
Auto approve certain types of change requests: Certain city processes require relatively rapid action (e.g. sewage spill response). The change request process slows things down too much in these cases. A solution is to automatically approve change requests that meet certain criteria. For example, if a change request is not retiring an address component it would be a good candidate for an auto-approve.
http://code.google.com/p/eas/issues/detail?id=396
Provide mail-merge functionality. Numerous agencies want to be able to specify a location on the map, and generate USPS mailing lists for residents and/or owners within N feet of the pin or containing parcel.
http://code.google.com/p/eas/issues/detail?id=226
Provide address lineage and display of retired addresses. This is something that is of keen interest to Building inspection. It is also one of the more complicated enhancements.
Add Comment