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

Johan C osmned at gmail.com
Sun Oct 26 22:20:15 UTC 2014


2014-10-23 2:20 GMT+02:00 Matt Toups <mtoups at cs.uno.edu>:

>  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!
>
>
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: https://github.com/gidema/josm-openservices

Cheers, Johan


> 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/20141026/160938df/attachment.html>


More information about the Imports mailing list