Well, hang on a tic... I don't know if you can really say, "...no one will
manually enter in all those parts, especially since the distinction would be
meaningless to most people." Just like breaking out the prefix, I think
breaking out the address into a finer granularity makes the address more
useful all around. And I think there's plenty of latent demand for improving
address data in OSM.

I whole-heartedly agree with you though that a large part of the address
standard is beyond most OSM needs. So what parts of the standard can we take
and which can we ignore (for now)? Some months ago I did a quick cross-walk
of the address standard and the Karlsruhe schema. I'll try to dig it out and
update it.

SEJ
----
"Wretches, utter wretches, keep your hands from beans." -Empedocles



On Thu, Aug 12, 2010 at 15:57, Kevin Atkinson <ke...@atkinson.dhs.org>wrote:

> On Wed, 11 Aug 2010, Lord-Castillo, Brett wrote:
>
>  I just want to point out that the federal address standard has passed
>> through the public comment period and is now in committee review. It is
>> expected to become a federal regulation in early 2011.
>>
>> http://www.urisa.org/about/initiatives/addressstandard
>>
>> ...
>>
>>
>> The standard is presented as a tag based model expressed in xml. It
>> would probably be a serious mistake to ignore it. It actually directly
>> addresses (in address data content) all of the issues that are getting
>> hashed over here, and quite a few that have not been brought up yet (like
>> dual and quad number addresses).
>>
>
> I looked it over.  If you really wanted to break out every last possible
> part of a street name it would be a good guideline to follow.  The problem
> is no one will manually enter in all those parts, especially since the
> distinction would be meaningless to most people.
>
> My main goal was to separate out the directional prefix because, which
> while important for mailing, did not really belong as part of the street
> name.  I thought I would take care of the suffix as well.
>
> However, since I now see that there are other, non-directional, prefix and
> suffixes. I might simplify my proposal to simply include any prefix and
> suffixes not included with the displayed street name.  I am also considering
> dropping the "included" provision until such time that all components are
> broken out.
>
>
>
> _______________________________________________
> Talk-us mailing list
> Talk-us@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
>
_______________________________________________
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Reply via email to