« zpět na výpis měsíce |

[Talk-cz] rúian bot - první výsledky testů

Vlákno 5.8. - 21.8.2012, počet zpráv: 25


5.8.2012 11:30:11 (#1)
gravatar

Miroslav Šulc

<fordfrog at fordfrog.com>
101
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 ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120805/085c5fb2/attachment.html> ------------- další část --------------- A non-text attachment was scrubbed... Name: ruian-bot.zip Type: application/zip Size: 30341 bytes Desc: [žádný popis není k dispozici] URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120805/085c5fb2/attachment.zip> ------------- další část --------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4475 bytes Desc: Elektronicky podpis S/MIME URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120805/085c5fb2/attachment.bin>

6.8.2012 04:54:09 (#2)
gravatar

Mirek Dlask

<dlask.m at gmail.com>
107
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 <fordfrog na fordfrog.com> napsal(a): zobrazit citaci
> 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 > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120806/14736f2b/attachment.html>

6.8.2012 08:05:22 (#3)
gravatar

hanoj

<ehanoj at gmail.com>
718
zobrazit citaci
> 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ů) ? zobrazit citaci
> 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

6.8.2012 12:08:59 (#4)
gravatar

Miroslav Šulc

<fordfrog at fordfrog.com>
101
Dne 6.8.2012 04:54, Mirek Dlask napsal(a): zobrazit citaci
> 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. zobrazit citaci
> > 150 je fakt nějak moc > > Mirek
ff ------------- další část --------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4475 bytes Desc: Elektronicky podpis S/MIME URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120806/8b8b5141/attachment.bin>

6.8.2012 12:29:37 (#5)
gravatar

Miroslav Šulc

<fordfrog at fordfrog.com>
101
Dne 6.8.2012 08:05, hanoj napsal(a): zobrazit citaci
>> 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. zobrazit citaci
>> 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.) zobrazit citaci
> h. > hanoj
ff ------------- další část --------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4475 bytes Desc: Elektronicky podpis S/MIME URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120806/f5e6775d/attachment.bin>

6.8.2012 03:00:58 (#6)
gravatar

Mirek Dlask

<dlask.m at gmail.com>
107
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 Dne 6. srpna 2012 12:29 Miroslav Šulc <fordfrog na fordfrog.com> napsal(a): zobrazit citaci
> Dne 6.8.2012 08:05, hanoj napsal(a): > >> 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 > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120806/33e28d32/attachment.html>

6.8.2012 03:27:34 (#7)
gravatar

Miroslav Šulc

<fordfrog at fordfrog.com>
101
Dne 6.8.2012 15:00, Mirek Dlask napsal(a): zobrazit citaci
> > 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. zobrazit citaci
> 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í. zobrazit citaci
> 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. zobrazit citaci 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). zobrazit citaci
> > Mirek
ff zobrazit citaci
> > Dne 6. srpna 2012 12:29 Miroslav Šulc <fordfrog na fordfrog.com > <mailto:fordfrog na fordfrog.com>> napsal(a): > > Dne 6.8.2012 08:05, hanoj napsal(a): > >> 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 > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org <mailto:Talk-cz na openstreetmap.org> > http://lists.openstreetmap.org/listinfo/talk-cz > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120806/6d8a34b1/attachment.html> ------------- další část --------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4475 bytes Desc: Elektronicky podpis S/MIME URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120806/6d8a34b1/attachment.bin>

6.8.2012 04:02:57 (#8)
gravatar

Mirek Dlask

<dlask.m at gmail.com>
107
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 Dne 6. srpna 2012 15:27 Miroslav Šulc <fordfrog na fordfrog.com> napsal(a): zobrazit citaci
> Dne 6.8.2012 15:00, Mirek Dlask napsal(a): > > > 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 > > > Dne 6. srpna 2012 12:29 Miroslav Šulc <fordfrog na fordfrog.com> napsal(a): > >> Dne 6.8.2012 08:05, hanoj napsal(a): >> >> 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 >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> > > > _______________________________________________ > Talk-cz mailing listTalk-cz na openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-cz > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120806/f7baa1db/attachment.html>

6.8.2012 04:04:40 (#9)
gravatar

Jan Bilak

<jan.bilak.osm at gmail.com>
149
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 <dlask.m na gmail.com> napsal(a): zobrazit citaci
> 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 <fordfrog na 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=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 >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

6.8.2012 05:04:39 (#10)
gravatar

vrs na email.cz

<vrs at email.cz>
44
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 zobrazit citaci
> ------------ Původní zpráva ------------ > Od: Jan Bilak <jan.bilak.osm na 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 <dlask.m na 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 <fordfrog na 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=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 > >> > >> _______________________________________________ > >> Talk-cz mailing list > >> Talk-cz na openstreetmap.org > >> http://lists.openstreetmap.org/listinfo/talk-cz > >> > > > > > > _______________________________________________ > > Talk-cz mailing list > > Talk-cz na openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk-cz > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >

6.8.2012 07:07:41 (#11)
gravatar

Miroslav Šulc

<fordfrog at fordfrog.com>
101
Dne 6.8.2012 16:04, Jan Bilak napsal(a): zobrazit citaci
> 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ý. zobrazit citaci
> 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. zobrazit citaci
> Honza
ff zobrazit citaci
> > > Dne 6. srpna 2012 4:54 Mirek Dlask <dlask.m na 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 <fordfrog na 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=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 >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz
------------- další část --------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4475 bytes Desc: Elektronicky podpis S/MIME URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120806/05d75f0b/attachment.bin>

6.8.2012 07:27:13 (#12)
gravatar

Miroslav Šulc

<fordfrog at fordfrog.com>
101
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 Dne 6.8.2012 16:02, Mirek Dlask napsal(a): zobrazit citaci
> 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 > > > > Dne 6. srpna 2012 15:27 Miroslav Šulc <fordfrog na fordfrog.com > <mailto:fordfrog na fordfrog.com>> napsal(a): > > Dne 6.8.2012 15:00, Mirek Dlask napsal(a): >> >> 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 > >> >> Dne 6. srpna 2012 12:29 Miroslav Šulc <fordfrog na fordfrog.com >> <mailto:fordfrog na fordfrog.com>> napsal(a): >> >> Dne 6.8.2012 08:05, hanoj napsal(a): >> >> 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 >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org <mailto:Talk-cz na openstreetmap.org> >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org <mailto:Talk-cz na openstreetmap.org> >> http://lists.openstreetmap.org/listinfo/talk-cz > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org <mailto:Talk-cz na openstreetmap.org> > http://lists.openstreetmap.org/listinfo/talk-cz > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120806/a455ea29/attachment.html> ------------- další část --------------- A non-text attachment was scrubbed... Name: ruian-bot-mb.zip Type: application/zip Size: 51243 bytes Desc: [žádný popis není k dispozici] URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120806/a455ea29/attachment.zip> ------------- další část --------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4475 bytes Desc: Elektronicky podpis S/MIME URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120806/a455ea29/attachment.bin>

7.8.2012 12:46:58 (#13)
gravatar

Miroslav Šulc

<fordfrog at fordfrog.com>
101
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 Dne 6.8.2012 19:27, Miroslav Šulc napsal(a): zobrazit citaci
> 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: > ...
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120807/ad98d7bc/attachment.html> ------------- další část --------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4475 bytes Desc: Elektronicky podpis S/MIME URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120807/ad98d7bc/attachment.bin>

7.8.2012 12:44:28 (#14)
gravatar

Jakub Sykora

<kubajz at kbx.cz>
617
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): zobrazit citaci
> 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 > > 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

7.8.2012 09:43:19 (#15)
gravatar

Mirek Dlask

<dlask.m at gmail.com>
107
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 <fordfrog na fordfrog.com> napsal(a): zobrazit citaci
> 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 > > > >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120807/fb3c1527/attachment.html>

7.8.2012 09:47:36 (#16)
gravatar

Libor Pechacek

<lpechacek at gmx.com>
68
On Mon 06-08-12 19:27:13, Miroslav Šulc wrote: [...] zobrazit citaci
> 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

7.8.2012 09:53:54 (#17)
gravatar

Libor Pechacek

<lpechacek at gmx.com>
68
Ahoj, On Mon 06-08-12 17:04:39, vrs na email.cz wrote: zobrazit citaci
> 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 zobrazit citaci
> Jan > > > > ------------ Původní zpráva ------------ > > Od: Jan Bilak <jan.bilak.osm na 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 <dlask.m na 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 <fordfrog na 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=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 > > >> > > >> _______________________________________________ > > >> Talk-cz mailing list > > >> Talk-cz na openstreetmap.org > > >> http://lists.openstreetmap.org/listinfo/talk-cz > > >> > > > > > > > > > _______________________________________________ > > > Talk-cz mailing list > > > Talk-cz na openstreetmap.org > > > http://lists.openstreetmap.org/listinfo/talk-cz > > > > > > > _______________________________________________ > > Talk-cz mailing list > > Talk-cz na openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk-cz > > > > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz
--

7.8.2012 10:17:11 (#18)
gravatar

Mirek Dlask

<dlask.m at gmail.com>
107
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 <lpechacek na gmx.com> napsal(a): zobrazit citaci
> 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120807/515e9259/attachment.html>

7.8.2012 10:26:28 (#19)
gravatar

Miroslav Šulc

<fordfrog at fordfrog.com>
101
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): zobrazit citaci
> 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 <lpechacek na gmx.com > <mailto:lpechacek na 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 na openstreetmap.org <mailto:Talk-cz na openstreetmap.org> > http://lists.openstreetmap.org/listinfo/talk-cz > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120807/08d0090e/attachment.html> ------------- další část --------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4475 bytes Desc: Elektronicky podpis S/MIME URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120807/08d0090e/attachment.bin>

7.8.2012 11:13:56 (#20)
gravatar

Miroslav Šulc

<fordfrog at fordfrog.com>
101
Dne 7.8.2012 21:43, Mirek Dlask napsal(a): zobrazit citaci
> 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. zobrazit citaci
> > Ž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. zobrazit citaci
> 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ú? zobrazit citaci
> Č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. zobrazit citaci
> 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. zobrazit citaci
> > 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. zobrazit citaci
> 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 zobrazit citaci
> > Dne 6. srpna 2012 19:27 Miroslav Šulc <fordfrog na fordfrog.com > <mailto:fordfrog na 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120807/2138ca15/attachment.html> ------------- další část --------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4475 bytes Desc: Elektronicky podpis S/MIME URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120807/2138ca15/attachment.bin>

7.8.2012 11:50:12 (#21)
gravatar

Mirek Dlask

<dlask.m at gmail.com>
107
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 * Dne 7. srpna 2012 23:13 Miroslav Šulc <fordfrog na fordfrog.com> napsal(a): zobrazit citaci
> 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 <fordfrog na 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 listTalk-cz na openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-cz > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120807/2295cf92/attachment.html>

20.8.2012 07:36:02 (#22)
gravatar

jzvc

<jzvc at tpfree.net>
556
Dne 7.8.2012 23:13, Miroslav Šulc napsal(a): zobrazit citaci
> 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.
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. zobrazit citaci
> >> 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. zobrazit citaci
> >> 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 <fordfrog na fordfrog.com >> <mailto:fordfrog na 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 na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120820/721dbe47/attachment.html>

20.8.2012 09:54:38 (#23)
gravatar

Miroslav Šulc

<fordfrog at fordfrog.com>
101
Dne 20.8.2012 19:36, jzvc napsal(a): zobrazit citaci
> Dne 7.8.2012 23:13, Miroslav Šulc napsal(a): >> Dne 7.8.2012 21:43, Mirek Dlask napsal(a): >>> Ž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. zobrazit citaci
>>> 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. zobrazit citaci
> 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 ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120820/aa3b27f9/attachment.html> ------------- další část --------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4475 bytes Desc: Elektronicky podpis S/MIME URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120820/aa3b27f9/attachment.bin>

21.8.2012 09:31:38 (#24)
gravatar

Václav Řehák

<rehakv01 at gmail.com>
63
Dne 20. srpna 2012 19:36 jzvc <jzvc na tpfree.net> napsal(a): zobrazit citaci
> 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?

21.8.2012 12:50:16 (#25)
gravatar

Pavel Machek

<pavel at ucw.cz>
1056 1226
On Tue 2012-08-21 09:31:38, Václav Řehák wrote: zobrazit citaci
> Dne 20. srpna 2012 19:36 jzvc <jzvc na tpfree.net> napsal(a): > > > 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 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

« zpět na výpis měsíce