<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014-10-23 2:20 GMT+02:00 Matt Toups <span dir="ltr"><<a href="mailto:mtoups@cs.uno.edu" target="_blank">mtoups@cs.uno.edu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>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></div></div></blockquote><div><br></div><div>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></div><div><br></div><div>Cheers, Johan</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div>
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!<span class=""><font color="#888888"><br>
Matt<br>
</font></span><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!<span class=""><br>
<br>
On 10/22/2014 06:01 PM, Johan C wrote:<br>
</span></div><span class="">
<blockquote type="cite">
<div dir="ltr">
<div style="font-family:arial,sans-serif;font-size:13px">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:</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br>
</div>
<div style="font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(0,0,0);font-family:sans-serif;line-height:19.2000007629395px">1.
</span><span style="color:rgb(0,0,0);font-family:sans-serif;line-height:19.2000007629395px">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?</span></div>
<div style="font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(0,0,0);font-family:sans-serif;line-height:19.2000007629395px"><br>
</span></div>
<div style="font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(0,0,0);font-family:sans-serif;line-height:19.2000007629395px">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 </span><span style="color:rgb(0,0,0);font-family:sans-serif;line-height:19.2000007629395px">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.</span><span style="color:rgb(0,0,0);font-family:sans-serif;line-height:19.2000007629395px"> 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.</span></div>
<div style="font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(0,0,0);font-family:sans-serif;line-height:19.2000007629395px"><br>
</span></div>
<div style="font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(0,0,0);font-family:sans-serif;line-height:19.2000007629395px">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</span></div>
<div style="font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(0,0,0);font-family:sans-serif;line-height:19.2000007629395px"><br>
</span></div>
<div style="font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(0,0,0);font-family:sans-serif;line-height:19.2000007629395px">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.</span></div>
<div style="font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(0,0,0);font-family:sans-serif;line-height:19.2000007629395px"><br>
</span></div>
<div style="font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(0,0,0);font-family:sans-serif;line-height:19.2000007629395px">5.
Do you have zip codes which enables you to use
addr:postcode?</span></div>
<div style="font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(0,0,0);font-family:sans-serif;line-height:19.2000007629395px"><br>
</span></div>
<div style="font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(0,0,0);font-family:sans-serif;line-height:19.2000007629395px">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.</span></div>
<div style="font-family:arial,sans-serif;font-size:13px"><br>
</div>
<div style="font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(0,0,0);font-family:sans-serif;line-height:19.2000007629395px">7.
I can recommend Geofabrik inspector as a QA tool to align
names of streets to streetnames in addresnodes: </span><font face="sans-serif" color="#000000"><span style="line-height:19.2000007629395px"><a href="http://tools.geofabrik.de/osmi/?view=addresses&lon=10.75140&lat=59.91387&zoom=14&overlays=street_not_found" target="_blank">http://tools.geofabrik.de/osmi/?view=addresses&lon=10.75140&lat=59.91387&zoom=14&overlays=street_not_found</a></span></font><br>
</div>
<br>
</div>
</blockquote>
<br>
</span></div>
</blockquote></div><br></div></div>