Ahoj, právě mě přestává bavit přesouvat tisíce adresních bodů, které jsou posunuty o 3 domy vedle. Uvažuji o něčem, co by mělo mělo zbytek importu výrazně urychlit. Jak určíme, kde má v OSM být adresní bod? Návrh: 1.) vezmeme ho z OSM - je do 0.5m od hranic stavebního objektu? Ano, OK, bereme z OSM, není co řešit. - nejsou hranice SO, leží adresa v OSM do 3m od definičního bodu SO? OK, není co řešit - není def. bod SO? Leží v OSM bod do 3m od souřadnic AM v RUIAN? OK, není co řešit. Pokud jsme neuspěli, pokračujeme 2.) Souřadnice AM z RUIAN - jsou souřadnice AM v RUIAN do 0.5m od hranic SO? OK, bereme souřadnice AM z RUIAN - nejsou hranice SO, leží AM v RUIAN do 3m od definičního bodu SO? OK, bereme souřadnice AM z RUIAN Pokud jsme neuspěli, pokračujeme 3.) ST_Centroid hranic SO - nachází se definiční bod SO uvnitř hranic SO či do 1m od hranic? (*viz poznámka dole) OK, bereme ST_Centroid SO. Pokud jsme neuspěli, pokračujeme 4.) Definiční bod SO Pokud jsme neuspěli, bereme souřadnice z OSM. Pokud bod nemáme v OSM, máme smůlu ;-). V RUIAN jsou AM, která nemají žádné souřadnice. * poznámka: jak jsem psal, definiční bod SO může ležet jednotky či desítky km od hranic stavebního objektu. Takových chyb je v RUIAN několik stovek včetně oné rekordní 221km. Velmi podezřelých je pak asi 1500 (třeba definiční bod SO je 100 metrů od hranic). Potřebuji ovšem vědět, co je to definiční bod, tedy hlavně mě zajímá, zda definiční bod správně musí ležet na povrchu polygonu hranic. Mějme budovu ve tvaru U, pak ovšem ST_Centroid nebude ležet na povrchu polygonu. http://postgis.refractions.net/docs/ST_Centroid.html - obrázek vlevo dole. V tomto případě ST_Contains(hranice_SO,adresni_bod) vráti false. Takže asi tolerovat nějakou vzdálenost definičního bodu SO od jeho hranic? Jakou? Výsledkem tohoto postupu by mělo být, že jediná varování, která by měl řešit člověk, by byla "AM blízko u sebe". Importoval bych už jen po celých polygonech, tedy obcích (včetně obcí Plzeň, Jihlava a podobných velkých měst; už jich moc nezbývá. Asi i Brno.) Proč po jasných polygonech? Protože vše, co má nějaký addr: a po tomto procesu zůstane uvnitř tohoto přesného polygonu, to bych zlikvidoval. Když se dívám na ortofoto míst, která zbudou (to jsou ty hlášky "V OSM je nějaký bod s adresou podezřele blízko"), pak v naprosté většině je to zbořeniště či dům, který i z leteckého snímku vypadá, že se brzy rozpadne sám. V menšině jsou to domy, svítící novotou a tak asi ještě nemají nové číslo. Tímto postupem bychom se také vyhnuli reimportu - tedy kompletnímu smazání všech adres a jejich novému vytvoření. Ten systém reimportu funguje, ale ještě jsem ho naostro nepoužil. Nakonec by zbyly oblasti, kde je velmi vysoký počet duchů uvnitř budovy, tuším, že například Mníšek pod Brdy. V těchto případech by se asi vyplatilo počkat, až budou duchové odstraněni, protože importem bychom si OSM spíš zaplevelili. Tento postup by se týkal i následných, tedy už probíhajících, aktualizací už importovaných území. Pokud je item_timestamp AM v RUIAN novější než timestamp, kdy jsme místo importovali, tak se zaktualizuje. Tak co kdo na to? -- Petr, pv na propsychology.cz zobrazit citaci

Dne Ne 29. června 2014 12:58:26, Petr Vejsada napsal(a): Tak, folks, je to nakódováno, funguje to naprosto perfektně. Zbývá ošetřit případ, kdy adresní bod sedí na nějakém shopu či hospodě a bot usoudí, že by měl změnit souřadnice. V tomto případě bych volil cestu sundat adresní tagy ze shopu a bod vytvořit nový. V souvislosti s tím se nabízí otázka, zda to nedělat rovnou a všude - tedy když bude adresa na man_made, historic, shop, amenity, (... co dalšího?), tak jí odstranit a udělat samostatný bod. Další varianta - dělat to i v případě, že adresa je na cestě (budova) nebo dokonce na relaci. Škoda, že jsme toto nevymysleli hned na začátku; to by bylo ušetřené práce. Ono to totiž řeší prakticky všechny situace. Špatně umístěný bod v OSM, špatně umístěné adresní místo v RUIAN, když je AM daleko od SO a dokonce i to, když polygon SO je úplně jinde, než má být. Jediné, co to neřeší, je duch uvnitř budovy/zdvojené adresní body, protože není jak poznat, který je skutečný a který ne. Nedá mi to, abych neukázal obrázek, jak bot srovnal špatně umístěné adresy: http://pedro.poloha.net/osm/josm.png Jediné mírné riziko vidím v tom, že tento režim zlikviduje z daného polygonu vše, co má nějakou adresu (přesněji zlikviduje jen ty adresní tagy) a není to v RUIAN. V praxi to bude, myslím, výjimečná věc. v RUIAN spíš leccos přebývá než že by chybělo. Statistiky pokusného běhu - obec Plzeň: count | kdesevzal -------+----------- 18740 | 1 - bod je umístěn správně, do 0.5m od hranic SO a definiční bod SO je v pořádku, tedy není nikde mimo. Zůstávají souřadnice z OSM 274 | 2 - SO nemá hranice, adresa je do 3 metrů od definičního bodu, zůstavají souřadnice z OSM 6124 | 4 - souřadnice se vzaly z geometrie adresního bodu z RUIAN - adresní bod v RUIAN leží do vzdálenosti 0.5m od hranic SO a definiční bod SO je v pořádku 197 | 5 - souřadnice se vzaly z geometrie AM. SO nemá hranice, geometrie AM v RUIAN lezi do 3m od definicniho bodu. 94 | 6 - Souřadnice se vzaly ze st_centroidu hranic SO. Definiční bod SO je v pořádku. Pravděpodobně geometrie AM buď chybí nebo je AM v RUIAN ustřeleno někam daleko 135 | 7 - souřadnice se vzaly z definičního bodu SO, protože vše předtím selhalo. 1 | 8 - všechno selhalo, souřadnice se berou z OSM (pokud jsou) 15 | <NULL> - souřadnice nejsou relevantní, adresa je na cestě nebo relaci. V Plzni se bot chystá zlikvidovat 503 adresních entit. Namátková kontrola neodhalila žádnou chybu. Také ještě trochu si pohrát s konstantami, možná by šla tolerovat větší vzdálenost od SO než je 0.5m. Ta stejná statistika s rozlišením, zda se AM nově vytváří (true) nebo zda už v OSM bylo (false): count | nove_vytvoreny_bod | kdesevzal -------+--------------------+----------- 18740 | f | 1 274 | f | 2 5682 | f | 4 442 | t | 4 168 | f | 5 29 | t | 5 85 | f | 6 9 | t | 6 78 | f | 7 57 | t | 7 1 | t | 8 15 | f | (12 řádek) Tak co kdo na to? -- Petr zobrazit citaci ...

Ahoj! zobrazit citaci zobrazit citaci No, pekne, ale jak chudak programator zjisti adresu daneho obchodu? A... bude ten postup fungovat i na data mimo ceskou republiku? Primlouval bych se adresy z obchodu (etc) nemazat, aspon pokud jsou souradnice "uveritelne". Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Narazil jsem na budovu, kde byly asi 3 POI různě uvnitř polygonu a na každém z nich adresa. Také jsem narazil na polygon ohraničující golfové hřiště, který měl přiřazenou adresu. Chápu to dobře, že skript počítá i s těmito variantami? JAnD Dne 29. června 2014 20:13 Petr Vejsada <osm na propsychology.cz> napsal(a): zobrazit citaci

On Mon, Jun 30, 2014 at 08:21:45AM +0200, Jan Dudík wrote: zobrazit citaci z tohoto duvodu jsem Petra zacal tlacit do samostatnych adresnich bodu, pro jeden objekt, jeden adresni bod a hotovo. Jinak jsou tam duplicity, chyby se resi mnohem hur, pripadne zmena POI znamena problemy (nekdo smaze i s adresou apod.) Ano, jak pak ziskat adresu daneho POI nevim (teda ne ze to nejde ale tohle jsem nikdy neresil, tak neznam moznosti a potreby). Bye -- Tomas Kasparek e-mail: kasparek na fit.vutbr.cz CVT FIT VUT Brno, L127 jabber: tomas.kasparek na jabber.cz Bozetechova 1, 612 66 web : http://www.fit.vutbr.cz/~kasparek Brno, Czech Republic phone : +420 54114-1220 GPG: 2F1E 1AAF FD3B CFA3 1537 63BD DCBE 18FF A035 53BC May the command line live forever! ------------- další část --------------- A non-text attachment was scrubbed... Name: [žádný popis není k dispozici] Type: application/pgp-signature Size: 213 bytes Desc: [žádný popis není k dispozici] URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20140630/a0b1c650/attachment.sig>

zobrazit citaci *** příspěvek k debatě. Definice Adresního Místa dle zákona: "Adresním místem je takové místo v terénu, kterému lze ve vztahu ke stavebnímu objektu přiřadit adresu" http://geoinformatics.fsv.cvut.cz/data/2014/06-12/05-Formanek-Geoinformatics-2014.pdf#page=18 http://www.zakonyprolidi.cz/cs/2009-111#p29-d ha hanoj Dne 29. června 2014 12:58 Petr Vejsada <osm na propsychology.cz> napsal(a): zobrazit citaci

Ahoj, tohle je docela velky zasah a je rozhodne ho potreba promyslet. Mam trochu strach z toho to delat uplne automatizovane. zobrazit citaci když zobrazit citaci jí zobrazit citaci že zobrazit citaci Ovsem z hlediska toho, jak svet funguje, muze mit obrys budovy adresu, ktera obsahuje pouze cast obce a cislo popisne/evidencni (a nema zadnou ulici ani cislo orientacni, protoze to uz je jen u bezneho AM). Mam za to, ze takova adresa na dome je korektni, dokonce uzitecna, protoze muzu najit "Liben 2295" a tady timhle bys mi ji smazal. Takhle automaticke mazani z cest ani relaci se mi moc nelibi. Stejne tak se mi na prvni pohled moc nelibi, ze by se mazala adresa z POI (man_made, historic, ...). Prece jen si s tim nekdo dal nejakou praci, kdyz to tam dal a my to ted jen tak smazeme? Asi bych jeste unesl, kdyby se to delalo rucne, tedy ze by nekdo zkontroloval, jestli pobliz je adresa z RUIAN a ta adresa na POI je stejna a pak ji smazal. Zdravi, Dalibor

Zdravím všechny, zkusím se dotknout všeho takto v jedné zprávě. Měl jsem na mysli technickou stránku věci, ale měl jsem tušit, že spustím nové kolo debaty. O mazání či nemazání tagů z amenit se tu diskutovalo už několikrát. Mám za to, že většina byla pro mazání, aby tam nebylo více stejných adres, které je pak problém udržovat. Adresní místo není nic, co by se často měnilo. Některé může být stále stejné desítky let. Přesto v celorepublikovém měřítku ke změnám dochází. Mám vyřešen způsob aktualizace a také jsem ho už několikrát použil, tedy zatím pokusně. První kolo bylo Praha-Prosek, druhé kolo celá Praha a třetí kolo celá republika najednou. Zdá se, že vše funguje úplně OK. Jen počítám s tím, že jedno adresní místo je jedno adresní místo, nikoli dvě či pět. Ty obchody ve skutečnosti žádnou adresu nemají. Adresa je - jak psal hanoj - místo v terénu vztažené ke *stavebnímu objektu*. Obchod není žádný stavební objekt, ale sídlí ve stavebním objektu, stejně jako tam sídlí další firmy či bydlí lidé. Odbíhám - mám za to, že to mazání se provádí už teď několik týdnů/měsíců. Jen je to otrocká práce spolupracovníků a toto má jen odstranit tuto otrockou práci. Navrhuji tedy toto - objekty/tagy neodstraňovat, ale přidat k nim nějaký tag, jako treba czechaddress=deleteme či tak něco. Každý ze spolupracovníků se pak může rozhodnout, jak s tím naloží. Například si v JOSM vybere czechaddress=deleteme a všechny vybrané smaže či z nich odstraní adresní tagy. Nebo je nechá být a jen odstraní vlastní tag czechaddress=deleteme. Nebo je všechny projde jeden po druhém. Plzeň, na které jsem to testoval, obsahuje něco přes 500 kandidátů na smazání. Chtěl jsem proces jen co nejvíce usnadnit. Úctu k práci jiných, myslím, mám, přesto bez ostychu mažu budovy a adresy, které neexistují. Jen z piety bych je v OSM nenechával - ještě že tu nemáme odbor památkové péče ;-). To by mohlo přiměřeně platit i pro technický pokrok. Nepotřebujeme tagovat adresou každý kámen. Kdybychom už tedy opravdu měli, pak jen referencí na existující adresu a ne stejná data duplikovat. Pavlovi - jak má chudák programátor najít adresu, na které se obchod nachází? Jakou adresu má lékárna na souřadnicích 50.1072394, 14.3922216? Programátor nechť si naprogramuje jednoduchý skript, jehož výstupem bude: "curl http://nominatim.openstreetmap.org/reverse?format=xml&lat=50.1072394,&lon=14.3922216&zoom=18&addressdetails=1" Lékárna tuto adresu nemá, opakuji, má ji ten dům. Lékárna se nachází v domě s adresou 1570/14a, Zelená, Dejvice, Praha, okres Hlavní město Praha, Hlavní město Praha, Praha, 16000, Česko, což bude i v odpovědi na uvedený http dotaz. Modifikovat lze i na "http://localhost/reverse....", případně mohu dodat funkci reversegeocode do Postgisu. Chtěl bych si hlavně ujasnit, jak tyto multiadresy udržovat. Mám při změně adresy hledat nekonečné množství entit v okolí, z nich sundat staré tagy a nasadit nové? Chtěl bych si to jen ujasnit, nechci si prosazovat svojí hlavu. K Daliborovi - není třeba před mazáním kontrolovat, zda tam adresa z RUIAN je či není. Je tam (pokud nechybí v RUIAN). Adresa POI často stejná nebývá; bývá neúplná nebo naopak přeplněná (country, city). K tomu hledání Libeň 2205 - jo, tento nedostatek Nominatimu mě pěkně štve. Stačilo by place a housenumber. Klidně mohu přidat body s těmito dvěma tagy všude, kde součástí adresy je ulice. Asi jen body, protože budovy v OSM někdy neodpovídají realitě či RUIAN. Pak by bylo ještě potřeba dořešit, co s budovami, které mají více adres. tedy více čísel popisných. Všechny je plácnout na jeden bod? Tohle by šlo udělat, jen nevím, zda na to nebudeme potřebovat další schvalovací proces. Ten bych asi už nepřežil ;-). Abych se jen nechválil, tak v průběhu testování jsem narazil na dvě nepěkné věci. První je estetická. Pokud jsou v oblasti adresní body umístěné mimo, tak existuje nějaká rozhodná hodnota, která když je překročena, tak se bod posune. Jestliže se v oblasti ta nepřesnost pohybuje kolem této rozhodné hodnoty (třeba vzdálenost do 2 metrů od SO), tak některé body ji překročí a některé ne. Výsledkem je pak nehezky vypadající mapa, kdy některé body jsou hezky seřazené třeba nad vchody či uprostřed domu a jiné jsou prostě šoupnuté, protože jejich odchylka od umístění nepřekročila prahovou hodnotu. Druhý problém, se kterým si teď vůbec nevím rady, je stuace "dům místo nádvoří". Nenapadá mě nic, jak tuto anomálii zjistit. V tomto případě může dojít k posunu správně umístěného bodu na špatné místo. Přesto bych zvážil - jednu část Brna, čítající 1000 adres, dělal kolega 8 hodin. Já jsem na tom pak pracoval další 2.5 hodiny a nejsem si úplně jist, zda by to nechtělo ještě další práci. To byl také jeden z hlavních impulzů, proč začít ty posuny řešit. Ještě poznámka nakonec - vše uvedené se týká pouze zbytku probíhajícího importu, nikoli aktualizací už importovaných území. Aktualizace probíhá 1 změna v RUIAN = 1 změna v OSM, tedy si žádných okolních adres nevšímá. Může se ovšem stát, že když adresa na obchodě bude úplná a bude blíže souřadnicím v RUIAN, tak bot udělá změnu na té adrese s obchodem a tu "oficiální" nechá na pokoji. -- Petr

Ahoj! Jenom k těm poi... zobrazit citaci Nedá se prostě "kontrolovaný" adresní bod odlišit od POI za běhu podle toho jestli tak je nějaký druh ruian id (ano) versus tagy mimo addr:* (ne)? Potom by se daly všechny POI ignorovat a bude... Osobně bych byl spíš za schopnost nástrojů zachovat adresu na poi, protože... zobrazit citaci ...toto je sice formálně zcela správně, ale v realitě "tam venku" obchod lokalizuje právě adresa - nikdo si nepíše souřadnice :-D Vazba tam tedy je, a v současných frontendech k osm se bohužel předpokládá explicitní: iD má políčka pro adresu jako součást toho co se dá/má pro poi nastavit. Nevím tedy jak moc je reálné "spravit všechny ostatní lidi"? Hezký večer, Vláďa

Ahoj, Dne Út 1. července 2014 00:03:34, Vladimír Slávik napsal(a): zobrazit citaci teď nejde o budoucí aktualizace, v nich snad problém není, jde o způsob dokončení importu, který se snažím ještě více zautomatizovat, protože zbývající území jsou náročná, pracná. "Kontrolovaným" bodem se stane ten, který se nejlépe shoduje s adresou v RUIAN. Všechny nemají RUIANID. Může to být samostatný bod, budova, relace (třeba budova s dírou) nebo také adresa na obchodě. Prostě ta entita, která se nejlépe shoduje. To, co na území zbude - není to v RUIAN - předpokládám, že neexistuje a patří pryč. Dá se udělat, že se tedy tagy z obchodů odstraňovat nebudou; pak ovšem není záruka, že jsou správné. zobrazit citaci :-), ven chodím každý den, takže tak zlé to se mnou není. On tu asi převažuje názor v závislosti na tom, kteří lidé tuto konferenci v dané době čtou. Buďto tedy vím adresu obchodu, pak jí zadám do vyhledávače, vyhledávač mi najde adresní místo a v okruhu těch několika metrů už snad ten obchod najdu. Druhá varianta - adresu obchodu neznám a chci jí zjistit. Najdu si tedy obchod podle názvu a čtvrti, zjistím jeho souřadnice a zeptám se, co je na těch souřadnicích za adresu. Otázka byla, jak to má programátor udělat. Jistě že všude se najdou výjimky - může existovat 50 m dlouhý dům nebo celé tržiště s jednou adresou. Nu, vidím to tedy na pravidlo nevšímat si entit, které mají fyzické tagy (amenity, shop ...) ? -- Petr zobrazit citaci

zobrazit citaci A co udelat malou hlasovaci stranku na wiki, kde bys navrhl, ze ty adresni tagy z POI budes mazat a dat treba mesic na to, aby se k tomu lidi, co ctou konferenci jednoznacne vyjadrili? Dalibor

zobrazit citaci *** myslíš adresu sídla podnikání, místa podnikání nebo sídla pobočky? *** jak charakterizuje POI jeho adresa v nákupním centrum, obchodním domě? zobrazit citaci *** předělávat lidi samozřejmě není nutné, stačí když robot ví co s tím ha hanoj

Ahoj, Dne Út 1. července 2014 14:35:21, Dalibor Jelínek napsal(a): zobrazit citaci zobrazit citaci možná ano, jak naložit s výsledkem? Kdyby bylo třeba 60 % lidí pro mazání, je to dost? IMO není. Navíc máme tady 4 varianty: 1.) Automaticky odstraňovat adresy ze všech fyzických objektů, pokud samostatný adresní bod není, tak ho vytvořit. Nepoužívat fyzické objekty pro jako adresní místa. 2.) Nechávat adresy na fyzických objektech tehdy, kdy je to jediné, botem vybrané "oficiální" adresní místo. Z případných ostatních fyzických objektů adresy odstranit. 3.) Nechat bota vybrat "oficiální" adresní místo bez ohledu na to, zda jde či nejde o fyzický objekt. Adresy na ostatních fyzických objektech ponechat. 4.) Fyzických objektů si vůbec nevšímat, tedy neodstraňovat z nich adresy, nepoužívat je jako "oficiální" adresní místo. Pokud samostatný "oficiální" adresní bod neexistuje, vytvořit ho (klidně paralelně s existujícími adresami na fyzických objektech). Na něco jsem zapomněl? Je třeba mít na mysli, že adresy na těch fyzických objektech jsou často neúplné - je tam jen popisné číslo nebo jen housenumber, jen ulice, jen ulice a housenumber atd. -- Petr

Ahoj, Dne Út 1. července 2014 14:58:55, hanoj napsal(a): zobrazit citaci tak tak, o to jde - snažím se tady dosáhnout dohody, jak to dělat. Paralelně s tím vyjadřuji svůj názor, což ovšem neznamená, že to nakonec bude podle mého. Díky. -- Petr

Ahoj, Dne 1.7.2014 19:02, Petr Vejsada napsal(a): zobrazit citaci Přesně z toho důvodu jsem pro smazání. Neúplné adresy v OSM nepotřebujeme. Stejně to nikdo neudržuje. Z importu adres si pamatuji snad jen jednu korektní adresu. Na golfovém hřišti. Ale i to hřiště má nějakou správní budovu, které je ta adresa přiřazena. Z logiky věci. Adresní místo je vázáno na objekt. Mělo by tedy být uvnitř daného objektu (vím, adresy na nádvoří tomu trochu odporují, ale to se časem vyřeší). Pokud tedy chci zjistit adresu nějakého POI umístěného v budově, tak stačí najít adresní bod ležící ve stejné budově. Pokud v budově není adresa, zkusím najít nejbližší adresu v okolí. A když se nepovede, tak vrátím nejnižší administrativní celek (třeba část obce). Úplně jiná situace je v případě adresy na nějakém kusu šutru venku v přírodě (památník ;-) ). Ten, pokud to není přímo budova, většinou leží vně budovy, dokonce může být kilometry daleko od nejbližšího obydlí (třeba Poslední vlk v Beskydech). V tomto případě nelze žádná adresa přiřadit a neměla by tam být. Když se budu chtít k takovému památníku dostat, potřebuji buď popis cesty, nebo mapu případně mapu a souřadnice. Mimochodem, jak hledáte nějakou adresu? Zadáte do nominatimu a podíváte se na mapě, kde to je v prostoru. Je to mnohem jednodušší, než jezdit křížem krážem po Dlouhé Lhotě a hledat č.p. 99. Může se stát, že ani místní nebudou vědět, kde to č.p. 99 je. Zato kde je ve vsi hospoda, budou určitě vědět všichni ;-) Marián zobrazit citaci

On Tue, Jul 01, 2014 at 10:59:04PM +0200, Marián Kyral wrote: zobrazit citaci Po zkusenostech z importu jsem pro s doplnenim toho co psal Marian o adresach na vecech, co nejsou budouvy (ale budou takove vubec v RUIAN tj. bude se jich tykat import?) zobrazit citaci Bye -- Tomas Kasparek e-mail: kasparek na fit.vutbr.cz CVT FIT VUT Brno, L127 jabber: tomas.kasparek na jabber.cz Bozetechova 1, 612 66 web : http://www.fit.vutbr.cz/~kasparek Brno, Czech Republic phone : +420 54114-1220 GPG: 2F1E 1AAF FD3B CFA3 1537 63BD DCBE 18FF A035 53BC May the command line live forever! ------------- další část --------------- A non-text attachment was scrubbed... Name: [žádný popis není k dispozici] Type: application/pgp-signature Size: 213 bytes Desc: [žádný popis není k dispozici] URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20140702/7dc8c7ec/attachment.sig>

Cau, tady uplne nesouhlasim. Ja myslim, ze mame dva ruzne druhy adres: a) adresa domu cast obce - cislo popisne/evidencni ta je uvedena v RUIAN u stavebniho objektu (SO) b) adresa vchodu ulice - cislo popisne/evidencni - cislo orientacni - cast obce - psc ta je uvedena v RUIAN jako adresni misto (AM), ktere by melo byt pripojeno k SO, ale casto neni a existuje samo o sobe Podle me by idealne adresa a) mela byt na outline cele budovy, protoze je to prave budova, ktera ma cislo popisne/evidencni. Adresa b) by pak mela byt na vchodu do budovy, tedy na jednom bodu, ktery je soucasti outline budovy a je oznaceny jako entrance=yes. Tohle je samozrejme idealni predstava, ke ktere by se mel RUIAN i OSM blizit. Priklad je treba tady http://www.openstreetmap.org/way/62173897#map=19/50.10810/14.48417 Co udela automaticky script s adresou typu a), kterou jsem pridal na outline domu? Smaze mi ji? Proc? Dokaze nejak overit, ze je dobre, kdyz ten dum samotny v RUIAN neni? Pocitam, ze automatickym importem z RUIAN asi nedokazeme urcit presne a zakreslit ty adresy vchodu do mapy primo do outline budovy, ale melo by se pocitat s tim, ze to uz nekdo tak udelal a nemazat mu to. Jak to poznat? Snad tim, ze ten bod sice neni na poloze, ktera je v RUIAN, ale ma uz ref:ruian:addr. zobrazit citaci Jak pisu, idealne by melo byt na outline budovy v miste vchodu. Kdyz nevime, tak asi uvnitr budovy pobliz vchodu. A kdyz nevim ani to, tak bych ho spise nechal tam, kde ho ma RUIAN, pokud to vypada pravdepodobne, ze tam patri. Nebo ne? A pokud AM lezi velky kus od SO, ke kteremu by melo patrit, tak bych to mozna snad ani do OSM neimportoval, protoze se asi bude jednat o chybu v RUIAN a do te doby nez se opravi v RUIAN, tak to bez ni v OSM asi prezijeme. zobrazit citaci budově zobrazit citaci tak zobrazit citaci Tohle nebude fungovat moc dobre. V te budove, kterou ukazuji nahore, treba sidli fa Sunnysoft, ktera ma vlastni vchod s cislem 1a. Kdybych tam daval POI, tak ho placnu nekam pobliz vchodu 1a, ale i tak bude nebezpecne blizko adrese 1 i 3. Tady by bylo lepsi, kdyby mel adresu i primo na sobe. Ale na druhou stranu je fakt, ze se bez toho da obejit, protoze kdyz najdu Sunnysoft, tak i kdybych ho nasel na adrese 1 nebo 3 misto 1a, tak bych ho v realite taky dohledal a postacka doufejme take. Takze tedy hlasuji pro mazani adres z POI (ale ne z building=*). Nevim, jestli souhlasite s moji vizi idealniho zakreslovani adres obou typu, ale zda se mi nejvic v souladu s realtiou a RUIAN a jen jsem na to chtel upozornit, nez se vytvori nejaky script, ktery na tohle nebude myslet. Zdravi, Dalibor

Ahoj, On Wed, Jul 02, 2014 at 09:52:38AM +0200, Dalibor Jelínek wrote: zobrazit citaci Udělá s ní to, na čem se dohodneme. zobrazit citaci na ref:ruian:addr spolehnout nelze, protože ne všechny body v OSM ho mají. Ty body, které byly zakresleny před lety a jsou v pořádku, tak ho nemají. Bot na ně nesahá. Bot nebude šoupat body v OSM za předpokladu, že leží v "rozumné" vzdálenosti od hranic SO (momentálně nastaveno 3.5 metru) či leží v "rozumné" vzdálenosti od definičního bodu (momentálně nastaveno 12 metrů). zobrazit citaci Část, která rozhoduje o poloze adresního bodu v OSM je zde: http://pedro.poloha.net/osm/poloha-am.sql , jsou tam komentáře. Nejvíce důvěryhodná informace v RUIAN je definiční bod SO a z toho vychází i ten SQL. Umisťuje adresní body správně (tedy pokud za "správně" lze uznat, i když bod není přesně nad vchodem ;-)). Největší problém jsou duchové uvnitř budovy. Včera jsem nahrával CZ update a opět potvrzuji, že duchové uvnitř budovy z RUIAN mizí. Možnost je zatím neimportovat území s relativně velkým výskytem duchů uvnitř budovy nebo ta území importovat, ale bez těch adres, které se vztahují ke dvojicím budova-duch v budově. K tomu označování budov jen addr:place a addr:conscriptionnumber (provisionalnumber) - jediný smysl vidím kvůli Nominatimu, který umí hledat buďto podle addr:place nebo podle addr:street, ale neumí obojí současně. Před pár dny jsem psal, že bych klidně zavedl tyto body (place a číslo) do OSM - odvolávám - je jich více než 1.5 milionu - tak pokud to vyjednáš se Serge ... ;-) Myslím, že chybovost bota je teď srovnatelná s chybovostí člověka, přičemž jeho rychlost s rychlostí člověka srovnatelná není. Chybovostí teď myslím, že by posunul adresu v OSM na méně vhodné místo, než byla předtím. Zato dokáže během pár minut přesunou stovky adres, které jsou 3 baráky vedle. K importu zbývá už "jen" 700 tis. adres, tak zvažme, nakolik je reálné projít jednu adresu po druhé člověkem, jaké škody může bot způsobit, když občas šoupne adresu z místa nad vchodem na místo uprostřed baráku a jak dlouho trvalo šoupat 1000 adres v Brně ručně (celé hodiny) a výsledek nejspíš i tak není tak dobrý, jako od bota. Pojďme teď řešit, jak to dělat s těmi "zbylými" adresami - na shopech, budovách atd. zobrazit citaci a co když bude (a není to vzácné) amenity=car_repair building=yes ? zobrazit citaci no ten smysl vidím jen tam, kde jsou ulice kvůli tomu Nominatimu. -- Petr

Dne 30.6.2014 19:14, Petr Vejsada napsal(a): zobrazit citaci Cus, jen jedna pripominka, ktera jiste zaznela uz nekolikrat ... sam sem navrhoval adresni bod tam, kde budova byla, ale uz treba neni a tam kde budova je, priradit adresu ji. Nekdo totiz muze hledat, kde takova adresa byla, pripadne se pouziva v ramci lokalni znalosti k navigaci typu "prijed ke kominu" a to i kdyz tam ten komin uz 20 let nestoji. Samozrejme nemam problem s likvidaci duplicit a jineho chaosu. co se tyce "viceadresnych" budov ... tech co si pamatuju bylo v celkovem objemu nepatrne mnoztvi a muzou se poresit rucne. zobrazit citaci Nemas tak uplne pravdu ;D. Cp/Co/... patri budove, ale to nezmanema, ze v te budove nemuze existovat subjekt, se zcela vlastni adresou - klidne s vlastnim PSC. Pokud bys heldal kompletni seznam PSC, tak se obavam, ze .... ho nijak snadno nesezenes (to co si muzes sosnout na webu posty neni komplet). zobrazit citaci Vysat extra, nebo je aspon nejak oznacit, neplacat na sebe, to se neda editovat, aspon metr od sebe. Dost casto se takova budova da vpohode rozdelit na vice budov (byt to stavebne je jedina, tak trebas panelakovy vchody ...) zobrazit citaci

Ahoj, Dne Pá 4. července 2014 20:49:00, jzvc napsal(a): zobrazit citaci na takovou připomínku si nevzpomínám, ale má paměť není dokonalá ;-). To bych řešil jako place=locality, name="U komína". S adresou, která byla a už není, to si teď rady nevím. Mrkl jsem na Wiki, kde se píše o 4. dimenzi OSM, tedy o času, zbouraných objektech, demolished, abandoned, construction, ale k adresám a času žádnou nápovědu nenacházím. Zase jsem tak moc nehledal. Užitečné to může být, je nutné nějaké označení, že to už neplatí. Nevím, možná zase využít locality? zobrazit citaci Díval jsem se na Kolín, kde už import proběhl. Bylo to hrozně pracné, adresy posunuté hodně daleko a nepravidelně. Prohlédl jsem si mapu a zjistil, že se ani za mnoho hodin ruční práce nepodařilo vychytat zdaleka všechno. Tak jsem na to pustil tu novou verzi bota. Polohově umravnil asi 500 adres a 28 smazal. Byly tam adresní body v místech, kde podle fotek budovy už velmi dlouho nejsou. Ve dvou případech jsem si tedy nebyl jist - v RUIAN byla adresa aktivně smazaná, ale dům na fotografii stál a rozhodně nevypadal, že se chystá rozpadnout. Možná to smazání tedy byla chyba, ale pokud tam adresa má být, tak se tam dříve či později objeví v aktualizaci z RUIAN. zobrazit citaci :-)n na procenta nepatrné množství, ale je jich drobet přes 24 tisíc. U tohoto pořád nevím, k čemu to má sloužit. To hledání podle čtvrti a čísla by bylo super. Máme možnosti počkat, až to bude Nominatim umět, zapojit se do vývoje Nominatimu nebo tam přidat ty dvojice číslo/část obce. Míst bez ulice a s ulici je skoro přesně půl na půl: count | jeulice ---------+--------- 1426741 | f 1468004 | t nemůžeme tam jen tak nandat milion a půl dalších dat. Na budovy to už nepůjde vůbec - budovy v OSM neodpovídají budovám v RUIAN, digitální mapa v RUIAN není všude ... možná za pár let by to šlo. zobrazit citaci Vlastní PSČ firmy mají, to vím, ale adresu? Že by měly jinou ulici, jiné číslo domovní? To se mi nezdá, ale nemohu vyvrátit. Tato PSČ v RUIAN asi nejsou - zkoušel jsem to na České Televizi, která má svoje PSČ. V RUIAN nejsou; jsou tam "standardní" PSČ. Dvořákova 18, Ostrava je ostravské studio, podle webu Televize má svoje PSČ, v RUIAN není. zobrazit citaci Asi se tu míchají 2 rozdílné, byť související věci. Jedna je nahrát do OSM všechny údaje z adresních míst, které mají ulici, ještě jednou, aby je Nominatim našel i bez uvedení ulice. Je jich 1.4 milionu, tedy moc, toto neprojde. Druhá věc je označit všechny budovy s více adresami (24 tisíc) a tam ten přínos moc nechápu. Dá se to v pohodě najít i teď - příkladem je dotaz "Technická 1902", zkus si. -- Petr

Ahoj! zobrazit citaci Proc si to radsi nenajdu na googlu? :-). Sorry, odkaz na nominatim, ktery mozna obcas funguje neni uplne to co jsem chtel. zobrazit citaci A ano, lekarna tu adresu ma, protoze kdyz do ty lekarny budu chtit poslat dopis, budu tam muset napsat adresu [vchodu do] lekarny. Jinymi slovy -- myslim, ze by bylo dobry mit v mape nejaky spojeni mezi POI a adresou toho POI, protoze dotaz "jaka je postovni adresa danyho POI" dava dobry smysl. Funguje ten nominatim? Aha, a odpoved je ze nominatim nefunguje: http://wiki.openstreetmap.org/wiki/Nominatim/FAQ#How_was_the_address_calculated.3F How was the address calculated? For features down to street level addresses are calculated using a combination of admin boundaries, is_in tags and place features. For building level features addresses are calculated using the address of the most suitable street. If no explicit boundaries or relations are include the system will fall back to a simple 'nearest' calculation - this will often be wrong! Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Dobrý den, zobrazit citaci zobrazit citaci číslo domovní? To se >mi nezdá, ale nemohu vyvrátit. zobrazit citaci svoje PSČ. V RUIAN >nejsou; jsou tam "standardní" PSČ. Dvořákova 18, Ostrava je ostravské studio, podle webu >Televize má svoje PSČ, v RUIAN není. ... ano to mohu potvrdit. V RÚIAN jsou pouze tzv. územní PSČ, která se vztahují k území. Dále Česká Pošta (ČP) provozuje tzv. speciální PSČ, která se vztahují k osobě (firmě). Tato PSČ nejsou vázána k území, ale k firmě. Bohužel již několik let se snažíme získat z ČP aktuální seznam těchto vazeb PSČ x IČO firmy, ale zatím neúspěšně. Těchto speciálních firemních PSČ existuje cca 3500 ks. Dále existují PSČ, která jsou přidělena P.O.Boxům a ani tato PSČ v RÚIAN nevedeme. Petr Souček

Ahoj, Dne Ne 6. července 2014 11:01:45, Pavel Machek napsal(a): zobrazit citaci zobrazit citaci i já se omlouvám, je mi jasné, že to není to, co jsi chtěl a rýpanec to byl, dokonce vědomý. Promiň. zobrazit citaci S tím úplně souhlasím, že vazba by měla být. Jen si nemyslím, že ideální vazbou je tu adresu zduplikovat. IMO by byl vhodný odkaz na ID adresy (té hlavní, jediné). To teď taky nepůjde. Každá adresa není v OSM označena RUIANID a i kdyby byla, tak bychom to označování pomocí ID mohli udělat, ale žádný stávající program s tím nebude umět pracovat. Mně jde hlavně o to, aby adresy v OSM byly aktualizovatelné a aktualizované. Jak to udělat? Dejme tomu, že by na POI adresy byly. (duplicitní). Pak bych prosil, aby byly kompletní, ne jen housenumber, jen ulice atd. Asi by šlo napsat kód, který rozparsuje nekompletní adresu, z ní vyextrahuje domovní číslo, ulici a případné číslo orientační a podle toho se rozhodnout, ke které oficiální adrese tento poi patří a tu adresu na něm zkompletovat. Pokud by na poi nebylo dost údajů pro zjištění konkrétní adresy (např. byla by jen ulice, město a stát), tam bych ji opravdu smazal. To by se dalo i při aktualizacích. Když dojde ke změně adresního místa, bot by tak, jako doposud, nalezl adresu v OSM s největší shodou a tu by použil jako tu hlavní. Následně by se rozhlédl kolem po poi, zda v okolí nejsou nějaké poi, které k této adrese patří, tedy mají stejnou adresu. Ty by zaktualizoval také. Primární adresy bych na poi nenechával, takže bych to udělal tak, že pokud hlavní adresa bude na poi, vytvořil bych ji vedle ještě jednou samostatně. Pak by proběhl výše popsaný algoritmus rozhlédnutí se v okolí po poi. Ze svého návrhu nejsem úplně nadšen, ale vzhledem k okolnostem a momentálnímu stavu OSM, software atd. by to takto mohlo být průchozí. Tak co kdo na to? zobrazit citaci S těmi is_in ve skutečnosti moc nepracuje, nominatim na propsy:~/Nominatim$ grep -lri is_in * osm2pgsql/osm2pgsql osm2pgsql/build_geometry.o osm2pgsql/m4/ax_lua.m4 osm2pgsql/output-gazetteer.o osm2pgsql/output-gazetteer.c osm2pgsql/autom4te.cache/traces.0 osm2pgsql/autom4te.cache/traces.2 osm2pgsql/autom4te.cache/requests utils/tigerAddressImport.py koukal jsem do zdrojáku a vidím, že celá práce s is_in je jen vyextrahování country code. V případě Tiger dat je to to samé; v CZ nerelevantní. zobrazit citaci To se CZ netýká! Mluvíme ovšem o úrovni budov - adresy na polygonech budov nemáme, tedy ano, může se stát, že nejbližší adresa bude jiná než ta, na které lékárna sídlí. Tak se prosím, kdo chcete, vyjádřete k tomu návrhu způsobu, jakým aktualizovat adresy na POI. -- Petr

Ahoj, údržba adres na POI se ukazuje natolik komplikovaná, že je nereálná. Pokud by to vůbec šlo s dostatečnou spolehlivostí, vyžadovalo by to další desítky hodin práce a ty tomu už nedám. Jestliže je tedy odpor (jako že je) vůči mazání adres na POI, nebudu si POI všímat vůbec. Kdybych si jich všímal a pracoval s nimi, mohlo by docházet k jejich posunu a to u obchodů asi není dobré. Nemá smysl dělat seznam POI, který je na importovaném území - k čemu by to bylo? Nechme tedy POI být, ať si mají adresy, jaké mají, ať už správné či nesmyslné. Dalibore, prosím tě, napiš mi nějaký algoritmus, jakým poznám ty budovy, které jsou schválně označeny addr:place a addr:*number. Jsou vůbec takové na území, které se má ještě zpracovat? Pokud jich není moc, třeba by se hodil jejich seznam ;-). Zakomponuji to tam nějak tak, aby si bot těchto budov také nevšímal. Jiné řešení už mě nenapadá a bylo by fajn, kdyby se ten import dotáhl do konce. -- Petr

Ahoj, Ať hledám jak hledám, nedaří se mi najít nějaký popis jak zacházet s adresou na POI. Jestli ti tam vůbec dávat. Všude u adresy se píše jen o budovách. Nic o POI. U POI (alespoň ty cou jsem zkoumal - třeba hotel) se zase nepíše o adrese. Ale možná jen špatně hledám. Ta vazba adresní bod - POI by šla zařídit pomocí relace type=site [ http:// wiki.openstreetmap.org/wiki/Relation:site (http://wiki.openstreetmap.org/wiki/Relation:site) ] A way to group of features, for example buildings or amenities, which belong together. Examples: the various facilities associated with a school, college, university, airport or military bases. Jsem pro to, aby se adresy na POI ignorovaly. Maximálně by bylo vhodné vyjet z databáze nějaký seznam POI s nekompletní/nesprávnou adresou - má minimálně jeden klíč addr:* a nemá ruian id. To by mohla být nějaká simple query pro OverPass api. Marián

Ahoj, taky si myslim, ze v soucasne dobe bude lepsi nechat POI s adresou na pokoji. Lepsi bude, kdyz dotahnes import adres, nez se ted zasmodrchat v tom jak spravne znacit POI a domy. Tomu se da venovat kdykoliv pozdeji. Co se tyce budov s adresou, ktere jsou schvalne oznaceny addr:place a addr:*number, tak tech asi moc nebude. Naloz s nimi stejne, jak nakladas se zbytkem adres. Tech asi ctyrech domu, ktere jsme takhle experimentalne oznacil, zadna skoda nebude a nevim o tom, ze by to nekde nekdo masivne takhle znacil. Zdravi, Dalibor zobrazit citaci desítky zobrazit citaci POI zobrazit citaci k zobrazit citaci nesmyslné. zobrazit citaci tam zobrazit citaci

zobrazit citaci *** Odpor tu byl, ale nebylo navrženo jiné řešení než nic nedělat, což mne mrzí. Takže budu-li proti tomuto odporu, diskuze se vzájemně vyruší ;) ? Také je zřejmé, že "jindy" znamená "nikdy". A teď k věci. Z 53 000 POI (node.shop+node.amenity) má adresu 5%, takže použití této vazby je v hypotéze její potřebnosti prakticky k ničemu. Kdežto funkční, referenční a jednotný a aktualizovatelný systém adres můžeme mít letos. ha hanoj

Ahoj, Dne Út 8. července 2014 06:26:05, Marián Kyral napsal(a): zobrazit citaci to by mohlo být tím, že POI žádnou adresu nemají; tu mají jen budovy (v české terminologii a přesněji stavební objekty) ;-) zobrazit citaci Bingo! Tak mám námět, co dělat po dokončení importu :-) zobrazit citaci Nj, wtf "nekompletní adresa"? Že nemá ruianid nic neříká - to nemá spousta adres. Ty, co jsou v OSM celé roky a jsou správně, tak na ty jsme nesahali - viz Serge, takže takhle se poznat nedají. -- Petr

Ahoj, Dne Út 8. července 2014 09:10:26, Dalibor Jelínek napsal(a): zobrazit citaci jj zobrazit citaci Koumal jsem, když se podívám na tu tvou vzorovou budovu, tak se ničím neliší od regulérní adresy domu bez ulice. Jedině snad tím, že v okolí je stejné č.p., které ulici má. No poměr adres s ulicí a bez ulice je cca 1:1, tak ty 4 dohledatelnost adres opravdu moc neovlivní. Rozbít ti je můžu jen na dosud neimportovaných územích - při aktualizacích se to nestane. Při aktualizacích se maže jen to, co bylo smazáno v RUIAN a ještě tam je navíc kontrolní mechanizmus, který počítá, kolik adres s tímto č.p. /nebo č.ev.) je v okolí a nesmaže nic, pokud by počet adres v OSM poklesl pod počet adres v RUIAN. Tak jo, díky za vstřícnost. -- Petr

zobrazit citaci - viz zobrazit citaci Ja mych myslel, ze vyhledove by bylo fajn doplnit to RUIAN ID i k tem, co jsou spravne, jinak nebude fungovat aktualizace podle RUIAN. Nebo bude aktualizace parovat i adresy, ktere jsi ted nechal na pokoji? Zdravi, Dalibor

AHoj, Dne Út 8. července 2014 09:30:08, hanoj napsal(a): zobrazit citaci :-))) zobrazit citaci Jindy znamená tehdy, kdy bude shoda (=nikdy) ;-). Technicky jsem na to vybaven, trvalo by tak hoďku-2 napsat skript, který by to udělal globálně v celé ČR. Nechme to na pak, ty relace vypadají slibně. Ostatně myslím na to, že bych měl vyhledat a odstranit kůly v plotě - volné uzly, které nemají žádné tagy a nejsou součástí ničeho. Pár desítek tisíc jich bude. zobrazit citaci

Ahoj, Dne Út 8. července 2014 10:47:12, Dalibor Jelínek napsal(a): zobrazit citaci Aktualizace nebude fungovat, aktualizace funguje. Mrkni na changesety CzechAddress, které se jmenuji "CZ update". Bylo by fajn, kdyby to zkouklo ještě jiné oko než mé. Tedy doufám, že to funguje. -- Petr