> 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)?

> 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,

> - 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?

> 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?

>> - 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)

> 6. Potreboval bych rozdelit obrovsky multipolygon lesa, abych mohl u > casti vyznacit typ lesa. U hranic se Slovenskem, kde to delalo

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

> 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

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

>>> 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?

> Probuh, jen to ne ... ty lesy jsou i tak neuveritelne nepresny ... ale > je tam bambilion rucnich zmen, ktery bys tim naprosto vsechny zahodil.

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

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

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

> 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. >

> 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. > > > 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 > >

> 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?

> 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.

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

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

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

> 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 > - ...?

>> 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í.

> 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.

> 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. >

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

>>...každá plocha má nejen svou hranu na hranici, ale také své lomové body.

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

>>>...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é.

> >>>...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

> >>>...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 >

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

> 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.

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

> 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?

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

> 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)

> 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?

> 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).

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

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

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

> > 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.

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

> > 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... >

> * 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)

> 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.

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

> 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 > http://lists.openstreetmap.org/listinfo/talk-cz

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

> rozfrncat vsechny cesty na pidisegmenty ... (a pak se v takovy krizovatce > renderuje nazev ulice 10x ...)

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