<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
4. Lipiec 2018 08:38 od <a href="mailto:f@zz.de" target="_blank" rel="noopener noreferrer">f@zz.de</a>: <br /><blockquote class="tutanota_quote" style="border-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;">Its a big spaghetti mess<br />and data consumers take whats documented and ignore misspellings. Users<br />have to fix it with discipline noticing the errors in data consumers<br />products. Thats been OSM for more than a decade. It turned software<br />development principles upside down. For decades we invested man months<br />to do input validation before storing data. With OSM we store anything<br />if it looks like it might be representable in a key and value. Data<br />consumers have to decide which of the kv pairs look promising and<br />process them. This made OSM the most flexible way of storing everyones<br />geo data.<br /></blockquote><p><br /></p><p>I fully agree, that is a good description how OSM works (though it gives too much weight to</p><p>documentation, something documented and not present in database will be ignored,</p><p>data consumers may also support undocumented tags). <br /></p><p><br /></p><blockquote class="tutanota_quote" style="border-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;">There is no such thing as "database quality". </blockquote><p><br /></p><p>I strongly disagree here. I am not going to try defining quality metrics but there are certainly areas</p><p>mapped better and poorly mapped, it is also possible to compare quality of tagging</p><p>(for example database where buildings are marked by building=* tag is preferable to one</p><p>where buildings are defined by buillding=* or budynek=* or rakennus=* or edificio=* or feature=2727).<br /></p><p> </p> </body>
</html>