<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin-top:0cm;
margin-right:0cm;
margin-bottom:10.0pt;
margin-left:0cm;
line-height:115%;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoNoSpacing, li.MsoNoSpacing, div.MsoNoSpacing
{mso-style-priority:1;
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNoSpacing style='text-indent:36.0pt'>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).<o:p></o:p></p><p class=MsoNoSpacing><a href="https://drive.google.com/file/d/0B6qGm3k2qWHqdW1XYXN6MENpUVE/view?usp=sharing">https://drive.google.com/file/d/0B6qGm3k2qWHqdW1XYXN6MENpUVE/view?usp=sharing</a><o:p></o:p></p><p class=MsoNoSpacing>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.<o:p></o:p></p><p class=MsoNoSpacing style='text-indent:36.0pt'>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. <o:p></o:p></p><p class=MsoNoSpacing style='text-indent:36.0pt'>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.<o:p></o:p></p><p class=MsoNoSpacing>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). <o:p></o:p></p><p class=MsoNoSpacing> 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.<o:p></o:p></p><p class=MsoNoSpacing>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. <o:p></o:p></p><p class=MsoNoSpacing>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).<o:p></o:p></p><p class=MsoNoSpacing> 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.<o:p></o:p></p><p class=MsoNoSpacing><o:p> </o:p></p><p class=MsoNoSpacing>Oslo, 14.10.14. Regards, Sandor<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>