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-us mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/imports-us
