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 _______________________________________________ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
