search

DataSF / draft-publishing-standards

Draft documentation for DataSF open data publishing standards
https://www.gitbook.com/book/datasf/draft-publishing-standards/details
2 stars 2 forks source link

Comment:Location-Addresses #2

Open samuelvaldez-sfgov opened 7 years ago

samuelvaldez-sfgov commented 7 years ago

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.

jasonlally commented 7 years ago

@samuelvaldez-sfgov Great feedback. I think there's some finessing and nuancing we can do to:

  1. Make some of the guidance more specific and provide examples
  2. Align more to FGDC or in the direction of that and point to that as a recommendation (focusing on maybe core common fields in the documentation and pointing to more robust collateral for all the rest).

And then I think this is a perfect agenda item for the AWG. My aim is not to issue by fiat but rather to leverage what makes sense to solve a real problem around consistency in addresses across different domains and data. And to provide tools to make it easier for people to use the standard and provide visible benefits of doing so!

FGDC represents a very thorough body of work, so I think it's a good thing to put forward to the group.

I'll work up some edits based on your comments and then send you something you can do direct suggestions on in text.