Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
For now till we get some more content
An interesting article on storing addresses. http://stackoverflow.com/questions/7639637/sql-database-design-best-practice-addresses
We should also look at House Facts and what they were proposing to store. I am not suggesting that we use the record layouts. https://sites.google.com/site/housefactsdatastandard/home/specification
Not much of one yet.
- Provision a GIS Server
- Provision a ubuntu Server (on AWS) with Postgresql some instructions
- Create an initial Database that will change many times
- Load test address data to load is Land Bank Parcels from the PAT project.
- Create some restfull API's
- Regroup, change everything, and iterate.
The system will allow people to query information about one or more addresses.
The system will store the following information for an address/parcel:
- Identifiers that other systems use to identify the address/parcel, KIVA PIN, County APN
- Attributes of an address/parcel such as Census Tract, City Council District ...
- Data about an address/parcel, amount paid in taxes, ...
It is intended to answer the following:
- Get a normalized standard address, for example "210 W 19th Ter, Kansas City, MO" standard address might be "210 West 19th Terrace, Kansas City, MO, 64108"
- Return selected identifiers, attributes, and data related to one or more address. This will allow for other
- Get a list of addresses within a radius of a coordinate or other boundary.
In addition with the data we collect for the above we can return other information such as:
- All addresses in a census tract
- Census tracts that are in a neighborhood
- How handle a large number of addresses being returned? Paging? CSV download only?
- Do we want to handle addresses that merge into one and/or addresses that split into more than one.