Formát zápisu adresních bodů (was Data RUIAN - výměnný formát)

12 zpráv
Zpět na přehled

Formát zápisu adresních bodů (was Data RUIAN - výměnný formát)

12 zpráv JLJMH 5 účastníků 19 min čtení
  1. Libor Pechacek lpechacek na gmx.com #m900f92
    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í.
    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
  2. Jan Bilak jan.bilak.osm na gmail.com #m6ff5f7
    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
  3. Libor Pechacek lpechacek na gmx.com #m36ebaa
    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
  4. Martin Kokeš shr3k na typo3-hosting.com #mee6c46
    Některé atributy jsou důležité pro službu Nominatim http://wiki.openstreetmap.org/wiki/Nominatim/Development_overview MK
  5. Jan Bilak jan.bilak.osm na gmail.com #m3b2817
    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
  6. jzvc jzvc na tpfree.net #m599344
    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.
  7. jzvc jzvc na tpfree.net #mb9fec9
    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.
  8. Libor Pechacek lpechacek na gmx.com #m07e981
    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/1238981111 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
  9. jzvc jzvc na tpfree.net #m89201e
    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:VlajkaText>List 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:ZnakText>V 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
  10. Jan Bilak jan.bilak.osm na gmail.com #m88c6d2
    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:VlajkaText>List 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:ZnakText>V 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
  11. jzvc jzvc na tpfree.net #m34fc28
    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.
  12. hanoj ehanoj na gmail.com #mdf9d83
    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
Napsat odpověď e-mailem… Odpovědět

Otevře váš e-mailový klient. Odpovědi pak sledujte zde na webu.