[Imports] [Imports-us] New Orleans: importing buildings and addresses

Matt Toups mtoups at cs.uno.edu
Thu Oct 23 00:20:05 UTC 2014


Johan, thank you for the kind words. Preparing this import was 
difficult, often tedious work!

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.)

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.

Unfortunately there are no ZIP codes in the address data set.

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.

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!

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.

Thanks!
Matt

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!

On 10/22/2014 06:01 PM, Johan C wrote:
> 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:
>
> 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?
>
> 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.
>
> 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
>
> 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.
>
> 5. Do you have zip codes which enables you to use addr:postcode?
>
> 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.
>
> 7. I can recommend Geofabrik inspector as a QA tool to align names of 
> streets to streetnames in addresnodes: 
> http://tools.geofabrik.de/osmi/?view=addresses&lon=10.75140&lat=59.91387&zoom=14&overlays=street_not_found
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20141022/6536b22e/attachment-0001.html>


More information about the Imports mailing list