« zpět na výpis měsíce |

[Talk-cz] Podivné relace a překryvy landuse=*

Vlákno 19.11. - 21.11.2014, počet zpráv: 17


19.11.2014 08:29:18 (#1)
gravatar

Petr Vejsada

<osm at propsychology.cz>
507
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 zobrazit citaci
>p<

19.11.2014 12:56:47 (#2)
gravatar

Martin Švec - OSM

<osm at maatts.cz>
109
Ahoj, Dne 19.11.2014 8:29, Petr Vejsada napsal(a): zobrazit citaci
> 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. zobrazit citaci
> 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. zobrazit citaci
> "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 zobrazit citaci
> > -- > Petr >> p< > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz

19.11.2014 03:39:39 (#3)
gravatar

Kasparek Tomas

<kasparek at fit.vutbr.cz>
40
On Wed, Nov 19, 2014 at 12:56:47PM +0100, Martin Švec - OSM wrote: zobrazit citaci
> 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 -- Tomas Kasparek e-mail: kasparek at fit.vutbr.cz CVT FIT VUT Brno, L127 jabber: tomas.kasparek at jabber.cz Bozetechova 1, 612 66 web : http://www.fit.vutbr.cz/~kasparek Brno, Czech Republic phone : +420 54114-1220 GPG: 2F1E 1AAF FD3B CFA3 1537 63BD DCBE 18FF A035 53BC May the command line live forever! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 213 bytes Desc: not available URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20141119/ed7374ce/attachment.sig>

19.11.2014 04:20:31 (#4)
gravatar

Martin Švec - OSM

<osm at maatts.cz>
109
Dne 19.11.2014 15:39, Kasparek Tomas napsal(a): zobrazit citaci
> 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. Martin zobrazit citaci
> Dik > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz
------------- další část --------------- HTML příloha byla odstraněna... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20141119/856d4e3b/attachment.html>

19.11.2014 04:29:59 (#5)
gravatar

Petr Vejsada

<osm at propsychology.cz>
507
Ahoj, On Wed, Nov 19, 2014 at 12:56:47PM +0100, Martin Švec - OSM wrote: zobrazit citaci
> 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

19.11.2014 04:51:50 (#6)
gravatar

Kasparek Tomas

<kasparek at fit.vutbr.cz>
40
On Wed, Nov 19, 2014 at 04:20:31PM +0100, Martin Švec - OSM wrote: zobrazit citaci
> 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.
Diky, takhle jsem si to predstavoval. -- Tomas Kasparek e-mail: kasparek at fit.vutbr.cz CVT FIT VUT Brno, L127 jabber: tomas.kasparek at jabber.cz Bozetechova 1, 612 66 web : http://www.fit.vutbr.cz/~kasparek Brno, Czech Republic phone : +420 54114-1220 GPG: 2F1E 1AAF FD3B CFA3 1537 63BD DCBE 18FF A035 53BC May the command line live forever! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 213 bytes Desc: not available URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20141119/665c1010/attachment.sig>

19.11.2014 05:18:11 (#7)
gravatar

Martin Švec - OSM

<osm at maatts.cz>
109
Dne 19.11.2014 16:29, Petr Vejsada napsal(a): zobrazit citaci
> 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.
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. zobrazit citaci
> 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. zobrazit citaci
> 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

19.11.2014 05:36:53 (#8)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
138
Dne 19.11.2014 17:18, Martin Švec - OSM napsal(a): zobrazit citaci
> 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.
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

19.11.2014 08:15:13 (#9)
gravatar

jzvc

<jzvc at tpfree.net>
530
Dne 19.11.2014 v 12:56 Martin Švec - OSM napsal(a): zobrazit citaci
> 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. >
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. zobrazit citaci
> Martin > >> >> -- >> Petr >>> p< >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-cz > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz >

19.11.2014 08:19:47 (#10)
gravatar

Petr Vejsada

<osm at propsychology.cz>
507
Ahoj, Dne St 19. listopadu 2014 17:36:53, Petr Morávek [Xificurk] napsal(a): zobrazit citaci
> 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. zobrazit citaci
> 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

19.11.2014 08:24:51 (#11)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
138
Dne 19.11.2014 20:19, Petr Vejsada napsal(a): zobrazit citaci
> 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.
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

19.11.2014 08:32:20 (#12)
gravatar

jzvc

<jzvc at tpfree.net>
530
Dne 19.11.2014 v 16:29 Petr Vejsada napsal(a): zobrazit citaci
> 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é...).
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). zobrazit citaci
> > No já se spíš orientuju na mazání zjevných duplicit. > > -- > Petr > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz >

19.11.2014 08:39:09 (#13)
gravatar

jzvc

<jzvc at tpfree.net>
530
Dne 19.11.2014 v 20:19 Petr Vejsada napsal(a): zobrazit citaci
> 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?
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. zobrazit citaci
> > -- > Petr > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz >

21.11.2014 12:40:30 (#14)
gravatar

Petr Vejsada

<osm at propsychology.cz>
507
Ahoj, Dne St 19. listopadu 2014 20:39:09, jzvc napsal(a): zobrazit citaci
> 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 zobrazit citaci
> 2) zkontrolujes, zda ma 1-N outer
zda má právě 1 outer zobrazit citaci
> 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? zobrazit citaci
> 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. zobrazit citaci
> 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. zobrazit citaci
> 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. zobrazit citaci
> 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

21.11.2014 01:41:12 (#15)
gravatar

jzvc

<jzvc at tpfree.net>
530
Dne 21.11.2014 v 0:40 Petr Vejsada napsal(a): zobrazit citaci
> 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
=> co je na relaci, ti je jedno, a prepises to tim, co je na ceste? zobrazit citaci
> >> 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. zobrazit citaci
> >> 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. zobrazit citaci
> >> 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. zobrazit citaci
> >> 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 at openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz >

21.11.2014 01:52:17 (#16)
gravatar

Petr Vejsada

<osm at propsychology.cz>
507
Ahoj, On Fri, Nov 21, 2014 at 01:41:12PM +0100, jzvc wrote: zobrazit citaci
> 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. zobrazit citaci
> 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 ... -- Petr

21.11.2014 03:20:19 (#17)
gravatar

Martin Švec - OSM

<osm at maatts.cz>
109
Ahoj, Dne 21.11.2014 13:52, Petr Vejsada napsal(a): zobrazit citaci
> 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 ...
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

« zpět na výpis měsíce