> == The issue == > > Long motorways and coastlines are broken up into > small fragments. It seems that filtering on the > length of the individual way is not enough as > large parts of important motorways are filtered out.
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. > == What I intend to do == > > I would like to combine split-up roads before simplifying them. > This is what I am currently working on and where I am not sure > if my aproach is the best that can be done. 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 zero-way-nodes I tried to obtain "one continuous way per motorway and direction" last september and were faced to several hundred examples of problems like - doubled segments, i.e. a sequence of several subsequent node members in different ways - small holes in the ways, i.e. nodes close to each other or to inner points of another segment such that the ways look like being connected on the map but aren't in fact - ways that are accidentally not contained in the respective relations - ways that are accidentally tagged as motorway instead of motorway_link and vice versa - ways that are labelled strangely or not at all - somebody has mapped a temporary construction site at A 1 near Vechta as a gap in the motorway I don't think these issues have changed much in the last months. And the data for secondary would have got probably even less attention. 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) - there are motorways not connected to the rest of the network, e.g. the A 44 near Hessisch Lichtenau - there are short gaps in the network, e.g. A 52 near Gladbeck, A 516 near Oberhausen or A 46 at junction Wuppertal-Nord - the gap right in between the German A 3 at Kreuz Oberhausen is due to the layout of that junction and is also correct - 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 - there are sections of motorway which are not one-way, roundabouts just in between motorways, exits to the left, parallel sections of the same motorway, motorways that split immediately from each other and maybe other surprises > * 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. 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. 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. Cheers, Roland _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
