On Mon, 5 Jan 2009 22:27:55 +0100, Roland Olbricht <[email protected]> wrote: > First of all, I'm grateful for the opportunity to discuss this. I'm faced > to > similar difficulties deriving the national borders from the given boundary > data.
I tried the same and data-quality was horrible. Back then I tried to correct at least the german border but had to stop at the baltic sea. > I think this will be extremely difficult due to the current quality of the > data. There are a lot of inconsistencies in the data more intricate than > just ... I have changed my code to combine the relations into a set of ways instead of a single way. Currently it is relying on the ordered relations of api 0.6 but I will add the code required to puzzle together unordered lists of ways sharing start or end-nodes. This should give me something that can actually be rendered. I don`t care for small holes but I absolutely need to reduce the number of nodes dramatically for realtime rendering. > On the other hand, a lot of strange phenomena are verbatim from reality, > e.g. > - multiple motorway-relations might share the same segment (e.g. A 1/A 61 > in > Germany near Euskirchen) This should be no problem for me but thaks for pointing it out. > - in Belgium, the effective numbering of the motorways is provided by the > European E-numbers instead of the national numbers > - if you take an extract of a single country, you might still find short > sequences of motorway from other countries and thus numbers like "A 1" > might > appear multiple times Good point. For rendering it should not matter but for driving-directions (on the not-simplified map) this can pose issues. >> * Also extend the simplification-algorithm to also remove nodes that are >> too >> near each other even of they introduce a significant course-error. > > I think, the fastest bailout would be to do this and to use sets of > segments > taken from the ways instead of trying to construct long ways. This should > address most of the above issues. Yes, I have come to the same conclusion and written the code last night on the train. It seems to work now but needs more debugging and is highly incomplete. > Another approach might be to let the software silently do clever guesswork > whether something exists in reality, is an unusual way of mapping or simply > > wrong. But this would not give feedback to the mappers for the remaining > errors, and the developed algorithms might not be found by other projects > when they are faced to the same problems. > > A better approach would be something like the coastline error checker - it > gives also feedback to the mappers where to put attention on the map and > correct the data if necessary and how some particular piece of data will > impact on the map. I think such things belong into specialized programs and web-sites and not into the rendering of a navigation-program. I expect that my users want to route from A to B without being distracted by error-messages that have nothing to do with them driving. They are however something we need to care about as mappers for our own quality-assurance. > Maybe in the long run, we could even find a unifying framework for smart > guesswork that incorporates all the given tools (e.g. the coastline error > checker, some monitors of strange tags discussed a few weeks ago and this > software coping with the motorway or area constraints, renderer's style > files > and maybe others). Thus, the mapper will get a comprehensive feedback on > what > is still requiring attention of a particular piece of OSM data without > surfing to half a dozen of different sites with different syntax. I tried to collect all the rules you have to know to do routing and interpretation of the street-network on the following wiki-pages: http://wiki.openstreetmap.org/wiki/Routing http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing If you find any clever rules on how to avoid real-world errors in the map that are not easier to fix then to program around, feel free to add them in a way that can be implemented by others. It would be a great help to any developer. Marcus _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
