[Imports] CzechAddress Import
Petr Vejsada
osm at propsychology.cz
Thu Feb 27 18:17:50 UTC 2014
Hi, All,
Dne Čt 27. února 2014 08:02:35, Serge Wroclawski napsal(a)/wrote:
> >> > you elaborate on this more, and why it's needed here?
> >
> > addr:suburb is a larger administrative division of a city, it contains
> > several city quaters and it is used very often in reffering to a general
> > directions in a city.
> >
> > We will create a wiki page for it later.
>
> If you want is as part of the import, it should be discussed during,
> not after the import.
Dalibor has already added the information to wiki and forgot it :-)
> > The vast majority of OSM users here have never heard of boundary relation.
> > If we want to convince them that OSM is useful (i.e. generating POI files
> > for navigation units) then we have to make the as simple as possible.
>
> The vast majority of OSM users never need to know what relations are
> at all, but it does not matter, since the tools they use will do the
> right thing. We do not need to fill up the database with duplicate
> data for no reason.
I'm looking for address place in Libochovany, housenumber 129. Well defined
country boundaries, well defined city boundaries, well defined and named
boundaries of admin level 10. Try nominatim to ask for this house. Not found.
This was my primary motivation to run this import. Which tools i should use,
when Nominatim fails? Is Nominatim so bad software? I don't think. But,
Nominatim cannot find this house, because there is missing
addr:place=Libochovany. Nominatim has all information nedded to show me the
house.
We are not living in ideal world and we don't have ideal software, include
Nominatim.
Serge, you can look at http://www.czso.cz/csu/rso.nsf/i/soustava_prvku , it's
in czech language, but there is diagram of administrative classification in
Czech republic. It's really difficult to understand it complettelly, i also
don't understand ;) Trust us, we spent about 2 months in discussion about
address tags in talk-cz conference, for example those threads:
https://lists.openstreetmap.org/pipermail/talk-cz/2014-February/009238.html
https://lists.openstreetmap.org/pipermail/talk-cz/2014-February/009284.html
https://lists.openstreetmap.org/pipermail/talk-cz/2014-February/009399.html
>
> > The source code is here
> >
> > http://pedro.poloha.net/osm/czechaddress-sql.zip
>
> All I see in that file is sql statements for transforming the data
> you've collected and managing it. I do not see any code related to how
> you will:
>
> 1. Merge it with existing OSM data
Serge, you probably overlooked it. Merging RUIAN with existing OSM data is
majority of the code. I'm author of the code and i spent tenth of hours to find
reliable constants of distances and other parameters to merge the data as
reliable as possible and pair them.
The main function is refresh_ruian_osm - this do the merging. It calls
functions nearest_osm_address1 to nearest_osm_address6. How it works is
described on the mentioned wiki page.
http://wiki.openstreetmap.org/wiki/Import_adres_z_RUIAN
Function opecuj_changeset (in english something like take_a_care_of_changeset)
is postproccessing function. It disables creating duplicate address nodes and
search the best candidate into pair.
There are other post-proccessing functions. They are for creating the
warnings for operator - for example: "Warning - in OSM is unpaired address
entity very close to RUIAN address node". It's described on the wiki as well.
> 2. Validate the data you have with ground truth
> Those are what I'm most concerned about. Please tell me how your
> process will handle this validation step.
I'm not sure what do you mean. Among others, JOSM do the validation tasks
also. I don't know, what we should do more.
I'm running my own instances of OSM APIDB at http://mapapi.poloha.net,
nominatim instance at http://nominatim.poloha.net and customized Mapnik. There
is also visualisation of the RUIAN data - parcels, buildings (budovy), streets
(ulice) and address places (adresy). You can see it at
http://ruian.poloha.net.
I can create testing changeset for you.
If you really want, i can run testing changeset against my APIDB and you can
inspect it, if everything is OK. Then i will revert it. Let's chose region for
testing.
If it's not enough, i can get rid of OSM and run the whole import against my
own database only.
I'm sorry, my english is probably really terrible, but i couldn't be silent.
--
Petr
More information about the Imports
mailing list