<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html lang="de" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html charset=ISO-8859-1" /><title></title><style type="text/css">html,body{background-color:#fff;color:#333;line-height:1.4;font-family:sans-serif,Arial,Verdana,Trebuchet MS;}</style></head><body><p>Hi Tom,</p>
<p>I see your point. Hope you don't mind if I make a quick counter argument and try to convice you:</p>
<ul>
<li>For one, this type of information is already part of OSM: http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dpostal_code</li>
<li>According to my evaluations, the postal code relation coverage in Germany is near perfect (less than 1% error according to my evaluations, depending on what you measure) without (as far as I know) there being publically available information.</li>
<li>The current postal code tagging of admin levels in Austria/Switzerland is not only of bad quality but also wrong from a logical aspect. The boundaries of the two have no connection in real life. We should get rid of THAT information because it produces false results in Nominatim.</li>
<li>For most countries, there seem to be no official, publically available data </li>
<li>You can verify it if you a) have sets of addresses (e.g. customer databases) that are so large that incorrect entries can be filtered out as noise or b) drive along the boundary, knock on doors and ask people what their postal address is (no serious suggestion of course, but technically not much worse then when people walk to each individual house to map the house number)</li>
</ul>
<p>It's actually not "invented" but rather (imperfect) "derived" data, I think that's an important distinction. By having a high quality initial reconstruction, it makes it easy for others in the community to find errors in individual boundary lines and produce even better postal code areas. This information helped me detect/correct incorrect tagging on individual houses because of the inconsistency between postal code areas and the invidiual node/way. Vice versa, each new house that is tagged with a postal code will make it possible to detect inconsistencies and improve the postal code relation. Add to that the improvement to Novinatim if we would have that information in OSM.</p>
<p>So the information has high practicle value and can help push OSM into new areas of usage. That's why I believe it is very important to add it for more countries...</p>
<p>Alex</p>
<p> </p>
<div ></div>
<p>Tom Hughes wrote on 29.03.2017 00:00:</p>
<blockquote cite="mid:d41cb16c-c0ff-5de7-d0db-c1bb3fc4296c@compton.nu" type="cite">
<pre>On 28/03/17 22:24, Alex K wrote:
> Basically I'm using a semi-automatic process which takes all the know
> data points (e.g. buildings/nodes with an explicit postal code tagged to
> them) in OSM, generate voronoi cells and then merge them to larger
> regions. Then I do manually editing and clean up in my tool (aligning
> boundaries more nicely, reducing number of nodes, etc) and finally want
> to import the results as new relations into OSM. I did some evaluations
> on Austria against a real life data set and although the computed
> regions can only be an approximation, it did improve the quality of
> answers a lot! I did some basic write up of the details plus screenshots
> here:
Invented non-real world data like this simply doesn't belong in
OpenStreetMap I'm afraid.
I mean feel free to generate these areas and make them available for
geocoding etc but they're not real things and they clearly can't be
verified by anybody because they don't actually exist.
Tom
--
Tom Hughes (tom@compton.nu)
<a href="http://compton.nu/" target="_blank" title="http://compton.nu/">http://compton.nu/</a>
</pre>
</blockquote></body></html>