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