[OSM-dev] Traps in vector mapping

Sandor Seres sandors39 at gmail.com
Sat Oct 18 20:23:31 UTC 2014


There are many traps developers meet while developing vector-based mapping
systems. Consequences are errors, some more visible than the others. Just a
few days ago a researcher from Samsung Electronics asked, on the help forum,
a legal question related to OSM licencing ("OSM Developer Licenec" 07 Oct).
In one of the comments, he was adviced to visit a site already funded by
Samsung where they use OSM. So, I did the same and sow the same traps again
(and again). The illustrations and exaples are taken from the demo mapping
system of this site. If interrested, you may find them via this link (or you
may just repeat the same experiments).

https://drive.google.com/file/d/0B6qGm3k2qWHqdW1XYXN6MENpUVE/view?usp=sharin
g

I just thought it might be useful to make a comment/warning to those planing
vector mapping development. Let me emphasize just two, with highly visible
consequences: fragmentation and stripes (brakes/virtual bridges). The source
of these traps are most probably in the data preparation realted algorithms.

An inevitable section of any map data preparation is the scale levels
generation. The vector scale levels are created in radically different
manner and under different criteria compared to the classical raster zoom
levels. Though, many raster mapping systems use vector scale levels as input
for their zoom levels generation. Anyway, the scale levels generation is
unthinkable without the data generalisation which in turn consists of
scaling, vector smoothing and filtering. While the vector scaling is a
straight forward function, the last two functions are much more complex and
as a rule heuristics based. 

When scaling vector data down, the vectors become shorter and the curvatures
less visible. A smoothing algorithm tries to replace series of consequtive
vectors vith a resultant vector without noticeable visual difference. But no
metter which vector smoothing algorithm is used the self-crossings are
practically unawoidable on area borders especially on thinn sections like on
rivers, fjords, channels, peninsulas and so on. Because many fill algorithms
requirer simple closed border lines, smoothing algorithms often use an
additional procedure to avoid selfcrossings. One of the most used is to
divide the area into new independent areas with no selfcrossing borders
(between neighbouring sefcrossing points). In this way, the data
generalisatio creates many small/tiny areas, eventually, in addition to the
set of small areas from the input data. After this, the the filtering/data
reduction algoriyhm ignores many of these tiny (subpixel thinn or sized)
areas and the area connectivity destruction is a fact. For illustration you
can see the the screen-dump (image 1) taken today from the mentioned site.

So, the most probable cause/trap for the connectivity destruction is in the
data generalisation algorithm and in the highly fragmented input geometry
(like the river banks). 

               The second mentioned trap causes thinn stripe errors less
visible in rendering but more confusing and present even in higher scale
(zoom-in) values. For illustration see the image 2 taken from the mentioned
site also today.

Any vector smoothing algorithm (no matter if distance based, surface based,
corridor based .) inherently moves slightly the line geometry
nodes/vertices. So, if adjasent area fractions are processed independently,
a common border section after the smoothing may result in slightly different
poly-line section. In addition, the decimal-to-integer rounding in rendering
may just increase this effect (known from the vectorization, or
raster-to-vector transformation age as the white pixel effect). Note that
the white pixel effect is hard to avoid even in raster based mapping systems
if the source areas are fragmented. Namely, the rounded pixel position
values may be different when a common border vector is AB for one and BA for
the adjasent area in rendering. For illustration see the image 3 made from
the BigMap 2 (toner layer) screen dump today. This blurring effect is
present in most of the raster mapping systems though less visible when light
color shades are used for area decoration/fill (eventually combined with
dithering type of pattern). But this is just hiding/masking the white pixel
effect in raster zomm levels. 

It is maybe worth to note another consequence of the white pixels effect in
raster zoom levels. If you are curious and entusiast, take a raster mapping
system (example gratia Google Maps, Bing Maps, Slippy Map(s).), zoom roughly
to 1:10mill and go to an area with lots of islands/spots (exampel gratia,
south/east part of Finnland in the Baltic sea). You will find large number
of confusing spots with various colour shades between the light blue (the
sea) and light gray (the land) colours. You may even take a screen dump of
that area, load it into an image editor and enlarge it several time for
better proof (see the image 4 created in this way from Google Maps).
Besides that these spots are with undeclared meaning they have also a
considerable impact on the corresponding PNG format's size (need 24 bits, or
more, per pixel at the input side to the compression).

               Finally, someone might say - so what? I can liv with those
traps and errors. Of course that is just fine especially while the mapping
service is free. But when you have to pay for the service, data transmission
and for the client-side flexibility, aestethics and efficiency then suddenly
your criteria may become radically stronger. Also note that with a robust
vector data-preparation-tool-chain we can avoid all the mentioned
traps/errors and achieve much, much more.

 

Oslo, 14.10.14. Regards, Sandor

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20141018/112b5701/attachment.html>


More information about the dev mailing list