rúian bot - první výsledky testů

25 zpráv
Zpět na přehled

rúian bot - první výsledky testů

25 zpráv MMLHJVJJ 10 účastníků 24 min čtení
  1. Miroslav Šulc fordfrog na fordfrog.com #ma18b43
    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=18&lat=50.56166&lon=14.65557&layers=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,0000046 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
  2. Mirek Dlask dlask.m na gmail.com #mfce7d9
    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
  3. hanoj ehanoj na gmail.com #m874cbb
    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).
    *** jakým způsobem budeme pracovat s OSM addr, které jsou vloženy v polygonech budov(building=yes)? Převedeme tyto addr informace před prací bota na z polygonu body (centroindy polygonů) ?
    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,
    *** na prvni pohled mi neni zrejme co je cilem parovani, ale v k.u. Tuřany, k.u. Chrlice je běžná vzdálenost bodů addr v OSM (import z UIR-ADR) vůči WMS CUZK:KM 10 až 30 metrů, h. hanoj
  4. Miroslav Šulc fordfrog na fordfrog.com #ma65ee8
    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 ...
    adresní body bez čísla v rúian neexistují (jsou tam pouze 4, ale ty mají příznak smazání), protože to z podstaty věci není adresa :-) za "adresní body bez čísla" lze ale považovat stavební objekty (na nich je právě definovaný ten typ čísla "bez čísla"). podle mě ale nemá smysl je zobrazovat jako body, budovy (které mají definovanou geometrii) se do osm z rúian dřív nebo později také dostanou.
    150 je fakt nějak moc Mirek
    ff
  5. Miroslav Šulc fordfrog na fordfrog.com #m73775a
    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).
    *** jakým způsobem budeme pracovat s OSM addr, které jsou vloženy v polygonech budov(building=yes)? Převedeme tyto addr informace před prací bota na z polygonu body (centroindy polygonů) ?
    dobře že se o nich zmiňuješ, na ně jsem úplně zapomněl. upravím bota tak, aby načítal i adresy z budov. následně při aktualizaci by pak bot údaje o adrese z budovy mohl smazat a vytvořil by nový adresní bod.
    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,
    *** na prvni pohled mi neni zrejme co je cilem parovani, ale v k.u. Tuřany, k.u. Chrlice je běžná vzdálenost bodů addr v OSM (import z UIR-ADR) vůči WMS CUZK:KM 10 až 30 metrů,
    cílem párování je zjistit, který bod z osm odpovídá kterému bodu z rúian. na základě toho pak může dojít ze strany bota k aktualizaci již existujícího bodu místo odstranění jednoho a vytvoření druhého, takže dojde k zachování historie. neumím přepočítávat vzdálenost ze stupňů na metry, ale odhadem ten limit 0.005 bude asi tak 500m. ono když bota pustím na malém území, tak tenhle parametr nehraje roli, ale když bych ho pustil na celé čr, tak se potřebuju vyhnout tomu, aby mi pároval mezi sebou body z opačných krajů republiky jako shodné (vzhledem k tomu, že u některých adresních bodů v osm chybí addr:city, tak je to možné). takhle bot spáruje jen body, které jsou v od sebe vzdálené maximálně 500m. (v příkladu, který jsem uváděl v prvním mailu, je maximální vzdálenost dvou spárovaných bodů cca 100m.)
    h. hanoj
    ff
  6. Mirek Dlask dlask.m na gmail.com #mb02b4e
    A taky ti musíme držet palce ;-) při řešení duplicit adresních bodů :-( M. Boleslav, Debř ............... Docela by mě zajímal počet. Co s nima? Smazat ty vzdálenější, co nejdříve, respektive pře aktualizací? Už jsem jednou zmiňoval, že na některých adresních bodech jsou další tagy. name, amenity, operator, http://www.openstreetmap.org/browse/node/1767482902/history Převést tagy na nové body, nebo budovy? Jinak co jsem našel, už jsem před časem opravoval. V budoucnu bude asi problém se jmény ulic http://tools.geofabrik.de/osmi/?view=addresses&lon=15.18443&lat=50.46818&zoom=18&opacity=0.97&overlays=buildings,buildings_with_addresses,postal_code,nodes_with_addresses_defined,nodes_with_addresses_interpolated,no_addr_street,street_not_found,interpolation,interpolation_errors,connection_lines,nearest_points,nearest_roads Tím tvým postupem se vlastně i aktualizuje název ulice u adresního bodu. Ulici na Václava Havla bude muset přejmenovat člobrda. Mirek
  7. Miroslav Šulc fordfrog na fordfrog.com #me07f27
    A taky ti musíme držet palce ;-) při řešení duplicit adresních bodů :-( M. Boleslav, Debř ............... Docela by mě zajímal počet.
    kdyžtak mi pošli boudning box pro oblast, kde je hodně duplicit, a já na tom pustím bota a uvidíme, co z něj vyleze.
    Co s nima? Smazat ty vzdálenější, co nejdříve, respektive pře aktualizací?
    no, jestli se nepletu, tak duplicity se vyfiltrují tím botem, protože první bod se namapuje na odpovídající bod v rúian, a druhý bod už nebude na co namapovat, takže zbyde a bot ho bude brát jako nadbytečný a určený k odstranění.
    Už jsem jednou zmiňoval, že na některých adresních bodech jsou další tagy. name, amenity, operator, http://www.openstreetmap.org/browse/node/1767482902/history Převést tagy na nové body, nebo budovy? Jinak co jsem našel, už jsem před časem opravoval.
    taky jsem si toho všimnul. vzhledem k tomu, že bot u bodů, které existují v rúian i v osm, provede aktualizaci bodu v osm, tak ke ztrátě informací nedojde (upraví pouze adresní tagy + source). jiná situace je u duplicit, tam je otázka, který bod si bot vybere (aktuálně ten bližší k souřadnicím v rúian) a tam pak může dojít ke ztrátě určitých tagů. asi by se to dalo nějak ošetřit, např že by bot přidával větší váhu bodu, který má více tagů, ale to je otázka, jestli by to nemělo negativní vliv na párování. na budovy bych to asi (aspoň v tuhle chvíli) nepřeváděl, protože budov je v osm nesrovnatelně méně než adresních bodů. osobně ani netuším, zda je tohle tagování adresních bodů (amenity apod) ok nebo by se to mělo dělat jinak.
    V budoucnu bude asi problém se jmény ulic http://tools.geofabrik.de/osmi/?view=addresses&lon=15.18443&lat=50.46818&zoom=18&opacity=0.97&overlays=buildings,buildings_with_addresses,postal_code,nodes_with_addresses_defined,nodes_with_addresses_interpolated,no_addr_street,street_not_found,interpolation,interpolation_errors,connection_lines,nearest_points,nearest_roads Tím tvým postupem se vlastně i aktualizuje název ulice u adresního bodu. Ulici na Václava Havla bude muset přejmenovat člobrda.
    přesně tak, bot by měl zvládnout i přejmenování ulic na adresních bodech (ale ne na ulicích). určitě by nebyl problém někam reportovat změnu názvu ulice (adresy obecně), aby to pak někdo mohl ručně zkontrolovat a zaktualizovat případně související objekty (název ulice apod).
    Mirek
    ff
  8. Mirek Dlask dlask.m na gmail.com #mdd9d01
    Test box na duplicity 14.9 50.44 , 14.92 50.41 Není to celá MB. Kněžmost - místo kde č.p. nedostavají domy ale dvorky .-) http://maps.fordfrog.com/?zoom=18&lat=50.49012&lon=15.03952&layers=B00FFF
  9. Jan Bilak jan.bilak.osm na gmail.com #mcd6689
    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
  10. vrs na email.cz vrs na email.cz #m1baed0
    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í? Jan
  11. Miroslav Šulc fordfrog na fordfrog.com #m6543fa
    Ahoj, jak ten bot rychlý? Aneb za jak dlouho by zpracoval (pokusně) celou ČR - tedy vygeneroval log?
    no, chvíli by mu to asi trvalo, ale v tom nevidím problém. až budu mít aspoň trochu jistotu, že z toho nepolezou bláboly, tak to můžu zkusit na celé čr. akorát mám trochu obavy z toho, že ten log bude až moc velký.
    Můžeš udělat histogram vzdáleností spárovaných bodů?
    nad tímhle už jsem přemýšlel. zkusím to rozdělit po nějakých rozumných intervalech a přidám to do těch výstupních statistik.
    Honza
    ff
  12. Miroslav Šulc fordfrog na fordfrog.com #me1180d
    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
  13. Miroslav Šulc fordfrog na fordfrog.com #m026d13
    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/M5AwaeFN<http://pastebin.com/jtbpMzdX> tady je část mladé boleslavi a kosmonos: http://pastebin.com/jtbpMzdX ff
  14. Jakub Sykora kubajz na kbx.cz #m5e3ff1
    Dobra prace! Opravdu ocenuju tolik vlozeneho usili. Zda se, ze automaticky import je precijen realny! K
  15. Mirek Dlask dlask.m na gmail.com #mbce448
    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
  16. Libor Pechacek lpechacek na gmx.com #mf67941
    [...]
    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
  17. Libor Pechacek lpechacek na gmx.com #mf85583
    Ahoj,
    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
  18. Mirek Dlask dlask.m na gmail.com #mdaf036
    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
  19. Miroslav Šulc fordfrog na fordfrog.com #mb96095
    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
  20. Miroslav Šulc fordfrog na fordfrog.com #mc2ca0b
    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
  21. Mirek Dlask dlask.m na gmail.com #m690878
    Chajdy jsou na webu OK. * Definiční bod adresního místa ID 1857484 FID 80901527 DOMOVNICISLO 102 TYPDOMCISLA 2 ORIENTACNICISLO PARCELNICISLO 1575 PARCELAPODLOMENI 4 DRUHPARCCISLA 2 KODKATASTRU 669857 NAZEVULICE NAZEVOBCE KOSMONOSY IDOB 1030274321 CUZKBUD_ID 0 IDADR 30019308531 ULICE_ID PSC 29306 CASTOBCE Kosmonosy Definiční bod adresního místa ID 2655618 FID 22030160 DOMOVNICISLO 175 TYPDOMCISLA 2 ORIENTACNICISLO PARCELNICISLO 1575 PARCELAPODLOMENI 13 DRUHPARCCISLA 2 KODKATASTRU 669857 NAZEVULICE NAZEVOBCE KOSMONOSY IDOB 1030275327 CUZKBUD_ID 373189207 IDADR 30015238474 ULICE_ID PSC 29306 CASTOBCE Kosmonosy Ještě jsem narazil na jeden problém - dvě skoro stejná čp. Mladá Boleslav, Hwiezdoslavova 699/11 Mladá Boleslav, tř. Václava Klementa 699 Nám asi nevadí... Ač nejsem Boleslavák, nějak moc se v ní poslední dobou rýpu ;-) Mirek *
  22. jzvc jzvc na tpfree.net #m8f4e15
    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.
    Vidis, tohle je jeden z duvodu, proc sem proti mazani cehokoli. Mimochodem, patri ty adresy (bez tech souradnic) nejakym budovam se souradnicemi? Bylo by zajimavy z toho vytahnout nejaky pocet.
    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.
    Da se to v praxi i s adresou na budovu - dalsi duvod proc preferovat adresu na budove, kam logicky patri. Amo, pokud je v budove vice, daj se dalsi body do ni. Ale prevazne ma budova jako takova nejaky primarni ucel. Jinak, pokud mas na budeove amenity, renederuje se ta prednostne pred adresou, ale vyheldavanim to samozrejme najdes a zaroven mas informaci, ze toto patri teto budove.
  23. Miroslav Šulc fordfrog na fordfrog.com #m465c28
    Ž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.
    Vidis, tohle je jeden z duvodu, proc sem proti mazani cehokoli. Mimochodem, patri ty adresy (bez tech souradnic) nejakym budovam se souradnicemi? Bylo by zajimavy z toho vytahnout nejaky pocet.
    být proti mazání čehokoliv je podle mě dost jednobarevný a předčasný pohled. robot je zatím stále ještě v syrové podobě. podle mě až bude ve finální podobě a vyjede z něj, co on by měl v úmyslu smazat a porovnáme to s realitou, tak pak bude teprve zřejmé, jestli mazat nebo nemazat. jinak co se týče počtu adresních bodů, které nemají souřadnice, ale budova, na které jsou, má v db souřadnice, jsou počty následující: adresní body bez souřadnic: 205488 související budova má souřadnice: 66463 související budova má obrys: 36657 překryv jsem nezjišťoval. použití těchhle souřadnic by mohlo trochu pomoct, ale i tak zbydou body bez souřadnic. ale to by neměl být problém pořešit. databáze je kvůli tomuhle bugu http://trac.osgeo.org/postgis/ticket/1936 už docela zastaralá, protože jí nemůžu aktualizovat. situace v datech tudíž může být už jiná, snad lepší, ale dokud někdo ten bug nefixne, tak jsme v tomhle směru na mrtvém bodě. já bohužel céčko ovládám mizivě, takže s tím asi nic neudělám.
    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.
    Da se to v praxi i s adresou na budovu - dalsi duvod proc preferovat adresu na budove, kam logicky patri. Amo, pokud je v budove vice, daj se dalsi body do ni. Ale prevazne ma budova jako takova nejaky primarni ucel.
    no, já osobně preferuju používat vždy jeden způsob implementace něčeho než jich mít několik různých. v případě adresních bodů narážím na to, že jsou budovy, které mají víc adresních bodů. další problém je, že v osm nemáme ani zdaleka 100% budov. navíc adresní bod může určovat i umístění vchodu.
    Jinak, pokud mas na budeove amenity, renederuje se ta prednostne pred adresou, ale vyheldavanim to samozrejme najdes a zaroven mas informaci, ze toto patri teto budove.
    tady já vidím problém v tom, že v mapě se taková informace skryje. navíc stejně jako u adresních bodů, amenity umístěné přesně nad místem, kde skutečně existuje, je podle mě přidanou hodnotou mapy ve srovnání s unifikovaným zobrazením na středu budovy. ff
  24. Václav Řehák rehakv01 na gmail.com #m15ebe1
    Da se to v praxi i s adresou na budovu - dalsi duvod proc preferovat adresu na budove, kam logicky patri. Amo, pokud je v budove vice, daj se dalsi body do ni. Ale prevazne ma budova jako takova nejaky primarni ucel.
    To mi připadá jako hodně odvážné tvrzení. Co třeba běžný obytný činžák, který má v přízemí železářství a pekárnu? Jaký je primární účel takové budovy?
  25. Pavel Machek pavel na ucw.cz #m61906a
    Da se to v praxi i s adresou na budovu - dalsi duvod proc preferovat adresu na budove, kam logicky patri. Amo, pokud je v budove vice, daj se dalsi body do ni. Ale prevazne ma budova jako takova nejaky primarni ucel.
    To mi připadá jako hodně odvážné tvrzení. Co třeba běžný obytný činžák, který má v přízemí železářství a pekárnu? Jaký je primární účel takové budovy?
    No, je to "bezny obytny cinzak", tak primarni ucel nejspis bude obytna... Pavel
Napsat odpověď e-mailem… Odpovědět

Otevře váš e-mailový klient. Odpovědi pak sledujte zde na webu.