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

Johan C osmned at gmail.com
Wed Oct 22 23:01:50 UTC 2014


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

Cheers, Johan
aka It's so funny
The Netherlands

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

> Thanks Jason, these are useful points.
>
> On 10/22/2014 06:59 AM, Jason Remillard wrote:
>
>> Hi Matt,
>>
>> - It is not clear if including the ids is useful. You should consider
>> dropping them.
>> - Why only put the id on the buildings, but not the address nodes.
>>
>
> 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.
>
> 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 data.nola.gov.
> 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.
>
> 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.
>
> 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?
>
> 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.
>
> 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.)
>
> I am not wedded to this idea. I am willing to drop the building IDs from
> the import.
>
>  - Consider figuring out how to capture multiple addresses at the same
>> node location, rather than dropping them in favor of the primary
>> address.
>>
>
> 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).
>
> 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"
> ?
>
> 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.
>
> 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.
>
>  - You might want to double check that you have captured all of the
>> abbreviations. It seems like this is always a problem.
>>
>
> Eric Ladner brought this up in more detail, I'll address it in a response
> to his message.
>
>  - Have you down a JOSM verify in places where there are many touching
>> buildings? Again, this seems like it is always a problem/tricky issue.
>>
>
> 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.
>
> There are a small number of self-intersecting ways which are easily
> corrected.
>
>  - Do you have any addresses data to conflate with?
>>
>>
> 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.
>
> 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.)
>
> 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.
>
> Matt
>
>
> _______________________________________________
> 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/20141023/755c05b4/attachment.html>


More information about the Imports mailing list