Welcome

The San Francisco Enterprise GIS Program (SFGIS) is pleased to announce that version 1.3.8 of the
Enterprise Addressing System (EAS) is now available internally to all City and County of San Francisco
staff for production use.

This version features:

• Improvements in Announce New Release and Address Change Report notifications

• Behind-the-scenes, operational improvements (deployment, disaster recovery)

• Documentation clean-up

The complete list of issues that were resolved in this version is available here.

Perhaps more importantly than these particular product features, Dan King has been working diligently since our previous release, preparing to bulk-load approximately 118,000 new addresses into the EAS during the next few weeks. This will noticeably improve the comprehensiveness of the EAS' address data, something that the SFGIS Address Working Group requested some time ago. We will communicate this further once the bulk-loading begins in earnest.

Finally, we are also planning to release the next version of the EAS in early April 2019.

The San Francisco Enterprise GIS Program Staff

The Enterprise Addressing System (EAS) version 1.3.7 has been successfully released, and it is now available internally to all City and County of San Francisco staff for production use.

This version features:

• Displaying address data sources, and other minor GUI clean-up

• 2018 imagery basemap (Thank you, Brian B. Quinn (Unlicensed) !)

• State of California LUCA 2018 addresses bulk-loading preparatory work

• Miscellaneous documentation clean-up

The complete list of issues that were resolved in this version is available here.

Look for another release in about one month’s time!

EAS Release 1.3.6 (internal to the City and County of San Francisco) is now live, and this is our first release in quite a while!

This release features the successful migration of the EAS application’s failover instance from a commercial data center that is located in San Diego, CA, to the City’s Disaster Recovery (DR) Data Center, which is located near Sacramento, CA. Besides allowing us to save some money every month, this migration will also reduce some friction from related operational and support activities.

The complete list of issues that were resolved in this release is available here.

Welcome back, EAS!

EAS Release 1.3.5 (internal) is now live!

This release mostly features behind the scenes fixes.  A full list of the issues addressed in this release is available here.

EAS version 1.3.4 is now live!

It's been a long time since we've done a new release, so we're getting things started light here.  This release includes a couple new features for our users:

1. The ability to seed EAS with a search in the URL, e.g.: http://eas.sfgov.org/debug?query=1 south van ness
2. New, better imagery, now available at 3 additional zoom levels - super helpful for drawing address points on the map.

Thanks!

EAS Release 1.3.3 (internal) is now live!

Release 1.3.3 is focused on creating new tools for system administrators to load address data into EAS in bulk.  These tools will allow dumps of address data from sources both inside and outside of the City to be loaded into EAS by system administrators.  

If you have or are aware of a source of address data that should be loaded into EAS, please contact the EAS support team and let us know.  The team will then evaluate the source address data and if applicable load them into EAS using the new bulk address loader mechanism.

A full list of the issues addressed in this release is available here.

Release 1.3.2 (internal) is now live.  In addition to a number of bug fixes and minor changes, Release 1.3.2 includes two major changes.

First, we've added a new feature that will send address change notification emails to a list of subscribers.  Currently the emails will be sent on a weekly basis to the Assessor.  If you would like to be added to the subscriber list, please contact the EAS support team.

We've also added support for linking addresses located in the right of way to parcels from their nearest block.  Previously, addresses located in the right of way could only be linked to the "service parcel" (0000-000), but now they can be linked to the service parcel as well as parcels from the block nearest to the address point location.

A full list of the issues addressed in this release is available here.

Release 1.3.1 (internal) is now live.  This is a minor release consisting primarily of clean up tasks following our recent migration from Google Code to BitBucket.  We've cleaned up our documentation a bit as well as fixed some minor bugs.  Most of the changes made in this release relate to internal system processes and should not effect our users.

One change that is noteworthy for users is the addition of a new Unit Address type, 'home owners association', which was added at DBI's request.

A full list of the issues addressed in this release is available here.

Release 1.3.0 (internal) is now live.  This release was primarily focused on moving our source code hosting and issue tracking from Google Code and Atlassian OnDemand over to BitBucket.  Now that all repositories are using BitBucket, it should be much simpler in the future for SF developers and other organizations to develop against EAS.  As of this release we are retiring the EAS Google Code site as the official project site.  It will remain available for the time being as a reference, but our new official project site is the EAS BitBucket page.

This release also includes a couple enhancements for our users. 

The first enhancement is the ability to find parcels on the map.  This is done by right clicking on the map and at a location of interest and choosing "View Parcels Here".  EAS will then display a list of the parcels located at the selected location in the left-hand panel.

The second is that we've updated the road labels on the base map so that now they will curve to follow the road lines.  We've also added these same road labels to the imagery to provide additional context.

A full list of the issues addressed in this release is available here.  In future releases issues will be tracked in the new EAS BitBucket issues page.

Release 1.2.1(internal) includes 4 significant enhancements for our users.  

The first is that we are now showing retired addresses on the map when you check the "include historical" checkbox next to the search tool at the top.  Points that contain at least one retired and one un-retired address are distinguishable on the map by their lighter color and grey outline on the map or a black outline on the imagery.  Points that contain only retired addresses (clusters or single address points) are white in the center with a grey outline on the map or a black outline on the imagery.  Retired addresses show up in grey in the cluster popup list.  This is meant to be another tool for users to find and inspect retired addresses.

The second is that we have moved validation warnings from the "More" tab of the address report and into the header so that now it is easier to see these warnings without having to click on the "More" tab.  These warnings are now also visible in the address list tool (for example, after doing an address search).

The third change is that we've added provisioning information to the parcels tool on the left.  If a parcel has been provisioned, the provisioning date information will be shown along with the create and retire date information.

Finally, we felt that it was taking too long for address points to come up on the map, so in an attempt to alleviate this we've put effort into improving the performance here and we are pleased to announce that we've increased the performance of our server-side code to return these points by more than 3x (!!!), which should result in noticeable performance improvements for our users.  You will also now see a loading icon in the bottom left hand corner of the map to let you know when address points are in the process of being loaded.

A full list of the issues addressed in this release is available here.

We've got 3 significant enhancements in the 1.2.0 release (internal). After much preparation, we've added the address change report (aka address lineage).  This feature allows you to discover, for any given address, what address(es) preceded it and/or what address(es) succeeded it.  This works at the parcel level and is a many to many relationship.  To see the change report for an address, just click on the link/unlink dates within the address detail report.  Most addresses will not have any lineage yet because we started capturing lineage on February 15, 2012 when EAS was first released.  The second enhancement in this release is a major rework of the address detail report.  We mostly did this to support navigation to the address change report.  We also moved it from a popup on the map to the left hand panel because most people thought the popup was blocking too much of their view of the map.  Finally, address validations are now visible by default.  You can spot an address that has a validation issue by looking for the little yellow warning triangles () on the map and in the address detail report.  What is a validation issue?  For example, a typo may result in "1000 Main Street" being created on the 100 block of Main Street.  Another example is when an address remains linked to a parcel even though the parcel has been retired.  EAS won't force you to fix all address validation issues - but now you'll see the warnings right up front - and you decide if something needs fixing.  We expect that there will be a few more features around validations in the medium term. The complete list of issues and enhancements in this release is here.

With the release of 1.1.9 (internal) we are supporting access to historic addresses - meaning that you can now search for and report on addresses that have been retired. We have also added an address linking feature so you can easily link to an address. To use this feature, look for the  at the top of the address report popup. You can see all the issues here.

With release 1.1.8 (internal) we now properly support "post direction" for streets (e.g. Mission Bay Blvd North). If you are tracking addresses in your databases, consider adding a post direction field. If you can't do this, a reasonable hack for this is to concatenate "street name", "street type", and "post direction", and place the result back into the "street name" field, and optionally set "street type" to null. Another alternative is to concatenate these 3 fields into a separate field called something like "full street name". To make this more concrete take a look at the exported view of EAS addresses. In any event, thanks go to the Base Map team at the Department of Public works for maintaining street data - a critical, difficult, and often times thankless job. While we were making changes to the street data data model, we attended to other data model house keeping and worked fairly hard to get rid of stuff that no one uses anymore. This sort of work is not exciting but improves the sustainability of any IT project. The only new feature is a parcel service which we have built in cooperation with the Aksel Olsen at the Department of Planning. The complete issue list is here.

As of 1.1.7 (internal) our ETL processing is now backed by PostgreSQL instead of DB2 which we are decommissioning.  This will reduce software license costs and overhead.  On the front end, we've provided three enhancements. First, we've simplified search - less confusion, less mousing, and less clicking!  Second, the address report now has a direct way to show parcels (and units).  If there are lots of parcels (or units) you can filter by right clicking on the grid headers. Thirdly, accessing parcel information is now much better integrated into the application. On the back end we've made a couple of changes. The EAS geocoder web service has been completely reworked. Included in this rework is a python command line client and greater OGC compliance. In addition, we now return unit and parcel level information. Finally, if you use the flat file export, you'll want to look at the flat file export page to see what fields we have added. The complete issue list is here.

As of 1.1.6, the ETL infrastructure for EAS is running on VMware, just like the application itself. Because VMware is a city standard this should improve support. Our (DT) virtual infrastructure is monitored and supported by some very competent engineers. I am very happy to have this kind of support because I am busy wearing lots of other hats. The entire issue list for this release is here.