Zrovna v případě silnic/řek apod. základní pravidlo existuje - jeden objekt v realitě - jeden objekt v osm. Z toho by vyplývalo, že v osm by měl být jen jeden objekt s ref=D1 a to by nutně byla relace, proti kterým existuje značný (pro mě nepochopitelný) odpor. Stejně tak u školy bych tyto informace dával do relace - je to univerzálnější v případě, že škola má víc budov/hřišť/celý areál, zároveň funguje i pro jednodomkovou vesnickou školu. LM_1
Dne 23. května 2013 14:07 jzvc <j...@tpfree.net> napsal(a): > 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 <eha...@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@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > > _______________________________________________ > Talk-cz mailing > listTalk-cz@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-cz > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > >
_______________________________________________ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz