« zpět na výpis měsíce |

[Talk-cz] Par dotazu, na veci nenalezene na Wiki

Vlákno 19.5. - 26.5.2013, počet zpráv: 44


19.5.2013 10:02:10 (#1)
gravatar

Pavel Moravec

<pavel.moravec at email.cz>
11
Dobry den, zacal jsem s editaci OSM zejmena kvuli doplnovani chybejicich turistickych tras a pri te prilezitosti jsem se rozhodl trochu doplnit veci z okoli. Vetsinu veci jsem si nastudoval z EN wiki a ceskych wiki stranek, svoje chyby ze zacatku (jako spolehani se na tvar budovy z tracer pluginu) jsem odstranil, ale presto mam nekolik dotazu, na ktere jsem nenasel odpovedi. 1. V okoli je spousta krizeni vodnich toku a cest, ktere pak na validatoru keepright.at sviti jako cerveny blesk (nekterych z tech cest se tykaji i me editace, ale vesmes tam byly uz prede mnou). - Staci doplnit spolecny bod, nebo je treba doplnit i informace o mostku? Co kdyz nejsou znamy, nechat to tak? - Jak resit situaci, kdy tam neni most, ale betonova skruz pod cestou , kterou je potok kratky usek sveden - rozdelit potok na useky a uvest layer a odpovidajici tag? - Uvadet ford=yes i u pesich turistickych cest (skutecne je nutno prejit potok mokrou nohou nebo preskakat po kamenech)? 2. Ustalilo se v CZ komunite, jak znacit chatoviste? Tady v okoli uz bylo neco znacene pomoci landuse=recreational_area, ale narazil jsem v archivech tohoto talku na doporuceni pouziti residential? 3. Sportovni centrum, kde je zaroven kryty bazen, kuzelky, apod. Jak vse zaznacit najednou (ruzne tagy)? Nebo nechat jen to sportovni centrum? 4. Kresleni turistickych tras - je jasne, ze z Shocartu/KCT/... nelze kopirovat (a sam vim, ze casto ta jejich trasa v mape vede kus od te skutecne). Nicmene je mozne pouzit cizi verejne dostupny zaznam trasy v GPX, nebo pouze survey, local_knowledge, bing a vlastni GPS zaznamy? - Jak stara data je mozno pro trasy pouzit? Mam zaznamy v GPX nekolik let zpet, ale mezitim mohl byt potencialne nejaky usek posunut. - Co papirove mapy vydane krajem, z podpory EU apod., je mozne se inspirovat z nich (ale pouzit informace z rozcestniku, uz existujici cesty v mape resp. je nakreslit podle Bingu)? - Cisla tras - maji se uvadet i nove typy, co jsou na rozcestnicich (FM123a - pokud se to vubec tyka tras), nebo jen puvodni ctyrciselne kody? 5. Jak zaznacit zvonicku - man 'made=campanile' se mi nikde nerenderuje, je jeste nejaka dalsi alternativa? 6. Potreboval bych rozdelit obrovsky multipolygon lesa, abych mohl u casti vyznacit typ lesa. U hranic se Slovenskem, kde to delalo neplechu pri generovani map pro jednotlive zeme jsem to uz vyresil rucne, ale byla to strasna prace, zejmena spravne rozdeleni inner polygonu mezi nove multipolygony. Neexistuje nejaky rozumny nastroj (idealne do JOSM) pro deleni multipolygonu? 7. Cisla popisna - v me oblasti uz byla importovana, ale uplne nesedi na stredy budov. Maji se nechat na puvodni pozici kvuli konzistenci s ruznymi nastroji, ktere je pak kontroluji/aktualizuji informace, nebo je posunovat? 8. Pozemky v obcich (zahrady) - nekde jsou vzaty z katastru a zakresleny jinde jsou jen budovy. Je nejaky zazity standard, jestli je znacit nebo ne? Pavel Moravec

19.5.2013 11:01:09 (#2)
gravatar

Karel Volný

<kavol at seznam.cz>
558
zdravím, bez záruky, jak to vidím já: zobrazit citaci
> 1. V okoli je spousta krizeni vodnich toku a cest, ktere pak na > validatoru keepright.at sviti jako cerveny blesk (nekterych z tech cest > se tykaji i me editace, ale vesmes tam byly uz prede mnou). > - Staci doplnit spolecny bod, nebo je treba doplnit i informace o > mostku?
společný bod rozhodně nedoplňovat, pokud nejde o níže zmíněný brod ... tuším že již proběhla nějaká diskuse na téma falešných poplachů u keeprightu - resp. on má vpodstatě pravdu, to křížení by se mělo lišit hodnotou layer, jinak tam společný bod být "musí", ale to souvisí s následujícím: zobrazit citaci
> Co kdyz nejsou znamy, nechat to tak?
pokud nelze dát most s vyšším layerem anebo tu dále zmíněnou skruž s nižším, tak nechat - validátor je pomůcka, která může pomoci odhalit chyby, rozhodně není správné zanášet do mapy chyby faktické jen pro uspokojení validátoru obecně, někteří (já a pár dalších podivínů ;-)) zastávají názor, že lepší informace "hic sunt leones" nežli něco, co sice vypadá uvěřitelně, ale realitu stejně nepopisuje zobrazit citaci
> - Jak resit situaci, kdy tam neni most, ale betonova skruz pod cestou > , kterou je potok kratky usek sveden - rozdelit potok na useky a uvest > layer a odpovidajici tag?
řekl bych, že přesně tak zobrazit citaci
> - Uvadet ford=yes i u pesich turistickych cest (skutecne je nutno > prejit potok mokrou nohou nebo preskakat po kamenech)?
ano; resp. to přeskákání po kamench lze upřesnit: ford=stepping_stones zobrazit citaci
> 3. Sportovni centrum, kde je zaroven kryty bazen, kuzelky, apod. Jak vse > zaznacit najednou (ruzne tagy)? Nebo nechat jen to sportovni centrum?
to je na individuální posouzení ... pokud je známo co vše se tam provozuje a dá se předpokládat, že tato informace bude sedět s realitou, tak za sebe určitě preferuju maximální upřesnění zobrazit citaci
> 4. Kresleni turistickych tras - je jasne, ze z Shocartu/KCT/... nelze > kopirovat (a sam vim, ze casto ta jejich trasa v mape vede kus od te > skutecne). Nicmene je mozne pouzit cizi verejne dostupny zaznam trasy v > GPX,
to záleží na licenci toho konkrétního záznamu, co chceš použít - pokud se bavíme o uploadech tracklogů na OSM, tak tam to samozřejmě dovoluje zobrazit citaci
> - Jak stara data je mozno pro trasy pouzit? Mam zaznamy v GPX nekolik > let zpet, ale mezitim mohl byt potencialne nejaky usek posunut.
ač jsem výše říkal něco o lvech, tady konkrétně(*) se zase kloním k názoru, že lepší něco než nic - tedy po ověření, zda trasa vůbec ještě existuje moje zkušenost je taková, že při tom přeznačování se ledacos vrací do původních tras, už kolikrát jsme šli vandr s různejma vydáníma téže mapy, a stará seděla a nová byla v pytli ... (*) co se týče (ne)konzistence v názorech - rozdíl, proč se na to dívám jinak, je ten, že tady někdo tu realitu aspoň kdysi viděl, kdežto když se někde kříží potok z DIBAVODu a cesta z ŘSD, tak to máme dva nespolehlivé zdroje a nulovou osobní zkušenost, hm ... zobrazit citaci
> - Co papirove mapy vydane krajem, z podpory EU apod., je mozne se > inspirovat z nich (ale pouzit informace z rozcestniku, uz existujici > cesty v mape resp. je nakreslit podle Bingu)?
opět, záleží na konkrétní licenci ... je to poměrně složitá problematika, některé granty dokonce vyžadují otevřenost, většinou se to neřeší, pokud by dílo bylo vytvořeno přímo úřadem, tak je by default k dispozici, ale realita je taková, že úřad to někomu zadá a pak práva omezuje ten zpracovatel ... tenký led, fakt tenký led, nejlepší je pokusit se získat explicitní souhlas zobrazit citaci
> - Cisla tras - maji se uvadet i nove typy, co jsou na rozcestnicich > (FM123a - pokud se to vubec tyka tras), nebo jen puvodni ctyrciselne kody?
obecně se preferuje to, co je přímo na tom rozcestníku (ale pokud je k disposici i informace navíc, jak je ta trasa vedena v nějaké evidenci, tak to, že to na tom rozcestníku není, neznamená, že bychom si tu informaci jako doplňkovou nemohli uvést) zobrazit citaci
> 5. Jak zaznacit zvonicku - man 'made=campanile' se mi nikde nerenderuje, > je jeste nejaka dalsi alternativa?
pokud se nerenderuje něco, co by mělo (je to odsouhlasený způsob značení), pak je třeba obrátit se na správce příslušného rendereru, aby to přidal, nikoliv měnit značení zobrazit citaci
> 7. Cisla popisna - v me oblasti uz byla importovana, ale uplne nesedi na > stredy budov. Maji se nechat na puvodni pozici kvuli konzistenci s > ruznymi nastroji, ktere je pak kontroluji/aktualizuji informace, nebo je > posunovat?
nemůžu se vyjadřovat za ty "různé nástroje", ale AFAIK to sedět na středy budov ani na původní umístění nemusí - naopak, číslo by mělo označovat spíše příslušný vchod zobrazit citaci
> 8. Pozemky v obcich (zahrady) - nekde jsou vzaty z katastru a zakresleny > jinde jsou jen budovy. Je nejaky zazity standard, jestli je znacit nebo ne?
hm, jak se komu chce? K.

19.5.2013 11:38:42 (#3)
gravatar

Pavel Moravec

<pavel.moravec at email.cz>
11
Zdravim, dekuji za odpovedi, jen mozna upresneni: zobrazit citaci
>> - Cisla tras - maji se uvadet i nove typy, co jsou na rozcestnicich >> (FM123a - pokud se to vubec tyka tras), nebo jen puvodni ctyrciselne kody? > > obecně se preferuje to, co je přímo na tom rozcestníku (ale pokud je k > disposici i informace navíc, jak je ta trasa vedena v nějaké evidenci, tak to, > že to na tom rozcestníku není, neznamená, že bychom si tu informaci jako > doplňkovou nemohli uvést)
Tady mi slo hlavne o to, jestli to XXNNNz kde XX je kod okresu, NNN je cislo a z je nejaky podkod je skutecne cislo trasy nebo neco jineho. Protoze je to v miste, kde na tech tabulich bylo cislo trasy, ale podle rozcestniku u nadrazi kousek odsud mi to spise pripada jako kod tabulky na rozcestniku (a odvozeny z cisla rozcestniku?). Proto jsem si to chtel ujasnit. Pavel Moravec

19.5.2013 12:14:35 (#4)
gravatar

Pavel Machek

<pavel at ucw.cz>
1056 1226
Ahoj! zobrazit citaci
> 6. Potreboval bych rozdelit obrovsky multipolygon lesa, abych mohl u > casti vyznacit typ lesa. U hranic se Slovenskem, kde to delalo
V puvodnich uhulich datech typ lesa byl, jen jsme ho neimportovali :-(. Mozna by davalo smysl to importovat znovu, s typem lesa, a bez generalizace? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

19.5.2013 12:14:57 (#5)
gravatar

Václav Kubíček

<vase.k at centrum.cz>
50
Ahoj, jde o to, že KČT už na rozcestníky neuvádí čísla tras, ale tzv. číslo TIM (turistické informační místo) tj kód daného rozcestníku. Pokud objevíš číslo trasy, tak ho zapiš do relace trasy (např. ref=0401) a číslo TIM zapisuj do bodu rozcestníku (opět ref=FM123). To poslední písmenko "z" tam nepiš, co jsem si všiml, tak "m" je tabulka s názvem a "a,b,c,d..." jsou jednotlivé tabulky rozcestníků. Vašek zobrazit citaci
>Zdravim, >dekuji za odpovedi, jen mozna upresneni: > >>> - Cisla tras - maji se uvadet i nove typy, co jsou na rozcestnicich >>> (FM123a - pokud se to vubec tyka tras), nebo jen puvodni ctyrciselne kody? >> >> obecně se preferuje to, co je přímo na tom rozcestníku (ale pokud je k >> disposici i informace navíc, jak je ta trasa vedena v nějaké evidenci, tak to, >> že to na tom rozcestníku není, neznamená, že bychom si tu informaci jako >> doplňkovou nemohli uvést) > >Tady mi slo hlavne o to, jestli to XXNNNz kde XX je kod okresu, NNN je >cislo a z je nejaky podkod je skutecne cislo trasy nebo neco jineho. > >Protoze je to v miste, kde na tech tabulich bylo cislo trasy, ale podle >rozcestniku u nadrazi kousek odsud mi to spise pripada jako kod tabulky >na rozcestniku (a odvozeny z cisla rozcestniku?). Proto jsem si to chtel >ujasnit. > > Pavel Moravec > >_______________________________________________ >Talk-cz mailing list >Talk-cz na openstreetmap.org >http://lists.openstreetmap.org/listinfo/talk-cz >

19.5.2013 03:12:45 (#6)
gravatar

Karel Volný

<kavol at seznam.cz>
558
předně omlouvám se že jsem to ráno pomotal, samozřejmě že číslo trasy patří k relaci trasy a ne na rozcestník samotný, a zkusím ještě upřesnit upřesnění :-) Dne Ne 19. května 2013 12:14:57, Václav Kubíček napsal(a): zobrazit citaci
> jde o to, že KČT už na rozcestníky neuvádí čísla tras, ale tzv. číslo TIM > (turistické informační místo) tj kód daného rozcestníku. Pokud objevíš > číslo trasy, tak ho zapiš do relace trasy (např. ref=0401)
právě tato čísla bylo možno na starších rozcestnících dohledat např. zde: http://cs.wikipedia.org/wiki/Soubor:Rozdil_mezi_TZ_v_CR_a_SR.jpg 4545 je číslo trasy zobrazit citaci
> a číslo TIM zapisuj do bodu rozcestníku (opět ref=FM123). To poslední > písmenko "z" tam nepiš, co jsem si všiml, tak "m" je tabulka s názvem > a "a,b,c,d..." jsou jednotlivé tabulky rozcestníků. Vašek
tak naokraj, tyto identifikátory, stejně jako formální název daného rozcestníku, lze ověřit (nikoli opisovat!) zde: http://www.kct.cz/cms/vyhledavac-znacenych-tras K.

22.5.2013 09:45:50 (#7)
gravatar

jzvc

<jzvc at tpfree.net>
556
Dne 19.5.2013 12:14, Pavel Machek napsal(a): zobrazit citaci
> Ahoj! > >> 6. Potreboval bych rozdelit obrovsky multipolygon lesa, abych mohl u >> casti vyznacit typ lesa. U hranic se Slovenskem, kde to delalo > V puvodnich uhulich datech typ lesa byl, jen jsme ho neimportovali > :-(. Mozna by davalo smysl to importovat znovu, s typem lesa, a bez > generalizace? > > Pavel >
Probuh, jen to ne ... ty lesy jsou i tak neuveritelne nepresny ... ale je tam bambilion rucnich zmen, ktery bys tim naprosto vsechny zahodil.

22.5.2013 10:05:28 (#8)
gravatar

hanoj

<ehanoj at gmail.com>
718
zobrazit citaci
>>> 6. Potreboval bych rozdelit obrovsky multipolygon lesa, abych mohl u >>> casti vyznacit typ lesa. U hranic se Slovenskem, kde to delalo >> V puvodnich uhulich datech typ lesa byl, jen jsme ho neimportovali >> :-(. Mozna by davalo smysl to importovat znovu, s typem lesa, a bez >> generalizace?
*** spíš byla adekvátní ten tag jen doplnit, pokud však odpovídá skutečnosti, což někdo rozporoval. Technicky by se udělal geometrický průnik dvou vrstev lesů (OSM vs UHUL) a pak by se předal atribut "typu lesa" do OSM. zobrazit citaci
> Probuh, jen to ne ... ty lesy jsou i tak neuveritelne nepresny ... ale > je tam bambilion rucnich zmen, ktery bys tim naprosto vsechny zahodil.
*** hodnotu nehledejme v množství, ale v kvalitě editací, V principu by bylo možné les zpřesnit daty typu GMES, ten však nemá plné pokrytí. ha hanoj

22.5.2013 10:08:21 (#9)
gravatar

Lukas Kohout

<luko at luko.name>
22
Ahoj, při čtení diskuze o lesích bych měl otázku ohledně jejich hranic s jinými plochami. Plochy s různým využitím mají mít společné a nebo oddělené hranice? Například les sousedící s polem, uprostřed pole remízek, uprostřed lesa mýtina, nebo lom či zahrádkářská kolonie atd. Nyní je to v některých oblastech naházené přes sebe se spoustou překryvů a v moři čar se občas při editaci docela těžce orientuje. Je na to nějaká doporučená best practice? Díky. LuKo On 22.5.2013 9:45, jzvc wrote: zobrazit citaci
> Dne 19.5.2013 12:14, Pavel Machek napsal(a): >> Ahoj! >> >>> 6. Potreboval bych rozdelit obrovsky multipolygon lesa, abych mohl u >>> casti vyznacit typ lesa. U hranic se Slovenskem, kde to delalo >> V puvodnich uhulich datech typ lesa byl, jen jsme ho neimportovali >> :-(. Mozna by davalo smysl to importovat znovu, s typem lesa, a bez >> generalizace? >> >> Pavel >> > Probuh, jen to ne ... ty lesy jsou i tak neuveritelne nepresny ... ale > je tam bambilion rucnich zmen, ktery bys tim naprosto vsechny zahodil. > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

22.5.2013 10:17:36 (#10)
gravatar

LM_1

<flukas.robot+osm at gmail.com>
103
Někdo by mohl nesouhlasit, ale podle mě: na hranici mezi loukou a lesem jen jedna cesta (way) s tagem source, případně plotem nebo jinou fyzickou hranicí apod., která je členem dvou multipolygonů - jednoho pro les, jednoho pro louku, na kterých jsou všechny příslušné tagy. Více čar přes sebe (byť se stejnými body) obvykle komplikuje editaci. Lukáš Matějka (LM_1) Dne 22. května 2013 10:08 Lukas Kohout <luko na luko.name> napsal(a): zobrazit citaci
> Ahoj, > > při čtení diskuze o lesích bych měl otázku ohledně jejich hranic s > jinými plochami. Plochy s různým využitím mají mít společné a nebo oddělené > hranice? Například les sousedící s polem, uprostřed pole remízek, uprostřed > lesa mýtina, nebo lom či zahrádkářská kolonie atd. Nyní je to v některých > oblastech naházené přes sebe se spoustou překryvů a v moři čar se občas při > editaci docela těžce orientuje. Je na to nějaká doporučená best practice? > Díky. > > LuKo > > > > > > On 22.5.2013 9:45, jzvc wrote: > >> Dne 19.5.2013 12:14, Pavel Machek napsal(a): >> >>> Ahoj! >>> >>> 6. Potreboval bych rozdelit obrovsky multipolygon lesa, abych mohl u >>>> casti vyznacit typ lesa. U hranic se Slovenskem, kde to delalo >>>> >>> V puvodnich uhulich datech typ lesa byl, jen jsme ho neimportovali >>> :-(. Mozna by davalo smysl to importovat znovu, s typem lesa, a bez >>> generalizace? >>> >>> >>> Pavel >>> >>> Probuh, jen to ne ... ty lesy jsou i tak neuveritelne nepresny ... ale >> je tam bambilion rucnich zmen, ktery bys tim naprosto vsechny zahodil. >> >> ______________________________**_________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.**org/listinfo/talk-cz<http://lists.openstreetmap.org/listinfo/talk-cz> >> >> > > ______________________________**_________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.**org/listinfo/talk-cz<http://lists.openstreetmap.org/listinfo/talk-cz> >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20130522/2cd47638/attachment.html>

22.5.2013 12:49:12 (#11)
gravatar

jzvc

<jzvc at tpfree.net>
556
Dne 22.5.2013 10:17, LM_1 napsal(a): zobrazit citaci
> Někdo by mohl nesouhlasit, ale podle mě: na hranici mezi loukou a > lesem jen jedna cesta (way) s tagem source, případně plotem nebo jinou > fyzickou hranicí apod., která je členem dvou multipolygonů - jednoho > pro les, jednoho pro louku, na kterých jsou všechny příslušné tagy. > Více čar přes sebe (byť se stejnými body) obvykle komplikuje editaci. > Lukáš Matějka (LM_1) >
Potiz je, ze na to musis vyrabet relace a s relacema se ani pres veskerou snahu nepracuje zrovna nativne a pohodlne. Viz budovy, kdyz mas dve vedle sebe, tak mezi nima je nejspis jedna zed ne dve ... presto se budovy kresli tak, ze maji soubezne hranicni cesty. Stejne se pak kresli drtiva vetsina ploch, a do relaci se to dava spis vyjimecne - tam kde to ma nejaky zcela zasadni smysl nebo to jinak udelat nejde. To by se totiz editory musely chovat tak, ze z toho tu relaci vyrobi automaticky, aniz by do toho kreslic musel nejak hrabat ... a idealne aniz by to nekde videl. Navic by takovych automatismu musel abyt cela rada ... co treba, kdyz najdu na hranici nejakych dvou ploch nejakou dalsi, jinou plochu ... pokud to nejsou relace, tak proste ty dve cary odtahnu od sebe a vepisu tam to co tam je... kdyz to bude relace... je to sr..ni na pul dne. Plati (bohuzel) zcela obecne ... o vsech pripadech vyuziti relaci. Pridelal sem odbocku k silnici, puvodni tam roztrch, abych moh doplnit zakazy odboceni ... z zjistil, ze puvodni uz v nekolika odbocovacich relacich byla ... nekde jinde ...=> rucne sem je musel spravovat ... a to sem v tomhle pripade vedel, jak ta relace "datove" ma vypadat, protoze i JOSM to sice umi nastrojem vyrobit, ale to je tak vsechno. V tomhle pripade by editor mel zcela automaticky z ty relace vyhodit segmenty, ktere nejsou pripojeny k definovanemu krizeni. Je spousta relaci se slozitou strukturou, ktery se nijak rozumne rucne editovat nedaj, ale rozbit se daj velmi snadno libovolnym zasahem v okoli. Velmi vyjimecne se editor aspon zepta (napr pri otoceni smeru cesty a jednosmerce ...) => osobne se snazim relacim vyhybat, pokud to jen jde. zobrazit citaci
> > Dne 22. května 2013 10:08 Lukas Kohout <luko na luko.name > <mailto:luko na luko.name>> napsal(a): > > Ahoj, > > při čtení diskuze o lesích bych měl otázku ohledně jejich > hranic s jinými plochami. Plochy s různým využitím mají mít > společné a nebo oddělené hranice? Například les sousedící s polem, > uprostřed pole remízek, uprostřed lesa mýtina, nebo lom či > zahrádkářská kolonie atd. Nyní je to v některých oblastech > naházené přes sebe se spoustou překryvů a v moři čar se občas při > editaci docela těžce orientuje. Je na to nějaká doporučená best > practice? Díky. > > LuKo > > > > > > On 22.5.2013 9:45, jzvc wrote: > > Dne 19.5.2013 12:14, Pavel Machek napsal(a): > > Ahoj! > > 6. Potreboval bych rozdelit obrovsky multipolygon > lesa, abych mohl u > casti vyznacit typ lesa. U hranic se Slovenskem, kde > to delalo > > V puvodnich uhulich datech typ lesa byl, jen jsme ho > neimportovali > :-(. Mozna by davalo smysl to importovat znovu, s typem > lesa, a bez > generalizace? > > > Pavel > > Probuh, jen to ne ... ty lesy jsou i tak neuveritelne nepresny > ... ale > je tam bambilion rucnich zmen, ktery bys tim naprosto vsechny > zahodil. > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org <mailto:Talk-cz na openstreetmap.org> > http://lists.openstreetmap.org/listinfo/talk-cz > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org <mailto:Talk-cz na openstreetmap.org> > http://lists.openstreetmap.org/listinfo/talk-cz > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20130522/550b39bf/attachment.html>

22.5.2013 01:43:03 (#12)
gravatar

LM_1

<flukas.robot+osm at gmail.com>
103
Kromě toho, že ve skutečnosti existuje jen jedna hranice a proto není důvod aby jich v datech bylo víc: Dne 22. května 2013 12:49 jzvc <jzvc na tpfree.net> napsal(a): zobrazit citaci
> Dne 22.5.2013 10:17, LM_1 napsal(a): > > Někdo by mohl nesouhlasit, ale podle mě: na hranici mezi loukou a lesem > jen jedna cesta (way) s tagem source, případně plotem nebo jinou fyzickou > hranicí apod., která je členem dvou multipolygonů - jednoho pro les, > jednoho pro louku, na kterých jsou všechny příslušné tagy. Více čar přes > sebe (byť se stejnými body) obvykle komplikuje editaci. > Lukáš Matějka (LM_1) > > > Potiz je, ze na to musis vyrabet relace a s relacema se ani pres veskerou > snahu nepracuje zrovna nativne a pohodlne. Viz budovy, kdyz mas dve vedle > sebe, tak mezi nima je nejspis jedna zed ne dve ... presto se budovy kresli > tak, ze maji soubezne hranicni cesty. Stejne se pak kresli drtiva vetsina > ploch, a do relaci se to dava spis vyjimecne - tam kde to ma nejaky zcela > zasadni smysl nebo to jinak udelat nejde. >
U budov je to většinou jen pár segmentů, navíc obvykle jsou tam opravdu dvě stěny (kromě řadových garáží). To ale nic neznamená, kreslí se obrys budovy, ne konstrukční řešení. Ohledně komfortu práce s relacemi nesouhlasím, mě se s relací pracuje mnohem lépe než bez nich (JOSM + relation Toolbox) zobrazit citaci
> To by se totiz editory musely chovat tak, ze z toho tu relaci vyrobi > automaticky, aniz by do toho kreslic musel nejak hrabat ... a idealne aniz > by to nekde videl. Navic by takovych automatismu musel abyt cela rada ... > co treba, kdyz najdu na hranici nejakych dvou ploch nejakou dalsi, jinou > plochu ... pokud to nejsou relace, tak proste ty dve cary odtahnu od sebe a > vepisu tam to co tam je... kdyz to bude relace... je to sr..ni na pul dne. >
Odtáhnout dvě čáry od sebe je v připadě, že sdílejí uzly, náročnější než nakreslit novou čáru a dosadit ji jako člena relace - nebo se pletu? zobrazit citaci
> Plati (bohuzel) zcela obecne ... o vsech pripadech vyuziti relaci. > Pridelal sem odbocku k silnici, puvodni tam roztrch, abych moh doplnit > zakazy odboceni ... z zjistil, ze puvodni uz v nekolika odbocovacich > relacich byla ... nekde jinde ...=> rucne sem je musel spravovat ... a to > sem v tomhle pripade vedel, jak ta relace "datove" ma vypadat, protoze i > JOSM to sice umi nastrojem vyrobit, ale to je tak vsechno. V tomhle pripade > by editor mel zcela automaticky z ty relace vyhodit segmenty, ktere nejsou > pripojeny k definovanemu krizeni. Je spousta relaci se slozitou strukturou, > ktery se nijak rozumne rucne editovat nedaj, ale rozbit se daj velmi snadno > libovolnym zasahem v okoli. Velmi vyjimecne se editor aspon zepta (napr pri > otoceni smeru cesty a jednosmerce ...) > > => osobne se snazim relacim vyhybat, pokud to jen jde. > > > Dne 22. května 2013 10:08 Lukas Kohout <luko na luko.name> napsal(a): > >> Ahoj, >> >> při čtení diskuze o lesích bych měl otázku ohledně jejich hranic s >> jinými plochami. Plochy s různým využitím mají mít společné a nebo oddělené >> hranice? Například les sousedící s polem, uprostřed pole remízek, uprostřed >> lesa mýtina, nebo lom či zahrádkářská kolonie atd. Nyní je to v některých >> oblastech naházené přes sebe se spoustou překryvů a v moři čar se občas při >> editaci docela těžce orientuje. Je na to nějaká doporučená best practice? >> Díky. >> >> LuKo >> >> >> >> >> >> On 22.5.2013 9:45, jzvc wrote: >> >>> Dne 19.5.2013 12:14, Pavel Machek napsal(a): >>> >>>> Ahoj! >>>> >>>> 6. Potreboval bych rozdelit obrovsky multipolygon lesa, abych mohl u >>>>> casti vyznacit typ lesa. U hranic se Slovenskem, kde to delalo >>>>> >>>> V puvodnich uhulich datech typ lesa byl, jen jsme ho neimportovali >>>> :-(. Mozna by davalo smysl to importovat znovu, s typem lesa, a bez >>>> generalizace? >>>> >>>> >>>> Pavel >>>> >>>> Probuh, jen to ne ... ty lesy jsou i tak neuveritelne nepresny ... ale >>> je tam bambilion rucnich zmen, ktery bys tim naprosto vsechny zahodil. >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > > _______________________________________________ > Talk-cz mailing listTalk-cz na openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-cz > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20130522/c113c6a4/attachment.html>

22.5.2013 02:13:36 (#13)
gravatar

Dalibor Jelínek

<dalibor at dalibor.cz>
415 1552
Ahoj, kdyz jsem si precetl tuhle odpoved, tak me napadl dotaz. Kdyz je v OSM uz naimportovany les a ja lehce upravim jeho tvar, tak bych mel radsi smazat ten tag, ze je to import z UHUL? Nebo je to jedno, protoze uz se zadny novy import, ktery by zahodil me zmeny stejne nikdy delat nebude? Dalibor Mozna by davalo smysl to importovat znovu, s typem lesa, a bez generalizace? Pavel Probuh, jen to ne ... ty lesy jsou i tak neuveritelne nepresny ... ale je tam bambilion rucnich zmen, ktery bys tim naprosto vsechny zahodil. _______________________________________________ Talk-cz mailing list Talk-cz na openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz _______________________________________________ Talk-cz mailing list Talk-cz na openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20130522/135c6c57/attachment.html>

23.5.2013 08:11:24 (#14)
gravatar

hanoj

<ehanoj at gmail.com>
718
zobrazit citaci
> kdyz jsem si precetl tuhle odpoved, tak me napadl dotaz. > Kdyz je v OSM uz naimportovany les a ja lehce upravim > jeho tvar, tak bych mel radsi smazat ten tag, ze je to import z UHUL?
*** měl bys popsat všechny zdroje, které se na výsledném podobě lesa podíleli ha hanoj

23.5.2013 08:50:49 (#15)
gravatar

hanoj

<ehanoj at gmail.com>
718
zobrazit citaci
> Někdo by mohl nesouhlasit, ale podle mě: na hranici mezi loukou a lesem jen > jedna cesta (way) s tagem source, případně plotem nebo jinou fyzickou > hranicí apod., která je členem dvou multipolygonů - jednoho pro les, jednoho > pro louku, na kterých jsou všechny příslušné tagy. Více čar přes sebe (byť > se stejnými body) obvykle komplikuje editaci.
*** Já se také snažím vyhýbat multipolygonům. Datový model by měl být služka ne pán a multipolygon je nyní často pánem. Někdy je použití naopak vhodné, jako je dnešní administrativní členění územních celků. Je zajímavé, že dodnes, díky multipolygonům, nelze z OSM rozumně exportovat plochy, což považuji za velký handicap. Je zajímavé, že běžně užívané datové modely v GIS naše úsporné problémy neřeší, prostě každá plocha má nejen svou hranu na hranici, ale také své lomové body. Tedy ten luxus v OSM, že nody jsou jen jednou v běžných formátech GIS neznám. (Aby nedocházelo ke smyčkám a překryvům při editaci může fungovat nadstavba mezi uživatelem a modelem, která to neumožní.) Přesto formáty GIS zpravidla umožňují definovat polygonu exklávu nebo enklávu. hranice polygonů v GIS (ESRI Shapefile): a-----b-----c-----d g-----h-----i-----j hranice polygonů v OSM bez relací: a-----b-----c-----d a-----b-----c-----d hranice polygonů v OSM s relací: a-----b-----c-----d + rel1 +rel2 ha hanoj

23.5.2013 10:48:19 (#16)
gravatar

LM_1

<flukas.robot+osm at gmail.com>
103
Přiznám se, že jsem to nikdy nezkoušel, ale není ten problém s exportem ploch v tom, že je tolik způsobů jejich reprezentace? - uzavřená cesta s typickým tagam pro oblast - uzavřená plocha s typickým liniovým tagem a area=yes - multipolygon - ...? LM_1 Dne 23. května 2013 8:50 hanoj <ehanoj na gmail.com> napsal(a): zobrazit citaci
> > Někdo by mohl nesouhlasit, ale podle mě: na hranici mezi loukou a lesem > jen > > jedna cesta (way) s tagem source, případně plotem nebo jinou fyzickou > > hranicí apod., která je členem dvou multipolygonů - jednoho pro les, > jednoho > > pro louku, na kterých jsou všechny příslušné tagy. Více čar přes sebe > (byť > > se stejnými body) obvykle komplikuje editaci. > *** Já se také snažím vyhýbat multipolygonům. Datový model by měl být > služka ne pán a multipolygon je nyní často pánem. Někdy je použití > naopak vhodné, jako je dnešní administrativní členění územních celků. > Je zajímavé, že dodnes, díky multipolygonům, nelze z OSM rozumně > exportovat plochy, což považuji za velký handicap. > > Je zajímavé, že běžně užívané datové modely v GIS naše úsporné > problémy neřeší,
zobrazit citaci
> prostě každá plocha má nejen svou hranu na hranici, > ale také své lomové body.
Tomu nerozumím, ocenil bych vysvětlení. zobrazit citaci
> Tedy ten luxus v OSM, že nody jsou jen > jednou v běžných formátech GIS neznám. (Aby nedocházelo ke smyčkám a > překryvům při editaci může fungovat nadstavba mezi uživatelem a > modelem, která to neumožní.) Přesto formáty GIS zpravidla umožňují > definovat polygonu exklávu nebo enklávu. > > hranice polygonů v GIS (ESRI Shapefile): > a-----b-----c-----d > g-----h-----i-----j > > hranice polygonů v OSM bez relací: > a-----b-----c-----d > a-----b-----c-----d > > hranice polygonů v OSM s relací: > a-----b-----c-----d + rel1 +rel2 > > > ha > hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20130523/8e224e1c/attachment.html>

23.5.2013 02:07:06 (#17)
gravatar

jzvc

<jzvc at tpfree.net>
556
Dne 23.5.2013 10:48, LM_1 napsal(a): zobrazit citaci
> Přiznám se, že jsem to nikdy nezkoušel, ale není ten problém s > exportem ploch v tom, že je tolik způsobů jejich reprezentace? > - uzavřená cesta s typickým tagam pro oblast > - uzavřená plocha s typickým liniovým tagem a area=yes > - multipolygon > - ...? >
To spolu souvisi ;D, a je to zcela obecnej problem OSM, nejen problem ploch. Jen si bohuzel moc nedokazu predstavit zpusob, jak to vyresit. Tech problemu je samo vic ... trebas vazby virtualnich prvku na realny (hranice vs silnice, silnice vs jeji oznaceni ...). Vem si, ze mas klasickou dvouprodouvou dalnici ... vetsinou se to kresli jako dve silnice ... a vetsinou se to dava do relace ... A ted ... das oznaceni (ref=..D1...) na ty cesty nebo az do relace? => je to jak kde a jak kdy a je to cim dal horsi, cim vic ruznych prvku se v mape objevuje. A samo, nekdy reneder bere info z relace v potaz, nekdy ne ... pro priklad, mam tu budovu skoly, a vedle druhou budovu, ktera je jako moltipolygon. V prvnim pripade jsou tagy primo na ceste => renederuje se jako skola, ve druhym jsou na relaci => renederuje se jako obyc barak ... Potiz vidim v tom, ze jaksi neexistuje ani nejaky zakladni desatero co kam patri. zobrazit citaci
> LM_1 > > > Dne 23. května 2013 8:50 hanoj <ehanoj na gmail.com > <mailto:ehanoj na gmail.com>> napsal(a): > > > Někdo by mohl nesouhlasit, ale podle mě: na hranici mezi loukou > a lesem jen > > jedna cesta (way) s tagem source, případně plotem nebo jinou > fyzickou > > hranicí apod., která je členem dvou multipolygonů - jednoho pro > les, jednoho > > pro louku, na kterých jsou všechny příslušné tagy. Více čar přes > sebe (byť > > se stejnými body) obvykle komplikuje editaci. > *** Já se také snažím vyhýbat multipolygonům. Datový model by měl být > služka ne pán a multipolygon je nyní často pánem. Někdy je použití > naopak vhodné, jako je dnešní administrativní členění územních celků. > Je zajímavé, že dodnes, díky multipolygonům, nelze z OSM rozumně > exportovat plochy, což považuji za velký handicap. > > Je zajímavé, že běžně užívané datové modely v GIS naše úsporné > problémy neřeší, > > > > prostě každá plocha má nejen svou hranu na hranici, > ale také své lomové body. > > Tomu nerozumím, ocenil bych vysvětlení. > > > Tedy ten luxus v OSM, že nody jsou jen > jednou v běžných formátech GIS neznám. (Aby nedocházelo ke smyčkám a > překryvům při editaci může fungovat nadstavba mezi uživatelem a > modelem, která to neumožní.) Přesto formáty GIS zpravidla umožňují > definovat polygonu exklávu nebo enklávu. > > hranice polygonů v GIS (ESRI Shapefile): > a-----b-----c-----d > g-----h-----i-----j > > hranice polygonů v OSM bez relací: > a-----b-----c-----d > a-----b-----c-----d > > hranice polygonů v OSM s relací: > a-----b-----c-----d + rel1 +rel2 > > > ha > hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org <mailto:Talk-cz na openstreetmap.org> > http://lists.openstreetmap.org/listinfo/talk-cz > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20130523/d7de0630/attachment.html>

23.5.2013 02:51:46 (#18)
gravatar

LM_1

<flukas.robot+osm at gmail.com>
103
Zrovna v případě silnic/řek apod. základní pravidlo existuje - jeden objekt v realitě - jeden objekt v osm. Z toho by vyplývalo, že v osm by měl být jen jeden objekt s ref=D1 a to by nutně byla relace, proti kterým existuje značný (pro mě nepochopitelný) odpor. Stejně tak u školy bych tyto informace dával do relace - je to univerzálnější v případě, že škola má víc budov/hřišť/celý areál, zároveň funguje i pro jednodomkovou vesnickou školu. LM_1 Dne 23. května 2013 14:07 jzvc <jzvc na tpfree.net> napsal(a): zobrazit citaci
> Dne 23.5.2013 10:48, LM_1 napsal(a): > > Přiznám se, že jsem to nikdy nezkoušel, ale není ten problém s exportem > ploch v tom, že je tolik způsobů jejich reprezentace? > - uzavřená cesta s typickým tagam pro oblast > - uzavřená plocha s typickým liniovým tagem a area=yes > - multipolygon > - ...? > > > To spolu souvisi ;D, a je to zcela obecnej problem OSM, nejen problem > ploch. Jen si bohuzel moc nedokazu predstavit zpusob, jak to vyresit. Tech > problemu je samo vic ... trebas vazby virtualnich prvku na realny (hranice > vs silnice, silnice vs jeji oznaceni ...). Vem si, ze mas klasickou > dvouprodouvou dalnici ... vetsinou se to kresli jako dve silnice ... a > vetsinou se to dava do relace ... > > A ted ... das oznaceni (ref=..D1...) na ty cesty nebo az do relace? => je > to jak kde a jak kdy a je to cim dal horsi, cim vic ruznych prvku se v mape > objevuje. A samo, nekdy reneder bere info z relace v potaz, nekdy ne ... > pro priklad, mam tu budovu skoly, a vedle druhou budovu, ktera je jako > moltipolygon. V prvnim pripade jsou tagy primo na ceste => renederuje se > jako skola, ve druhym jsou na relaci => renederuje se jako obyc barak ... > > Potiz vidim v tom, ze jaksi neexistuje ani nejaky zakladni desatero co kam > patri. > > > LM_1 > > > Dne 23. května 2013 8:50 hanoj <ehanoj na gmail.com> napsal(a): > >> > Někdo by mohl nesouhlasit, ale podle mě: na hranici mezi loukou a lesem >> jen >> > jedna cesta (way) s tagem source, případně plotem nebo jinou fyzickou >> > hranicí apod., která je členem dvou multipolygonů - jednoho pro les, >> jednoho >> > pro louku, na kterých jsou všechny příslušné tagy. Více čar přes sebe >> (byť >> > se stejnými body) obvykle komplikuje editaci. >> *** Já se také snažím vyhýbat multipolygonům. Datový model by měl být >> služka ne pán a multipolygon je nyní často pánem. Někdy je použití >> naopak vhodné, jako je dnešní administrativní členění územních celků. >> Je zajímavé, že dodnes, díky multipolygonům, nelze z OSM rozumně >> exportovat plochy, což považuji za velký handicap. >> >> Je zajímavé, že běžně užívané datové modely v GIS naše úsporné >> problémy neřeší, > > > >> prostě každá plocha má nejen svou hranu na hranici, >> ale také své lomové body. > > Tomu nerozumím, ocenil bych vysvětlení. > > >> Tedy ten luxus v OSM, že nody jsou jen >> jednou v běžných formátech GIS neznám. (Aby nedocházelo ke smyčkám a >> překryvům při editaci může fungovat nadstavba mezi uživatelem a >> modelem, která to neumožní.) Přesto formáty GIS zpravidla umožňují >> definovat polygonu exklávu nebo enklávu. >> >> hranice polygonů v GIS (ESRI Shapefile): >> a-----b-----c-----d >> g-----h-----i-----j >> >> hranice polygonů v OSM bez relací: >> a-----b-----c-----d >> a-----b-----c-----d >> >> hranice polygonů v OSM s relací: >> a-----b-----c-----d + rel1 +rel2 >> >> >> ha >> hanoj >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > > _______________________________________________ > Talk-cz mailing listTalk-cz na openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-cz > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20130523/b07a48ef/attachment.html>

23.5.2013 03:04:49 (#19)
gravatar

hanoj

<ehanoj at gmail.com>
718
zobrazit citaci
> Přiznám se, že jsem to nikdy nezkoušel, ale není ten problém s exportem > ploch v tom, že je tolik způsobů jejich reprezentace? > -1 uzavřená cesta s typickým tagam pro oblast > -2 uzavřená plocha s typickým liniovým tagem a area=yes > -3 multipolygon > - ...?
*** ano, exportovat variantu -1 případně -2 není problém. Multipolygon už není jen o změně zápisu přes nějaké API ale o celkové přeformulování formy objektu. zobrazit citaci
>> Je zajímavé, že běžně užívané datové modely v GIS naše úsporné >> problémy neřeší, >> prostě každá plocha má nejen svou hranu na hranici, >> ale také své lomové body. > > Tomu nerozumím, ocenil bych vysvětlení.
*** viz srovnání níže hranice dvou polygonů v GIS (ESRI Shapefile): a-----b-----c-----d g-----h-----i-----j hranice dvou polygonů v OSM bez relací: a-----b-----c-----d a-----b-----c-----d hranice dvou polygonů v OSM s relací: a-----b-----c-----d + rel1 +rel2 ha hanoj

23.5.2013 03:24:01 (#20)
gravatar

Milan Vancura

<milan at ucw.cz>
25
On Thu 23-05-13 14:51:46, LM_1 wrote: zobrazit citaci
> Zrovna v případě silnic/řek apod. základní pravidlo existuje - jeden objekt > v realitě - jeden objekt v osm. Z toho by vyplývalo, že v osm by měl být > jen jeden objekt s ref=D1 a to by nutně byla relace, proti kterým existuje > značný (pro mě nepochopitelný) odpor. > Stejně tak u školy bych tyto informace dával do relace - je to > univerzálnější v případě, že škola má víc budov/hřišť/celý areál, zároveň > funguje i pro jednodomkovou vesnickou školu.
Problém je, že pak bys musel zavést pravidlo, že (téměř) všechno je až v relacích. Proč by škola měla být výjimkou? Navíc to dává už teď v mnoha jiných případech dobrý smysl. Např. ulice. Dnes jsou tak rozkouskované, mimo jiné kvůli (zase jiným) relacím, že u mnoha ulic už neexistuje jeden objekt "ulice", který by ji obsahoval celou. Pak z toho plynou různé problémy. Nejsnáz/okamžitě je to vidět třeba na popiscích v mapě, jak jsou často nelogicky a hustě v místech, kde by je člověk v mapě fakt nečekal a nechtěl. Např. na mostě či v tunelu. Proč tam jsou? Protože ten úsek (např. v tunelu) je samostatný objekt, a to se jménem. Ale to by bylo nových relací... A úplně nová pravidla pro editaci OSM. A asi sousta feature requestů na JOSM, protože aspoň mně teda přijde, že editovat relace (zkoušel jsem pražskou MHD) je za trest. Milan

23.5.2013 03:47:12 (#21)
gravatar

LM_1

<flukas.robot+osm at gmail.com>
103
Dne 23. května 2013 15:24 Milan Vancura <milan na ucw.cz> napsal(a): zobrazit citaci
> On Thu 23-05-13 14:51:46, LM_1 wrote: > > Zrovna v případě silnic/řek apod. základní pravidlo existuje - jeden > objekt > > v realitě - jeden objekt v osm. Z toho by vyplývalo, že v osm by měl být > > jen jeden objekt s ref=D1 a to by nutně byla relace, proti kterým > existuje > > značný (pro mě nepochopitelný) odpor. > > Stejně tak u školy bych tyto informace dával do relace - je to > > univerzálnější v případě, že škola má víc budov/hřišť/celý areál, zároveň > > funguje i pro jednodomkovou vesnickou školu. > > Problém je, že pak bys musel zavést pravidlo, že (téměř) všechno je až v > relacích. Proč by škola měla být výjimkou? Navíc to dává už teď v mnoha > jiných > případech dobrý smysl. >
Kdyby to bylo jen na mě tak bych ho zavedl. zobrazit citaci
> > Např. ulice. Dnes jsou tak rozkouskované, mimo jiné kvůli (zase jiným) > relacím, > že u mnoha ulic už neexistuje jeden objekt "ulice", který by ji obsahoval > celou. Pak z toho plynou různé problémy. Nejsnáz/okamžitě je to vidět > třeba na > popiscích v mapě, jak jsou často nelogicky a hustě v místech, kde by je > člověk > v mapě fakt nečekal a nechtěl. Např. na mostě či v tunelu. Proč tam jsou? > Protože ten úsek (např. v tunelu) je samostatný objekt, a to se jménem. >
Relace = přítel člověka zobrazit citaci
> > Ale to by bylo nových relací... A úplně nová pravidla pro editaci OSM. A > asi > sousta feature requestů na JOSM, protože aspoň mně teda přijde, že editovat > relace (zkoušel jsem pražskou MHD) je za trest. >
Používám toto http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Relation_Toolbox a relace jsou za odměnu. :-) zobrazit citaci
> > Milan > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20130523/3a214cdf/attachment.html>

23.5.2013 03:49:32 (#22)
gravatar

LM_1

<flukas.robot+osm at gmail.com>
103
@hanoj: zobrazit citaci
>>...každá plocha má nejen svou hranu na hranici, ale také své lomové body.
Má tento výrok ještě jiný význam, než že hranice mezi dvěma objekty není vždy rovná čára, ale někdy i lomená? Jestli ne, je všechno jasné. LM_1 Dne 23. května 2013 15:04 hanoj <ehanoj na gmail.com> napsal(a): zobrazit citaci
> > Přiznám se, že jsem to nikdy nezkoušel, ale není ten problém s exportem > > ploch v tom, že je tolik způsobů jejich reprezentace? > > -1 uzavřená cesta s typickým tagam pro oblast > > -2 uzavřená plocha s typickým liniovým tagem a area=yes > > -3 multipolygon > > - ...? > *** ano, exportovat variantu -1 případně -2 není problém. Multipolygon > už není jen o změně zápisu přes nějaké API ale o celkové > přeformulování formy objektu. > > >> Je zajímavé, že běžně užívané datové modely v GIS naše úsporné > >> problémy neřeší, > >> prostě každá plocha má nejen svou hranu na hranici, > >> ale také své lomové body. > > > > Tomu nerozumím, ocenil bych vysvětlení. > *** viz srovnání níže > > hranice dvou polygonů v GIS (ESRI Shapefile): > a-----b-----c-----d > g-----h-----i-----j > > hranice dvou polygonů v OSM bez relací: > a-----b-----c-----d > a-----b-----c-----d > > hranice dvou polygonů v OSM s relací: > a-----b-----c-----d + rel1 +rel2 > > ha > hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20130523/516ebd7d/attachment.html>

23.5.2013 05:02:12 (#23)
gravatar

hanoj

<ehanoj at gmail.com>
718
zobrazit citaci
>>>...každá plocha má nejen svou hranu na hranici, ale také své lomové body. > Má tento výrok ještě jiný význam, než že hranice mezi dvěma objekty není > vždy rovná čára, ale někdy i lomená? Jestli ne, je všechno jasné.
*** Nerozumím otázce ;) *** Dva sousedíci polygony mají společnou společnou hranici (tj. dotýkají se v úsečkách). Pak v datovém modelu: * v GIS má každý polygon své originální lomové body (respektivé své hrany) * v OSM má každý polygon svou hranu po společných bodech * v OSM s relací má každý polygon společnou hranu i body ha hanoj

23.5.2013 05:07:13 (#24)
gravatar

Milan Vancura

<milan at ucw.cz>
25
On Thu 23-05-13 17:02:12, hanoj wrote: zobrazit citaci
> >>>...každá plocha má nejen svou hranu na hranici, ale také své lomové body. > > Má tento výrok ještě jiný význam, než že hranice mezi dvěma objekty není > > vždy rovná čára, ale někdy i lomená? Jestli ne, je všechno jasné. > *** Nerozumím otázce ;) > *** Dva sousedíci polygony mají společnou společnou hranici (tj. > dotýkají se v úsečkách). Pak v datovém modelu: > * v GIS má každý polygon své originální lomové body (respektivé své hrany) > * v OSM má každý polygon svou hranu po společných bodech > * v OSM s relací má každý polygon společnou hranu i body
Jo, tohle jsem nepochopil, jak se to v praxi používá. Např. když kolem části lesa vede plot, můžu použít stejné body a "obtáhnout" část jeho hranice novou cestou barrier=fence nebo musím duplikovat body? Minimálně u budov mi přijde, že se body duplikují a faktu, že bod může být součástí více cest, se nevyužívá. Milan

23.5.2013 05:10:33 (#25)
gravatar

LM_1

<flukas.robot+osm at gmail.com>
103
Už je mi to jasné. :) Dne 23. května 2013 17:02 hanoj <ehanoj na gmail.com> napsal(a): zobrazit citaci
> >>>...každá plocha má nejen svou hranu na hranici, ale také své lomové > body. > > Má tento výrok ještě jiný význam, než že hranice mezi dvěma objekty není > > vždy rovná čára, ale někdy i lomená? Jestli ne, je všechno jasné. > *** Nerozumím otázce ;) > *** Dva sousedíci polygony mají společnou společnou hranici (tj. > dotýkají se v úsečkách). Pak v datovém modelu: > * v GIS má každý polygon své originální lomové body (respektivé své hrany) > * v OSM má každý polygon svou hranu po společných bodech > * v OSM s relací má každý polygon společnou hranu i body > > ha > hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20130523/cd307daf/attachment.html>

23.5.2013 08:31:59 (#26)
gravatar

LM_1

<flukas.robot+osm at gmail.com>
103
Body se neduplikují a více cest vedoucích jedním bodem se u průběžných hranic používá docela v hojné míře. V případě oploceného lesa bych nakreslil jen plot a použil ho pro multipolygon lesa v roli outer (stejně jako případnou sousedící louku) - o tom jestli to tak má být je podstatná část předchozí diskuse. LM_1 Dne 23. května 2013 17:07 Milan Vancura <milan na ucw.cz> napsal(a): zobrazit citaci
> On Thu 23-05-13 17:02:12, hanoj wrote: > > >>>...každá plocha má nejen svou hranu na hranici, ale také své lomové > body. > > > Má tento výrok ještě jiný význam, než že hranice mezi dvěma objekty > není > > > vždy rovná čára, ale někdy i lomená? Jestli ne, je všechno jasné. > > *** Nerozumím otázce ;) > > *** Dva sousedíci polygony mají společnou společnou hranici (tj. > > dotýkají se v úsečkách). Pak v datovém modelu: > > * v GIS má každý polygon své originální lomové body (respektivé své > hrany) > > * v OSM má každý polygon svou hranu po společných bodech > > * v OSM s relací má každý polygon společnou hranu i body > > Jo, tohle jsem nepochopil, jak se to v praxi používá. Např. když kolem > části > lesa vede plot, můžu použít stejné body a "obtáhnout" část jeho hranice > novou > cestou barrier=fence nebo musím duplikovat body? Minimálně u budov mi > přijde, > že se body duplikují a faktu, že bod může být součástí více cest, se > nevyužívá. > > Milan > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20130523/f0281c96/attachment.html>

24.5.2013 12:18:51 (#27)
gravatar

Milan Vancura

<milan at ucw.cz>
25
On Thu 23-05-13 20:31:59, LM_1 wrote: zobrazit citaci
> Body se neduplikují a více cest vedoucích jedním bodem se u průběžných > hranic používá docela v hojné míře. > V případě oploceného lesa bych nakreslil jen plot a použil ho pro > multipolygon lesa v roli outer (stejně jako případnou sousedící louku) - o > tom jestli to tak má být je podstatná část předchozí diskuse.
Teda nechci se hádat, ale tohle mám pocit nemůže technicky projít. Asi jsme si nerozuměli, klíčové bylo, že ten plot NEjde kolem celého lesa, čili zatímco hranice lesa je uzavřená křivka a--b--c--d--e--f--a, tak plot je např. c--d--e a jinde není pro jednoduchost vůbec nic (sousedícího). Podle mě relace typu multipolygon potřebuje uzavřené křivky, nebo ne? Takže s mmi dnešními znalostmi bych to řešil tak, že bych zavedl body a, b, c, d, e a f, pak vyrobil první cestu a--b--c--d--e--f--a a otagoval bych jí jako les a naposledy druhou cestu, neuzavřenou, c--d--e a otagoval bych ji jako plot. A tto je ta otázka, co mě zajímá: děláte to také tak? :-) Nebo se dokonce pletu a jdou na to nějak napasovat ty multipolygony? Milan

24.5.2013 07:11:57 (#28)
gravatar

LM_1

<flukas.robot+osm at gmail.com>
103
Multipolygon právě umožňuje udělat oblast z různých, rozdělených úseků. Já bych to udělal takto: první cesta: e--f--a--b--c (žádný tag kromě source) druhá cesta: c--d--e (plot, source) multipolygon obsahující obě cesty (les) LM Dne 24. května 2013 0:18 Milan Vancura <milan na ucw.cz> napsal(a): zobrazit citaci
> On Thu 23-05-13 20:31:59, LM_1 wrote: > > Body se neduplikují a více cest vedoucích jedním bodem se u průběžných > > hranic používá docela v hojné míře. > > V případě oploceného lesa bych nakreslil jen plot a použil ho pro > > multipolygon lesa v roli outer (stejně jako případnou sousedící louku) - > o > > tom jestli to tak má být je podstatná část předchozí diskuse. > > Teda nechci se hádat, ale tohle mám pocit nemůže technicky projít. Asi > jsme si > nerozuměli, klíčové bylo, že ten plot NEjde kolem celého lesa, čili zatímco > hranice lesa je uzavřená křivka a--b--c--d--e--f--a, tak plot je např. > c--d--e > a jinde není pro jednoduchost vůbec nic (sousedícího). Podle mě relace typu > multipolygon potřebuje uzavřené křivky, nebo ne? > > Takže s mmi dnešními znalostmi bych to řešil tak, že bych zavedl body a, > b, c, > d, e a f, pak vyrobil první cestu a--b--c--d--e--f--a a otagoval bych jí > jako > les a naposledy druhou cestu, neuzavřenou, c--d--e a otagoval bych ji jako > plot. A tto je ta otázka, co mě zajímá: děláte to také tak? :-) > Nebo se dokonce pletu a jdou na to nějak napasovat ty multipolygony? > > Milan > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20130524/041e0124/attachment.html>

24.5.2013 07:33:13 (#29)
gravatar

Pavel Moravec

<pavel.moravec at email.cz>
11
Zdravim, zobrazit citaci
> Teda nechci se hádat, ale tohle mám pocit nemůže technicky projít. Asi jsme si > nerozuměli, klíčové bylo, že ten plot NEjde kolem celého lesa, čili zatímco > hranice lesa je uzavřená křivka a--b--c--d--e--f--a, tak plot je např. c--d--e > a jinde není pro jednoduchost vůbec nic (sousedícího). Podle mě relace typu > multipolygon potřebuje uzavřené křivky, nebo ne?
Kupodivu nepotrebuje, jen je treba seradit useky cest za sebou tak, aby tu uzavrenou krivku tvorily (a velka cast rendereru si to umi seradit sama i pokud jsou tam se spravnou roli outer na preskacku). Ono by to ani jinak neslo kvuli omezeni maximalniho poctu bodu v 1 ceste, takze treba takova hranice CR by se nedala realizovat.

24.5.2013 09:15:09 (#30)
gravatar

Milan Vancura

<milan at ucw.cz>
25
On Fri 24-05-13 07:33:13, Pavel Moravec wrote: zobrazit citaci
> >multipolygon potřebuje uzavřené křivky, nebo ne? > Kupodivu nepotrebuje, jen je treba seradit useky cest za sebou tak, > aby tu uzavrenou krivku tvorily (a velka cast rendereru si to umi
On Fri 24-05-13 07:11:57, LM_1 wrote: zobrazit citaci
> Multipolygon právě umožňuje udělat oblast z různých, rozdělených úseků. Já > bych to udělal takto: > první cesta: e--f--a--b--c (žádný tag kromě source) > druhá cesta: c--d--e (plot, source) > multipolygon obsahující obě cesty (les)
Díky vám oběma, zase vím něco víc. Takže ta část relace pro trasu linky MHD, kde jsou cesty, je vlastně něco podobného (cesty seřazené za sebou). A teď ještě jakou to má výhodu oproti tomu znovupoužití bodů? Že je to mnohem univerzálnější princip? Milan

24.5.2013 10:41:12 (#31)
gravatar

jan lana

<lana.jan at gmail.com>
9
Dne 24. května 2013 9:15 Milan Vancura <milan na ucw.cz> napsal(a): zobrazit citaci
> On Fri 24-05-13 07:33:13, Pavel Moravec wrote: > > >multipolygon potřebuje uzavřené křivky, nebo ne? > > Kupodivu nepotrebuje, jen je treba seradit useky cest za sebou tak, > > aby tu uzavrenou krivku tvorily (a velka cast rendereru si to umi > > On Fri 24-05-13 07:11:57, LM_1 wrote: > > Multipolygon právě umožňuje udělat oblast z různých, rozdělených úseků. > Já > > bych to udělal takto: > > první cesta: e--f--a--b--c (žádný tag kromě source) > > druhá cesta: c--d--e (plot, source) > > multipolygon obsahující obě cesty (les) > > Díky vám oběma, zase vím něco víc. Takže ta část relace pro trasu linky > MHD, > kde jsou cesty, je vlastně něco podobného (cesty seřazené za sebou). > A teď ještě jakou to má výhodu oproti tomu znovupoužití bodů? Že je to > mnohem > univerzálnější princip?
kreslit s pomoci relaci je (mozna) pracnejsi, ale mnohem lepe se pak edituje - kdyz mam napriklad nakreslit les a pole vedle sebe a---b---c---d---e | Pole | Les | | f-------g | | h-------i Bez relaci to lze namalovat jako dve cesty C1: a-b-c-f-i-h-a (tag source,pole) C2: a-d-e-g-f-c (tag source, les) Kdyz to maluji jako relaci, nejdriv vyrobim tri cesty E1: c-b-a-h-i-f (tag source) E2: c-f (tag source) E3: c-d-e-g-f (tag source) (ve skutecnosit v JOSM namaluju C1, pak vyberu body c a f a dam split a pak namaluju E3, takze to jde stejne rychle) a pak udelate dva multipolygony M1: C1+C2 (tag pole) M2: C2+C3 (tag les) Vysledek je stejny. Ale kdyz treba chcete zpresnit hranici c--f (protoze to puvodne bylo treba moc hrube), tak ve variante s relacemi jen pridame par bodu do cesty E2': c-x-y-z-f a je hotovo. U varianty bez relaci to znamena ... no, vlastne nevim, asi pridat ty body do C1 a pak nejak pridat ty stejne body i do C2. Vychytavka JOSM je v tom, ze kdyz rozdelite cestu, tak automaticky upravi vsechny relace ktere tu cestu obsahuji, takze kdyz si pak treba vsimnu, ze v bode f je rybnicek, tak jen rozdelim E1 v bode i na E1a a E1b E3 v bode g, na E3a a E3b namaluju cestu E4: i-g (tag source) a vyrobim multipolygon M3: E1a+E3a+E4 (tag rybnik) (s temi vsemi pismenky a indexy to vypada slozite, ale v JOSM je to jen par kliku, zkuste si to). - Jenda ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20130524/9d3d36b2/attachment.html>

24.5.2013 11:08:48 (#32)
gravatar

Marián Kyral

<mkyral at email.cz>
2385 2735
---------- Původní zpráva ---------- Od: jan lana <lana.jan na gmail.com> Datum: 24. 5. 2013 Předmět: Re: [Talk-cz] Společné hranice ploch " Dne 24. května 2013 9:15 Milan Vancura <milan na ucw.cz(mailto:milan na ucw.cz)>  napsal(a): " On Fri 24-05-13 07:33:13, Pavel Moravec wrote: zobrazit citaci
> >multipolygon potřebuje uzavřené křivky, nebo ne? > Kupodivu nepotrebuje, jen je treba seradit useky cest za sebou tak, > aby tu uzavrenou krivku tvorily (a velka cast rendereru si to umi
On Fri 24-05-13 07:11:57, LM_1 wrote: zobrazit citaci
> Multipolygon právě umožňuje udělat oblast z různých, rozdělených úseků. Já > bych to udělal takto: > první cesta: e--f--a--b--c (žádný tag kromě source) > druhá cesta: c--d--e (plot, source) > multipolygon obsahující obě cesty (les)
Díky vám oběma, zase vím něco víc. Takže ta část relace pro trasu linky MHD, kde jsou cesty, je vlastně něco podobného (cesty seřazené za sebou). A teď ještě jakou to má výhodu oproti tomu znovupoužití bodů? Že je to mnohem univerzálnější princip?" kreslit s pomoci relaci je (mozna) pracnejsi, ale mnohem lepe se pak edituje - kdyz mam napriklad nakreslit les a pole vedle sebe   a---b---c---d---e   | Pole  | Les   |   |       f-------g   |       |   h-------i    Bez relaci to lze namalovat jako dve cesty C1: a-b-c-f-i-h-a (tag source,pole) C2: a-d-e-g-f-c (tag source, les) Kdyz to maluji jako relaci, nejdriv vyrobim tri cesty  E1: c-b-a-h-i-f (tag source) E2: c-f         (tag source) E3: c-d-e-g-f   (tag source) (ve skutecnosit v JOSM namaluju C1, pak vyberu body c a f a dam split a pak namaluju E3, takze to jde stejne rychle) a pak udelate dva multipolygony  M1: C1+C2 (tag pole) M2: C2+C3 (tag les) Vysledek je stejny. Ale kdyz treba chcete zpresnit hranici c--f (protoze to puvodne bylo treba moc hrube), tak ve variante s relacemi jen pridame par bodu do cesty E2': c-x-y-z-f a je hotovo. U varianty bez relaci to znamena ... no, vlastne nevim, asi pridat ty body do C1 a pak nejak pridat ty stejne body i do C2. " Normálně přidám body x - y - z a ty se automaticky přidají do cesty C1 i C2. Obě oblasti musí být uzavřeny. Takže i když mají společnou hranici, ve skutečnosti to jsou dvě plochy. OSM před   <way id='-976' action='modify' visible='true'>     <nd ref='-217' />     <nd ref='-975' />     <nd ref='-977' />     <nd ref='-979' />     <nd ref='-217' />     <tag k='landuse' v='farmland' />     <tag k='name' v='pole' />   </way>   <way id='-218' action='modify' visible='true'>     <nd ref='-214' />     <nd ref='-217' />     <nd ref='-979' />     <nd ref='-216' />     <nd ref='-215' />     <nd ref='-214' />     <tag k='landuse' v='forest' />     <tag k='name' v='les' />     <tag k='source' v='cuzk:km;bing' />   </way> a po přidání zpřesňujících bodů na společné hranici:   <way id='-976' action='modify' visible='true'>     <nd ref='-217' />     <nd ref='-975' />     <nd ref='-977' />     <nd ref='-979' />     <nd ref='-1089' />     <nd ref='-1086' />     <nd ref='-1083' />     <nd ref='-217' />     <tag k='landuse' v='farmland' />     <tag k='name' v='pole' />   </way>   <way id='-218' action='modify' visible='true'>     <nd ref='-214' />     <nd ref='-217' />     <nd ref='-1083' />     <nd ref='-1086' />     <nd ref='-1089' />     <nd ref='-979' />     <nd ref='-216' />     <nd ref='-215' />     <nd ref='-214' />     <tag k='landuse' v='forest' />     <tag k='name' v='les' />     <tag k='source' v='cuzk:km;bing' />   </way> Nebo jsem něco přehlédl? Marián ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20130524/61e25e13/attachment.html>

24.5.2013 11:18:45 (#33)
gravatar

hanoj

<ehanoj at gmail.com>
718
zobrazit citaci
> a---b---c---d---e > | Pole | Les | > | f-------g > | | > h-------i > > (s temi vsemi pismenky a indexy to vypada slozite, ale v JOSM je to jen par > kliku, zkuste si to).
*** Ono o té jednoduchosti multipolygonu už mluví to, že pro 2 plochy vytvoříš 5 objektů s různými tagy ;) Což, vytvořit to ještě možná jde, ale vysvětli to někomu nebo po někom zedituj, zkontroluj, oprav to... Popravdě mi Plugin Relation Toolbox mnoho štestí nepřinesl. Jsem rád, že zatím to nikoho nenapadlo dělat hromadně s buildings... Kde vidím multipolygony oprávněné a použitelně: * Vnitřní ostrovy polygonů jako multipolygony s inner/outer, OK. * Trasy (zpravidla myšlené) jako multipolygony s route, OK. * Seskupování autonomních objektů jako multipolygony s collection, OK. * Administrativní hranice jako multipolygony s inner/outer, OK (to vzniklo jednou a navždy importem a edituje to jen pár guru). ha hanoj

24.5.2013 12:47:27 (#34)
gravatar

jan lana

<lana.jan at gmail.com>
9
aha, diky za info - kdyz jsem to kdysi v JOSM zkousel tak to pridalo ten bod jen do jedne cesty, takze vznikla "dira". Ale ted to funguje jak rikate (neni ani nutne aby ty cesty byly uzavrene) JOSM prida ty nove body do obou. tudiz tenhle argument pada, autori JOSM podporuji obe varianty :) - jenda Dne 24. května 2013 11:08 Marián Kyral <mkyral na email.cz> napsal(a): zobrazit citaci
> > ---------- Původní zpráva ---------- > Od: jan lana <lana.jan na gmail.com> > Datum: 24. 5. 2013 > Předmět: Re: [Talk-cz] Společné hranice ploch > > Dne 24. května 2013 9:15 Milan Vancura <milan na ucw.cz> napsal(a): > > On Fri 24-05-13 07:33:13, Pavel Moravec wrote: > > >multipolygon potřebuje uzavřené křivky, nebo ne? > > Kupodivu nepotrebuje, jen je treba seradit useky cest za sebou tak, > > aby tu uzavrenou krivku tvorily (a velka cast rendereru si to umi > > On Fri 24-05-13 07:11:57, LM_1 wrote: > > Multipolygon právě umožňuje udělat oblast z různých, rozdělených úseků. > Já > > bych to udělal takto: > > první cesta: e--f--a--b--c (žádný tag kromě source) > > druhá cesta: c--d--e (plot, source) > > multipolygon obsahující obě cesty (les) > > Díky vám oběma, zase vím něco víc. Takže ta část relace pro trasu linky > MHD, > kde jsou cesty, je vlastně něco podobného (cesty seřazené za sebou). > A teď ještě jakou to má výhodu oproti tomu znovupoužití bodů? Že je to > mnohem > univerzálnější princip? > > > kreslit s pomoci relaci je (mozna) pracnejsi, ale mnohem lepe se pak > edituje - kdyz mam napriklad nakreslit les a pole vedle sebe > > > a---b---c---d---e > | Pole | Les | > | f-------g > | | > h-------i > > Bez relaci to lze namalovat jako dve cesty > > C1: a-b-c-f-i-h-a (tag source,pole) > C2: a-d-e-g-f-c (tag source, les) > > Kdyz to maluji jako relaci, nejdriv vyrobim tri cesty > > E1: c-b-a-h-i-f (tag source) > E2: c-f (tag source) > E3: c-d-e-g-f (tag source) > > (ve skutecnosit v JOSM namaluju C1, pak vyberu body c a f a dam split a > pak namaluju E3, takze to jde stejne rychle) > > a pak udelate dva multipolygony > > M1: C1+C2 (tag pole) > M2: C2+C3 (tag les) > > Vysledek je stejny. > > Ale kdyz treba chcete zpresnit hranici c--f (protoze to puvodne bylo treba > moc hrube), tak ve variante s relacemi jen pridame par bodu do cesty > > E2': c-x-y-z-f > > a je hotovo. U varianty bez relaci to znamena ... no, vlastne nevim, asi > pridat ty body do C1 a pak nejak pridat ty stejne body i do C2. > > > Normálně přidám body x - y - z a ty se automaticky přidají do cesty C1 i > C2. Obě oblasti musí být uzavřeny. Takže i když mají společnou hranici, ve > skutečnosti to jsou dvě plochy. > > > OSM před > > > <way id='-976' action='modify' visible='true'> > <nd ref='-217' /> > <nd ref='-975' /> > <nd ref='-977' /> > <nd ref='-979' /> > <nd ref='-217' /> > <tag k='landuse' v='farmland' /> > <tag k='name' v='pole' /> > </way> > <way id='-218' action='modify' visible='true'> > <nd ref='-214' /> > <nd ref='-217' /> > <nd ref='-979' /> > <nd ref='-216' /> > <nd ref='-215' /> > <nd ref='-214' /> > <tag k='landuse' v='forest' /> > <tag k='name' v='les' /> > <tag k='source' v='cuzk:km;bing' /> > </way> > > > a po přidání zpřesňujících bodů na společné hranici: > > > <way id='-976' action='modify' visible='true'> > <nd ref='-217' /> > <nd ref='-975' /> > <nd ref='-977' /> > <nd ref='-979' /> > <nd ref='-1089' /> > <nd ref='-1086' /> > <nd ref='-1083' /> > <nd ref='-217' /> > <tag k='landuse' v='farmland' /> > <tag k='name' v='pole' /> > </way> > <way id='-218' action='modify' visible='true'> > <nd ref='-214' /> > <nd ref='-217' /> > <nd ref='-1083' /> > <nd ref='-1086' /> > <nd ref='-1089' /> > <nd ref='-979' /> > <nd ref='-216' /> > <nd ref='-215' /> > <nd ref='-214' /> > <tag k='landuse' v='forest' /> > <tag k='name' v='les' /> > <tag k='source' v='cuzk:km;bing' /> > </way> > > > Nebo jsem něco přehlédl? > > > Marián > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20130524/cf0941a2/attachment.html>

24.5.2013 12:50:22 (#35)
gravatar

Zdeněk Pražák

<zprazak at seznam.cz>
800
No zde se řeší vytváření relací multi polygonů ale mne více trápí případ pro rozdělení polygonu na multipolygon s vniřními polygony, například když chci rozdelit polygon lesa na část tvořenou smíšeným lesem, část tvořenou jehličnatým lesem, ve kterém bude rybník, případně mýtina či louka. Pokud se bude jednat o malý objekt tak to v JOSM nakreslím snadno, horší je to v případě většího lesa již vytvořeného jako multipolygon - zde se mi mnohdy stane přestože používám editor relací v JOSM, že výsledek se nějak zamotá a musím jej smazat. Existuje nějaký jednoduchý postup na dělení velkých multipolygonů? Pražák Dne 24. května 2013 10:41 jan lana <lana.jan na gmail.com> napsal(a): zobrazit citaci
> Dne 24. května 2013 9:15 Milan Vancura <milan na ucw.cz> napsal(a): > >> On Fri 24-05-13 07:33:13, Pavel Moravec wrote: >> > >multipolygon potřebuje uzavřené křivky, nebo ne? >> > Kupodivu nepotrebuje, jen je treba seradit useky cest za sebou tak, >> > aby tu uzavrenou krivku tvorily (a velka cast rendereru si to umi >> >> On Fri 24-05-13 07:11:57, LM_1 wrote: >> > Multipolygon právě umožňuje udělat oblast z různých, rozdělených úseků. >> Já >> > bych to udělal takto: >> > první cesta: e--f--a--b--c (žádný tag kromě source) >> > druhá cesta: c--d--e (plot, source) >> > multipolygon obsahující obě cesty (les) >> >> Díky vám oběma, zase vím něco víc. Takže ta část relace pro trasu linky >> MHD, >> kde jsou cesty, je vlastně něco podobného (cesty seřazené za sebou). >> A teď ještě jakou to má výhodu oproti tomu znovupoužití bodů? Že je to >> mnohem >> univerzálnější princip? > > > kreslit s pomoci relaci je (mozna) pracnejsi, ale mnohem lepe se pak > edituje - kdyz mam napriklad nakreslit les a pole vedle sebe > > > a---b---c---d---e > | Pole | Les | > | f-------g > | | > h-------i > > Bez relaci to lze namalovat jako dve cesty > > C1: a-b-c-f-i-h-a (tag source,pole) > C2: a-d-e-g-f-c (tag source, les) > > Kdyz to maluji jako relaci, nejdriv vyrobim tri cesty > > E1: c-b-a-h-i-f (tag source) > E2: c-f (tag source) > E3: c-d-e-g-f (tag source) > > (ve skutecnosit v JOSM namaluju C1, pak vyberu body c a f a dam split a > pak namaluju E3, takze to jde stejne rychle) > > a pak udelate dva multipolygony > > M1: C1+C2 (tag pole) > M2: C2+C3 (tag les) > > Vysledek je stejny. > > Ale kdyz treba chcete zpresnit hranici c--f (protoze to puvodne bylo treba > moc hrube), tak ve variante s relacemi jen pridame par bodu do cesty > > E2': c-x-y-z-f > > a je hotovo. U varianty bez relaci to znamena ... no, vlastne nevim, asi > pridat ty body do C1 a pak nejak pridat ty stejne body i do C2. > > Vychytavka JOSM je v tom, ze kdyz rozdelite cestu, tak automaticky upravi > vsechny relace ktere tu cestu obsahuji, takze kdyz si pak treba vsimnu, ze > v bode f je rybnicek, tak jen rozdelim > > E1 v bode i na E1a a E1b > E3 v bode g, na E3a a E3b > > namaluju cestu > > E4: i-g (tag source) > > a vyrobim multipolygon > > M3: E1a+E3a+E4 (tag rybnik) > > (s temi vsemi pismenky a indexy to vypada slozite, ale v JOSM je to jen > par kliku, zkuste si to). > > - Jenda > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20130524/c5861674/attachment.html>

24.5.2013 01:26:54 (#36)
gravatar

LM_1

<flukas.robot+osm at gmail.com>
103
Dělení velkých multipolygonů (JOSM+relation toolbox): - Nakreslím hranici, v místech, kde končí (dotýká se hranic stávajícího multipolygonu) rozdělit cesty, pokud už nejsou - původní multipolygon je buď stejný, nebo se uvnitř něk rozdělily cesty ale pořád funguje jako předtím. - Vyberu si, jednu ze dvou nových oblastí - tu která zůstane v současném multipolygonu. Postupně klikám na úseky které nejsou hranicí této oblasti a na [-] - odstraním je z relace, stejně tak vyberu novou hranici a kliknu na [+] - přidám novou hranici. Ve vlastnostech původní relace nechám seřadit úseky za sebou - měl by se ukázat uzavřený ovál přes všechny úseky. - Vyberu všechny úseky / hranice nově vytvářeného multipolygonu a kliknu na [multipolygon] v toolboxu - vytvoří se nový multipolygon, na něj přidám tagy podle potřeby. Jestli to stále zní složitě tak zkusím udělat návod s obrázkama. LM Dne 24. května 2013 12:50 Zdeněk Pražák <zprazak na seznam.cz> napsal(a): zobrazit citaci
> No zde se řeší vytváření relací multi polygonů > ale mne více trápí případ pro rozdělení polygonu na multipolygon s > vniřními polygony, například když chci rozdelit polygon lesa na část > tvořenou smíšeným lesem, část tvořenou jehličnatým lesem, ve kterém bude > rybník, případně mýtina či louka. > Pokud se bude jednat o malý objekt tak to v JOSM nakreslím snadno, horší > je to v případě většího lesa již vytvořeného jako multipolygon - zde se mi > mnohdy stane přestože používám editor relací v JOSM, že výsledek se nějak > zamotá a musím jej smazat. > Existuje nějaký jednoduchý postup na dělení velkých multipolygonů? > Pražák > > > Dne 24. května 2013 10:41 jan lana <lana.jan na gmail.com> napsal(a): > >> Dne 24. května 2013 9:15 Milan Vancura <milan na ucw.cz> napsal(a): >> >>> On Fri 24-05-13 07:33:13, Pavel Moravec wrote: >>> > >multipolygon potřebuje uzavřené křivky, nebo ne? >>> > Kupodivu nepotrebuje, jen je treba seradit useky cest za sebou tak, >>> > aby tu uzavrenou krivku tvorily (a velka cast rendereru si to umi >>> >>> On Fri 24-05-13 07:11:57, LM_1 wrote: >>> > Multipolygon právě umožňuje udělat oblast z různých, rozdělených >>> úseků. Já >>> > bych to udělal takto: >>> > první cesta: e--f--a--b--c (žádný tag kromě source) >>> > druhá cesta: c--d--e (plot, source) >>> > multipolygon obsahující obě cesty (les) >>> >>> Díky vám oběma, zase vím něco víc. Takže ta část relace pro trasu linky >>> MHD, >>> kde jsou cesty, je vlastně něco podobného (cesty seřazené za sebou). >>> A teď ještě jakou to má výhodu oproti tomu znovupoužití bodů? Že je to >>> mnohem >>> univerzálnější princip? >> >> >> kreslit s pomoci relaci je (mozna) pracnejsi, ale mnohem lepe se pak >> edituje - kdyz mam napriklad nakreslit les a pole vedle sebe >> >> >> a---b---c---d---e >> | Pole | Les | >> | f-------g >> | | >> h-------i >> >> Bez relaci to lze namalovat jako dve cesty >> >> C1: a-b-c-f-i-h-a (tag source,pole) >> C2: a-d-e-g-f-c (tag source, les) >> >> Kdyz to maluji jako relaci, nejdriv vyrobim tri cesty >> >> E1: c-b-a-h-i-f (tag source) >> E2: c-f (tag source) >> E3: c-d-e-g-f (tag source) >> >> (ve skutecnosit v JOSM namaluju C1, pak vyberu body c a f a dam split a >> pak namaluju E3, takze to jde stejne rychle) >> >> a pak udelate dva multipolygony >> >> M1: C1+C2 (tag pole) >> M2: C2+C3 (tag les) >> >> Vysledek je stejny. >> >> Ale kdyz treba chcete zpresnit hranici c--f (protoze to puvodne bylo >> treba moc hrube), tak ve variante s relacemi jen pridame par bodu do cesty >> >> E2': c-x-y-z-f >> >> a je hotovo. U varianty bez relaci to znamena ... no, vlastne nevim, >> asi pridat ty body do C1 a pak nejak pridat ty stejne body i do C2. >> >> Vychytavka JOSM je v tom, ze kdyz rozdelite cestu, tak automaticky upravi >> vsechny relace ktere tu cestu obsahuji, takze kdyz si pak treba vsimnu, ze >> v bode f je rybnicek, tak jen rozdelim >> >> E1 v bode i na E1a a E1b >> E3 v bode g, na E3a a E3b >> >> namaluju cestu >> >> E4: i-g (tag source) >> >> a vyrobim multipolygon >> >> M3: E1a+E3a+E4 (tag rybnik) >> >> (s temi vsemi pismenky a indexy to vypada slozite, ale v JOSM je to jen >> par kliku, zkuste si to). >> >> - Jenda >> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20130524/8d3d6cf5/attachment.html>

24.5.2013 03:42:04 (#37)
gravatar

Pavel Machek

<pavel at ucw.cz>
1056 1226
Ahoj! zobrazit citaci
> > Zrovna v případě silnic/řek apod. základní pravidlo existuje - jeden objekt > > v realitě - jeden objekt v osm. Z toho by vyplývalo, že v osm by měl být > > jen jeden objekt s ref=D1 a to by nutně byla relace, proti kterým existuje > > značný (pro mě nepochopitelný) odpor. > > Stejně tak u školy bych tyto informace dával do relace - je to > > univerzálnější v případě, že škola má víc budov/hřišť/celý areál, zároveň > > funguje i pro jednodomkovou vesnickou školu. > > Problém je, že pak bys musel zavést pravidlo, že (téměř) všechno je až v > relacích. Proč by škola měla být výjimkou? Navíc to dává už teď v mnoha jiných > případech dobrý smysl. > > Např. ulice. Dnes jsou tak rozkouskované, mimo jiné kvůli (zase jiným) relacím, > že u mnoha ulic už neexistuje jeden objekt "ulice", který by ji obsahoval > celou. Pak z toho plynou různé problémy. Nejsnáz/okamžitě je to vidět třeba na > popiscích v mapě, jak jsou často nelogicky a hustě v místech, kde by je člověk > v mapě fakt nečekal a nechtěl. Např. na mostě či v tunelu. Proč tam jsou? > Protože ten úsek (např. v tunelu) je samostatný objekt, a to se > jménem.
zobrazit citaci
> Ale to by bylo nových relací... A úplně nová pravidla pro editaci OSM. A asi > sousta feature requestů na JOSM, protože aspoň mně teda přijde, že editovat > relace (zkoušel jsem pražskou MHD) je za trest.
Ale tady jsou ty nove relace asi na miste :-(. A taky chytrejsi renderer, ktery si porovna jmeno, a nebude psat 2x stejne.... -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

24.5.2013 03:55:36 (#38)
gravatar

Zdeněk Pražák

<zprazak at seznam.cz>
800
jestli bych mohl poprosit o obrázkový návod pro počítačové negramoty Děkuji Dne 24. května 2013 13:26 LM_1 <flukas.robot+osm na gmail.com> napsal(a): zobrazit citaci
> Dělení velkých multipolygonů (JOSM+relation toolbox): > - Nakreslím hranici, v místech, kde končí (dotýká se hranic stávajícího > multipolygonu) rozdělit cesty, pokud už nejsou - původní multipolygon je > buď stejný, nebo se uvnitř něk rozdělily cesty ale pořád funguje jako > předtím. > - Vyberu si, jednu ze dvou nových oblastí - tu která zůstane v současném > multipolygonu. > Postupně klikám na úseky které nejsou hranicí této oblasti a na [-] - > odstraním je z relace, stejně tak vyberu novou hranici a kliknu na [+] - > přidám novou hranici. Ve vlastnostech původní relace nechám seřadit úseky > za sebou - měl by se ukázat uzavřený ovál přes všechny úseky. > - Vyberu všechny úseky / hranice nově vytvářeného multipolygonu a kliknu > na [multipolygon] v toolboxu - vytvoří se nový multipolygon, na něj přidám > tagy podle potřeby. > > Jestli to stále zní složitě tak zkusím udělat návod s obrázkama. > LM > > > Dne 24. května 2013 12:50 Zdeněk Pražák <zprazak na seznam.cz> napsal(a): > >> No zde se řeší vytváření relací multi polygonů >> ale mne více trápí případ pro rozdělení polygonu na multipolygon s >> vniřními polygony, například když chci rozdelit polygon lesa na část >> tvořenou smíšeným lesem, část tvořenou jehličnatým lesem, ve kterém bude >> rybník, případně mýtina či louka. >> Pokud se bude jednat o malý objekt tak to v JOSM nakreslím snadno, horší >> je to v případě většího lesa již vytvořeného jako multipolygon - zde se mi >> mnohdy stane přestože používám editor relací v JOSM, že výsledek se nějak >> zamotá a musím jej smazat. >> Existuje nějaký jednoduchý postup na dělení velkých multipolygonů? >> Pražák >> >> >> Dne 24. května 2013 10:41 jan lana <lana.jan na gmail.com> napsal(a): >> >>> Dne 24. května 2013 9:15 Milan Vancura <milan na ucw.cz> napsal(a): >>> >>>> On Fri 24-05-13 07:33:13, Pavel Moravec wrote: >>>> > >multipolygon potřebuje uzavřené křivky, nebo ne? >>>> > Kupodivu nepotrebuje, jen je treba seradit useky cest za sebou tak, >>>> > aby tu uzavrenou krivku tvorily (a velka cast rendereru si to umi >>>> >>>> On Fri 24-05-13 07:11:57, LM_1 wrote: >>>> > Multipolygon právě umožňuje udělat oblast z různých, rozdělených >>>> úseků. Já >>>> > bych to udělal takto: >>>> > první cesta: e--f--a--b--c (žádný tag kromě source) >>>> > druhá cesta: c--d--e (plot, source) >>>> > multipolygon obsahující obě cesty (les) >>>> >>>> Díky vám oběma, zase vím něco víc. Takže ta část relace pro trasu linky >>>> MHD, >>>> kde jsou cesty, je vlastně něco podobného (cesty seřazené za sebou). >>>> A teď ještě jakou to má výhodu oproti tomu znovupoužití bodů? Že je to >>>> mnohem >>>> univerzálnější princip? >>> >>> >>> kreslit s pomoci relaci je (mozna) pracnejsi, ale mnohem lepe se pak >>> edituje - kdyz mam napriklad nakreslit les a pole vedle sebe >>> >>> >>> a---b---c---d---e >>> | Pole | Les | >>> | f-------g >>> | | >>> h-------i >>> >>> Bez relaci to lze namalovat jako dve cesty >>> >>> C1: a-b-c-f-i-h-a (tag source,pole) >>> C2: a-d-e-g-f-c (tag source, les) >>> >>> Kdyz to maluji jako relaci, nejdriv vyrobim tri cesty >>> >>> E1: c-b-a-h-i-f (tag source) >>> E2: c-f (tag source) >>> E3: c-d-e-g-f (tag source) >>> >>> (ve skutecnosit v JOSM namaluju C1, pak vyberu body c a f a dam split a >>> pak namaluju E3, takze to jde stejne rychle) >>> >>> a pak udelate dva multipolygony >>> >>> M1: C1+C2 (tag pole) >>> M2: C2+C3 (tag les) >>> >>> Vysledek je stejny. >>> >>> Ale kdyz treba chcete zpresnit hranici c--f (protoze to puvodne bylo >>> treba moc hrube), tak ve variante s relacemi jen pridame par bodu do cesty >>> >>> E2': c-x-y-z-f >>> >>> a je hotovo. U varianty bez relaci to znamena ... no, vlastne nevim, >>> asi pridat ty body do C1 a pak nejak pridat ty stejne body i do C2. >>> >>> Vychytavka JOSM je v tom, ze kdyz rozdelite cestu, tak automaticky >>> upravi vsechny relace ktere tu cestu obsahuji, takze kdyz si pak treba >>> vsimnu, ze v bode f je rybnicek, tak jen rozdelim >>> >>> E1 v bode i na E1a a E1b >>> E3 v bode g, na E3a a E3b >>> >>> namaluju cestu >>> >>> E4: i-g (tag source) >>> >>> a vyrobim multipolygon >>> >>> M3: E1a+E3a+E4 (tag rybnik) >>> >>> (s temi vsemi pismenky a indexy to vypada slozite, ale v JOSM je to jen >>> par kliku, zkuste si to). >>> >>> - Jenda >>> >>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20130524/e5425a61/attachment.html>

24.5.2013 04:08:32 (#39)
gravatar

jan lana

<lana.jan at gmail.com>
9
Dne 24. května 2013 11:18 hanoj <ehanoj na gmail.com> napsal(a): zobrazit citaci
> > a---b---c---d---e > > | Pole | Les | > > | f-------g > > | | > > h-------i > > > > (s temi vsemi pismenky a indexy to vypada slozite, ale v JOSM je to jen > par > > kliku, zkuste si to). > *** Ono o té jednoduchosti multipolygonu už mluví to, že pro 2 plochy > vytvoříš 5 objektů s různými tagy ;) Což, vytvořit to ještě možná jde, > ale vysvětli to někomu nebo po někom zedituj, zkontroluj, oprav to... > Popravdě mi Plugin Relation Toolbox mnoho štestí nepřinesl. Jsem rád, > že zatím to nikoho nenapadlo dělat hromadně s buildings... >
on ten pomer zacne byt vyrovnanejsi kdyz je tech sousedicich ploch vic (vesnice, kolem pole a lesy ...) nebo po hranach vedou zminovane ploty, cesty apod. A jak se nam mapa zaplnuje, je takovych mist vic a vic ... Vysvetlovani nevim, princip "nejdriv si to nacrtni a pak to teprve vybarvi" mi prijde celkem pochopitelny, ale jasne ze bodel se da vyrobit ve vsem. Relation Toolbox neznam, podivam se co to umi. Kde vidím multipolygony oprávněné a použitelně: zobrazit citaci
> * Vnitřní ostrovy polygonů jako multipolygony s inner/outer, OK. > * Trasy (zpravidla myšlené) jako multipolygony s route, OK. > * Seskupování autonomních objektů jako multipolygony s collection, OK. > * Administrativní hranice jako multipolygony s inner/outer, OK (to > vzniklo jednou a navždy importem a edituje to jen pár guru)
pouzitelne jsou i jinde (viz tento diskutovany priklad), jestli opravnene ...ani jeden model bych nezatracoval, vzajemne si neprekazi a uvidime za par let jak se to vyvine ... Me osobne se relace libi vic - trojvrstvy model: body, z nich cesty a z nich relace (objekty) mi prijde elegantni - automaticky prevod relace -> sdilene body je jednoduchy, opacny smer ne - kdyz jsou hranice dlouhe, data zaberou min mista - jenda ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20130524/e5a0afea/attachment.html>

24.5.2013 10:29:04 (#40)
gravatar

jzvc

<jzvc at tpfree.net>
556
Dne 23.5.2013 15:24, Milan Vancura napsal(a): zobrazit citaci
> On Thu 23-05-13 14:51:46, LM_1 wrote: >> Zrovna v případě silnic/řek apod. základní pravidlo existuje - jeden objekt >> v realitě - jeden objekt v osm. Z toho by vyplývalo, že v osm by měl být >> jen jeden objekt s ref=D1 a to by nutně byla relace, proti kterým existuje >> značný (pro mě nepochopitelný) odpor. >> Stejně tak u školy bych tyto informace dával do relace - je to >> univerzálnější v případě, že škola má víc budov/hřišť/celý areál, zároveň >> funguje i pro jednodomkovou vesnickou školu. > Problém je, že pak bys musel zavést pravidlo, že (téměř) všechno je až v > relacích. Proč by škola měla být výjimkou? Navíc to dává už teď v mnoha jiných > případech dobrý smysl. > > Např. ulice. Dnes jsou tak rozkouskované, mimo jiné kvůli (zase jiným) relacím, > že u mnoha ulic už neexistuje jeden objekt "ulice", který by ji obsahoval > celou. Pak z toho plynou různé problémy. Nejsnáz/okamžitě je to vidět třeba na > popiscích v mapě, jak jsou často nelogicky a hustě v místech, kde by je člověk > v mapě fakt nečekal a nechtěl. Např. na mostě či v tunelu. Proč tam jsou? > Protože ten úsek (např. v tunelu) je samostatný objekt, a to se jménem.
Ono to svoji logiku (ty relace vsude) ale ma ... cesta = nejaky "fyzicky" objekt (reka/potok/plot ...) ... vse dalsi (ulice s nazvem, silnice a jeji reference...) by melo byt uz v relaci, protoze to se netyka toho fyzickyho objektu. Ten muze mit nejaky povrch, rozmery ... ale ne jmeno. Silnice muze byt nejak siroka, mit nejaky povrch ... ale to ze je to 1/2/3. trida ... stejne od pohledu nepoznas. Navic je to jak kdy a jak kde. Potiz je v tech nastrojich - JOSM jde v tomhle nejdal, presto je prace s relacema proste tragicka, predevsim pokud mas jeden objekt, kterej je clenem vice relaci ... tak je to takovej gulas, ze se to stava naprosto neudrzovatelny. Vem si, ze mas dum ... fyzicky objekt ... a ten bude sam o sobe v deseti relacich, protoze je v nem 10 obchodu (tohle by dokonce vyresilo problem vice stejnych tagu nebo vice adres...), dal ten dum bude trebas v relaci "je pamatkove chranen" s 50ti dalsima, cast z nich bude v relaci "skola" .... a tahle se ti to bude ruzne prolinat a prekryvat, coz z hlediska dat jako takovych problem neni ... problem je, jak to editovat aby to nebylo vecne rozbity. Z myho pohledu by totiz idealni stav byl takovej, ze pri nejakym "BFUlike" nastaveni, by ten clovek vubec netusil, ze neco jako relace existuje. Jednoduse klipnu na barak ... a zjistim ... building=yes height=... color=... --------- address+ address+ shop+ shop+ shop+ kdyz pak klipnu na opluskovany data ... tak se mi rozvine obsah ty relace. Typy vuci jednotlivym objektum jako budova/silnice/... relaci bych urcil striktne (proste co se dohodne a nic jinyho, s tim, ze se samo muze neco pridat, pokud se dojde k tomu ze je to treba) custom tagy by pak povine mely mit prefix - trebas cust_ - s tim, ze v pripade standardizace by se hromadne odstranil a samo, slo by je davat pouze do relaci, v zadnym pripade primo na objekty. Jeneze ... protlac to ... ;D zobrazit citaci
> > Ale to by bylo nových relací... A úplně nová pravidla pro editaci OSM. A asi > sousta feature requestů na JOSM, protože aspoň mně teda přijde, že editovat > relace (zkoušel jsem pražskou MHD) je za trest. > > Milan > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

24.5.2013 10:51:42 (#41)
gravatar

jzvc

<jzvc at tpfree.net>
556
Dne 24.5.2013 10:41, jan lana napsal(a): zobrazit citaci
> Dne 24. května 2013 9:15 Milan Vancura <milan na ucw.cz > <mailto:milan na ucw.cz>> napsal(a): > > On Fri 24-05-13 07:33:13, Pavel Moravec wrote: > > >multipolygon potřebuje uzavřené křivky, nebo ne? > > Kupodivu nepotrebuje, jen je treba seradit useky cest za sebou tak, > > aby tu uzavrenou krivku tvorily (a velka cast rendereru si to umi > > On Fri 24-05-13 07:11:57, LM_1 wrote: > > Multipolygon právě umožňuje udělat oblast z různých, rozdělených > úseků. Já > > bych to udělal takto: > > první cesta: e--f--a--b--c (žádný tag kromě source) > > druhá cesta: c--d--e (plot, source) > > multipolygon obsahující obě cesty (les) > > Díky vám oběma, zase vím něco víc. Takže ta část relace pro trasu > linky MHD, > kde jsou cesty, je vlastně něco podobného (cesty seřazené za sebou). > A teď ještě jakou to má výhodu oproti tomu znovupoužití bodů? Že > je to mnohem > univerzálnější princip? > > > kreslit s pomoci relaci je (mozna) pracnejsi, ale mnohem lepe se pak > edituje - kdyz mam napriklad nakreslit les a pole vedle sebe
Rozhodne se to lepe needituje ... protoze kdyz standarne stahnes uzavrenou cestu, jejiz cast je ve vyrezu, stahne se ti ta cesta cela, vidis tagy ty plochy, ktery sou prirazeny ceste. Kdyz je to tak jak niz popisujes, mas problem ... hned nekolik problemu. Sosne se ti jen ta jedna cesta (trebas) a na ty v principu nemusi byt vubec zadne tagy ... nebo na ni jsou jen nejake - uz to je matouci. Porpavde velmi casto netusim, podle jakyho klice to vznika ... ale trebas vim, ze "aktualni" multipolygon (tak jak to vyrobi JOSM) dava vetsinu tagu do relace, kdezto kdysi to bylo tak, ze relace byla prazdna a tagy byly na vnejsi ceste ... Dal, kdyz klipnu na nejaky objekt, ocekavam, ze edituju vybrany objekt a ne nejaky dalsi. A mas zase problem ... bod/cesta ... muze byt v N ruznych relacich ... a ty chces editovat N-X objektu ... Kdyby ... se o chovalo tak, ze z hlediska dat to bude jedna cesta v relaci, ale editor by se tvaril, jako ze to jsou cesty dve ... tak stim nemam zadnej problem. Ostatne, velmi podobne bych si doved predstavit kresleni vicepruhovych vozovek - proste aby se to pro kreslice jevilo, jako ze maluje jednotlivy pruhy, odbocovaky .... a at si to pak editor nejak preklopi do relaci. Protoze vysvetlovat nekomu, ze kdyz kresli slozitejsi krizovatku, ze musi do kazdyho bodu krizeni pridavat 2+ zakazy odboceni, a kvuli tomu musi rozfrncat vsechny cesty na pidisegmenty ... (a pak se v takovy krizovatce renderuje nazev ulice 10x ...) zobrazit citaci
> > > a---b---c---d---e > | Pole | Les | > | f-------g > | | > h-------i > > Bez relaci to lze namalovat jako dve cesty > > C1: a-b-c-f-i-h-a (tag source,pole) > C2: a-d-e-g-f-c (tag source, les) > > Kdyz to maluji jako relaci, nejdriv vyrobim tri cesty > > E1: c-b-a-h-i-f (tag source) > E2: c-f (tag source) > E3: c-d-e-g-f (tag source) > > (ve skutecnosit v JOSM namaluju C1, pak vyberu body c a f a dam split > a pak namaluju E3, takze to jde stejne rychle) > > a pak udelate dva multipolygony > > M1: C1+C2 (tag pole) > M2: C2+C3 (tag les) > > Vysledek je stejny. > > Ale kdyz treba chcete zpresnit hranici c--f (protoze to puvodne bylo > treba moc hrube), tak ve variante s relacemi jen pridame par bodu do cesty > > E2': c-x-y-z-f > > a je hotovo. U varianty bez relaci to znamena ... no, vlastne nevim, > asi pridat ty body do C1 a pak nejak pridat ty stejne body i do C2. > > Vychytavka JOSM je v tom, ze kdyz rozdelite cestu, tak automaticky > upravi vsechny relace ktere tu cestu obsahuji, takze kdyz si pak treba > vsimnu, ze v bode f je rybnicek, tak jen rozdelim > > E1 v bode i na E1a a E1b > E3 v bode g, na E3a a E3b > > namaluju cestu > > E4: i-g (tag source) > > a vyrobim multipolygon > > M3: E1a+E3a+E4 (tag rybnik) > > (s temi vsemi pismenky a indexy to vypada slozite, ale v JOSM je to > jen par kliku, zkuste si to). > > - Jenda > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20130524/cfce67d9/attachment.html>

24.5.2013 10:59:39 (#42)
gravatar

jzvc

<jzvc at tpfree.net>
556
Dne 24.5.2013 13:26, LM_1 napsal(a): zobrazit citaci
> Dělení velkých multipolygonů (JOSM+relation toolbox): > - Nakreslím hranici, v místech, kde končí (dotýká se hranic > stávajícího multipolygonu) rozdělit cesty, pokud už nejsou - původní > multipolygon je buď stejný, nebo se uvnitř něk rozdělily cesty ale > pořád funguje jako předtím. > - Vyberu si, jednu ze dvou nových oblastí - tu která zůstane v > současném multipolygonu. > Postupně klikám na úseky které nejsou hranicí této oblasti a na [-] - > odstraním je z relace, stejně tak vyberu novou hranici a kliknu na [+] > - přidám novou hranici. Ve vlastnostech původní relace nechám seřadit > úseky za sebou - měl by se ukázat uzavřený ovál přes všechny úseky. > - Vyberu všechny úseky / hranice nově vytvářeného multipolygonu a > kliknu na [multipolygon] v toolboxu - vytvoří se nový multipolygon, na > něj přidám tagy podle potřeby. > > Jestli to stále zní složitě tak zkusím udělat návod s obrázkama. > LM
Ono ti neni slozity, ale je to neskutecnej vupruz - narozdil od rozdeleni plochy bez relace. Pokud by to JOSM zpracovat z hlediska uzivatele transparentne => pracujes s plochou jako celkem, ne s jednotlivejma cestama, tak by se to i dalo pouzivat. Proste bych (trebas) cekal, ze kdyz oznacim dva body vnejsi hranice, tak to v nich roztrhne a "prepuli" to primkou ... ja si pak doladim kudy vede ... zobrazit citaci
> > > Dne 24. května 2013 12:50 Zdeněk Pražák <zprazak na seznam.cz > <mailto:zprazak na seznam.cz>> napsal(a): > > No zde se řeší vytváření relací multi polygonů > ale mne více trápí případ pro rozdělení polygonu na multipolygon s > vniřními polygony, například když chci rozdelit polygon lesa na > část tvořenou smíšeným lesem, část tvořenou jehličnatým lesem, ve > kterém bude rybník, případně mýtina či louka. > Pokud se bude jednat o malý objekt tak to v JOSM nakreslím snadno, > horší je to v případě většího lesa již vytvořeného jako > multipolygon - zde se mi mnohdy stane přestože používám editor > relací v JOSM, že výsledek se nějak zamotá a musím jej smazat. > Existuje nějaký jednoduchý postup na dělení velkých multipolygonů? > Pražák > > > Dne 24. května 2013 10:41 jan lana <lana.jan na gmail.com > <mailto:lana.jan na gmail.com>> napsal(a): > > Dne 24. května 2013 9:15 Milan Vancura <milan na ucw.cz > <mailto:milan na ucw.cz>> napsal(a): > > On Fri 24-05-13 07:33:13, Pavel Moravec wrote: > > >multipolygon potřebuje uzavřené křivky, nebo ne? > > Kupodivu nepotrebuje, jen je treba seradit useky cest za > sebou tak, > > aby tu uzavrenou krivku tvorily (a velka cast rendereru > si to umi > > On Fri 24-05-13 07:11:57, LM_1 wrote: > > Multipolygon právě umožňuje udělat oblast z různých, > rozdělených úseků. Já > > bych to udělal takto: > > první cesta: e--f--a--b--c (žádný tag kromě source) > > druhá cesta: c--d--e (plot, source) > > multipolygon obsahující obě cesty (les) > > Díky vám oběma, zase vím něco víc. Takže ta část relace > pro trasu linky MHD, > kde jsou cesty, je vlastně něco podobného (cesty seřazené > za sebou). > A teď ještě jakou to má výhodu oproti tomu znovupoužití > bodů? Že je to mnohem > univerzálnější princip? > > > kreslit s pomoci relaci je (mozna) pracnejsi, ale mnohem lepe > se pak edituje - kdyz mam napriklad nakreslit les a pole vedle > sebe > > > a---b---c---d---e > | Pole | Les | > | f-------g > | | > h-------i > > Bez relaci to lze namalovat jako dve cesty > > C1: a-b-c-f-i-h-a (tag source,pole) > C2: a-d-e-g-f-c (tag source, les) > > Kdyz to maluji jako relaci, nejdriv vyrobim tri cesty > > E1: c-b-a-h-i-f (tag source) > E2: c-f (tag source) > E3: c-d-e-g-f (tag source) > > (ve skutecnosit v JOSM namaluju C1, pak vyberu body c a f a > dam split a pak namaluju E3, takze to jde stejne rychle) > > a pak udelate dva multipolygony > > M1: C1+C2 (tag pole) > M2: C2+C3 (tag les) > > Vysledek je stejny. > > Ale kdyz treba chcete zpresnit hranici c--f (protoze to > puvodne bylo treba moc hrube), tak ve variante s relacemi jen > pridame par bodu do cesty > > E2': c-x-y-z-f > > a je hotovo. U varianty bez relaci to znamena ... no, vlastne > nevim, asi pridat ty body do C1 a pak nejak pridat ty stejne > body i do C2. > > Vychytavka JOSM je v tom, ze kdyz rozdelite cestu, tak > automaticky upravi vsechny relace ktere tu cestu obsahuji, > takze kdyz si pak treba vsimnu, ze v bode f je rybnicek, tak > jen rozdelim > > E1 v bode i na E1a a E1b > E3 v bode g, na E3a a E3b > > namaluju cestu > > E4: i-g (tag source) > > a vyrobim multipolygon > > M3: E1a+E3a+E4 (tag rybnik) > > (s temi vsemi pismenky a indexy to vypada slozite, ale v JOSM > je to jen par kliku, zkuste si to). > > - Jenda > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org <mailto:Talk-cz na openstreetmap.org> > http://lists.openstreetmap.org/listinfo/talk-cz > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org <mailto:Talk-cz na openstreetmap.org> > http://lists.openstreetmap.org/listinfo/talk-cz > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20130524/4193095a/attachment.html>

25.5.2013 10:04:47 (#43)
gravatar

hanoj

<ehanoj at gmail.com>
718
zobrazit citaci
> rozfrncat vsechny cesty na pidisegmenty ... (a pak se v takovy krizovatce > renderuje nazev ulice 10x ...)
*** No v editoru to az tak asi nevadi a pri renderovani lze pouzit bezny postprocessing pro konkrétní tag. V GIS se tomu říká rozpuštění, dissolve, viz obrázek: http://kuc.cz/ds40o2 Dissolve je opačný princip k neomezené hierarchizaci tagů. ha hanoj

26.5.2013 12:27:23 (#44)
gravatar

LM_1

<flukas.robot+osm at gmail.com>
103
Slíbený návod na dělení multipolygonů: http://wiki.openstreetmap.org/wiki/CS:How_to_split_multipolygon Dne 25. května 2013 22:04 hanoj <ehanoj na gmail.com> napsal(a): zobrazit citaci
> > rozfrncat vsechny cesty na pidisegmenty ... (a pak se v takovy krizovatce > > renderuje nazev ulice 10x ...) > *** No v editoru to az tak asi nevadi a pri renderovani lze pouzit > bezny postprocessing pro konkrétní tag. V GIS se tomu říká rozpuštění, > dissolve, viz obrázek: http://kuc.cz/ds40o2 > > Dissolve je opačný princip k neomezené hierarchizaci tagů. > > > ha > hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20130526/2332fb94/attachment.html>

« zpět na výpis měsíce