[Talk-us] Address Standard
BLord-Castillo at stlouisco.com
Thu Aug 12 21:59:07 BST 2010
I understand that idea. But TigerLine 2010 starts releasing in December, with every state released by February. The main difference between your proposal and adopting the address standard would be that directional and type prefixes and suffixes would be broken out from each other and from informational prefixes and suffixes. That's a small subset of streets to worry about, but it will mean that streets will actually match up to the new tiger data, rather than having to manually rematch all of those.
Or, we could just forgot about using TigerLine 2010, which I think would be a mistake.
Information Systems Designer/GIS Programmer
St. Louis County Police
Office of Emergency Management
14847 Ladue Bluffs Crossing Drive
Chesterfield, MO 63017
From: Kevin Atkinson [mailto:kevin at atkinson.dhs.org]
Sent: Thursday, August 12, 2010 3:54 PM
To: Lord-Castillo, Brett
Cc: 'talk-us at openstreetmap.org'
Subject: RE: [Talk-us] Address Standard
On Thu, 12 Aug 2010, Lord-Castillo, Brett wrote:
> The vast majority of street addresses are only going to have only four elements:
> 126.96.36.199 Address Number
> 188.8.131.52 Street Name Pre Directional or 184.108.40.206 Post Directional
> 220.127.116.11 Street Name
> 18.104.22.168 Street Name Post Type or 22.214.171.124 Street Name Pre Type
> That's hardly a significant burden and easily understood by most people. If the other elements don't exist, you don't use them at all. Like I said, it's a tag based model, not a table based, so you don't even need to enter nulls for the other elements.
> The complex elements do not have to be entered either, since they are all compositions of the simple elements. All the other 12 elements are only entered for the rare addresses that use them.
My point I was trying to make was that it still more trouble than just
entering in a single name, and, in my view, not worth the extra complexity
in data entry.
I think that these components should be automatically separated by parsing
the street name some how, and only require manual entry when there is
ambiguity. When there is ambiguity, I think just entering in the Street
Name (base type in tiger) will be enough.
> As I said, the important thing here is that this is likely to be the
> FGDC standard soon, and looks to be the format for TIGER 2010 and
> subsequent updates.
The point as I was trying to make is that I personally don't want to deal
with them in my proposal for prefixes and suffixes. I want to push
something simple though which can get used now. At a latter date we can
decide if we should fully break out the address and how to use it.
Also my proposal is more about what should be displayed as the street
name on the map, and less about a full breakout. I will redo my proposal
to make that more clear, and also to make sure it is not incompatible with
a future move to a full breakout.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Lord-Castillo, Brett.vcf
Size: 378 bytes
Desc: Lord-Castillo, Brett.vcf
More information about the Talk-us