[Talk-cz] obkreslování
nazdar, nevím, kdo dělal domy v Brně Řečkovicích, a radši po tom nebudu pátrat, ale docela by mě zajímalo, odkud to obkreslil ... zajímal mě barák č.p. 1468-1469 a koukám, že na Seznamích mapách je blbě označenej jako č.p. 1470-1471 (a okolní domy jsou patřičně špatně taky) ... kouknu do OSM a tam to samý přitom v katastru je to dobře, kouknu na Googlí mapy, tam je to dobře, kouknu na Atlas, tam je to dobře, aha to je zdroj Google, tak nic ... K. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] obkreslování
On 7.8.2012 8:07, Karel Volný wrote: nazdar, nevím, kdo dělal domy v Brně Řečkovicích, a radši po tom nebudu pátrat, ale docela by mě zajímalo, odkud to obkreslil ... zajímal mě barák č.p. 1468-1469 a koukám, že na Seznamích mapách je blbě označenej jako č.p. 1470-1471 (a okolní domy jsou patřičně špatně taky) ... kouknu do OSM a tam to samý přitom v katastru je to dobře, kouknu na Googlí mapy, tam je to dobře, kouknu na Atlas, tam je to dobře, aha to je zdroj Google, tak nic ... K. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz V Josm to lze zjistit velice rychle položkou Users. Spíš než se rozčilovat, bylo by vhodné tomu hříšníkovi napsat a upozornit ho na chybu. Pokud neví že něco dělá špatně bude tak činit nadále. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] rúian bot - první výsledky testů
Dobra prace! Opravdu ocenuju tolik vlozeneho usili. Zda se, ze automaticky import je precijen realny! K Dne 7.8.2012 00:46, Miroslav Šulc napsal(a): tak jsem přidal do statistik bota ještě ten histogram vzdáleností spárovaných bodů a informace o změně názvu obce/ulice adresního bodu. tady jsou doksy: http://pastebin.com/M5AwaeFNhttp://pastebin.com/jtbpMzdX tady je část mladé boleslavi a kosmonos: http://pastebin.com/jtbpMzdX ff Dne 6.8.2012 19:27, Miroslav Šulc napsal(a): v příloze posílám log z bota. tady pak ještě výtah z logy pro ty, kterým se nebude chtít zip otevírat: ... ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] rúian bot - první výsledky testů
Díky za hodně zajímavé výstupy. Že se liší OSM od RÚIAN není překvapení, ale rozdíl mezi RÚIAN a KM je zarážející. Čekal bych, že používají stejná data, ale zjevně tomu tak není. Všechny body v Doksech, které nejsou v RÚIAN jsou v KM i OSM Zkoušel jsem dva body z Kosmonos. Tam pro změnu jsou v RÚIAN, ale v KM jsou domečky/chatičky bez čp/če. Čemu nerozumím. POINT(14.9199488 50.4377038) CZ, 29306 Kosmonosy, Květinová 979 má protějšek http://www.openstreetmap.org/browse/node/1238703135/history přesně na místě jako v KM, tedy na ulici ;-) Přesto, že má protějšek, je v Not matched RÚIAN addresses: Znamená to, že je příliš vzdálen? Neměl by být onen protějšek v Not matched OSM addresses: ? Nebo by byl vymazán? Nekonzistence dat vypadá takto Not matched OSM addresses: POINT(14.9130038 50.4308788) CZ, null null, null 1396 Duplicity to selektí skvěle. Ještě jeden zajímavej bod POINT(14.9097779 50.4360764) CZ, 293 06 null, Na Radouči 1326 Na něm je připíchnutá lékárna, čímž není vidět čp. (docela blbý ne? pro navigace asi OK) http://www.openstreetmap.org/browse/node/1781453132/history Navíc na stejné budově je další nekonzistence http://www.openstreetmap.org/browse/node/1238706528/history Zakončím pozitivní zprávou. Na této budově je ještě jeden adresní bod, který je na stejném místě v OSM, KM i RÚIAN. Mirek Dne 6. srpna 2012 19:27 Miroslav Šulc fordf...@fordfrog.com napsal(a): v příloze posílám log z bota. tady pak ještě výtah z logy pro ty, kterým se nebude chtít zip otevírat: Loaded 1 632 OSM nodes Loaded 2 044 RÚIAN nodes Matching nodes by full address... 0 nodes matched Matching nodes by street... Matched RÚIAN node POINT(14.901064 50.4144003) CZ, 29301 Mladá Boleslav, Ptácká 28/29 and OSM node POINT(14.9009875 50.4211801) CZ, null null, Ptácká 28/29 but their distance 0,0067802 is over the limit 0,005 Matched RÚIAN node POINT(14.9009205 50.4145706) CZ, 29301 Mladá Boleslav, Ptácká 295 and OSM node POINT(14.9001738 50.4229025) CZ, null null, Ptácká 295 but their distance 0,0083653 is over the limit 0,005 Matched RÚIAN node POINT(14.9043758 50.4183866) CZ, 29301 Mladá Boleslav, Folprechtova 1259 and OSM node POINT(14.9031463 50.4242688) CZ, null null, Folprechtova 1259 but their distance 0,0060093 is over the limit 0,005 1 398 nodes matched Matching nodes by conscription/provisional number... Matched RÚIAN node POINT(14.9063657 50.4280101) CZ, 29301 Mladá Boleslav, U stadionu 983 and OSM node POINT(14.919441 50.4385282) CZ, null null, Jižní 983 but their distance 0,0167808 is over the limit 0,005 Matched RÚIAN node POINT(14.901064 50.4144003) CZ, 29301 Mladá Boleslav, Ptácká 28/29 and OSM node POINT(14.9009875 50.4211801) CZ, null null, Ptácká 28/29 but their distance 0,0067802 is over the limit 0,005 Matched RÚIAN node POINT(14.9009205 50.4145706) CZ, 29301 Mladá Boleslav, Ptácká 295 and OSM node POINT(14.9001738 50.4229025) CZ, null null, Ptácká 295 but their distance 0,0083653 is over the limit 0,005 Matched RÚIAN node POINT(14.9059945 50.4299041) CZ, 29301 Mladá Boleslav, Na Radouči 1078 and OSM node POINT(14.9109589 50.4126665) CZ, null null, Třída T. G. Masaryka 1078 but their distance 0,0179382 is over the limit 0,005 Matched RÚIAN node POINT(14.9043758 50.4183866) CZ, 29301 Mladá Boleslav, Folprechtova 1259 and OSM node POINT(14.9031463 50.4242688) CZ, null null, Folprechtova 1259 but their distance 0,0060093 is over the limit 0,005 Matched RÚIAN node POINT(14.9091991 50.4195372) CZ, 29301 Mladá Boleslav, Palackého 1396 and OSM node POINT(14.9130038 50.4308788) CZ, null null, null 1396 but their distance 0,0119628 is over the limit 0,005 202 nodes matched Total matched nodes: 1 600 Total unmatched nodes - RÚIAN: 444, OSM: 32 Maximum matched node distance: 0,0023727 (RÚIAN: POINT(14.9013315 50.422053) CZ, 29301 Mladá Boleslav, Pod skalou 303 OSM: POINT(14.9006775 50.4243338) CZ, null null, Pod Skalou 303) ff ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] rúian bot - první výsledky testů
On Mon 06-08-12 19:27:13, Miroslav Šulc wrote: [...] Ptácká 28/29 and OSM node POINT(14.9009875 50.4211801) CZ, null null, Ptácká 28/29 but their distance 0,0067802 is over the limit 0,005 A vida! Bod z KM+ČUZK importu beznadějně mimo, opravený UIR-ADR je jen o 13 metrů vedle na jiném domě. :) Co se týče Mladé Boleslavi, duplicity jsem tam vytvořil já s tím, že budu brzy mít skript, kterým je odstraním. Inu, skript je od té doby stále skoro hotový. Jak už jsem psal dříve, souhlasím s nahrazením svých importů daty z RÚIAN. Tedy tyto body mazat, pokud jsou ve verzi 1 a jsem jejich vlastníkem. Libor ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] rúian bot - první výsledky testů
Jestli jsem správně pochopil, chce ff ty bližší body posunout (bude-li třeba) a vymazat se budou muset ty vzdálenější, z předchozího importu. http://www.openstreetmap.org/browse/changeset/1964311 Mirek Dne 7. srpna 2012 21:47 Libor Pechacek lpecha...@gmx.com napsal(a): On Mon 06-08-12 19:27:13, Miroslav Šulc wrote: [...] Ptácká 28/29 and OSM node POINT(14.9009875 50.4211801) CZ, null null, Ptácká 28/29 but their distance 0,0067802 is over the limit 0,005 A vida! Bod z KM+ČUZK importu beznadějně mimo, opravený UIR-ADR je jen o 13 metrů vedle na jiném domě. :) Co se týče Mladé Boleslavi, duplicity jsem tam vytvořil já s tím, že budu brzy mít skript, kterým je odstraním. Inu, skript je od té doby stále skoro hotový. Jak už jsem psal dříve, souhlasím s nahrazením svých importů daty z RÚIAN. Tedy tyto body mazat, pokud jsou ve verzi 1 a jsem jejich vlastníkem. Libor ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] rúian - struktura dat adresních bodů
Ahoj, On Mon 06-08-12 22:07:46, Petr Morávek [Xificurk] wrote: Libor Pechacek wrote: Ahoj Petře, Jak už jsem psal dříve, is_in obsahuje informaci z mapy katastrálních území neodvoditelnou. Jednak někdy KÚ obsahuje více obcí, druhak se někdy obec jmenuje trochu jinak něž katasrální území. Je ke zvážení, jestli je addr:city plnohodnotnou náhradou. Libor Ahoj, asi budu potřebovat trochu vyjasnit, co jsi měl namysli... Předem, popletl jsem pojmy obec a část obce. Při importech byly někdy části tak jasně oddělěny, že jsem je (intuitivně) pojal jako samostatné obce. Tímto tedy odpovídám na otázku ze závěru Tvého příspevku. 1) KÚ je vždy součástí jenom jedné obce. Jedinou výjimkou je obec Strýčice, která nemá žádné KÚ a leží na území obce Radošovice. 2) Název KÚ je pro adresní body irelevantní - v žádném formátu adresy se neuvádí, pokud se nepletu, č.p. by měla být unikátní v rámci části obce, jméno KÚ do toho nikde nevstupuje. Navázal jsem na Tvůj výrok, že ti přijde zbytečné tam znova vypisovat informaci, která už je jednou na relacích hranic. Názvy katastrálních území se od názvů obcí nepatrně liší. Co jsem se teď díval, tak názvy KÚ mají často ještě nějaký místopisný přílepek - Doksy u Máchova jezera (normální smrtelníci znají jen jako Doksy), Obora v Podbezdězí (Obora) nebo Břevniště pod Ralskem. Když tedy například zkusíš rekonstruovat is_in bodu http://www.openstreetmap.org/browse/node/983573832 z relací administrativních hranic, dojdeš k trochu jinému výsledku: současné is_in = Břevniště, Hamr na Jezeře, Liberecký kraj, CZ vs odvozené is_in = Břevniště pod Ralskem, Hamr na Jezeře, Liberecký kraj, CZ Nejsem si jist, který z názvů je správný, nicméně jsem si celkem jist, jak sám hledám sídla v mapě. ;) 3) Osobně si myslím, že addr:city by mělo obsahovat jméno obce a to sice z čistě praktických důvodů - je to položka, která se typicky píše na obálku, máme netriviální počet přesahů, kdy adresní body patřící pod obec A, leží na území obce B (sice se tyhle anomálie pomalu odstraňují, ale existují). Vložení názvu části do addr:city podle mě problém systémově vyřeší alespoň pro ČR - jméno části obce (ve smyslu §27 odst. 2 zákona o obcích) je podle mých dosavadních zkušeností v rámci KÚ jednoznačné a nemá další dělení. Tag is_in zabilo jeho nadužívání (až zneužívání) pro vše možné i nemožné, takže nikdo přesně neví, co vlastně jeho obsah má znamenat, proto bych se mu snažil vyhnout. Přijde mi celkem zbytečné psát třeba: is_in=Pardubice, okres Pardubice, Pardubický kraj, Severovýchod, Česká republika když to samé získám prostým pohledem (dotazem do databáze) na hranice, které máme komplet. I nominatim, který se používá na openstreetmap.org tohle obstojně zvládá. (Předpokládám, že počet meziokresních, nedej bože mezikrajských, přesahů bude řádově menší než meziobecních... víte vůbec někdo o takovém případě? Kolik jich v republice je?) Když už něco dávat do is_in, tak jméno části obce... a to říkám jen proto, že mě momentálně nenapadá lepší tag ;-) Jj, to je zač se tady zasazuji. :) Pěkný večer, Petr Morávek aka Xificurk PS: Ah, až teď když jsem to všechno dopsal, tak mě trklo, že jsi možná pod pojmem obec neměl namysli pojem ze zákona č. 128/2000 Sb. (O obcích), ale obecně sídlo. Je to tak? Můžeš prosím vyjasnit? Libor ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] rúian bot - první výsledky testů
aktuálně je to tak, že bot se vždycky snaží napárovat osm bod na nejbližší rúian bod. teď mě ale napadá, že záleží na pořadí bodů v osm. pokud bude v exportu z osm nejdřív vzdálenější bod (a ten bude do vzdálenosti 0.005) a pak ten bližší, tak se na sebe napárují body vzdálenější. budu to muset otočit, aby se párovaly rúian body na osm body a ne osm body na rúian body jak je to teď, protože v rúian by duplicity být neměly. ff Dne 7.8.2012 22:17, Mirek Dlask napsal(a): Jestli jsem správně pochopil, chce ff ty bližší body posunout (bude-li třeba) a vymazat se budou muset ty vzdálenější, z předchozího importu. http://www.openstreetmap.org/browse/changeset/1964311 Mirek Dne 7. srpna 2012 21:47 Libor Pechacek lpecha...@gmx.com mailto:lpecha...@gmx.com napsal(a): On Mon 06-08-12 19:27:13, Miroslav Šulc wrote: [...] Ptácká 28/29 and OSM node POINT(14.9009875 50.4211801) CZ, null null, Ptácká 28/29 but their distance 0,0067802 is over the limit 0,005 A vida! Bod z KM+ČUZK importu beznadějně mimo, opravený UIR-ADR je jen o 13 metrů vedle na jiném domě. :) Co se týče Mladé Boleslavi, duplicity jsem tam vytvořil já s tím, že budu brzy mít skript, kterým je odstraním. Inu, skript je od té doby stále skoro hotový. Jak už jsem psal dříve, souhlasím s nahrazením svých importů daty z RÚIAN. Tedy tyto body mazat, pokud jsou ve verzi 1 a jsem jejich vlastníkem. Libor ___ Talk-cz mailing list Talk-cz@openstreetmap.org mailto:Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz smime.p7s Description: Elektronicky podpis S/MIME ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] rúian bot - první výsledky testů
Ahoj, On Mon 06-08-12 17:04:39, v...@email.cz wrote: Mimochodem znáte plugin Conflation pro JOSM? http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Conflation Nemám s tím zkušenosti (jsem tu nový), ale podle popisu to lze použít pro poloautomatický import a slučování dat z vnějších databází do OSM. Např. právě přiřazování adres z RÚIAN existujícím prvkům v OSM. Možná to není vhodné na plně automatický chod, ale třeba by to šlo použít na manuální dočišťování? Věnoval jsem zatím zkoumání tohoto nástroje přibližně půl hodiny a přijde mi použitelný. Nicméně, je to mocný nástroj a jako takový je třeba jej používat s rozumem. Na dočišťování asi bude vhodný. Libor Jan Původní zpráva Od: Jan Bilak jan.bilak@gmail.com Předmět: Re: [Talk-cz] rúian bot - první výsledky testů Datum: 06.8.2012 16:04:59 Ahoj, jak ten bot rychlý? Aneb za jak dlouho by zpracoval (pokusně) celou ČR - tedy vygeneroval log? Můžeš udělat histogram vzdáleností spárovaných bodů? Honza Dne 6. srpna 2012 4:54 Mirek Dlask dlas...@gmail.com napsal(a): Je otázka, zda nejsou v RÚIAN adresní body domů bez č.p. , asi tam budou adresní body rozestavěných domů. Ty v OSM předpokládám nejsou. Nebo by se asi zobrazovaly tečky bez čísel!? Buď zkusit zmenšit boxík na nějaké garáže, nebo průmysl bez č.p. , nebo SELECT adresních bodů bez čísel popisných a zároveň evidenčních, jsou-li ... 150 je fakt nějak moc Mirek Dne 5. srpna 2012 23:30 Miroslav Šulc fordf...@fordfrog.com napsal(a): tak jsem dodělal bota do stádia, že načte body z osm api a z rúian db, pokusí se je spárovat a vygeneruje nějaké statistiky. pokud se někdo chce podívat do kódu, tak je k dispozici na https://github.com/fordfrog/ruian2osm co se týče načítání bodů z api, tak jsem to omezil na nody, které mají tag addr:housenumber a tag addr:country=CZ (doufám, že adresní body v čr mají aspoň tyto tagy, pokud ne, tak bych to musel udělat jinak). pro testy jsem použil BOX(14.63 50.55,14.68 50.58). pro párování bodů jsem nastavil maximální povolenou vzdálenost na 0.005, nicméně největší vzdálenost mezi shodnými body je 0,0009538 (RÚIAN: POINT(14.6562825 50.5617608) CZ, Doksy, Hálkova 890 OSM: POINT(14.6553375 50.5616313) CZ, null, Hálkova 890, http://maps.fordfrog.com/?zoom=18lat=50.56166lon=14.65557layers=0B0FTF). u tohohle bodu je zajímavé, že údaj v kú je jiný než údaj v rúian (je to vidět z kú vrstvy, u nás ale zatím neproběhla digitalizace). co se týče propojování, tak úspěšnost byla následující: Total matched nodes: 1 136 Total unmatched nodes - RÚIAN: 150, OSM: 15 z toho mj vyplývá, že pokud jsem nikde neudělal chybu, tak v dané oblasti je oproti rúian navíc 15 adresních bodů a 150 jich chybí (což je opravdu dost na tak malé území, aspoň podle mě). k párování ještě poznámka. to že se body sprárovaly ještě neznamená, že osm obsahuje kompletní adresy. jak jsem psal jinde, u nás kompletně chybí addr:city, součástí adresy není ani addr:postcode. párování probíhá v několika cyklech, nejdříve podle celé adresy, nespárované body se pak porovnávají podle ulice a čísla, a to co zbyde se nakonec porovná pouze podle čísla. ve všech případech se ještě zohledňuje vzdálenost bodů. pro programátory podrobnější info tady: https://github.com/fordfrog/ruian2osm/blob/next_release/src/main/java/com/fordfrog/ruian2osm/AddressNodesMatcher.java tady je ještě údaj o průměrné vzdálenosti propojených bodů: Average matched node distance: 0,046 v příloze posílám (snad proleze zip) kompletní log z bota. uvítal bych, pokud by se někdo na ten log podíval, jestli tam nenajde ještě něco zajímavého (nějaké zjevné chyby, na co si dát pozor apod.). stejně tak, pokud budete někdo chtít, abych pustil bota (samozřejmě pouze v testovacím režimu) na nějaké vaší oblíbené oblasti, tak mi pošlete bounding box a já vám pošlu log z bota. ff ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz -- ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] rúian bot - první výsledky testů
Dne 7.8.2012 21:43, Mirek Dlask napsal(a): Díky za hodně zajímavé výstupy. díky za skvělou analýzu. díky ní jsem narazil na další problémy, které jsem přehlídnul a je potřeba je vyřešit. Že se liší OSM od RÚIAN není překvapení, ale rozdíl mezi RÚIAN a KM je zarážející. Čekal bych, že používají stejná data, ale zjevně tomu tak není. Všechny body v Doksech, které nejsou v RÚIAN jsou v KM i OSM hledal jsem, kde je problém, a našel jsem příčinu. v rúian je celkem 205488 adresních bodů (z celkových 2915347), které nemají definované souřadnice. z toho vyplývá, že když udělám do db dotaz na určitý bounding box, tak tyhle ve výsledném seznamu chybí. je otázka, jak tohle pořešit. osm definice adresního bodu typu POINT(14.6523938 50.5632938) CZ, null null, null 948 není z adresního hlediska moc jednoznačná :-) nicméně z rúian db by mělo jít vytáhnout, v jaké obci se bod nachází (podle osm souřadnic), takže bych měl dostat identifikaci obec - číslo. s tím už by mělo být ve většině případů asi možné body jednoznačně napárovat. Zkoušel jsem dva body z Kosmonos. Tam pro změnu jsou v RÚIAN, ale v KM jsou domečky/chatičky bez čp/če. a jak je to na webu čúzk v nahlížení do kú? Čemu nerozumím. POINT(14.9199488 50.4377038) CZ, 29306 Kosmonosy, Květinová 979 má protějšek http://www.openstreetmap.org/browse/node/1238703135/history přesně na místě jako v KM, tedy na ulici ;-) Přesto, že má protějšek, je v Not matched RÚIAN addresses: Znamená to, že je příliš vzdálen? Neměl by být onen protějšek v Not matched OSM addresses: ? Nebo by byl vymazán? tady je problém v bounding boxu. jelikož jsme definovali bounding box jako BOX(14.9 50.41,14.92 50.44) a bod z osm je mimo něj (50.4375975, *14.9201675*), tak se body nepotkaly (export z osm api mi bod nedal, protože je mimo bbox). v praxi by bot nejdřív načetl body z celé čr (z osm i z rúian db), takže k tomuhle problému by dojít nemělo. Nekonzistence dat vypadá takto Not matched OSM addresses: POINT(14.9130038 50.4308788) CZ, null null, null 1396 Duplicity to selektí skvěle. jak jsem psal jinde, budu muset ještě upravit párování, aby se vždy párovaly nejbližší body. teď to záleží na pořadí bodů v osm. tj pokud mají oba duplicitní body stejné adresní informace a vzdálenější bod je v exportu z osm api před bližším, tak se rúian bod spáruje s tím vzdálenějším. ta úprava ale nebude mít vliv na body, které jsou sice duplicitní, ale kvalitativně rozdílné. tj pokud jeden z duplicitních bodů má např. navíc správně ulici a druhý ne, tak se na rúian bod napáruje první bod, i kdyby byl dál než ten bez ulice. Ještě jeden zajímavej bod POINT(14.9097779 50.4360764) CZ, 293 06 null, Na Radouči 1326 Na něm je připíchnutá lékárna, čímž není vidět čp. (docela blbý ne? pro navigace asi OK) http://www.openstreetmap.org/browse/node/1781453132/history z pohledu renderování amenity přímo na adresním bodě asi není zrovna ideální. další problém určitě nastává v případě, kdy je na adrese víc různých amenity, ale namapovat jde tímhle způsobem jen jedna. na druhou stranu je z toho naprosto zřejmá adresa daného amenity. jak se tohle v praxi řeší, aby amenity mělo i adresu ale současně nebylo adresním bodem? bot by eventuelně mohl z bodů extrahovat amenity a posunout je třeba o metr, aby nedocházelo k tomuhle jevu. pokud ovšem budeme chtít. Navíc na stejné budově je další nekonzistence http://www.openstreetmap.org/browse/node/1238706528/history Zakončím pozitivní zprávou. Na této budově je ještě jeden adresní bod, který je na stejném místě v OSM, KM i RÚIAN. Mirek ff Dne 6. srpna 2012 19:27 Miroslav Šulc fordf...@fordfrog.com mailto:fordf...@fordfrog.com napsal(a): v příloze posílám log z bota. tady pak ještě výtah z logy pro ty, kterým se nebude chtít zip otevírat: Loaded 1 632 OSM nodes Loaded 2 044 RÚIAN nodes Matching nodes by full address... 0 nodes matched Matching nodes by street... Matched RÚIAN node POINT(14.901064 50.4144003) CZ, 29301 Mladá Boleslav, Ptácká 28/29 and OSM node POINT(14.9009875 50.4211801) CZ, null null, Ptácká 28/29 but their distance 0,0067802 is over the limit 0,005 Matched RÚIAN node POINT(14.9009205 50.4145706) CZ, 29301 Mladá Boleslav, Ptácká 295 and OSM node POINT(14.9001738 50.4229025) CZ, null null, Ptácká 295 but their distance 0,0083653 is over the limit 0,005 Matched RÚIAN node POINT(14.9043758 50.4183866) CZ, 29301 Mladá Boleslav, Folprechtova 1259 and OSM node POINT(14.9031463 50.4242688) CZ, null null, Folprechtova 1259 but their distance 0,0060093 is over the limit 0,005 1 398 nodes matched Matching nodes by conscription/provisional number... Matched RÚIAN node POINT(14.9063657 50.4280101) CZ, 29301 Mladá Boleslav, U stadionu 983 and OSM node POINT(14.919441 50.4385282) CZ, null null, Jižní 983 but their distance 0,0167808 is over the limit 0,005 Matched RÚIAN node POINT(14.901064
