[Talk-cz] Adresy z RUIAN, 3. rekapitulace + ukázka

[Petr Vejsada]

Ahoj,

Dne St 19. února 2014 18:07:40, Petr Morávek [Xificurk] napsal(a):

> Ahoj,
> 
> Dne 18.2.2014 21:48, Petr Vejsada napsal(a):
> > Přidávat, nahrazovat:
> > addr:country=CZ
> 
> Tohle bych vážně ještě zvážil - zatím taky nezazněl případ, kdy je ten
> tag potřeba. Jak jsem psal - osobně bych preferoval nemazat, nepřidávat.
> Pokud se ukáže, že to někde bezpodmínečně potřeba je, tak nebude problém
> provést hromadné doplnění.

Mé lokální taginfo říká, že mám v evidenci 2.294.624 entit s adresním tagem, z 
toho 2.082.028 má addr:country=CZ a asi 2.400 má tag sousední země (Geofabrik 
nemá ten polygon tak přesný jako CÚZK; má trochu přesah).v RUIAN je teď 
2.907.794 AM, takže nárůst bude cca 25%, hmm, to není zase málo.

> Je potřeba si uvědomit, že adresní body tvoří momentálně cca 70% všech
> tagovaných bodů v ČR, po doplnění by to mělo být 75%. Takže každý
> "zbytečný" tag bude mít ne úplně zanedbatelný dopad na celkový objem dat
> a náročnost jejich zpracování.
> To samo o sobě samozřejmě není důvodem pro nějaké mazání, ale je to imho
> důvodem k pečlivému zvážení, jestli jsou jednotlivé tagy k něčemu užitečné.

Tak zvažujte, mně se teď momentálně zvažovat nechce a už mě to trochu unavuje.

> > Mazat:
> +created_by

nj, na to jsem nenarazil, přidávám do mazání.

> > Mazat tyto kombinace k,v:
> Ještě zhruba 50 000 bodů má:
> http://taginfo.openstreetmap.cz/tags/note=Nekonzistence%20cuzk%3Akm%20a%20mv
> cr%3Aadresa Vzhledem k tomu, že by se během importu měla provádět kontrola,
> tak by se to mohlo taky rovnou mazat.

Tyto nekonzistence stále existují. Narazil jsem na několik takových, kdy v OSM 
bylo úplně jiné číslo domu než v RUIAN, klidně i tak, že v jedné DB bylo číslo 
popisné a v druhé číslo evidenční. Objevil jsem tak, že bot hledá k RUIAN AM 
nějakou adresu v OSM, žádnou nenajde, tak jí vytvoří a následně vydá varování, 
protože obě leží buď na stejné, nebo velmi blízké pozici. Co s tím nevím. 
Řešil bych tak, že v editoru smažu ten nový bod z RUIAN a nechám starý v OSM. 
Pokud se v budoucnu v RUIAN bod změní, půjde znovu do zpracování. Jak řešit 
situaci, kdy se bod v RUIAN nezmění, protože je správně, tak to nevím. Nevím 
jak zjistit, zda je správně KM nebo RUIAN.

> 
> > Připravil jsem opět ukázku, tentokrát větší, a to pražské čtvrti Střížkov
> > a
> > Prosek. http://pedro.poloha.net/osm/data.zip . Obsahuje dva soubory,
> > data.osm a data.csv. Co je v data.osm je snad jasné, v data.csv je
> > tabulka varování - seznam míst, kterým je třeba věnovat pozornost. Pro
> > uživatele JOSM je tam link na JOSM remote control, jeho otevřením v
> > prohlížeči nebo curl apod. JOSM skočí
> > na problematické místo.Typy chyb:
> Mohl bys trochu osvětlit, co znamená obsah jednotlivých sloupců v
> tabulce varování?

Jde o dvojice nebo trojice adresních entit, u kterých bylo vygenerováno to 
varování. Česky jsou značena data z RUIAN, anglicky z OSM. Koncovka _a nebo _b 
označuje jeden z dvojice bodů z RUIAN, kterých se varování týká. Takže třeba 
varování AM jsou blízko u sebe plus označení těch bodů, které jsou blízko u 
sebe. cislo_popisne_a je č.p. prvního a cislo_popisne_b je č.p. druhého bodu z 
RUIAN. Může, ale nemusí u toho být i adresní entita z OSM, případně to může 
být pár, složený jen z jednoho bodu RUIAN a jedné entity v OSM.

> 
> > Píšu tady o tom proto, protože ačkoli je chyb RELATIVNĚ málo, v
> > absolutních
> > číslech to dá desetitisíce a není reálné, abych to zvládl v rozumném čase
> > prohlédnout všechno. Proto pravděpodobně poprosím dobrovolníky, kteří by
> > chtěli dostávat .osm s jimi vybranou oblastí, prohlédnout je, opravit a
> > poslat mi je zpátky. Takže je to taková příprava na lov brigádníků ;-).
> 
> Zapiš si mě ;-)

OK :-), díky., jestli má Merkaartor také něco jako JOSM remote control, tak 
přidám sloupeček :)

--
Petr