Dne 15.2.2012 23:52, LM_1 napsal(a): > Souhlasím s body 1-6 Petra Morávka a s Lukášem Kabrtem. > Pokud je oblast definována zákonem jako jdoucí potokem/břehem/středem > silnice/podél administrativní hranice tak by měla využívat tyto prvky > jako svou hranici i v OSM. > > To znamená ,že v relaci (multipolygonu) bude potok nebo část > multipolygonu waterway=riverbank. Pokud jde po silnici, tak bude > obsahovat silnici nebo jinou hranici. > > Naopak pokud jde po břehu/kraji silnice tak by rozhodně neměla být > nijak napojena na vlastní čáru toku nebo silnice. > > Důvodem je, že hranice bude následovat osud těchto prvků - při změně > toku potoka nebo trasy silnice se pohne i hranice oblasti. Platí to > samozřejmě i pro administrativní hranice, které jsou z definice > tvořeny potokem. > > Úplně jiná situace by byla, kdyby byla hranice definována souřadnicemi > a náhodou šla podél něčeho, potom není spojování na místě. > > > V závislosti na přesnosti dat by nebylo od věci uvažovat o použití > tvarů pro zpřesnění těch cest/potoků... > > > @jzvc: Pokud budeš chtít hranici využít tak máš informace o tom, co tu > hranici tvoří, to s tím dost silně souvisí (i když se to nemusí vždy > hodit). > > > Tagy vztahující se k oblasti by samozřejmě měly být jen na tom > multipolygonu, na čárách jen servisní (source...) a označení hranice > (silnice, plot) > > Protože jde o evropská data, budou pravděpodobně k dispozici ve více > zemích, bylo by proto vhodné se podívat jestli už někdo něco > neimportoval a pokud ano tak použít hotové nástroje a zachovat > konzistentní tagování. Pokud ne tak oznámit import i zahraničně, aby > to mohl udělat zahraniční importér stejně. > > Lukáš Matějka (LM_1) Problem je prave trebas to, pokud ty hranice nekdo bude casem chtit automaticky ze zdroje aktualizovat = v pripade pouziti silnice, potoka ... nerealne. Navic, to tak nelze ani importovat, musel bys to nasledne komplet rucne predelat, coz anuluje smysl importu. Nehlede na to, sem nejaky to chko zakresloval a klickuje to ruzne podel silnic, okraju lesa, hranic administrativnich celku ... a nekde to vede klido prostredkem pole ... Kde to vedlo soubezne s admin hranicema, tak tam sem je vyuzil, ale i to je dost sporny.
> > > 2012/2/15 jzvc <j...@tpfree.net>: >> Dne 15.2.2012 22:43, Lukas Kabrt napsal(a): >>>> 2) Sdílené hranice - souvisí s předchozím. Nemělo by vést více hranic >>>> přes stejné body. Lepší je rozsekat jeden megapolygon do více cest a >>>> přidat je do příslušných relací hranic - viz poměrně dlouhá zdvojená >>>> hranice mezi CHKO Železné hory a Žďárské vrchy. >>>> (Námět pro ty, co se nudí: sloučení s cestami administrativních hranic >>>> na úsecích, které jsou totožné). >>> Hranice CHKO a asi i dalších chráněných území (aspoň těch >>> velkoplošných) jsou definované nejen pomocí administrativních hranic, >>> ale i různými přírodními hranicemi - řeka, silnice apod. Průběh >>> hranice je určený ve vyhlášce o zřízení daného chráněného území - >>> příklad [1] >>> >>> IMHO nejčistší řešení by bylo chráněná do OSM přidat jako relace, kde >>> členové té relace by byli objekty (silnice, řeky, administrativní >>> hranice), tak jak jsou definované v příslušné vyhlášce. >> Tohle by prave bylo dost nestastny, protoze se to pak blbe modifikuje. >> Silnice muze byt trebas z ruznych duvodu posunuta, ale to (predpokladam) >> nezmeni hranici chko. Vubec nemluve o tom, ze je to jen virtualni >> hranice => melo by to mit svoji caru se kterou lze pripadne nezavisle >> hybat. Je to stejny jako administrativni hranice, tam se taky kvuli >> udrzbe zavrhlo pouziti trebas potoku a je to samostatna cara, ac hranice >> vede trebas v ose vodniho toku. Jenze jinde vede po brehu a s chko to >> bude podobny ... >> >> + samozrejme pokud budu chtit tu hranici nejak vyuzit, trebas pro nejaky >> overlay, tak vazne nechci aby se mi zaroven s tim postahovali trebas >> znacky natagovane k silnici. >> >> Zkratka nemixoval bych v relacich fyzicke a virtualni objekty mapy. >> >>> [1] old.ochranaprirody.cz/res/data/012/002287.pdf >>> >>> _______________________________________________ >>> 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 > _______________________________________________ > 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
