AI features contain self-intersections and spurious connections
bos opened this issue · 9 comments
Description
I'm frequently encountering an issue where AI-detected features have their geometry mangled.
The pattern appears to be as follows.
Two pieces of "road" aren't connected properly into a single piece, but instead have a spurious "jaggy" line segment connecting the pieces in a way that doesn't make sense. Sometimes the jaggy can be hundreds of meters long and result in visually confusing geometry.
It is often difficult to visually understand how to break the correctly-connected pieces apart, delete the jaggy, and then connect them back together properly.
I'm going to leave this example unedited so that you can see it on the live map. It's also captured in the screenshot below.
Screenshots
Version
2.4.0
What browser are you seeing the problem on? What version are you running?
Safari v18.0
The OS you're using
mac
Steps to reproduce
There's no obvious cause for why some roads have jaggies while most don't.
The browser URL at the time you encountered the bug
The auto-detected useragent string for your browser (leave blank if you're manually filling this form out)
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.0 Safari/605.1.15
I encountered the same hundreds of time. I guess this is unavoidable as how the AI recognize the paterns in the imagery. Plus all imagery used for the AI process was Maxar, no longer available to OpenStreetMap so AI needs to be updated to be with Bing or Esri.
Hundreds of buildings are not show neither recognized because the Maxar imagery was quite old..
Thanks for reporting @bos this is also some other issues, #1313 and #1426
It has been pretty frustrating for me too.
This relates back to the issue you reported on #1288 and the related commits 57db299 and c515b7f
The root cause is that the service that we fetch the road data from splits them up into pieces, and it does this in a way that is non deterministic (sometimes the pieces contain different segments, sometimes the segments are drawn in opposing directions even). This means Rapid is forced to try to piece them back together, and that's not always possible. The best fix would be for the service to just send us the complete road geometry (same as how Esri and OSM sources do).
Here's a visual of the issue around the place in the screenshot:
The AI roads cross zoom 16 tile boundaries.. So you can imagine that each of those squares is a separate https request to the service, and imagine that the service returns back 4 different versions of the road and that don't agree. The 4 requests might even be handled by different servers.
"Just give me the whole road in the response" is a thing I've been asking for years.
I'll ask around and see if there is anyone that can assist.
(cc @eneerhut)
Ah, I see, this is a design flaw in the interaction between back end and UI. Thank you for describing, I can see how it would be tricky to address.
@bhousel will see if there is appetite for a whole revisit of the AI road generation layer. Sounds like the backend would need revisiting too, so this is no small task and a lot of the original team are working on different projects.
@bhousel will see if there is appetite for a whole revisit of the AI road generation layer. Sounds like the backend would need revisiting too, so this is no small task and a lot of the original team are working on different projects.
I do think this is worth investigating. If the server breaks up the roads this way, it will be a problem for sidewalks too.
I've investigated this issue for the as-yet-unreleased footways layer and we are going to take take a different approach to serving the footways. Rather than having the conflation service split the footways along tile borders (as @bhousel mentioned above) and letting Rapid reassemble it, Instead we'll simply return all the roads that intersect with a tile. If Rapid encounters a duplicate road, it can drop it knowing that it already has the full road shape.
This should give us greater accuracy and lower service request latency, simpler code at both client/server side since we're no longer doing splitting/reassembly, but at the cost of serving more data than we strictly need for each tile. I think that's a fine tradeoff to make. Data is cheap- mapper time is not!
Over time, if this approach proves itself we can investigate doing the same thing with the AI Roads. That may be a bit tougher as roads can be much much longer than footways on average, so we'd have to split the difference between 'serve the entire road shape' and 'split along tile border and make reassembly hard'.