Comment:Location-Addresses
Location (addresses)
I have not announced this generally but I am leaning toward promoting the idea of a single, logical, San Francisco Address Database (working title, but arguably could also be EAS, see below*), and promoting that as the City's reference address, or address data, resource.
* Right now, there is some confusion because the EAS Web application is called the Enterprise Addressing System even though it focuses almost entirely on DBI processes, so one idea would be to call the the current EAS something else (like DBI Permit Application) and then give the EAS moniker to the City's new reference address data resource.
As for the content of this section, you could generically refer to the "City's Reference Address Data Resource" as a placeholder, and state that the specific resource would named later.
In terms of guidance for address output, I might move that content from this section to the Address formats section below.
Address components
This is probably going to be contentious but my intent was to attempt to steer the AWG towards the United States Thoroughfare, Landmark, and Postal Address Data Standard, which I reference heavily in the AWG's user stories in JIRA, for example, [AWG-15] Provide Street Name Elements standardization.
What happens right now is that every address data set in the City, including expressions of EAS data, use whatever address fields make sense for their particular use case. The idea behind conforming to a standard is that were source address data at least conceptualized, if not stored, per a standard, then these source address data could be transformed into any other format to support specific use cases. Notably, the FGDC standard includes points-of-interest (called Landmarks), and other address classes, which may not be represented within this document.
Concretely, this entire draft table could be re-worked to reflect the concepts and nomenclature of the FGDC standard, and then that could become one of the first steps toward encouraging stakeholders to talk about addresses and address components using the same language.
Address formats
For the second bullet-point, I could provide several examples (San Francisco addresses that are based upon the FGDC standard) that would serve as concrete illustrations of the goals of the guidance.
The third bullet-point is potentially another source of confusion that could be alleviated by providing some examples. I am not clear on the intent of this specific guidance, so perhaps some elaboration would help.
Comment:Location-Addresses
Location (addresses)
I have not announced this generally but I am leaning toward promoting the idea of a single, logical, San Francisco Address Database (working title, but arguably could also be EAS, see below*), and promoting that as the City's reference address, or address data, resource.
As for the content of this section, you could generically refer to the "City's Reference Address Data Resource" as a placeholder, and state that the specific resource would named later.
In terms of guidance for address output, I might move that content from this section to the Address formats section below.
Address components
This is probably going to be contentious but my intent was to attempt to steer the AWG towards the United States Thoroughfare, Landmark, and Postal Address Data Standard, which I reference heavily in the AWG's user stories in JIRA, for example, [AWG-15] Provide Street Name Elements standardization.
What happens right now is that every address data set in the City, including expressions of EAS data, use whatever address fields make sense for their particular use case. The idea behind conforming to a standard is that were source address data at least conceptualized, if not stored, per a standard, then these source address data could be transformed into any other format to support specific use cases. Notably, the FGDC standard includes points-of-interest (called Landmarks), and other address classes, which may not be represented within this document.
Concretely, this entire draft table could be re-worked to reflect the concepts and nomenclature of the FGDC standard, and then that could become one of the first steps toward encouraging stakeholders to talk about addresses and address components using the same language.
Address formats
For the second bullet-point, I could provide several examples (San Francisco addresses that are based upon the FGDC standard) that would serve as concrete illustrations of the goals of the guidance.
The third bullet-point is potentially another source of confusion that could be alleviated by providing some examples. I am not clear on the intent of this specific guidance, so perhaps some elaboration would help.