Ok, so we ve come up with quite possibly the most boring :tle to this talk imaginable. Thanks for coming despite the somewhat overbearing :tle.

Transcription

1 1

2 Ok, so we ve come up with quite possibly the most boring :tle to this talk imaginable. Thanks for coming despite the somewhat overbearing :tle. We d like to discuss addresses this morning, and tackle 3 main ques:ons today. 2

3 DPW, Graffi: removal; Building Inspec:on; permits, parking, blocking driveway. Typically some one calls 311, who record the address of the incident. 311 alerts Public Works (unless its City owned property, like a park. Then it s Rec and Parks). Public Works has to create a work order and dispatch some one to the site. If it s private property, the owner can be charged for the clean by the City. Need to Check with the Assessor to determine property owner. 3

4 50 plus departments, tradi:onally independent, mutually suspicious, reluctant to share many address lists in the City varying needs and uses varying formats, standards, and levels of accuracy or completeness 4

5 So, inevitably the result is a profusion of address lists across departments. Not only is the data and effort to tracking address duplicated, its done without any coordina:on, guaranteeing that departmental address data are inconsistent with each other. Unsurprisingly, this is an expensive approach that makes it very difficult for departments to coordinate their efforts. 5

6 In effect, each department has its own version of the actual addresses in the City. And because so much informa:on is :ed to an address, this makes it very difficult for departments to share and integrate their data. Consider for a moment how hard it is to coordinate work order ac:vi:es, inspec:ons, permiwng, and many of the other ac:vi:es that have to happen every day when basic informa:on like addresses aren t standardized. 6

7 At best, this makes it very difficult for departments coordinate their efforts using addresses. At worst, essen:al services can be compromised. Not only is it hard to dispatch an ambulance or fire truck if addresses aren t complete and up- to- date. But it turns out that many services, like request for graffi: removal, get funneled through local government in surprisingly complicated ways. In San Francisco, people o]en call 311 to alert the city to many needs like graffi: removal. But 311, Public Works, Rec and Parks, Housing, et al have different address databases, so determine who to call, and how to get the right people to the right place takes much longer, and therefore costs more, than it should. 7

8 This is a real problem. Addresses should be the Rose`a stone that allow departments to quickly translate their data into ac:onable informa:on for their colleagues. Addresses should streamline services delivery! They should NOT be part of the problem. And this realiza:on made it clear to San Francisco that an Enterprise Address System was essen:al. A centrally available, authorita:ve addressing system is the necessary method for streamlining the business of government: delivering services. 8

9 So, lets take a closer look at what this Enterprise Address System needs to be able to do. At a minimum, the addressing system needs to manage some basic spa:al rela:onships. Addresses are located on parcels, the management of which belongs to the County Assessor. Addresses are also spa:ally related to a street centerline segment. In SF, this is the purview of the Public Works Department. And of course, address numbers are the most basic element of an address. In SF, it the Dept of Building Inspec:on that is legally charted with the responsibility of assigning address numbers. Right off the bat, you can see that even the most fundamental elements of an address span 3 departments, already making address management an enterprise endeavor. 9

10 Now, let me say that if you re siwng there thinking I ve got this covered. I already have an address point layer in my GIS, I would suggest that you reconsider. 10

11 For one thing, Addresses are NOT points. At least, not just simple point features like you re used to. I know that sounds a bit counter intui:ve, but it s true. And there are at least 5 reasons why I can say that trea:ng an address as a point feature class is inadequate. 11

12 Reason #1: addresses can have complex spa:al rela:onships with other features, such as parcels, structures, and street centerlines. Consider parcels. Its easy to imaging that a parcel has a single address. Easy to image, and, unfortunately, wrong. Ask anyone in the assessor s office, and you ll quickly discover that addresses and parcels have a Many to Many rela:onship. Just look at :me- share condos, and you ll see what I mean! In this case, a single address might be associated with tens or hundreds of APNs. 12

13 Reason #2: No:ce, also that a single address like 609 Mission Street can have lots and lots of suites, apartments, and units associated with it. These units are all bona fide addresses, and their geometries and a`ributes need to be modeled just like any other address. We ve thought about how to manage these rela:onships, and feel that suites, apartments, etc. really are best modeled as children of a single geometry. That is to say, one geometry can represent many addresses such as apartments and suites. 13

14 Addresses change all the :me. Its quite common for addresses to come and go, even within a single building. And given that many important legal documents, like permits, and privileges, like the right to vote, are :ed very :ghtly to an address. So its extremely important for any address management system to track the lineage of address over :me. For example, any EAS worth a darn must be able to preserve and unravel the rela:onship between older addresses that have been superseded by new, valid addresses. Indeed, the EAS should be able to move backward and forward through :me to show addresses. 14

15 Note, also, that addresses are related specific streets. But its very common for a single street segment to have many aliases, and for these aliases to change over :me. Managing this requires a bit more thought than simply modeling an as a point. 15

16 And finally, of all the data you have in your GIS, addresses almost certainly represent the most essen:al business data in use throughout your organiza:on. That s why every department has an address list. Its because they have to. People are using Excel, Google Docs, text files, Access, Word, and SQL Server to track the same addresses that you re trying to manage with simple address points. If you don t have an easy was for your users to access, add, and edit addresses in your GIS, you ll never get everyone to play from the same sheet of music. And departments will con:nue to take address maintenance ma`ers into their own hands. 16

17 Ok, so addresses really can t be treated as simple points in my GIS. What is the right way to do it? And how? 17

18 So, if addresses aren t just points, let s start with a look at how address we need to build an address. At a minimum, this means modeling an address as a point geometry that interests poten:ally many parcels, is associated with a par:cular street segment, and may have many units associated with it. What we re trying to show here is that a single address is built upon several features, and that it we need to track poten:al hundreds of parcel and unit rela:onships. We need a data model specifically designed for this. 18

19 Remember that we need to track how addresses change over :me. We ll need to include the tables necessary for tracking how addresses evolve over :me in our address data model. This how we ll track address lineages. 19

20 Recall that I said any prac:cal EAS will need to make it easy for authorized people to access and edit addresses. If it s not easy for our colleagues to find, use, and contribute to the address maintenance effort, we ll remain stuck with a fragmented, inefficient, and silo ed system for managing our addresses. This means that our EAS will need to include the tables logic to track users, their address edi:ng privileges. 20

21 Finally, we need a way to ensure that all these addresses, and all the changes, and managed in a consistent manner. We don t want users to change addresses without at least some oversight. What we really want is an address edi:ng workflow, with well defined business rules, that allows our authorized colleagues to ini:ate address edits, but in a way that ensures that address edits, addi:ons, and re:rements are reviews and conducted in an orderly, predictable, and valid manner. We want some one to confirm that address changes conform to the rules we ve set. We want to conduct the process in a way that ensures the en:re organiza:on con:nues to operate smoothly. 21

22 So, at its heart, our Enterprise Addressing System is built upon a Master Address Database. This MAD is the single, authorita:ve, geodatabase responsible for managing addresses, their spa:al rela:onships with parcels, streets, apartments, units, and all the lineage requirements we ve discussed. For those of you who might be interested in the technical details, we ve implemented the MAD using the excellent PostGIS spa:al database. If you d like to to see the data model, feel free to swing by the Farallon booth later today or tomorrow. 22

23 We ve developed a nice, simple, and responsive web interface to the MAD. This web mapping app allows users to quickly find valid addresses using either a text based search, or via the map. We ve chosen OpenLayers as the primary client side library, and we can use basemaps from Google, Microso], the City s own custom basemaps, and any ArcGIS Server :lecache. 23

24 Remember that I said earlier that any EAS worth its salt needs to make it easy to manage addresses, even if you ve never used a GIS applica:on before. Our web based Master Address Maintenance Applica:on interface allows users to login and add a new address, edit exis:ng addresses, re:re and replace address, all in accordance with the business rules for addresses that we talked about earlier. Each edit is treated as an Address Change Request, that is automa:cally routed to people who are authorized to approve address changes. This Change Request metaphor makes it easy for anyone to edit addresses, and ensures that every request is approved by an authorized individual before the Master Address Database is updated. 24

25 So, the Enterprise Addressing System consists of a Master Address Database, an address browser, and the Master Address Maintenance Applica:on, the app that ensures that address data are consistently edited and audited. We ve implemented this system using PostGIS for the MAD, python and GeoDjango, a very cool web applica:on development framework, and OpenLayers and Extjs to build the client- side user interface. Together, these technologies allow us to develop what I believe are the minimum essen:al capabili:es of an enterprise addressing system. 25

26 You might have no:ced that my summary consisted en:rely of OpenSource geospa:al technologies. And, I think, its fair to ask why we decided to build the system using Open Source so]ware. 26

27 Well, let me say right off the bat that our choice of open source was NOT due to technical reasons. Our team has been using ESRI, Open Source, Google, Microso], Intergraph, Autodesk, and Oracle geospa:al technology for years. Given our needs, we were sure that any of them could meet our technical requirements. 27

28 Please don t take this to mean that all GIS technology is the same. Its not. Like any guitarist knows, you select your instrument based on the sound that you want. You want a good, solid, geospa:al sound? Lot s of People like the ESRI Stratocaster. 28

29 But if you want that innova:ve, collabora:ve, and cool Web 2.0 vibe, the Open Source Les Paul is a great choice. 29

30 No, we decided to use Open Source because we re more concerned about the Band that we are the instruments. A]er all, that s where the real magic comes from. And here s why. If you like what we ve done, jump on board and implement it. There s no up- front cost to stand in your way. But, if you think our lead singer writes sappy and wimpy address audi:ng rou:nes, or he can t do address lineages right, go ahead and find some one be`er. By going with OpenSource, we think its just a lot easier for you to review our work and adopt it or extend it if you want. 30

31 And when I say extend it, you have a lot of freedom. Want to use different technologies? Want to improve the user interface? Want to take what we ve done and add more capability? Go for it. By choosing an open source approach, we re hoping that other governments will take what we ve done and improve upon it. We re hoping that you take advantage of our hard work, and focus on the parts that need addi:onal improvement. An OpenSource EAS let s you build on the good work we ve done, and keeps you from re- inven:ng (and re- funding) the development of a whole new system. 31

32 Like Bob Dylan, we may not be able to sing. But there s a lot of power in wri:ng a good tune. Just ask Jimi Hendrix, the Byrds. The Ramones, Chrissie Hinde, Beck, and the White Stripes, all bands who covered a dylan tune and made it their own. We re hopeful that something like this could work for an OpenSource EAS. We don t think it makes sense for governments to fund essen:ally the same solu:on on top of proprietary code over and over again. Much be`er to work collabora:vely and improve the solu:on together. We believe that its ul:mately a less expensive, faster, and more sustainable approach. 32

33 For example, if you look at the the code for a good system, its much easier to see how and why an applica:on does what it does. Its easier to add flourishes, if the applica:on does most of what you need. And it s a great star:ng point if you want to do a significant rewrite or reinterpreta:on. The City of SF is currently working through the final details, but expects to release the EAS (with the MAD populated with the city s addresses) under the GPL license. You can talk with Blair for more details a]er our talk. 33

34 The point is, we wanted to create a great system, one that is flexible and adaptable. One that can meet the needs of San Francisco, but is also a great star:ng point for other governments in the Bay Area, California, and beyond. In short, we wanted to build a system that goes to 11. And we re willing to share! 34

35 Ul:mately, the reason we chose to develop the EAS with an Open Source mentality, is that we want to avoid silos of government, just as much as we want to avoid silos of informa:on. Of course, you can develop your own EAS. There s no reason you can t fund your own system. But you ll get a solid, flexible, and scalable system up and running a lot faster and less expensively if you start by extending San Francisco s. Imagine the possibili:es if neighboring governments started using a common system to manage addresses. One that can be customized by anyone, And a nice li`le by- product will be that you ll help reduce the distance between silos 35

36 Finally, just a quick word about myself. I work for Farallon Geographics, a systems integra:on company located in San Francisco. We re focused pre`y specifically on helping our clients use geospa:al data, spa:al analysis, and spa:ally aware technologies to improve their businesses. And by that I mean we work very closely with our clients to ensure that GIS helps improve services and revenues, o]en through producing be`er or more innova:ve products like we ve done with the City of SF. 36

37 Let me end there. Thank you for your a`en:on. And I d be happy to take any ques:ons that you might have. 37