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

2012-08-20 Thread jzvc 
Dne 7.8.2012 23:13, Miroslav Šulc napsal(a):
> 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.

>
>> 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.

>
>> 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 > > 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
>> Matc

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

2012-08-20 Thread Miroslav Šulc 
Dne 20.8.2012 19:36, jzvc napsal(a):
> 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.

>>> 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


smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz