<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 color="#000000" face="sans-serif"><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><div><font color="#000000" face="sans-serif"><br></font></div><div><font color="#000000" face="sans-serif">Cheers, Johan</font></div><div><font color="#000000" face="sans-serif">aka It's so funny</font></div><div><font color="#000000" face="sans-serif">The Netherlands</font></div><div><br></div><div class="gmail_extra"><div class="gmail_quote">2014-10-22 23:23 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">Thanks Jason, these are useful points.<span class=""><br>
<br>
On 10/22/2014 06:59 AM, Jason Remillard wrote:<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">
Hi Matt,<br>
<br>
- It is not clear if including the ids is useful. You should consider<br>
dropping them.<br>
- Why only put the id on the buildings, but not the address nodes.<br>
</blockquote>
<br></span>
I realize these ID numbers are controversial, I appreciate the thoughts from you and the others who spoke up about this question. I am quite aware of how imports can bloat the OSM database with useless tags, so I agree with the general consensus that we should keep tagging minimal in these imports.<br>
<br>
I do want a way to keep the data up-to-date. The addresses shapefile is updated weekly (most recently on Monday of this week) on <a href="http://data.nola.gov" target="_blank">data.nola.gov</a>. In fact, I only just now noticed that their latest update changes a filename which breaks my Makefile in the import scripts. Oops, I'll fix that now.<br>
<br>
So the address data is definitely being updated often. The city is constantly processing building permits, property tax assessments, and a number of other routine things which then gets pushed to the GIS system. Unfortunately the building outlines are not updated quite so often, although there have been updates: I see building outlines in there for buildings I know constructed within the past year.<br>
<br>
You're right that only putting IDs on buildings and not on address nodes was an oversight. Unfortunately there does not seem to be any consistent mapping between the building IDs and the corresponding address points. So when I merge buildings and addresses, which do I use?<br>
<br>
Address points have a "BUILDID" which does not correspond with the "OBJECTID" on the building outline. The only thing they have in common is a "GEOPIN" which apparently is derived from the coordinates. I'm not familiar with this GEOPIN, has anyone here seen this? It doesn't look useful to me.<br>
<br>
I agree it is possible they might not be useful in the future. But I was hoping they might. I will admit that part of the reason I included the building ID tag is that I was using the nycbuildings and dcbuildings source code as a starting point, and both of those imports included the ID tags. (Those IDs are still in OSM today, I also noticed. And only on buildings, not address nodes.)<br>
<br>
I am not wedded to this idea. I am willing to drop the building IDs from the import.<span class=""><br>
<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">
- Consider figuring out how to capture multiple addresses at the same<br>
node location, rather than dropping them in favor of the primary<br>
address.<br>
</blockquote>
<br></span>
I'm not sure how to go about this. I think the case where there is one building and one address, the behavior is correct (add tags to building area). I think the case where there are two (or more) addresses within a building outline but in different locations, the behavior is correct (add separate nodes in distinct locations).<br>
<br>
But the case with multiple addresses in the exact same location? What is my alternative? I think generating multiple nodes in the same location is a poor choice (and of course will not pass the JOSM validator). Then what? Add more tags to the same node? I've seen lots of name_1, name_2 etc from the TIGER import and I'm not a big fan. Would I create "addr:housenumber_2" ?<br>
<br>
Fortunately I never have to flip a coin, only one address is considered "primary" in the upstream data. So in this case, I go with that one. I think it's the best alternative given the situation.<br>
<br>
Another good thing is that the uploading is being done by locals who can correct errors. I already plan to do this in my own neighborhood, and other parts of the city I know well.<span class=""><br>
<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">
- You might want to double check that you have captured all of the<br>
abbreviations. It seems like this is always a problem.<br>
</blockquote>
<br></span>
Eric Ladner brought this up in more detail, I'll address it in a response to his message.<span class=""><br>
<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">
- Have you down a JOSM verify in places where there are many touching<br>
buildings? Again, this seems like it is always a problem/tricky issue.<br>
</blockquote>
<br></span>
I have done a JOSM verify on several different sections of the city. To my surprise there aren't many things caught. In the oldest, densest part of our city (the French Quarter) I found a few places where overlapping buildings were caught by the validator. But in most parts of the city, buildings are detached and don't come close to intersecting.<br>
<br>
There are a small number of self-intersecting ways which are easily corrected.<span class=""><br>
<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">
- Do you have any addresses data to conflate with?<br>
<br>
</blockquote>
<br></span>
Using an XAPI query I have extracted all existing ways and nodes in the area with addr:housenumber tags. The situation is similar to what I outlined with existing building=yes tags.<br>
<br>
There are 119 ways and 990 nodes with addresses today. The ways are all buildings which I already analyzed and put on the wiki (clustered in a few small areas and easily merged). The nodes are mostly POIs that will be kept, I'll make sure the workflow docs indicate that uploaders need to check for duplicate addresses and remove the imported ones when there are already existing. (Does JOSM validator check for two nodes with the same addr:housenumber value? It isn't necessary wrong for two different nodes to share an address, but I think it would be nice to get a warning.)<br>
<br>
I'll also note that of those 119 ways and 990 nodes, 45% were created by wegavision (confined to a small part of the French Quarter, which we already plan to keep). 21% were created by me. 5% were created by Eric Ladner. All other users are under 5%. I will continue to reach out to users who have mapped here previously to see if they're willing to help with uploading and merging their own data with the import. This method has already yielded several volunteers. More eyeballs on the data to be imported makes this conflation trivial.<span class=""><font color="#888888"><br>
<br>
Matt</font></span><div class=""><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
Imports mailing list<br>
<a href="mailto:Imports@openstreetmap.org" target="_blank">Imports@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/imports" target="_blank">https://lists.openstreetmap.<u></u>org/listinfo/imports</a><br>
</div></div></blockquote></div><br></div></div>