<div dir="ltr">As far as I know, the tools that generates the missing address in Flanders, does this purely based upon addr:street and addr:housenumber. Look at [1], and fill in e.g. 1980 or 2610 as postal code , check Load OSM data and press "update"<div><br></div><div>Documentation for end-users can be found under the documentation link. I think Sander is willing to explain the technology behind it when needed. I only knows it uses Overpass and Javascript .</div><div><br></div><div>There is no need for additional "refs".</div><div><br></div><div>regards</div><div><br></div><div>m</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 10, 2015 at 10:59 AM, Wiktor Niesiobedzki <span dir="ltr"><<a href="mailto:osm@vink.pl" target="_blank">osm@vink.pl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
In Poland we have quite a few addresses imported from government<br>
sources for quite long time, but as time goes on, changes are made to<br>
the source databases, and local communities don't have any viable<br>
tools, to track, what has changed in source. In case of city of<br>
Skarżysko-Kamienna, local mapper tried hard to track all the changes<br>
in source (as well as check this on site), but still, missed a lot of<br>
changes, and as it's now - there is no tooling to help such users.<br>
<br>
What I'd like to do, is to prepare a service, that will generate<br>
changes for OSM containing differences for each municipality, so local<br>
mapper can load, review and decide what to import.<br>
<br>
But this tool, to be efficient, needs additional information to be<br>
stored in OSM - identifier of the object in the source database, for<br>
which i propose tag: ref:addr.<br>
<br>
This tag is used for both identifying what was already imported, as<br>
well as, I'd like to create a protocol, that if there are some "wrong"<br>
data in the import source, we would leave a point in OSM containing:<br>
addr:ref<br>
source:addr<br>
<br>
So we can instruct further imports, to skip this point, unless there<br>
will be some change in source data.<br>
<br>
I find this solution most robust, as it gives great Signal-to-Noise<br>
ratio for local mappers, when they are identifying what needs to be<br>
updated, as well as, gives as resilience when someone accidentally<br>
deletes some address.<br>
<br>
In Poland there thousands of people employed by government to keep<br>
this data in good quality and using OSM community to duplicate their<br>
work is in my opinion - wasteful. Using this method, we can use their<br>
work, and use OSM community to improve the data, that government is<br>
sourcing. And this is something we should consider for all of the<br>
imports.<br>
<br>
We had some discussion about this already in Polish community, but as<br>
it seems, it might be philosophical change for this project, I'd like<br>
to raise this issue on global level.<br>
<br>
Apart from addresses I plan to start importing national heritage<br>
objects, for which I see exactly the same problem.<br>
<br>
The other solution that we discussed in our community is to keep track<br>
of import source state in separate database, and use this, to see what<br>
has changed in source, to generate files for local mappers, but I see<br>
following disadvantages of such solution:<br>
- such solution doesn't take into account current state of objects in<br>
OSM, what may generate duplicates or miss data, that were accidentally<br>
deleted<br>
- it makes harder to fork OSM project, as you need to fork two<br>
databases, know about them, and the license for such database should<br>
be open<br>
- it still needs some "protocol" to this database, to mark that import<br>
was done (and in what extent) - it would require additional tooling<br>
and might be additional problem to causual mappers, and probably would<br>
render the tool unusable<br>
- it gives no tools for integrity with OSM databases<br>
- needs additional support<br>
<br>
<br>
The disadvantages of my solution, that I found most concerning were:<br>
- nodes contaning only ref:addr and source:addr might be hard to<br>
understand by newcomers, especially that ref:addr doesn't contain any<br>
human-understandable data<br>
- ref:addr might get clobbered during merge of nodes<br>
<br>
But I hope that with extensive description on Wiki we can handle that problems.<br>
<br>
Cheers,<br>
<br>
Wiktor Niesiobędzki<br>
<br>
_______________________________________________<br>
talk mailing list<br>
<a href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk" target="_blank">https://lists.openstreetmap.org/listinfo/talk</a><br>
</blockquote></div><br></div>