[OSM-dev] Rendering of long roads

Roland Olbricht roland.olbricht at gmx.de
Mon Jan 5 21:27:55 GMT 2009


> == 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




More information about the dev mailing list