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

Gertjan Idema g.idema at zonnet.nl
Wed Oct 29 10:29:00 UTC 2014


Matt,

The principle dividing up multiple addresses on the same location within
the building is quite simple.
If there are multiple addresses on one location within a building I do
the following.

1. Sort the addresses by postcode, street, house number.
2. Determine the angle of the line pointing from the address location to
the center of the building.
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.
4. Iterate over the address nodes and add  (i * delta x) to the x
coordinate an (i * delta y) to the y coordinate.

If the address location is at the center of the building, I set the
angle to 0.

Gertjan Idema


On Sun, 2014-10-26 at 23:20 +0100, Johan C wrote:
> 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
>         > 
>         > 
>         > 
>         > 
>         
>         
>         
> 
> 
> 
> 
> _______________________________________________
> Imports mailing list
> Imports at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20141029/f4fe5c52/attachment.html>


More information about the Imports mailing list