Společné hranice ploch

32 zpráv
Zpět na přehled

Společné hranice ploch

32 zpráv LJHMJZPM 9 účastníků 30 min čtení
  1. jzvc jzvc na tpfree.net #mcda5fe
    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.
  2. LM_1 flukas.robot+osm na gmail.com #m9fbe67
    Kromě toho, že ve skutečnosti existuje jen jedna hranice a proto není důvod aby jich v datech bylo víc:
    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)
    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?
  3. hanoj ehanoj na gmail.com #m287339
    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
  4. LM_1 flukas.robot+osm na gmail.com #m0eac85
    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
    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í.
  5. jzvc jzvc na tpfree.net #m2b0c96
    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.
  6. LM_1 flukas.robot+osm na gmail.com #m22db0f
    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
  7. hanoj ehanoj na gmail.com #m6c2824
    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
  8. Milan Vancura milan na ucw.cz #mc92aa9
    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
  9. LM_1 flukas.robot+osm na gmail.com #mdd9dbb
    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.
    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
    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. :-)
  10. LM_1 flukas.robot+osm na gmail.com #mcb5d31
    @hanoj:
    ...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
  11. hanoj ehanoj na gmail.com #ma23b52
    ...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
  12. Milan Vancura milan na ucw.cz #md66247
    ...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
  13. LM_1 flukas.robot+osm na gmail.com #m985139
    Už je mi to jasné. :)
  14. LM_1 flukas.robot+osm na gmail.com #m96f3f4
    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
  15. Milan Vancura milan na ucw.cz #mcc5359
    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
  16. LM_1 flukas.robot+osm na gmail.com #m033a5d
    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
  17. Pavel Moravec pavel.moravec na email.cz #m3c6821
    Zdravim,
    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.
  18. Milan Vancura milan na ucw.cz #mb0d94c
    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)
    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
  19. jan lana lana.jan na gmail.com #mb9ac0c
    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)
    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
  20. Marián Kyral mkyral na email.cz #m9baf91
    Dne 24. května 2013 9:15 Milan Vancura <milan na ucw.cz>
    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)
    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
  21. hanoj ehanoj na gmail.com #m40a783
    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
  22. jan lana lana.jan na gmail.com #mf10f09
    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
  23. Zdeněk Pražák zprazak na seznam.cz #m876ace
    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
  24. LM_1 flukas.robot+osm na gmail.com #me81408
    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
  25. Pavel Machek pavel na ucw.cz #mc2375b
    Ahoj!
    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.
    Ale tady jsou ty nove relace asi na miste :-(. A taky chytrejsi renderer, ktery si porovna jmeno, a nebude psat 2x stejne....
  26. Zdeněk Pražák zprazak na seznam.cz #m0f7b98
    jestli bych mohl poprosit o obrázkový návod pro počítačové negramoty Děkuji
  27. jan lana lana.jan na gmail.com #m2f563d
    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ě:
    * 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
  28. jzvc jzvc na tpfree.net #m6e061b
    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
  29. jzvc jzvc na tpfree.net #m2b0e5d
    Dne 24. května 2013 9:15 Milan Vancura <milan na ucw.cz
    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)
    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 ...)
  30. jzvc jzvc na tpfree.net #m49b537
    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 ...
  31. hanoj ehanoj na gmail.com #mbf6626
    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
  32. LM_1 flukas.robot+osm na gmail.com #me64b19
    Slíbený návod na dělení multipolygonů: http://wiki.openstreetmap.org/wiki/CS:How_to_split_multipolygon
Napsat odpověď e-mailem… Odpovědět

Otevře váš e-mailový klient. Odpovědi pak sledujte zde na webu.