ArcGIS Pro Conflation short fall?

[SalemOR_BAP]

I have directional road linework. Conflation refuses to transfer attribution to both linework features...only the closest even though both are clearly within the search distance. Fat grey is Source. Red & thin black are Targets. The black Target is the one that received the attributes. The red received none. My search distance is 100' and the greatest distance from the Source to target missed is <50'. My entire state network shows this issue. Conflation seems to 'stop' for an area once is finds the first match. Suggestions? Thanks all. Greatly appreciated.

Spatial join is too messy in the metro areas with all the crossing highways & ramps. The results are too invalid.

[SalemOR_BAP]

I would say this is correct linework. Because the linework is directional, for example, the westbound could be of different length than the eastbound. I couldn't guarantee without detailing myself, but if the linework was offset, I believe this would present itself. Because westbound/eastbound overlap (product of transportation software as segments go from node-to-node), as you select & highlight you are capturing both directions and it appears to be overlapping segments when in fact, if offset, they really aren't.

Other than a split roadway (couplet or such where there is a clear division between roadway1 and roadway2), all transportation linework is like this.

[SalemOR_BAP]

Good morning.

I'm finding segments that are not conflating and when I look closely they clearly are within the search distance I requested. My thought was, depending on which direction the conflation is taking place through the code, the end of the segment Arc come across first was out of my requested boundary so skipped. However, I look at the other end of the segment and it too is well within the conflation search distance. 

Is there anywhere I can see/learn of the algorithm taking process? If I understood what processes are taking place (and in what order) it might make sense for these misses and I could possibly counteract somehow.

Greatly appreciated  🙂  bap

[DanLee]

Thanks for your confirmation about the duplicate and overlapping features. 

It seems your source data have nodes at intersections while target data don't have nodes at overpasses and underpasses.  When it comes to feature matching, which ultimately is the basis for attribute transfer, it's hard to make the decision, for example in the following location of your data:

The two target features 1317 and 1914 go through the intersection. The sources features 3393 and 3394 are much longer features and both of them may see the two target features as matching candidates. Which one should match the two targets?  Or should the two targets not be matched due to the ambiguity? Do you wish the source features be split at the red arrow locations so they may have better correspondences to the two targets?

You mentioned some features not being conflated even when they are within search distance. Could you point to the specific features in the shared data so I can take a look?

Regarding the in-house algorithm, we don't really describe it in the tool reference. I appreciate your thought on counteract. But I don't see how easily something can be done beyond the general behavior I already described - currently if multiple candidates are found, only one of them is matched, not the duplicate ones. Your iteration workflow makes sense.  If you have specific cases for me to look into, I'd be happy to do so. If you prefer, we can discuss your data specific cases offline; feel free to email me at dlee@esri.com.