<html>
<head></head>
<body> <span dir="ltr" style="font-family:sans-serif">On Fri, May 28, 2021, at 14:00, Jack Arnold via Talk-us-newyork wrote:</span>
<br>
<blockquote style="font-family:sans-serif;margin-top:0;margin-bottom:0" dir="ltr"> <span>Hello again,</span>
<br>
<br> <span>I looked over Hamilton County around Lake Pleasant. Looking great as</span>
<br> <span>usual! The data over there seems simple with few apartment compelexes</span>
<br> <span>or other edge cases.</span>
<br>
<br> <span>My understanding of the conflation is a little bit rusty, but I found</span>
<br> <span>these nodes that don't seem to be correct in Watkins Glen (Schuyler</span>
<br> <span>county):</span>
<br>
<br> <span>Original:</span>
<br> <span><a href="https://www.openstreetmap.org/node/7685157126">https://www.openstreetmap.org/node/7685157126</a></span>
<br> <span>From import:</span>
<br> <span><a href="https://www.openstreetmap.org/node/8759324317">https://www.openstreetmap.org/node/8759324317</a></span>
<br> <span>From import, but housenumber is different:</span>
<br> <span><a href="https://www.openstreetmap.org/node/8759324646">https://www.openstreetmap.org/node/8759324646</a></span>
<br>
<br> <span>The first two nodes look like they should be conflated, as the data is</span>
<br> <span>identical. The third one makes sense, the addr:housenumber tag is</span>
<br> <span>technically different. There are more of these in the same area I</span>
<br> <span>didn't list.</span>
<br>
</blockquote>
<br> <span dir="ltr" style="font-family:sans-serif">Yeah, in this case, there was already a duplicate node in the preexisting data (this is what the review tag "found > 1 existing matching address</span>
<br> <span dir="ltr" style="font-family:sans-serif">" means). There were these two before the import:</span>
<br>
<br> <span dir="ltr" style="font-family:sans-serif"><a href="https://www.openstreetmap.org/node/7685157126">https://www.openstreetmap.org/node/7685157126</a></span>
<br> <span dir="ltr" style="font-family:sans-serif"><a href="https://www.openstreetmap.org/node/7685157097">https://www.openstreetmap.org/node/7685157097</a></span>
<br>
<br> <span dir="ltr" style="font-family:sans-serif">When there are multiple matches for the same address, the importer intentionally does not conflate it, because it is ambiguous which one is the "right one," so instead we mark it for review so a human can figure out which one is right and deduplicate.</span>
<br>
<br> <span dir="ltr" style="font-family:sans-serif">My guess in this case is that this is a rogue import of the same data (either directly or indirectly), and one of the two is actually supposed to be "311 1/2" (which was imported as <a href="https://www.openstreetmap.org/node/8759324646">https://www.openstreetmap.org/node/8759324646</a>) but either the source data from this import did not fill in the pre-address number field for "addr:housenumber", or this RI-Improve user didn't make use of it, creating what looks like a duplicate.</span>
<br>
<br>
<blockquote style="font-family:sans-serif;margin-top:0;margin-bottom:0" dir="ltr"> <span>Similarly, there are a few buildings in Montour Falls (Schuyler county)</span>
<br> <span>where the original contributor only put partial data:</span>
<br> <span><a href="https://www.openstreetmap.org/node/3810205975">https://www.openstreetmap.org/node/3810205975</a></span>
<br> <span><a href="https://www.openstreetmap.org/way/823147605">https://www.openstreetmap.org/way/823147605</a></span>
</blockquote>
<br>
<blockquote style="font-family:sans-serif;margin-top:0;margin-bottom:0" dir="ltr">
<br> <span>More scattered around the block:</span>
<br> <span>https://www.openstreetmap.org/node/3810205974</span>
<br> <span>https://www.openstreetmap.org/way/823147893</span>
<br>
</blockquote>
<br> <span dir="ltr" style="font-family:sans-serif">Yeah, partial data is tricky. In an early iteration of the importer, I actually did fall back to just the house number when it didn't find house number + street, but that led to its own problems where addresses were getting skipped because, sure enough, there were different houses with the same number very close to each other, but they were on different streets. Even worse than skipping it, it could end up filling in the extra missing data on the wrong house because it found 123 B street when it meant to find 123 A street, but the existing element only had the house number. In order to avoid false positives when searching for existing data, we need at least a house number and street to be sure it's the right match.</span>
<br>
<br> <span dir="ltr" style="font-family:sans-serif">So I think in these cases, we have a choice between skipping good data and possibly conflating with the wrong house, or "duplicating" it with another node. Personally I'd rather duplicate it so we don't skip good data, or conflate with the wrong building.</span>
<br>
<br>
<blockquote style="font-family:sans-serif;margin-top:0;margin-bottom:0" dir="ltr"> <span>In Penn Yan (Yates county), more I didn't list:</span>
<br> <span><a href="https://www.openstreetmap.org/node/8766705037">https://www.openstreetmap.org/node/8766705037</a></span>
<br> <span><a href="https://www.openstreetmap.org/way/823227024">https://www.openstreetmap.org/way/823227024</a></span>
<br>
<br> <span><a href="https://www.openstreetmap.org/node/8766705496">https://www.openstreetmap.org/node/8766705496</a></span>
<br> <span><a href="https://www.openstreetmap.org/way/823227003">https://www.openstreetmap.org/way/823227003</a></span>
<br>
<br> <span><a href="https://www.openstreetmap.org/node/8766705350">https://www.openstreetmap.org/node/8766705350</a></span>
<br> <span><a href="https://www.openstreetmap.org/node/8766705421">https://www.openstreetmap.org/node/8766705421</a></span>
<br> <span><a href="https://www.openstreetmap.org/way/823235994">https://www.openstreetmap.org/way/823235994</a></span>
<br>
</blockquote>
<br> <span dir="ltr" style="font-family:sans-serif">These are actually not conflated on purpose because there are several other address points inside the same building. I did this because the location of the point often matters, especially in larger buildings.</span>
<br>
<br> <span dir="ltr" style="font-family:sans-serif">In these cases, I could have chosen to pick the house number that matched and conflate the address point with the building and left the rest of them as points, but the addresses that are on the buildings are not really correct, as it implies that the whole building is that single house number, when it in fact has several. When there is a problem with the existing data, detecting each imaginable problem and deciding what to do would be time consuming, error prone, and not come out great in the effort to benefit ratio; so, generally, I prefer to leave bad data alone and let a human decide what to do with it.</span>
<br>
<br>
<blockquote style="font-family:sans-serif;margin-top:0;margin-bottom:0" dir="ltr"> <span>Also, I found what appears to be a building with many units not</span>
<br> <span>conflated. Would this be correct behavior if they are seperate physical</span>
<br> <span>buildings? If there was a large building under all of them, would it</span>
<br> <span>conflate? Montour Falls (Schuyler county):</span>
<br>
<br> <span><a href="https://www.openstreetmap.org/node/8759325174">https://www.openstreetmap.org/node/8759325174</a></span>
<br> <span><a href="https://www.openstreetmap.org/node/8759325761">https://www.openstreetmap.org/node/8759325761</a></span>
<br> <span><a href="https://www.openstreetmap.org/node/8759324918">https://www.openstreetmap.org/node/8759324918</a></span>
<br> <span><a href="https://www.openstreetmap.org/node/8759324798">https://www.openstreetmap.org/node/8759324798</a></span>
<br>
</blockquote>
<br> <span dir="ltr" style="font-family:sans-serif">This looks correct to me. The one point without a unit looks like the primary address point, and the rest are the locations of the individual units. I chose only to combine units into the primary point when they are all stacked on top of each other, as that doesn't really help anyone. But these unit points show you where each unit is, which is helpful.</span>
<br>
<br> <span dir="ltr" style="font-family:sans-serif">As for buildings, the intended behavior is: in the first phase, address points that are stacked on top of each other, and all have the same house number, get combined if the list of units/floors/rooms can fit into a single tag (otherwise they are left as separate stacked nodes). Then it compares with the existing OSM data. If an address point is inside a building, it only gets conflated in the obvious case: it is the only address point inside the building. If there are multiple address points inside the building, then they are left separate, as they often show reasonably exact locations of units or house numbers within the building.</span>
<br>
<br>
<blockquote style="font-family:sans-serif;margin-top:0;margin-bottom:0" dir="ltr"> <span>As a side note, this holds the record for worst (but correct?)</span>
<br> <span>rendering node I've ever seen:</span>
<br> <span><a href="https://www.openstreetmap.org/node/8759326333">https://www.openstreetmap.org/node/8759326333</a></span>
<br>
</blockquote>
<br> <span dir="ltr" style="font-family:sans-serif">Haha, yeah, Carto doesn't handle list values well. It's useful to render the unit when it's only a single unit, but that utility breaks down when the value is a list of units.</span>
<br>
<br>
<blockquote style="font-family:sans-serif;margin-top:0;margin-bottom:0" dir="ltr"> <span>I know I raise more issues than solutions, but I hope they are helpful.</span>
<br> <span>I'd be willing to manually edit some of these if needed. Excellent work</span>
<br> <span>as always, and I can't wait to see the whole state imported.</span>
<br>
<br> <span>Jack</span>
<br>
</blockquote>
<br> <span dir="ltr" style="font-family:sans-serif">Thanks so much for reviewing the data, it's super appreciated. Hopefully my answers make sense, and sound like reasonable decisions. I'm open to feedback if you have any.</span>
<br>
</body>
</html>