Description:

Very similar to previous PR #150. There is an issue with proper tag assignment for synthetic boundary node tagging when a feature is located between country boundaries. In order to capture navigable features extending outside their respective country boundaries (think ferries or bridges), we walk the connected network outside of the country boundary and ingest any such features. The basic logic is to keep a list of nodes that are "node identifiers at network boundary". Each time we walk outside of this network, we grab an edge connected to one of the network boundary nodes, remove that node from the list, add the edge and put its end node back into the network boundary list. This is prone to many different edge cases and the one this PR exposes is the case where the network is walked from two directions. In this case, there are two navigable ways, one coming from the Danish side and the other from the Swedish side. The traversal from the Swedish side stops at this node one, while the traversal from the Danish side stops at a latter one. The result is correct if you're looking at the data with both countries point of view. However, the moment you remove one of the countries (pick Sweden or Denmark), there is an inconsistency. If you're looking at the exact nodes on the boundary of where you expect synthetic boundary node tags to occur, namely: node one and node two - you'll have a synthetic boundary node tag at the top one - because that's where the traversal ended from the Swedish side. However, there will be no synthetic boundary node tag on the bottom one, since the traversal from Denmark's side kept going further. The important note is that we rely on the aforementioned "node identifiers at network boundary" list to accurately place the synthetic boundary node tags, but because the traversal is happening with multiple countries at play, that leads to an inconsistent view when looking from a single country's perspective. This is easily verified if we remove the Sweden boundary from our test file and run with only a DNK boundary.

It's also important to note that this case is handled correctly in the raw atlas flow, so the respective unit test checks for correctness instead of incorrectness, as is the case for the existing flow.

Potential Impact:

No impact here - just adding unit tests to highlight the issue in the existing and raw atlas flows.

Unit Test Approach:

Added two unit tests - one for the old flow and one for the raw atlas flow to test the scenario given 4 ways and dummy Denmark and Sweden boundaries on either side.

Test Results:

N/A

In doubt: Contributing Guidelines