Podivné relace a překryvy landuse=*

17 zpráv
Zpět na přehled

Podivné relace a překryvy landuse=*

17 zpráv PMJKP 5 účastníků 21 min čtení
  1. Petr Vejsada osm na propsychology.cz #me70ce2
    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 :(
  2. Martin Švec - OSM osm na maatts.cz #m9c5f48
    Ahoj,
    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
  3. Kasparek Tomas kasparek na fit.vutbr.cz #m3a6f98
    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
  4. Martin Švec - OSM osm na maatts.cz #m0833c3
    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. Martin
  5. Petr Vejsada osm na propsychology.cz #m9e66ca
    Ahoj,
    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.
  6. Kasparek Tomas kasparek na fit.vutbr.cz #md5c5ea
    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.
    Diky, takhle jsem si to predstavoval.
  7. Martin Švec - OSM osm na maatts.cz #m308ad7
    Ahoj,
    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.
    Záleží jak máš chuť a čas :-) Co si matně vzpomínám, zasekli jsme se na odstraňování tagů z inner cest. Můžu s tím zas pomoct, ale od začátku října jsem strávil většinu času předěláváním LPIS traceru, takže jsem to zatím pustil z hlavy. Rozhodně by to pomohlo traceru, multipolygony bez otagovaných cest rozřezává mnohem agresivněji, to je jen čistá geometrie. Přemýšlel jsem i o zaintegrování opravy old-style lesních multipolygonů přímo do LPIS traceru. Stejně se při ořezech do multipolygonů zasahuje, tak by se v rámci ořezu upravily pro přesně definované případy i landuse=forest tagy.
    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.
    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.
    Martin
  8. "Petr Morávek [Xificurk]" petr na pada.cz #mbf4ab7
    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.
    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. S pozdravem, Petr Morávek aka Xificurk [1] https://github.com/openstreetmap/osm2pgsql/issues/80
  9. jzvc jzvc na tpfree.net #me8a92d
    Ahoj,
    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.
    Cus, ty % chyb bych asi razantne snizil. Podivej se trebas na KU. Hromada cest je clenem 1-N relaci ruznych urovni, trebas v pripade statnich hranic je to zaroven soucast kraje, okresu, obce a konkretniho KU. Vubec bych se nedivil, kdyby to podobne bylo i jinde nez u hranic.
  10. Petr Vejsada osm na propsychology.cz #mdd2d69
    Ahoj,
    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?
  11. "Petr Morávek [Xificurk]" petr na pada.cz #m09a74e
    Ahoj,
    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.
    Ono se mi toho za ten rok už dost z hlavy vypařilo :-) Zkusím se na to podívat a sepsat nějak srozumitelně algoritmus, který se používá. Ale neslibuju, kdy se k tomu dostanu... Bohužel jsem teď dost vytížen jinými záležitostmi. S pozdravem, Petr Morávek aka Xificurk
  12. jzvc jzvc na tpfree.net #m3d5e47
    Ahoj,
    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é...).
    V tomhle panuje v OSM obecne poradnej bordelak. Mineno rozliseni plosnych a liniovych objektu. Neco je chapano jako plocha "od prirody", neco se jako plocha extra znaci (area=yes) ... neco dokonce vyzaduje, aby to byl multipoly. Pak stim nejak funguj automatizovane. Jako bonus, nekdy je kombinace linioveho a plosneho objektu zadouci a logicka, nekdy prozmenu spis nezadouci. Trebas u ty oploceny obory je dost nepravdepodobny, ze by jeji hranice vedla jinudy, nez kudy vede plot, ale prozmenu pokud nekdo pouzije jako hranici silnice, tak driv nebo pozdejs narazis na to, ze silnici nekdo o 30m prelozil, ale hranici nikoli. Muj ciste osobni nazor na to je ten, ze by to chtelo trochu vetsi vynucovaci power obecne (porad lepsi spatne, ale vsude stejne). Co se tagovani samotnyho tyce, dlouhodobe si myslim, ze na objekt jako takovy patri vyhradne "fyzicke" vlastnosti a vse ostatni do relace. Tudiz trebas na silnici by melo byt, ze je asfaltova, ma 3 pruhy, ale ze to je 1/2/3/D/R/... uz patri do relace. Dtto adresa u domu by mela byt idealne v relaci (a jeden dum pak muze mit klidne 150 adres).
  13. jzvc jzvc na tpfree.net #m58f710
    Ahoj,
    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?
    To je presne ono (viz predchozi), les je spravne i jako uzavrena cesta. A ses v loji. 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.
  14. Petr Vejsada osm na propsychology.cz #m18bb37
    Ahoj,
    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.?
  15. jzvc jzvc na tpfree.net #m37bb3b
    Ahoj,
    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
    => co je na relaci, ti je jedno, a prepises to tim, co je na ceste?
    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?
    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. Vnitri cesty jsou az dalsi krok.
    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.
    Tagu muze byt mnohem vic. Pokud vemes landuse a presunes to na relaci, tak nejake upresneni v podobe typu nechas na ceste? Ale tim to uplne rozbijes.
    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.
    Mluvim o situaci, kdy inner cesty maji totozne tagovani jako v tuto chvili relace, coz je principielni nesmysl (pak tam nemusi byt) takze se da predpokladat, ze je to mineno jako dira. 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.
  16. Petr Vejsada osm na propsychology.cz #m62db2d
    Ahoj,
    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 ...
  17. Martin Švec - OSM osm na maatts.cz #mc8d75a
    Ahoj,
    Ahoj,
    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 ...
    Je určitě nesmysl chtít pokrýt všechny kombinace. Já se na to díval z druhé strany. Existuje pár dobře definovatelných podmnožin, které pokrývají vysoké procento lesů v ČR. Ručně už jsem lesů přetagoval určitě přes dvě stovky a budťo je to původní uhul:wms import, nebo ho kreslil Petr1868 ;-) Do nich se pak prováděly zásahy, které se buď dají zas přesně definovat (louka uprostřed lesa), nebo se holt prohlásí za riskantní a nechají na ruční kontrolu. Všechny tagy navíc oproti očekávaným = riskantní multipolygon. Každopádně i když to Petr odpíská, probralo se tu pár užitečných věcí, takže díky za inspiraci. Jestli/až mě přestane bavit vrtání v traceru, zkusím se k tomu problému vrátit. Btw, související poznámka: JOSM zjednodušuje situaci tím, že za otagované považuje jen ty objekty, které obsahují "zajímavé" tagy. Existuje výčet "nezajímavých" tagů, které při podobných rozhodováních ignoruje. Totéž dělá i tracer při rozhodování o bezpečnosti ořezů. Seznam tagů viz zdrojáky JOSM [1] [2], funkce OsmPrimitive.getUninterestingKeys() a updateTagged(), nebo přímo předvolby v JOSM (tags.discardable, tags.uninteresting, tags.workinprogress). [1] http://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/data/osm/OsmPrimitive.java#L665 [2] http://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/data/osm/OsmPrimitive.java#L818 Martin
Napsat odpověď e-mailem… Odpovědět

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