>p<

> Ahoj, > > dává smysl relace s pouze inner cestami? 24777 je takovou. Tady asi měla být > cesta 273460501 (les) jako outer.

> Pak jsou tu překryvy v landuse, které se snažím řešit, některé jsou dost > masakrózní, třeba relace 934661 a 25984 - jeden a ten samý les, jen s jinými > dírami.

> "Obyčejné" překryvy landuse asi půjde vyřešit botem stejně jako velké překryvy > budov, ale tohle teda asi ne :(

> > -- > Petr >> p< > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz

> V první řadě bych asi oprášil myšlenku opravy old-style landuse multipolygonů na new-style > multipolygony. Co dělám na ořezu multipolygonů v LPIS traceru, tak old-style multipolygony jsou

> On Wed, Nov 19, 2014 at 12:56:47PM +0100, Martin Švec - OSM wrote: >> V první řadě bych asi oprášil myšlenku opravy old-style landuse multipolygonů na new-style >> multipolygony. Co dělám na ořezu multipolygonů v LPIS traceru, tak old-style multipolygony jsou > Kdyz jsme u toho je nekde na wiki popsan old a new style?

> Dik > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz

> V první řadě bych asi oprášil myšlenku opravy old-style landuse multipolygonů na new-style > multipolygony. Co dělám na ořezu multipolygonů v LPIS traceru, tak old-style multipolygony jsou > největší problém při identifikaci, o jakou plochu se vůbec jedná. Hlavně u inner cest, kde je v > tagování pěkný chaos. Ale už jsem viděl nekonzistentní tagování i u outer cest. V podstatě teď > nedovolím říznout do víc než jedné otagované cesty zároveň, protože jinak bych musel výčtem > kontrolovat všechny legální, pololegální a nelegální kombinace tagů v zasažených cestách > multipolygonu. (A zvykl jsem si v JOSM každý landuse multipolygon okamžitě ručně opravit na > new-style tagování, když na něj narazím. :-))

> Dne 19.11.2014 15:39, Kasparek Tomas napsal(a): > > On Wed, Nov 19, 2014 at 12:56:47PM +0100, Martin Švec - OSM wrote: > >> V první řadě bych asi oprášil myšlenku opravy old-style landuse multipolygonů na new-style > >> multipolygony. Co dělám na ořezu multipolygonů v LPIS traceru, tak old-style multipolygony jsou > > Kdyz jsme u toho je nekde na wiki popsan old a new style? > > http://wiki.openstreetmap.org/wiki/Relation:multipolygon ... sekce "Tagging", popř. "Mapping Style, > best practice": *apply all tags which describe the area **/to the relation, and not to the ways/*. > > Stručně řečeno: > > * new-style = tagy popisující vlastnosti plochy multipolygonu jsou pouze na relaci. > > * old-style = tagy jsou na outer cestách, popř. na outer i inner cestách (u nás hodně lesů), > případně mix všech tří způsobů v důsledku editací. > > Jak mají renderery ten chaos řešit je nastíněno v sekci "Detailed tagging", ale řada kombinací tam > chybí nebo nesedí s praxí. Podle těch pravidel by se např. otagované inner cesty uhul:wms lesů > neměly renderovat jako díry. Editacemi old-style multipolygonu pak bohužel často padneš do kategorie > "undefined results", aniž by sis toho vůbec všiml.

> Ahoj, > > On Wed, Nov 19, 2014 at 12:56:47PM +0100, Martin Švec - OSM wrote: > >> V první řadě bych asi oprášil myšlenku opravy old-style landuse multipolygonů na new-style >> multipolygony. Co dělám na ořezu multipolygonů v LPIS traceru, tak old-style multipolygony jsou >> největší problém při identifikaci, o jakou plochu se vůbec jedná. Hlavně u inner cest, kde je v >> tagování pěkný chaos. Ale už jsem viděl nekonzistentní tagování i u outer cest. V podstatě teď >> nedovolím říznout do víc než jedné otagované cesty zároveň, protože jinak bych musel výčtem >> kontrolovat všechny legální, pololegální a nelegální kombinace tagů v zasažených cestách >> multipolygonu. (A zvykl jsem si v JOSM každý landuse multipolygon okamžitě ručně opravit na >> new-style tagování, když na něj narazím. :-)) > mám tu ten otestovaný skript na lesy. Nebyl nikdy použit naostro, ale použít > se může. Otestovaný znamená, že byla ověřeno u značného množství lesů, že > spuštění skriptu neudělá ještě větší binec, ale pomůže spíš pořádku.

> Zobecnit to na všechny relace s landuse či na všechny relace si netroufám, > to by potřebovalo větší průzkum. Není totiž pravda, že všechny tagy z outer > cesty by se měly přesunout na relaci. Příklad - oplocený les, obora.

> landuse=forest má být na relaci, ale barrier=fence má být na outer cestě. > Přesun plotu na relaci by bylo chybou (za předpokladu, díry nejsou také > oplocené...). > > No já se spíš orientuju na mazání zjevných duplicit.

> Dne 19.11.2014 16:29, Petr Vejsada napsal(a): >> Zobecnit to na všechny relace s landuse či na všechny relace si netroufám, >> to by potřebovalo větší průzkum. Není totiž pravda, že všechny tagy z outer >> cesty by se měly přesunout na relaci. Příklad - oplocený les, obora. > > Jo, určitě. To jsme probírali už v září, že přesouvat se může jen landuse=forest tag. Další typy > landuse by se musely prozkoumat.

> Ahoj, > > Dne 19.11.2014 8:29, Petr Vejsada napsal(a): >> Ahoj, >> >> dává smysl relace s pouze inner cestami? 24777 je takovou. Tady asi měla být >> cesta 273460501 (les) jako outer. > IMHO jasná chyba. Ta relace býval normální uhul:wms les, ale pak ho někdo rozdělil na víc kusů a > neopravil původní relaci. > >> Pak jsou tu překryvy v landuse, které se snažím řešit, některé jsou dost >> masakrózní, třeba relace 934661 a 25984 - jeden a ten samý les, jen s jinými >> dírami. > Viděl jsem lepší, byla to nějaká zoologická zahrada nebo park. Tam to byly tuším tři relace s > několika stejnými outer cestami. > >> "Obyčejné" překryvy landuse asi půjde vyřešit botem stejně jako velké překryvy >> budov, ale tohle teda asi ne :( > V první řadě bych asi oprášil myšlenku opravy old-style landuse multipolygonů na new-style > multipolygony. Co dělám na ořezu multipolygonů v LPIS traceru, tak old-style multipolygony jsou > největší problém při identifikaci, o jakou plochu se vůbec jedná. Hlavně u inner cest, kde je v > tagování pěkný chaos. Ale už jsem viděl nekonzistentní tagování i u outer cest. V podstatě teď > nedovolím říznout do víc než jedné otagované cesty zároveň, protože jinak bych musel výčtem > kontrolovat všechny legální, pololegální a nelegální kombinace tagů v zasažených cestách > multipolygonu. (A zvykl jsem si v JOSM každý landuse multipolygon okamžitě ručně opravit na > new-style tagování, když na něj narazím. :-)) > > Pokud jde o členství v landuse multipolygon relacích, je běžné že inner cesta v jedné relaci je > zároveň outer cesta v druhé relaci. Multipolygon pouze s inner cestami je imho vždy nesmysl. > Společná outer cesta ve více multipolygonech může být teoreticky v pořádku, pokud je to hraniční > cesta mezi dvěma sousedními plochami. Ale v 95% případů to bude spíš taky chyba. >

> Martin > >> >> -- >> Petr >>> p< >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-cz > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz >

> Ohledně zobecnění na další multipolygony by asi stálo za to se podívat > na kód osm2pgsql, který tohle obstarává. Před rokem jsem se trochu > šťoural v jednom bugu [1], který s tím souvisí - tenkrát jsem docela > načetl kód, co to obstarává. Pokud se něco nezměnilo, tak to není moc > ideální, ale funguje to ve většině případů. Myslím, že pokud by se takto > přetogovalo vše na new-style, tak jedině dobře. Je možné, že občas bude > výsledek ne úplně ideálně správný, ale aspoň bude shodný s tím, jak se

> to chová teď, protože většina lidí stejně nejprve importuje OSM data > přes osm2pgsql do postgisu a pak s nima pracuje dál.

> Ahoj, > > Dne St 19. listopadu 2014 17:36:53, Petr Morávek [Xificurk] napsal(a): > >> Ohledně zobecnění na další multipolygony by asi stálo za to se podívat >> na kód osm2pgsql, který tohle obstarává. Před rokem jsem se trochu >> šťoural v jednom bugu [1], který s tím souvisí - tenkrát jsem docela >> načetl kód, co to obstarává. Pokud se něco nezměnilo, tak to není moc >> ideální, ale funguje to ve většině případů. Myslím, že pokud by se takto >> přetogovalo vše na new-style, tak jedině dobře. Je možné, že občas bude >> výsledek ne úplně ideálně správný, ale aspoň bude shodný s tím, jak se > > no, když to máš nastudované, tak bych docela uvítal tvůj popis než abych to > třeba studoval od začátku.

> Ahoj, > > On Wed, Nov 19, 2014 at 12:56:47PM +0100, Martin Švec - OSM wrote: > >> V první řadě bych asi oprášil myšlenku opravy old-style landuse multipolygonů na new-style >> multipolygony. Co dělám na ořezu multipolygonů v LPIS traceru, tak old-style multipolygony jsou >> největší problém při identifikaci, o jakou plochu se vůbec jedná. Hlavně u inner cest, kde je v >> tagování pěkný chaos. Ale už jsem viděl nekonzistentní tagování i u outer cest. V podstatě teď >> nedovolím říznout do víc než jedné otagované cesty zároveň, protože jinak bych musel výčtem >> kontrolovat všechny legální, pololegální a nelegální kombinace tagů v zasažených cestách >> multipolygonu. (A zvykl jsem si v JOSM každý landuse multipolygon okamžitě ručně opravit na >> new-style tagování, když na něj narazím. :-)) > > mám tu ten otestovaný skript na lesy. Nebyl nikdy použit naostro, ale použít > se může. Otestovaný znamená, že byla ověřeno u značného množství lesů, že > spuštění skriptu neudělá ještě větší binec, ale pomůže spíš pořádku. > Zobecnit to na všechny relace s landuse či na všechny relace si netroufám, > to by potřebovalo větší průzkum. Není totiž pravda, že všechny tagy z outer > cesty by se měly přesunout na relaci. Příklad - oplocený les, obora. > landuse=forest má být na relaci, ale barrier=fence má být na outer cestě. > Přesun plotu na relaci by bylo chybou (za předpokladu, díry nejsou také > oplocené...).

> > No já se spíš orientuju na mazání zjevných duplicit. > > -- > Petr > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz >

> Ahoj, > > Dne St 19. listopadu 2014 17:36:53, Petr Morávek [Xificurk] napsal(a): > >> Ohledně zobecnění na další multipolygony by asi stálo za to se podívat >> na kód osm2pgsql, který tohle obstarává. Před rokem jsem se trochu >> šťoural v jednom bugu [1], který s tím souvisí - tenkrát jsem docela >> načetl kód, co to obstarává. Pokud se něco nezměnilo, tak to není moc >> ideální, ale funguje to ve většině případů. Myslím, že pokud by se takto >> přetogovalo vše na new-style, tak jedině dobře. Je možné, že občas bude >> výsledek ne úplně ideálně správný, ale aspoň bude shodný s tím, jak se > > no, když to máš nastudované, tak bych docela uvítal tvůj popis než abych to > třeba studoval od začátku. > >> to chová teď, protože většina lidí stejně nejprve importuje OSM data >> přes osm2pgsql do postgisu a pak s nima pracuje dál. > > to možná ano, ale že by zrovna pomocí osm2pgsql? Na analýzy se hodí víc > snapshot schema a to se dělá přes osmosis. > > Nemám na to kapacitu si teď přibrat studium osm2pgsql, přesto díky za tip. > > Zpět k tomu stávajícímu skriptu. Pustil jsem si ho teď na pouhých 5 lesů a > zjistil jsem, že neodstraňuje tagy landuse=forest na inner cestách. Tak jsem > to upravil - jednak jsem přidal na univerzálnosti, že jako parametr je teď k,v > , tedy mohu zadat nejen landuse=forest, ale cokoli=cokoli. Nato jsem si > uvědomil, že může být i situace: > > outer landuse=forest, forest_type=typ_a > inner landuse=forest, forest_type=typ_b > > a pak bych na inner cestě odstranil landuse=forest neoprávněně. > > Hmm, co s tím?

> > -- > Petr > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz >

> Defakto co muzes udela je zhruba: > 1) Vemes mulipoly, na kterym nejsou tagy.

> 2) zkontrolujes, zda ma 1-N outer

> a zda maji vsechny stejne tagovani > (pokud ne, konec)

> 3) tagy vlozis na relaci a zrusis na outer cestach

> 4) vyberes vsechny inner se stejnym tagovanim jake ma ted relace > 5) zrusis na nich tagovani.

> Alternativy jsou samozrejme ze podobne projdes i multipoly s tagovanim, > a provedes jen kontrolu/odstranovani tagu.

> Zabordeleny relace muzes oznacit nejakym fixme.

> Ahoj, > > Dne St 19. listopadu 2014 20:39:09, jzvc napsal(a): > >> Defakto co muzes udela je zhruba: >> 1) Vemes mulipoly, na kterym nejsou tagy. > > dělám to tak, že vezmu outer cesty, na kterých je náš hledaný tag

> >> 2) zkontrolujes, zda ma 1-N outer > > zda má právě 1 outer > >> a zda maji vsechny stejne tagovani >> (pokud ne, konec) > > proč? tady ještě končit nemusím. Mohu přesunout náš tag z outer na relaci. Tím > těm inner neublížím, ne?

> >> 3) tagy vlozis na relaci a zrusis na outer cestach > > jen ten jeden tag, který hledáme (landuse, building, ...) / přesunout fence z > našeho příkladu by bylo chybou.

> >> 4) vyberes vsechny inner se stejnym tagovanim jake ma ted relace >> 5) zrusis na nich tagovani. > > no, ale tady se netrefím s dostatečnou spolehlivostí, pže relace nebude mít ty > tagy, které měla předtím outer. Že k té shodě dojde, sice možné je, ale je to > dost náhodná veličina. Pokud totiž z těch inner ty tagy nesundám, relation > bude forest a inner bude taky forest (i když na inner být nemá a ke shodě > nedojde kvůli nějaké kravině, jako created_by=JOSM), tak se žádná díra nejspíš > konat nebude. Nebo bude, ale to záleží na momentální konfiguraci, verzi a > náladě Mapniku.

> >> Alternativy jsou samozrejme ze podobne projdes i multipoly s tagovanim, >> a provedes jen kontrolu/odstranovani tagu. > > To vlastně dělám tím, že začínám hledat na outer. > >> Zabordeleny relace muzes oznacit nejakym fixme. > > Vraťme se k verzi, kdy nebudu srovnávat _všechny_ tagy na relaci se _všemi_ > tagy na inner. > > Chyba může nastat, když náš (příklad) landuse=forest bude mít ještě nějaký > přívlastek (jehličnatý, listnatý). Co varianta, že bychom to před akcí vždy > nastudovali, tedy jaké zrádnosti nás mohou čekat u lesů, jaké u luk, baráků > atd.? > > -- > Petr > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz >

> Muzes mit 1-N OUTER cest, a kazda muze mit jiny tagovani. Jak rozhodnes, co > je spravne? Pokud vybiras jen takovy, ktery maji prave jeden, tak ten > problem samo nevznika.

> Zkusim priklad: > > > landuse=forest > leaf_cycle=semi_deciduous > leaf_type=broadleaved > name=lesik > > Tohle je landuse tagovani. > > Pro jednoduchost prikladu predpokladejme, ze je na outer i inner ceste > totez. > > A rekneme, ze na outer ceste je navic jako bonus: > barrier=fence > > => ty musis z outer cesty vzit vsechny 4 tagy, presunout je do relace + bys > mel ty stejne tagy odstranit na inner ceste. Plot nechas tam kde je. > > Pokud presunes pouze landuse=forest, tak si tomu prave nasadil korunu.

> Ahoj, > > On Fri, Nov 21, 2014 at 01:41:12PM +0100, jzvc wrote: > >> Muzes mit 1-N OUTER cest, a kazda muze mit jiny tagovani. Jak rozhodnes, co >> je spravne? Pokud vybiras jen takovy, ktery maji prave jeden, tak ten >> problem samo nevznika. > nn, myslel jsem relace, které mají právě jednu outer cestu a ne víc. O tom > už tu byla debata. > > outer=les > outer=les > outer=louka > > a dohromady to nemá s lesem mnoho společného, protože jde o přírodní > rezervaci, která se skládá ze dvou lesů a jedné louky. > >> Zkusim priklad: >> >> >> landuse=forest >> leaf_cycle=semi_deciduous >> leaf_type=broadleaved >> name=lesik >> >> Tohle je landuse tagovani. >> >> Pro jednoduchost prikladu predpokladejme, ze je na outer i inner ceste >> totez. >> >> A rekneme, ze na outer ceste je navic jako bonus: >> barrier=fence >> >> => ty musis z outer cesty vzit vsechny 4 tagy, presunout je do relace + bys >> mel ty stejne tagy odstranit na inner ceste. Plot nechas tam kde je. >> >> Pokud presunes pouze landuse=forest, tak si tomu prave nasadil korunu. > > no to teda jo. A jelikož udělat vyčerpávající seznam tagů, které spolu souvisí, > je nemožné, tak se mi do toho chce čím dál méně. Ostatně celosvětově to také > odpískali ...