In the image you can see where the two roads meet there is a gap. This is due to my code drawing the two roads as separate polylines. I create a test renderer to see if this could be improved:
This version has joined the two roads together, drawing only one polyline for both of them. This results in a smooth join, and also a reduction in the number of objects. For example joining roads where they share a start and end point reduces the number of objects for south-west London from ~40k to ~30k. So not only does it create nicer looking maps, it makes them less memory intensive.
It occurs to me that this technique could be used for any Xaml consisting of multiple lines, as my findings suggest that Silverlight performs faster (one poly line with a 1,000 segments is faster than 1,000 single line segments)
My join algorithm is brute forced within a tile (creating an O(n2) complexity) which won't do for release code. So I will write a smarter version - hopefully of the order of O(3n).
I also spotted that a lot of ways within OSM are artificially split (the river Thames for example) I don't know if this is a feature of data collection or policy. My QuadStore design can cope with large entities like the river Thames quite easily - so applying this same technique at a higher level may generate smooth maps overall.
1 comment:
There are elements of both: any time a segment does not share some tag or relation with its neighboring segment, it needs splitting. In the case of coaslines (which include many river segments) and some other very long ways (such as some borders), it is an issue of policy (long ways cause issues in editing, and the coastlines are a completely separate process in the Slippy map, though I have no idea how it actually works.)
Post a Comment