[OSM-dev] Rendering of long roads

[marcus.wolschon at googlemail.com]

On Mon, 5 Jan 2009 22:27:55 +0100, Roland Olbricht <roland.olbricht at gmx.de>
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