[OSM-dev] Street Addresses with Relations?

[Karl Newman]

On Dec 25, 2007 8:19 AM, Dave Hansen <dave at sr71.net> wrote:
> Andy, thanks for the pointer!
>
> On Mon, 2007-12-24 at 11:30 -0700, Kelly Jones wrote:
> > I'd like to upload 200K+ nodes that weren't obtained from a GPS
> > track. Specifically, the nodes representing every street address in
> > Albuquerque, NM:
> >
> > http://www.cabq.gov/gisshapes/
> >
> > I've confirmed this information is public domain.
> >
> > What's the best way to do this?
>
> Hi Kelly!
>
> Trying to get the street addresses into OSM sounds like a great idea.
> But, I'm not sure the best way to go about it, just yet.  Let's cc the
> dev list where some more of the hard core people are sure to see it. :)
>
> You might want to take a quick look here:
>
> http://wiki.openstreetmap.org/index.php/OSM_Protocol_Version_0.5
>
> to see how relations work.
>
> Is anyone else around using relations to describe street addresses?  I
> have the feeling that just uploading ~200k nodes by themselves won't be
> horribly useful by itself.  My thought is that we should attach the data
> as directly to the other OSM objects as possible.  Perhaps give a
> relation with a src and destination node in a way and an associated
> address range.
>
> Kelly, could you give us an idea of how your data is organized?  Is it a
> gps coordinate for each individual address, or is it more in ranges?
>
> -- Dave

Dave,

I'm in active debate about this on the Wiki. The proposal page is a
mess, and I'm tempted to wipe it out and start over. Anyway, look at
my suggestion here:
http://wiki.openstreetmap.org/index.php/Proposed_features/House_numbers#Third_Suggestion_.28Using_relations.29

My perspective on this is getting numbering to work on existing GPS
navigation devices (specifically Garmin). What I've proposed is
compatible with the requirements for that. I don't like the idea of
ranges because it could (will) lead to overlapping ranges, data
duplication at the endpoints, etc. Ranges just make it more
complicated than it needs to be.

Karl