Ahoj, Přidávat, nahrazovat: addr:conscriptionnumber addr:provisionalnumber addr:streetnumber addr:housenumber addr:street addr:place addr:suburb addr:city addr:postcode addr:country=CZ Pouze u nových uzlů přidat: ref:ruian:addr=nnnnnn Mazat: ref:ruian source:addr is_in addr:alternatenumber addr:provisional uir_adr:ADRESA_KOD uir_adr:adresa_kod addr:number Mazat tyto kombinace k,v: source:loc=cuzk:km source:position=cuzk:km source:loc=ruian source:position=cuzk_km source:position=cuzk:ruian source:loc=source=cuzk:km Source:addr a source:loc bude patrný z tagů changesetu. Ad is_in - myslím, že to, co tu před chvílí proběhlo, t.j. že ČR "vlastní" 71 procent všech tagů is_in na světě, dává argumentům pro jejich zachování váhu limitně se blížící nule. A tak se ptám - opravdu je tu někdo, kdo tento tag používá a jeho smazáním se mu něco rozbije? Nechť promluví teď nebo ať mlčí navždy ;-). 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: AM příliš blízko u sebe - to znamená až 0.00 metrů, tedy ležící na sobě - nutno bezpodmínečně řešit. Pak obsahuje blízká místa do vzdálenosti 5 metrů. Není nutné je procházet všechna. Záleží na místní situaci, co je již podezřelé a co je nejspíš OK. V OSM je nějaký bod s adresou podezřele blízko - to je situace, kdy nějaký adresní bod v OSM není spárován s ničím z RUIAN, ale leží podezřele blízko adresnímu místu z RUIAN. Zdá se, že to bývají chyby v čísle popisném, kdy se jedná o totéž místo, ale v OSM je jiné číslo popisné (či evidenční) než v RUIAN. Je třeba prozkoumat. Ulice Xxx je příliš daleko - pokud má adresní místo ulici, kouknu se, jak je podle RUIAN ta ulice daleko od adresního bodu. Varování se vydává, je-li dále než 100 metrů. Často jde o falešný poplach, ale někdy ne. Objevil jsem adresní bod, vzdálený od ulice 1.5km, přičemž mezi ním a danou ulicí ležely desítky jiných ulic, takže se jednalo o evidentní nesmysl v RUIAN. 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ů ;-). Poznámka: V ukázkovém souboru stále je tag is_in s hodnotou 'Is in ...', ale opravdu počítám s tím, že půjde pryč. K diskusi - doufám, že nic. -- Petr, pv na propsychology.cz zobrazit citaci

Dne Út 18. února 2014 21:48:59, Petr Vejsada napsal(a): Oops, samozřejmě přidává se u všech uzlů, jak nových, tak modifikovaných. zobrazit citaci

Ahoj, Dne 18.2.2014 21:48, Petr Vejsada napsal(a): zobrazit citaci 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í. 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é. zobrazit citaci +created_by zobrazit citaci Ještě zhruba 50 000 bodů má: http://taginfo.openstreetmap.cz/tags/note=Nekonzistence%20cuzk%3Akm%20a%20mvcr%3Aadresa Vzhledem k tomu, že by se během importu měla provádět kontrola, tak by se to mohlo taky rovnou mazat. zobrazit citaci Mohl bys trochu osvětlit, co znamená obsah jednotlivých sloupců v tabulce varování? zobrazit citaci Zapiš si mě ;-) Zdraví, Petr Morávek aka Xificurk

Ahoj, Dne St 19. února 2014 18:07:40, Petr Morávek [Xificurk] napsal(a): zobrazit citaci 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. zobrazit citaci Tak zvažujte, mně se teď momentálně zvažovat nechce a už mě to trochu unavuje. zobrazit citaci nj, na to jsem nenarazil, přidávám do mazání. zobrazit citaci 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. zobrazit citaci 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. zobrazit citaci OK :-), díky., jestli má Merkaartor také něco jako JOSM remote control, tak přidám sloupeček :) -- Petr