<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/4.2.2">
</HEAD>
<BODY>
Matt,<BR>
<BR>
The principle dividing up multiple addresses on the same location within the building is quite simple.<BR>
If there are multiple addresses on one location within a building I do the following.<BR>
<BR>
1. Sort the addresses by postcode, street, house number.<BR>
2. Determine the angle of the line pointing from the address location to the center of the building.<BR>
3. From the angle and the desired distance between the address nodes, calculate a delta x an a delta y. Either or both may be negative.<BR>
4. Iterate over the address nodes and add  (i * delta x) to the x coordinate an (i * delta y) to the y coordinate.<BR>
<BR>
If the address location is at the center of the building, I set the angle to 0.<BR>
<BR>
Gertjan Idema<BR>
<BR>
<BR>
On Sun, 2014-10-26 at 23:20 +0100, Johan C wrote:
<BLOCKQUOTE TYPE=CITE>
    2014-10-23 2:20 GMT+02:00 Matt Toups <<A HREF="mailto:mtoups@cs.uno.edu">mtoups@cs.uno.edu</A>>:
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        Johan, thank you for the kind words. Preparing this import was difficult, often tedious work!<BR>
        <BR>
        It sounds like you are in favor of keeping the building ID tags, but no ID tags on address points, which is exactly how it works currently. (Of course, others disagree. I'm glad to hear a variety of opinions on the subject.)<BR>
        <BR>
        I'm not sure I see the value in adding the exact same addr:city tag to all of the 100000+ addresses I'm working with. I'm trying to keep the size down. I can trivially add this later though, if it is desired.<BR>
        <BR>
        Unfortunately there are no ZIP codes in the address data set.<BR>
        <BR>
        The idea of dividing up multiple addresses on the same location within the building is interesting. Is the source code for that available? I'd like to check it out.<BR>
        <BR>
        Fortunately it is not a common case so I hesitate to invest even more time into it. But if somebody has already solved this, great!<BR>
        <BR>
        <BR>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BR>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    Matt, the code for dividing up multiple address nodes with exactly the same LAT/LON coordinates is programmed somewhere (I don't know the exact spot) in this JOSM plugin code: <A HREF="https://github.com/gidema/josm-openservices">https://github.com/gidema/josm-openservices</A>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BR>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    Cheers, Johan
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
     <BR>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        That geofabrik tool is great, thanks. I see that it looks like the majority of existing, pre-import addr tags in my city are flagged by the tool now. In all of the cases I've seen so far, it is due to inconsistencies in the expansion of street type abbreviations. Hopefully during our import, the expanded addresses will replace these. I'll make a note for our importers to pay attention to this.<BR>
        <BR>
        Thanks!<BR>
        <FONT COLOR="#888888">Matt</FONT><BR>
        <BR>
        ps: I just added the geofabrik link to our OSM wiki page. Of course I had to solve reCAPTCHA to save the wiki, so it looks like I just performed some addressing labor for Google... while working on my OSM addressing import!<BR>
        <BR>
        On 10/22/2014 06:01 PM, Johan C wrote:<BR>
        <BR>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <BLOCKQUOTE TYPE=CITE>
            Matt, compliments to you and the others in the New Orleans community to do the valuable job of importing addresses and buildings. Some questions and recommendations:
        </BLOCKQUOTE>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <BLOCKQUOTE TYPE=CITE>
            <BR>
            <BR>
        </BLOCKQUOTE>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <BLOCKQUOTE TYPE=CITE>
            1. In OSM it's common either to attach addresses/poi's to single building outlines (if the complete building with all floors has one address/poi) or to have them as separate nodes. Depending on local communities imports can either choose to attach nodes to building outlines or to import them as single nodes. Two factors can be important in that decision: 1) when the nola address data contains information on the entrance of a building, because it's located on or near the entrance, it would be a waste to throw away that useful info by merging that address data to the building outline without setting an entrance tag 2) you write that the nola updates of building outlines have a different frequency than the updates of addresses. Will merging address data to buildings make the update process in OSM more difficult?
        </BLOCKQUOTE>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <BLOCKQUOTE TYPE=CITE>
            <BR>
            <BR>
        </BLOCKQUOTE>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <BLOCKQUOTE TYPE=CITE>
            2. For the updates of building outlines I can imagine that you are using ID's. OSM has no tool around yet that is able to compare OSM building outlines semi-automatically to an updated government database. A second problem is that due to various reasons (like the specialized OSM QA tools a government doesn't use) the building shapes in OSM have a good chance to vary a tiny bit from a government dataset. The - hopefully somewhere in the future to be built - tool will have to deal with these minor geometry differences in order to keep updates, after an energizing initial import, fun for mappers. Although it's true that ID's can be changed, it's the only thing available yet to assist in semi-automatic updates of building outlines.
        </BLOCKQUOTE>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <BLOCKQUOTE TYPE=CITE>
            <BR>
            <BR>
        </BLOCKQUOTE>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <BLOCKQUOTE TYPE=CITE>
            3. Address data in my opinion does not require ID's, because addresses should be unique in themself by the combination of addr:housenumer and addr:postcode
        </BLOCKQUOTE>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <BLOCKQUOTE TYPE=CITE>
            <BR>
            <BR>
        </BLOCKQUOTE>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <BLOCKQUOTE TYPE=CITE>
            4. It's quite normal in recent imports to add addr:city. Not from a computerized point of view (technically it can be derived from a boundary), but more from a mappers perspective.
        </BLOCKQUOTE>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <BLOCKQUOTE TYPE=CITE>
            <BR>
            <BR>
        </BLOCKQUOTE>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <BLOCKQUOTE TYPE=CITE>
            5. Do you have zip codes which enables you to use addr:postcode?
        </BLOCKQUOTE>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <BLOCKQUOTE TYPE=CITE>
            <BR>
            <BR>
        </BLOCKQUOTE>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <BLOCKQUOTE TYPE=CITE>
            6. About the multiple addresses on the same node: I would never drop addresses. The idear is that more people start using OSM because it's better than other comparable datasets, like TomTom or Google. When these new users search an address, it would be frustrating when that address does not show up in their smartphone app. Frustrating enough to turn to Google/Here etc again. We had the problem of multiple addresses on the exact same LAT/LON location in the Netherlands import. Because we had the luck of a great guy in our community with programming skills he managed to automatically divide these 'nodes on top of each other' within the building outline. So, this is also a tool question. And thus solvable.
        </BLOCKQUOTE>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <BLOCKQUOTE TYPE=CITE>
            <BR>
            <BR>
        </BLOCKQUOTE>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <BLOCKQUOTE TYPE=CITE>
            7. I can recommend Geofabrik inspector as a QA tool to align names of streets to streetnames in addresnodes: <FONT COLOR="#000000"><A HREF="http://tools.geofabrik.de/osmi/?view=addresses&lon=10.75140&lat=59.91387&zoom=14&overlays=street_not_found">http://tools.geofabrik.de/osmi/?view=addresses&lon=10.75140&lat=59.91387&zoom=14&overlays=street_not_found</A></FONT><BR>
            <BR>
        </BLOCKQUOTE>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <BLOCKQUOTE TYPE=CITE>
            <BR>
            <BR>
        </BLOCKQUOTE>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BLOCKQUOTE>
        <BR>
        <BR>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <BR>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<PRE>
_______________________________________________
Imports mailing list
<A HREF="mailto:Imports@openstreetmap.org">Imports@openstreetmap.org</A>
<A HREF="https://lists.openstreetmap.org/listinfo/imports">https://lists.openstreetmap.org/listinfo/imports</A>
</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>