When 3 dual carriageways meet 1 single carriageway

Based on the fix for bus lanes (Breda), sometimes you get funny intersections (Toronto)

There are occasions where one of the two sides of the triangle is missing

In some occasions, a single carriageway won't extend to the other side as it should.

Now we have our own code for snapping the geometry which might sometimes freak out as it makes a few assumptions. It might be worth trying to replace the whole thing using the shapely.ops.snap function which should be reliable. Maybe worth a try.

This is a special case that breaks during trim and extend. During trim, line 0x33b638... follows the last part of 0xb36d95fd..., but it doesn't detect that it intersects 0x2bf785b1... as well. Then, in extend it tries to reach the end of the other side of 0x2bf785b1..., which makes a new branch.

Again more for when we look at how to store in CityJSON, how can we model ramps and overpasses as truly 3D? OSM doesn't store z coords.

Bookmark - Uh Oh

Bookmark - Oops

Bookmark - Pour Discussion

Bookmark - Niet

Bookmark - I like

We don't fix all four-way duals as they should. This occurs a few times in Poznan and remains unresolved. It might be possible to ignore.

Need to ensure connectivity prior to running anything.

Toronto

Many times, one of the two sides of a merge might not snap

We could have a column where we add error/warning codes during the construction process, so we can better track down the minor issues that were dealt as degenerate cases.

There are traffic island holes here which is why the width comes out so small... Maybe we should be more tolerant... or dissolve holes...

Doesn't happen too much, but it happens. If we were using NDW it wouldn't have been much of a problem, because it seems that where BGT does the division, NDW also models individual carriageways.

• We need to preserve flyover information for the final pass where we create nodes
• Match them with the BGT for the road width calculation
• Check for them when snapping or extending

This is more for when we focus again on how to store roads in CityJSON but we need to remember to examine the relationship between roads and bridges and roads and tunnels.

Weird case where trim should work. Needs investigation.

Several false dual roads in Toronto

One of the four sides doesn't intersect with the perpendicular road. This could be ignored for now, as a real degenerate case.

• Fix UUIDs (we could compute bigger ones and convert to string)
• Fix SQL script (add an argument to support other EPSGs)
• Remove CityJSON stuff
• Refactoring (for instance, make EPSG declared once at the beginning)
• Rename stuff away from BGT
• Rename road_width_final_final 🤓
• Export all output as .gpkg instead of .geojson
• Clean-up
  • One pass to remove overlapping parts of roads at an intersection
  • One pass to gather overlapping parts of roads at an intersection in one global array
  • One pass to join the overlapping parts with both attributes and add them to the dataframe
• Brew some nice stats
• Merge the two notebooks
• Four-way duals triangles (as in #13)
• Check the number of edges per connected component
• All the small cleaning mentioned in #10

Long roads should not be affected by very short segments afterwards

There are far more limits to procedural lanes generation than in carriageways. This is because lane have a much more local variability nature than carriageways. For example:

In other words, lanes vary across the same road much more than carriageways. Creating really useful lanes (especially merging lanes etc) requires more detailed width calculation (e.g. a width per segment of the same road) which are also more prone to errors.

Let the script allow the option to be run without calculating road width, and carriageways will just be generated for any dual direction road.

There are probably lines that are there for the network and don't correspond to real roads, and those we should force to be single carriageways.

http://www.geopackage.org/spec120/#extension_metadata

http://www.geopackage.org/guidance/extensions/metadata.html

Helsinki

This line is getting this ugly shape after trim. The reason is that we don't build a straight segment between the intersection of the two lines and the end point, but we try to maintain the original curvature of the line.

We can fix that by checking if something peculiar happens (e.g., in this case the length gets almost twice as long as the original) in which case we fall back to constructing a straight segment.

Step 4:

Step 5:

Already calculated in script:

• Number of road edges in filtered network and final network
• Number of connected components (and the count per component) in filtered network and final network
• Number of road edges in the filtered network that are classified as dual carriageway

Potentially easy to calculate:

• Average length and SD of road edge in filtered network and final network
• Number of nodes in filtered network and final network
• Number of polygons in aerial representation (to use in ratio later)
• Average area of polygons
• Average width and SD

Indicators:

• Number of polygons / number of edges
• Average area of polygons / average length of edges

When a road intersects with a dual carriageway, sometimes it might not be possible to turn both ways because of some physical barrier. I think we should discuss about it as something that is dealt "automatically" since in those cases the dual carriageways will be modelled as two individual single ways in OSM, therefore this is taken care already.

Minor issue: we didn't check if there are cases that are still modelled as a dual carriageway with a single line and there are semantics to denote turning restrictions.

In clean-up

This is really a degenerate case: a line starts at the center of a dual carriageway and normally would have identified as a crossing road and would have been trimmed there. But, in this case, the actual neighbour of 0x63c2d9... is really short, so 0x63c2d9... crosses the next segment, which is not taken into account during the trim processing step.

We now have a solution similar solution for this: we take into consideration the neighbours of the next segment if the current segment length is below 3m. We'll have to do the same here for neighbours, but with a bigger tolerance.

• #3
• make nodes
• new uuids
• recalculate length
• check network connectivity

Why not?

https://stackoverflow.com/questions/18603270/progress-indicator-during-pandas-operations

https://pypi.org/project/tqdm/#ipython-jupyter-integration

Maybe this is extreme, but some roads are already modelled as dual carriageways, not sure if we can identify them? For example in this figure the dual carriageways could be linked? Also in the figure in #5

I hate my life...

It can be overridden by loosing the criteria in such cases.