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

[Talk-cz] Adresy z RUIAN

Vlákno 11.2. - 18.2.2014, počet zpráv: 63


11.2.2014 01:06:30 (#1)
gravatar

Petr Vejsada

<osm at propsychology.cz>
516
Ahoj, také jsem pilný a zdá se, že nástroj na nahrávání adres z RUIAN je hotov. Funguje tak, že se vybere oblast, pustí se SQL skript a za pár (desítek) minut je připravený changeset pro JOSM. K tomu z toho vypadnou varovací tabulky se seznamem míst, kde si to neporadilo a chce to lidský průzkum. Počet vět v těchto tabulkách je nepřímo úměrný kvalitě dat v RUIAN v dané oblasti ;-) Podle tabulek s problémy se pak dají patřičná místa pravit v JOSM před uploadem. Potřebuji se domluvit na podobě dat. Tyto tagy se zpracovávají: addr:city - obec addr:conscriptionnumber - číslo popisné addr:housenumber - složenina, jak je popsaná na Wiki, tedy ev.<evidenční> či <popisné>/<orientační> atd, addr:provisionalnumber - evidenční číslo addr:streetnumber - číslo orientační addr:place - část obce addr:street - ulice addr:postcode - PSČ source:addr=cuzk:ruian ref:ruian=<rn_adresni_misto.kod> Na ostatní tagy nesahám, tedy nesahám ani na is_in, source, addr:country či další addr: či ne-addr:. Nesahám ani na souřadnice. Algoritmus je osmiprůchodový, z toho 6 průchodů je na vlastní přiřazení a zbylé 2 jsou na generování varovných tabulek. Zdrojáky tajné nejsou, je to 100% plpgsql/postgis, nicméně netvořil jsem to pro uživatele, ale pro sebe a tak kód odráží moji místní situaci - vyžaduje schema RUIAN, OSM APIDB (nikoli samotné API, jen databázové schema) a Mapnik schema. Urcite by slo predelat pro snapshot schema, které má sympatický HSTORE, ale v tuto chvíli to tak není hlavně proto, protože snapshot schema nemám. Pracuje to se všemi typy entit - s body, cestami/polygony i relacemi. Nalezne- li entitu s adresou (což nalezne skoro vždy), upraví ji tak, že nahradí výše zmíněné tagy a ostatních si nevšímá. Nenalezne-li, vytvoří nový adresní bod se souřadnicemi z RUIAN, a to buď deiniční bod adresního místa, není-li, pak deiniční bod stavebního objektu, není-li tak st_centroid stavebního objektu. Není-li, tak nic; na parcelu už jsem nešel, mohlo by to být geometricky dost mimo. Co se týká mazání, tak momentálně se nic nemaže. Pamatuji si, který den to zpracuje která data a může pak porovnávat s RUIAN a mazat by se mohlo tehdy, kdy se adresa smaže z RUIAN a zároveň bylo toto místo zpracováno. Zásadní otázka č.1 - co s tagy addr:country a is_in? Možnosti jsou ponechat, mazat či nahrazovat. Jaký máte názor? Zásadní otázka č.2 - zda do toho vůbec jít, tedy začít probírat celou republiku a pokud ano, co je třeba předtím udělat? O pravidlech pro importy ponětí mám a tak zahajuji diskusi s místní komunitou ;-). Mojí motivací bylo a je hlavně to, že Nominatim ve stávajících datech moc hledat neumí, protože is_in ho vůbec nezajímá, takže hlavně přidat addr:place, sjednotit vše a snad tedy zlepšit. -- Petr, pv na propsychology.cz zobrazit citaci
>p<

11.2.2014 06:07:17 (#2)
gravatar

Marián Kyral

<mkyral at email.cz>
2389 2735
Dne 11.2.2014 01:06, Petr Vejsada napsal: zobrazit citaci
> Ahoj, > > také jsem pilný a zdá se, že nástroj na nahrávání adres z RUIAN je > hotov. > Funguje tak, že se vybere oblast, pustí se SQL skript a za pár > (desítek) minut > je připravený changeset pro JOSM. K tomu z toho vypadnou varovací > tabulky se > seznamem míst, kde si to neporadilo a chce to lidský průzkum. Počet vět > v > těchto tabulkách je nepřímo úměrný kvalitě dat v RUIAN v dané oblasti > ;-) > Podle tabulek s problémy se pak dají patřičná místa pravit v JOSM před > uploadem. >
Ty tabulky mají stejný formát jako to csv co jsi posílal? Nebylo by lepší ty sporné body nějak označit? Třeba tagem fixme. Líp se to pak bude v JSOM hledat/opravovat. zobrazit citaci
> Potřebuji se domluvit na podobě dat. > > Tyto tagy se zpracovávají: > > addr:city - obec > addr:conscriptionnumber - číslo popisné > addr:housenumber - složenina, jak je popsaná na Wiki, tedy > ev.<evidenční> či > <popisné>/<orientační> atd, > addr:provisionalnumber - evidenční číslo > addr:streetnumber - číslo orientační > addr:place - část obce > addr:street - ulice > addr:postcode - PSČ > > source:addr=cuzk:ruian > ref:ruian=<rn_adresni_misto.kod> > > Na ostatní tagy nesahám, tedy nesahám ani na is_in, source, > addr:country či > další addr: či ne-addr:. Nesahám ani na souřadnice. > > Algoritmus je osmiprůchodový, z toho 6 průchodů je na vlastní přiřazení > a > zbylé 2 jsou na generování varovných tabulek. > > Zdrojáky tajné nejsou, je to 100% plpgsql/postgis, nicméně netvořil > jsem to > pro uživatele, ale pro sebe a tak kód odráží moji místní situaci - > vyžaduje > schema RUIAN, OSM APIDB (nikoli samotné API, jen databázové schema) a > Mapnik > schema. Urcite by slo predelat pro snapshot schema, které má sympatický > HSTORE, ale v tuto chvíli to tak není hlavně proto, protože snapshot > schema > nemám. >
Udělej tomu nějakou konfiguraci, případně by mohlo nastavit si nějaká ta synonyma. Koukal jsem, že postgresql by to měl umět. Myslím, že třeba pro studijní by se to mohlo hodit. zobrazit citaci
> Pracuje to se všemi typy entit - s body, cestami/polygony i relacemi. > Nalezne- > li entitu s adresou (což nalezne skoro vždy), upraví ji tak, že nahradí > výše > zmíněné tagy a ostatních si nevšímá. Nenalezne-li, vytvoří nový adresní > bod se > souřadnicemi z RUIAN, a to buď deiniční bod adresního místa, není-li, > pak > deiniční bod stavebního objektu, není-li tak st_centroid stavebního > objektu. > Není-li, tak nic; na parcelu už jsem nešel, mohlo by to být geometricky > dost > mimo. > > Co se týká mazání, tak momentálně se nic nemaže. Pamatuji si, který den > to > zpracuje která data a může pak porovnávat s RUIAN a mazat by se mohlo > tehdy, > kdy se adresa smaže z RUIAN a zároveň bylo toto místo zpracováno. > > Zásadní otázka č.1 - co s tagy addr:country a is_in? Možnosti jsou > ponechat, > mazat či nahrazovat. Jaký máte názor? >
Určitě nechat, případně opravit, ať je to aktuální. Když to tam zůstane, tak se nic strašného nestane. zobrazit citaci
> Zásadní otázka č.2 - zda do toho vůbec jít, tedy začít probírat celou > republiku a pokud ano, co je třeba předtím udělat? O pravidlech pro > importy > ponětí mám a tak zahajuji diskusi s místní komunitou ;-). >
Nebylo by škoda teď skončit, když už jsi tomu věnoval tolik času a energie? V nejhorším bych mohl udělal nějaký plugin, který by to dokázal využít. BTW: czechaddress plugin by asi chtěl taky opravit. Přidat možnost doplnit chybějící údaje z RUIAN (pokud jsou k dispozici). BTW 2: na Slovenském mailing listu je teď taky zajímavá debata o odresách: https://groups.google.com/forum/#!topic/osm_sk/YJr78HvG2TA Marián zobrazit citaci
> Mojí motivací bylo a je hlavně to, že Nominatim ve stávajících datech > moc > hledat neumí, protože is_in ho vůbec nezajímá, takže hlavně přidat > addr:place, > sjednotit vše a snad tedy zlepšit. > > -- > Petr, pv na propsychology.cz >> p< > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz

11.2.2014 07:31:47 (#3)
gravatar

Marián Kyral

<mkyral at email.cz>
2389 2735
Dne 11.2.2014 06:07, Marián Kyral napsal: zobrazit citaci
> Dne 11.2.2014 01:06, Petr Vejsada napsal: >> Zásadní otázka č.2 - zda do toho vůbec jít, tedy začít probírat celou >> republiku a pokud ano, co je třeba předtím udělat? O pravidlech pro >> importy >> ponětí mám a tak zahajuji diskusi s místní komunitou ;-). >> > Nebylo by škoda teď skončit, když už jsi tomu věnoval tolik času a > energie? > V nejhorším bych mohl udělal nějaký plugin, který by to dokázal využít. >
Tak mně tak napadá, nedalo by se to brát jako součást/rozšíření projektu Import Adres ČR? ( http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR ). Pak by celá ta procedura mohla být jednodušší. Marián

11.2.2014 08:39:22 (#4)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
Dne 11.2.2014 01:06, Petr Vejsada napsal(a): zobrazit citaci
> Co se týká mazání, tak momentálně se nic nemaže. Pamatuji si, který den to > zpracuje která data a může pak porovnávat s RUIAN a mazat by se mohlo tehdy, > kdy se adresa smaže z RUIAN a zároveň bylo toto místo zpracováno. > > Zásadní otázka č.1 - co s tagy addr:country a is_in? Možnosti jsou ponechat, > mazat či nahrazovat. Jaký máte názor?
Asi by bylo dobré udělat nějakou základní analýzu obsahu is_in tagu - pokud obsahuje jen část obce, obec, stát... (nebo čárkami oddelenou kombinaci), tak smazat. Pokud jsou všechna data is_in tagu obsažena ve strukturované podobě v addr:*, tak si myslím, že nemá cenu, aby nám tu nadále strašil. Zdraví, Petr Morávek aka Xificurk

11.2.2014 08:52:16 (#5)
gravatar

Petr Vejsada

<osm at propsychology.cz>
516
Ahoj, Dne Út 11. února 2014 06:07:17, Marián Kyral napsal(a): zobrazit citaci
> > těchto tabulkách je nepřímo úměrný kvalitě dat v RUIAN v dané oblasti > > ;-) > > Podle tabulek s problémy se pak dají patřičná místa pravit v JOSM před > > uploadem. > > Ty tabulky mají stejný formát jako to csv co jsi posílal? > Nebylo by lepší ty sporné body nějak označit? Třeba tagem fixme. Líp se > to > pak bude v JSOM hledat/opravovat.
to mě nenapadlo, zato mě napadlo, a je tam, do těch tabulek dát odkaz na http://localhost:8111 ..., takže zkopírovat url do prohlížeče a JOSM na to msto skočí. Výhoda je, že ty FIXME se nemusí pak v JOSM mazat. Varuje třeba před adresními body příliš blízko u sebe, ale stane se, že je to 100 garáží, kde je to legitimní a pak bych musel 100 garáží editovat, kdežto takto to stačí jen zkouknout a nechat být :) zobrazit citaci
> > schema. Urcite by slo predelat pro snapshot schema, které má sympatický > > HSTORE, ale v tuto chvíli to tak není hlavně proto, protože snapshot > > schema > > nemám. > > Udělej tomu nějakou konfiguraci, případně by mohlo nastavit si nějaká ta > synonyma. Koukal jsem, že postgresql by to měl umět. Myslím, že třeba > pro studijní > by se to mohlo hodit.
Hm, teď ne, možná někdy -> asi určitě ne, pže čas, musel bych studovat snapshot schema atd. a bez testování to nemá smysl. Může si to udělat, kdo bude chtít ;) zobrazit citaci
> > Zásadní otázka č.1 - co s tagy addr:country a is_in? Možnosti jsou > > ponechat, > > mazat či nahrazovat. Jaký máte názor? > > Určitě nechat, případně opravit, ať je to aktuální. Když to tam zůstane, > tak > se nic strašného nestane.
Ta varianta ponechat má nevýhodu, že data budou vlastně pocházet z různých zdrojů. addr:country a is_is bude z původního zdroje a zbytek z RUIAN, tak já bych to viděl buď na zahodit nebo přepsat. zobrazit citaci
> > > Zásadní otázka č.2 - zda do toho vůbec jít, tedy začít probírat celou > > republiku a pokud ano, co je třeba předtím udělat? O pravidlech pro > > importy > > ponětí mám a tak zahajuji diskusi s místní komunitou ;-). > > Nebylo by škoda teď skončit, když už jsi tomu věnoval tolik času a > energie? > V nejhorším bych mohl udělal nějaký plugin, který by to dokázal využít.
no něco s tím určitě naadresuji, otázka byla spíš na globálnost celé akce. Například okres Vyškov byl opravdu dost bílý. Naklikal jsem tam tisíce budov tracerem, takže je dobře otestovaný (známé bugy: bug serveru - když je oblouk tvořený tak mnoha body, že změna úhlu mezi třemi po sobě jdoucími body je méně než 3 stupně, tak ty body postupně zahodí úplně všechny a oblouk zmizí a bug pluginu - křížící se budovy - napojování). Ten okres Vyškov jsem zkoušel, všude OK, jen v samotném Vyškově pracují asi nějací horliví kartoilové, protože jsou tam mraky adresních bodů 2x i 3x na stejném místě. Liší se jménem ulice nebo dokonce částí obce (Vyškov X Vyškov- předměstí např.) -- Petr

11.2.2014 08:54:57 (#6)
gravatar

Petr Vejsada

<osm at propsychology.cz>
516
Dne Út 11. února 2014 06:07:17, Marián Kyral napsal(a): zobrazit citaci
> Ty tabulky mají stejný formát jako to csv co jsi posílal? > Nebylo by lepší ty sporné body nějak označit? Třeba tagem fixme. Líp se > to > pak bude v JSOM hledat/opravovat.
pro ty, co mají přístup sem do DB - jsou to view osmimport.warnings_view, osmimport.warnings_view_full a osmimport.morewarnings -- Petr

11.2.2014 09:01:07 (#7)
gravatar

Dalibor Jelínek

<dalibor at dalibor.cz>
415 1552
Ahoj, ja teda is_in tag rad nemam, protoze nevim, jak se ma spravne vyplnovat. Na druhou stranu se mi nezda hezke mazat neco, co nekdo do mapy s nejakym usilim pridal. Pokud opravdu dokazeme nahradit vse, co ted ten tag obsahuje, pak ano. Ale uz ted vim, ze zatim ten navrh PV neobsahuje vse, co je v is_in. V is_in jsou mestske casti (nekde) a stat, to tam zatim PV nema. Ja bych navrhoval, do tech adres pridavat : addr:country=CZ (czechaddress to tam dava a proc to vynechavat?) addr:suburb=Praha 14 (z městská část/obvod) A jeste, to povazuji za dost dulezite, ale uz je asi pozde, bych zmenil ref:ruian=<rn_adresni_misto.kod> na treba ref:ruian:am=<rn_adresni_misto.kod> Protoze, az budeme chtit pridavat jine veci z RUIAN, treba stavebni objekty, pak casem nevyhnutelne dojde k tomu, ze se dostane adresa z bodu na objekt a bude konflikt ref:ruian. Ale jestli je to uz pouzito na hodne mistech, pak asi nezbyde, nez ref:ruian brat jako ID pro adresni misto a jina ID znacit jinak. Co se tyce importu, pak bych radsi prosel tu proceduru znova pro RUIAN, nez rozsirovat jiz stavajici import. Klidne to vykomunikuju. Zdravi, Dalibor

11.2.2014 09:11:04 (#8)
gravatar

Dalibor Jelínek

<dalibor at dalibor.cz>
415 1552
zobrazit citaci
> Na ostatní tagy nesahám, tedy nesahám ani na is_in, source, addr:country
či zobrazit citaci
> další addr: či ne-addr:. Nesahám ani na souřadnice.
V mem okoli jsou bezne adresy treba v tomhle formatu. addr:conscriptionnumber=1068 addr:housenumber=1068/3 addr:postcode=19800 addr:street=Vlčkova addr:streetnumber=3 source:addr=uir_adr uir_adr:ADRESA_KOD=22412948 addr:conscriptionnumber=643 addr:country=CZ addr:housenumber=643/3 addr:street=Šedova addr:streetnumber=3 is_in=Černý Most, Praha, CZ source:addr=mvcr:adresa source:position=cuzk:km Zda se mi, ze treba v tom prvnim pripade bys mel smazat uir_adr: ADRESA_KOD, pokud v tom tagu neco zmenis. Nebo ne? Nebudeme mit pak zmatek v tom, z ceho ty udaje pochazi? Co tedy znamena, ze je adresa oznacena ref:ruian a source:addr= cuzk:ruian? Znamena to, ze jen ten text je z ruian a poloha ne? A kdyz budeme chtit naimportovat/zmenit i polohu podle RUIAN, pak to budeme znacit ref:ruian, source:addr= cuzk:ruian a source:position=cuzk:ruian? Jen bych to chtel mit ujasneno dopredu. Zdravi, Dalibor

11.2.2014 09:21:34 (#9)
gravatar

Petr Vejsada

<osm at propsychology.cz>
516
Dne Út 11. února 2014 09:11:04, Dalibor Jelínek napsal(a): Super postřehy, přesně o tom ta diskuse má být. Pokračuj/te ;) zobrazit citaci
> Zda se mi, ze treba v tom prvnim pripade bys mel smazat uir_adr: ADRESA_KOD, > pokud v tom tagu neco zmenis. Nebo ne? > > Nebudeme mit pak zmatek v tom, z ceho ty udaje pochazi? > > Co tedy znamena, ze je adresa oznacena ref:ruian a source:addr= cuzk:ruian? > Znamena to, ze jen ten text je z ruian a poloha ne? > A kdyz budeme chtit naimportovat/zmenit i polohu podle RUIAN, pak to > budeme znacit ref:ruian, source:addr= cuzk:ruian a > source:position=cuzk:ruian? > Jen bych to chtel mit ujasneno dopredu.

11.2.2014 11:49:11 (#10)
gravatar

Petr Vejsada

<osm at propsychology.cz>
516
Ahoj, Dne Út 11. února 2014 09:01:07, Dalibor Jelínek napsal(a): zobrazit citaci
> Ahoj, > ja teda is_in tag rad nemam, protoze nevim, jak se ma spravne vyplnovat. > Na druhou stranu se mi nezda hezke mazat neco, co nekdo do mapy > s nejakym usilim pridal. > Pokud opravdu dokazeme nahradit vse, co ted ten tag obsahuje, pak ano. > Ale uz ted vim, ze zatim ten navrh PV neobsahuje vse, co je v is_in. > V is_in jsou mestske casti (nekde) a stat, to tam zatim PV nema. > > Ja bych navrhoval, do tech adres pridavat : > addr:country=CZ (czechaddress to tam dava a proc to vynechavat?) > addr:suburb=Praha 14 (z městská část/obvod)
přidat stát není problém, otázka spíš je, zda to má smysl.? suburb - tabulka rn_spravni_obvod, ale tam je jen ta Praha zobrazit citaci
> > A jeste, to povazuji za dost dulezite, ale uz je asi pozde, bych zmenil > ref:ruian=<rn_adresni_misto.kod> > na treba > ref:ruian:am=<rn_adresni_misto.kod> > Protoze, az budeme chtit pridavat jine veci z RUIAN, treba stavebni objekty, > pak casem nevyhnutelne dojde k tomu, ze se dostane adresa z bodu > na objekt a bude konflikt ref:ruian.
V OSM už jsou tisíce stavebních objektů s ref_ruian=nnnnnn; někteří jsme byli pilní. Adresní místo jsem ještě nepřidal ani jedno, takže by to změnit šlo. zobrazit citaci
> Ale jestli je to uz pouzito na hodne mistech, pak asi nezbyde, nez ref:ruian > brat jako ID pro adresni misto a jina ID znacit jinak.
Spíš ref_ruian brát jako budovu, i když nevím, jaký je aktuální stav. zobrazit citaci
> > Co se tyce importu, pak bych radsi prosel tu proceduru znova pro RUIAN, > nez rozsirovat jiz stavajici import. Klidne to vykomunikuju.
Za tuto nabídku moc díky! Pokud se to spustí, tak budu rád. -- Petr

12.2.2014 12:05:58 (#11)
gravatar

Petr Vejsada

<osm at propsychology.cz>
516
Dne Út 11. února 2014 09:11:04, Dalibor Jelínek napsal(a): zobrazit citaci
> source:addr=uir_adr > uir_adr:ADRESA_KOD=22412948 > > is_in=Černý Most, Praha, CZ > source:addr=mvcr:adresa > source:position=cuzk:km > > Zda se mi, ze treba v tom prvnim pripade bys mel smazat uir_adr: ADRESA_KOD, > pokud v tom tagu neco zmenis. Nebo ne?
Určitě ano, díky zobrazit citaci
> > Nebudeme mit pak zmatek v tom, z ceho ty udaje pochazi? >
Asi trochu ano. Co se týká polohy, tak tu bych nechtěl (zbytečně) automaticky měnit. Bod mohl někdo šoupnout nad vchod podle vlastní znalosti. Data v RUIAN nejsou příšerná, ale někdy jsou ty body umístěné nevhodně. Což v OSM někdy taky, těžko říci, kde je více nevhodných umístění. Já si to zkoušel nanečisto, t.j. bez uploadu na OSM, a když jsem editoval polohy bodů v JOSM, tak mi subjektivně přišlo, že v OSM leží často na vhodnějších místech, než v RUIAN. Bůh suď. Nehýbal bych s tím. Z toho by tedy mělo vyplývat, že pokud ručně šoupnu bod nad vchod, měl bych smazat source:position? Asi ano. zobrazit citaci
> Co tedy znamena, ze je adresa oznacena ref:ruian a source:addr= cuzk:ruian? > Znamena to, ze jen ten text je z ruian a poloha ne?
Já to chápu tak, že údaje o adrese pochází primárně z RUIAN. Na bodu mohou být další tagy, typicky hospody a obchody; ty pochopitelně z RUIAN nepochází. zobrazit citaci
> A kdyz budeme chtit naimportovat/zmenit i polohu podle RUIAN, pak to > budeme znacit ref:ruian, source:addr= cuzk:ruian a > source:position=cuzk:ruian? > Jen bych to chtel mit ujasneno dopredu.
Přijde mi to jako příliš tagů typu source, navíc jsou platné jen do chvíle, než to někdo zedituje ručně a v tom případě není záruka, zda ty source: taky smaže. Ale nemám nic proti této variantě, Takže source:addr=cuzk:ruian source:position=[ponechat stávající|cuzk:ruian ref:ruian:am=nnnn nebo ref:ruian:addr=nnnnn (asi mezinárodně srozumitelnější) -- Petr

12.2.2014 02:05:10 (#12)
gravatar

Petr Vejsada

<osm at propsychology.cz>
516
Dne Út 11. února 2014 08:39:22, Petr Morávek [Xificurk] napsal(a): zobrazit citaci
> > Zásadní otázka č.1 - co s tagy addr:country a is_in? Možnosti jsou > > ponechat, mazat či nahrazovat. Jaký máte názor? > > Asi by bylo dobré udělat nějakou základní analýzu obsahu is_in tagu - > pokud obsahuje jen část obce, obec, stát... (nebo čárkami oddelenou > kombinaci), tak smazat. Pokud jsou všechna data is_in tagu obsažena ve > strukturované podobě v addr:*, tak si myslím, že nemá cenu, aby nám tu > nadále strašil.
Zběžná analýza provedena, - is_in obsahuje navíc kraj - is_in je u cca 90 procent všech entit, kde se vyskytují adresní tagy. Tak co s tím krajem? -- Petr

12.2.2014 09:15:24 (#13)
gravatar

hanoj

<ehanoj at gmail.com>
718
zobrazit citaci
> > A kdyz budeme chtit naimportovat/zmenit i polohu podle RUIAN, pak to > > budeme znacit ref:ruian, source:addr= cuzk:ruian a > > source:position=cuzk:ruian? > > Jen bych to chtel mit ujasneno dopredu. > > Přijde mi to jako příliš tagů typu source, navíc jsou platné jen do
chvíle,> než to někdo zedituje ručně a v tom případě není záruka, zda ty source: taky zobrazit citaci
> > smaže. Ale nemám nic proti této variantě, > > > > Takže > > source:addr=cuzk:ruian > > source:position=[ponechat stávající|cuzk:ruian > > ref:ruian:am=nnnn nebo ref:ruian:addr=nnnnn (asi mezinárodně
srozumitelnější) *** spíše "source:loc" než position http://taginfo.openstreetmap.org/keys/source:position#combinations http://taginfo.openstreetmap.org/keys/source:loc#combinations ha hanoj ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20140212/3a715a1b/attachment.html>

12.2.2014 10:32:16 (#14)
gravatar

Dalibor Jelínek

<dalibor at dalibor.cz>
415 1552
Ahoj, jeste k tem referencim. Nevim, jak to vidi ostatni, ale ja bych hodne moc zadal o to, abychom ty reference na RUIAN opravdu oddelili. Mame v RUIAN mimimalne (zatim) ctyri ID cisla, ktera kazde znamena neco jineho: AM - adresni misto http://vdp.cuzk.cz/vdp/ruian/adresnimista/26147394 SO - stavebni objekt http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/25647661 P - parcelu http://vdp.cuzk.cz/vdp/ruian/parcely/2110216101 TEA vchodu tady neznam primy link na vyhledavani Prijde mi naprosto nevhodne, abychom to nerozsilovali a znacili stejnym tagem. Jednak pak neni mozne se atuomaticky odkazat na web RUIAN a zobrazit si detaily o te veci z RUIAN, protoze se proste nevi, jaky link vytvorit. Za druhe nektere veci proste nejdou udelat. Pokud nekdo prida adresu dle AM na nejaky maly domek (tedy nepouzije adresni bod, ale da to na jeho cestu, coz hodne lidi dela, pac jim to prijde lepsi), pak uz neni kam pridat RUIAN ID te budovy. Nebo, kdyz narazite na takovy objekt, tak se nevi, jestli to ref:ruian odkazuje na AM nebo SO. zobrazit citaci
> V OSM už jsou tisíce stavebních objektů s ref_ruian=nnnnnn; někteří jsme
byli pilní. zobrazit citaci
> Spíš ref_ruian brát jako budovu, i když nevím, jaký je aktuální stav.
Chapu, nenavrhuju to ted zpetne menit, ale byl bych rad, kdybychom od ted zacali pripadavat tu referenci do jine znacky, nez se usnest, ze ref_ruian bez rozliseni je SO. zobrazit citaci
> ref:ruian:am=nnnn nebo ref:ruian:addr=nnnnn (asi mezinárodně
srozumitelnější) Jo, to je urcite lepsi. RUIAN sice je taky cesky, ale to addr aspon dava smysl. zobrazit citaci
> To nechám na ostatních, jak se k tomu vyjádří. Ono záleží, jakým stylem se
mapuje, případně bude mapovat. zobrazit citaci
> Ono je něco jiného ref:ruian na budově a něco jiného je ref:ruian na
pozemku nebo adresním místě. No, prave proto, ze je to neco jineho. A rozlisovat to jen podle toho, na jakem prvku je to pridane mi prijde velmi nevhodne, protoze se to bude v praxi michat mezi sebou (nekdo treba prekopiruje znacky z adresniho bodu na cestu domu). Muj navrh by tedy byl zacit pouzivat treba toto: AM - adresni misto ref:ruian:addr=nnnnn SO - stavebni objekt ref:ruian:building=nnnnn P - parcelu ref:ruian:parcel=nnnnn (nebo mozna ref:ruian:land ci ref:ruian:estate) TEA vchodu ref:ruian:entrance=nnnnn Co myslite? Zdravi, Dalibor PS: Za pokus o prohlaseni kraju za neexistujici se omlouvam. To byla blbost. Jen jsem mel zafixovano, ze kraje byly zruseny, pak zavedeny jinak a nekde se pouzivala porad stara struktura, pac byla v necem lepsi. Moc rychle jsem psal a malo myslel.

12.2.2014 06:06:45 (#15)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
Dne 12.2.2014 02:05, Petr Vejsada napsal(a): zobrazit citaci
> Dne Út 11. února 2014 08:39:22, Petr Morávek [Xificurk] napsal(a): > >>> Zásadní otázka č.1 - co s tagy addr:country a is_in? Možnosti jsou >>> ponechat, mazat či nahrazovat. Jaký máte názor? >> >> Asi by bylo dobré udělat nějakou základní analýzu obsahu is_in tagu - >> pokud obsahuje jen část obce, obec, stát... (nebo čárkami oddelenou >> kombinaci), tak smazat. Pokud jsou všechna data is_in tagu obsažena ve >> strukturované podobě v addr:*, tak si myslím, že nemá cenu, aby nám tu >> nadále strašil. > > Zběžná analýza provedena, > - is_in obsahuje navíc kraj > - is_in je u cca 90 procent všech entit, kde se vyskytují adresní tagy. > > Tak co s tím krajem? > > -- > Petr
Obecně si myslím, že dávat na adresní informaci o jakémkoliv administrativním celku od obce výše je nesmysl (a do toho zahrnuji i stát) - na adresu se to typicky nepíše a pokud to někdo potřebuje z jiných důvodů, tak od toho máme udržované administrativní hranice a overpass API a i ten Nominatim tyto hranice umí používat. Zdraví, Petr Morávek aka Xificurk

12.2.2014 09:00:50 (#16)
gravatar

Marián Kyral

<mkyral at email.cz>
2389 2735
Dne 12.2.2014 18:06, Petr Morávek [Xificurk] napsal: zobrazit citaci
> Dne 12.2.2014 02:05, Petr Vejsada napsal(a): >> Dne Út 11. února 2014 08:39:22, Petr Morávek [Xificurk] napsal(a): >> >>>> Zásadní otázka č.1 - co s tagy addr:country a is_in? Možnosti jsou >>>> ponechat, mazat či nahrazovat. Jaký máte názor? >>> >>> Asi by bylo dobré udělat nějakou základní analýzu obsahu is_in tagu - >>> pokud obsahuje jen část obce, obec, stát... (nebo čárkami oddelenou >>> kombinaci), tak smazat. Pokud jsou všechna data is_in tagu obsažena >>> ve >>> strukturované podobě v addr:*, tak si myslím, že nemá cenu, aby nám >>> tu >>> nadále strašil. >> >> Zběžná analýza provedena, >> - is_in obsahuje navíc kraj >> - is_in je u cca 90 procent všech entit, kde se vyskytují adresní >> tagy. >> >> Tak co s tím krajem? >> >> -- >> Petr > > Obecně si myslím, že dávat na adresní informaci o jakémkoliv > administrativním celku od obce výše je nesmysl (a do toho zahrnuji i > stát) - na adresu se to typicky nepíše a pokud to někdo potřebuje z > jiných důvodů, tak od toho máme udržované administrativní hranice a > overpass API a i ten Nominatim tyto hranice umí používat. >
A máme jistotu, že to někdo třeba nepoužívá? Marián zobrazit citaci
> Zdraví, > Petr Morávek aka Xificurk > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz

13.2.2014 12:51:48 (#17)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
Dne 12.2.2014 21:00, Marián Kyral napsal(a): zobrazit citaci
> Dne 12.2.2014 18:06, Petr Morávek [Xificurk] napsal: >> Dne 12.2.2014 02:05, Petr Vejsada napsal(a): >>> Dne Út 11. února 2014 08:39:22, Petr Morávek [Xificurk] napsal(a): >>> >>>>> Zásadní otázka č.1 - co s tagy addr:country a is_in? Možnosti jsou >>>>> ponechat, mazat či nahrazovat. Jaký máte názor? >>>> >>>> Asi by bylo dobré udělat nějakou základní analýzu obsahu is_in tagu - >>>> pokud obsahuje jen část obce, obec, stát... (nebo čárkami oddelenou >>>> kombinaci), tak smazat. Pokud jsou všechna data is_in tagu obsažena ve >>>> strukturované podobě v addr:*, tak si myslím, že nemá cenu, aby nám tu >>>> nadále strašil. >>> >>> Zběžná analýza provedena, >>> - is_in obsahuje navíc kraj >>> - is_in je u cca 90 procent všech entit, kde se vyskytují adresní tagy. >>> >>> Tak co s tím krajem? >>> >>> -- >>> Petr >> >> Obecně si myslím, že dávat na adresní informaci o jakémkoliv >> administrativním celku od obce výše je nesmysl (a do toho zahrnuji i >> stát) - na adresu se to typicky nepíše a pokud to někdo potřebuje z >> jiných důvodů, tak od toho máme udržované administrativní hranice a >> overpass API a i ten Nominatim tyto hranice umí používat. >> > > A máme jistotu, že to někdo třeba nepoužívá? > Marián
Naprostá jistota samozřejmě nikdy nebude, ale vzhledem k rozmanitosti formátu i obsahu tagu is_in (a zároveň dostupnosti té samé informace na "lepších" místech), bych se docela divil, kdyby to někde bylo ve větší míře bylo používáno. Petr

13.2.2014 03:31:34 (#18)
gravatar

Pavel Machek

<pavel at ucw.cz>
1056 1226
On Tue 2014-02-11 23:49:11, Petr Vejsada wrote: zobrazit citaci
> Ahoj, > > Dne Út 11. února 2014 09:01:07, Dalibor Jelínek napsal(a): > > > Ahoj, > > ja teda is_in tag rad nemam, protoze nevim, jak se ma spravne vyplnovat. > > Na druhou stranu se mi nezda hezke mazat neco, co nekdo do mapy > > s nejakym usilim pridal. > > Pokud opravdu dokazeme nahradit vse, co ted ten tag obsahuje, pak ano. > > Ale uz ted vim, ze zatim ten navrh PV neobsahuje vse, co je v is_in. > > V is_in jsou mestske casti (nekde) a stat, to tam zatim PV nema. > > > > Ja bych navrhoval, do tech adres pridavat : > > addr:country=CZ (czechaddress to tam dava a proc to vynechavat?) > > addr:suburb=Praha 14 (z městská část/obvod) > > přidat stát není problém, otázka spíš je, zda to má smysl.?
Jo, ma. Wiki rika, ze to tam ma byt, a ne kazdy si chce stahovat hranice zemi aby mohl pracovat s adresama. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

13.2.2014 05:57:07 (#19)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
Dne 13.2.2014 15:31, Pavel Machek napsal(a): zobrazit citaci
> On Tue 2014-02-11 23:49:11, Petr Vejsada wrote: >> Ahoj, >> >> Dne Út 11. února 2014 09:01:07, Dalibor Jelínek napsal(a): >> >>> Ahoj, >>> ja teda is_in tag rad nemam, protoze nevim, jak se ma spravne vyplnovat. >>> Na druhou stranu se mi nezda hezke mazat neco, co nekdo do mapy >>> s nejakym usilim pridal. >>> Pokud opravdu dokazeme nahradit vse, co ted ten tag obsahuje, pak ano. >>> Ale uz ted vim, ze zatim ten navrh PV neobsahuje vse, co je v is_in. >>> V is_in jsou mestske casti (nekde) a stat, to tam zatim PV nema. >>> >>> Ja bych navrhoval, do tech adres pridavat : >>> addr:country=CZ (czechaddress to tam dava a proc to vynechavat?) >>> addr:suburb=Praha 14 (z městská část/obvod) >> >> přidat stát není problém, otázka spíš je, zda to má smysl.? > > Jo, ma. Wiki rika, ze to tam ma byt, a ne kazdy si chce stahovat > hranice zemi aby mohl pracovat s adresama. > Pavel >
Ahoj, Wiki není žádná norma... a nikdy nebyla. Taginfo říká, že addr:country existuje na necelé polovině adresních bodů - konkrétně jej má: - 44% objektů, které mají addr:housenumber - 46% objektů, které mají addr:street Takže ono to až tak důsledně, jak naznačuješ, používané není. Nevím, co si mám představit pod "mohl pracovat s adresama", ale... Pokud chci dostat skutečně všechny adresní body v ČR je to otázka jediného jednoduchého dotazu na overpass API. Pokud mám bod a chci získat všechny administrativní celky (KÚ až stát), ve kterých leží, tak opět položím jeden jednoduchý dotaz na overpass API. Ani pro jedno si já nepotřebuju stahovat hranice k sobě a zároveň to dává spolehlivější výsledky, než hledání podle addr:country. Zdraví, Petr Morávek aka Xificurk

13.2.2014 06:20:26 (#20)
gravatar

Pavel Machek

<pavel at ucw.cz>
1056 1226
AhoJ! zobrazit citaci
> > Jo, ma. Wiki rika, ze to tam ma byt, a ne kazdy si chce stahovat > > hranice zemi aby mohl pracovat s adresama. > > Wiki není žádná norma... a nikdy nebyla.
Ne? A co je tedy norma? talk-cz@ mailing list? zobrazit citaci
> Taginfo říká, že addr:country existuje na necelé polovině adresních bodů > - konkrétně jej má: > - 44% objektů, které mají addr:housenumber > - 46% objektů, které mají addr:street > Takže ono to až tak důsledně, jak naznačuješ, používané není.
Coz porad neni duvod to kazit jeste vic. Dela se hromadna uprava, hromadna uprava by mela byt spravne. Pokud nesouhlasis s wiki, fajn, oprav wiki. Ale import by se mel ridit tim co je na wiki. (A ne, nemyslim ze by pro import bylo vic prace pridat addr:country, a nemyslim ze tech par bajtu navic neco zmeni.) zobrazit citaci
> Nevím, co si mám představit pod "mohl pracovat s adresama", ale... Pokud > chci dostat skutečně všechny adresní body v ČR je to otázka jediného > jednoduchého dotazu na overpass API. Pokud mám bod a chci získat > všechny
Mam tady offline navigaci na n900. Fakt chci aby zustala offline, a ne, nebudu si instalovat posgresql pro to, a by mi fungovalo vyhledavani podle adresy. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

13.2.2014 08:28:44 (#21)
gravatar

Martin Mares

<mj at ucw.cz>
18
Hello, world!\n zobrazit citaci
> Mam tady offline navigaci na n900. Fakt chci aby zustala offline, a > ne, nebudu si instalovat posgresql pro to, a by mi fungovalo > vyhledavani podle adresy.
Uprimne receno, na to vubec postgresql nepotrebujes. Lokalizace bodu v rozkladu roviny na mnohouhelniky je vcelku trivialni problem, na ktery staci napriklad uplne jednoducha konstrukce persistentniho stromu. Kdysi jsem o tom neco malo napsal, muzes se inspirovat treba zde: http://mj.ucw.cz/vyuka/ads/43-geom.pdf Have a nice fortnight -- Martin `MJ' Mares <mj na ucw.cz> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "Object orientation is in the mind, not in the compiler." -- Alan Cox

13.2.2014 10:12:38 (#22)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
Ahoj, já to radši zas sloučím do jednoho vlákna. A rovnou se omlouvám, že ty tvoje dva maily a odpovědi na ně promíchám, ale je to jedno téma, tak ať je to pohromadě. Dne 13.2.2014 18:20, Pavel Machek napsal(a): zobrazit citaci
>> Wiki není žádná norma... a nikdy nebyla. > > Ne? A co je tedy norma? talk-cz@ mailing list?
Ne, talk-cz@ skutečně taky žádná norma není. Norma pro OSM tagování totiž jednoduše neexistuje. Jaké tagy jsou nebo nejsou požíváno určuje jen a pouze to, jestli skutečně jsou nebo nejsou v databázi používány. Wiki slouží jako dokumentace "best-practice". Rozhodně není pravda, že co je na wiki, tak se musí používat a žádná jiná varianta není přípustná, nebo že co není na wiki, to neexistuje a se nesmí se používat. A tohle není můj osobní výmysl, takto je to prezentováno, jak na wiki samotné, tak i jednotlivých mezinárodních mailing listech. (A příště mi prosím nepodsouvej věci, které jsem ani v nejmenším nenaznačoval.) zobrazit citaci
>> Taginfo říká, že addr:country existuje na necelé polovině adresních bodů >> - konkrétně jej má: >> - 44% objektů, které mají addr:housenumber >> - 46% objektů, které mají addr:street >> Takže ono to až tak důsledně, jak naznačuješ, používané není. > > Coz porad neni duvod to kazit jeste vic. Dela se hromadna uprava, > hromadna uprava by mela byt spravne. Pokud nesouhlasis s wiki, fajn, > oprav wiki. Ale import by se mel ridit tim co je na wiki.
Import by se v prvé řadě měl řídit zdravým rozumem, až následně nějakým článkem na wiki. Znění těch článků se koneckonců mění právě na základě diskuze a předložení racionálních argumentů. zobrazit citaci
>> Už jsem psal komentář vedle, proč tento tag považuji za >> "pořekonaný". > > Wiki si to nemysli. Jestli s tebou zbytek sveta souhlasi, tak nebude > problem problem problem opravit na wiki, ze?
Wiki není potřeba opravovat, ono to tam už totiž je. Jen jsi to asi přehlédl: zobrazit citaci
> The keys addr:housenumber=* und addr:street=* in principle are the only necessary ones if there are valid border polygons.
(http://wiki.openstreetmap.org/wiki/Addr) zobrazit citaci
> (A ne, nemyslim ze by pro import bylo vic prace pridat addr:country, a > nemyslim ze tech par bajtu navic neco zmeni.)
Těmi pár bajty se tu ohání lidi nějak často... Celá státní hranice ČR (relace, všechny cesty a body a jejich tagy) má 11 MB v nekomprimovaném formátu. '<tag k="addr:country" v="CZ"/>\n' 31 B * 2917732 adresních míst = 86 MB Těch "par bajtu navic" je ve skutečnosti mnohonásobně víc než má kompletní hranice ČR (jejímuž stahování se těmi par bajty navic snažíš vyhnout). zobrazit citaci
>> Nevím, co si mám představit pod "mohl pracovat s adresama", ale... Pokud >> chci dostat skutečně všechny adresní body v ČR je to otázka jediného >> jednoduchého dotazu na overpass API. Pokud mám bod a chci získat >> všechny > > Mam tady offline navigaci na n900. Fakt chci aby zustala offline, a > ne, nebudu si instalovat posgresql pro to, a by mi fungovalo > vyhledavani podle adresy.
Nenapsal jsi, v čem konkrétně by nastal problém, takže neumím dát konkrétní odpověď. Ale předpokládám, že nějak ty data aktualizuješ. A z toho, co jsi psal hádám, že tam necpeš přímo celý dump OSM dat, ale děláš nějaký pre-processing, nevím čím a jak ale divil bych se, kdyby to neumělo spolupracovat z relacemi hranic a spoléhalo se jen a pouze na addr:country, nebo is_in tag. A i kdyby neumělo, tak existuje zmíněné overpass API. zobrazit citaci
>> Ale je pravda, že narozdíl od is_in v tomto případě hrozí větší riziko, >> že to stále ještě někdo používá. > > Is_in se pouzival treba tady: > > http://code.google.com/p/osmand/issues/detail?id=391
Irelevantní po přečtení první věty: zobrazit citaci
> Convert using OsmAndMapCreator-0.5.1beta-b2, an osm map without borders to delimit cities, so street ownership is determined by is_in tag in the corresponding "way".
My ty hranice (nejen) měst máme... a ještě k tomu máme (a nikdo se nesnaží to změnit) i addr:place. Já netvrdím, že se to "nikde a vůbec" nepoužívá... právě naopak z historických důvodů to jako úplně poslední fallback používá celá řada softwaru, ale je to skutečně až ten nejposlednější fallback. Jednoduše tenhle tag je deprecated a nemá smysl ho dále udržovat, protože existují spolehlivější cesty, jak se k daným informacím dostat. zobrazit citaci
> Opravdu si chces projit vsechen existujici software, a overit, ze uz > to nikdo nepouziva?
Nechci, chtěl jsem po tobě alespoň jeden konkrétní příklad, k čemu/kde je to užitečné - myslel jsem, že jsem to napsal dost jasně, ne? A myslím opravdu užitečné, tzn. "S is_in/addr:country tagem 'tohle' funguje, bez něj ne." zobrazit citaci
>> Osobně jsem tedy pro: nepřidávat, ale nemazat (krom případů, kdy tam je >> nějaký nesmysl). > > Na wiki ten tag stale jeste je, tak by to tam byt melo.
Na wiki je napsáno, že tam být nemusí, tak tam taky být nemusí :P zobrazit citaci
>>> (A viz anglicka wiki, ktera vysvetluje, ze mesto v is_in muze byt jine >>> nez v addr:city.) >> >> Máš konkrétní příklad pro ČR? > > Proc bych mel mit priklad pro CR?
Eh, to jako vážně? Nu, dobrá... Tématem této diskuze je "Adresy z RUIAN", to jsou adresy v ČR. Tvoji výše uvedenou poznámku jsem si vyložil tak, že is_in tag by se v rámci tohoto importu neměl mazat, protože je užitečný, protože může obsahovat jiné město než addr:city. Jelikož mě osobně nenapadá žádný příklad adresního místa (importovaného z RUIAN), kde by se tato vlastnost hodila, tak jsem se zeptal, jestli ty nějaký takový máš. Je to stejné jako s tím softwarem - předlož nějaký rozumný příklad. Já jsem připraven kdykoliv změnit svůj názor, ale potřebuji k tomu nějaký racionální argument. Zdraví, Petr Morávek aka Xificurk

13.2.2014 10:24:34 (#23)
gravatar

Marián Kyral

<mkyral at email.cz>
2389 2735
Dne 13.2.2014 20:28, Martin Mares napsal: zobrazit citaci
> Hello, world!\n > >> Mam tady offline navigaci na n900. Fakt chci aby zustala offline, a >> ne, nebudu si instalovat posgresql pro to, a by mi fungovalo >> vyhledavani podle adresy. > > Uprimne receno, na to vubec postgresql nepotrebujes. Lokalizace bodu > v rozkladu roviny na mnohouhelniky je vcelku trivialni problem, na > ktery > staci napriklad uplne jednoducha konstrukce persistentniho stromu. > > Kdysi jsem o tom neco malo napsal, muzes se inspirovat treba zde: > http://mj.ucw.cz/vyuka/ads/43-geom.pdf > > Have a nice fortnight

14.2.2014 08:29:49 (#24)
gravatar

Dalibor Jelínek

<dalibor at dalibor.cz>
415 1552
Ahoj, se nam ta debata nejak rozvasnuje. ;-) zobrazit citaci
> Pokud mám bod a chci získat všechny administrativní celky (KÚ až stát), ve kterých leží, tak opět položím jeden jednoduchý dotaz na overpass API
Tak ho sem napis. Ja ho neumim, vymyslet ho nechci, ale chtel bych se podivat, jak se to dela. Ja bych to addr:country=CZ daval vsude, protoze to treba zjednodusi vyhledavani bodu zajmu v prihranici. A do te adresy to proste tak nejak patri, i kdyz se zda, ze je to z naseho pohledu implicitni. Tady je dokonce nejaky naznak, ze to nekde dela problemy, kdyz to chybi http://wiki.openstreetmap.org/wiki/OSM_Inspector/Views/Addresses Ano, o neco to zvetsi databazi, ale to je fakt zanedbatelne. Kdyz uz chceme setrit misto, tak bych zmenil nazor a hlasoval pro mazani is_in tagu. Skutecne si myslim, ze je prezity, ale hlavne neni jasne nikde napsano v jakem tvaru se ma vytvaret, takze dost pochybuju, ze by ho nekdo mohl rozumne vyuzit. Jeho hlavni prinos jsem videl v dobe, kdy se nepouzivalo addr:place. Ted uz nevidim zadny.Puvodne jsem ho tam chtel nechavat, protoze mi prislo nevhodne neco mazat, ale stejne bychom ho pak museli opravovat, tedy poradne nadefinovat a obavam se, ze v tom procesu bychom zjistili, ze ho vlastne nepotrebujeme vubec. Zdravi, Dalibor

14.2.2014 08:54:05 (#25)
gravatar

Marián Kyral

<mkyral at email.cz>
2389 2735
Dne 14.2.2014 08:29, Dalibor Jelínek napsal: zobrazit citaci
> Ahoj, > > Kdyz uz chceme setrit misto, tak bych zmenil nazor a hlasoval pro > mazani > is_in tagu. Skutecne si myslim, ze je prezity, ale hlavne neni jasne > nikde > napsano v jakem tvaru se ma vytvaret,
http://wiki.openstreetmap.org/wiki/Cs:JOSM/Plugins/CzechAddress#Adresy_v_OpenStreetMap zobrazit citaci
> takze dost pochybuju, ze by ho > nekdo mohl rozumne vyuzit. Jeho hlavni prinos jsem videl v dobe, kdy > se nepouzivalo addr:place. Ted uz nevidim zadny.Puvodne jsem ho tam > chtel nechavat, protoze mi prislo nevhodne neco mazat, ale stejne > bychom > ho pak museli opravovat, tedy poradne nadefinovat a obavam se, ze v tom > procesu bychom zjistili, ze ho vlastne nepotrebujeme vubec.
Pokud jej zachováme, tak jsem pro to, aby se to udělalo pořádně: [místní část], [městská část], [město], [okres], [kraj], CZ S tím, že minimální zápis bude: [město], [okres], [kraj], CZ Marián

14.2.2014 10:02:19 (#26)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
Dne 14.2.2014 08:29, Dalibor Jelínek napsal(a): zobrazit citaci
> Ahoj, > se nam ta debata nejak rozvasnuje. ;-) > >> Pokud mám bod a chci získat všechny administrativní celky (KÚ až stát), ve kterých leží, tak opět položím jeden jednoduchý dotaz na overpass API > Tak ho sem napis. Ja ho neumim, vymyslet ho nechci, ale chtel bych se podivat, jak se to dela. > > Ja bych to addr:country=CZ daval vsude, protoze to treba zjednodusi > vyhledavani bodu zajmu v prihranici. A do te adresy to proste tak nejak patri, > i kdyz se zda, ze je to z naseho pohledu implicitni.
Jak konkrétně to zjednoduší? Když hledám "Ulice 42, Obec", "Ulice, Obec", nebo "POI, Obec", tak tam ani CZ nemám a typicky to nepotřebuji (ta obec stačí). A znovu musím opakovat, že pro tyhle údaje existují spolehlivější zdroje, schválně si dejte hledat v nominatimu "praha hlavní nádraží" a zobrazí se vám: Železniční stanice Prague Main Railway Station, Legerova, Vinohrady, Praha, Hlavní město Praha, Praha, 12000, Česko (hm, asi bych se měl podívat, proč to tam je anglicky :D) A přitom ten uzel neobsahuje jediný addr:* nebo is_in tag. A pokud jde o reverzní úkol, např. získat všechny adresní body třeba v Mikulově, tak tady jsou: http://overpass-turbo.eu/s/2w1 Opět, na to není potřeba žádný addr:* nebo is_in tag. zobrazit citaci
> Tady je dokonce nejaky naznak, ze to nekde dela problemy, kdyz to chybi > http://wiki.openstreetmap.org/wiki/OSM_Inspector/Views/Addresses
Uvědomuješ si, že dáváš odkaz na něco, co už víc jak pět let nefunguje? :-) Navíc ten hlavní problém není v chybějícím addr:country, ale jednoduše špatně navrženém algoritmu. Zdraví, Petr Morávek aka Xificurk

14.2.2014 01:35:36 (#27)
gravatar

Dalibor Jelínek

<dalibor at dalibor.cz>
415 1552
Ahoj, http://wiki.openstreetmap.org/wiki/Cs:JOSM/Plugins/CzechAddress#Adresy_v_OpenStreetMap tak to jsem nenasel. Cekal bych, ze to najdu na ceskych Map Features nebo Editing Standards. Neva, prilezitostne to tam dopisu. zobrazit citaci
> Pokud jej zachováme, tak jsem pro to, aby se to udělalo pořádně: > [místní část], [městská část], [město], [okres], [kraj], CZ > S tím, že minimální zápis bude: > [město], [okres], [kraj], CZ
Hmm. A nevadi nam, ze tam mame carky, kdyz tady http://wiki.openstreetmap.org/wiki/Key:is_in se zcela zjevne doporucujou stredniky? Mě to teda vadí hodně. Středník by byl lepší, protože to je standardní oddělovátko. Navíc ta stránka píše, že vlastně na pořadí těch částí zas tak moc nezáleží (i když je lepší je mít seřazené), ale my vlastně žádné části nemáme, takže zahraniční programy na to asi koukaj dost divně. zobrazit citaci
> Uvědomuješ si, že dáváš odkaz na něco, co už víc jak pět let nefunguje?
Ee, nee, proste jsem to jen nasel. Mozna blbej algoritmus, ale chybelo jim to. ;-) zobrazit citaci
> Pokud mám bod a chci získat všechny administrativní celky (KÚ až > stát), ve kterých leží, tak opět položím jeden jednoduchý dotaz na > overpass API
Když já jsem chtěl vědět, jak se dělá tohle. Najít adresy v nějakých hranicích už jste mě naučili. Zdraví, Dalibor

14.2.2014 03:26:36 (#28)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
Dne 14.2.2014 13:35, Dalibor Jelínek napsal(a): zobrazit citaci
> Ahoj, > http://wiki.openstreetmap.org/wiki/Cs:JOSM/Plugins/CzechAddress#Adresy_v_OpenStreetMap > tak to jsem nenasel. Cekal bych, ze to najdu na ceskych Map Features nebo Editing Standards. > Neva, prilezitostne to tam dopisu. > >> Pokud jej zachováme, tak jsem pro to, aby se to udělalo pořádně: >> [místní část], [městská část], [město], [okres], [kraj], CZ >> S tím, že minimální zápis bude: >> [město], [okres], [kraj], CZ > > Hmm. A nevadi nam, ze tam mame carky, kdyz tady > http://wiki.openstreetmap.org/wiki/Key:is_in > se zcela zjevne doporucujou stredniky? > Mě to teda vadí hodně. Středník by byl lepší, protože to je standardní oddělovátko. > Navíc ta stránka píše, že vlastně na pořadí těch částí zas tak moc nezáleží (i když je lepší > je mít seřazené), ale my vlastně žádné části nemáme, takže zahraniční programy na > to asi koukaj dost divně.
A ještě by se tam mohl přidat NUTS2 region, katastrální území, ZSJ, PSČ, jméno ulice, ... těch pár bajtů navíc nikoho nezabije :P A teď vážně - dokáže někdo říct k čemu by to mělo být užitečné? O tom, že je tento tag překonaný koneckonců svědčí i čísla z taginfo: addr:housenumber celkem 29 mil. objektů, 2 mil. má is_in tag addr:street celkem 26 mil. objektů, 1 mil. z nich má is_in tag is_in celkem 4 mil. objektů zobrazit citaci
>> Uvědomuješ si, že dáváš odkaz na něco, co už víc jak pět let nefunguje? > Ee, nee, proste jsem to jen nasel. Mozna blbej algoritmus, ale chybelo jim to. ;-)
Chybělo jim to "tenkrát" - bylo potřeba buď addr:country, rozumnější hranice států, nebo chytřejší algoritmus. Rozhodně tuhle pět let mrtvou věc nelze považovat za smysluplný argument pro plošné používání addr:country ;-) zobrazit citaci
>> Pokud mám bod a chci získat všechny administrativní celky (KÚ až >> stát), ve kterých leží, tak opět položím jeden jednoduchý dotaz na >> overpass API > Když já jsem chtěl vědět, jak se dělá tohle.
Např. takto: http://overpass-turbo.eu/s/2wb zobrazit citaci
> Najít adresy v nějakých hranicích už jste mě naučili.
Overpass API toho umí opravdu spoustu, na wiki je rozsáhlá dokumentace. Hlavní výhodou je, že není potřeba vlastníma silama něco instalovat a nastavovat. Zdraví, Petr Morávek

15.2.2014 10:59:21 (#29)
gravatar

Pavel Machek

<pavel at ucw.cz>
1056 1226
Ahoj! zobrazit citaci
> > Mam tady offline navigaci na n900. Fakt chci aby zustala offline, a > > ne, nebudu si instalovat posgresql pro to, a by mi fungovalo > > vyhledavani podle adresy. > > Uprimne receno, na to vubec postgresql nepotrebujes. Lokalizace bodu > v rozkladu roviny na mnohouhelniky je vcelku trivialni problem, na ktery > staci napriklad uplne jednoducha konstrukce persistentniho stromu.
Je zajimave, cemu se jeste da rict "vcelku trivialni". Uprimne receno, nepotrebuju. Takze mam dobrovolnika, ktery tohle implementuje do monav-u, navit-u, osmand-u a marble a ja nevim ceho jeste dalsiho? Tesim se na patche, a do doby nez budou aplikovany, muzeme prosim tagovat adresy dle wiki? (Mimochodem, zeme neni rovina; pro ceskou republiku je to asi jedno, ale kdyby nas zajimala jen ceska republika, tak opravdu neni nutne tagovat kod zeme). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

15.2.2014 11:12:15 (#30)
gravatar

Pavel Machek

<pavel at ucw.cz>
1056 1226
On Fri 2014-02-14 10:02:19, "Petr Morávek [Xificurk]" wrote: zobrazit citaci
> Dne 14.2.2014 08:29, Dalibor Jelínek napsal(a): > > Ahoj, > > se nam ta debata nejak rozvasnuje. ;-) > > > >> Pokud mám bod a chci získat všechny administrativní celky (KÚ až stát), ve kterých leží, tak opět položím jeden jednoduchý dotaz na overpass API > > Tak ho sem napis. Ja ho neumim, vymyslet ho nechci, ale chtel bych se podivat, jak se to dela. > > > > Ja bych to addr:country=CZ daval vsude, protoze to treba zjednodusi > > vyhledavani bodu zajmu v prihranici. A do te adresy to proste tak nejak patri, > > i kdyz se zda, ze je to z naseho pohledu implicitni. > > Jak konkrétně to zjednoduší? > > Když hledám "Ulice 42, Obec", "Ulice, Obec", nebo "POI, Obec", tak tam > ani CZ nemám a typicky to nepotřebuji (ta obec stačí). > > A znovu musím opakovat, že pro tyhle údaje existují spolehlivější > zdroje, schválně si dejte hledat v nominatimu "praha hlavní nádraží" a > zobrazí se vám: > Železniční stanice Prague Main Railway Station, Legerova, Vinohrady, > Praha, Hlavní město Praha, Praha, 12000, Česko > (hm, asi bych se měl podívat, proč to tam je anglicky :D) > A přitom ten uzel neobsahuje jediný addr:* nebo is_in tag.
Nominatim to zvladnul. Na http://wiki.openstreetmap.org/wiki/Routing je seznam pouzivanych programu na hledani. Zvladnou to vsechny z nich? zobrazit citaci
> A pokud jde o reverzní úkol, např. získat všechny adresní body třeba v > Mikulově, tak tady jsou: > http://overpass-turbo.eu/s/2w1 > Opět, na to není potřeba žádný addr:* nebo is_in tag.
A jak to udelam v josm bez overpassu? Jinak... ta zeme je soucasti adresy, pise se na dopisy zaslany ze zahranici. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

15.2.2014 11:30:39 (#31)
gravatar

Pavel Machek

<pavel at ucw.cz>
1056 1226
Ahoj! zobrazit citaci
> já to radši zas sloučím do jednoho vlákna. A rovnou se omlouvám, že ty > tvoje dva maily a odpovědi na ně promíchám, ale je to jedno téma, tak ať > je to pohromadě. > > > Dne 13.2.2014 18:20, Pavel Machek napsal(a): > >> Wiki není žádná norma... a nikdy nebyla. > > > > Ne? A co je tedy norma? talk-cz@ mailing list? > > Ne, talk-cz@ skutečně taky žádná norma není. Norma pro OSM tagování > totiž jednoduše neexistuje. Jaké tagy jsou nebo nejsou požíváno určuje > jen a pouze to, jestli skutečně jsou nebo nejsou v databázi používány. > Wiki slouží jako dokumentace "best-practice". Rozhodně není pravda, > že
Fajn. Takze je to best-practice. Od ktere se chces odchylit, a duvodem se zda byt "je mi lito 86MB v databazi". To myslim neni dobry duvod, proc se od best-practice odchylit. zobrazit citaci
> Import by se v prvé řadě měl řídit zdravým rozumem, až následně nějakým > článkem na wiki. Znění těch článků se koneckonců mění právě na základě > diskuze a předložení racionálních argumentů.
Muj zdravy rozum rika ze jinde se addr:country pouziva, tak by tam mel byt i nadale. zobrazit citaci
> Wiki není potřeba opravovat, ono to tam už totiž je. Jen jsi to asi > přehlédl: > > The keys addr:housenumber=* und addr:street=* in principle are the only necessary ones if there are valid border polygons. > (http://wiki.openstreetmap.org/wiki/Addr)
Ale neni tam "due to space reasons, it is reasonable to delete addr:country when border polygons are available". zobrazit citaci
> Těch "par bajtu navic" je ve skutečnosti mnohonásobně víc než má > kompletní hranice ČR (jejímuž stahování se těmi par bajty navic snažíš > vyhnout).
Hlavne se chci vyhnout programovani tech vypoctu. A nerad bych "opravoval" programy, ktere addr:country z nejakeho duvodu pouzivaji. zobrazit citaci
> >> Nevím, co si mám představit pod "mohl pracovat s adresama", ale... Pokud > >> chci dostat skutečně všechny adresní body v ČR je to otázka jediného > >> jednoduchého dotazu na overpass API. Pokud mám bod a chci získat > >> všechny > > > > Mam tady offline navigaci na n900. Fakt chci aby zustala offline, a > > ne, nebudu si instalovat posgresql pro to, a by mi fungovalo > > vyhledavani podle adresy. > > Nenapsal jsi, v čem konkrétně by nastal problém, takže neumím dát > konkrétní odpověď. Ale předpokládám, že nějak ty data aktualizuješ. A z > toho, co jsi psal hádám, že tam necpeš přímo celý dump OSM dat, ale > děláš nějaký pre-processing, nevím čím a jak ale divil bych se, kdyby to > neumělo spolupracovat z relacemi hranic a spoléhalo se jen a pouze na > addr:country, nebo is_in tag. A i kdyby neumělo, tak existuje zmíněné > overpass API.
Mam tu monav, ano, obcas stahnu novy data. Ne, neumi to spolupracovat s relacemi hranic. Bohuzel pro to nektere ulice nevidi v Praze. zobrazit citaci
> Já netvrdím, že se to "nikde a vůbec" nepoužívá... právě naopak z > historických důvodů to jako úplně poslední fallback používá celá řada > softwaru, ale je to skutečně až ten nejposlednější fallback. Jednoduše > tenhle tag je deprecated a nemá smysl ho dále udržovat, protože existují > spolehlivější cesty, jak se k daným informacím dostat.
Existuji spolehlivejsi cesty, ktere ovsem maji jine nevyhody, a ne kazdy software je implementuje. zobrazit citaci
> > Opravdu si chces projit vsechen existujici software, a overit, ze uz > > to nikdo nepouziva? > > Nechci, chtěl jsem po tobě alespoň jeden konkrétní příklad, k čemu/kde > je to užitečné - myslel jsem, že jsem to napsal dost jasně, ne? A myslím > opravdu užitečné, tzn. "S is_in/addr:country tagem 'tohle' funguje, bez > něj ne."
Zda se ze napriklad navit potrebuje is_in tag: * Navit only works with is_in tags, can't work with boundaries. http://wiki.openstreetmap.org/wiki/Talk:Key:is_in Z osobni zkusenosti vim, ze monav neumi vyuzit hranice mest. Myslim ze z hranicemi zemi to bude podobne. zobrazit citaci
> >>> (A viz anglicka wiki, ktera vysvetluje, ze mesto v is_in muze byt jine > >>> nez v addr:city.) > >> > >> Máš konkrétní příklad pro ČR? > > > > Proc bych mel mit priklad pro CR? > > Eh, to jako vážně? Nu, dobrá... Tématem této diskuze je "Adresy z > RUIAN", to jsou adresy v ČR. Tvoji výše uvedenou poznámku jsem si > vyložil tak, že is_in tag by se v rámci tohoto importu neměl mazat, > protože je užitečný, protože může obsahovat jiné město než addr:city. > Jelikož mě osobně nenapadá žádný příklad adresního místa (importovaného > z RUIAN), kde by se tato vlastnost hodila, tak jsem se zeptal, jestli ty > nějaký takový máš.
Z jineho mailu: #Aha. Takže Krásná, pošta Raškovice má být # #addr:city=Raškovice #is_in=Krásná # #místo #addr:city=Krásná #is_in=Krásná Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

15.2.2014 11:32:46 (#32)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
Dne 15.2.2014 11:12, Pavel Machek napsal(a): zobrazit citaci
> On Fri 2014-02-14 10:02:19, "Petr Morávek [Xificurk]" wrote: >> A znovu musím opakovat, že pro tyhle údaje existují spolehlivější >> zdroje, schválně si dejte hledat v nominatimu "praha hlavní nádraží" a >> zobrazí se vám: >> Železniční stanice Prague Main Railway Station, Legerova, Vinohrady, >> Praha, Hlavní město Praha, Praha, 12000, Česko >> (hm, asi bych se měl podívat, proč to tam je anglicky :D) >> A přitom ten uzel neobsahuje jediný addr:* nebo is_in tag. > > Nominatim to zvladnul. Na http://wiki.openstreetmap.org/wiki/Routing > je seznam pouzivanych programu na hledani. Zvladnou to vsechny z nich?
Nevím. Ale je jisté, že pokud to některý z nich nezvládá, tak má celkem problém bez ohledu na to, jak dopadne tahle naše diskuze. Jen malá část objektů v databázi má is_in tag a z adresních bodů má jen necelá polovina tag addr:country, pokud tedy někdo staví svoje vyhledávání jen a pouze nad těmito daty, tak toho asi moc nenajde. zobrazit citaci
>> A pokud jde o reverzní úkol, např. získat všechny adresní body třeba v >> Mikulově, tak tady jsou: >> http://overpass-turbo.eu/s/2w1 >> Opět, na to není potřeba žádný addr:* nebo is_in tag. > > A jak to udelam v josm bez overpassu?
Čtu to už asi po desáté a pořád to nedává smysl... Já tu ukážu, jak s určitým nástrojem (overpass api) dosáhnout určitého cíle (stažení specifických dat z nějaké oblasti) a tvoje následná otázka je typu "A jak to můžu udělat jinak?" Zdraví, Petr Morávek aka Xificurk

15.2.2014 11:42:32 (#33)
gravatar

Pavel Machek

<pavel at ucw.cz>
1056 1226
On Fri 2014-02-14 15:26:36, "Petr Morávek [Xificurk]" wrote: zobrazit citaci
> Dne 14.2.2014 13:35, Dalibor Jelínek napsal(a): > > Ahoj, > > http://wiki.openstreetmap.org/wiki/Cs:JOSM/Plugins/CzechAddress#Adresy_v_OpenStreetMap > > tak to jsem nenasel. Cekal bych, ze to najdu na ceskych Map Features nebo Editing Standards. > > Neva, prilezitostne to tam dopisu. > > > >> Pokud jej zachováme, tak jsem pro to, aby se to udělalo pořádně: > >> [místní část], [městská část], [město], [okres], [kraj], CZ > >> S tím, že minimální zápis bude: > >> [město], [okres], [kraj], CZ > > > > Hmm. A nevadi nam, ze tam mame carky, kdyz tady > > http://wiki.openstreetmap.org/wiki/Key:is_in > > se zcela zjevne doporucujou stredniky? > > Mě to teda vadí hodně. Středník by byl lepší, protože to je standardní oddělovátko. > > Navíc ta stránka píše, že vlastně na pořadí těch částí zas tak moc nezáleží (i když je lepší > > je mít seřazené), ale my vlastně žádné části nemáme, takže zahraniční programy na > > to asi koukaj dost divně. > > A ještě by se tam mohl přidat NUTS2 region, katastrální území, ZSJ, PSČ, > jméno ulice, ... těch pár bajtů navíc nikoho nezabije :P > > A teď vážně - dokáže někdo říct k čemu by to mělo být užitečné?
Aby fungoval existujici software, jako napriklad navit. (A ano, kus softwaru, ktery vezme .osm, a doplni tam is_in tagy podle hranic by asi nebyl spatny. Nekdo, kdo tvrdi jak jednoduche je tu informaci dopocitat by ho sem mohl napastovat :-). Asi by bylo dobry aby ten kus sw fungoval i pro jiny zeme nez je Ceska Republika. Pak by aspon bylo mozny navigaci pred spustenim jejiho zpracovani potrebny informace doplnit.) Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

15.2.2014 12:57:54 (#34)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
Dne 15.2.2014 11:30, Pavel Machek napsal(a): zobrazit citaci
> Fajn. Takze je to best-practice. Od ktere se chces odchylit, a duvodem > se zda byt "je mi lito 86MB v databazi". To myslim neni dobry duvod, > proc se od best-practice odchylit.
Zas mi podsouváš něco, co jsem nikdy ani v nejmenším nenaznačoval - 86MB byla reakce na tvých "pár bajtů" a že bys radši přidával addr:country, protože se ti nechce stahovat celé hranice ČR. Best-practice na wiki říká, že jakmile existují spolehlivé polygony hranic, tak tyto tagy nejsou potřeba a já s tím souhlasím a zatím nevidím důvod, proč je nadále udržovat, nebo dokonce někde přidávat. zobrazit citaci
>> Import by se v prvé řadě měl řídit zdravým rozumem, až následně nějakým >> článkem na wiki. Znění těch článků se koneckonců mění právě na základě >> diskuze a předložení racionálních argumentů. > > Muj zdravy rozum rika ze jinde se addr:country pouziva, tak by tam mel > byt i nadale.
Míst, kde se používá addr:country je méně než míst, kde se nepoužívá. Pro is_in tag je ten rozdíl ještě mnohem výraznější - je řádově víc objektů bez něj než s ním. zobrazit citaci
> Mam tu monav, ano, obcas stahnu novy data. Ne, neumi to spolupracovat > s relacemi hranic. Bohuzel pro to nektere ulice nevidi v Praze.
... zobrazit citaci
> Zda se ze napriklad navit potrebuje is_in tag: > > * Navit only works with is_in tags, can't work with boundaries. > > http://wiki.openstreetmap.org/wiki/Talk:Key:is_in > > Z osobni zkusenosti vim, ze monav neumi vyuzit hranice mest. Myslim ze > z hranicemi zemi to bude podobne.
http://wiki.navit-project.org/index.php/OpenStreetMap Navit (resp. maptool, který převádí osm do binárního formátu pro navit) umí používat jak hranice států, tak i měst. https://groups.google.com/forum/#!msg/monav-discuss/kWz7Xvao7jM/SBABYSQ4Oy0J Podle tohoto MoNav s nějakými polygony pracovat umí, takže bude jen problém v tom, jaké využívá. Zároveň jsem ale nikde v dokumentaci nebo kódu nenašel zmínku o tom, že by se používala hodnota is_in nebo addr:country, takže jejich ponechání/doplnění stejně nic nevyřeší. Co tam máš dál? ;-) zobrazit citaci
> Z jineho mailu: > > #Aha. Takže Krásná, pošta Raškovice má být > # > #addr:city=Raškovice > #is_in=Krásná > # > #místo > #addr:city=Krásná > #is_in=Krásná
Omlouvám se, to jsem nějak přehlédl. Ale naprosto nesouhlasím s tímto použitím. * addr:city by mělo obsahovat jméno obce, kde se AM nachází (tak jak je to i v RUIAN), v žádném případě by tam nemělo být něco jiného. * "pošta Raškovice" je to samé jako PSČ 73907. Nemá smysl tu samou informaci duplikovat v OSM. Ani není potřeba ji duplikovat v adrese na dopisu - jediný význam je "pro kontrolu", takže když napíšeš "Krásná, pošta Raškovice, PSČ 12345", tak to pravděpodobně dojde. Z vlastní zkušenosti vím, že Česká pošta je schopná doručit i dopisy s hodně zkomolenou adresou. Zdraví, Petr Morávek aka Xificurk

15.2.2014 02:50:50 (#35)
gravatar

Petr Vejsada

<osm at propsychology.cz>
516
Ahoj, Dne So 15. února 2014 11:32:46, Petr Morávek [Xificurk] napsal(a): zobrazit citaci
> > Nominatim to zvladnul. Na http://wiki.openstreetmap.org/wiki/Routing > > je seznam pouzivanych programu na hledani. Zvladnou to vsechny z nich? > > Nevím. Ale je jisté, že pokud to některý z nich nezvládá, tak má celkem > problém bez ohledu na to, jak dopadne tahle naše diskuze. > > Jen malá část objektů v databázi má is_in tag a z adresních bodů má jen > necelá polovina tag addr:country, pokud tedy někdo staví svoje > vyhledávání jen a pouze nad těmito daty, tak toho asi moc nenajde.
K tomuto tolik, že i ten Nominatim má vážný problém. Libochovany 129 - prostě to nenajde, ačkoli má dokonce hned dvě možnosti, jak to udělat. Barák existuje, existují hranice obce, existují hranice "čtvrti" - asi katastrální území, existuje addr:city, addr:housenumber i addr:conscriptionnumber. Z toho víceméně vyplývá, že nebude schopen najít barák ve městě ani po zavedení addr:place. Dotaz bude muset být na část obce (což v případě Libochovan jsou taky Libochovany), ovšem ne vždy tomu tak bude. -- Petr

15.2.2014 03:02:41 (#36)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
Dne 15.2.2014 14:50, Petr Vejsada napsal(a): zobrazit citaci
> K tomuto tolik, že i ten Nominatim má vážný problém. > > Libochovany 129 - prostě to nenajde, ačkoli má dokonce hned dvě možnosti, jak > to udělat. Barák existuje, existují hranice obce, existují hranice "čtvrti" - > asi katastrální území, existuje addr:city, addr:housenumber i > addr:conscriptionnumber.
A dokonce i is_in=Libochovany, Ústecký kraj, CZ Chtělo by to přijít na to, kde je zakopaný pes a proč to nenajde. zobrazit citaci
> Z toho víceméně vyplývá, že nebude schopen najít barák ve městě ani po > zavedení addr:place.
Já teda osobně nevidím, jak to z toho vyplývá (vždyť ani nevíme, proč nenajde "Libochovany 129"!) A že nenajde adresu Praha 42 je sice škoda, ale žádná tragedie. zobrazit citaci
> Dotaz bude muset být na část obce (což v případě > Libochovan jsou taky Libochovany), ovšem ne vždy tomu tak bude.
To by nebylo až tak katastrofální - typicky chceš hledat podle názvu ulice, nebo části obce (protože tam nejsou pojmenované ulice). Petr

15.2.2014 04:04:20 (#37)
gravatar

Marián Kyral

<mkyral at email.cz>
2389 2735
Dne 15.2.2014 12:57, Petr Morávek [Xificurk] napsal: zobrazit citaci
> Dne 15.2.2014 11:30, Pavel Machek napsal(a):
zobrazit citaci
> Co tam máš dál? ;-) > > >> Z jineho mailu: >> >> #Aha. Takže Krásná, pošta Raškovice má být >> # >> #addr:city=Raškovice >> #is_in=Krásná >> # >> #místo >> #addr:city=Krásná >> #is_in=Krásná > > Omlouvám se, to jsem nějak přehlédl. Ale naprosto nesouhlasím s tímto > použitím. > * addr:city by mělo obsahovat jméno obce, kde se AM nachází (tak jak je > to i v RUIAN), v žádném případě by tam nemělo být něco jiného. > * "pošta Raškovice" je to samé jako PSČ 73907. Nemá smysl tu samou > informaci duplikovat v OSM. Ani není potřeba ji duplikovat v adrese na > dopisu - jediný význam je "pro kontrolu", takže když napíšeš "Krásná, > pošta Raškovice, PSČ 12345", tak to pravděpodobně dojde. Z vlastní > zkušenosti vím, že Česká pošta je schopná doručit i dopisy s hodně > zkomolenou adresou.
Tak tohle je od Pavla trochu podpásovka. V tom původním emailu hned za tím následoval otazník. Taky jsem se zmínil, že informace o poště je v obsažena v PSČ. Nikdo to už pak nekomentoval. Marián

15.2.2014 04:41:04 (#38)
gravatar

Dalibor Jelínek

<dalibor at dalibor.cz>
415 1552
Ahoj, tohle jsem nepochopil. Proc by to po zavedeni addr:place nefungovalo? Kdyz jsem to zkousel, tak to fungovalo vzdy na tvar addr:place cislo popisne. Praha 2295 to samozrejme nenajde, ale Libeň 2295 ano. U tech Libochovic to musi fungovat taky, kdyz si Nominatim docte addr:place do databaze. Dalibor Sent from my HTC
----- Reply message ----- From: "Petr Vejsada" <osm na propsychology.cz> To: "OpenStreetMap Czech Republic" <talk-cz na openstreetmap.org> Subject: [Talk-cz] Adresy z RUIAN Date: Sat, Feb 15, 2014 14:50 Ahoj, Dne So 15. února 2014 11:32:46, Petr Morávek [Xificurk] napsal(a): zobrazit citaci
> > Nominatim to zvladnul. Na http://wiki.openstreetmap.org/wiki/Routing > > je seznam pouzivanych programu na hledani. Zvladnou to vsechny z nich? > > Nevím. Ale je jisté, že pokud to některý z nich nezvládá, tak má celkem > problém bez ohledu na to, jak dopadne tahle naše diskuze. > > Jen malá část objektů v databázi má is_in tag a z adresních bodů má jen > necelá polovina tag addr:country, pokud tedy někdo staví svoje > vyhledávání jen a pouze nad těmito daty, tak toho asi moc nenajde.
K tomuto tolik, že i ten Nominatim má vážný problém. Libochovany 129 - prostě to nenajde, ačkoli má dokonce hned dvě možnosti, jak to udělat. Barák existuje, existují hranice obce, existují hranice "čtvrti" - asi katastrální území, existuje addr:city, addr:housenumber i addr:conscriptionnumber. Z toho víceméně vyplývá, že nebude schopen najít barák ve městě ani po zavedení addr:place. Dotaz bude muset být na část obce (což v případě Libochovan jsou taky Libochovany), ovšem ne vždy tomu tak bude. -- Petr _______________________________________________ Talk-cz mailing list Talk-cz na openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20140215/ee8b9dd8/attachment.html>

15.2.2014 04:46:28 (#39)
gravatar

Petr Vejsada

<osm at propsychology.cz>
516
Ahoj, Dne So 15. února 2014 15:02:41, Petr Morávek [Xificurk] napsal(a): Z Changelogu verze 2.1 (poslední stable): * support for addresses without a street (addr:place and conscription number house numbers) takže to vypadá, že schopnost nalézt dům bez ulice je vlastně nová vlastnost. Koukal jsem do gitu Nominatimu, nenašel jsem od release 2.1 žádné změny v tomto smyslu. zobrazit citaci
> Dne 15.2.2014 14:50, Petr Vejsada napsal(a): > > K tomuto tolik, že i ten Nominatim má vážný problém. > > > > Libochovany 129 - prostě to nenajde, ačkoli má dokonce hned dvě možnosti, > > jak to udělat. Barák existuje, existují hranice obce, existují hranice > > "čtvrti" - asi katastrální území, existuje addr:city, addr:housenumber i > > addr:conscriptionnumber. > > A dokonce i is_in=Libochovany, Ústecký kraj, CZ > Chtělo by to přijít na to, kde je zakopaný pes a proč to nenajde. > > > Z toho víceméně vyplývá, že nebude schopen najít barák ve městě ani po > > zavedení addr:place. > > Já teda osobně nevidím, jak to z toho vyplývá (vždyť ani nevíme, proč > nenajde "Libochovany 129"!) > A že nenajde adresu Praha 42 je sice škoda, ale žádná tragedie. > > > Dotaz bude muset být na část obce (což v případě > > Libochovan jsou taky Libochovany), ovšem ne vždy tomu tak bude. > > To by nebylo až tak katastrofální - typicky chceš hledat podle názvu > ulice, nebo části obce (protože tam nejsou pojmenované ulice). > > Petr > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz

15.2.2014 04:48:15 (#40)
gravatar

Petr Vejsada

<osm at propsychology.cz>
516
Ahoj, Dne So 15. února 2014 16:41:04, Dalibor Jelínek napsal(a): zobrazit citaci
> tohle jsem nepochopil. Proc by to po zavedeni addr:place nefungovalo? Kdyz > jsem to zkousel, tak to fungovalo vzdy na tvar addr:place cislo popisne. > Praha 2295 to samozrejme nenajde, ale Libeň 2295 ano. U tech Libochovic to > musi fungovat taky, kdyz si Nominatim docte addr:place do databaze.
no právě - mně by se líbilo, kdyby to našlo i Praha 2295. Ovšemže by to bylo asi více domů. -- Petr

15.2.2014 06:57:12 (#41)
gravatar

Petr Vejsada

<osm at propsychology.cz>
516
Ahoj, Xificurkovy připomínky jsou mi velmi blízké a sympatické, nelíbí se mi duplikace dat. To je ideální svět, ve kterém nejsme. Jedna věc je, rozhodnout se nějaký tag nepřidávat versus nějaký tag mazat. V případě addr:country a is_in by to bylo ve většině případů mazání, nikoli nepřidávání. Nechci nikomu rozbíjet Navit (příklad) ani nikoho nutit předělávat osm2navit. OSM snad není jen pro ajťáky a kartografy. Chybění tagů, které možná nějaký soft využívá, by mohlo stimulovat pokrok ve vývoji dotyčného software - vývojáři by byli "nuceni" svůj soft přizpůsobit novému obsahu databáze, jen si myslím, že zrovna nefunkční vyhledávání v CZ v Navitu (příklad) nezpůsobí, že vývojáři všeho nechají a vrhnou se na "opravu" Navitu. Proto se kloním k tomu zahrnout do importu i addr:country a is_in. Takže Přidávat, nahrazovat: addr:conscriptionnumber addr:provisionalnumber addr:streetnumber addr:housenumber addr:street addr:place addr:suburb addr:city addr:postcode addr:country=CZ is_in source:addr=cuzk:ruian ref:ruian:addr=nnnnnn Mazat: addr:provisional # cca 200 případů, asi záměna s addr:provisionalnumber addr:number # několik případů, asi omyl addr:alternatenumber # asi 300 případů, asi záměna s conscriptionnumber ref:ruian # Minimalis_import i jiné uir_adr:ADRESA_KOD či uir_adr:adresa_kod Jelikož j obecnému konsensu ohledně is_in a addr:country nejspíš nedojde, chci poprosit, abyste se už k přidávání těchto tagů nevyjadřovali, ledaže by nutkání či argumenty byly nepřekonatelně silné. Zato uvítám podněty k obsahu tagu is_in. K diskusi: - obsah tagu is_in - source:position - nevím, k čemu je. Možnosti ignorovat, mazat, i nově přidaných AM přidat, ? - cokoli dalšího ;) -- Petr

15.2.2014 08:32:44 (#42)
gravatar

Dalibor Jelínek

<dalibor at dalibor.cz>
415 1552
Tak prohledej archiv talk-cz. O tehle zmene v Nominatim jsem psal uz o dost drive. :-) Sent from my HTC
----- Reply message ----- From: "Petr Vejsada" <osm na propsychology.cz> To: "OpenStreetMap Czech Republic" <talk-cz na openstreetmap.org> Subject: [Talk-cz] Adresy z RUIAN Date: Sat, Feb 15, 2014 16:46 Ahoj, Dne So 15. února 2014 15:02:41, Petr Morávek [Xificurk] napsal(a): Z Changelogu verze 2.1 (poslední stable): * support for addresses without a street (addr:place and conscription number house numbers) takže to vypadá, že schopnost nalézt dům bez ulice je vlastně nová vlastnost. Koukal jsem do gitu Nominatimu, nenašel jsem od release 2.1 žádné změny v tomto smyslu. zobrazit citaci
> Dne 15.2.2014 14:50, Petr Vejsada napsal(a): > > K tomuto tolik, že i ten Nominatim má vážný problém. > > > > Libochovany 129 - prostě to nenajde, ačkoli má dokonce hned dvě možnosti, > > jak to udělat. Barák existuje, existují hranice obce, existují hranice > > "čtvrti" - asi katastrální území, existuje addr:city, addr:housenumber i > > addr:conscriptionnumber. > > A dokonce i is_in=Libochovany, Ústecký kraj, CZ > Chtělo by to přijít na to, kde je zakopaný pes a proč to nenajde. > > > Z toho víceméně vyplývá, že nebude schopen najít barák ve městě ani po > > zavedení addr:place. > > Já teda osobně nevidím, jak to z toho vyplývá (vždyť ani nevíme, proč > nenajde "Libochovany 129"!) > A že nenajde adresu Praha 42 je sice škoda, ale žádná tragedie. > > > Dotaz bude muset být na část obce (což v případě > > Libochovan jsou taky Libochovany), ovšem ne vždy tomu tak bude. > > To by nebylo až tak katastrofální - typicky chceš hledat podle názvu > ulice, nebo části obce (protože tam nejsou pojmenované ulice). > > Petr > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz
_______________________________________________ Talk-cz mailing list Talk-cz na openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20140215/a9b3955f/attachment.html>

15.2.2014 08:35:47 (#43)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
Dne 15.2.2014 18:57, Petr Vejsada napsal(a): zobrazit citaci
> Jelikož j obecnému konsensu ohledně is_in a addr:country nejspíš nedojde, chci > poprosit, abyste se už k přidávání těchto tagů nevyjadřovali, ledaže by > nutkání či argumenty byly nepřekonatelně silné. Zato uvítám podněty k obsahu > tagu is_in. > > K diskusi: > > - obsah tagu is_in
Ahoj, dokud nebude jasné čemu má obsah toho tagu sloužit, tak se těžko shodnem na jeho formátu. Já taky nechci někomu zbytečně rozbíjet fungující software, a proto mě zajímá která konkrétní věc s is_in/addr:country tagem funguje a bez něj ne. Pokud jsem něco nepřehlédl, tak tu zatím nikdo takovou neuvedl. Nominatim - umí polygony hranic, addr:country/is_in tedy není potřeba. Navit - resp. maptool, které převádí osm formát do binárního formátu pro navit, umí polygony hranic států i měst, is_in/addr:country tedy není potřeba. MoNav - sice neumí polygony hranic, ale neumí ani is_in/addr:country. OsmAnd - umí polygony hranic, is_in/addr:country tedy není potřeba. ... Ne opravdu jsem neprocházel všechen software, ale čistě ze statistik taginfo bych se fakt divil, kdyby na přítomnost těchto tagů něco opravdu spoléhalo. Zajímá mě nějaký příklad toho, kde jsou tyto tagy užitečné mj. i proto, abysme si vyjasnili, jaký formát/obsah by is_in mělo mít. Zdraví, Petr Morávek aka Xificurk

15.2.2014 10:23:08 (#44)
gravatar

Václav Řehák

<rehakv01 at gmail.com>
63
zobrazit citaci
> > > Já taky nechci někomu zbytečně rozbíjet fungující software, a proto mě > zajímá která konkrétní věc s is_in/addr:country tagem funguje a bez něj > ne. Pokud jsem něco nepřehlédl, tak tu zatím nikdo takovou neuvedl. >
A nemůžeme to vzít opačně? Opravdu ti ta duplicita addr:country vadí na tolik, že má smysl kvůli tomu zdržovat celý import? Obecná zásada bývá nedělat duplicity, ale proč? Aby nevznikaly rozpory mezi neaktualizovanými verzemi těch dat. Zrovna u RUIANu si nemyslím, že by to byl problém, když většina těch dat bude importována/udržována automaticky. Jinak řečeno, pořád chceš příklady, co se rozbije, když to odstraníme. Máš nějaký příklad, co se rozbije, když to tam necháme/přidáme? Těch pár MB opravdu není argument ve světě OSM, kde se importují jednotlivé stromy v parku a další (pro mě až nesmyslné) detaily. O is_in nemluvím, tam je to asi opravdu nejasné, k čemu má sloužit a i to rozsynchronizování si dovedu představit o dost realističtěji. V. ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20140215/884c35f3/attachment.html>

15.2.2014 10:39:17 (#45)
gravatar

Pavel Machek

<pavel at ucw.cz>
1056 1226
On Sat 2014-02-15 16:04:20, Marián Kyral wrote: zobrazit citaci
> Dne 15.2.2014 12:57, Petr Morávek [Xificurk] napsal: > >Dne 15.2.2014 11:30, Pavel Machek napsal(a): > > >Co tam máš dál? ;-) > > > > > >>Z jineho mailu: > >> > >>#Aha. Takže Krásná, pošta Raškovice má být > >># > >>#addr:city=Raškovice > >>#is_in=Krásná > >># > >>#místo > >>#addr:city=Krásná > >>#is_in=Krásná > > > >Omlouvám se, to jsem nějak přehlédl. Ale naprosto nesouhlasím s tímto > >použitím. > >* addr:city by mělo obsahovat jméno obce, kde se AM nachází (tak jak je > >to i v RUIAN), v žádném případě by tam nemělo být něco jiného. > >* "pošta Raškovice" je to samé jako PSČ 73907. Nemá smysl tu samou > >informaci duplikovat v OSM. Ani není potřeba ji duplikovat v adrese na > >dopisu - jediný význam je "pro kontrolu", takže když napíšeš "Krásná, > >pošta Raškovice, PSČ 12345", tak to pravděpodobně dojde. Z vlastní > >zkušenosti vím, že Česká pošta je schopná doručit i dopisy s hodně > >zkomolenou adresou. > > Tak tohle je od Pavla trochu podpásovka. V tom původním emailu hned > za tím následoval otazník. Taky jsem se zmínil, že informace o poště > je v obsažena v PSČ. Nikdo to už pak nekomentoval.
Za podpasovku sorry, ale proste to dle wiki vypada, ze v addr:city ma byt jmeno posty, ktere se nemusi nutne shodovat s tim kde to je. Ze Vam to prijde reduntantni s PSC... no to asi ano, ale chudak zahranicni uzivatel asi nema po ruce databazi mest odpovidajicich k PSC... coz je duvod proc mame addr:city. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

15.2.2014 11:46:26 (#46)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
Dne 15.2.2014 16:41, Dalibor Jelínek napsal(a): zobrazit citaci
> Ahoj, > tohle jsem nepochopil. Proc by to po zavedeni addr:place nefungovalo? > Kdyz jsem to zkousel, tak to fungovalo vzdy na tvar addr:place cislo > popisne. Praha 2295 to samozrejme nenajde, ale Libeň 2295 ano. U tech > Libochovic to musi fungovat taky, kdyz si Nominatim docte addr:place do > databaze. > Dalibor
Ahoj, z toho, co jsem teď testoval to vypadá, že umí najít "Street 1", nebo " Place 2", ale ne obojí - pokud je nastaveno addr:street, tak už to nenajde kombinaci s addr:place. Ten příklad s Libní to umí jen proto, že existuje budova, která má addr:place, ale nemá addr:street a zároveň existují adresní body, které mají jak addr:place=Libeň, tak addr:street=Kovanecká. Škoda, že neumí oboje, ale asi je to celkem očekávané chování - když jsou pojmenované ulice, tak hledám podle názvu ulice. Zdraví, Petr Morávek aka Xificurk

16.2.2014 05:38:28 (#47)
gravatar

Petr Vejsada

<osm at propsychology.cz>
516
Ahoj, Dne So 15. února 2014 18:57:12, Petr Vejsada napsal(a): zobrazit citaci
> K diskusi: > > - obsah tagu is_in > > - source:position - nevím, k čemu je. Možnosti ignorovat, mazat, i nově > přidaných AM přidat, ?
source:position se nemaže, v případě přidávání nových bodů se přidává. V is_in je momentálně text 'Is in ...', dokud se nedohodne, co s tím. Na http://pedro.poloha.net/osm/ukazka.osm je ulice Milady Horákové v Praze. Bot nevydal žádná varování. Prosím o kontrolu - překlepy a všeho, co vás napadne. JOSM proti ničemu neprotestuje. Neuploadovat na OSM ;-) -- Petr

16.2.2014 09:37:12 (#48)
gravatar

hanoj

<ehanoj at gmail.com>
718
zobrazit citaci
> > - source:position - nevím, k čemu je. Možnosti ignorovat, mazat, i nově > > přidaných AM přidat, ? > > > source:position se nemaže, v případě přidávání nových bodů se přidává.
*** spíše "source:loc" než "source:position" http://taginfo.openstreetmap.org/keys/source:position#combinations http://taginfo.openstreetmap.org/keys/source:loc#combinations hanoj ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20140216/6648b82b/attachment.html>

16.2.2014 11:06:57 (#49)
gravatar

Dalibor Jelínek

<dalibor at dalibor.cz>
415 1552
Ahoj, jo, to asi je lespi. Takze navthuji najit u adresniho bodu source:position source:pos a prendat obsah do source:loc a tagy smazat. a pokud nejsou, tak source:loc nastavit na cuzk:ruian. Zdravi, Dalibor From: hanoj [mailto:ehanoj na gmail.com] Sent: Sunday, February 16, 2014 9:37 AM To: OpenStreetMap Czech Republic Subject: Re: [Talk-cz] Ukázkový .osm Re: Adresy z RUIAN - 2. rekapitulace zobrazit citaci
> > - source:position - nevím, k čemu je. Možnosti ignorovat, mazat, i nově > > přidaných AM přidat, ? > > > source:position se nemaže, v případě přidávání nových bodů se přidává.
*** spíše "source:loc" než "source:position" http://taginfo.openstreetmap.org/keys/source:position#combinations http://taginfo.openstreetmap.org/keys/source:loc#combinations hanoj ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20140216/238e2631/attachment.html>

16.2.2014 11:28:27 (#50)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
Dne 16.2.2014 09:37, hanoj napsal(a): zobrazit citaci
>> > - source:position - nevím, k čemu je. Možnosti ignorovat, mazat, i nově >> > přidaných AM přidat, ? >> > >> source:position se nemaže, v případě přidávání nových bodů se přidává. > > *** spíše "source:loc" než "source:position" > http://taginfo.openstreetmap.org/keys/source:position#combinations > http://taginfo.openstreetmap.org/keys/source:loc#combinations > > hanoj
Ahoj, nebylo by lepší ty source tagy dát přímo na changeset (což je v současnosti doporučovaný postup pro importy)? Obzvláště u toho source:position, resp. source:loc bych se celkem bál, že při editaci lidi posunou bod, ale zapomenou změnit/odmazat tag. V ČR je stejně jen jeden zdroj pro tyhle data, takže není potřeba na každém bodu explicitně uvádět, že fakt pochází z RUIANu a ne odněkud jinud. Zdraví, Petr Morávek aka Xificurk

16.2.2014 12:02:45 (#51)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
Dne 15.2.2014 22:39, Pavel Machek napsal(a): zobrazit citaci
> Za podpasovku sorry, ale proste to dle wiki vypada, ze v addr:city ma > byt jmeno posty, ktere se nemusi nutne shodovat s tim kde to je. Ze > Vam to prijde reduntantni s PSC... no to asi ano, ale chudak > zahranicni uzivatel asi nema po ruce databazi mest odpovidajicich k > PSC... coz je duvod proc mame addr:city. > > Pavel >
Ahoj, já teda tu anglickou stránku [1] chápu tak, že tam má být to, co se píše do kolonky "město" na obálku dopisu. A to může a nemusí být shodné s městem, pod které adresní místo administrativně/územně spadá, ale zrovna tak to může a nemusí být shodné se jménem pošty, která dané místo obsluhuje. Problém je, že v ČR je to strašný maglajz. Česká pošta má sice nějaké doporučené vzory psaní adres [2], ale moc moudrý z toho nejsem. Přijde mi, že tam termín "obec" používají dost volně a skutečně se tváří jako, že chtějí hlavně jméno adresní pošty. Důsledné aplikování těch pravidel vede v mnoha případech k naprostým kravinám. Myslím, že bude lepší se přidržet toho tvaru, co zobrazuje RUIAN, t.j. držet addr:city="Název obce". Zdraví, Petr Morávek aka Xificurk [1] http://wiki.openstreetmap.org/wiki/Addr [2] http://www.ceskaposta.cz/cz/nastroje/uzitecne-informace/doporucene-vzory-postovnich-adres/doporucene-vzory-psani-postovnich-adres-id1078/

16.2.2014 12:03:25 (#52)
gravatar

Petr Vejsada

<osm at propsychology.cz>
516
Ahoj, může se stát, že některá adresní entita bude mít source:loc i source:position či source:pos zároveň. Co mám dělat pak? Prostým přejmenováním tagu vytvořím duplicitu. A který z nich si mám vybrat a použít jeho hodnotu pro source:loc? Když bude takových případů pár, tak to opravím ručně, nicméně může se stát, že narazím na lokalitu, kde bude takových 10.000 a do toho stavu bych se fakt nechtěl dostat. Dne Ne 16. února 2014 11:06:57, Dalibor Jelínek napsal(a): zobrazit citaci
> Ahoj, > > jo, to asi je lespi. > > > > Takze navthuji najit u adresniho bodu > > source:position > > source:pos > > a prendat obsah do > > source:loc > > a tagy smazat. > > > > a pokud nejsou, tak source:loc nastavit na cuzk:ruian. > > > > Zdravi, > > Dalibor > > > > > > From: hanoj [mailto:ehanoj na gmail.com] > Sent: Sunday, February 16, 2014 9:37 AM > To: OpenStreetMap Czech Republic > Subject: Re: [Talk-cz] Ukázkový .osm Re: Adresy z RUIAN - 2. rekapitulace > > > > - source:position - nevím, k čemu je. Možnosti ignorovat, mazat, i nově > > > přidaných AM přidat, ? > > > > source:position se nemaže, v případě přidávání nových bodů se přidává. > > *** spíše "source:loc" než "source:position" > http://taginfo.openstreetmap.org/keys/source:position#combinations > http://taginfo.openstreetmap.org/keys/source:loc#combinations > > > > hanoj
-- Petr

16.2.2014 12:09:16 (#53)
gravatar

Petr Vejsada

<osm at propsychology.cz>
516
Ahoj, Dne Ne 16. února 2014 11:28:27, Petr Morávek [Xificurk] napsal(a): zobrazit citaci
> nebylo by lepší ty source tagy dát přímo na changeset (což je v > současnosti doporučovaný postup pro importy)? > Obzvláště u toho source:position, resp. source:loc bych se celkem bál, > že při editaci lidi posunou bod, ale zapomenou změnit/odmazat tag. > > V ČR je stejně jen jeden zdroj pro tyhle data, takže není potřeba na > každém bodu explicitně uvádět, že fakt pochází z RUIANu a ne odněkud jinud.
Polohu neměním, tedy zdrojem polohy není RUIAN (pokud jím nebyl už v původní adrese). Zdrojem polohy je RUIAN pouze u nově přidávaných bodů. To vše právě proto, že s bodem mohl někdo šoupnout a posunout ho na lepší polohu - nad vchod, namísto původní, méně vhodné polohy. -- Petr

16.2.2014 12:16:44 (#54)
gravatar

Petr Vejsada

<osm at propsychology.cz>
516
Ahoj, jj, i v CZ: source:position | 45821 source:loc | 1113248 source:locality | 1 Dne Ne 16. února 2014 09:37:12, hanoj napsal(a): zobrazit citaci
> > > - source:position - nevím, k čemu je. Možnosti ignorovat, mazat, i nově > > > přidaných AM přidat, ? > > > > source:position se nemaže, v případě přidávání nových bodů se přidává. > > *** spíše "source:loc" než "source:position" > http://taginfo.openstreetmap.org/keys/source:position#combinations > http://taginfo.openstreetmap.org/keys/source:loc#combinations > > hanoj
-- Petr

16.2.2014 12:29:08 (#55)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
Dne 16.2.2014 12:09, Petr Vejsada napsal(a): zobrazit citaci
> Ahoj, > > Dne Ne 16. února 2014 11:28:27, Petr Morávek [Xificurk] napsal(a): > >> nebylo by lepší ty source tagy dát přímo na changeset (což je v >> současnosti doporučovaný postup pro importy)? >> Obzvláště u toho source:position, resp. source:loc bych se celkem bál, >> že při editaci lidi posunou bod, ale zapomenou změnit/odmazat tag. >> >> V ČR je stejně jen jeden zdroj pro tyhle data, takže není potřeba na >> každém bodu explicitně uvádět, že fakt pochází z RUIANu a ne odněkud jinud. > > Polohu neměním, tedy zdrojem polohy není RUIAN (pokud jím nebyl už v původní > adrese). Zdrojem polohy je RUIAN pouze u nově přidávaných bodů. To vše právě > proto, že s bodem mohl někdo šoupnout a posunout ho na lepší polohu - nad > vchod, namísto původní, méně vhodné polohy. > > -- > Petr
Aha, tak to jsem z té ukázky moc nepochopil - tam mají všechny body source:position=cuzk:ruian. To by asi mít neměly, vzhledem k tomu, že již existují a neposouváš je, ne? Ale stále platí výše uvedená otázka... V principu by všechny adresní body v ČR měly svým obsahem i pozicí být odvozeny od RUIAN. Jakékoliv odchylky od stavu RUIANu budou buď opravy chyb (doufejme, že jich v databázi moc není), malá pošoupnutí adresního místa na "lepší" místo (např. blíže k vchodu/schránce), příp. doplnění nějakých POI tagů. Otázkou tedy je, zda by nebylo vhodnější tyhle globální tagy dát přímo na changesety importu (jak doporučují import guidelines), na jednotlivých bodech by se pak už přidávat nemusely - co se s tím bodem během importu přesně dělalo, se uvidí v jeho historii. Zdraví, Petr Morávek aka Xificurk

16.2.2014 01:00:20 (#56)
gravatar

Petr Vejsada

<osm at propsychology.cz>
516
Ahoj, Dne Ne 16. února 2014 12:29:08, Petr Morávek [Xificurk] napsal(a): zobrazit citaci
> Aha, tak to jsem z té ukázky moc nepochopil - tam mají všechny body > source:position=cuzk:ruian. To by asi mít neměly, vzhledem k tomu, že > již existují a neposouváš je, ne?
Všechny mají source:addr=cuzk:ruian. source:position=cuzk:ruian mají jen nově přidané. 9 se nově přidává, 111 se upravuje. Ať koukám, jak koukám, vidím to tak, jak píšu. Nezaměnil jsi to se source:addr? zobrazit citaci
> > Ale stále platí výše uvedená otázka... V principu by všechny adresní > body v ČR měly svým obsahem i pozicí být odvozeny od RUIAN. Jakékoliv > odchylky od stavu RUIANu budou buď opravy chyb (doufejme, že jich v > databázi moc není), malá pošoupnutí adresního místa na "lepší" místo > (např. blíže k vchodu/schránce), příp. doplnění nějakých POI tagů.
Jestli to správně chápu, pak by to prakticky znamenalo zrušení informace o zdroji polohy pro všechny body a zavedení předpokladu, že vše pochází od CUZK, není-li uvedeno jinak. V praxi to tak je (pouze ty, které jsou zastoupeny více než 100x): cuzk:km | 1155200 uhul:ortofoto | 353 uhul:ortofoto, cuzk:km | 287 ruian | 2900 zobrazit citaci
> > Otázkou tedy je, zda by nebylo vhodnější tyhle globální tagy dát přímo > na changesety importu (jak doporučují import guidelines), na > jednotlivých bodech by se pak už přidávat nemusely - co se s tím bodem > během importu přesně dělalo, se uvidí v jeho historii.
Jaká konkrétní hodnota source:loc by se tedy měla dávat na changeset? Mně to vychází na cuzk:km, ovšem záeží na lokalitě. V okolí Vyškova to bude 99% RUIAN, protože tam prostě skoro žádné adresy nejsou. V Praze to bude cuzk:km. -- Petr

16.2.2014 01:01:58 (#57)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
Dne 15.2.2014 22:23, Václav Řehák napsal(a): zobrazit citaci
> > Já taky nechci někomu zbytečně rozbíjet fungující software, a proto mě > zajímá která konkrétní věc s is_in/addr:country tagem funguje a bez něj > ne. Pokud jsem něco nepřehlédl, tak tu zatím nikdo takovou neuvedl. > > > A nemůžeme to vzít opačně? Opravdu ti ta duplicita addr:country vadí na > tolik, že má smysl kvůli tomu zdržovat celý import? > > Obecná zásada bývá nedělat duplicity, ale proč? Aby nevznikaly rozpory > mezi neaktualizovanými verzemi těch dat. Zrovna u RUIANu si nemyslím, že > by to byl problém, když většina těch dat bude importována/udržována > automaticky. > > Jinak řečeno, pořád chceš příklady, co se rozbije, když to odstraníme. > Máš nějaký příklad, co se rozbije, když to tam necháme/přidáme? Těch pár > MB opravdu není argument ve světě OSM, kde se importují jednotlivé > stromy v parku a další (pro mě až nesmyslné) detaily. > > O is_in nemluvím, tam je to asi opravdu nejasné, k čemu má sloužit a i > to rozsynchronizování si dovedu představit o dost realističtěji. > > V.
Ahoj, však o addr:country už jsem psal dříve: zobrazit citaci
> Osobně jsem tedy pro: nepřidávat, ale nemazat (krom případů, kdy tam je > nějaký nesmysl).
Asi jsem to pak zbytečně zamotal tím, že jsem začal tak nějak addr:country a is_in házet do jednoho pytle - to proto, že se objevily názory, že oba tagy jsou užitečné a je žádoucí je všude ponechat a doplnit, ale zatím nikdo neukázal, kde/jak/proč jsou užitečné. is_in má oproti addr:country jeden zásadní problém - není jasné, co by tam mělo být, a tak není ani možné jednoduše zkontrolovat, jestli současný obsah na existujících bodech je blábol, nebo správná hodnota. A asi těžko vymyslíme Ten Správný Formát(TM), dokud nebude jasné k čemu/kde se to používá. Nepřidávání a zároveň nemazání addr:country má jeden pozitivní vedlejší efekt - pokud na tu hodnotu něco přeci jen spoléhá, tak: a) to bude i po importu fungovat ve stejné míře jako doteď b) je slušná šance, že si po importu někdo všimne (a ozve se), že software XYZ nefunguje úplně všude, protože ten tag někde chybí. Jakmile bude na stole konkrétní problém, tak bude rozhodování řádově snažší - buď doplníme tag na zbylé body, nebo se napíše patch, který to zvládne vyřešit i bez addr:country. Zdraví, Petr Morávek aka Xificurk

16.2.2014 01:14:32 (#58)
gravatar

Petr Vejsada

<osm at propsychology.cz>
516
Ahoj, procházím si těch 9 nově přidaných bodů. Milady Horákové 34 - ukázně pitomě umístěného bodu uprostřed baráku. Vsadím se, že Haškova 2 má v RUIAN stejnou pozici. Milady Horákové 135 - vůbec neleží na ulici Milady Horákové, ale věřme, že barák má opravdu adresu Milady Horákové 135. Většina těch nových bodů je umístěna nevhodně uprostřed baráku. Milady Horákové 98 je taky úplně jinde, rozhodně ne na ulici Milady Horákové, ovšem vchod tam může být. Dne Ne 16. února 2014 12:29:08, Petr Morávek [Xificurk] napsal(a): zobrazit citaci
> > Polohu neměním, tedy zdrojem polohy není RUIAN (pokud jím nebyl už v > > původní adrese). Zdrojem polohy je RUIAN pouze u nově přidávaných bodů. > > To vše právě proto, že s bodem mohl někdo šoupnout a posunout ho na lepší > > polohu - nad vchod, namísto původní, méně vhodné polohy.
-- Petr

16.2.2014 01:28:20 (#59)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
Dne 16.2.2014 13:00, Petr Vejsada napsal(a): zobrazit citaci
> Ahoj, > > Dne Ne 16. února 2014 12:29:08, Petr Morávek [Xificurk] napsal(a): > >> Aha, tak to jsem z té ukázky moc nepochopil - tam mají všechny body >> source:position=cuzk:ruian. To by asi mít neměly, vzhledem k tomu, že >> již existují a neposouváš je, ne? > > Všechny mají source:addr=cuzk:ruian. source:position=cuzk:ruian mají jen nově > přidané. 9 se nově přidává, 111 se upravuje. Ať koukám, jak koukám, vidím to > tak, jak píšu. Nezaměnil jsi to se source:addr?
Aha, moje chyba - já si proklikal jen pár náhodných bodů v západní části a naprosto špatně z toho vyvodil, že to mají všechny. zobrazit citaci
>> >> Ale stále platí výše uvedená otázka... V principu by všechny adresní >> body v ČR měly svým obsahem i pozicí být odvozeny od RUIAN. Jakékoliv >> odchylky od stavu RUIANu budou buď opravy chyb (doufejme, že jich v >> databázi moc není), malá pošoupnutí adresního místa na "lepší" místo >> (např. blíže k vchodu/schránce), příp. doplnění nějakých POI tagů. > > Jestli to správně chápu, pak by to prakticky znamenalo zrušení informace o > zdroji polohy pro všechny body a zavedení předpokladu, že vše pochází od CUZK, > není-li uvedeno jinak. V praxi to tak je (pouze ty, které jsou zastoupeny více > než 100x): > > cuzk:km | 1155200 > uhul:ortofoto | 353 > uhul:ortofoto, cuzk:km | 287 > ruian | 2900 > >> >> Otázkou tedy je, zda by nebylo vhodnější tyhle globální tagy dát přímo >> na changesety importu (jak doporučují import guidelines), na >> jednotlivých bodech by se pak už přidávat nemusely - co se s tím bodem >> během importu přesně dělalo, se uvidí v jeho historii. > > Jaká konkrétní hodnota source:loc by se tedy měla dávat na changeset? Mně to > vychází na cuzk:km, ovšem záeží na lokalitě. V okolí Vyškova to bude 99% > RUIAN, protože tam prostě skoro žádné adresy nejsou. V Praze to bude cuzk:km. > > -- > Petr
Na tom changesetu by to podle mě nebylo potřeba rozlišovat (jestli se mění/doplňuje adresa, nebo i pozice je vidět přímo z jeho obsahu), použil bych něco jako: source=cuzk:ruian url=http://wiki.openstreetmap.org/wiki/POPIS_IMPORTU import=yes bot=yes comment=??? V historii každého bodu pak bude např.: v1: import RUIAN v2: user123 změnil o pár mětrů pozici v3: user456 přidal shop=* ... Tím pádem na všech vytvořených nebo zkontrolovaných bodech by nebylo potřeba source:addr, source:loc by se nechalo jen pokud obsahuje nějakou jinou než s RUIANem související hodnotu, např. 'uhul:ortofoto'. Zdraví, Petr Morávek aka Xificurk

16.2.2014 02:22:49 (#60)
gravatar

Václav Řehák

<rehakv01 at gmail.com>
63
Ano, takto bych s tím souhlasil. V. Dne 16. února 2014 13:01 "Petr Morávek [Xificurk]" <petr na pada.cz> napsal(a): zobrazit citaci
> Dne 15.2.2014 22:23, Václav Řehák napsal(a): > > > > Já taky nechci někomu zbytečně rozbíjet fungující software, a proto > mě > > zajímá která konkrétní věc s is_in/addr:country tagem funguje a bez > něj > > ne. Pokud jsem něco nepřehlédl, tak tu zatím nikdo takovou neuvedl. > > > > > > A nemůžeme to vzít opačně? Opravdu ti ta duplicita addr:country vadí na > > tolik, že má smysl kvůli tomu zdržovat celý import? > > > > Obecná zásada bývá nedělat duplicity, ale proč? Aby nevznikaly rozpory > > mezi neaktualizovanými verzemi těch dat. Zrovna u RUIANu si nemyslím, že > > by to byl problém, když většina těch dat bude importována/udržována > > automaticky. > > > > Jinak řečeno, pořád chceš příklady, co se rozbije, když to odstraníme. > > Máš nějaký příklad, co se rozbije, když to tam necháme/přidáme? Těch pár > > MB opravdu není argument ve světě OSM, kde se importují jednotlivé > > stromy v parku a další (pro mě až nesmyslné) detaily. > > > > O is_in nemluvím, tam je to asi opravdu nejasné, k čemu má sloužit a i > > to rozsynchronizování si dovedu představit o dost realističtěji. > > > > V. > > Ahoj, > > však o addr:country už jsem psal dříve: > > Osobně jsem tedy pro: nepřidávat, ale nemazat (krom případů, kdy tam je > > nějaký nesmysl). > > Asi jsem to pak zbytečně zamotal tím, že jsem začal tak nějak > addr:country a is_in házet do jednoho pytle - to proto, že se objevily > názory, že oba tagy jsou užitečné a je žádoucí je všude ponechat a > doplnit, ale zatím nikdo neukázal, kde/jak/proč jsou užitečné. > > is_in má oproti addr:country jeden zásadní problém - není jasné, co by > tam mělo být, a tak není ani možné jednoduše zkontrolovat, jestli > současný obsah na existujících bodech je blábol, nebo správná hodnota. A > asi těžko vymyslíme Ten Správný Formát(TM), dokud nebude jasné k > čemu/kde se to používá. > > Nepřidávání a zároveň nemazání addr:country má jeden pozitivní vedlejší > efekt - pokud na tu hodnotu něco přeci jen spoléhá, tak: > a) to bude i po importu fungovat ve stejné míře jako doteď > b) je slušná šance, že si po importu někdo všimne (a ozve se), že > software XYZ nefunguje úplně všude, protože ten tag někde chybí. Jakmile > bude na stole konkrétní problém, tak bude rozhodování řádově snažší - > buď doplníme tag na zbylé body, nebo se napíše patch, který to zvládne > vyřešit i bez addr:country. > > Zdraví, > Petr Morávek aka Xificurk > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20140216/617a9079/attachment.html>

16.2.2014 02:24:21 (#61)
gravatar

Petr Vejsada

<osm at propsychology.cz>
516
Ahoj, začíná mi to trochu připomínat diskusi o administrativních hranicích, kam by stačilo přidávat addr:place ;-). Osobně nepovažuji source:loc za důležitý údaj a klidně bych ho vypustil. Mimochodem - sázku bych vyhrál - roh Milady Horákové a Haškovy - v RUIAN jsou obě adresy na stejném místě uprostřed baráku. Haškovu dělal Petr Dlouhý podle UIR_ADDR, nikdy jsem nezkoumal, jak to funguje a jak je tam určena poloha, nicméně tak, jak jsou umístěny adresní body v Haškově bych dal source:loc=zdravý_rozum ;-) Dne Ne 16. února 2014 13:28:20, Petr Morávek [Xificurk] napsal(a): zobrazit citaci
> > Jaká konkrétní hodnota source:loc by se tedy měla dávat na changeset? Mně > > to vychází na cuzk:km, ovšem záeží na lokalitě. V okolí Vyškova to bude > > 99% RUIAN, protože tam prostě skoro žádné adresy nejsou. V Praze to bude > > cuzk:km.
zobrazit citaci
> Na tom changesetu by to podle mě nebylo potřeba rozlišovat (jestli se > mění/doplňuje adresa, nebo i pozice je vidět přímo z jeho obsahu), > použil bych něco jako: > source=cuzk:ruian > url=http://wiki.openstreetmap.org/wiki/POPIS_IMPORTU > import=yes > bot=yes > comment=???
Tohle by šlo. zobrazit citaci
> > V historii každého bodu pak bude např.: > v1: import RUIAN > v2: user123 změnil o pár mětrů pozici > v3: user456 přidal shop=* > ... > > Tím pádem na všech vytvořených nebo zkontrolovaných bodech by nebylo > potřeba source:addr, source:loc by se nechalo jen pokud obsahuje nějakou > jinou než s RUIANem související hodnotu, např. 'uhul:ortofoto'.
Tohle by taky šlo, respektive je mi to jedno, nicméně červíček - vyžaduje to pátrání v historii uzlu a tedy to snižuje uživatelskou přívětivost editace a získávání informací. To znamená, že bych se musel kouknout na poslední changeset, pak na historii a z toho dovozovat, jaký je vlastně současný stav uzlu. Znamenalo by to, že informaci, která je teď dostupná hned, by bylo třeba dovozovat. Podobně jako ať si Navit (příklad) spočítá podle hranic, kde se vlastně nachází. No nic, jdu dodělávat další test, zda se adresní místo nachází do 50m od ulice, ke které patří. -- Petr

18.2.2014 07:26:28 (#62)
gravatar

Petr Vejsada

<osm at propsychology.cz>
516
Ahoj, Dne Ne 16. února 2014 13:28:20, Petr Morávek [Xificurk] napsal(a): zobrazit citaci
> Na tom changesetu by to podle mě nebylo potřeba rozlišovat (jestli se > mění/doplňuje adresa, nebo i pozice je vidět přímo z jeho obsahu), > použil bych něco jako: > source=cuzk:ruian > url=http://wiki.openstreetmap.org/wiki/POPIS_IMPORTU > import=yes > bot=yes > comment=??? > > V historii každého bodu pak bude např.: > v1: import RUIAN > v2: user123 změnil o pár mětrů pozici > v3: user456 přidal shop=* > ... > > Tím pádem na všech vytvořených nebo zkontrolovaných bodech by nebylo > potřeba source:addr, source:loc by se nechalo jen pokud obsahuje nějakou > jinou než s RUIANem související hodnotu, např. 'uhul:ortofoto'.
můžeš ještě upřesnit, co je 'nesouvisející s RUIAN'? Resp. související s RUIAN? uir_adr? cuzk:km? mvcr:adresa? Dík. -- Petr BTW: těch is_in je dnes dle mé DB 2.069.921. Hranice Geofabrik.

18.2.2014 07:44:34 (#63)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
Dne 18.2.2014 19:26, Petr Vejsada napsal(a): zobrazit citaci
> Ahoj, > > Dne Ne 16. února 2014 13:28:20, Petr Morávek [Xificurk] napsal(a): > >> Na tom changesetu by to podle mě nebylo potřeba rozlišovat (jestli se >> mění/doplňuje adresa, nebo i pozice je vidět přímo z jeho obsahu), >> použil bych něco jako: >> source=cuzk:ruian >> url=http://wiki.openstreetmap.org/wiki/POPIS_IMPORTU >> import=yes >> bot=yes >> comment=??? >> >> V historii každého bodu pak bude např.: >> v1: import RUIAN >> v2: user123 změnil o pár mětrů pozici >> v3: user456 přidal shop=* >> ... >> >> Tím pádem na všech vytvořených nebo zkontrolovaných bodech by nebylo >> potřeba source:addr, source:loc by se nechalo jen pokud obsahuje nějakou >> jinou než s RUIANem související hodnotu, např. 'uhul:ortofoto'. > > můžeš ještě upřesnit, co je 'nesouvisející s RUIAN'? Resp. související s > RUIAN? uir_adr? cuzk:km? mvcr:adresa? Dík.
Pro tyto účely bych za shodné považoval ruian, cuzk:ruian (příp. další variace) a cuzk:km. Ten zbytek bych asi radši nechal oddělený - kdo ví, co v těch rejstříkách tenkrát bylo nebo nebylo. zobrazit citaci
> -- > Petr > BTW: těch is_in je dnes dle mé DB 2.069.921. Hranice Geofabrik.
Je drsné, že u nás v ČR je 3x víc bodů s is_in než v celém zbytku světa. A dalším zajímavým poznatkem z českého taginfo je, že adresní body (a to ještě nejsou v OSM všechny) u nás tvoří cca 70% všech "tagovaných" bodů. Zdraví, Petr Morávek aka Xificurk

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