Re: [Talk-cz] Formát zápisu adresních bodů (was Data RUIAN - výměnný formát)
pokusim se vmisit... Trochu sem se prohrab temi samply, a me by se libilo nevyrabet adresni body ale priradit adresy budovam, neb ta vazba v tech datech je. Bod bych vyrobil jen tam, kde budova neni (a je tam definovana adresa). Co se tyce ulic, tam to asi s jejich presnosti nebude zadna slava - predpokladam, ze kazdej kdo obkresloval rucne to udelal podrobnejsi. Ale lepsi nez dratem do oka. Adresní bod a budova ... to mě napadlo také (a někde se to v OSM i používá), ale vidím v tom trochu problémy. Zaprvé budova může mít více vchodů/adres. Jak by se jmenovaly tagy? addr:housenumber1, addr:housenumber2, addr:housenumber3 apod.? Nebo by se dělila budova na části? Ale jak? Nikdo nebude zkoumat vnitřní strukturu budovy - typicky ji vidíš zvenku a pár vchodů dovnitř. Občas se je zřejmé, ale nemusí být vždy. S tim se pocita, data v tech samplech jsou reseny jak sem si vsim tak, ze jedna adresa, je zvolena jako primarni a dalsi jsou k ni pripojeny jako sekundarni = na budovu se da ta primarni, ostatni se muzou hodit jako body. Samo, technicky spravne by bylo to na tu budovu nahazet podobne, jako je to ve zdroji, ale to se obavam v OSM netusim jak udelat, aby to zaroven fungovalo - idealni by bylo neco jako hodit tu budovu do relace a adresu urcit az v ty relaci, cimz by slo budove dat neomezeny mnozstvi relaci/adres, ale obavam se, ze tohle zadnej stavajici nastroj nepobere. Ostatne, podobne bych si doved predstavit i prilinkovani veci jako hospoda (+samo nazev, otviracka, ...), posilovna ... , cimz by se eliminoval vsemoznej tagovaci chaos (pokud na necem je 20+ tagu, tak uz je to peknej bordelak) a navrch by souvisejici data byly pekne pohromade. Du testnout, co neco takovyho udela ;D. Jinak, pokud predpokladam, ze vetsina km vypada vsude +- stejne, tak zaroven predpokladam, ze v drtivy vetsine pripadu budou klasicky panelaky zaneseny co vhod to samostatna budova (i kdyz to konstrukcne neni pravda). Budov s vice adresami nebude (IMO) nijak zavratny mnoztvi. *** Me se vlozeni adresniho bodu do budovy nelibi (pokud to dobre chapu). Adresni bod je bod uz z nazvu. To ze se zvyrazni budova pod nim je veci sw a trivialni prostorove analyzy. Budova se casto sklada z pristavku a privesku a co bude mit adresni bod, nejvetsi cast budovy? V Brne je skoro kazdy druhy rohovy dum s dvema adresnimi body. Vazba budova a adresni bod bude tedy velmi volna, M:N. Ale urcite at je jeden element (adresni bod) jedna normalni forma, primarni sekundarni to je spatne... hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Formát zápisu adresních bodů (was Data RUIAN - výměnný formát)
Dne 26.6.2012 19:21, Libor Pechacek napsal(a): Ahoj Honzo, Zabral jsem se do detailů a nějak zapomněl uzavřít návrhem. Jsem pro požití tagů addr:housenumber, addr:streetnumber, addr:conscriptionnumber, addr:street a is_in. Is_in proto, že často obsahuje informaci o městských částech, kterou z mapy nelze odvodit. Pokud někdo najde nějakou hypoalergenní[1] variantu k is_in, jsem pro. Dál navrhuji seskupit adresy jedné ulice do relace, která ponese addr:street a is_in, aby se předešlo duplikaci. Adresní body by v tom případě měly jen addr:housenumber, addr:streetnumber a addr:conscriptionnumber. Otázkou je, jak by taková relace měla vypadat[2]. Toto je neprohledatelny, zadny stavajici nastroj s necim takovym nepocita, tudiz tu adresu nikdo nenajde. Jako bonus je to obtizne editovatelny. Podle me naopak nejvetsi kandidat na vyhozeni je prave is_in, protoze je to nestrukturovana hromada cehosi. Navic v soucasnosti drtiva vetsina aplikaci spravne najde ze adresa lezi uvnitr boundary XYZ. Priklad http://nominatim.openstreetmap.org/details.php?place_id=43709385 PSC je naopak identifikator, ktery muze byt v ramci stejneho katastralniho uzemi ruzny, tudiz rozhodne ponechat. Uvedom si, ze nektere podniky maji vlastni psc. Nehlede na to, ze pokud si pamatuju, vedla se tu na to tema uz nejaka diskuse, a prakticky nikdo neni schopen rict, odkud kam je nejake konkretni psc. country a city ... country je asi na vyhozeni, u city tam je to takove trochu sporne, neb by IMO adresa mela byt komplet - zkratka kdyz si sosnu vyrez mapy, tak bych z toho tagovani mel byt schopen tu adresu dohledat kdekoli a nemuset si kvuli tomu stahovat cely mesto. Ale technicky to samozrejme nadbytecny je. Addr:postcode, addr:city a addr:country bych klidně zahodil, pokud neposlouží jako náhrada is_in. Libor [1] http://wiki.openstreetmap.org/wiki/Key:is_in#Controversy [2] v úvahu zřejmě připadá http://wiki.openstreetmap.org/wiki/Relations/Proposed/Collected_Ways, http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street nebo http://wiki.openstreetmap.org/wiki/Relation:associatedStreet On Tue 26-06-12 16:12:11, Jan Bilak wrote: Ahoj, díky za rozbor, ale myslel jsem to tak, jaký zápis chceme v OSM ideálně mít. Tedy v jakém formátu připravovat import z RUIAN, jaké tagy tam dát pro nové adresní body, jaké tagy doplnit ke stávajícím, jaké existující tagy případně smazat nebo změnit (ostatní předpokládám zachovat). Tedy aby to všude jednotné (+ u některých bodů nějaké specifické tagy). Jak se má složit obsah tagu is_in (pokud tam má být), protože to je složenina různých údajů. Honza Dne 26. června 2012 13:58 Libor Pechacek lpecha...@gmx.com napsal(a): Ahoj, Z mojí zkušenosti se formát adresního bodu liší podle použitého nástroje. Jsou tři (polo)automatické způsoby importu, a nakonec pak ruční zadání. On Tue 26-06-12 04:14:04, Jan Bilak wrote: jak vypadá ideální zápis adresního bodu v OSM XML? Koukal jsem se do snapshotu OSM dat ČR a zápisy nemají jednotný formát. Např.: node id=296674495 lat=48.9631350 lon=14.5119948 version=2 changeset=1965423 user=Radomír Černoch uid=51295 timestamp=2009-07-28T14:56:31Z tag k=addr:conscriptionnumber v=2030 / tag k=addr:housenumber v=2030/1 / tag k=addr:postcode v=37006 / tag k=addr:street v=U pramene / tag k=addr:streetnumber v=1 / tag k=source:addr v=uir_adr / tag k=uir_adr:ADRESA_KOD v=23398671 / /node Tohle je podle mě výsledek UIR-ADR importu. http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap#Adresn.C3.AD_body_-_MPSV.28UIR-ADR.29 node id=1496603658 lat=48.8736400 lon=14.6758775 version=1 changeset=9784174 user=Petr1868 uid=72020 timestamp=2011-11-09T19:54:47Z tag k=addr:conscriptionnumber v=13 / tag k=addr:country v=CZ / tag k=addr:housenumber v=13 / tag k=is_in v=Třebeč, Borovany, Jihočeský kraj, CZ / tag k=source:addr v=mvcr:adresa / tag k=source:loc v=cuzk:km / /node Tento záznam vytváří nástroje napsané Lukášem Kábrtem. http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR Pokud jsou v obci ulice, je přítomen i tag addr:street. node id=33705330 lat=49.7021197 lon=17.0731786 version=12 changeset=5435557 user=NE2 uid=207745 timestamp=2010-08-08T17:43:41Z tag k=addr:city v=Litovel / tag k=addr:conscriptionnumber v=678 / tag k=addr:country v=CZ / tag k=addr:housenumber v=678/1 / tag k=addr:postcode v=78401 / tag k=addr:street v=Mlýnská / tag k=addr:streetnumber v=1 / tag k=is_in v=Litovel, Olomoucký kraj, CZ / tag k=name v=Penzion U starého mlýna / tag k=source:addr v=mvcr:adresa / tag k=tourism v=hotel /
Re: [Talk-cz] Formát zápisu adresních bodů (was Data RUIAN - výměnný formát)
Dne 27.6.2012 5:05, Jan Bilak napsal(a): Ahoj, koukám, že tu budou i různé rozdíly mezi adresami z registru a z OSM, i když v OSM mají v tagu uveden kód adresy registru (tedy mělo by se jednat o stejnou adresu a asi import z UIR-ADR): Pár rozdílů z Prahy (pokud jsem neudělal chybu): http://jabi.aspone.cz/osm/temp/praha-rozdily.pdf Narážím konkrétně na rozdíly v číslech domu, nikoli v poloze. Poznámka: levá část je z registru, pravá část z OSM, 0 = neuvedeno, vzdálenost brát s velkou rezervou, celkově je výstup odporný... Otázka je, co je správně. Řešit to ručně? Bude toho mnohem více (i z Prahy). A jak to vůbec řešit? Honza To tam budes muset vyrazit a podivat se ... ;D Ne, vazne, chyby jsou ve vsech zdrojich, a pokud preadresujes neco trebas tak, ze tam nekdo importoval a ty pres to pustis josm plugin, tak zjistis, ze ti kazdej zdroj bude tvrdit neco trochu jinyho. Ohledne reseni - pokud je tam nejaky zasadni rozdil, tak by asi nebylo od veci stavajici marknout jako fixme a prifarit tam trebas novy bod s adresou ze zdroje a k tomu pridat trebas note. Nasledne je to na rucni upravy/opravy. Ale nerad bych opet videl dalsi vodni toky ... ;D Protoze spravovat neco je 100x vetsi vopruz nez to nakreslit rucne. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Formát zápisu adresních bodů (was Data RUIAN - výměnný formát)
On Wed 27-06-12 09:22:24, jzvc wrote: Dne 26.6.2012 19:21, Libor Pechacek napsal(a): Ahoj Honzo, Zabral jsem se do detailů a nějak zapomněl uzavřít návrhem. Jsem pro požití tagů addr:housenumber, addr:streetnumber, addr:conscriptionnumber, addr:street a is_in. Is_in proto, že často obsahuje informaci o městských částech, kterou z mapy nelze odvodit. Pokud někdo najde nějakou hypoalergenní[1] variantu k is_in, jsem pro. Dál navrhuji seskupit adresy jedné ulice do relace, která ponese addr:street a is_in, aby se předešlo duplikaci. Adresní body by v tom případě měly jen addr:housenumber, addr:streetnumber a addr:conscriptionnumber. Otázkou je, jak by taková relace měla vypadat[2]. Toto je neprohledatelny, zadny stavajici nastroj s necim takovym nepocita, tudiz tu adresu nikdo nenajde. Jako bonus je to obtizne editovatelny. Nominatim používá relaci associatedStreet. http://wiki.openstreetmap.org/wiki/Nominatim/Development_overview#Building_Indexing Editace jsou samozřejmě obtížnější, nicméně mě stále láká strukturovanost této relace. Na druhou stranu, software na import asi psát nebudu, a kdyby ano, nemořil bych se s generováním relací. Takže to tu nechme jako dobrý nápad. Podle me naopak nejvetsi kandidat na vyhozeni je prave is_in, protoze je to nestrukturovana hromada cehosi. Navic v soucasnosti drtiva vetsina aplikaci spravne najde ze adresa lezi uvnitr boundary XYZ. Souhlas, je to nestrukturovaná hromada, ovšem to cosi nese užitečnou informaci. Jak už jsem psal, někdy jedno katastrální uzemí obsahuje více částí obce, každá část má vlastní číslování domů. Tedy v hranicích jednoho KÚ se čísla opakují. Priklad http://nominatim.openstreetmap.org/details.php?place_id=43709385 Protipříklad http://nominatim.openstreetmap.org/details.php?place_id=14212965 Nominatim podle administrativní hranice odvodil příslušnost k Pískové Lhotě, ale tento dům je v Pískové Lhotě - Zámostí. Písková Lhota 8 je tady: http://www.openstreetmap.org/browse/node/123898 Zřejmě bych dovedl najít i příklad kde je v jednom KÚ více obcí s různými jmény. PSC je naopak identifikator, ktery muze byt v ramci stejneho katastralniho uzemi ruzny, tudiz rozhodne ponechat. Uvedom si, ze nektere podniky maji vlastni psc. Nehlede na to, ze pokud si pamatuju, vedla se tu na to tema uz nejaka diskuse, a prakticky nikdo neni schopen rict, odkud kam je nejake konkretni psc. Já osobně PSČ k vyhledání adres nepoužívám, ale nejsem proti přidání tohoto údaje. country a city ... country je asi na vyhozeni, u city tam je to takove trochu sporne, neb by IMO adresa mela byt komplet - zkratka kdyz si sosnu vyrez mapy, tak bych z toho tagovani mel byt schopen tu adresu dohledat kdekoli a nemuset si kvuli tomu stahovat cely mesto. Ale technicky to samozrejme nadbytecny je. Jak vidno výše, Nominatim nášemu formátu is_in asi nerozumí. Jestli porozumí addr:city, použijme ten. Libor Addr:postcode, addr:city a addr:country bych klidně zahodil, pokud neposlouží jako náhrada is_in. Libor [1] http://wiki.openstreetmap.org/wiki/Key:is_in#Controversy [2] v úvahu zřejmě připadá http://wiki.openstreetmap.org/wiki/Relations/Proposed/Collected_Ways, http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street nebo http://wiki.openstreetmap.org/wiki/Relation:associatedStreet On Tue 26-06-12 16:12:11, Jan Bilak wrote: Ahoj, díky za rozbor, ale myslel jsem to tak, jaký zápis chceme v OSM ideálně mít. Tedy v jakém formátu připravovat import z RUIAN, jaké tagy tam dát pro nové adresní body, jaké tagy doplnit ke stávajícím, jaké existující tagy případně smazat nebo změnit (ostatní předpokládám zachovat). Tedy aby to všude jednotné (+ u některých bodů nějaké specifické tagy). Jak se má složit obsah tagu is_in (pokud tam má být), protože to je složenina různých údajů. Honza Dne 26. června 2012 13:58 Libor Pechacek lpecha...@gmx.com napsal(a): Ahoj, Z mojí zkušenosti se formát adresního bodu liší podle použitého nástroje. Jsou tři (polo)automatické způsoby importu, a nakonec pak ruční zadání. On Tue 26-06-12 04:14:04, Jan Bilak wrote: jak vypadá ideální zápis adresního bodu v OSM XML? Koukal jsem se do snapshotu OSM dat ČR a zápisy nemají jednotný formát. Např.: node id=296674495 lat=48.9631350 lon=14.5119948 version=2 changeset=1965423 user=Radomír Černoch uid=51295 timestamp=2009-07-28T14:56:31Z tag k=addr:conscriptionnumber v=2030 / tag k=addr:housenumber v=2030/1 / tag k=addr:postcode v=37006 / tag k=addr:street v=U pramene / tag k=addr:streetnumber v=1 / tag k=source:addr v=uir_adr / tag k=uir_adr:ADRESA_KOD v=23398671 / /node Tohle je podle mě výsledek UIR-ADR importu.
Re: [Talk-cz] Formát zápisu adresních bodů (was Data RUIAN - výměnný formát)
Ono, co si budem rikat, mazat se da vzdycky, takze lepsi je tam mit duplicitni a nadbytecna data, nez tam neco nemit. Trochu sem se prohrab temi samply, a me by se libilo nevyrabet adresni body ale priradit adresy budovam, neb ta vazba v tech datech je. Bod bych vyrobil jen tam, kde budova neni (a je tam definovana adresa). Co se tyce ulic, tam to asi s jejich presnosti nebude zadna slava - predpokladam, ze kazdej kdo obkresloval rucne to udelal podrobnejsi. Ale lepsi nez dratem do oka. Co se tyce dalsich dat, pokud sem dobre zahlid, je tam nejaky typ/zpusob vyuziti budovy - predpokladam neco jako obytna/prumyslova/... to by se dalo vyuzit jako parametr pro building= , ale nikde sem nenasel nejakej popis co za hodnoty tam muze byt a co znamenaji - hedal sem tuhle http://www.cuzk.cz/docvfr/vfr-schema-doc/. Tohle je pekny, ale uvital bych SVG. obi:VlajkaTextList tvoří tři vodorovné pruhy, žlutý, modrý oboustranně zubatý a žluto-černě polcený, v poměru 1:2:1. Modrý má nahoře i dole po čtyřech zubech a pěti mezerách, vysokých jednu osminu šířky listu. V modrém pruhu žlutý kráčející lev s červenou zbrojí držící v předních tlapách bílou rybu hlavou nahoru a hřbetem k žerdi. Poměr šířky k délce listu je 2:3./obi:VlajkaText obi:ZnakTextV modrém štítě se zlatou cimbuřovou hlavou zlatý kráčející lev s červenou zbrojí držící v předních tlapách stříbrnou rybu, pod ním zlato-černě polcený štítek./obi:ZnakText Pocet podlazi se urcite vyuzije, pokud se najde zbusob jak zjistit, kolik jich je nad zemi ... , mapka bude pekne 3D Dne 27.6.2012 15:33, Libor Pechacek napsal(a): On Wed 27-06-12 09:22:24, jzvc wrote: Dne 26.6.2012 19:21, Libor Pechacek napsal(a): Ahoj Honzo, Zabral jsem se do detailů a nějak zapomněl uzavřít návrhem. Jsem pro požití tagů addr:housenumber, addr:streetnumber, addr:conscriptionnumber, addr:street a is_in. Is_in proto, že často obsahuje informaci o městských částech, kterou z mapy nelze odvodit. Pokud někdo najde nějakou hypoalergenní[1] variantu k is_in, jsem pro. Dál navrhuji seskupit adresy jedné ulice do relace, která ponese addr:street a is_in, aby se předešlo duplikaci. Adresní body by v tom případě měly jen addr:housenumber, addr:streetnumber a addr:conscriptionnumber. Otázkou je, jak by taková relace měla vypadat[2]. Toto je neprohledatelny, zadny stavajici nastroj s necim takovym nepocita, tudiz tu adresu nikdo nenajde. Jako bonus je to obtizne editovatelny. Nominatim používá relaci associatedStreet. http://wiki.openstreetmap.org/wiki/Nominatim/Development_overview#Building_Indexing Editace jsou samozřejmě obtížnější, nicméně mě stále láká strukturovanost této relace. Na druhou stranu, software na import asi psát nebudu, a kdyby ano, nemořil bych se s generováním relací. Takže to tu nechme jako dobrý nápad. Podle me naopak nejvetsi kandidat na vyhozeni je prave is_in, protoze je to nestrukturovana hromada cehosi. Navic v soucasnosti drtiva vetsina aplikaci spravne najde ze adresa lezi uvnitr boundary XYZ. Souhlas, je to nestrukturovaná hromada, ovšem to cosi nese užitečnou informaci. Jak už jsem psal, někdy jedno katastrální uzemí obsahuje více částí obce, každá část má vlastní číslování domů. Tedy v hranicích jednoho KÚ se čísla opakují. Priklad http://nominatim.openstreetmap.org/details.php?place_id=43709385 Protipříklad http://nominatim.openstreetmap.org/details.php?place_id=14212965 Nominatim podle administrativní hranice odvodil příslušnost k Pískové Lhotě, ale tento dům je v Pískové Lhotě - Zámostí. Písková Lhota 8 je tady: http://www.openstreetmap.org/browse/node/123898 Zřejmě bych dovedl najít i příklad kde je v jednom KÚ více obcí s různými jmény. PSC je naopak identifikator, ktery muze byt v ramci stejneho katastralniho uzemi ruzny, tudiz rozhodne ponechat. Uvedom si, ze nektere podniky maji vlastni psc. Nehlede na to, ze pokud si pamatuju, vedla se tu na to tema uz nejaka diskuse, a prakticky nikdo neni schopen rict, odkud kam je nejake konkretni psc. Já osobně PSČ k vyhledání adres nepoužívám, ale nejsem proti přidání tohoto údaje. country a city ... country je asi na vyhozeni, u city tam je to takove trochu sporne, neb by IMO adresa mela byt komplet - zkratka kdyz si sosnu vyrez mapy, tak bych z toho tagovani mel byt schopen tu adresu dohledat kdekoli a nemuset si kvuli tomu stahovat cely mesto. Ale technicky to samozrejme nadbytecny je. Jak vidno výše, Nominatim nášemu formátu is_in asi nerozumí. Jestli porozumí addr:city, použijme ten. Libor Addr:postcode, addr:city a addr:country bych klidně zahodil, pokud neposlouží jako náhrada is_in. Libor [1] http://wiki.openstreetmap.org/wiki/Key:is_in#Controversy [2] v úvahu zřejmě připadá http://wiki.openstreetmap.org/wiki/Relations/Proposed/Collected_Ways, http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street nebo http://wiki.openstreetmap.org/wiki/Relation:associatedStreet On Tue 26-06-12 16:12:11,
Re: [Talk-cz] Formát zápisu adresních bodů (was Data RUIAN - výměnný formát)
Ahoj, Trochu sem se prohrab temi samply, a me by se libilo nevyrabet adresni body ale priradit adresy budovam, neb ta vazba v tech datech je. Bod bych vyrobil jen tam, kde budova neni (a je tam definovana adresa). Co se tyce ulic, tam to asi s jejich presnosti nebude zadna slava - predpokladam, ze kazdej kdo obkresloval rucne to udelal podrobnejsi. Ale lepsi nez dratem do oka. Adresní bod a budova ... to mě napadlo také (a někde se to v OSM i používá), ale vidím v tom trochu problémy. Zaprvé budova může mít více vchodů/adres. Jak by se jmenovaly tagy? addr:housenumber1, addr:housenumber2, addr:housenumber3 apod.? Nebo by se dělila budova na části? Ale jak? Nikdo nebude zkoumat vnitřní strukturu budovy - typicky ji vidíš zvenku a pár vchodů dovnitř. Občas se je zřejmé, ale nemusí být vždy. Zadruhé adresní bod (pokud je vhodně umístěn) říká i polohu vchodu. Např. budova stojí mezi dvěma ulicemi a takto by nebylo zřejmé, odkud je vlastně vchod. Zatřetí je otázka, zda je vhodné štěpit jeden druh informace do různých zápisů (někdy adresní bod, někde vlastnost budovy). Nicméně informace u budovy může být také užitečná. Teoreticky lze najít všechny adresní body, které leží uvnitř polygonu budovy. Jak je rychlé/pracné, to záleží na tom, jak se data oindexují apod. Jak je to pracné v existujících nástrojích, to nevím. Předpokládám, že dotaz na objekty ležící v daném obdélníku je jeden z nejčastějších dotazů a data jsou tedy vhodně oindexována (r-tree, quad-tree nebo tak něco). Tohle je pekny, ale uvital bych SVG. obi:VlajkaTextList tvoří tři vodorovné pruhy, žlutý, modrý oboustranně zubatý a žluto-černě polcený, v poměru 1:2:1. Modrý má nahoře i dole po čtyřech zubech a pěti mezerách, vysokých jednu osminu šířky listu. V modrém pruhu žlutý kráčející lev s červenou zbrojí držící v předních tlapách bílou rybu hlavou nahoru a hřbetem k žerdi. Poměr šířky k délce listu je 2:3./obi:VlajkaText obi:ZnakTextV modrém štítě se zlatou cimbuřovou hlavou zlatý kráčející lev s červenou zbrojí držící v předních tlapách stříbrnou rybu, pod ním zlato-černě polcený štítek./obi:ZnakText Tohle tam není jen textově, ale i ve formě obrázků. Pravda - bitmap, nikoli vektorů. Ono asi ani všechno vektory nejde dobře vyjádřit nebo nejsou data ve vektorech dostupná. Přeci jen tohle vznikalo v době, kdy se ještě malovalo štětcem na papír apod. Podle me naopak nejvetsi kandidat na vyhozeni je prave is_in, protoze je to nestrukturovana hromada cehosi. Navic v soucasnosti drtiva vetsina aplikaci spravne najde ze adresa lezi uvnitr boundary XYZ. Souhlas, je to nestrukturovaná hromada, ovšem to cosi nese užitečnou informaci. Jak už jsem psal, někdy jedno katastrální uzemí obsahuje více částí obce, každá část má vlastní číslování domů. Tedy v hranicích jednoho KÚ se čísla opakují. Nestrukturovaná data se mě také nelíbí. Ale existuje strukturovaná verze is_in, jak píšou na té stránce http://wiki.openstreetmap.org/wiki/Key:is_in (is_in:city, is_in:country, ...). Dál navrhuji seskupit adresy jedné ulice do relace, která ponese addr:street a is_in, aby se předešlo duplikaci. Adresní body by v tom případě měly jen addr:housenumber, addr:streetnumber a addr:conscriptionnumber. Otázkou je, jak by taková relace měla vypadat[2]. Toto je neprohledatelny, zadny stavajici nastroj s necim takovym nepocita, tudiz tu adresu nikdo nenajde. Jako bonus je to obtizne editovatelny. Nominatim používá relaci associatedStreet. http://wiki.openstreetmap.org/wiki/Nominatim/Development_overview#Building_Indexing Editace jsou samozřejmě obtížnější, nicméně mě stále láká strukturovanost této relace. Na druhou stranu, software na import asi psát nebudu, a kdyby ano, nemořil bych se s generováním relací. Takže to tu nechme jako dobrý nápad. Po stránce software na import bych tom neviděl velký problém (software na import průběžně připravuji). Větší starost mi dělá to, že vlastně nevím, co mám přesně udělat. Tedy jak má vypadat výsledek, co udělat se starými daty, podle čeho matchovat stará a nová data apod. Nemám dobrý přehled o významu všech tagů a vůbec konvencích a doporučení OSM a studovat WIKI se mi opravdu nechce (zabralo by mi to spoustu času). Proto bych rád, kdyby z diskuse vzešly nějaké závěry a mohl jsem to podle nich implementovat. Honza ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Formát zápisu adresních bodů (was Data RUIAN - výměnný formát)
Dne 27.6.2012 22:12, Jan Bilak napsal(a): Ahoj, Trochu sem se prohrab temi samply, a me by se libilo nevyrabet adresni body ale priradit adresy budovam, neb ta vazba v tech datech je. Bod bych vyrobil jen tam, kde budova neni (a je tam definovana adresa). Co se tyce ulic, tam to asi s jejich presnosti nebude zadna slava - predpokladam, ze kazdej kdo obkresloval rucne to udelal podrobnejsi. Ale lepsi nez dratem do oka. Adresní bod a budova ... to mě napadlo také (a někde se to v OSM i používá), ale vidím v tom trochu problémy. Zaprvé budova může mít více vchodů/adres. Jak by se jmenovaly tagy? addr:housenumber1, addr:housenumber2, addr:housenumber3 apod.? Nebo by se dělila budova na části? Ale jak? Nikdo nebude zkoumat vnitřní strukturu budovy - typicky ji vidíš zvenku a pár vchodů dovnitř. Občas se je zřejmé, ale nemusí být vždy. S tim se pocita, data v tech samplech jsou reseny jak sem si vsim tak, ze jedna adresa, je zvolena jako primarni a dalsi jsou k ni pripojeny jako sekundarni = na budovu se da ta primarni, ostatni se muzou hodit jako body. Samo, technicky spravne by bylo to na tu budovu nahazet podobne, jako je to ve zdroji, ale to se obavam v OSM netusim jak udelat, aby to zaroven fungovalo - idealni by bylo neco jako hodit tu budovu do relace a adresu urcit az v ty relaci, cimz by slo budove dat neomezeny mnozstvi relaci/adres, ale obavam se, ze tohle zadnej stavajici nastroj nepobere. Ostatne, podobne bych si doved predstavit i prilinkovani veci jako hospoda (+samo nazev, otviracka, ...), posilovna ... , cimz by se eliminoval vsemoznej tagovaci chaos (pokud na necem je 20+ tagu, tak uz je to peknej bordelak) a navrch by souvisejici data byly pekne pohromade. Du testnout, co neco takovyho udela ;D. Jinak, pokud predpokladam, ze vetsina km vypada vsude +- stejne, tak zaroven predpokladam, ze v drtivy vetsine pripadu budou klasicky panelaky zaneseny co vhod to samostatna budova (i kdyz to konstrukcne neni pravda). Budov s vice adresami nebude (IMO) nijak zavratny mnoztvi. Zadruhé adresní bod (pokud je vhodně umístěn) říká i polohu vchodu. Např. budova stojí mezi dvěma ulicemi a takto by nebylo zřejmé, odkud je vlastně vchod. Nerika, rozhodne ne pokud ho nebudes (kazdy jeden) rucne posunovat, adresni bod je unisten v centru budovy. Nehlede na to, ze na oznaceni vhodu jsou uplne jiny tagy (entrance). Zatřetí je otázka, zda je vhodné štěpit jeden druh informace do různých zápisů (někdy adresní bod, někde vlastnost budovy). Tak technicky je (IMO) spravnejsi, aby adresu mela budova (protoze ty patri CP/Cev/...). Ale pokud tam ta budova uz z nejakyho duvodu neni, tak to neznamena, ze nemuzeme nechat tu adresu najit (z duvodu navigace ... - to je jedinej duvod proc pripadne vyrabim ty body). Navic by bylo hned zrejmy, ze na dany adrese nestoji zadna budova = jde o proluku nebo jiny prazdny pozemek = hned se to lip hleda (specilene v nasem bordelstanu, kde je casto problem zjistit nazev ulice ve ktery clovek stoji). Nicméně informace u budovy může být také užitečná. Teoreticky lze najít všechny adresní body, které leží uvnitř polygonu budovy. Jak je rychlé/pracné, to záleží na tom, jak se data oindexují apod. Jak je to pracné v existujících nástrojích, to nevím. Předpokládám, že dotaz na objekty ležící v daném obdélníku je jeden z nejčastějších dotazů a data jsou tedy vhodně oindexována (r-tree, quad-tree nebo tak něco). Daleko rychlejsi ale je, vyrobit adresni body z budov, predpokladam, ze v ty databazi kde je to ulozeno to delaji prave takhle, protoze si nedovedu moc dobre predstavit, jak lezou na strechu kazdyho baraku a zamerujou jeho stred ... ;D, navic sem uz u par navigaci videl, ze pokud je hledana adresa primo budova, tak navigace tu budovu zvyrazni, coz je v hustci zastavbe fajn. + jako bonus, pokud by ta budova mela skutecne otagovany vchody, tak te to muze navigovat k tomu bliz a nemusis kvuli tomu trebas obchazet blok, protoze adresne to patri to ulice na druhy strane. Tohle je pekny, ale uvital bych SVG. obi:VlajkaTextList tvoří tři vodorovné pruhy, žlutý, modrý oboustranně zubatý a žluto-černě polcený, v poměru 1:2:1. Modrý má nahoře i dole po čtyřech zubech a pěti mezerách, vysokých jednu osminu šířky listu. V modrém pruhu žlutý kráčející lev s červenou zbrojí držící v předních tlapách bílou rybu hlavou nahoru a hřbetem k žerdi. Poměr šířky k délce listu je 2:3./obi:VlajkaText obi:ZnakTextV modrém štítě se zlatou cimbuřovou hlavou zlatý kráčející lev s červenou zbrojí držící v předních tlapách stříbrnou rybu, pod ním zlato-černě polcený štítek./obi:ZnakText Tohle tam není jen textově, ale i ve formě obrázků. Pravda - bitmap, nikoli vektorů. Ono asi ani všechno vektory nejde dobře vyjádřit nebo nejsou data ve vektorech dostupná. Přeci jen tohle vznikalo v době, kdy se ještě malovalo štětcem na papír apod. Podle me naopak nejvetsi kandidat na vyhozeni je prave is_in, protoze je to nestrukturovana hromada cehosi. Navic v soucasnosti
[Talk-cz] Formát zápisu adresních bodů (was Data RUIAN - výměnný formát)
Ahoj, Z mojí zkušenosti se formát adresního bodu liší podle použitého nástroje. Jsou tři (polo)automatické způsoby importu, a nakonec pak ruční zadání. On Tue 26-06-12 04:14:04, Jan Bilak wrote: jak vypadá ideální zápis adresního bodu v OSM XML? Koukal jsem se do snapshotu OSM dat ČR a zápisy nemají jednotný formát. Např.: node id=296674495 lat=48.9631350 lon=14.5119948 version=2 changeset=1965423 user=Radomír Černoch uid=51295 timestamp=2009-07-28T14:56:31Z tag k=addr:conscriptionnumber v=2030 / tag k=addr:housenumber v=2030/1 / tag k=addr:postcode v=37006 / tag k=addr:street v=U pramene / tag k=addr:streetnumber v=1 / tag k=source:addr v=uir_adr / tag k=uir_adr:ADRESA_KOD v=23398671 / /node Tohle je podle mě výsledek UIR-ADR importu. http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap#Adresn.C3.AD_body_-_MPSV.28UIR-ADR.29 node id=1496603658 lat=48.8736400 lon=14.6758775 version=1 changeset=9784174 user=Petr1868 uid=72020 timestamp=2011-11-09T19:54:47Z tag k=addr:conscriptionnumber v=13 / tag k=addr:country v=CZ / tag k=addr:housenumber v=13 / tag k=is_in v=Třebeč, Borovany, Jihočeský kraj, CZ / tag k=source:addr v=mvcr:adresa / tag k=source:loc v=cuzk:km / /node Tento záznam vytváří nástroje napsané Lukášem Kábrtem. http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR Pokud jsou v obci ulice, je přítomen i tag addr:street. node id=33705330 lat=49.7021197 lon=17.0731786 version=12 changeset=5435557 user=NE2 uid=207745 timestamp=2010-08-08T17:43:41Z tag k=addr:city v=Litovel / tag k=addr:conscriptionnumber v=678 / tag k=addr:country v=CZ / tag k=addr:housenumber v=678/1 / tag k=addr:postcode v=78401 / tag k=addr:street v=Mlýnská / tag k=addr:streetnumber v=1 / tag k=is_in v=Litovel, Olomoucký kraj, CZ / tag k=name v=Penzion U starého mlýna / tag k=source:addr v=mvcr:adresa / tag k=tourism v=hotel / tag k=url v=http://ustarehomlyna.cz; / /node Tohle je podle mě CzechAddress plugin pro JOSM napsaný Radomírem Černochem. http://wiki.openstreetmap.org/wiki/CS:JOSM/Plugins/CzechAddress Name a URL tagy byly zřejmě přidány ručně. node id=283050015 lat=50.1039117 lon=14.5115490 version=2 changeset=1984279 user=Radomír Černoch uid=51295 timestamp=2009-07-30T12:44:24Z tag k=addr:housenumber v=?/66 / tag k=addr:streetnumber v=66 / tag k=created_by v=Potlatch 0.10b / /node Tenhle byl asi vyroben ručně v Potlatchi, JOSM vytváří podobné. Chybí v nich is_in. Jak se vlastně jednoznačně/algoritmicky určí, co je a co není adresní bod? Všechny mají addr:housenumber, čehož bych se držel. Je vidět, že některé adresní body obsahují i doplňkové informace, které bude třeba zachovat. Tedy nějaké globální mazání a import adresních bodů nebude možný. Bude třeba matchovat staré a nové a podle toho se nějak zachovat. Rozhodně. A aby to nebylo jednoduché, různé zdroje mají různou přesnost. Polohově nejpřesnější jsou ruční editace, pak je import pomocí nástrojů Lukáše K., nejméně přesný je UIR-ADR. Co se týče doplňkových informací, informaci o ulici, čísle orientačním a hierarchii sídel obsahují body vytvořené ručně s pomocí CzechAddress a poloautomaticky nástroji Lukáše K. Informace o čísle, ulici a sídle pochází z databáze adres MVČR, umístění adresního bodu je pak výsledkem tvůrčí práce. V případech, kdy je na jednom katastrálním území více částí obcí, mohou někdy být tyto informace nesprávně. Záleží totiž, jak pečlivě byl import proveden. Libor ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Formát zápisu adresních bodů (was Data RUIAN - výměnný formát)
Ahoj, díky za rozbor, ale myslel jsem to tak, jaký zápis chceme v OSM ideálně mít. Tedy v jakém formátu připravovat import z RUIAN, jaké tagy tam dát pro nové adresní body, jaké tagy doplnit ke stávajícím, jaké existující tagy případně smazat nebo změnit (ostatní předpokládám zachovat). Tedy aby to všude jednotné (+ u některých bodů nějaké specifické tagy). Jak se má složit obsah tagu is_in (pokud tam má být), protože to je složenina různých údajů. Honza Dne 26. června 2012 13:58 Libor Pechacek lpecha...@gmx.com napsal(a): Ahoj, Z mojí zkušenosti se formát adresního bodu liší podle použitého nástroje. Jsou tři (polo)automatické způsoby importu, a nakonec pak ruční zadání. On Tue 26-06-12 04:14:04, Jan Bilak wrote: jak vypadá ideální zápis adresního bodu v OSM XML? Koukal jsem se do snapshotu OSM dat ČR a zápisy nemají jednotný formát. Např.: node id=296674495 lat=48.9631350 lon=14.5119948 version=2 changeset=1965423 user=Radomír Černoch uid=51295 timestamp=2009-07-28T14:56:31Z tag k=addr:conscriptionnumber v=2030 / tag k=addr:housenumber v=2030/1 / tag k=addr:postcode v=37006 / tag k=addr:street v=U pramene / tag k=addr:streetnumber v=1 / tag k=source:addr v=uir_adr / tag k=uir_adr:ADRESA_KOD v=23398671 / /node Tohle je podle mě výsledek UIR-ADR importu. http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap#Adresn.C3.AD_body_-_MPSV.28UIR-ADR.29 node id=1496603658 lat=48.8736400 lon=14.6758775 version=1 changeset=9784174 user=Petr1868 uid=72020 timestamp=2011-11-09T19:54:47Z tag k=addr:conscriptionnumber v=13 / tag k=addr:country v=CZ / tag k=addr:housenumber v=13 / tag k=is_in v=Třebeč, Borovany, Jihočeský kraj, CZ / tag k=source:addr v=mvcr:adresa / tag k=source:loc v=cuzk:km / /node Tento záznam vytváří nástroje napsané Lukášem Kábrtem. http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR Pokud jsou v obci ulice, je přítomen i tag addr:street. node id=33705330 lat=49.7021197 lon=17.0731786 version=12 changeset=5435557 user=NE2 uid=207745 timestamp=2010-08-08T17:43:41Z tag k=addr:city v=Litovel / tag k=addr:conscriptionnumber v=678 / tag k=addr:country v=CZ / tag k=addr:housenumber v=678/1 / tag k=addr:postcode v=78401 / tag k=addr:street v=Mlýnská / tag k=addr:streetnumber v=1 / tag k=is_in v=Litovel, Olomoucký kraj, CZ / tag k=name v=Penzion U starého mlýna / tag k=source:addr v=mvcr:adresa / tag k=tourism v=hotel / tag k=url v=http://ustarehomlyna.cz; / /node Tohle je podle mě CzechAddress plugin pro JOSM napsaný Radomírem Černochem. http://wiki.openstreetmap.org/wiki/CS:JOSM/Plugins/CzechAddress Name a URL tagy byly zřejmě přidány ručně. node id=283050015 lat=50.1039117 lon=14.5115490 version=2 changeset=1984279 user=Radomír Černoch uid=51295 timestamp=2009-07-30T12:44:24Z tag k=addr:housenumber v=?/66 / tag k=addr:streetnumber v=66 / tag k=created_by v=Potlatch 0.10b / /node Tenhle byl asi vyroben ručně v Potlatchi, JOSM vytváří podobné. Chybí v nich is_in. Jak se vlastně jednoznačně/algoritmicky určí, co je a co není adresní bod? Všechny mají addr:housenumber, čehož bych se držel. Je vidět, že některé adresní body obsahují i doplňkové informace, které bude třeba zachovat. Tedy nějaké globální mazání a import adresních bodů nebude možný. Bude třeba matchovat staré a nové a podle toho se nějak zachovat. Rozhodně. A aby to nebylo jednoduché, různé zdroje mají různou přesnost. Polohově nejpřesnější jsou ruční editace, pak je import pomocí nástrojů Lukáše K., nejméně přesný je UIR-ADR. Co se týče doplňkových informací, informaci o ulici, čísle orientačním a hierarchii sídel obsahují body vytvořené ručně s pomocí CzechAddress a poloautomaticky nástroji Lukáše K. Informace o čísle, ulici a sídle pochází z databáze adres MVČR, umístění adresního bodu je pak výsledkem tvůrčí práce. V případech, kdy je na jednom katastrálním území více částí obcí, mohou někdy být tyto informace nesprávně. Záleží totiž, jak pečlivě byl import proveden. Libor ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Formát zápisu adresních bodů (was Data RUIAN - výměnný formát)
Ahoj Honzo, Zabral jsem se do detailů a nějak zapomněl uzavřít návrhem. Jsem pro požití tagů addr:housenumber, addr:streetnumber, addr:conscriptionnumber, addr:street a is_in. Is_in proto, že často obsahuje informaci o městských částech, kterou z mapy nelze odvodit. Pokud někdo najde nějakou hypoalergenní[1] variantu k is_in, jsem pro. Dál navrhuji seskupit adresy jedné ulice do relace, která ponese addr:street a is_in, aby se předešlo duplikaci. Adresní body by v tom případě měly jen addr:housenumber, addr:streetnumber a addr:conscriptionnumber. Otázkou je, jak by taková relace měla vypadat[2]. Addr:postcode, addr:city a addr:country bych klidně zahodil, pokud neposlouží jako náhrada is_in. Libor [1] http://wiki.openstreetmap.org/wiki/Key:is_in#Controversy [2] v úvahu zřejmě připadá http://wiki.openstreetmap.org/wiki/Relations/Proposed/Collected_Ways, http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street nebo http://wiki.openstreetmap.org/wiki/Relation:associatedStreet On Tue 26-06-12 16:12:11, Jan Bilak wrote: Ahoj, díky za rozbor, ale myslel jsem to tak, jaký zápis chceme v OSM ideálně mít. Tedy v jakém formátu připravovat import z RUIAN, jaké tagy tam dát pro nové adresní body, jaké tagy doplnit ke stávajícím, jaké existující tagy případně smazat nebo změnit (ostatní předpokládám zachovat). Tedy aby to všude jednotné (+ u některých bodů nějaké specifické tagy). Jak se má složit obsah tagu is_in (pokud tam má být), protože to je složenina různých údajů. Honza Dne 26. června 2012 13:58 Libor Pechacek lpecha...@gmx.com napsal(a): Ahoj, Z mojí zkušenosti se formát adresního bodu liší podle použitého nástroje. Jsou tři (polo)automatické způsoby importu, a nakonec pak ruční zadání. On Tue 26-06-12 04:14:04, Jan Bilak wrote: jak vypadá ideální zápis adresního bodu v OSM XML? Koukal jsem se do snapshotu OSM dat ČR a zápisy nemají jednotný formát. Např.: node id=296674495 lat=48.9631350 lon=14.5119948 version=2 changeset=1965423 user=Radomír Černoch uid=51295 timestamp=2009-07-28T14:56:31Z tag k=addr:conscriptionnumber v=2030 / tag k=addr:housenumber v=2030/1 / tag k=addr:postcode v=37006 / tag k=addr:street v=U pramene / tag k=addr:streetnumber v=1 / tag k=source:addr v=uir_adr / tag k=uir_adr:ADRESA_KOD v=23398671 / /node Tohle je podle mě výsledek UIR-ADR importu. http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap#Adresn.C3.AD_body_-_MPSV.28UIR-ADR.29 node id=1496603658 lat=48.8736400 lon=14.6758775 version=1 changeset=9784174 user=Petr1868 uid=72020 timestamp=2011-11-09T19:54:47Z tag k=addr:conscriptionnumber v=13 / tag k=addr:country v=CZ / tag k=addr:housenumber v=13 / tag k=is_in v=Třebeč, Borovany, Jihočeský kraj, CZ / tag k=source:addr v=mvcr:adresa / tag k=source:loc v=cuzk:km / /node Tento záznam vytváří nástroje napsané Lukášem Kábrtem. http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR Pokud jsou v obci ulice, je přítomen i tag addr:street. node id=33705330 lat=49.7021197 lon=17.0731786 version=12 changeset=5435557 user=NE2 uid=207745 timestamp=2010-08-08T17:43:41Z tag k=addr:city v=Litovel / tag k=addr:conscriptionnumber v=678 / tag k=addr:country v=CZ / tag k=addr:housenumber v=678/1 / tag k=addr:postcode v=78401 / tag k=addr:street v=Mlýnská / tag k=addr:streetnumber v=1 / tag k=is_in v=Litovel, Olomoucký kraj, CZ / tag k=name v=Penzion U starého mlýna / tag k=source:addr v=mvcr:adresa / tag k=tourism v=hotel / tag k=url v=http://ustarehomlyna.cz; / /node Tohle je podle mě CzechAddress plugin pro JOSM napsaný Radomírem Černochem. http://wiki.openstreetmap.org/wiki/CS:JOSM/Plugins/CzechAddress Name a URL tagy byly zřejmě přidány ručně. node id=283050015 lat=50.1039117 lon=14.5115490 version=2 changeset=1984279 user=Radomír Černoch uid=51295 timestamp=2009-07-30T12:44:24Z tag k=addr:housenumber v=?/66 / tag k=addr:streetnumber v=66 / tag k=created_by v=Potlatch 0.10b / /node Tenhle byl asi vyroben ručně v Potlatchi, JOSM vytváří podobné. Chybí v nich is_in. Jak se vlastně jednoznačně/algoritmicky určí, co je a co není adresní bod? Všechny mají addr:housenumber, čehož bych se držel. Je vidět, že některé adresní body obsahují i doplňkové informace, které bude třeba zachovat. Tedy nějaké globální mazání a import adresních bodů nebude možný. Bude třeba matchovat staré a nové a podle toho se nějak zachovat. Rozhodně. A aby to
Re: [Talk-cz] Formát zápisu adresních bodů (was Data RUIAN - výměnný formát)
Některé atributy jsou důležité pro službu Nominatim http://wiki.openstreetmap.org/wiki/Nominatim/Development_overview MK - Original Message - From: Libor Pechacek [mailto:lpecha...@gmx.com] To: OpenStreetMap Czech Republic [mailto:talk-cz@openstreetmap.org] Sent: Tue, 26 Jun 2012 19:21:52 +0200 Subject: Re: [Talk-cz] Formát zápisu adresních bodů (was Data RUIAN - výměnný formát) Ahoj Honzo, Zabral jsem se do detailů a nějak zapomněl uzavřít návrhem. Jsem pro požití tagů addr:housenumber, addr:streetnumber, addr:conscriptionnumber, addr:street a is_in. Is_in proto, že často obsahuje informaci o městských částech, kterou z mapy nelze odvodit. Pokud někdo najde nějakou hypoalergenní[1] variantu k is_in, jsem pro. Dál navrhuji seskupit adresy jedné ulice do relace, která ponese addr:street a is_in, aby se předešlo duplikaci. Adresní body by v tom případě měly jen addr:housenumber, addr:streetnumber a addr:conscriptionnumber. Otázkou je, jak by taková relace měla vypadat[2]. Addr:postcode, addr:city a addr:country bych klidně zahodil, pokud neposlouží jako náhrada is_in. Libor [1] http://wiki.openstreetmap.org/wiki/Key:is_in#Controversy [2] v úvahu zřejmě připadá http://wiki.openstreetmap.org/wiki/Relations/Proposed/Collected_Ways, http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street nebo http://wiki.openstreetmap.org/wiki/Relation:associatedStreet On Tue 26-06-12 16:12:11, Jan Bilak wrote: Ahoj, díky za rozbor, ale myslel jsem to tak, jaký zápis chceme v OSM ideálně mít. Tedy v jakém formátu připravovat import z RUIAN, jaké tagy tam dát pro nové adresní body, jaké tagy doplnit ke stávajícím, jaké existující tagy případně smazat nebo změnit (ostatní předpokládám zachovat). Tedy aby to všude jednotné (+ u některých bodů nějaké specifické tagy). Jak se má složit obsah tagu is_in (pokud tam má být), protože to je složenina různých údajů. Honza Dne 26. června 2012 13:58 Libor Pechacek lpecha...@gmx.com napsal(a): Ahoj, Z mojí zkušenosti se formát adresního bodu liší podle použitého nástroje. Jsou tři (polo)automatické způsoby importu, a nakonec pak ruční zadání. On Tue 26-06-12 04:14:04, Jan Bilak wrote: jak vypadá ideální zápis adresního bodu v OSM XML? Koukal jsem se do snapshotu OSM dat ČR a zápisy nemají jednotný formát. Např.: node id=296674495 lat=48.9631350 lon=14.5119948 version=2 changeset=1965423 user=Radomír Černoch uid=51295 timestamp=2009-07-28T14:56:31Z tag k=addr:conscriptionnumber v=2030 / tag k=addr:housenumber v=2030/1 / tag k=addr:postcode v=37006 / tag k=addr:street v=U pramene / tag k=addr:streetnumber v=1 / tag k=source:addr v=uir_adr / tag k=uir_adr:ADRESA_KOD v=23398671 / /node Tohle je podle mě výsledek UIR-ADR importu. http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap#Adresn.C3.AD_body_-_MPSV.28UIR-ADR.29 node id=1496603658 lat=48.8736400 lon=14.6758775 version=1 changeset=9784174 user=Petr1868 uid=72020 timestamp=2011-11-09T19:54:47Z tag k=addr:conscriptionnumber v=13 / tag k=addr:country v=CZ / tag k=addr:housenumber v=13 / tag k=is_in v=Třebeč, Borovany, Jihočeský kraj, CZ / tag k=source:addr v=mvcr:adresa / tag k=source:loc v=cuzk:km / /node Tento záznam vytváří nástroje napsané Lukášem Kábrtem. http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR Pokud jsou v obci ulice, je přítomen i tag addr:street. node id=33705330 lat=49.7021197 lon=17.0731786 version=12 changeset=5435557 user=NE2 uid=207745 timestamp=2010-08-08T17:43:41Z tag k=addr:city v=Litovel / tag k=addr:conscriptionnumber v=678 / tag k=addr:country v=CZ / tag k=addr:housenumber v=678/1 / tag k=addr:postcode v=78401 / tag k=addr:street v=Mlýnská / tag k=addr:streetnumber v=1 / tag k=is_in v=Litovel, Olomoucký kraj, CZ / tag k=name v=Penzion U starého mlýna / tag k=source:addr v=mvcr:adresa / tag k=tourism v=hotel / tag k=url v=http://ustarehomlyna.cz; / /node Tohle je podle mě CzechAddress plugin pro JOSM napsaný Radomírem Černochem. http://wiki.openstreetmap.org/wiki/CS:JOSM/Plugins/CzechAddress Name a URL tagy byly zřejmě přidány ručně. node id=283050015 lat=50.1039117 lon=14.5115490 version=2 changeset=1984279 user=Radomír Černoch uid=51295 timestamp=2009-07-30T12:44:24Z tag k=addr:housenumber v=?/66 / tag k=addr:streetnumber v=66 / tag k=created_by v=Potlatch 0.10b / /node Tenhle byl asi
Re: [Talk-cz] Formát zápisu adresních bodů (was Data RUIAN - výměnný formát)
Ahoj, koukám, že tu budou i různé rozdíly mezi adresami z registru a z OSM, i když v OSM mají v tagu uveden kód adresy registru (tedy mělo by se jednat o stejnou adresu a asi import z UIR-ADR): Pár rozdílů z Prahy (pokud jsem neudělal chybu): http://jabi.aspone.cz/osm/temp/praha-rozdily.pdf Narážím konkrétně na rozdíly v číslech domu, nikoli v poloze. Poznámka: levá část je z registru, pravá část z OSM, 0 = neuvedeno, vzdálenost brát s velkou rezervou, celkově je výstup odporný... Otázka je, co je správně. Řešit to ručně? Bude toho mnohem více (i z Prahy). A jak to vůbec řešit? Honza ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
