[Imports] Address import from government open data in Serbia

[Matthew Whilden]

One of the nice secondary benefits of high quality address data is that you
get a good cross-check on the street information already in OSM. You may
consider adding either the MapWithAI plugin for JOSM users (it has a great
validator rule for this) OR do a post facto cleanup using the address view
over at https://tools.geofabrik.de/osmi/. For the United States equivalent,
it has caught typos, misspellings, incorrect abbreviation expansions etc.

Here's a diary about verifying US roadway data with our National Address
Database: https://www.openstreetmap.org/user/watmildon/diary/400827

Matt

On Sun, Mar 26, 2023 at 2:39 PM Branko Kokanovic <branko at kokanovic.org>
wrote:

> Hi, comments inline
>
> On Sun, Mar 26, 2023, at 20:31, Marc_marc wrote:
> > Le 26.03.23 à 22:11, Branko Kokanovic a écrit :
> >> Main wiki (en and sr):
> https://wiki.openstreetmap.org/wiki/Serbia/Projekti/Adresni_registar
> >
> > Thank you for this multilingual page
> > unfortunately the English page contains a lot of non-English
> sentence/word.
>
> Ah, sorry, I started translating and did only headings and forgot:). It is
> translated fully now, check please!
>
> >
> > 3 remarks if I understood correctly :
> > - you refer to the addr page in Serbia for the tags, this one is in
> Serbian
> > Could you instead include the correspondence between the data names
> > in the opendata data and the osm tags you plan to use ?
>
> Not sure what you mean here? RGZ (cadastre) data include street and
> housenumber that we are converting to addr:street and addr:housenumber as
> explained, all other fields are not from RGZ. There will be
> "ref:RS:kucni_broj" which is reference to ID in RGZ. There are other fields
> in RGZ like district, municipality, settlement that we will use to match
> RGZ and OSM, but those will not be imported. Maybe I can translate
> https://wiki.openstreetmap.org/wiki/Serbia/Adresses if it can help? Or
> maybe I just don't understand question fully?
>
> > - you plan to use a ref in some cases.
> > Unfortunately, practice shows that these refs are of no use either for a
> > future import or for the QA since you have to take into account the new
> > addresses without refs anyway. I recommend deleting this external ref
> > which only makes the data heavier for the contributor
>
> Interestingly, our experience is quite different - having reference to
> open data is huge help for lot of scripts/reports we have. For example, we
> use this: https://gitlab.com/osm-serbia/prostorne-jedinice-import for
> daily check of administrative boundaries (download OSM and open data each
> day and check quality in OSM) and references (tag "ref:RS:naselje") are
> used to match these. Also for other stuff like heritage
> https://www.osmsrbija.iz.rs/nkd/ with tag "ref:RS:nkd". It offers us to
> do two-way sync and report newly added/recently removed entities from both
> OSM and open data! Since it is mostly automated effort to check them (and
> report those missing refs), there is no expectation that anyone should add
> these manually, so I hope it is no burden to any contributor.
>
> > - I don't see a changeset tag, could you add the tags you plan to use?
>
> Yes, we plan to use it (are you referring to source during changeset
> commit?). It should be mentioned in my original mail as "RGZ_AR_Import". It
> is also part of .osm files in report.
>
> Hope this clarifies things better!
>
> Thanks, Branko
>
> >
> >
> >
> > _______________________________________________
> > Imports mailing list
> > Imports at openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/imports
>
> _______________________________________________
> Imports mailing list
> Imports at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20230327/893c71b6/attachment.htm>