Simplification approach

[martinfleis]

I did some unstructured playing with momepy, osmnx and cityseer and wanted to step back to give a thought to the approach to simplification we shall probably adopt. Below are some initial thoughts that may (or may not) guide the work.

Simplification approach

1. Be conservative - when there's a chance that the change results in more erroneous network than you started with, stop.
2. Start small - focus on small and easy changes first. Small, simple intersections, roundabouts, easy parallels.
3. One size does not fits all - when dealing with parameters, their values are geographically sensitive
4. Be explicit about the change - some situations may be solved by more algorithms. But when you want to snap to a centroid in case of a roundabout, you don't want it in T-shaped intersection. Apply change only when it does what you want it to do, not when it "also simplifies this".
5. Don't waste energy on spaghetti - large highway interchanges are pain and it is often questionable what to do with those. For many use cases, like urban form analysis, they are also largely irrelevant. There are no buildings, blocks and open spaces there. You can ignore it and not much will happen.
6. Order matters - simplification is a sequence of steps. It matters which will be done first and which second. Think twice to figure out if node consolidation precedes T-shape resolution or vice versa.

Some comments on that.

Point 1 is what I've seen happening with both osmnx and cityseer. The algos have a tendency to overdo things in certain locations. Think of the dense network snapped to a single point in osmnx method.

Point 2 is more to slow down my own ambitions :D.

Point 3 is what we've already extensively discussed and what is not covered by existing tools at all (research gap)

Point 4 is aimed at attempts to solve everything with one algo - parenx case.

Point 5 is something we need to keep in mind all the time. Spaghetti intersections are everywhere but even when they are super visible, they may not be relevant to a use case.

Point 6 is clear I suppose. See cityseer and their thoughts on the order and repetition. It clearly matters.

All of this may be obvious but it helps me to clarify the goals before getting to coding. And it allows me to filter out useful existing tools from less useful.

Thoughts? Especially from @anastassiavybornova and @jGaboardi but also interested what others think. Maybe @Kryndlea and @dancejod may have insights derived from their manual simplification?

[jGaboardi]

@martinfleis Can you give a concrete example of the T example is (1)? While I understand the scenario, it would be very helpful for clear case to visualize, especially going forward into a paper or presentation.

[martinfleis]

For example these 3 at -36.8897222, 174.7512042 are nice T examples. You can process this with osmnx and get rid of that. But as a result, the new intersection will be in the centroid of the enclosed shape, hence breaking the continuity of the main street.

This is how @Kryndlea correctly simplified this case:

And this is a result of osmnx simplification using a small tolerance:

Larger tolerance snaps the two on the bottom together but the one above shows exactly my point. While this algorithm will work for a roundabout, here it causes another trouble and, for example, momepy.COINS would be completely irrelevant on a network with these.

[jGaboardi]

Both related & unrelated at the same time is my approach on tigernet during my dissertation, which never came to fruition for many reasons:

• it was written specifically for my dissertation
• it was written specifically for TIGER/Line – only USA
• it's generalizable, but very location/county specific – edge cases broke the algo
• it's a beast and hasn't really been touched in 5 years

However, some meta concepts might be of interest to us:

• description in README – steps 3-7
• description in dissertation – Chapter 1 :: Section 1.2 :: Process 1.1
• example – cells 4-8

Please don't judge me on this LOL. Most of it was written in 2016-2018.