Re: [Talk-cz] Tracer LPIS - drobne relikty puvodnich drivev ymapovanych poli a luk po pretrasovani podle LPIS
Ahoj, (1) Přetrasovávání ručně nakreslených polí je dost velká piplačka, která vyžaduje pečlivost a zabere mraky času. Vím o čem mluvím :-) Takže ji spíš nedoporučuju. Rozhodně se nesmí dělat stylem klikač úderník. Obvykle stará data předem promažu, případně jak psal Marián natrasuju pole s Ctrl a sloučím přes ContourMerge s původním, abych zachoval historii objektu a kredit původního autora pole. Pozor, stará data jsou často zakreslena hodně kreativními způsoby, podle stylu práce autora. Našel jsem i oblast, kde asi mapper trpěl fóbií z uzlů sdílených mezi více cestami. Takže místo aby každé pole mělo jednu cestu kolem dokola a sdílelo uzly s okolím, hranice mezi poli rozsekal na spojité segmenty a ty poslepoval do multipolygonů. (2) Ty odřezky polí co zůstávají po ořezech bychom měli vyřešit :-( Netýká se to jen přetrasování starých dat, ale i přetrasování LPIS polí které mezitím výrazně změnily geometrii. Algoritmy jsou hotové, viz trasování budov. Akorát když jsem zahazování odřezků před rokem zkoušel použít v LPISu, nepodařilo se mi najít vhodná kritéria co ještě zahodit a co prohlásit za regulérní plochu, byť hodně malou. Pokud by se našel dobrovolník, který by si pohrál s testováním a laděním parametrů, můžu mazání odřezků kdykoliv zapojit i v LPISu. Martin Dne 26.1.2016 v 20:38 Pavel Bokr napsal(a): > OK, > > ale prosim nedelat pri tom ty kousky – ja kdyz se koukam kolem sebe tak > postizeno je vetsi uzemi > nez jsem myslel, mame napriklad i utrzky poli kolem luk a naopak: > https://www.openstreetmap.org/#map=18/49.98447/14.02426 > https://www.openstreetmap.org/#map=18/49.99286/13.99835 > https://www.openstreetmap.org/#map=18/49.99137/14.03235 > a ty relikty jsou na celkem velkem uzemi – postupne se to snad opravi, ale > pokud mozno netvorit uz > nove. > > Ano z dnesniho pohledu jsem spatne urcil louku/pole a to by se melo > aktualizovat, ale bez tech > reliktu – to je snad IMHO lepe kdyby nebyla ta hranice uplne presna dle LPIS > ale nebyly v mape ty > relikty (k presnosti ja se snad vetsinu snazil trasovat podrobne a bez > zjednoduseni; snazil jsem > se i dle KM nastavovat posun podkladu). > > > > > Samozrejme souhlasim, ze LPIS je obecne presnejsi – paradoxne zakresy do nej > jsou mnohdy trasovany > podle ortofota cuzk (o kterem se zde vedly diskuze jestli muzeme - nemuzeme). > Takze to co urednik > nebo farmar otrasuje dle ortofota cuzk do LPISu tak pak muzeme pouzivat v OSM > Veselý obličej > > Na druhou stranu ne vse z LPISu je vhodne prejimat za ucelem aktualizace, > protoze tam jsou vedeny > i plochy, ktere nejsou spravne (treba kde uz se stavi nove domy, nebo jsou > spojeny pole, ktere > jsou ve skutecnosti rozdelene mezi s cestou a prikopem a mam je rozdelene i v > OSM – dokud to nekdo > neotrasuje z LPISu) a treba louky se mohou v LPISu kreslit radeji mensi, aby > pak nevznikl > zemedelci problem, ze obhospodaruje mensi vymeru nez vyjde z LPISu (proto > treba se v lukach > vynechavaji “diry” i pro jednotlive stromy i kdyz trava roste i pod stromem a > pro OSM by dle meho > nazoru bylo vhodnejsi louku nechat a dat do ni strom jako bod ze proste > uvnitr te louky roste > strom, urednici ale sleduji v LPIS jine ucely nez sleduje OSM). > > > > > Takze tam kde je mapovano rucne muze byt asi nejvhodnejsi nejaky kompromis, > to co je OK prevzit z > LPIS to co, ale neni vhodne z LPISu prebirat tak to do OSM “netahat”. Je to > ale casove narocnejsi > nez naklikat co LPIS nabizi. Otrasovanim vseho by se neco urcite zpresnilo a > neco urcite > znepresnilo – resp. zavedly by se do OSM i vetsi chyby nez jsou nepresnosti > ve soucasne rucne > vznikle mape. K tomu je ale treba osobni znalost nebo si konkrolovat > spravnost a aktualnost LPIS > podle ortofot. > > Pri takovem kompromisnim mapovani (vzit si z LPISu jen to dobre) se ale ne > vsechno co je v LPISu > prenese do OSM a nebylo by dobre aby tam pak nekdo dodelal i ty chybejici > prvky z LPISu co treba > nekdo zamerne netrasoval, aby do OSM nevnesly vetsi nepresnosti. Nebo se muze > stat ze se neceo > pretrasuje z LPISu, pak se rucne upravi geometrie aby byla v OSM byla > spravnejsi nez v LPISu, ale > pokud nekdo za nejaky cas opet provede pretrasovani tak to rucni vylepseni > OSM oproti LPISu zrusi. > > Ve vysledku to vychazi tak, ze pretrasovani rucni mapy (pokud byla delana > podrobne) to chce trochu > vice peclivosti, aby to byla opravdu aktualizace pokud mozno jen k lepsimu. > To je pak k reseni > vice vez jen to jestli nahodou nezustavaji relikty nebo diry. > > > > Kdyz na ten LPIS koukam tak treba u velkych celku slozenych z vice dilcich > casti nevim jestli neni > porad lepsi mit v OSM velke pole jako jeden rucne mapovany celek bez napojeni > na LPISu, podle > LPISu treba jen rucne upravit – zpresnit vnejsi hranici (tedy pokud pole neni > fakticky preruseno a > je to jeden celek – jedno dilci pole tesne sousedi s druhym a je to porad to > same >
Re: [Talk-cz] Tracer LPIS - drobne relikty puvodnich drive vymapovanych poli a luk po pretrasovani podle LPIS
Dne 26.1.2016 v 23:09 Petr Holub napsal(a): >> jeste by hodne pomohlo efektivite tohoto procesu, kdybychom umeli >> "odecitani" polygonu: >> v podstate "jen" vyrazne zefektivneni toho procesu s ContourMerge. tam >> je problem, >> ze kdyz dany les navazuje na nekolik poli (typicky takove ty >> "roznudlovane pole" >> na Jizni Morave), tak clovek musi pres ContourMerge delat jeden po >> druhem, casto >> se blbe hledaji ty koncove body, atd. Pokud by se ten les dal >> pretahnout tak, aby >> vsechna ty pole prekryl a pak se jen ta pole odecetla, tak by to byla >> velka pomoc. >> >> >> >> >> >> No podpora geometrických operací v Traceru, díky Martinovi, je. Jak moc >> složité by bylo >> upravit Contour Merge netuším.Ale asi to bude nad mé síly. >> >> >> >> >> Ale můžeš to simulovat tak, že si ten les nejprve vytáhneš do polí a až pak >> pole přetrasuješ. > Jo, ale problem je s existujicimi poli - smazat vsechno, roztahnout les > a pak pretrasovat (ale zase by tim clovek stoupal ve statistikach > zmen ;o))) ). Pokud bychom to meli i jako samostatnou funkcionalitu > na existujicich objektech, tak by to bylo super - mozna by to nemuselo > byt tolik prace, kdyz uz to vlastne v Traceru mas. > >> Jeste dalsi vylepseni by pak byl "rozliv" polygonu, ktery by ho >> automaticky dotahl >> ke vsem dalsim polygonum, ktere se s nim dotykaji alespon ve dvou >> mistech. Tim by >> se resily takove ty zapomenute "zdibce", kterych si clovek kolikrat ani >> nevsimne >> a pak na ne ContourMerge neaplikuje. >> >> >> >> >> Který polygon by se dotáhnul kam? > To by chtelo rozmalovat a presneji dorozmyslet jednotlive pripady, ale > zhruba takto (nerucim za spravny desing, uz mam ponekud unavenou hlavu): > stav 1: vyberu rozlivany objekt (uzavrena cesta) - editor prejde do stavu 2 > stav 2: editor postupne proiteruje vsechny diry, ktere jsou tvorene: > a) plochami (uzavrenymi cestami) ktere se rozlevaneho objektu dotykaji > ve dvou bodech, ale mezi temito dvema body existuje po neblizsich > cestach (nikoli nutne nejkratsi ve smyslu poctu bodu, ale nejkratsi > ve smyslu delky segmentu - to by melo fungovat, musi se ale zkontrolovat, > ze plocha sama sebe nekrizi) nesdileny bod na jedne nebo druhe ceste > b) na sebe navazujicim plochami (navazujici = sdili aspon 1 bod), z nichz > krajni plochy sdili s rozlivanym objektem alespon jeden bod - a opet > po nejkratsich cestach je tam 1 nebo vice nesdilenych bodu > stav 3: proiteruje vsechny diry a nabidne je k zaceleni uzivateli (zobrazi > diru a zepta se "zacelit - ano/ne" Na tohle téma jsme si psali tuším loni na jaře. IMHO tenhle postup je jednodušší, praktičtější a máme pro něj v Traceru spoustu kódu hotovou: (1) Vybrat rozlívaný objekt A, zapnout funkci rozlivu. (2) Editor přejde do režimu "freehand výběru". (3) Myší zhruba nakreslit "bramboru" B kam všude se má objekt A rozlít, s dostatečnými přesahy přes okolní objekty včetně objektu A. (4) Spočítat sjednocení polygonů A + B = polygon C. (5) Ořezat polygon C ořezovou funkcí která je v Traceru. (6) Vrátit se do bodu (2), nebo opustit funkci rozlivu přepnutím na jinou funkci JOSM. Tím zakreslením přibližné plochy B kam se má rozlívat odpadá problematická detekce "děr" a "průlivů do nekonečna". Není ani potřeba dotazovat se na každou díru, roztahování plochy se dá udělat na pár rychlých čmárnutí myší. Základní koncept je jednoduchý, ale cítím tam spoustu drobných zádrhelů, které se budou muset ošetřit a sežerou nejvíc času :-) Taky ta funkce nemůže být vyloženě univerzální -- musí existovat předdefinované sady tagů, které okolní polygony mají rozliv ořezávat a které se mají ignorovat. Sežeň si studenta který to odprogramuje, rád mu poradím, ale sám na to čas nemám. Hlavně na to ladění zádrhelů. Martin > > Petr > > > > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Multipolygony lesů - převod starého tagování na nové
Ale tentokrát to nejsem já :-) Pokud si vzpomínám, tehdy jsem z toho tiše vycouval, protože se vyskytla řada nejasných situací a nebylo jasné, jestli něco nerozbijeme. Víc viz thread. Navíc změn multipolygonů by bylo tolik, že to zavánělo porušením pravidla "používejte nový styl tagování ale neopravujte hromadně starý". Overpass query jsem taky nedal. Martin Dne 7.12.2015 v 21:12 Petr Vejsada napsal(a): > Ahoj, > > už zase? :-) > > thread začíná > https://lists.openstreetmap.org/pipermail/talk-cz/2014-September/010728.html > > Ale třeba nová aktivita bude úspěšnější. Odkazuji dle pravidla, že před > každou > vědeckou prací je nutné prostudovat dostupnou literaturu :) > > -- > Petr > > Dne Po 7. prosince 2015 20:41:42, Marián Kyral napsal(a): > >> Ahoj, >> jak se díváte na hromadnou opravu tagování multipolygonů. Z varianty >> landuse=forest na outer hranici(ích) na variantu landuse=forest na relaci? >> Zdá se, že některé rendery mají problém v případě, že outer roli má více >> cest: >> http://www.geocaching.cz/topic/25018-offline-turistick%C3%A1-mapa-pro-androi >> d/page-31#entry516431 Sice bychom mohli říci, že tohle je problém těch >> rendererů, ale vzhledem k tomu, že je to tagování zastaralé, bylo by asi >> lepší to opravit. >> >> A dokáže někdo sestavit overpass query, která by našla všechny lesní >> multipolygony , které na relaci nemají tag landuse, ale mají jej na >> outer cestě? Mně se to nějak nedaří. >> >> Marián > > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] LPIS import
Ahoj,
za prvé, souhlasím a podepisuji odpovědi od Mariána :-)
On 1.8.2015 07:47, Marián Kyral wrote:
Ahoj,
Dne 1.8.2015 v 03:05 Jakub Těšínský napsal(a):
Paráda, děkuju za odpovědi. Pár nejasností ještě mám
- V případě nejasností kouknout na nejnovější ortofoto. CUZK nebo
mapy.cz. Dle všeho ta pole vznikají na základě cuzk:ortofoto.
já mapuju většinou tyhle věci jen přímo z terénu, takže ortofoto moc
nepotřebuju. Mimochodem mapy.cz jsou volný zdroj?
Volný ne. Ale ověřovací by být mohl. Myslím teda letecké mapy od
seznamu. Ne přímo jejich mapy.
Jako zdroj pro mapování v žádném případě. Ale když je rozpor mezi volnými
zdroji, pomůže ti v rozhodování co z nich (ne)použít.
- Co je LPIS id není jasné. Někdy se to pole změní a ID zůstane, jindy
je nahrazeno novým.
Zvědavost mi nedá, proč ho teda máme v OSM? :)
Protože jsme předpokládali, že jej budeme potřebovat. Jak probíhají
aktualizace jsme nevěděli. Stačí si dohledat patřičnou diskuzi tady v
archivu.
- Pole neslučovat. Na každém může být za rok něco jiného. Třeba travní
porost. To se řešilo už při importu.
Mě se jedná napři o tuto situaci
http://osm.org/go/0Jaa4p5YF-?layers=Nm= značka ukazuje na mezeru mezi
loukou 12908950 a 12908957. V realitě tam nic takového není. Možná že
někdy tou mezerou vedla cesta, ale teď je to jedna louka. Kdyby to
nebylo naimportování z LIPS ale někdo to tam dal ručně dle
skutečnosti, bez skrupují ty dvě louky spojím a zlepším mapu. Nevím
jak ale spojit ref tagy, kterým nerozumím, takže to raděj nechám bejt,
abych něco nezkazil. Bohužel tím mapa přichází o edity (tohle je efekt
který je reálný, viz ten americkej import). Chtělo by to prostě nějaký
pokyn jak tohle řešit. Např tím, že kdykoli budu editovat něco s lips
refem tak ten ref smažu aby to nevypadalo, že můj edit je z lips
zdrojů. Nevím. Právě proto jsem se ptal jesli ten lips ref je na něco.
V tomto případě bych obě ID zahodil. Ale ostatní mají třeba jiný názor
(ale asi jsou na dovolené ;-) ).
A mimochodem, to že tam momentálně není žádná cesta ještě nic neznamená.
Může se tam zase objevit.
Musíš si zapnout LPIS WMS vrstvu :-) Pak uvidíš, že mezeru mezitím opravili
přímo v LPISu, stačilo pole přetrasovat a doladit škvíru (což jsem udělal).
wms:http://eagri.cz/public/app/wms/plpis.fcgi?language=engFORMAT=image/pngTRANSPARENT=TRUEVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLAYERS=LPIS_FB_KULSTYLES=SRS={proj}WIDTH={width}HEIGHT={height}BBOX={bbox}
- Malá editace polí není problém, ale může se stát, že o úpravy přijdeš,
když to někdo přetrasuje a nevšimne si, že tam je editace. Typicky, dvě
velká pole, která se v LPIS sloučila do jednoho.
Nerozumím? Mě přijde že právě malé editace tvatu podle polí by se při
jakémkoli reimportu měly respektovat, protože nejspíš mají nějaký
důvod. To se nedělá?
Myslel jsem to tak, že ten, kdo bude dělat aktualizaci toho pole, si
nemusí všimnout tvých změn,
Taktak, bez zkoumání historie editací je IMHO nereálné si ručních změn
všimnout. LPIS pole mají podrobnou geometrii samy o sobě a rychle se mění přímo
v LPIS registru. Je to krásně vidět u starších natrasovaných polí vůči LPIS WMS
vrstvě. Proto je potřeba při přetrasování přemýšlet a porovnávat co nejvíc
zdrojů.
- Na editaci doporučuji JOSM s pluginy: Tracer-testing, ContourMerge, a
utilsplugin2 (hlavně příkaz: Nahradit geometrii)
Mám v plánu jednou nějaké základní tipy na editaci sepsat, ale znáš to.
Jo znám :) ... třeba ti odpovědi na moje otázky poslouží jako základ
té wiki stránky :)
No můžeš začít tím, že tu stránku s otázkami vytvoříš :-D
Marián
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
Martin
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Správný průběh úprav ploch po importu polí a luk
Dne 30.6.2015 v 11:45 Jiří Sedláček napsal(a): Ahoj, dobrý den, koukal jsem na mě známá místa a nevím, jak mám případně postupovat při nějakých úpravách - možná to lehce souvisí s dírami po sloupech, ale tohle jsou spíš remízky a sem tam nějaké kopečky s dvěma či třemi stromy. http://www.openstreetmap.org/#map=16/49.2527/15.9036 - místo Co s tím, mám do těch děr “přikreslit” les? Patří tam něco? Mám odstranit ty “díry”? Určitě neodstraňovat, podle ortofoto tyhle díry dávají smysl (skalky, křoví, stromy). Tam kde to znám (nebo kde je to poznat z bingu) díry taguju jako natural=scrub, natural=grassland, natural=wood, natural=heath, atd., podle charakteru porostu. Klasický hospodářský les (landuse=forest) se na to obvykle nehodí, viz https://wiki.openstreetmap.org/wiki/Cs:Forest a nedávná diskuse zde. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Dalsi preklady wiki a znaceni lesa
Ahoj, já používám natural=wood jako mezistupeň mezi natural=scrub a normálním lesem. Tj. kde jsou sice vzrostlé stromy, ale zároveň to není klasický obhospodařovaný les. Např. pruhy stromů s křovinatým podrostem kolem vodních toků mezi poli, větší neudržované remízky v polích, ostrůvky stromů v krasových oblastech apod. Pokud se přístup 3 rozšíří kromě pralesa i na neobhospodařované porosty stromů bez těžby dřeva, měl bych se do definice vejít ;-) Martin Dne 2.6.2015 10:17, Dalibor Jelínek napsal(a): Ahoj, prelozili jsme s Vopem dalsi wiki stranky, tak je nabizime k precteni a pripadne korekci. Zejmena zajimava je uvaha na tema znaceni lesa: https://wiki.openstreetmap.org/wiki/Cs:Forest Nevim, zda se da rici, ze v CR pouzivame zasadne popsany pristup 3, tedy, ze obecne vsechny lesy jsou landuse=forest a jen pralesy a lesy bez tezby dreva jsou natural=wood. Pokud to nekdo znaci jinak, nebo vi o jinem znaceni, tak at se prosim ozve, jinak bych tohle doporuceni dopsal na ceskou wiki jako standard pro CR. https://wiki.openstreetmap.org/wiki/Cs:Tag:landuse%3Dforest https://wiki.openstreetmap.org/wiki/Cs:Tag:landuse%3Dfarmland https://wiki.openstreetmap.org/wiki/Cs:Tag:landuse%3Dfarmyard https://wiki.openstreetmap.org/wiki/Cs:Tag:landuse%3Dfarm https://wiki.openstreetmap.org/wiki/Cs:Tag:landuse%3Dgarages https://wiki.openstreetmap.org/wiki/Cs:Tag:landuse%3Dgrass https://wiki.openstreetmap.org/wiki/Cs:Tag:landuse%3Dgreenhouse_horticulture https://wiki.openstreetmap.org/wiki/Cs:Tag:landuse%3Dindustrial https://wiki.openstreetmap.org/wiki/Cs:Tag:landuse%3Dlandfill https://wiki.openstreetmap.org/wiki/Cs:Tag:landuse%3Dmeadow Dalibor ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] LPIS - objem dat, zjednodušení kontur
Ahoj, Dne 2.6.2015 16:52, Petr Hluštík napsal(a): Dobrý den / ahoj, viděl jsem v archívu několik diskusí na téma LPIS... Klobouk dolů před vámi systematickými mapaři. Jsem asi 3 roky amatérským drobným přispěvatelem do OSM (POI, polní/lesní cesty/horské chodníky z GPS, výjimečně oprava hranic lesa, atd.). Používám OSM offline v OsmAnd-u, nedávno jsem si všiml, že velikost stahované mapy ČR silně narostla (o 30%?). Možná je to importem LPIS? Určitě je to importem LPIS. :-) Však taky mapa konečně vypadá jako mapa a ne ostrůvky života na poušti. (Jo, připouštím, někde jsou ta políčka až moc rozdrobená.) Proč se ptám - při kreslení cest v JOSM vidím, že hranice polí jsou na mé gusto velmi (zbytečně) detailní, body jsou i jen několik m od sebe na rovném úseku, takže jsem několikrát neodolal pokušení jejich hranice zjednodušit (Shift-Y). Je to OK? A pokud ano, nebylo by rozumné ty hranice zjednodušit u všech polí při importu? Podle mne by počet datových bodů z LPIS klesl na polovinu a příslušně se zmenšila velikost mapových dat českého venkova... Vycházím ze své intuice, že účelem OSM není ani legální přesnost hranic (na to je asi katastr či RUIAN), ani statistická přesnost rozloh (na to jsou asi původní resortní databáze z kterých se importuje)?? Já pořád beru mapu hlavně jako podklad pro cestu odněkud někam a případně náhled, co je kolem... Zbytečně detailní je subjektivní :-) V případě LPIS polí se hustota liší i podle toho, kdy byly polygony natrasované. Tracer původně zbytečné body nemazal, zhruba od Vánoc už polygony zjednodušuje. Tolerance pro odstraňování uzlů je zas subjektivní, experimentálně jsem došel k odchylce max. 25 centimetrů a/nebo úhlové změně Pi/40. Při těch číslech Tracer smaže spoustu bodů na rovných úsecích ale přitom neničí oblouky, neslepují se pole mezi kterými je metrová pěšina atd. Zjednodušování hranic je OK, ale doporučuju (osobní názor) snížit maximální odchylku SimplifyWay, což jsou tuším 3 metry. To je IMHO na dnešní dobu hrozně moc. Používám kolem 0.5 metru a míň, podle okolností. Martin Díky za komentář, Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] LPIS - objem dat, zjednodušení kontur
Dne 2.6.2015 18:01, Petr Vejsada napsal(a): Ahoj, Dne Út 2. června 2015 16:52:51, Petr Hluštík napsal(a): viděl jsem v archívu několik diskusí na téma LPIS... Klobouk dolů před vámi systematickými mapaři. též smekám před LPIS mapery. Nechci se vyjadřovat k úhlům, počtu bodů atd., ale k tomu dělat zjednodušení jen pro zjednodušení samotné, tedy bez jiného důvodu. Ano, zmenší to objem dat v DB, ale bude to generovat (IMO zbytečný) tok změnových dat, takže já bych to nechal spíš na případné retrasování změn podle nových parametrů traceru, a to tehdy, kdy se užití pole zjevně změní. Ano, plošné zjednodušování LPISu je nesmysl. Obzvlášť z důvodu zmenšení dat. Pochopil jsem dotaz tak, jestli korigovat LPIS polygony v rámci místního mapování. Což já třeba běžně dělám. Samozřejmě s rozumem, tam kde vidím že Tracer neodvedl dobrou práci a kde to neuškodí přesnosti mapy. Pokud se kvůli zjednodušení posune hranice mezi dvěma kilometrovými lány o metr, sloučí pět uzlů nalepených u sebe, nebo odstraní nesmyslný ocásek, nevidím problém. Pokud kvůli tomu zmizí pěšina mezi poli, posune se přesně zaměřený plot, nebo poškodí pečlivě vyvedená kontura louky, je to chyba. Prostě úprava musí mít smysl a nemělo by dojít ke ztrátě užitečné informace. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Nove preklady wiki
On 29.5.2015 23:56, Marián Kyral wrote: Dne 29.5.2015 v 23:21 Martin Švec - OSM napsal(a): Ahoj, koukám do Osmose a co nevidím... Najednou se mu nelíbí moje noexit=no tagy. Po chvíli jsem našel, že v [1] byla hodnota noexit=no opravdu už dávno prohlášena za zastaralou, hmmm. Z diskuse na wiki není ten závěr tak jednoznačný, nicméně anglická verze [2] se o možnosti noexit=no taky nezmiňuje. Tušíte někdo kudy se dostávají pravidla do Osmose? Pokud je všeobecná shoda že noexit=no je zastaralé, měla by se upravit i česká wiki. A já se naučím používat jen fixme=continue :-) Commit na githubu: https://github.com/osm-fr/osmose-backend/commit/faf16aebcb2f26e34be04f891504ad1bce02ebb3 A Trac je tady: http://trac.openstreetmap.fr/ticket/608 (bohužel většina je francouzky :-( ) Marián Dík za nasměrování. Chybu noexit=no Osmose tahá přímo z wiki Deprecated_features, viz např. https://github.com/osm-fr/osmose-backend/commit/5acae8f715338f57277265a667da15d1d1c61207 V květnu proběhl úklid stránky Deprecated_features, noexit=no se tam dostal 18.5. prý ze seznamu abandoned a inactive tags: http://wiki.openstreetmap.org/w/index.php?title=Template:Deprecated_featuresdiff=prevoldid=1180184 Dále, nerealizovaný návrh pravidel v JOSM (a výživná diskuse na tagging listu :-)): https://josm.openstreetmap.de/ticket/9895 https://lists.openstreetmap.org/pipermail/tagging/2014-April/017247.html Můj osobní závěr: noexit=no by se neměl používat, preferuje se fixme=continue. Tag noexit=yes na cestách je dlouhodobě sporný, líbí se mi současný výklad na české wiki. Doporučuji upravit wiki ve smyslu, že noexit=no je zastaralé a pro označení nedomapované cesty se má použít pouze fixme=continue na posledním známém uzlu. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] LPIS: Tráva na orné, Úhor, Jiná trvalá kultura
Dne 28.5.2015 07:46, Marián Kyral napsal(a): -- Původní zpráva -- Od: Pavel Machek pa...@ucw.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 27. 5. 2015 23:34:09 Předmět: Re: [Talk-cz] LPIS: Tráva na orné, Úhor, Jiná trvalá kultura On Wed 2015-05-27 21:56:35, Marián Kyral wrote: Ahoj, v LPIS se objevily nějaké novinky a chtěl jsem se poradit, jak to nejlépe namapovat. A pokud máte i další, nenamapované kultury, tak je přidejte. Martin mi poslal nějaké patche a koncem týdne bych chtěl vydat aktualizovanou verzi Traceru. Takže prozatím známé novinky: *tráva na orné [1]* - tohle si představuji jako třeba jetel na poli - pořád to je pole, jen se pěstuje tráva - navrhuji /landuse=farmland, crop=grass/ No nevim; nebylo by lepsi landuse=meadow, note=meadow on farmland? Jak v terenu poznam jestli je to louka nebo trava na orne pude? Těžko říct. Asi stejný případ je, když zemědělec zorá louku a na rok dva tam něco zasadí. Koukám do zdrojáků, trávu na orné už teď tagujeme jako landuse=farmland, crop=grass. Ono v dlouhodobým horizontu tam pravděpodobně častěji bude pole než louka :-) *úhor [2]* - - Dočasně neobdělávané pole - mapování /landuse=farmland/, ale ještě by to asi chtělo něco k tomu.* crop=none? crop=not_now? /crop=no/ vypadá docela slibně. Souhlasím s landuse=farmland, crop=no. Zůstává nám jiná trvalá kultura, ale těch jsem viděl tak málo, že jsem nevypozoroval co přesně to má být. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] LPIS: Tráva na orné, Úhor, Jiná trvalá kultura
Dne 28.5.2015 08:01, Marián Kyral napsal(a): -- Původní zpráva -- Od: Petr Holub ho...@ics.muni.cz Komu: 'OpenStreetMap Czech Republic' talk-cz@openstreetmap.org Datum: 28. 5. 2015 7:01:55 Předmět: Re: [Talk-cz] LPIS: Tráva na orné, Úhor, Jiná trvalá kultura Ahoj, u úhoru by možná šlo crop=none. Mimochodem, plánuje se nějak automaticky pole aktualizovat? Při dočišťování importu jsem si totiž všiml, že spousta LPIS polí zmapovaných před nějakou dobou už s podklady ani tracerem nesedí. coz mne vede na otazku, jestli je lepsi zdroj dat LPIS nebo RUIAN pro potreby OSM. Jak moc je LPIS rocni zalezitost, kdy se rok od roku meni vyuziti pudy podle planu konkretniho zemedelce i s tim, ze se rok od roku mohou lisit tvary poli? Ten RUIAN by mohl byt z tohoto pohledu stabilnejsi, kdyz se jedna o vlastnictvi. Dle RUIAN existuje hafo polí na který ve skutečnosti už hodně, hodně dlouho stojí rodinné domy. LPIS je v tomto značně přesnější. U tech automatickych aktualizaci podle LPISu bych videl jeste jeden problem - tam, kde na sebe navazuji pole a les ci jine podobne vyuziti ploch bude tezko automaticky urcit, jestli v pripade zmenseni pole se ma posunout i hranice te druhe plochy nebo zda se maji oddelit. Pri zvetseni pole bych predpokladal, ze se to posunout ma, alespon v pripade lesa. Premyslel nekdo nad temito aspekty a ma napady, co s tim? Přemýšlel a moc to na automatickou aktualizaci nevidím. Nemáme možnost z LPIS získat informace jen o změnách. Vždy by jsi musel stahovat všechno a pak dělat složité porovnání dat s OSM. A udělat nějaký chytrý algoritmus na správnou automatickou editaci polí bude docela výzva. Možná na několik diplomových prací ;-) Raději bych zůstal u Traceru a ruční aktualizace. Přijde mi to lepší. Hned vidím, jestli se tvar pole změnil, jak moc a jestli má cenu se tím vůbec zabývat. Jediné, co nepoznám je změna z pole na louku a naopak. Ale to podle mně není až tak velký problém. Doteď jsme na tom byli hůř. Někdo před léty zaznačil pole a ono tam už třeba dávno není, ale nikdo to neopravil. Souhlasím, už jsem pár aktualizací dělal a pár cizích opravoval. Ty změny v LPISu bývají dost divoké. Velká pole se rozpadají na menší, malá slučují dohromady, objevují se a mizí díry (stožáry, remízky, jezírka), mění se geometrie. Někdy z LPISu bůhvíproč zmizí půlka pole i když z terénu vím že se nic nezměnilo (skončily dotace?). Orientovat se podle LPIS ID taky nefunguje, ID se občas mění i při drobné změně geometrie. Plus třeba já u spousty polí dělal ruční zásahy do geometrie (chybějící remízek, špatně navazující hrany, atd.), které by se automatickou editací zlikvidovaly. Takže aktualizace bych nechal na inteligenci místních mapperů, kteří si udržují své oblasti zájmu. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Nove preklady wiki
Jo, přesně tak. Uzel s noexit=yes je pro mě signál, že dál nenavazuje žádná mapovatelná pěšina/cesta. Kombinaci noexit=no + fixme=continue beru naopak jako výzvu, abych tady pokračoval v mapování. Martin Dne 27.5.2015 v 9:31 Dalibor Jelínek napsal(a): No, asi jo, ja bych to tak značil. Myslím, že hlavní smysl této značky je sdělit, že cesta skutečně končí a že se nejedná o případ, že by už nebyl čas/možnost cestu dále zmapovat. Dalibor *From:*Marián Kyral [mailto:mky...@email.cz] *Sent:* Wednesday, May 27, 2015 9:08 AM *To:* OpenStreetMap Czech Republic *Subject:* Re: [Talk-cz] Nove preklady wiki Takže takto mám značit všechny nájezdy na pole a polní cesty, které končí u poslední louky/ posledního pole? Tam taky pěšiny nebývají. Marián -- Původní zpráva -- Od: Dalibor Jelínek dali...@dalibor.cz mailto:dali...@dalibor.cz Komu: 'OpenStreetMap Czech Republic' talk-cz@openstreetmap.org mailto:talk-cz@openstreetmap.org Datum: 27. 5. 2015 9:02:38 Předmět: Re: [Talk-cz] Nove preklady wiki Myslím, že správná interpretace je, že se dále z bodu nedá pokračovat z hlediska mapování, tedy že tam není už dále ani pěšina, která by šla zmapovat. Pěšky projdeš skoro všude, to by ta značka neměla moc smysl. Dalibor *From:*Marián Kyral [mailto:mky...@email.cz] *Sent:* Wednesday, May 27, 2015 8:55 AM *To:* OpenStreetMap Czech Republic *Subject:* Re: [Talk-cz] Nove preklady wiki Teď ještě opravit ikonu v JOSM - značka slepé ulice hodně mate. Nějaký nápad na vhodnou ikonku? A ještě mám nejasnost ohledně definice skutečně již dále nelze pokračovat. Vyplývá mi z toho, že tag noexit by se měl dávat jen v případech, kdy cesta končí ve strži, na vysokém břehu nebo skále a v opravdu hustém lese. Ve všech ostatních případech bych měl být schopen pokračovat pěšky i v případě, že tam není pěšina. Je to tak? Marián -- Původní zpráva -- Od: Dalibor Jelínek dali...@dalibor.cz mailto:dali...@dalibor.cz Komu: 'OpenStreetMap Czech Republic' talk-cz@openstreetmap.org mailto:talk-cz@openstreetmap.org Datum: 27. 5. 2015 8:40:19 Předmět: Re: [Talk-cz] Nove preklady wiki Cau, to jsi napsal hezky, myslim, ze je to takto jasne. Dalibor *From:*Petr Vozdecký [mailto:v...@seznam.cz] *Sent:* Tuesday, May 26, 2015 11:27 PM *To:* OpenStreetMap Czech Republic *Subject:* Re: [Talk-cz] Nove preklady wiki Ahoj, aplikováno. Zatím ale zůstává na wikistránce u tohoto tagu ikona Way nepřeškrtnuta. K přeškrtnutí zatím nemám podporu komunity (viz historie EN hesla, kde škrtanec několikrát měnili). vop -- Původní zpráva -- Od: Petr Holub ho...@ics.muni.cz mailto:ho...@ics.muni.cz Komu: 'OpenStreetMap Czech Republic' talk-cz@openstreetmap.org mailto:talk-cz@openstreetmap.org Datum: 26. 5. 2015 13:26:04 Předmět: Re: [Talk-cz] Nove preklady wiki Ahoj, V teto souvislosti upozornuji na heslo Cs:Key:oneway, kde bych potreboval rozhodnout (dopresnit), jak je to s uzivanim tagu na cestach (Ways). Ruzne prameny to popisuji jinak a kontrolni nastroje OSM tento tag na ceste hodnoti jako chybu... dle meho nazoru je to rozumne davat jen na koncove body cesty, ktere uz nikam dal nevedou - protoze to reflektuje realitu z tohoto koncoveho bodu cesty se jiz nikam neda pokracovat. Navic to dobre funguje i na slepem stromecku, protoze tam je otazka, kdyby se to znacilo i na cestach, co by se melo znacit - jestli i kmen (ktery vede jen do tech slepych vetvi), nebo jen koncove vetvicky. Navic bych teda jeste na wiki uvedl dve veci: - ma smysl to pouzivat napr. i u lesnich cest, kdyz odtud dal uz cesta nikam nevede; takovych lesnich cest jsou spousty a pomaha to resit situaci mam sem jit mapovat nebo ne? - explicitne bych uvedl tu dvojkombinaci tagu noexit=no fixme=continues ted to tam uz popsane je jako soucast odstavce, ale prislo by mi lepsi, kdyby to uzivatele prastilo do oci a nemusel to hledat. Diky, Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org mailto:Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz = ___ Talk-cz mailing list Talk-cz@openstreetmap.org mailto:Talk-cz@openstreetmap.org
Re: [Talk-cz] Mapování ilegálního sportoviště
Ahoj, to mi něco připomíná: http://www.openstreetmap.org/way/129905013 :-) Můj osobní názor: pokud taková věc v terénu objektivně existuje, aktivně se využívá, mapper ji najde a cítí potřebu zanést do OSM, nejsem proti, přestože sám bych to asi nemapoval. Morální aspekty jsou málokdy černobílé. Lákají se tím další bikeři, nebo varují nevinní turisti, aby si dali pozor na překážky? Vymažeme Macochu, abychom k ní nepřitahovali sebevrahy? ;-) Nějaké tagování de-iure stavu by bylo fajn, akorát nevím jaké. Druhá věc je, že hřiště tam jednoznačně nemá co dělat. Tedy pokud cítím občanskou povinnost to řešit, nahlásím vlastníkovi. Když tam pošle bagr a skoky zmizí, s radostí dirty vymažu z OSM. Tož asi tak. Martin Dne 19.5.2015 v 12:02 Petr Vozdecký napsal(a): Ahoj, prosím o radu či názor ve věci mapování ilegálního sportoviště. Ve skutečnosti jde o svépomocí vybudovaný terén pro BMX kola (různé skoky apod.), který se ale nachází v prostoru Přírodní památky, kde je explicitně (i na tabulích přímo u sportoviště) vjezd na horském kole z důvodu ochrany rostlin zakázán. Pomineme-li poněkud zcestnou argumentaci samotných jezdců, že BMX není horské kolo (!), vzniká následující situace: 1) sportoviště na místě je a je vysoce specifické (k jinému účelu než pro BMX jej nelze použít) 2) sportoviště se (ke svému účelu) nesmí de-iure provozovat 3) majitelem pozemku je patrně obec nebo stát a nelze předpokládat, že by sportoviště jakkoliv hájil Otázky: 1) zakreslit takové sportoviště do mapy? Jak? 2) mapa by měla zachycovat stav de-facto, ale zachycuje běžně i stav de-iure (acces=*) 3) pokud mapovat, pak by bylo na místě zmapovat každou díru v plotě do placeného areálu včetně cesty, nebo cestu k místu, kde se dá plot přelézt... 4) před lety navrhovaný tag illegal=yes zatím nemá žádnou širší podporu a dle taginfo se v OSM vůbec nevyskytuje vop ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] nadmořská výška
Ahoj, mám dojem že mícháš dvě věci. Na vytvoření výškového profilu potřebuješ znát nadm. výšku celoplošně a s vysokou hustotou bodů. To nikdy v OSM nebude, od toho jsou SRTM data. Do OSM patří místopisné údaje typu vrchol hory, výška uvedená na rozcestníku atd. atd. Ale z těch zas neuděláš použitelný výškový profil. Jestli chceš běhat po okolí a každých 50 metrů si zaznamenat výšku, nic ti nebrání, ale do OSM to nepatří a hlavně raketoplány to dávno udělaly za tebe ;-) Martin Dne 13.5.2015 v 12:06 Radek Kuznik napsal(a): Cau, to co pises, tak je spis na hory apod. ne? Myslím spíš něco, aby se udělal výškovej rastr nebo jak to nazvat. Uvidím kopeček, zjistím výšku a zapíšu do mapy. a tak udělám okolí... a pak si z toho může někdo vytáhnout body a udělat si z toho výškový profil. R. Dne 13. května 2015 9:48 Dalibor Jelínek dali...@dalibor.cz mailto:dali...@dalibor.cz napsal(a): Ahoj, nejsme si jist, zda správně chápu tvůj dotaz. Nadmořská výška se dá normálně přidávat klíčem ele= http://wiki.openstreetmap.org/wiki/Key:ele k jakémukoliv uzlu na mapě. Dalibor *From:*Radek Kuznik [mailto:ra...@aktovka.net mailto:ra...@aktovka.net] *Sent:* Wednesday, May 13, 2015 9:26 AM *To:* OpenStreetMap Czech Republic *Subject:* [Talk-cz] nadmořská výška Zdar, řeší se nějak v OSM výškový body(nadmořská výška) v určitých místech a nebo pořád nic? Aby se pak třeba dal udělat později výškový profil apod? R. ___ Talk-cz mailing list Talk-cz@openstreetmap.org mailto:Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Rýmařov - parcela vs. budova
Dne 12.5.2015 v 18:27 Marián Kyral napsal(a): Medvídek? To měl být brouček :-) Ehm? :-)) No prostě ta neurčitá havěť na konci řádku RUIAN id ;-) Martin Marián Dne 12.5.2015 v 17:12 Martin Švec - OSM napsal(a): To je chyba v datech RUIANu, zdaleka ne první ani poslední. Hlásit to jde třeba v pluginu PointInfo, ikona medvídka vede do evidence chyb co udržuje Petr Vejsada. Viz thread https://lists.openstreetmap.org/pipermail/talk-cz/2014-November/011088.html Martin Dne 12.5.2015 v 16:30 Lukas Novotny napsal(a): Ještě náhled v příloze. Lukáš Dne 12. května 2015 16:24 Lukas Novotny lenoc...@tiscali.cz mailto:lenoc...@tiscali.cz napsal(a): Narazil jsem na menší chybku ve vrstvě Český RUIAN budovy kdy v Rýmařově u pozemku 1460/1 má budova stejný tvar jako pozemek, Asi se někdo uklikl a zakreslil to do chybné vrstvy. Není to chyba importu z ČUZK do používané vrstvy z tile.poloha.net http://tile.poloha.net? Lze to nějak nahlásit u ČUZK? S díky Lukáš ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Rýmařov - parcela vs. budova
To je chyba v datech RUIANu, zdaleka ne první ani poslední. Hlásit to jde třeba v pluginu PointInfo, ikona medvídka vede do evidence chyb co udržuje Petr Vejsada. Viz thread https://lists.openstreetmap.org/pipermail/talk-cz/2014-November/011088.html Martin Dne 12.5.2015 v 16:30 Lukas Novotny napsal(a): Ještě náhled v příloze. Lukáš Dne 12. května 2015 16:24 Lukas Novotny lenoc...@tiscali.cz mailto:lenoc...@tiscali.cz napsal(a): Narazil jsem na menší chybku ve vrstvě Český RUIAN budovy kdy v Rýmařově u pozemku 1460/1 má budova stejný tvar jako pozemek, Asi se někdo uklikl a zakreslil to do chybné vrstvy. Není to chyba importu z ČUZK do používané vrstvy z tile.poloha.net http://tile.poloha.net? Lze to nějak nahlásit u ČUZK? S díky Lukáš ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] Retrasování LPIS ve zmapovaných oblastech
Ahoj, při čištění překryvů LPIS polí (díky Petrovi Vejsadovi za data) jsem si všiml, že mají společný původ: pokusy o aktualizaci (retrasování) už existujících polygonů ve zmapovaných oblastech. Pokud se o aktualizaci pokoušíte, prosím postupujte s maximální opatrností! Zejména věnujte pozornost varováním Jednoduchá cesta bude zcela odstraněna... resp. Multipolygon by byl zcela odstraněn... Skoro vždy vyžadují manuální zásah, nebo aspoň kontrolu co se stalo. (Hlášky znamenají, že LPIS pole zcela překrývá jiný existující (multi)polygon a ořez by ho tiše smazal. Tracer polygon nesmaže, místo toho zobrazí varování.) Problémy při aktualizaci LPIS: * Ze dvou LPIS polí se v LPISu stalo jedno velké. Retrasované pole pak překryje druhé pole a zobrazí se popsané varování. Pokud nesmažete druhé pole ručně, vznikne překryv. Pokud se jedná o multipolygon(y), nezapomeňte na relace. * LPIS pole více či méně změnilo svou geometrii. Retrasováním ořízne sousední pole tak, že ho rozseká na víc kousků, případně z něj zůstanou miniaturní odřezky podél hran nové geometrie. Zde je na zodpovědnosti mappera, aby si zkontroloval do čeho zasahuje nová geometrie a opravil výsledek. * (Re)trasování LPIS polí uvnitř staršího landuse polygonu z jiného zdroje (např. vinice obkreslená podle KM). Opět vznikají nepatrné odřezky kvůli rozdílům v geometrii. Někdy na odřezky upozorní Tracer (Jednoduchá cesta bude zcela odstraněna), jindy bohužel tiše zůstanou v mapě. Sousedící LPIS geometrie mívají mezi sebou drobné škvíry a právě v nich zůstává smetí ze starého polygonu. Možná přidám do Traceru upozornění na odřezky a/nebo jejich smazání. Ale univerzální řešení pro všechny situace stejně neexistuje. Takže buďte opatrní a neklikejte bez rozmyslu na každé pole ;-) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Bordel
Ahoj, Dne 5.5.2015 v 21:37 Petr Vejsada napsal(a): Ahoj, Dne Út 5. května 2015 13:49:36, Martin Švec - OSM napsal(a): Petře, můžeš vytáhnout něco jako SELECT changeset_id, user, COUNT(sirotci) ... GROUP BY changeset_id v kterém uzly osiřely? Namátkou to vypadá jen na pár changesetů. Rád bych vyloučil chybu v Traceru. já nemám historii, takže nemůžu nalézt changeset, ve kterém uzly osiřely, ale s vysokou pravděpodobností to bude ten changeset poslední. Ledaže by někdo tyto sirotky editoval; těžko. Přikládám group-by changeset i group-by user. sarkasmVýsledek asi málokoho překvapí/sarkasm. :-)) Díky, mrknu na to, příležitostně. Vidím tam i sebe, třeba něco zjistím z logů. Nepamatuju si, že by mi JOSM v posledních měsících křupnul při uploadu. Btw, nedávno jsem při nahrávání LPISu narazil na zajímavou haluz -- v changesetu se mi náhodně zdvojily cesty LPIS polí. Duplikáty měly stejné tagy a sdílely všechny svoje uzly. Jako kdyby JOSM nahrál část nových cest a relací dvakrát za sebou. Objevil jsem je až za měsíc v Osmose, byl to jeden konkrétní changeset. Tracer to (doufám) udělat nemohl, to bych hned viděl, dvojitá pole měla v JOSM tmavší barvu. Tohle se občas, ale opravdu jen občas stane. Nejsem si úplně jist, zda je to softwarem nebo člověkem. Spíš to přisuzuji sobě. Nicméně - pokud jsou oba polygony naprosto stejné, JOSM, doufám, že vždy, zařve. Stalo se mi ovšem i to, že nebyly naprosto stejné. Sdílely třeba všechny uzly až na jeden. To může IMO vzniknout tak, že když se tracuje podruhé, je to jiná situace - na daném místě už landuse je. Já podezírám upload changesetu do OSM. Ty cesty a relace byly _naprosto_ identické, proto je taky našlo Osmose. JOSM validace nic nehlásila, to bych ven nepustil, a trasované polygony vizuálně hlídám jak jen to jde. Každopádně je dobré se občas mrknout do Osmose na svoje chyby. ;-)) Martin Co se týká povšimnutí si duplicity, tak nevím, o jaké tmavší barvě to píšeš - to asi hodně závisí na nastavení JOSM. Mám tu skript, který umí najít duplicity či téměř duplicity z LPIS, tak jsem ho teď pustil, ono to bude nějakou dobu chroupat. -- Petr Martin Dne 5.5.2015 v 6:56 Marián Kyral napsal(a): Ahoj, můžeš udělat nějakou statistiku? Stáří, changesety, uživatelé? Co jsem tak namátkou prošel, všechno to byly uzly staré dva měsíce od jednoho uživatele. Možná nějaký dočasný problém. Ať už JOSM nebo OSM API? Marián -- Původní zpráva -- Od: Petr Vejsada o...@propsychology.cz Komu: talk-cz@openstreetmap.org Datum: 5. 5. 2015 2:42:16 Předmět: [Talk-cz] Bordel Ahoj, právě mažu přes 200 tisíc osiřelých uzlů. Wtf? http://www.openstreetmap.org/changeset/30794706 -- p ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Rozdíl mezi road a track?
Dělám to stejně, highway=track, tracktype=grade1, popř. ještě surface=asphalt. Viz http://wiki.openstreetmap.org/wiki/Cs:Key:tracktype. Cesta Kočičákem je IMHO jasný případ, úzká lesácká a rekreační cesta neurčená pro průjezd osobáků, z obou stran závora. Já spíš váhal u nedaleké silničky z Javůrku do Hvozdce. Ta je povrchem už pomalu track, ale nakonec jsem ji označil highway=unclassified, kvůli větší šířce a způsobu používání jako spojnice mezi vesnicemi. Martin Dne 26.3.2015 v 9:02 Zdeněk Pražák napsal(a): Já značím takové lesní či cesty s asfaltovým nebo betonovým povrchem jako highway:track tracktype:grade1 Pražák Dne 26. března 2015 8:37 Miroslav Suchý miros...@suchy.cz mailto:miros...@suchy.cz napsal(a): Teď jsem narazil v Brně-Bystrci v Kočičím žlebě na cestu která je: highway=track sufrace=asphalt Což mě zarazilo. Vždycky [*] jak na cestě byl asfalt, tak jsem ji značil jako [service,minor] road. Track jsem nechával jenom pro lesní a polní cesty bez asfaltu až do té urovně dokud tam projede tereňák nebo traktor. Jaký je váš názor na asfaltové lesní cesty? [*] Teda až na Rumunsko, kde silnice bez asfaltu jsou docela běžné. -- ,,, (o o) =oOO==(_)==OOo=== ) mailto:miros...@suchy.cz mailto:miros...@suchy.cz tel:+420-603-775737 tel:%2B420-603-775737 ( One picture is worth 128K words. )Oooo. .oooO ( ) ( )) / \ ((_/ \_) ___ Talk-cz mailing list Talk-cz@openstreetmap.org mailto:Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] LPIS okolo Jindřichova Hradce
Ahoj, Dne 15.1.2015 v 22:25 Petr Kadlec napsal(a): Zdravím, všimnul jsem si podivně se zobrazujícího letiště Kámen [1] a po troše zkoumání jsem zjistil, že to pravděpodobně vzniklo v changesetu #28065150 „lpis okolo jindřichova hradce“, který provedl Petr1868. [2] Tenhle changeset hlavní cestu definující letiště rozsekal na několik kusů, včetně několika dost zdegenerovaných (např. [3]), a samotné letiště ořezal několika sousedními loukami. Předpokládám, že to bude způsobeno tím, že přímo na letišti bylo (odjakživa, já to tam nedal…) nastaveno landuse=meadow. Jo, to udělal tracer :-( Primárně je ale na zodpovědnosti mappera, aby se díval kam kliká a upravil výsledek. Hlavně v oblastech s existujícími daty, kde se může stát ledacos. Od toho je v traceru klávesa Ctrl, která vypne nebezpečné operace. Tracer je jen nástroj a zdaleka neřeší všechny záludnosti. Můžem dát dohromady seznam doplňujících tagů, kdy se nemá landuse ořezávat. Opačná možnost je zakázat ořezy u landuse s jinými tagy kromě explicitně povolených. Nebo máte jiné nápady? IMHO by to teď asi chtělo vrátit to letiště do předchozí podoby a poté z něj případně vyextrahovat meadow pryč (či alespoň na jiný objekt) a případně dále dělat LPISoviny. Ale sám to hned nedělám, protože nevím, jestli neexistují jiná či jednodušší řešení, než se to snažit lepit ručně. S reverty nemám zkušenosti, já osobně bych to opravil ručně. Martin Co vy na to? -- Petr Kadlec / Mormegil [1] http://osm.org/go/0JyYY7Q [2] https://www.openstreetmap.org/changeset/28065150 [3] https://www.openstreetmap.org/way/321484972 ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Snizovani kvality dat pri importu RUIAN/LPIS
Zdravím, Dne 16.1.2015 v 9:25 Janda Martin napsal(a): Dorby den, zjistil jsem ze dochazi ke zhorseni kvality dat behem importu RUIAN. 1) rozbijeji se polygony budov. Nejsou zarovnane, maji artefakty. Puvodni polygony jsou v poradku. Nevim proc se delaji nove kdyz staci jen zkontrolovat jestli sedi puvodni provedeni. Nove nemaji ani kolme/rovnobezne steny Jak už jsem psal, toto vždycky bude zodpovědnost mappera. Tracer bere geometrii z RUIANu a opravdu nemůže poznat, jestli je lepší původní nebo nová geometrie ;-) Kolmost stěn je individuální, často jsou baráky postavené nakřivo. Totéž artefakty. Některé výklenky jsou diskutabilní, něco jsou jasné chyby. U těch garáží to může být opěrná zídka která je součástí garáže, nebo chyba geometrie z KM kde garáže nelícují s parcelami. (Tipuju druhou možnost, podle toho jak jsou zmrvené RUIAN geometrie v okolí.) V pointinfu je proklik na hlášení chyb, kde se špatné geometrie RUIAN budov dají reportovat. 2) behem importu dochazi ke ztrate jiz definovanych tagu. Jako priklad prikladam dve garaze vedle sebe ktere maji byt stejne definovane (az na rozdily podle RUIAN) Obe garaze pochazeji ze stejneho changesetu a pred posledni zmenou meli stejne definovane tagy. Predpokladam ze stacilo jen doplni paranetry RUIAN. Snad s novou verzi pluginu se to zlepsi. Obdobne problemy se zarovnanim sousednich polygonu vznikaji i pri importu LPIS. RUIAN tracer žádné tagy nemaže. Do minulé verze přepisoval staré hodnoty tagů, teď to řeší výběrovým dialogem. Podle historie byla druhá garáž přidaná až v posledním changesetu, nepochází z traceru (v RUIANu vůbec není) a nemá ani source tag. Jestli tam byla už dřív, někdo ji musel napřed smáznout a udělat znova. Čili doporučuji dotaz na autora changesetu. Martin Dekuji Martin Way: 142323551 Data Set: 51dff96c Edited at: 2014-12-23T21:55:51Z Edited by: Salamandr (1708065) Version: 4 In changeset: 27660844 Tags: ref:ruian:building=46722581 access=private roof:shape=flat building:ruian:type=18 building:levels=2 source=cuzk:ruian building=garage Bounding box: 14.4339314, 50.0530421, 14.4339843, 50.0531312 Bounding box (projected): 1606777.8935930424, 6455466.8707308965, 1606783.7823941053, 6455482.318345269 Center of bounding box: 50.0530866, 14.4339579 Centroid: 50.0530859, 14.4339578 10 Nodes: 3250130690 1557741842 1557741844 1557741846 3250130695 1557741840 1557741831 1557741829 3250130691 3250130690 Way: 318632990 Data Set: 51dff96c Edited at: 2014-12-23T21:55:50Z Edited by: Salamandr (1708065) Version: 1 In changeset: 27660844 Tags: building=garage Bounding box: 14.4339744, 50.0530601, 14.4340248, 50.053149 Bounding box (projected): 1606782.6803311466, 6455469.991458761, 1606788.2908334823, 6455485.404404104 Center of bounding box: 50.0531046, 14.4339996 Centroid: 50.0531045, 14.4339995 9 Nodes: 3250139977 3250139976 3250139975 1557741840 1557741831 3250139967 3250139968 3250139969 3250139977 ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] LPIS okolo Jindřichova Hradce
Dne 16.1.2015 v 19:30 Petr Vejsada napsal(a): Ahoj, Dne Pá 16. ledna 2015 18:40:00, Martin Švec - OSM napsal(a): Od toho je v traceru klávesa Ctrl, která vypne nebezpečné operace. což to otočit? Implicitně nic neořezávat; jen na vyžádání. To se bude lišit místo od místa... V prázdných oblastech by mi zdřevěněl prst na Ctrl. V zmapovaných oblastech to vidím tak půl na půl. Možná přepínač výchozí hodnoty do nastavení? BTW: co ta varianta, že se neořezává okolí, ale nově tracovaná plocha? Tedy nechci tě prudit, máš jistě práce dost, ale IMO by to bylo fakt fajn. Jsem na tom bídně s časem, ale vedu to v patrnosti. Kolem Silvestra jsem dodělal zeleň v pár vesničkách, abych poznal reálné výsledky RuianLands a problémy co tam vznikají. Čili třeba se dočkáš. Nebo se může zapojit někdo další, plugin je open-source :-) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer-testing - nová verze
Ahoj, On 11.1.2015 09:12, Marián Kyral wrote: Ahoj, díky usilovné Martinově práci (díky, díky, díky), jsem mohl vydat novou verzi traceru. Kdo si hraje, nezlobí :-) *) Pokud se při přetrasování zjistí nějaký konflikt v tagování (třeba church vs, residental) - zobrazí se dialog, kde lze konflikt vyřešit. Zatím jen u RUIAN budov, ale není problém přidat dialog i v dalších modulech. Ještě bych v něm rád odlišil staré a nové hodnoty tagů, ale nevím jestli to půjde. Jo a pokud narazíte na konflikt tagů, který si zaslouží automatické pravidlo (church = civic, transportation = train_station, ...), napište na talk-cz. Ať dialog vyskakuje co nejmíň. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] RÚIAN tracer
Ahoj, On 3.1.2015 08:37, Marián Kyral wrote: Dne 3.1.2015 v 00:23 Michal Pustějovský napsal(a): Zdravím, měl bych malou prosbu na RÚIAN tracer. Šlo by naprogramovat, aby při nahrazování existujících domů u klíče building=* přepisoval stávající hodnotu tou z RÚIAN POUZE pro building=yes? Spousta domů už totiž má upřesňující značky typu building=supermarket, building=train_station apod. Při použití traceru hodnoty změní na obecnější civic příp. transportation. Podobná situace je i u building:levels, kdy ruian není vždy přesný. Takže bych radši nechávál stávající hodnoty. Stačil by například i zaškrtávací box v nastaveních. Dost by to zrychlilo a zpřesnilo práci. Ahoj, takhle to původně bylo, ale při úpravách se to ztratilo. Implementoval jsem oba požadavky. Asi nejlepší by bylo, kdyby se zobrazilo okno s rozdíly. Tak jak to je třeba dělá příkaz replace geometry. Ale podle mne by to spíše zdržovalo a časem by to mohlo začít vadit. Takže pokud bych to dělal, tak bych to asi udělal konfigurovatelné. Zobrazil bych okno s rozdíly jen tehdy, pokud je potřeba rozhodnout neznámý neošetřený konflikt. Když pak na talk-cz vychytáme seznam známých konfliktů (civic = church atd.), dialog bude otravovat minimálně. Zároveň ale upozorní na nesrovnalosti, třeba zrovna u building:levels. Už to mám napůl rozpracované, zatím to vypadá nadějně... Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Hromadná úprava tagu
Ahoj, pro změny na malém území stačí v JOSM vybrat víc objektů současně. Pak můžeš editovat jejich tagy hromadně přímo v okně pro úpravu tagů. Při změně tagu ti nabídne i přehled zastoupených hodnot ve výběru. Když se to zkombinuje s funkcí Hledat (Ctrl-F) [1] a pro přehlednost s filtry [2], dají se tím rychle dělat psí kusy na stažené oblasti. Akorát si vždycky dej dobrý pozor co máš vybráno. Proto je lepší vybrat objekty přes funkci Hledat a co nejpřesněji specifikovat jejich vlastnosti, než vybírat ručně myší nebo Shiftem. Dá se to i kombinovat, hledání umí hledat jen uvnitř současného výběru atd. [1] http://wiki.openstreetmap.org/wiki/JOSM/Search_function [2] https://www.mapbox.com/blog/2012-08-15-using-filters-josm/ Martin On 3.1.2015 22:12, rattsn...@gmail.com wrote: Ahoj všem, nejsem zrovna zběhlý v hromadných úpravách proto se chci zeptat na příkladu: je možné ve vybrané oblasti v JOSM hromadně upravit nějaký tag, myšleno vyhledat kde je a nahradit ho (Např. změnil se tag ze sub_station na substation). Je toto nějak možno alespoň trochu zautomatizovat? Díky za radu Pavel ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Posunutá mapa?
Tak oblast Křižánek je v mezích možností na svém místě. Opravil jsem budovy, silnice, cesty, vodní plochy a adresní místa. Svratka naštěstí posunutá nebyla. Funkce Filtr se tímto stává mým nejoblíbenějším nástrojem v JOSM ;-) Martin On 30.11.2014 07:48, Tomáš Tichý wrote: Dokonce jsem na to zakládal OSM note: http://www.openstreetmap.org/note/268165#map=14/49.6863/16.0872layers=N Po importu z RÚIAN už jdou podobné případy celkem snadno odhalit. TT On Sun Nov 30 2014 at 4:23:19 jzvc j...@tpfree.net mailto:j...@tpfree.net wrote: Dne 30.11.2014 v 1:33 Petr Vejsada napsal(a): Ahoj, na Bing to sedí naprosto přesně, takže věc je asi jasná :-( Na tohle narazim taky pomerne casto, Bing by bylo treba terminovat jako zdroj. Je klidne misty i 50 metru mimo. Zajimavy, ze tvurcum (neb to neni jeden clovek) nijak zvlast nevadi silnice skrz domy a podobne. Dne Ne 30. listopadu 2014 01:20:30, Martin Švec - OSM napsal(a): Ahoj, narazil jsem na podezřelou oblast: https://www.openstreetmap.org/#map=16/49.6887/16.0645 Zdá se mi to, nebo jsou adresní místa, budovy, cesty, silnice, Svratka atd. posunuté vůči katastrální mapě (a LPIS polygonům) o 5-10 metrů na západ? Jako by si někdo rovnal katastrální mapu vůči Bingu místo obráceně... Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org mailto:Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org mailto:Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org mailto:Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] funguje tracer LPIS
Nefunguje, jelikož mají odstávku: http://eagri.cz/public/web/mze/farmar/LPIS/novinky/odstavka-lpis-1.html V termínu 2. 1. 2015 (0:00) až 10. 1. 2015 (20:00 - odstávka může být ukončena i dříve) bude probíhat plánovaná odstávka registru LPIS. V tomto období budou probíhat úpravy registru LPIS v souvislosti s novelou zákona o zemědělství, která bude účinná od 1. 1. 2015. V tomto termínu nebude dostupné webové rozhraní veřejného LPIS a LPISu pro farmáře. Nedostupné budou také WMS/WFS služby a veřejné webové služby LPIS. Částečné omezení bude také v aplikacích napojených na LPIS a to: Data ke stažení, EPH, IZR a dále Registru vinic (RV). Přehledný soupis změn v LPISu od 1. 1. 2015 je uveden ve zvláštním článku. V případě problémů s LPIS kontaktujte helpdesk MZe - helpd...@mze.cz, 221 811 888. Martin On 2.1.2015 16:38, Zdeněk Pražák wrote: Chtěl jsem se zeptat, zda vám funguje LPIS tracer Pražák ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] chyba traceru a nefunkční modul ruian tracer
Dne 22.12.2014 v 20:28 Pavel napsal(a): Dne 22.12.2014 v 19:26 Marián Kyral napsal(a): Dne 22.12.2014 v 18:43 Zdeněk Pražák napsal(a): Ahoj Trasoval jsem pole v okolí Kokořínska a když jsem chtěl natrasovat modulem RUIAN budovy v Chotiněvsi, tak mi tento modul nereagoval a když jsem chtěl dále pokračovat v trasování polí tak objevila se hláška - Došlo k neočekávané chybě, kterou způsobil doplněk Tracer testing. Pražák Ahoj. to je super. Dokážeš chybu reprodukovat? Ideálně poslat log? Buď z konzole nebo z té hlášky? Když klikneš na Nahlásit chybu, tak se zobrazí přesný popis chyby (plus verze josm a tracer pluginu). To stačí jen zkopírovat do emailu. Zkusno jsem si všechny budovy naklikal a žádný problém se neobjevil. Zřejmě se stalo už něco před tím. Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz Můžu taky dotaz? změnilo se něco v nastavení? mně to v celé Praze hlásí: data nejsou dostupná... Díky Pavel Používáš tracer-testing? Zkusil jsem teď RUIAN i LPIS v Praze, oboje mi funguje. Zkontroluj, jestli nemáš v nastavení pluginu zapnuté jiné URL RUIAN serveru. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Padání traceru
Ahoj, ufff, multipolygon co má jako člena jinou relaci? Takovou obskurnost by tracer měl ignorovat, ale asi ne úplně dokonale. Zkusím nasimulovat a opravit. Martin On 20.12.2014 20:36, Michal Pustějovský wrote: Zdravím, dneska při mapování lpis polí okoli Českého Těšína mi tracer začal znenadání padat. Začalo to vždy u stejného pole a po jedné vyhozené chybě už přestalo trasovat i ostatní pole. Po hodině hrátek s datasetem jsem zjistil pravděpodobný důvod. Chybu způsobuje, pokud je KDEKOLIV v datasetu relace lesa (multipolygon), která má za člena s rolí inner jinou relaci. Po opravení a restartu JOSM už vše trasovat šlo. Třeba to někomu pomůže. Michal ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Padání traceru
Jo, padá :-) Tuhle situaci jsem považoval za tak nepravděpodobnou, že ji tracer sice zjistí, ale nesnaží se to řešit a rovnou vyhodí výjimku Multipolygon neobsahující cesty nelze editovat. Nu, něco s tím udělám, vidím to poprvé. Martin On 20.12.2014 20:58, Martin Švec - OSM wrote: Ahoj, ufff, multipolygon co má jako člena jinou relaci? Takovou obskurnost by tracer měl ignorovat, ale asi ne úplně dokonale. Zkusím nasimulovat a opravit. Martin On 20.12.2014 20:36, Michal Pustějovský wrote: Zdravím, dneska při mapování lpis polí okoli Českého Těšína mi tracer začal znenadání padat. Začalo to vždy u stejného pole a po jedné vyhozené chybě už přestalo trasovat i ostatní pole. Po hodině hrátek s datasetem jsem zjistil pravděpodobný důvod. Chybu způsobuje, pokud je KDEKOLIV v datasetu relace lesa (multipolygon), která má za člena s rolí inner jinou relaci. Po opravení a restartu JOSM už vše trasovat šlo. Třeba to někomu pomůže. Michal ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Osmose Česká republika
Dne 7.12.2014 22:09, Marián Kyral napsal(a): A ještě jeden nápad mám v hlavě - hodně mne štve, jak je komplikované udělat z kousku silnice most (kouska potoka tunel). Vybrat cesru a dva body, rozdělit pomocí p, vybrat prostřední kousek a změnit jej na most. Je tam dvakrát výběr. Uvažuji nad nějakým pluginem, kde by stačilo vybrat cestu a ty dva body a pak jen kliknout na Convert to bridge/ Convert to tunnel. Rozdělení a otagování by se provedlo automaticky. A proč se zdržovat s vyráběním+výběrem bodů? :-) Co takto: Při kliknutí na průsečík cesty a vody se zobrazí dialog, v něm se vybere bridge/culvert a délka v metrech. Pak se sekne příslušná cesta na obě strany od průsečíku a otaguje. Pokud už body v patřičné vzdálenosti existují, použijí se existující. (Možná bychom se obešli i bez dialogu, stačilo by přes klávesu přepínat mezi mostkem a strouhou, šířka rozumný default.) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Osmose Česká republika
Dne 8.12.2014 20:45, Marián Kyral napsal(a): Dne 8.12.2014 19:36, Martin Švec - OSM napsal(a): Dne 7.12.2014 22:09, Marián Kyral napsal(a): A ještě jeden nápad mám v hlavě - hodně mne štve, jak je komplikované udělat z kousku silnice most (kouska potoka tunel). Vybrat cesru a dva body, rozdělit pomocí p, vybrat prostřední kousek a změnit jej na most. Je tam dvakrát výběr. Uvažuji nad nějakým pluginem, kde by stačilo vybrat cestu a ty dva body a pak jen kliknout na Convert to bridge/ Convert to tunnel. Rozdělení a otagování by se provedlo automaticky. A proč se zdržovat s vyráběním+výběrem bodů? :-) Co takto: Při kliknutí na průsečík cesty a vody se zobrazí dialog, v něm se vybere bridge/culvert a délka v metrech. Pak se sekne příslušná cesta na obě strany od průsečíku a otaguje. Pokud už body v patřičné vzdálenosti existují, použijí se existující. No už vidím, jak se budu trefovat do správné délky :-D To raději udělám ty dva body podle katastrálních map. Navíc, v naprosté většině případů nemají cesty na průsečíku společný bod, takže jeden bod vytvořit musím. Ale co by šlo (ty určitě budeš mít představu jak to udělat v GUI, já to budu zkoumat mnohem déle): 1) aktivuji tool 2) kliknu na na cestu v místě začátku mostu/propustku (cesta na kterou chci kliknout se vysvítí - stejně jako u contourmerge pluginu) 3) vytvoří se bod (nebo se vybere již existující) 4) mezi prvním bodem a kurzorem myši se začne vykreslovat čára symbolizující most 5) kliknu na místo, kde most/propustek končí 6) vytvoří se (použije se již existující) druhý bod 7) cesta se rozdělí 8) vybere se segment mostu/tunelu 9) pokud jsem klikl na cestu - segment se otaguje jako most 10) pokud jsem klikl na waterway - segment se otaguje jako propustek 11) pokud to není ani higway ani waterway - rollback a chybová hláška 12) přidám nebo upravím tag layer - u mostu - layer = layer + 1; u propustku: layer = layer - 1 Jo, to zní taky dobře. Ale zklamu tě, interaktivní záležitosti v GUI jsem vůbec nezkoumal. Celý Tracer je jednorázová transakce nad zamknutým DataSetem, dál jsem se nedostal. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Osmose Česká republika
Dne 8.12.2014 21:18, Marián Kyral napsal(a): Dne 8.12.2014 21:12, Marián Kyral napsal(a): Dne 8.12.2014 19:55, Mirek Dlask napsal(a): Nedávno jsem našel toto http://geoportal.cuzk.cz/(S(edrn34aqju5rgehhxpqqot5a))/Default.aspx?mode=TextMetaside=wms.verejnemetadataID=CZ-CUZK-WMS-ZABAGED-PmetadataXSL=metadata.sluzbamenu=3113 http://geoportal.cuzk.cz/%28S%28edrn34aqju5rgehhxpqqot5a%29%29/Default.aspx?mode=TextMetaside=wms.verejnemetadataID=CZ-CUZK-WMS-ZABAGED-PmetadataXSL=metadata.sluzbamenu=3113 Znamená to snad, že můžeme mapovat podle ortofoto mapy, která je tam též? http://geoportal.cuzk.cz/%28S%28g0hxkax1lwypr5i5d1pmhq4z%29%29/Default.aspx?menu=3121mode=TextMetaside=wms.verejnemetadataID=CZ-CUZK-WMS-ORTOFOTO-PmetadataXSL=metadata.sluzba Jestli se nepletu, tak nemáme povoleno mapovat dle barevné ortofoto mapy od UHULu. A ČÚZK to má zřejmě ze stejního zdroje. Jak to tedy je? A vzhledem k tomu, že to má stejné podmínky užití, jako prohlížení KM, tak by to mohla být i pravda. No to by byla bomba. http://geoportal.cuzk.cz/Dokumenty/Podminky_sluzby_CUZK.pdf Lehce jsem podmínky prolítnul, když tu Petr Vejsada nadhodil dotaz v souvislosti s poloha.net. A coby neprávník si vůbec nejsem jistý, jak to s používáním WMS je. Na ukázku: * Podmínky užití - zpoplatnění služby: Žádné podmínky neplatí. :-)) * Omezení přístupu - Opětovnému využití dat zpřístupněných službou pro obchodní účely je zamezeno začleněním ochranných znaků (copyright ČÚZK). ...vyplývá z toho něco? * PDFko se odvolává na vyhlášku č. 103/2010. Z té právničiny mi přišlo, že není dovoleno skoro nic. * http://geoportal.cuzk.cz/Dokumenty/podminky.html, Podmínky poskytování a užití prohlížecích služeb: Bezplatně poskytované prohlížecí služby nejsou určeny ke komerčnímu užití a podléhají autorsko-právní ochraně zákona č. 121/2000 Sb. Pro jejich šíření, reprodukci v původní či pozměněné podobě i nekomerčního charakteru, je nutný písemný souhlas ZÚ. tohle už je dost konkrétní. * http://www.mail-archive.com/talk-cz@openstreetmap.org/msg08077.html ... jasné zamítnutí ZÚ/ČÚZK z roku 2012 pro účely obkreslování v OSM. Mně z toho vychází, že se do WMS můžeme dívat pro soukromou potřebu, ale nesmíme je dál šířit nebo obkreslovat. Možná by mohl někdo zběhlejší v právech a licencích znovu naťuknout ČÚZK. Třeba mezitím změnili právničku :-) Ortofoto jako zdroj v JOSM by byl naprosto super. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Osmose Česká republika
On 8.12.2014 21:38, Marián Kyral wrote: Dne 8.12.2014 21:22, Martin Švec - OSM napsal(a): Dne 8.12.2014 20:45, Marián Kyral napsal(a): Dne 8.12.2014 19:36, Martin Švec - OSM napsal(a): Dne 7.12.2014 22:09, Marián Kyral napsal(a): A ještě jeden nápad mám v hlavě - hodně mne štve, jak je komplikované udělat z kousku silnice most (kouska potoka tunel). Vybrat cesru a dva body, rozdělit pomocí p, vybrat prostřední kousek a změnit jej na most. Je tam dvakrát výběr. Uvažuji nad nějakým pluginem, kde by stačilo vybrat cestu a ty dva body a pak jen kliknout na Convert to bridge/ Convert to tunnel. Rozdělení a otagování by se provedlo automaticky. A proč se zdržovat s vyráběním+výběrem bodů? :-) Co takto: Při kliknutí na průsečík cesty a vody se zobrazí dialog, v něm se vybere bridge/culvert a délka v metrech. Pak se sekne příslušná cesta na obě strany od průsečíku a otaguje. Pokud už body v patřičné vzdálenosti existují, použijí se existující. No už vidím, jak se budu trefovat do správné délky :-D To raději udělám ty dva body podle katastrálních map. Navíc, v naprosté většině případů nemají cesty na průsečíku společný bod, takže jeden bod vytvořit musím. Ale co by šlo (ty určitě budeš mít představu jak to udělat v GUI, já to budu zkoumat mnohem déle): 1) aktivuji tool 2) kliknu na na cestu v místě začátku mostu/propustku (cesta na kterou chci kliknout se vysvítí - stejně jako u contourmerge pluginu) 3) vytvoří se bod (nebo se vybere již existující) 4) mezi prvním bodem a kurzorem myši se začne vykreslovat čára symbolizující most 5) kliknu na místo, kde most/propustek končí 6) vytvoří se (použije se již existující) druhý bod 7) cesta se rozdělí 8) vybere se segment mostu/tunelu 9) pokud jsem klikl na cestu - segment se otaguje jako most 10) pokud jsem klikl na waterway - segment se otaguje jako propustek 11) pokud to není ani higway ani waterway - rollback a chybová hláška 12) přidám nebo upravím tag layer - u mostu - layer = layer + 1; u propustku: layer = layer - 1 Jo, to zní taky dobře. Ale zklamu tě, interaktivní záležitosti v GUI jsem vůbec nezkoumal. Celý Tracer je jednorázová transakce nad zamknutým DataSetem, dál jsem se nedostal. No to já taky ne. Ale ty umíš lépe hledat v dokumentaci. Já se v ní ztrácím, hledám něco a ani vlastně nevím co :-D Určitě by se jako základ dal využít ten contour merge plugin. Musím to prozkoumat. Dokumentace? Ale fujtajbl :-) Hlavně se musí číst zdrojáky. Vyšel bych z ImproveWayAccuracyAction.java [1], tam je všechno krásně na jednom místě. Z toho co vidím: (a) Implementuješ rozšíření třídy MapMode = režim toolu, to dělá i Tracer. (b) Implementuješ rozhraní MapViewPaintable, přes něj se metodou paint() kreslí. (c) V enterMode() si přidáš dočasnou vrstvu s tvou implementací MapViewPaintable přes Main.map.mapView.addTemporaryLayer(this). (d) Zahákneš si listenery na události myši a modifikátorů. (e) Reaguješ na události, pamatuješ si stavy, a podle nich kreslíš a edituješ. (f) V exitMode() po sobě uklidíš listenery a kreslící vrstvu. Tolik teorie, praxi nechám na tobě ;-) Jaks výš popsal princip toolu -- v bodě (3) bych nový bod nevytářel, jen si zapamatoval jeho místo a vykresloval fiktivní bod v temporary vrstvě. Oba uzly by se vytvořily až po kliknutí (5), ať undo zruší celou operaci. [1] http://josm.openstreetmap.de/browser/trunk/src/org/openstreetmap/josm/actions/mapmode/ImproveWayAccuracyAction.java Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] LPIS duplicity
Dne 5.12.2014 17:28, Petr Vejsada napsal(a): Ahoj, On Fri, Dec 05, 2014 at 12:59:05AM +0100, Martin Švec - OSM wrote: Tak a jsou opraveny. Už vím proč jich bylo tak málo :-) Tys našel jen překryvy, kde _oba_ polygony byly plošně téměř totožné. Podmínky pro polygony L a F by měly vypadat asi takto, aby našly haluze po LPIS traceru: * plocha(L) průnik plocha(F) = plocha(L); * množina_uzlů(L) průnik množina_uzlů(F) = víc než cca 90% z množiny_uzlů(L). http://pedro.poloha.net/osm/pole2.ods pro dvojice platí, že st_contains(nonlpis,lpis) lpis_nodes - počet uzlů lpis geometrie nonlpis_nodes - počet uzlů non-lpis geometrie, které jsou společné s lpis procenta si spočítáš sám a pokud budeš počítat stejně jako já, dostaneš 23 řádků ...? Vups, že bych zas řešil skoro neexistující problém? :-( Dík moc za snahu. Já sám už jich opravoval cca dvacet jen náhodným objevením, takže jsem čekal úplně jiný číslo. Seznam se ale bude hodit bez ohledu na procenta, co jsem se namátkou díval. Ještě jednou díky. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] LPIS duplicity
On 4.12.2014 12:53, Martin Švec - OSM wrote: Dne 3.12.2014 20:05, Petr Vejsada napsal(a): Ahoj, On Wed, Dec 03, 2014 at 07:37:16PM +0100, Martin Švec - OSM wrote: No potěš koště... Někdo ignoruje warningy JOSM validátoru? Nebo jsou případy které JOSM neodchytí? já jsem se akce trasování polí prakticky vůbec neúčastnil, začal jsem až s trasováním těch RUIAN lands, nicméně zachytil jsem jeden případ, kdy JOSM varoval před něčím jako otevírací doba obchodu či co, otevírací dobu obchodu jsem opravil a teprve pak zařval na duplicitní landuse. 100% jsem na to nesahal; JOSM si toho všiml až napodruhé. Ještě by mě zajímaly LPIS pole, kde průnik s jiným polygonem je roven tomu LPIS poli a zároveň s ním pole sdílí většinu svých uzlů. Tj. kde se místo ořezu sousedního polygonu udělalo sjednocení. Když jsem v září obcházel lesní multipolygony, nacházel jsem jich spoustu. http://pedro.poloha.net/osm/pole.ods není toho moc a seznam nemusí být úplně spolehlivý, protože relace a outer a inner. Je tam jedna dvojice, kdy na relaci je farmland a na outer je forest. Zbytek jsem nezkoumal. Neděs se, je to asi 20 řádků. Díky. Jen tak málo? Zvláštní. Podle toho co jsem opravoval na lesních multipolygonech jsem jich čekal až stovky. Je pravda že to byly ty největší multipolygony s více outer cestami, asi na to byly náchylnější. Tak a jsou opraveny. Už vím proč jich bylo tak málo :-) Tys našel jen překryvy, kde _oba_ polygony byly plošně téměř totožné. Podmínky pro polygony L a F by měly vypadat asi takto, aby našly haluze po LPIS traceru: * plocha(L) průnik plocha(F) = plocha(L); * množina_uzlů(L) průnik množina_uzlů(F) = víc než cca 90% z množiny_uzlů(L). Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] LPIS duplicity
No potěš koště... Někdo ignoruje warningy JOSM validátoru? Nebo jsou případy které JOSM neodchytí? Ještě by mě zajímaly LPIS pole, kde průnik s jiným polygonem je roven tomu LPIS poli a zároveň s ním pole sdílí většinu svých uzlů. Tj. kde se místo ořezu sousedního polygonu udělalo sjednocení. Když jsem v září obcházel lesní multipolygony, nacházel jsem jich spoustu. Tam se musí provést znova ořez, což už asi hromadně opravit nepůjde. Martin Dne 3.12.2014 19:03, Petr Vejsada napsal(a): FYI, smazáno přes 1400 duplicitních LPIS polí. -- Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Evidence a hlášení špatných budov v RÚIAN
Ahoj, slušná práce :-) On 30.11.2014 20:00, Petr Vejsada wrote: Hlášení špatných budov - pro stroje (třeba odkaz z JOSM traceru ;-))) - http://ruian.poloha.net/building.php?kod= kde je kód stavebního objektu v RÚIAN PointInfo mi přijde jako lepší místo na proklik. Ale i do Traceru by to šlo, akorát v něm dochází klávesy. Zbývá jen Alt a kombinace s ním. - důvod - to je jasné, proč je budova špatně. Důvody jsou zatím 2, pište sem další důvody, abych je do menu přidal. Postrádám oblíbené useknutí/rozpůlení budovy hranicí parcely. Roztažení budovy přes celou plochu parcely budem počítat za špatnou polohu budovy? Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer - nová verze
Ahoj, re-trasování existujících polí funguje pouze u cest, které mají source=lpis. Jinými slovy, dají se opravovat dříve natrasované jednoduché LPIS polygony. Vše ostatní se bere jako materiál k oříznutí. Proto radši *neklikejte do ručně kreslených polí*, může to dopadnout všelijak. Nebo jak psal Marián, natrasovat s Ctrl (bez ořezů) a pak doladit výsledek přes Náhradu geometrie. Retrasování v LPISu jsem já osobně neměl (a nemám) jako prioritu, protože: (a) Jsem to nepotřeboval :-) Většina republiky je furt bílá, takže se řešily hlavně ořezy a napojování na okolí. (b) Mezi ručně zmapovanými a LPIS poli vidím zásadní rozdíly: velikost polygonů, počet polygonů, způsob navázání na okolní objekty, často nesedí typ (pole vs. louka) Mám trochu obavy, aby tracer nesváděl k rozbíjení hotových území, s kterými si někdo dal hodně práce. (c) Není snadné definovat, co se může a nesmí nahradit. Když kliknu doprostřed lesa a podle LPISu je tam louka, má se vytvořit mýtina, nebo nahradit celý les? Pro jaké kombinace tagů, tvarů a rozloh polygonů ještě použít nahrazení, a kdy už použít ořezání? (d) Je obecně problém retrasovat multipolygony. Zase kvůli výčtu možností, které můžou nastat. Tady by pomohla širší diskuse a názory lidí, kteří retrasování opravdu potřebují. Když z toho vyplynou nejčastější konkrétní případy, můžem je dodělat :-) Martin On 29.11.2014 00:59, Petr Schönmann wrote: Ahoj, nevim jestli to je chyba nebo ne, kazdopadne to neni moc dobre co to dela. Kdyz mam pole ktere nekdo zakreslil rucne a presahuje okraje pres lpis a ja RE-trasuju pole okolni zbytky jsou orezany a zustavaji. Viz obrazky. Vypada to divne kdyz skrz pole vede cesta a udelate trace na sousedici pole, tak cesta uprostred zustava stale jako farmland. Dne 28. listopadu 2014 23:08 Marián Kyral mky...@email.cz mailto:mky...@email.cz napsal(a): Ahoj, natural=grassland by se měl normálně ořezávat. Teď jsem to zkoušel a funguje to. Máš aktuální verzi pluginu (1417030875)? Marián Dne 28.11.2014 22:39, xkomc...@centrum.cz mailto:xkomc...@centrum.cz napsal(a): Ahoj, jeden návrh/prosbu bych měl: šlo by přidat do nastavení pluginu volbu které všechny plochy má plugin ořezávat? V současnosti je to např. landuse=forest, natural=wood, ale už to není natural=grassland. A to by se mi zrovna hodilo. Moje současné workflow je totiž takové, že si prvně vyznačím meze (které schválně přetáhnu více do pole/louky), označím to jako natural=wood, pak to nechám ze všech stran oříznout pluginem který tvoří pole/louky a nakonec tyto meze změním z natural=wood na natural=grassland. Kdybych mohl pluginu říct, že má řezat i natural=grassland, ušetřil bych tak jeden krok (a následnou kontrolu, případně opravu chyb, když to někde zapomenu změnit) Předem díky za zvážení návrhu xkomczax __ Od: Marián Kyral mky...@email.cz mailto:mky...@email.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org mailto:talk-cz@openstreetmap.org Datum: 26.11.2014 21:37 Předmět: [Talk-cz] Tracer - nová verze Ahoj, tak jsem právě nahrál novou verzi Tracer pluginu. Nového je hodně. Obrovskou zásluhu na tom má Martin Švec, který se do toho pustil s vervou a kompletně přepsal celou logiku zpracování, ořezávání a napojování okolních cest a čištění od nejrůznějších anomálií typu duplicitní body a ocásky. Už by jste neměli potkat chybu: Deleted node referenced. ;-) Převedeny jsou pluginy LPIS a Ruian. RuianLands je stále ve stádiu experimentů a modul původního traceru zatím převeden není. Tuto verzi už nějakou verzi testuji a funguje mnohem lépe než starý tracer. Funguje ořezávání cest a jednoduchých multipolygonů. Složitější multipolygony zatím nejsou podporovány. Stejně tak ještě stále nefunguje přetrasovávání již existujících polí. V tomto případě doporučuji pole natrasovat bez ořezu a použít funkci Nahradit geometrii z utilsplugin2 pluginu. Pak je možno dané pole znova natrasovat a to by se už měl provést ořez a napojení na okolní cesty (Ovšem s výjimkou těch prozatím nepodporovaných případů ;-) ) Takže vyzkoušejte a nahlaste nalezené problémy. Případně pokud máte nějaké návrhy, co by se ještě mohlo vylepšit. TODO: *) Převést i zbývající modul (Classic) *) Zahodit starý modul pro ořez a pročistit kód *) Předělat konfiguraci jednotlivých modulů *) Opravy chyb a další vylepšení Martinovi opět velmi děkuji za pomoc. Konec hlášení, Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org mailto:Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list
[Talk-cz] Posunutá mapa?
Ahoj, narazil jsem na podezřelou oblast: https://www.openstreetmap.org/#map=16/49.6887/16.0645 Zdá se mi to, nebo jsou adresní místa, budovy, cesty, silnice, Svratka atd. posunuté vůči katastrální mapě (a LPIS polygonům) o 5-10 metrů na západ? Jako by si někdo rovnal katastrální mapu vůči Bingu místo obráceně... Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer - nová verze
Dne 26.11.2014 21:35, Marián Kyral napsal(a): Ahoj, tak jsem právě nahrál novou verzi Tracer pluginu. Nového je hodně. Obrovskou zásluhu na tom má Martin Švec, který se do toho pustil s vervou a kompletně přepsal celou logiku zpracování, ořezávání a napojování okolních cest a čištění od nejrůznějších anomálií typu duplicitní body a ocásky. Už by jste neměli potkat chybu: Deleted node referenced. ;-) Převedeny jsou pluginy LPIS a Ruian. RuianLands je stále ve stádiu experimentů a modul původního traceru zatím převeden není. Tuto verzi už nějakou verzi testuji a funguje mnohem lépe než starý tracer. Funguje ořezávání cest a jednoduchých multipolygonů. Složitější multipolygony zatím nejsou podporovány. Stejně tak ještě stále nefunguje přetrasovávání již existujících polí. V tomto případě doporučuji pole natrasovat bez ořezu a použít funkci Nahradit geometrii z utilsplugin2 pluginu. Pak je možno dané pole znova natrasovat a to by se už měl provést ořez a napojení na okolní cesty (Ovšem s výjimkou těch prozatím nepodporovaných případů ;-) ) Takže vyzkoušejte a nahlaste nalezené problémy. Případně pokud máte nějaké návrhy, co by se ještě mohlo vylepšit. TODO: *) Převést i zbývající modul (Classic) *) Zahodit starý modul pro ořez a pročistit kód *) Předělat konfiguraci jednotlivých modulů *) Opravy chyb a další vylepšení Doplním pár bodů: (*) Pokud používáte v JOSM jinou projekci než Mercatora, ozvěte se. Patrně budete mít problém ;-) (*) Když neproběhne ořez multipolygonu, podívejte se jestli nemá old-style tagování (tagy na cestách). Případně převeďte na new-style (plošné tagy z cest přesunout na relaci) a zkuste znovu. New-style multipolygony Tracer ořezává mnohem ochotněji. (*) Pozor, při ořezech můžou vznikat malé odřezky, které byste měli zkontrolovat a popř. smazat. V RUIANu už se mažou automaticky, u LPISu zatím není jasné co považovat za malý odřezek. (*) Vůbec není podporován ořez multipolygonů s _neuzavřenými_ outer cestami, např. rozsáhlé lesy. Užijte si trasování a podezřelosti hned hlaste. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Podivné relace a překryvy landuse=*
Ahoj, Dne 21.11.2014 13:52, Petr Vejsada napsal(a): 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 ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Podivné relace a překryvy landuse=*
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@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Podivné relace a překryvy landuse=*
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. Martin Dik ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Podivné relace a překryvy landuse=*
Dne 19.11.2014 16:29, Petr Vejsada napsal(a): 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. 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 ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Nevykreslující se les
Dne 10.10.2014 13:58, Marián Kyral napsal(a): -- Původní zpráva -- Od: Jan Kouba kouba.ho...@gmail.com Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 10. 10. 2014 13:49:49 Předmět: Re: [Talk-cz] Nevykreslující se les Dne Čt 9. října 2014 22:34:09, Marián Kyral napsal(a): Dne 9.10.2014 19:59, Michal Pustějovský napsal(a): Zrovna jsem narazil na kus lesa, který se ze mně záhadných důvodů nevykresluje: http://www.openstreetmap.org/way/204803423 Ani JOSM validátor mi nic nenahlásil. Poslední úprava z doby cca před rokem je moje, vykreslovat se přestal v nedávné době. Nenapadá někoho něco? Ahoj, vypadá to podivně. Myslel jsem, že je nějaký problém se renderem, ale na osmapa.pl to taky na většině zoomů chybí. Třeba 16 [1] je v pořádku, ale výš nebo níž se to zase ztratí. [1] http://osmapa.pl/#lat=49.5787lon=18.1793z=16m=ms Možná bych zkusil udělat nějakou malou změnu, abych přinutil render oblast znova vykreslit. No to snad radši ne. Pokud chcete překreslit dlaždici, stačí přejít na URL URL dlaždice/dirty (např. http://b.tile.openstreetmap.org/17/72154/44691.png/dirty http://b.tile.openstreetmap.org/17/72154/44691.png). Sám jsem to musel použít, když jsem opravoval polygony lesů na jihu Čech a na openstreetmap.org se z nějakého důvodu neaktualizovaly dlaždice na nižších úrovních přiblížení. Jo ták. Tohle mne nenapadlo, že tam něco takového funguje. Přitom je to logické. Vidím tam jen jeden problém. Jak poznám, že se dlaždice už překreslila? Pokud udělám nějakou změnu (třeba natrasuji ta dvě chybějící políčka hned vedle lesa), poznám naprosto přesně, že se to překreslilo a les stále chybí. Informace o dlaždici by měl vracet /status na konci URL dlaždice. Je tam i datum + čas posledního renderování. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Oprava relaci landuse=forest
Ahoj, tak všechny old-style landuse=forest multipolygony v ČR s více než jednou outer cestou by měly být ručně přetagované z cest na relaci. Zůstaly mi dva německé lesy co přesahují pár metrů na Šumavě a pak asi 25 Lasu Państwowych, které Polákům nebudu rozbíjet. Předem se omlouvám pokud jsem něco rozbil, pár polygonů byly fakt lahůdky. Některé byly pěkně zprzněné LPIS tracerem, takže prosím při trasování neignorovat errory a warningy v JOSM :-) Pozornost by si zasloužila relace https://www.openstreetmap.org/relation/24276, pokud ji má někdo v rajónu. Vloni se 80% jejích uzlů podařilo někomu posunout asi o 200 metrů mimo a od té doby na ten posunutej les pár lidí přilepilo další objekty :-) Hodinu jsem ho po skupinkách uzlů opatrně přesouval zpět, ale opravdu negarantuju že jsem nepoškodil něco jiného. Martin Dne 27.9.2014 22:10, Petr Vejsada napsal(a): Ahoj, tak to mám nějako nachystané. Viděl bych to na 3 kola. V prvním kole zkusit 5-10 lesů, když OK, tak zbytek lesů, které nepřesahují hranice ČR. V posledním kole lesy, které přesahují hranice ČR; těch je 279, což není zrovna málo. Některé jsou takové, že se jen dotknou sousedního státu, jiné naopak - jen malým kouskem lezou do ČR. Co s nimi? Přesunout všechny tagy z outer cesty na relaci nebo přesunovat jen landuse? K tomu rušení relací s jednou cestou - třeba Poláci to takto mají úplně běžně. Nevím proč, možná při importu vytvářeli vždycky relace. Nicméně stále si nejsem jistý, zda by se to opravdu mělo udělat a co taková akce vlastně přinese? JOSM už několik hodin validuje pokusnou várku :-) Dne Ne 21. září 2014 16:55:53 jsi napsal(a): Ahoj, On 19.9.2014 08:09, Petr Vejsada wrote: http://pedro.poloha.net/osm/lesy3.csv http://pedro.poloha.net/osm/lesy3.sql je zde vidět source=* i tag landuse na relaci. Probral jsem podmnožinu wlanduse=forest + rlanduse=NULL, relace s cestami nad 600 uzlů proklikal, zbytek namátkově. Takže u nich se může tag landuse=forest přesunout z outer cesty na relaci, aspoň já už nevidím další zádrhely. Podmnožina wlanduse=forest + rlanduse=forest má cca 175 relací, tam se teoreticky nabízí vymazat landuse na outer cestě. Na množině wlanduse=NULL a rlanduse=forest není co opravovat :-) Jiné kombinace by se neměly vyskytovat, jednu větší haluz (landuse=farm les u Tachova) a pár drobností jsem opravil. Martin PS: tipy na další opravy v budoucnu: (a) zbytečné relace lesů s jedinou cestou; (b) spousta inner cest v relacích je otagovaných jako landuse=forest, přitom podle bingu to má být mýtina. -- Petr, p...@propsychology.cz p ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] ruian tracer bug?
Ahoj, Dne 8.10.2014 12:55, Marián Kyral napsal(a): No teď se v tom hrabe Martin Švec. Takže úplně sám už nejsem. Viz mail tady v konferenci. To napojování jsem už cca třikrát přepisoval, pokaždé jsem získal další puzzle do skládačky a podařilo se to dostat do stavu, že v 99% případů to funguje dobře a to zbývající procento generuje chyby, které lze po získání nějakých zkušeností docela lehce a rychle řešit. Ocásky, překrytí místo ukousnutí. 99 je u LPISu příliš optimistické číslo, to by mě k úpravám nedonutilo :-) Možná bych se mohl vrhnout na dokumentaci, Hodil by se mi souhrnný popis, o co všechno se teď Tracer snaží, dešifrování ze zdrojáku stojí vzácný čas. A aktuálně bych potřeboval search patterny, které existující Ways a Relations zahrnovat do napojování uzlů a které do ořezů. Ideálně jako výrazy landuse=* | natural=wood | natural=scrub, zkouším filtrování kandidátů přes SearchCompiler.Match (http://josm.openstreetmap.de/doc/org/openstreetmap/josm/actions/search/SearchCompiler.Match.html) Martin V tomhle patří velký dík Petrovi Vejsadovi, za prvotní impuls. Vždyť já původně chtěl jen změnit url, které bylo natvrdo v kódu. No a když už jsem rozjel kompilaci, tak jsem přidal tohle, upravil támto a pak se to celé nějak rozrostlo ;-) Marián -- Původní zpráva -- Od: Petr Schönmann pschonm...@gmail.com Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 8. 10. 2014 11:35:36 Předmět: Re: [Talk-cz] ruian tracer bug? Já se divím Mariáne, že to všechno celé děláš sám. Cožpak se nenajde někdo v OSM komunitě kdo by pomohl? Napojování co já vím řešíš už dost dlouho. Tak kdyby se našla nějaká další hlava, dali by jste to dohromady třeba i rychleji. Dne 8. října 2014 11:24 Marián Kyral mky...@email.cz napsal(a): Ahoj, Vypíchl bych tam tu větičku at least for now ;-) Momentálně je rozdíl mezi tím jak funguje trasování budov a LPIS. RUIAN budovy - umí aktualizovat existující geometrii, neumí multipolygony, LPIS - Umí multipolygony, neumí aktualizaci existujících polí (protože multipolygony). Věřím, že poté, co se povede finálně vyřešit problémy s napojováním na ostatní cesty, bude možné podporované vlastnosti obou tracerů sloučit. Tedy, že oba budou umět aktualizovat existující cesty a to včetně multipolygonů. Pak bude možné přidávat další možnosti, jako třeba aktualizace tagů. Ty teď mají nízkou prioritu, vzhledem k tomu, že existují jiné způsoby, jak to udělat. Marián -- Původní zpráva -- Od: Petr Schönmann pschonm...@gmail.com Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 8. 10. 2014 10:51:00 Předmět: Re: [Talk-cz] ruian tracer bug? Its not bug its a Feature ! https://github.com/mkyral/josm-tracer/issues/3#issuecomment-42116344 Dne 8. října 2014 10:40 Michal Grézl michal.gr...@openstreetmap.cz napsal(a): Kdyz necham tracerem updatnout budovu, ktera uz existuje a ma stejnou geometrii jako ruian budova, neupdatuji se tagy. Pomuze jen starou budovu smazat a kliknout na ni znovu. -- Michal Grézl http://openstreetmap.cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] opět chyba placeholder
Ahoj, FYI, od soboty překuchávám střeva Traceru. Po delším váhání a pokusech jsem opustil kód ConnectWays a začal od nuly, protože ten kód mi přišel příliš náchylnej na chyby při složitějších operacích. Základní idea o co se snažím: (*) Přidávání a editace uzlů+cest+multipolygonů neprobíhá přímo nad objekty JOSM, ale nad novými objekty EdNode, EdWay, EdMultipolygon. Které fungují stejně jako Node, Way, Relation. (*) Ed-objekty si pamatují jestli vznikly z původních objektů DataSetu nebo jsou úplně nové a jestli byly editované. Dále samy sledují, které Ed-objekty a původní JOSM objekty je zrovna využívají (referrers). A dohromady se to pokouší být natolik blbuvzdorné, aby to odhalilo pokusy o nekorektní použití ;-) (*) Všechny Ed-objekty si automaticky eviduje centrální WayEditor objekt. (*) Příkazy pro JOSM jsou generovány až na konci procesu editace WayEditor objektem. Ten vyhodnotí naráz celou hromadu Ed-objektů a rozhodne co se má přidat, změnit a smazat. A podle toho vygeneruje minimální nutnou sadu příkazů Add/Change/DeleteCommand. Od té chvíle jsou Ed-objekty zamknuté proti další editaci a obsahují finální JOSM objekty Node, Way, Relation. Teď jsem ve fázi, kdy mechanismus Ed-objektů vypadá že funguje. Nad tím postavený LPIS tracer trasuje a napojuje polygony na existující body, zatím bez ořezu okolních polygonů. Pokusím se kód co nejrychleji začistit a poslat ti alfa verzi ke zkouknutí. Doufám že v průběhu týdne nebo o víkendu. Nemám moc času a API Javy + JOSM se učím za pochodu :-) Obecný ořez polygonů mám zhruba rozmyšlený pro jednodušší varianty s využitím GPCJ2 knihovny. Výhodou by mělo být, že se dá postupně přidávat podpora pro složitější případy, aniž by se to celé rozbilo. Pár pracovních poznámek viz http://wiki.openstreetmap.org/wiki/User:Maatts, úplně na konci. Martin Dne 7.10.2014 8:02, Marián Kyral napsal(a): Ahoj, Tak jsem na to včera zase narazil. Naklikal jsem nějaké pole, vše v pohodě, ale nahrávání spadlo na missing placeholder chybu. Tak jsem si danou oblast stáhl do nové vrstvy a tam všechny pokusy skončily na Deleted node referrenced chybě. Dobrá zpráva je, že to dokáži zreprodukovat a vím, kde je problém. Špatná zpráva je, že je to o tom, že, narozdíl od budov, v LPIS traceru zatím nijak neřeším nahrazení již existující cesty. Tím, že se nově zpravovávají i multipolygony, se to celé zkomplikovalo a moc se mi do toho nechtělo. Ale možná už je na čase se na to podívat. Zatím alespoň zkouším to, že pokud narazím na tuto chybu, tak všechno zahodím a vypíšu chybu, že při trasování nastala chyba. Teoreticky by to mělo zabránit tomu, aby se pokazila data. Ovšem za cenu toho, že některé polygonu půjde natrasovat jen s pomocí klávesy Ctrl - zakáže se napojování a je to potřeba udělat ručně. Marián -- Původní zpráva -- Od: Marián Kyral mky...@email.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 2. 10. 2014 19:58:33 Předmět: Re: [Talk-cz] opět chyba placeholder No a teď mi poraď, jak to mám opravit :-D Podle mne se stane něco už dávno před tím. Nebo je to třeba o tom, jaké id ten nový objekt dostane. Nebo třeba záleží, kam přesně klikneš. Možností je hodně, řešení jen jedno. Marián -- Původní zpráva -- Od: Zdeněk Pražák zpra...@seznam.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 2. 10. 2014 19:19:03 Předmět: Re: [Talk-cz] opět chyba placeholder tak nevím, dnes jsem to naklikal hned napoprvé, zatímco včera mi na uvedeném poli josm pořád hlásil chybu. asi byla včera špatná konstelace hvězd Pražák Dne 2. října 2014 18:40 Marián Kyral mky...@email.cz mailto:mky...@email.cz napsal(a): Asi tě nepotěším, ale normálně jsem to naklikal a nic. Data furt koniistetntní :-( Můžeš to zkusit ještě jednou a pokud se ta chyba podaří zreprodukovat, poslat mi pokud možno co nejpřesnější postup? Díky, Marián -- Původní zpráva -- Od: Zdeněk Pražák zpra...@seznam.cz mailto:zpra...@seznam.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org mailto:talk-cz@openstreetmap.org Datum: 2. 10. 2014 11:56:35 Předmět: Re: [Talk-cz] opět chyba placeholder ano dělal jsem to v nově spuštěném JOSM Dne 2. října 2014 9:14 Marián Kyral mky...@email.cz mailto:mky...@email.cz napsal(a): OK. Díky za info. Odpoledne ve vlaku se na to mrknu. Když jsi to přetrasovával, dělal jsi to v restartovaném josm? Marián -- Původní zpráva -- Od: Zdeněk Pražák zpra...@seznam.cz mailto:zpra...@seznam.cz Komu:
Re: [Talk-cz] opět chyba placeholder
Dne 7.10.2014 13:19, Marián Kyral napsal(a): Ad nová verze) nevím jak jsi na tom s githubem, možná by bylo jednodušší sdílet změny přes fork, případně tě můžu přidat a můžeš commitovat přímo do mého repositáře. Záleží na tobě. Jo, github je dobrý nápad. Mrknu co to obnáší. Zatím jsem commitování změn neřešil, od soboty jsem stovky řádků 3x zahodil a napsal znova :-) Chci se v dohledné době dostat aspoň na úroveň současného LPIS traceru. Aby to bylo použitelné v testing větvi a nevyvíjeli jsme paralelně oba totéž. (Zatím ignoruju RUIAN tracer, ale ten může existovat na connectWays, dokud neověříme že jdeme správnou cestou.) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] importy LPIS
Ahoj, Dne 1.10.2014 15:35, jiri ja napsal(a): Přeji pěkný den všem diskutujícím, občas přispívám do OSM map, ale mailing list sem zatím jen příležitostně četl. Začínám mít ale smíšený pocit s klikacích importů s LPIS a proto se ozývám. Jistě jsou to data, která v OSM zatím nejsou. Ale krom toho, že to krásně přibývá, vnímám toto obrovské množství dat spíše negativně. LPIS obsahuje evidenci zemědělské půdy, na kterou čerpají zemědělci dotace. (jestli je to jinak tam mě opravte, ale asi to na věci nic zásadního nemění). Praxe je taková, že se rozrůstají po mapě území, kde je naklikáno z LPIS pole a trvalé travní porosty (což není jen louka, ale také tráva na poli – to tu ale rozebírat nechci). Mapa je jakoby téměř plošně plná ale ne moc přehledná. Mapnik podle mě kreslí tyto dvě kultury zbytečně výrazně. To je IMHO problém renderingu... Např. já mám v Locusu upravený styl mapy se světlými barvami a proti původním bílým plochám je to radikální pokrok. Rozlišit v mapě travnatou plochu od rozoraného pole se někdy zatraceně hodí :-) I ty škvíry mezi LPIS poli co mi napřed vadily se ukazují jako užitečné, protože jsou často průchozí i když tam není cesta. Hlavní je, že ale chybí mnohem důležitější věci, které už tam nikdo nejspíš nedokreslí. Myslím tím především stromy rostoucí mimo les: různé malé „lesíky“ stromy po mezích mezi poli – často celkem souvislé porosty, větrolamy…, což jsou pro orientaci mnohem důležitější věci jak volné plochy polí. Dále různé neobdělávané plochy, které jsou mokré nebo naopak moc suché či kamenité na to aby se intenzivně zemědělsky obdělávaly. Na nich rostou keře, stromy a samozřejmě tráva - není to les. Jsem z Vysočiny a tyto části krajiny jsou pro ni typické. Mezi tyto plochy patří i velká část maloplošných chráněných území. V mapě taky chybí všelijaké rumiště a smetiště, často naprosto neprůchodné území. Naprosto souhlasím, taky mám rád drobné detaily v krajině, protože OSM používám jako turistickou mapu při (cyklo)turistice. Jenže toto bohužel z žádné databáze asi nedostaneme... Takže zůstává ruční dokreslování z bingu a terénního průzkumu, dobrovolníci jsou vítaní. Problém možná je v tom že samotné OSM mapovaní takovéto krajiny ani moc neumožnuje. Mapy SHOCart rozptýlenou zeleň značí zeleným kolečky a Cenia DMU 25 jednotlivými smrčky. Ani v jednom případě se ale nejedná o konkrétní strom ve smyslu natural= tree. Obecně mě nenapadá žádná mapa, která by plošně značila ornou půdu a jen některé značí louky. Dnes sem narazit na případ kde při oklikání LPIS zmizelo území onačené jako natural=scrub (Jedná se o sadu změn 25693608 a asi cestu 213885832) a je tam jakési landuse=meadow (cesta 305184257 jako část relace) které je navíc podle mě v LPIS špatně. Do přílohy přikládám ilustrační obrázky, ale nevím, jestli to projde. To že území blízké Korouhve není označené jako residential jen ilustruje, že to důležité je v bílých místech. Jedná se o toto místo: http://osm.org/go/0J7Euz5C4- Oblast mám na svědomí já. Pracuju tak, že napřed si naklikám větší plochy tracerem. Pak se k nim vracím a podle Bingu a dalších zdrojů (KM, RUIAN, ...) doplňuju bílá místa mezi LPIS polygony, dokresluju cesty, plochy navazuju na okolní lesy, křoví apod. Je to práce zdlouhavá, takže přibývá pomaleji než LPIS polygony. Když se podíváš kolem Čisté, Trstěnic, Karle, Ostrého Kamene, nedávno u Lubné a Budislavi, tam už jsem tyhle detaily dodělával. Ad smazaná landuse=scrub plocha. Tak tu si přesně pamatuju, cizí práci mažu málokdy a nerad :-) Plochu ale tracer tak zpotvořil, že než bych ji opravoval, radši jsem ji dočasně smázul. Vůči Bingu mi totiž z velké části neseděla. Původní pás křovin neobsahoval pruh louky mezi křovinami a část louky v SV části, která tam podle Bingu opravdu je. Jakmile se k místu dostanu, samozřejmě doplním i s ostatními remízky v okolí. Ale jestli víš přímo z terénu, že ty křoviny byly správně, rád je vrátím přesně do původního stavu. Chybějící landuse=residential můžeš doplnit, prostě je to věc na kterou se nesoustředím :-) Plus nemám rád nahrubo obtažené residential oblasti kolem vesnic, které se pak zasahují do půlky lesů a polí. Pokud máš k té oblasti další připomínky, budu jen rád. Tak sem si postěžoval, … přeji všem přispěvatelům hezký den. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Oprava relaci landuse=forest
Dne 29.9.2014 16:51, Petr Holub napsal(a): Ahoj, no tedy, to jsem nevěděl, že landuse je i na inner. Myslím, že landuse=forest by se mělo z těch inner odstranit. Co by znamenalo, kdyby na té inner bylo landuse=meadow? Má se to chápat, že v té díře je louka? Nebo je to chyba a má to být tak, že je outer cesta lesa a pak je také inner cesta lesa? ja to teda videl pouzivane (a sam take pouzival) tak, ze kdyz je multipolygon les, tak ze jako inner cesta tam muze byt treba zarustajici mytina (landuse=scrub) a docela to podle mne mapuje realitu = les bezprostredne navazuje na nejake jine pokryti zemskeho povrchu. To je normální tagování, používám denně. Tag popisující plochu multipolygonu je na relaci a tag na inner cestě popisuje realitu uvnitř té inner cesty (rybník, mýtina, ...). Outer cesta je bez tagů, prázdné díry v multipolygonu jsou bez tagů. Potíž jsou old-style multipolygony, kde landuse tag není na relaci, ale na všech inner i outer cestách. Další verze je, že inner cesty nejsou otagované a landuse je na outer cestě. A pak je hromada multipolygonů, kde je to různě pomíchaný :-) Na wiki [1] v sekci Detailed tagging jsou doporučený pravidla renderování, který mi ovšem ne úplně sedí s reálnými výstupy. Výsledek je, že kdykoliv někdo sáhne do old-style multipolygonu, může to dopadnout všelijak. Otevřel jsem ten problém u landuse=forest, protože při importu LPISu se teď dost zasahuje do lesů. Ale platí to obecně u všech multipolygonů, viz [2]. Tam ale zavrhli plošnou opravu, protože old-style multipolygonů v OSM je čtvrt milionu :-) [1] http://wiki.openstreetmap.org/wiki/Relation:multipolygon [2] https://lists.openstreetmap.org/pipermail/dev/2014-June/027910.html Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Oprava relaci landuse=forest
Dne 29.9.2014 15:10, Petr Vejsada napsal(a): On Mon, Sep 29, 2014 at 02:00:54PM +0200, Martin Švec - OSM wrote: Ahoj, napadl mě možný zádrhel u inner cest. Jak budou interpretované díry v multipolygonech, pokud přesuneme landuse=forest z outer cesty na relaci, ale přitom ten tag necháme na inner cestách? no tedy, to jsem nevěděl, že landuse je i na inner. Myslím, že landuse=forest by se mělo z těch inner odstranit. Co jsem zatím prostudoval, tak by mělo být bezpečné odebrání landuse=forest z inner cest, za předpokladu že je to jediný tag spolu s tagy source/created_by/name. Pokud je tam víc tagů, čistě teoreticky můžeme poškodit mapu (napadá mě ostrůvek listnatého lesa uvnitř jehličnatého). Zkusím vyselektovat z databáze jestli něco takového hrozí... (Bavíme se o podmnožině old-style multipolygonů bez otagované relace.) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Oprava relaci landuse=forest
Dne 29.9.2014 17:54, Martin Švec - OSM napsal(a): Dne 29.9.2014 15:10, Petr Vejsada napsal(a): On Mon, Sep 29, 2014 at 02:00:54PM +0200, Martin Švec - OSM wrote: Ahoj, napadl mě možný zádrhel u inner cest. Jak budou interpretované díry v multipolygonech, pokud přesuneme landuse=forest z outer cesty na relaci, ale přitom ten tag necháme na inner cestách? no tedy, to jsem nevěděl, že landuse je i na inner. Myslím, že landuse=forest by se mělo z těch inner odstranit. Co jsem zatím prostudoval, tak by mělo být bezpečné odebrání landuse=forest z inner cest, za předpokladu že je to jediný tag spolu s tagy source/created_by/name. Pokud je tam víc tagů, čistě teoreticky můžeme poškodit mapu (napadá mě ostrůvek listnatého lesa uvnitř jehličnatého). Zkusím vyselektovat z databáze jestli něco takového hrozí... (Bavíme se o podmnožině old-style multipolygonů bez otagované relace.) Takže ano, hrozí, přesně ve dvou případech :-) https://www.openstreetmap.org/relation/23976 https://www.openstreetmap.org/relation/25716 ...jednou les uvnitř lesa, podruhé les rychlerostoucích dřevin, oboje rendrováno jako díra. V obou případech důsledky editování old-style multipolygonů kvůli LPISu. https://www.openstreetmap.org/way/26108222 https://www.openstreetmap.org/relation/26557 ...tady jsou díry v pořádku, i když mají i jiné tagy. A jedna nesouvisející zajímavost. Uniká mi logika dvou multipolygonů, z nichž každý popisuje část Dendrologické zahrady v Průhonicích a mají společnou outer cestu: https://www.openstreetmap.org/relation/2065821 https://www.openstreetmap.org/relation/2066402 Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Oprava relaci landuse=forest
Ahoj, On 27.9.2014 22:10, Petr Vejsada wrote: Ahoj, tak to mám nějako nachystané. Viděl bych to na 3 kola. V prvním kole zkusit 5-10 lesů, když OK, tak zbytek lesů, které nepřesahují hranice ČR. V posledním kole lesy, které přesahují hranice ČR; těch je 279, což není zrovna málo. Souhlas, klidně bych to rozdělil i do více dávek. Ať je prostor na kontrolu. Některé jsou takové, že se jen dotknou sousedního státu, jiné naopak - jen malým kouskem lezou do ČR. Co s nimi? Asi zatím vyloučit?? Přesunout všechny tagy z outer cesty na relaci nebo přesunovat jen landuse? Cesta může mít tagy, které se týkají jen cesty a ne plochy. Např. barrier=fence. Co jsem upravoval ručně, tak jsem přehazoval ještě source=uhul:wms/ortofoto, ale zbytek nechával na cestě. K tomu rušení relací s jednou cestou - třeba Poláci to takto mají úplně běžně. Nevím proč, možná při importu vytvářeli vždycky relace. Jojo, všiml jsem si. Ale to není na pořadu dne :-) Nicméně stále si nejsem jistý, zda by se to opravdu mělo udělat a co taková akce vlastně přinese? No, hrabu se v landuse cca 2 měsíce. Plus za tento týden jsem ručně upravil už pár desítek multipolygonů, které jsme vyloučili kvůli více outer cestám. Proč jsem tohle téma nadhodil: (*) JOSM (ale např. i data z osm.paws.cz v Locusu) špatně zobrazují les, když se okraj postaru tagovaného multipolygonu při editaci rozdělí na víc outer cest. Jak opravuju případy s více outer cestami, tak je to nejčastější závada. Typicky u složitých multipolygonů a v okolí měst (často editované polygony). (*) Multipolygon je mnohem náchylnější na problémy, když se do něj něco přidá nebo odebere. Např. dvě různě tagované outer cesty, nebo inner cesta omylem otagovaná jako outer, která z lesa náhodně udělá rybník, hřiště, parkoviště, pole (zatím do deseti kusů co jsem opravoval, ale občas jsou to lahůdky). (*) https://josm.openstreetmap.de/changeset/7569/josm ... warning v JOSM ;-) Čili spíš preventivní důvody, jak se vyhnout budoucím problémům. Třeba někoho napadnou další... Jestli máš dojem, že je to zbytečně velký zásah do dat v porovnání s přínosem, klidně to můžeme zrušit :-) Já doopravuju zbývající polygony s více outer cestami a jednou začas jen pustím select, co kdo zase rozbil. Martin JOSM už několik hodin validuje pokusnou várku :-) Dne Ne 21. září 2014 16:55:53 jsi napsal(a): Ahoj, On 19.9.2014 08:09, Petr Vejsada wrote: http://pedro.poloha.net/osm/lesy3.csv http://pedro.poloha.net/osm/lesy3.sql je zde vidět source=* i tag landuse na relaci. Probral jsem podmnožinu wlanduse=forest + rlanduse=NULL, relace s cestami nad 600 uzlů proklikal, zbytek namátkově. Takže u nich se může tag landuse=forest přesunout z outer cesty na relaci, aspoň já už nevidím další zádrhely. Podmnožina wlanduse=forest + rlanduse=forest má cca 175 relací, tam se teoreticky nabízí vymazat landuse na outer cestě. Na množině wlanduse=NULL a rlanduse=forest není co opravovat :-) Jiné kombinace by se neměly vyskytovat, jednu větší haluz (landuse=farm les u Tachova) a pár drobností jsem opravil. Martin PS: tipy na další opravy v budoucnu: (a) zbytečné relace lesů s jedinou cestou; (b) spousta inner cest v relacích je otagovaných jako landuse=forest, přitom podle bingu to má být mýtina. -- Petr, p...@propsychology.cz p ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Pravděpodobně chyba v traceru
Dne 24.9.2014 14:23, Marián Kyral napsal(a): Ahoj, Podotykam, ze validator zcela zjevne neodchyti problem vzdy, protoze neuploaduju pokud mi hlasi chyby, presto se mi povedlo nekolik uploadu s vyse uvedenyma chybama. Jak jsem psal výše, něco není jako chyba, ale jako pouze varování (cesty protínající sebe sama). Taky záleží, jakou verzi JOSM používáš. Momentálně se věci kolem validací docela hodně mění. Už mi prošly skrz JOSM i problémy, kde nehlásil ani error ani warning. Nevím jak to vzniklo a je mi to divný, ale sousední plocha překryla trasované pole tak šikovně že přitom nevytvořila žádnou z obvyklých chyb/warningů. JOSM nehlásil ani warning překrývání landuse polygonů. Přišel jsem na to až dodatečně, jak se vracím k natrasovaným oblastem a vylepšuju v nich detaily. Mimochodem, co takhle nejaky zaskrtitko, ktery vypne overlay hlasek o trasovani? Stejne se zobrazujou klidne i nekolik minut po akci ... Však to nevadí ne? :-D Já ty hlášky u sebe ve zdrojáku zrušil, protože mě lezly na nervy :-) Tím zpožděním ztrácí jakýkoliv smysl. Osobně bych se vykašlal na checkboxy a v případě úspěchu nic nezobrazoval, co se natrasovalo je přece vidět v mapě. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] Oprava relaci landuse=forest (was: Re: oprava relace 25469)
Ahoj, On 19.9.2014 08:09, Petr Vejsada wrote: http://pedro.poloha.net/osm/lesy3.csv http://pedro.poloha.net/osm/lesy3.sql je zde vidět source=* i tag landuse na relaci. Probral jsem podmnožinu wlanduse=forest + rlanduse=NULL, relace s cestami nad 600 uzlů proklikal, zbytek namátkově. Takže u nich se může tag landuse=forest přesunout z outer cesty na relaci, aspoň já už nevidím další zádrhely. Podmnožina wlanduse=forest + rlanduse=forest má cca 175 relací, tam se teoreticky nabízí vymazat landuse na outer cestě. Na množině wlanduse=NULL a rlanduse=forest není co opravovat :-) Jiné kombinace by se neměly vyskytovat, jednu větší haluz (landuse=farm les u Tachova) a pár drobností jsem opravil. Martin PS: tipy na další opravy v budoucnu: (a) zbytečné relace lesů s jedinou cestou; (b) spousta inner cest v relacích je otagovaných jako landuse=forest, přitom podle bingu to má být mýtina. ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] oprava relace 25469
Ahoj, díky moc, je toho poněkud víc, ale zase žádná tragedie. Zkusím večer namátkou projít záludnosti, které se tam vyskytují. Dokážeš zpřísnit kritéria o tyhle podmínky?: * relace musí mít pouze jedinou outer cestu * ta outer cesta není členem žádné jiné relace * relace nemá žádné jiné tagy než type=multipolygon * outer cesta má kromě landuse=forest i tag source=uhul:wms To by mohlo odfiltrovat většinu nejasných případů. Díky. Martin Dne 17.9.2014 15:06, Petr Vejsada napsal(a): Ahoj, On Wed, Sep 17, 2014 at 02:37:53PM +0200, Marián Kyral wrote: http://pedro.poloha.net/osm/lesy.csv Díky. Bylo by možné tam ještě přidat počet uzlů na cestě? A jak tak koukám, je tam, stejné url v některých případech je v jedné relaci více outer cest. Třeba http://www. openstreetmap.org/relation/23884 Asi následek dělení na 2000 uzlů. Může být, ovšem vysvětlení může být daleko více, třeba - outer - les - inner - louka uvnitř lesa - outer - les uvnitř té louky nebo outer - flek lesa, outer - flek lesa někde úplně jinde a pozor! - outer - flek lesa, outer - flek lesa, outer - flek louky a dohromady je to multipolygon, který ovšem nesdružuje les, ale třeba chráněnou oblast, do které patří dva lesy a jedna louka. Takže je třeba být pozorný při tom šoupání tagů z cesty na relaci, protože ty tagy na relaci vůbec patřit nemusí. -- Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] oprava relace 25469
Ahoj, On 18.9.2014 20:04, Petr Vejsada wrote: Ahoj, Dne Čt 18. září 2014 15:36:39 jsi napsal(a): * relace musí mít pouze jedinou outer cestu * ta outer cesta není členem žádné jiné relace * relace nemá žádné jiné tagy než type=multipolygon * outer cesta má kromě landuse=forest i tag source=uhul:wms To by mohlo odfiltrovat většinu nejasných případů. 1646 http://pedro.poloha.net/osm/lesy2.csv http://pedro.poloha.net/osm/lesy2.sql Pěknej select :-) hodně to ubylo při přidání posledních dvou podmínek, jinak ubylo vždy jen pár kusů. A ty poslední podmínky - nejsou zbytečné? Jestli to správně chápu, jde o to vytvořit seznam, u kterého se nebudeme muset bát udělat ten přesun tagů na relaci. Na to, myslím, stačí první dvě podmínky. Snažil jsem se omezit jen na původní uhul:wms lesy. Ale jak jsem proklikal rozdíly mezi prvním a druhým seznamem, určitě se může vyhodit source=uhul:wms. Lesů bez source nebo s jiným source je hromada. U omezení jen na type=multipolygon bych byl opatrnější, které konkrétní relace se kvůli tomu vyřadily. Btw, měl bys tip na slušný návod ke zprovoznění lokální kopie OSM databáze? Kdybych se o víkendu náhodou nudil... Vyžadováním posledních dvou podmínek se zbytečně připravíme o opravu asi jednoho tisíce relací, což je škoda, ne? Něco mi uteklo? Klidně to pak pustím, mám na tyhle věci funkce, které bude potřeba jen drobně upravit. Fajn :-) V sobotu se důkladněji podívám co vlastně hodláme rozbít, a pak bych se ozval. Díky Martin Díky. Martin Dne 17.9.2014 15:06, Petr Vejsada napsal(a): Ahoj, On Wed, Sep 17, 2014 at 02:37:53PM +0200, Marián Kyral wrote: http://pedro.poloha.net/osm/lesy.csv Díky. Bylo by možné tam ještě přidat počet uzlů na cestě? A jak tak koukám, je tam, stejné url v některých případech je v jedné relaci více outer cest. Třeba http://www. openstreetmap.org/relation/23884 Asi následek dělení na 2000 uzlů. Může být, ovšem vysvětlení může být daleko více, třeba - outer - les - inner - louka uvnitř lesa - outer - les uvnitř té louky nebo outer - flek lesa, outer - flek lesa někde úplně jinde a pozor! - outer - flek lesa, outer - flek lesa, outer - flek louky a dohromady je to multipolygon, který ovšem nesdružuje les, ale třeba chráněnou oblast, do které patří dva lesy a jedna louka. Takže je třeba být pozorný při tom šoupání tagů z cesty na relaci, protože ty tagy na relaci vůbec patřit nemusí. -- Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz -- Petr, p...@propsychology.cz p ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] oprava relace 25469
On 17.9.2014 13:00, Marián Kyral wrote: -- Původní zpráva -- Od: Petr Vejsada o...@propsychology.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 17. 9. 2014 12:09:48 Předmět: Re: [Talk-cz] oprava relace 25469 Ahoj, On Wed, Sep 17, 2014 at 09:34:42AM +0200, Marián Kyral wrote: musíme si říct, co přesně se má udělat. Najít všechny polygony, které mají landuse=forest a jsou členy relace typu multipolygon jako outer. Odebrat tagy landuse a source tomuto polygonu a dát je na popsanou relaci. Jo? Jo. Já hlavně chtěl zjistit, kolik toho je. Ono těch lesů jako multipolygon asi nebude až tak moc. Třeba v Beskydech to je jeden velký multipolygon. Souhlas, stačí pro začátek vyjet seznam. Třeba se bavíme o deseti multipolygonech :-) Já jen nahodil dotaz do pléna, protože jsem si všiml že to je systematický jev po celé republice. Pokud bude těch multipolygonů do stovky, není problém je opravit v JOSM. Pokud jich bude víc, dají se zpřísnit kritéria výběru a zbytek projít ručně. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] oprava relace 25469
Ahoj, A ještě jedna věc. Neměl by být ten tag landuse=forest na relaci? ten problém je IMHO obecnější. Co jsem si všiml, multipolygony lesů se source=uhul:wms mají tagovanou pouze outer cestu a relace tagovaná není. Jak se teď hrabe do velkých ploch díky LPISu, je to náchylné k chybám. Mě se od víkendu podařilo běžným postupem rozbít už dva rozsáhlé lesy na různých místech republiky. Z jednoho vzniklo parkoviště kvůli starším nesmyslům v tagování členů relace. A druhý les zmizel úplně, protože jsem rozdělil vnější cestu na víc úseků kvůli limitu uzlů. Což bez tagu na relaci např. JOSM už neinterpretoval jako les. Nešlo by ty lesní multipolygony nějak hromadně vyhledat v databázi a přesunout landuse=forest z outer cesty na relaci? Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] opět problém placeholder
On 14.9.2014 21:06, Marián Kyral wrote: Ahoj, posledně jsem si danou oblast natáhl do JOSM a chybějící pole jsem naklikal znova. Většina bodů se použila znova, ty ostatní jsem pomocí validátoru smazal. Dle všeho klikáš moc rychle a máš pomalejší počítač, takže se ti podaří vyvolat dvě tracer vlákna a ty si ta data navzájem přepisují. Nicméně snad se to brzo podaří vyřešit. Martin Švec mi poslal vylepšenou verzi Traceru, která tento problém řeší. Jen co otestuji, uvolním. Doufám, že co nejdříve. Ahoj, moje verze LPIS traceru mezitím prošla mnohahodinovým testováním. Výjimek radikálně ubylo, ale pořád něco zůstává. Asi 4x jsem narazil na Deleted node referenced. A jednou jsem skončil na Placeholder chybě, ale bylo to poté co jsem zkusil uploadnout data po Deleted node referenced výjimce. Mezitím jsem si zvykl v ošemetných místech trasovat s Ctrl a překryvy opravit ručně, od té doby nebyla výjimka žádná ;-) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Odstávka LPIS
Ahoj, díky za průzkum, zkusím se od toho odpíchnout dál. Martin Dne 9.9.2014 8:08, Jiri Klement napsal(a): Ahoj, kouknul jsem na ten heapdump v Eclipse memory analyzer. Problem je, ze JTree, ktera zobrazuje seznam provedenych prikazu v JOSM je prilis velka - priblizne 16k sirka i vyska. Takze kdyz zkousi udelat buffer na vykresleni, tak ma 16k*16k*4=1GB (a to jenom pro vykresleni jednoho radku) + pamet v GTK, kterou v dumpu neuvidim. Netusim, proc je to tak velke, ale zkusil bych ten dialog se seznamem prikazu schovat a zkontrolovat konfiguraci, jestli se tam nejakym omylem nedostali nesmyslne rozmery. -- Jirka 2014-09-09 0:59 GMT+02:00 Martin Švec - OSM o...@maatts.cz: Ahoj, (2) Občas JOSM po kliknutí naráz vyžere celý heap Javy a současně pár giga paměti X server procesu. Zabitím JOSM procesu se vše zas uvolní. Zkouším ještě předchozí verzi JOSM, jestli není bug spíš někde mezi nejnovějším JOSM, Xserverem a nvidia driverem. Pust josm s paremetry -Xmx2048m -XX:+HeapDumpOnOutOfMemoryError (pripadne mensi heap, jde o to, aby pri te chybe pretekl). JOSM spadne a udela javapid.hprof soubor s heapdumpem, do kteryho pak muzem kouknout, co sezralo veskerou pamet. V heapdumpu bude citelna veskera pamet JOSM, takze jestli jeste nepouzivas OsmAuth, tak na nej prejdi, jinak by slo (snadno) vycist tvoje heslo. Heapdump je k dispozici zde: http://uloz.to/xKexoVkr/java-pid9395-hprof-bz2 JOSM verze 7480 s -Xmx1500m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -jar josm-tested.jar java version 1.8.0_11 Java(TM) SE Runtime Environment (build 1.8.0_11-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.11-b03, mixed mode) Koukal jsem do dumpu přes JVisualVM ale žádný jasný leak nevidím. Total bytes: 89 251 549 taky rozhodně neodpovídá tomu, co reálně sežral josm proces. Pořád ve mě roste podezření, že to žere něco mimo VM Javy, například GTK. Mám 6 GB RAM + 4 GB swapu a byl problém vůbec ten dump vyrobit. Při -Xmx2000m a vyšších si vzal josm proces přes 8 GB RAM a sejmul ho OOM killer, než stihl něco uložit. Stack při OutOfMemoryErroru je pokaždé stejný: - java.lang.OutOfMemoryError: Java heap space Dumping heap to /tmp/java_pid9395.hprof ... Heap dump file created [103911020 bytes in 1,262 secs] CHYBA: java.lang.OutOfMemoryError: Java heap space java.lang.OutOfMemoryError: Java heap space at java.awt.image.DataBufferInt.init(DataBufferInt.java:75) at com.sun.java.swing.plaf.gtk.GTKEngine.finishPainting(GTKEngine.java:589) at com.sun.java.swing.plaf.gtk.GTKEngine.finishPainting(GTKEngine.java:580) at com.sun.java.swing.plaf.gtk.GTKPainter.paintTreeCellBackground(GTKPainter.java:1181) at javax.swing.plaf.synth.SynthTreeUI.paintRow(SynthTreeUI.java:554) at javax.swing.plaf.synth.SynthTreeUI.paint(SynthTreeUI.java:359) at javax.swing.plaf.synth.SynthTreeUI.update(SynthTreeUI.java:271) at javax.swing.JComponent.paintComponent(JComponent.java:777) at javax.swing.JComponent.paint(JComponent.java:1053) at javax.swing.JComponent.paintChildren(JComponent.java:886) at javax.swing.JComponent.paint(JComponent.java:1062) at javax.swing.JComponent.paintChildren(JComponent.java:886) at javax.swing.JComponent.paint(JComponent.java:1062) at javax.swing.JViewport.paint(JViewport.java:744) at javax.swing.JComponent.paintChildren(JComponent.java:886) at javax.swing.JComponent.paint(JComponent.java:1062) at javax.swing.JComponent.paintToOffscreen(JComponent.java:5217) at javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:290) at javax.swing.RepaintManager.paint(RepaintManager.java:1252) at javax.swing.JComponent._paintImmediately(JComponent.java:5165) at javax.swing.JComponent.paintImmediately(JComponent.java:4976) at javax.swing.RepaintManager$3.run(RepaintManager.java:811) at javax.swing.RepaintManager$3.run(RepaintManager.java:794) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:794) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:769) at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:718) at javax.swing.RepaintManager.access$1100(RepaintManager.java:62) at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1680) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Odstávka LPIS
Ahoj, Dne 8.9.2014 7:10, Marián Kyral napsal(a): Ahoj, díky ta intenzivní testování. -- Původní zpráva -- Od: Martin Švec - OSM o...@maatts.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org, Marián Kyral mky...@email.cz Datum: 8. 9. 2014 1:28:45 Předmět: Re: [Talk-cz] Odstávka LPIS Ahoj, tak jsem potrápil nejnovější LPIS tracer, díky za pěknou práci :-)) Pár postřehů: (1) Občas vyhodí NullPointerException kdesi hluboko ve stacku swingu uvnitř volání org.openstreetmap.josm.gui.progress.PleaseWaitProgressMonitor$4.run(PleaseWaitProgressMonitor.java:172). Dělá to ještě někomu? Tak tohle jsem ještě neviděl. Některé verze JOSM mi vyhazovaly NPE někde v hloubi gui.painter. Ale už se mi to nějakou dobu nestalo. Dělal mi to už kdysi RUIAN tracer, pak to zmizelo. Nezjistil jsem, jestli to bylo upgradem traceru nebo upgradem z IcedTea na Oraclí Javu. Přijde mi to jako nějaký race, když klikám rychleji než tracer stíhá zavírat dialog. Zkusím večer chvíli klikat z PC v práci s Win7, jestli se něco objeví. (2) Občas JOSM po kliknutí naráz vyžere celý heap Javy a současně pár giga paměti X server procesu. Zabitím JOSM procesu se vše zas uvolní. Zkouším ještě předchozí verzi JOSM, jestli není bug spíš někde mezi nejnovějším JOSM, Xserverem a nvidia driverem. Taky se mi ještě nestalo. Dokonce ani nemám tu doporučovanou volbu -Xmx...m. Ale zase na druhou stranu, mám na všech počítačích minimálně 4GB. Na tom nejnovějším dokonce 16G. Nicméně jsem si všiml, že u hodně velkých polí trvá ta automatika docela dlouho. Nejprve se vypíše, že bylo natrasováno pole, ale ještě pár sekund trvá, než se zobrazí. Dělá ti to u nějakých velkých lánů? Nebo i u pidi políček? Nebo při napojování malého políčka na nějaký obrovský lán, případně les? Je to jasný zacyklený memory leak, mám 6GB RAM ale nezáleží kolik paměti Javě dám, během pár sekund sežere celý heap. Systém jsem v tom zatím nenašel, někdy malé políčko, někdy velký lán. Nejvíc ramky si ale vezme Xorg, možná jen tracer zviditelnil chybu někde hlouběji. No, moje gentoo je směska verzí různých balíků, asi by to chtělo po 7mi letech rolling updates reinstall od nuly :-) (3) Ořezávání okolních polygonů je obecně super, ale místy dělá psí kusy :-) Semtam si vybere špatný směr v cestě LPIS polygonu a místo ořezu udělá zmrveninu připomínající sjednocení. Viz screenshot v příloze -- uprostřed byl remízek v polích, místo ořezu se ve vyznačeném místě rozlezl přes natrasovaný polygon. Ještě častější je vznik části cesty, která leze do hrany mezi dva LPIS polygony a vrací se zpátky sama po sobě. Jo o tom vím. Dokonce to umím i nasimulovat. Co zatím neumím, je to správně vyřešit. Musím si na to sednout, nachystat si testovací příklady a zkoušet možnosti. Mám nějaký nápad, uvidím, jestli zafunguje. Doufám, že se k tomu tento týden dostanu. Na ocásky se snad taky dostane. Zase musím dávat bacha, abych neusekl ten nesprávný kousek ;-) Možná blbý dotaz -- nesnažíš se zbytečně vymýšlet kolo? Základní operace nad (multi)polygony a další geospatial funkce musí přece být dávno někde implementované, včetně ošetření těch okrajových situací. V červenci jsem letmo mrknul na dokumentaci JTS+GeoTools a nevypadá to špatně, navíc tracer už je má jako závislost. Pokud by geometrie JTS šla obalit vrstvou převádějící datový model JOSM tam a zpátky...? (4) Šlo by udělat, aby při stisknuté klávese Ctrl se vynechala funkce ořezu a navázání na cizí polygony? Bylo by to fajn u LPISu i RUIANu. Někdy je rychlejší ručně napojit okolí na čistý polygon, než zkoumat a opravovat následky automatiky. LPIS viz výše. RUIAN zase typicky vykusuje zářezy do sousedících budov co nejsou v RUIANu, nakreslených nepřesně podle KM. Takže musím likvidovat ocásek vyrobený v místě průniku, přitom by stačilo jen ručně posunout uzel sousední budovy kam patří. Určitě. V tom původním traceru se modifikátory používaly. Já to většinou dělám tak, že dám zpět, bod posunu a znova to natracuji. Ale musím si toho všimnout. Já přilehlé non-RUIAN budovy preventivně posouvám pryč z dosahu traceru, pokud předem tuším problémy ;-) Ten modifikátor by se hodil. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Odstávka LPIS
Ahoj, Dne 8.9.2014 16:27, Jiri Klement napsal(a): Ahoj, (1) Občas vyhodí NullPointerException kdesi hluboko ve stacku swingu uvnitř volání org.openstreetmap.josm.gui.progress.PleaseWaitProgressMonitor$4.run(PleaseWaitProgressMonitor.java:172). Dělá to ještě někomu? Tohle se stava, kdyz se provadi zmeny na GUI componentach z jineho nez EDT vlakna. Swing neni threadsafe, veskere updaty GUI by se meli volat pres SwingUtilities.invokeLater. V Josm byval checker, ktery pri kazdem pristupu do GUI ze spatneho vlakna vypsal do konzole stacktrace (zapinalo se to pres propertu a defaultne v svn verzi), ale kdyz jsem ted kratce kouknul, tak ho tam nevidim. To by sedělo se subjektivními zkušenostmi, tipoval jsem race mezi thready :-) (2) Občas JOSM po kliknutí naráz vyžere celý heap Javy a současně pár giga paměti X server procesu. Zabitím JOSM procesu se vše zas uvolní. Zkouším ještě předchozí verzi JOSM, jestli není bug spíš někde mezi nejnovějším JOSM, Xserverem a nvidia driverem. Pust josm s paremetry -Xmx2048m -XX:+HeapDumpOnOutOfMemoryError (pripadne mensi heap, jde o to, aby pri te chybe pretekl). JOSM spadne a udela javapid.hprof soubor s heapdumpem, do kteryho pak muzem kouknout, co sezralo veskerou pamet. V heapdumpu bude citelna veskera pamet JOSM, takze jestli jeste nepouzivas OsmAuth, tak na nej prejdi, jinak by slo (snadno) vycist tvoje heslo. Díky za nasměrování, vyzkouším večer. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Odstávka LPIS
On 8.9.2014 21:18, Marián Kyral wrote:
Dne 8.9.2014 14:58, Marián Kyral napsal(a):
(4) Šlo by udělat, aby při stisknuté klávese Ctrl se vynechala funkce ořezu a navázání na
cizí polygony? Bylo by to fajn u LPISu i RUIANu. Někdy je rychlejší ručně napojit okolí
na čistý polygon, než zkoumat a opravovat následky automatiky. LPIS viz výše. RUIAN
zase typicky vykusuje zářezy do sousedících budov co nejsou v RUIANu, nakreslených nepřesně podle
KM. Takže musím likvidovat ocásek vyrobený v místě průniku, přitom by stačilo jen ručně posunout
uzel sousední budovy kam patří.
Určitě. V tom původním traceru se modifikátory používaly. Já to většinou dělám
tak, že dám zpět, bod posunu a znova to natracuji. Ale musím si toho všimnout.
Já přilehlé non-RUIAN budovy preventivně posouvám pryč z dosahu traceru,
pokud předem tuším problémy ;-) Ten modifikátor by se hodil.
OK. To by mělo být jednoduché. ;-)
Tak hotovo. Bohužel nový způsob distribuce aktualizací momentálně nefunguje
[1]. Tak tady je prozatímní odkaz: http://osm.kyralovi.cz/bin/Tracer-testing.jar
Tomu teda říkám servis :-) Vyzkouším zítra (ehm, vlastně už dneska), teď si
hraju s heap dumpem a někdy bych měl taky jít spát. Prozatím za odměnu
přikládám další chybu. Zas bych tipnul problém souběhu mezi thready, dvě cesty
dostaly stejné dočasné ID??:
org.openstreetmap.josm.data.osm.DataIntegrityProblemException: Prvek {Way
id=-39260 version=0 MVT nodes=[{Node id=-39262 version=0 MV
lat=49.6763737,lon=16.2361224}, .., {Node id=-39319 version=0 MV
lat=49.6764993,lon=16.23612}, {Node id=-39262 version=0 MV
lat=49.6763737,lon=16.2361224}]} nelze přidat do datové sady, jelikož v ní již
je
at
org.openstreetmap.josm.data.osm.DataSet.addPrimitive(DataSet.java:413)
at
org.openstreetmap.josm.command.AddCommand.executeCommand(AddCommand.java:52)
at
org.openstreetmap.josm.command.SequenceCommand.executeCommand(SequenceCommand.java:53)
at
org.openstreetmap.josm.data.UndoRedoHandler.addNoRedraw(UndoRedoHandler.java:43)
at
org.openstreetmap.josm.data.UndoRedoHandler.add(UndoRedoHandler.java:69)
at
org.openstreetmap.josm.plugins.tracer.LpisModule.trace(LpisModule.java:242)
at
org.openstreetmap.josm.plugins.tracer.TracerAction$1.realRun(TracerAction.java:135)
at
org.openstreetmap.josm.gui.PleaseWaitRunnable.doRealRun(PleaseWaitRunnable.java:82)
at
org.openstreetmap.josm.gui.PleaseWaitRunnable.run(PleaseWaitRunnable.java:150)
at java.lang.Thread.run(Thread.java:745)
Martin
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Odstávka LPIS
Ahoj, (2) Občas JOSM po kliknutí naráz vyžere celý heap Javy a současně pár giga paměti X server procesu. Zabitím JOSM procesu se vše zas uvolní. Zkouším ještě předchozí verzi JOSM, jestli není bug spíš někde mezi nejnovějším JOSM, Xserverem a nvidia driverem. Pust josm s paremetry -Xmx2048m -XX:+HeapDumpOnOutOfMemoryError (pripadne mensi heap, jde o to, aby pri te chybe pretekl). JOSM spadne a udela javapid.hprof soubor s heapdumpem, do kteryho pak muzem kouknout, co sezralo veskerou pamet. V heapdumpu bude citelna veskera pamet JOSM, takze jestli jeste nepouzivas OsmAuth, tak na nej prejdi, jinak by slo (snadno) vycist tvoje heslo. Heapdump je k dispozici zde: http://uloz.to/xKexoVkr/java-pid9395-hprof-bz2 JOSM verze 7480 s -Xmx1500m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -jar josm-tested.jar java version 1.8.0_11 Java(TM) SE Runtime Environment (build 1.8.0_11-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.11-b03, mixed mode) Koukal jsem do dumpu přes JVisualVM ale žádný jasný leak nevidím. Total bytes: 89 251 549 taky rozhodně neodpovídá tomu, co reálně sežral josm proces. Pořád ve mě roste podezření, že to žere něco mimo VM Javy, například GTK. Mám 6 GB RAM + 4 GB swapu a byl problém vůbec ten dump vyrobit. Při -Xmx2000m a vyšších si vzal josm proces přes 8 GB RAM a sejmul ho OOM killer, než stihl něco uložit. Stack při OutOfMemoryErroru je pokaždé stejný: - java.lang.OutOfMemoryError: Java heap space Dumping heap to /tmp/java_pid9395.hprof ... Heap dump file created [103911020 bytes in 1,262 secs] CHYBA: java.lang.OutOfMemoryError: Java heap space java.lang.OutOfMemoryError: Java heap space at java.awt.image.DataBufferInt.init(DataBufferInt.java:75) at com.sun.java.swing.plaf.gtk.GTKEngine.finishPainting(GTKEngine.java:589) at com.sun.java.swing.plaf.gtk.GTKEngine.finishPainting(GTKEngine.java:580) at com.sun.java.swing.plaf.gtk.GTKPainter.paintTreeCellBackground(GTKPainter.java:1181) at javax.swing.plaf.synth.SynthTreeUI.paintRow(SynthTreeUI.java:554) at javax.swing.plaf.synth.SynthTreeUI.paint(SynthTreeUI.java:359) at javax.swing.plaf.synth.SynthTreeUI.update(SynthTreeUI.java:271) at javax.swing.JComponent.paintComponent(JComponent.java:777) at javax.swing.JComponent.paint(JComponent.java:1053) at javax.swing.JComponent.paintChildren(JComponent.java:886) at javax.swing.JComponent.paint(JComponent.java:1062) at javax.swing.JComponent.paintChildren(JComponent.java:886) at javax.swing.JComponent.paint(JComponent.java:1062) at javax.swing.JViewport.paint(JViewport.java:744) at javax.swing.JComponent.paintChildren(JComponent.java:886) at javax.swing.JComponent.paint(JComponent.java:1062) at javax.swing.JComponent.paintToOffscreen(JComponent.java:5217) at javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:290) at javax.swing.RepaintManager.paint(RepaintManager.java:1252) at javax.swing.JComponent._paintImmediately(JComponent.java:5165) at javax.swing.JComponent.paintImmediately(JComponent.java:4976) at javax.swing.RepaintManager$3.run(RepaintManager.java:811) at javax.swing.RepaintManager$3.run(RepaintManager.java:794) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:794) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:769) at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:718) at javax.swing.RepaintManager.access$1100(RepaintManager.java:62) at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1680) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] RUIAN tracer chyby
On 29.8.2014 22:19, Marián Kyral wrote: Dne 29.8.2014 21:56, Martin Švec - OSM napsal(a): Ahoj, buďto dělám něco špatně, nebo tracer ošklivě rozbíjí budovy všude kolem sebe. Chtěl jsem opravit neuzavřené budovy v Litomyšli a místo toho jich s každým klikem přibývá ;-) Konkrétní příklad: https://www.openstreetmap.org/#map=19/49.87194/16.32011 Klikem na https://www.openstreetmap.org/way/263830995 se rozbijí na druhé straně ulice budovy https://www.openstreetmap.org/way/263830720 a https://www.openstreetmap.org/way/263835323. Budova č. 137 se opět vytvoří špatně uzavřená, je tam dovnitř ocas navíc. Ale v podstatě stačí kliknout na jakoukoliv osaměle stojící budovu v zástavbě a podle zásobníku příkazů tracer v sekvenci Odstranění nadbytečných uzlů rozdrbe široké okolí. Dále, v případě mrzáčků https://www.openstreetmap.org/way/263832564 a https://www.openstreetmap.org/way/263834808 úplně zhavaruje. Vyzkoušeno s těmito verzemi, dělá mi to v obou: http://www.kyralovi.cz/tmp/josm/beta/Tracer.jar http://www.kyralovi.cz/tmp/josm/beta/20140823/Tracer.jar Martin Díky za report. Mrknu na to (ale asi až během příštího týdne). Prozatím jsem tu funkci vypnul. S ocásky nic takhle narychlo neudělám, musím se na to pořádně podívat. http://www.kyralovi.cz/tmp/josm/beta/20140829/Tracer.jar Marián Díky za opravu, už zase šlape :-) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Návod: jak natlačit lesy do zákoutí v LPIS (ContourMerge plugin)
Jup :-))) Kam jsem se sakra díval, že jsem ten plugin přehlídnul? Návod je zbytečně složitý, plugin toho umí mnooohem víc než popisuješ :-) Klikáním na uzly se totiž dají cesty virtuálně rozsekat na menší úseky, není potřeba nic rozdělovat a slučovat. Takže po zjednodušení: (1) Kliknout na ikonu ContourMerge. (2) Kliknout na dva uzly zdrojové cesty, objeví se na nich žluté křížky. (3) Kliknout na dva uzly cílové cesty, zas se vyznačí křížky. (4) Přetáhnout myší takto vybraný úsek zdrojové cesty na odpovídající úsek cílové cesty. A co je nejlepší, dají se tím naráz spravit všechny nesrovnalosti kolem LPIS polygonu, překryvy i poloostrovy, i když jsou tvořeny více cestami. Těch rozdělovacích křížků se totiž dá naklikat neomezené množství na různých cestách a pak se dají úseky mezi nimi libovolně přesouvat. V rámci stejné cesty může být jeden úsek zdrojový, druhý cílový, záleží co se kam přetáhne. Křížky se dají průběžně přidávat a odebírat. A přetahovat se dá tak dlouho, dokud je funkce zapnutá. Poloostrov z více cest sice nejde zaplnit v jediném kroku, ale křížkování a přetahování po úsecích je triviální. Stačí si jen předdělat na segmentu zdrojové cesty zásobu uzlů, aby bylo z čeho přetahovat. Ruční práce na půl hodiny se smrskla na pár intuitivních kliků a přetažení. A krásně se tím dělají i nové plochy, hur. Martin Dne 10.8.2014 23:37, Marián Kyral napsal(a): Ahoj, Při hledání možností, jak řešit problém v předmětu jsem procházel seznam pluginů a narazil na CountourMerge plugin [1]. Ten už mám sice dlouho nainstalovaný, ale až dnes jsem se na něj podíval podrobněji a zjistil jak se s ním vlastně pracuje. Není to nic složitého, jsou potřeba jen dva segmenty, se kterými plugin manipuluje. Velmi dobře to funguje u poloostrovů tvořených jednou cestou. Pokud je tam těch cest více, tak to taky jde, ale je to větší piplačka - je potřeba pracovat s každou cestou zvlášť. Udělal jsem k tomu obrázkový návod a protože se mi nevešel do emailu, najdete jej tady: http://osm.kyralovi.cz/navody/ContourMerge_plugin.html Snad se to bude někomu hodit. Marián [1] http://wiki.openstreetmap.org/wiki/JOSM/Plugins/ContourMerge ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Návod: jak natlačit lesy do zákoutí v LPIS (ContourMerge plugin)
Dne 11.8.2014 14:37, Marián Kyral napsal(a): Aha, koukám, že jsem to neposlal do konference ;-) Navíc, jsem našel dole na stránce, takový nenápadný odkaz, kde to popsáno je. Škoda, že jsem to nedočetl až do konce ;-) http://josm.openstreetmap.de/wiki/Help/Plugin/ContourMerge Heh, tak ten odkaz jsem taky přehlídl... Já to zjistil klikáním v JOSM, omylem se mi na uzlu objevil jakejsi křížek, tak jsem zkoušel k čemu slouží ;-) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer - pLPIS
Tím to nebude (pokud nechce klasický trasování katastrální mapy).
(1) V nastavení pluginu zaškrtnout moduly RUIAN a LPIS, odškrtnout Klasický.
(2) Mac(kat T a sledovat jak se me(ní kurzor myši, R = budovy z RUIANu, LP =
pu*da z LPISu.
Martin
Dne 11.8.2014 15:53, Michal Puste(jovský napsal(a):
Máš spušte(ný tracer server?
-- Pu*vodní zpráva --
Od: Jan Dudík jan.du...@gmail.com
Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org
Datum: 11. 8. 2014 14:45:35
Pr(edme(t: Re: [Talk-cz] Tracer - pLPIS
De(lám ne(co špatne(?
stáhl jsem si tracer z [1], k ne(mu v JOSM dva vyžadované dopln(ky, na
pozadí si zapnul požadovanou vrstvu wms abych vide(l co klikám.
spustím tracer, kliknu na budovu - aktualizuje se dle RUIAN
kliknu na plochu, kde je v LPIS vybarvená plocha - a nic
mac(káním T dosáhnu jediné zme(ny, že se ani po kliku na budovu nic
nestane
[1] http://www.kyralovi.cz/tmp/josm/beta/lpis/Tracer.jar
JAnD
Dne 8. srpna 2014 21:04 Pavel Kwiecien pavel.kwiec...@seznam.cz
napsal(a):
Ahoj, trochu jsem si už s Tracerem zablbnul a už se mi to tady pod
horama
zazelenalo
http://www.openstreetmap.org/#map=13/50.5706/15.7740
Pokud by spojování nebylo automatické, tak nemá smysl se tím zabývat.
Tracer
funguje dobr(e, akorát import je potr(eba vždy!! projet v JOSM validací,
protože tracováním/vstupníma daty vzniká obrovské množství chyb a
varování.
Na dve( kliknutí se toho dá zbavit.
Ješte( pro neznalé. Je dobré si v JOSM nastavit tr(eba tuto WMS vrstvu:
http://eagri.cz/public/app/wms/plpis.fcgi?FORMAT=image/gifVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLAYERS=LPIS_FB_KULSTYLES=SRS={proj}WIDTH={width}HEIGHT={height}BBOX={bbox}
aby bylo vide(t, kde jsou LPIS data.
Zdraví Pavel Kwiecien
-- Pu*vodní zpráva --
Od: Marián Kyral mky...@email.cz
Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org
Datum: 8. 8. 2014 9:08:35
Pr(edme(t: Re: [Talk-cz] Tracer - pLPIS
Ahoj,
-- Pu*vodní zpráva --
Od: Pavel Machek pa...@ucw.cz
Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org
Datum: 5. 8. 2014 23:19:28
Pr(edme(t: Re: [Talk-cz] Tracer - pLPIS
ahoj!
Jak by sis to propojení pr(edstavoval? Mne nenapadá, jak by se to
dalo
ude(lat.
No úplne( pr(esne( to nevím :).
Napr(ed bych vide(l úvahu, zda jednotlivá políc(ka (=parcely a LPIS
polygony)
sdružovat nebo ne. Na tom závisí i strategie aktualizací. Zatím mi
pr(ijde
nemožné hlídat si podle ref:, zda se ne(co v LPIS zme(nilo a na zme(nu
zareagovat. Nevíme, co se mu*že me(nit. Urc(ite( druh kultury, možná i
geometrie?
Je možné, že tam, kde je ted( 50 malých políc(ek bude za 3 roky jen
jedno
velké
c(i naopak?
No, zato vime ze je to po katastralnich uzemich, ne?
Takze az to bude chtit nekdo updatovat:
Pro kazdy polygon:
Je polygon se stejnou geometrii v osm?
NE: importuju
ANO: zmenim parametry na ty z noveho lpis, je li nutne
Pro polygony z OSM ktere jsem zatim nezpracoval:
Jestlize polygon ma source=lpis
Jestlize se od importu nezmenil, smazu ho
Jinak je to na rucni rozhodnuti co je aktualnejsi.
Hmm?
Pavel
No zásadní problém je: Sluc(ovat nebo nesluc(ovat polygony se stejným
landuse
vedle sebe?
Tr(eba tady: http://www.openstreetmap.org/#map=17/49.66388/18.38023 by
se
slouc(ení hodilo. Ale když jsem experimentálne( pár polygonu* oznac(il
a nechal
slouc(it, tak z toho vylezl ne(jaký paskvil, protože ac( jsou ty
natrasované
polygony vizuálne( vedle sebe, ne vždy na sebe pr(esne( navazují.
Pokud je budu napojovat na sebe, tak musím nutne( s ne(jakým bodem
pohnout a
tím pádem zme(ním geometrii = problém pr(i aktualizaci - jak poznám,
že je
daný polygon stejný, jen byl mírne( zme(ne(n z du*vodu napojení na
sousední
polygon? Pr(idat ne(jakou toleranci?
A pokud se bude sluc(ovat (což bych v tomto konkrétním pr(ípade( rád
ude(lal),
co ude(lat s ref? Já bych jej úplne( vyhodil, nechal bych jen
source=lpis, aby
bylo jasné, odkud se to vzalo. A chybe(jící ref by znamenalo, že polygon
vznikl slouc(ením menších polygonu*. Nebo tam dát ne(jaký speciální tag?
Tr(eba lpis=merged ?
Pokud by ref zu*stalo, nutne( by to vedlo k ne(c(emu takovému:
ref=123;2231;2231;22455;875;646
Bylo by to k ne(c(emu?
Marián
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
Re: [Talk-cz] Tracer - pLPIS
Narazil jsem ještě na jednu zvláštnost, v LPIS polygonech se vzácně vyskytovaly dva po sobě jdoucí identické uzly. JOSM to komentoval hláškou polygon překrývá sám sebe a chvíli mi trvalo, než jsem objevil důvod. Můžeš mi poslat nějaký příklad? Rád bych na to mrknul. Ono je totiž možné, že v reálu jsou ty body jen malilinkatý kousek od sebe a stejné souřadnice dostanou až po zaokrouhlední na přesnost OSM. Mrknul jsem na to, máš pravdu -- uzly jsou pár centimetrů sebe a záleží s jakou přesností se importují: node id=-1857 lon=16.385882008070073 lat=49.405170737465724 node id=-1858 lon=16.385882107880310 lat=49.405170804926541 LPIS ref=9115243, 1506/6, https://www.openstreetmap.org/#map=19/49.40517/16.38588 Původní Pavlův skript exportoval xml s přesností jen na 6 des. míst. Proto mi po dobastlení slučování uzlů začaly vycházet dva stejné nody za sebou v jedné cestě. Ve stejném KÚ jsou tři takové případy: LPIS ref=9108586: node id='-49425' action='modify' visible='true' lat='49.40302624464' lon='16.38625580656' / node id='-49424' action='modify' visible='true' lat='49.40302624762' lon='16.38625584765' / LPIS ref=8619128: node id='-56367' action='modify' visible='true' lat='49.40300405326' lon='16.38931909829' / node id='-56366' action='modify' visible='true' lat='49.40300401305' lon='16.38931942154' / Tracer je sice natáhne jako dva uzly těsně vedle sebe, ale lepší by bylo je rovnou sloučit. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer - nová, přepracovaná verze a sloučená verze - RUIAN a LPIS
On 9.8.2014 00:22, Marián Kyral wrote: Ahoj, tak mi to nedalo a hned jak byl čas, tak jsem se na to vrhnul. (Manželka teda nebyla moc ráda ;-) ) Přihodil jsem tam i LPIS modul, takže teď je vše v kupě. A musím říct, že to je teď luxus. Jen mačkám t a klikám na pole nebo domečky - podle toho co je právě potřeba. Paráda, díky, funguje. Akorát když vidím co se děje v Krkonoších, vybavila se mi filmová hláška: Moc ráda bych věděla, kdo dal dítěti do rukou takovou zbraň. ;-) Mohl jsem to mít i dříve, ale zdržel jsem se přepisem parseru JSON z org.json na javax.json - po sloučení větví ruian a plpis se mi to nechtělo zkompilovat a už jsem zapomněl jak jsem jej posledně přesvědčil, aby si tu knihovnu sebral :-D No nic, stejně bych to musel udělat. Akorát jsem na to zapomněl. Grrr, zrovna včera jsem si stáhl zdrojáky a půl hodiny se marně pokoušel zkompilovat plugin s org.json :-) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer - pLPIS
On 9.8.2014 00:08, Marián Kyral wrote: Dne 8.8.2014 23:24, Pavel Machek napsal(a): Ahoj! No zásadní problém je: Slučovat nebo neslučovat polygony se stejným landuse vedle sebe? Prosil bych neslucovat. Pokud je budu napojovat na sebe, tak musím nutně s nějakým bodem pohnout a tím pádem změním geometrii = problém při aktualizaci - jak poznám, že je daný polygon stejný, jen byl mírně změněn z důvodu napojení na sousední polygon? Přidat nějakou toleranci? Protoze slucovani vede k problemum s updatem, a mizi tim uzitecna informace: 2 pole vedle sebe jsou 2 ruzne pole, pravdepodobne na kazdym roste neco jinyho (i kdyz z mapy nevime, co tam roste) a je mezi nima misto kudy se da jit; kdyz jsou vedle sebe 2 pastviny (nebo treba 2 vinice), nejspis je mezi nima plot. OK. A pokud se ty polygony dotýkají, můžu je spojit? Tedy, že budou mít společné uzly? Stejně tak, pokud se polygony budou překrývat, tak jednomu ten kousek useknu. Šlo by to? Duplicitní uzly na společných hranách landuse polygonů určitě slučovat do jednoho, to je důvod většiny errorů v JOSM. Ale zase bych neslučoval úplně s libovolným uzlem, třeba společné uzly landuse s elektrickým vedením mi nepřijou logické. Narazil jsem ještě na jednu zvláštnost, v LPIS polygonech se vzácně vyskytovaly dva po sobě jdoucí identické uzly. JOSM to komentoval hláškou polygon překrývá sám sebe a chvíli mi trvalo, než jsem objevil důvod. Pokud jde o slučování celých polygonů, tam souhlasím s Pavlem, raději zatím neslučovat. Překryvy v rámci LPIS polygonů jsem po sloučení duplicitních uzlů už nezaznamenal. Překryvy s OSM polygony je větší legrace, stačí se teď podívat do Podkrkonoší ;-) Useknout uhul:wms les podél LPIS polygonu bude ve většině případů v pořádku. U landuse=residential, farmyard apod. to už tak jasné není. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import of farmland from LPIS
Ahoj, pár věcí:
* Opravil jsem skript, aby se díval i do pole KULTURA_KL, teď už taguje
zelinářskou zahradu atd.
* Když narazí na neznámý kód kultury, vyhodí výjmku místo tagu.
* Vyházel jsem zbývající ploty -- byly tam z nějakého důvodu?
* crop=vegetable nebo crop=vegetables ? taginfo zná víc těch prvních
* kul. 98 (rychle rostoucí dřeviny): landuse=scrub ???
* Proč se taguje id_fb? Je to k něčemu dobrý?
Zkoušel jsem nanečisto v JOSM napojování většího kusu dat na existující landuse
polygony, je to pěkná drbačka, překryvů a děr je víc než dost. Pokud Marián
dodělá tracer, který by přidával políčka jedno po druhým, byl by asi
praktičtější. (A pohrávám si s myšlenkou dodělat do JOSM funkci, která přilepí
úsek jedné cesty ke druhé mezi určenými body. Fakt nic takovýho neexistuje nebo
jen špatně hledám?)
Btw, rozjel jsem PostGIS a zkoušel totéž s parcelami RUIANu. Když se vhodně sloučí
parcely podle typů jak psal Petr Vejsada, tak je to taky použitelné. Proti LPISu RUIAN
líp pokrývá celou plochu KÚ, ale LPIS zase obecně víc odpovídá Bingu.
Problémů s napojováním na okolí je u obou zhruba stejně. (Docela pěkně vychází parcely
RUIANu ve městech a vesnicích. Zkusím z toho někdy zmapovat vnitřnosti u pár vesnic,
kolik klikací práce to ušetří.)
Martin
On 28.7.2014 14:53, Pavel Machek wrote:
Hi!
I'd like to start import of LPIS farmland database, as we have very
good coverage of houses, forests and water, but farmland is very good
at places and completely missing at different places.
Import page is at https://wiki.openstreetmap.org/wiki/LPIS , import
script will probably be ogr2osm + script below.
Best regards,
Pavel
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
def getKultura(attrs):
if 'KULTURA_KL' in attrs and attrs['KULTURA_KL'] != '':
return int(attrs['KULTURA_KL'])
if 'KULTURA' in attrs and attrs['KULTURA'] != '':
kul = int(attrs['KULTURA'])
return -1;
def filterTags(attrs):
if not attrs:
return
tags = {}
tags['source'] = 'lpis'
if 'ID_FB' in attrs:
tags['id_fb'] = attrs['ID_FB'];
if 'VYSKA' in attrs:
tags[ele] = %d % int(float(attrs['VYSKA']))
if 'NKODFB' in attrs:
tags[ref] = attrs['NKODFB']
kul = getKultura(attrs)
if kul == 2:tags[landuse] = farmland
elif kul == 3: tags[landuse] = farmland; tags[crop] = hop
elif kul == 30: tags[landuse] = farmland; tags[crop] = hop
elif kul == 31: tags[landuse] = farmland; tags[crop] = hop
elif kul == 41: tags[landuse] = vineyard
elif kul == 61: tags[landuse] = orchard
elif kul == 62: tags[landuse] = orchard
elif kul == 7: tags[landuse] = meadow; tags[meadow] = agricultural
elif kul == 71: tags[landuse] = meadow; tags[meadow] = agricultural
elif kul == 72: tags[landuse] = meadow; tags[meadow] = agricultural
elif kul == 91: tags[landuse] = forest
elif kul == 92: tags[landuse] = farm; tags[crop] = vegetables
elif kul == 97: tags[landuse] = reservoir
elif kul == 98: tags[landuse] = scrub; tags[note]=rychle rostouci dreviny
elif kul == 99: tags[landuse] =forest
else: raise Exception (unknown farmland: %s % kul)
return tags
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import of farmland from LPIS
On 28.7.2014 22:35, Pavel Machek wrote: To druhy jsem zvladnul nejak osalit, jenze nemam potrebny balicky pro python3: from osgeo import ogr from osgeo import osr . Jestli ma nekdo napad... Pavel Mně to fungovalo samo od sebe... Koukám do systému, ogr.py/osr.py mi do Gentoo zavlekla GDAL knihovna s python USE flagem. A jako aktivní python mám 2.7. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import of farmland from LPIS
On 28.7.2014 23:03, Pavel Machek wrote: No, pro me je informace o plotech docela dulezita.. mam pocit ze vinice a chmelnice plot proste maji. Ale asi je to trochu drze... Mně se nelíbily ploty kolem a napříč loukami, kde vím že tam určitě nejsou. U vinic+chmelnic... mno, tam je pravděpodobnost plotu asi docela vysoká. Těžko říct... http://wiki.openstreetmap.org/wiki/Tag:natural%3Dscrub Aha, ma tam byt natural, ale jinak to myslim sedi. Opravim. Znova jsem se nad tím zamyslel... Záleží, co se myslí porostem rychle rostoucích dřevin. Natural=scrub je neobhospodařovaná příroda, landuse=* je obhospodařovaná krajina. Jestli jsou to plantáže na biomasu, landuse by tomu slušel víc. (Taginfo landuse=scrub zná, ale většinou na uzlech (wtf, jednotlivé keře?). Co jsem namátkou našel na polygonech, tak je to chybně otagovaný natural=scrub.) Update: jo, je to biomasa: viz par. 3i písm. j) zákona č. 252/1997 Sb. Zkoušel jsem nanečisto v JOSM napojování většího kusu dat na existující landuse polygony, je to pěkná drbačka, překryvů a děr je víc než dost. Pokud Marián dodělá tracer, který by přidával políčka jedno po druhým, byl by asi praktičtější. No, ja bych uplne landuse=farmland napriklad s lesama nespojoval.. ono vedle toho lesa byva ruzne siroky pruh ne-lesa ale jeste taky ne-pole. To je asi individuální... Když jsou mezi lesem a polem tři metry křovin a šouší, dávám pruh natural=scrub. Když jsou na okraji jen koleje od traktoru a rovnou les, spojuju přímo. Nemám rád v mapě bílé škvíry :-) Ty pruhy křoví jsou občas přímo v KM. Btw, rozjel jsem PostGIS a zkoušel totéž s parcelami RUIANu. Když se vhodně sloučí parcely podle typů jak psal Petr Vejsada, tak je to taky použitelné. Proti LPISu RUIAN líp pokrývá celou plochu KÚ, ale LPIS zase obecně víc odpovídá Bingu. Problémů s napojováním na okolí je u obou zhruba stejně. (Docela pěkně vychází parcely RUIANu ve městech a vesnicích. Zkusím z toho někdy zmapovat vnitřnosti u pár vesnic, kolik klikací práce to ušetří.) No, kdyby z toho byly nejaky soubory, treba pro okoli rican, tak se na rad podivam. Kdyby se v osm objevily ploty, tak me to hodne potesi... a ploty by mely jit vykoukat z mistni znalosti + hranic pozemku. Pokusím se vyrobit ukázku, až to trochu učešu. Ale teď se k tomu pár dnů nedostanu. Zatím hlavně googlím, co vůbec PostGIS nad daty dokáže. Btw, ty ploty... To je nějaká specifická úchylka? :-)) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Dvě budovy nakreslené v jedné
Obecně to nejde. Já porovnávám DKM s Bingem, RUIANem a OSM daty a odhaduju, co z toho je asi správně. Někdy nesedí ani jedno. Bing má snímky několik let staré, budova mohla být zbouraná a postavena jiná. Pár typických chyb v RUIANu je tady: https://wiki.openstreetmap.org/wiki/User:Maatts. (Což mi připomíná, že diskuse k tagování chyb nějak zapadla.) Máš link na konkrétní příklad? Martin On 26.7.2014 08:57, Lukas Novotny wrote: Mám dvě budovy. Jedna je větší nakreslená dle source=cuzk:ruian, druhá menší ale vkreslena uvnitř té větší ze zdroje source=cuzk:km. Dá se jednoduše určit z kterého zdroje má ta budova přednost a nebo to takto paušálně nejde? Lukáš ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import of farmland from LPIS
Ahoj,
pro zajímavost, tvůj skript jsem při zkoumání LPISu nakonec zavrhl, jelikož
jsem našel tohle:
http://wiki.openstreetmap.org/wiki/Ogr2osm
Stačí doplnit translation funkci (vypůjčeno z pův. skriptu, v příloze) a
veškerou srandu udělá jeden příkaz:
ogr2osm.py PLPIS_233406_KU_KOD_742376.shp -t trn-lpis.py -o ujezd.lpis.osm
Mj. je tím vyřešeno slučování uzlů, multipolygony a nejspíš i další problémy.
Martin
def filterTags(attrs):
if not attrs:
return
tags = {}
tags['source'] = 'lpis'
if 'ID_FB' in attrs:
tags['id_fb'] = attrs['ID_FB'];
if 'VYSKA' in attrs:
tags[ele] = %d % int(float(attrs['VYSKA']))
if 'NKODFB' in attrs:
tags[ref] = attrs['NKODFB']
kul = -1
if 'KULTURA' in attrs and attrs['KULTURA'] != '':
kul = int(attrs['KULTURA'])
if kul == 2:tags[landuse] = farmland
elif kul == 3: tags[landuse] = farmland; tags[crop] = hop
elif kul == 30: tags[landuse] = farmland; tags[crop] = hop
elif kul == 31: tags[landuse] = farmland; tags[crop] = hop
elif kul == 41: tags[landuse] = vineyard; tags[barrier] = fence
elif kul == 61: tags[landuse] = orchard; tags[barrier] = fence
elif kul == 62: tags[landuse] = orchard
elif kul == 7: tags[landuse] = meadow; tags[meadow] = agricultural
elif kul == 71: tags[landuse] = meadow; tags[meadow] = agricultural
elif kul == 72: tags[landuse] = meadow; tags[meadow] = agricultural
elif kul == 91: tags[landuse] = forest;
elif kul == 92: tags[landuse] = farm; tags[crop] = vegetables
elif kul == 97: tags[landuse] = reservoir
elif kul == 98: tags[landuse] = scrub; tags[note]=rychle rostouci dreviny
elif kul == 99: tags[landuse] =forest
else: tags[landuse] =unknown_farmland_%s % kul
return tags
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] Skript na parcely RUIANu
Ahoj,
obrázky parcel od Petra Vejsady mi nějak nedaly spát, tak jsem včera v
noci ubastlil skript na konverzi parcel do OSM.
Skriptík nemá jiné ambice než vyzkoušet si natažení parcel do JOSM a
vůbec se seznámit s VFR formátem RUIANu, takže nečekejte zázraky. Mj.
nefungují multipolygony, beru jen polygony typu gml:LinearRing apod.
Tagování jsem narychlo opsal z
http://wiki.openstreetmap.org/wiki/Cs:RUIAN, knihovny na zpracování
GML apod. jsem zatím nehledal.
Vyžaduje perl, proj, Geo::Proj4
(http://search.cpan.org/dist/Geo-Proj4/), a grid jezek_czech08.llb
přejmenovaný na czech (vyšťouráno tady v archívu,
http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid).
Pár obrázků:
http://www.maatts.cz/obrazek/3/lomnice-ruian-parcely-png/
http://www.maatts.cz/obrazek/3/blansko-ruian-parcely-png/
http://www.maatts.cz/obrazek/3/brno-ruian-parcely-png/
Vyzkoušeno na uvedených třech obcích = na čtvrté klidně může
zhavarovat. ;-)
BACHA - ve velkých městech skript žere mraky paměti, optimalizacema
jsem se netrápil. :-)) Třeba Brno (kód obce 582786) má ve výsledku
1.122.529 uzlů a 251.328 parcel, a skriptík na to potřebuje aspoň 12GB
RAM a/nebo hodně swapu na SSD.
Martin
#!/usr/bin/perl -w
use strict;
use Geo::Proj4;
use XML::Simple;
use Data::Dumper;
#
# !!! NEPOUZIVAT PRO OSTRE MAPOVANI DO OSM, POKUSNA ALFA VERZE !!!
#
#
# Pouziti:
#
# (1) Stahnout Kompletni datovou sadu vybrane oblasti z http://vdp.cuzk.cz/vdp/ruian/vymennyformat/vyhledej, napr. podle kodu
# 581976 = Lomnice u Tisnova
# 581283 = Blansko
# 582786 = Brno (velke!)
#
# (2) gunzip 20140630_OB_581976_UKSH.xml.gz
#
# (3) par2osm.pl 20140630_OB_581976_UKSH.xml lomnice.osm
#
#
#
my $input_file = $ARGV[0];
die No input file specified unless (defined $input_file);
die Input file not found unless (-f $input_file);
my $epsg_srs_name = 'urn:ogc:def:crs:EPSG::5514';
my $proj_from = Geo::Proj4-new('+proj=krovak +ellps=bessel +nadgrids=czech');
my $proj_to = Geo::Proj4-new('+proj=longlat +datum=WGS84');
die Undefined source projection unless (defined $proj_to);
die Undefined destination projection unless (defined $proj_from);
my $nodemap = {};
my $idgen = -1;
my $druh_pozemku_map = {
# 1 = [] ???
2 = [ 'landuse', 'farmland' ],
3 = [ 'landuse', 'hop_garden' ],
4 = [ 'landuse', 'vineyard' ],
5 = [ 'leisure', 'garden' ],
6 = [ 'landuse', 'orchard' ],
7 = [ 'landuse', 'meadow' ],
8 = [ 'landuse', 'meadow' ],
10 = [ 'landuse', 'forest', 'wood', 'yes' ],
};
my $zpusoby_vyuziti_map = {
1 = [ 'landuse', 'greenhouse_horticulture' ],
2 = [ 'landuse', 'plant_nursery' ],
3 = [ 'landuse', 'plantation', 'wood', 'yes' ],
4 = [ 'natural', 'wood', 'wood', 'yes' ],
5 = [ 'landuse', 'forest', 'wood', 'yes' ],
6 = [ 'natural', 'water', 'water', 'pond' ],
7 = [ 'waterway', 'river' ],
8 = [ 'waterway', 'canal' ],
9 = [ 'natural', 'water', 'water', 'lake' ],
10 = [ 'natural', 'water', 'water', 'reservoir' ],
11 = [ 'natural', 'wetland' ],
#12 = [ ] ???
13 = [ 'landuse', 'brownfield' ],
14 = [ 'landuse', 'railway' ],
15 = [ 'landuse', 'highway' ],
16 = [ 'landuse', 'highway' ],
17 = [ 'landuse', 'highway' ],
18 = [ 'landuse', 'transport' ],
19 = [ 'landuse', 'grass' ],
20 = [ 'landuse', 'recreation_ground' ],
21 = [ 'landuse', 'cemetery' ],
#22 = [] ???
23 = [ 'highway', 'service', 'area', 'yes' ],
24 = [ 'landuse', 'quarry' ],
25 = [ 'landuse', 'landfill' ],
#26 = [] ???
27 = [ 'natural', 'scrub' ], # ... casty vyskyt
28 = [ 'natural', 'water' ],
29 = [ 'landuse', 'industrial' ],
};
sub warning
{
my ($text) = @_;
print STDERR $text\n;
return undef;
}
sub nodemap_get
{
my ($lon, $lat) = @_;
my $key = $lon/$lat;
my $node = $nodemap-{$key};
return $node if (defined $node);
my $krpos = [$lon, $lat];
my $osmpos = $proj_from-transform ($proj_to, $krpos);
$node = {
id = --$idgen,
krpos = $krpos,
osmpos = $osmpos,
};
$nodemap-{$key} = $node;
return $node;
}
sub parse_gml_pos
{
my ($pos) = @_;
return undef unless ($pos =~ /^\s*(\S+)\s+(\S+)\s*$/);
my $lon = $1;
my $lat = $2;
return nodemap_get ($lon, $lat);
}
sub parse_gml_poslist
{
my ($poslist) = @_;
$poslist =~ s/^\s*//;
$poslist =~ s/\s*$//;
my @list = split (/\s+/, $poslist);
die Odd number of poslist entries: $poslist
unless ((int(@list) % 2) == 0);
my $waynodes = [];
for (my $i = 0; $i int(@list); $i += 2)
{
my $lon = @list[$i];
my $lat = @list[$i + 1];
push (@$waynodes, nodemap_get ($lon, $lat));
}
my $way = {
id = --$idgen,
nodes = $waynodes
};
return $way;
}
sub parse_pai_defpoint
{
my ($xdefpoint) = @_;
my $gml_point = $xdefpoint-{'gml:Point'};
return undef unless (defined $gml_point);
my $gml_pos = $gml_point-{'gml:pos'};
return undef unless (defined $gml_pos);
my $srs_name = $gml_point-{'srsName'};
return undef unless (defined $srs_name);
die Unsupported EPSG: $srs_name unless ($srs_name eq $epsg_srs_name);
return parse_gml_pos ($gml_pos);
}
sub
Re: [Talk-cz] Skript na parcely RUIANu
No, poté co jsem si to vyzkoušel jsem si prakticky jistý, že 1:1 hromadný převod všech parcel do OSM není průchozí :-) Ty miliony rozdrobených parcelek by nadělaly solidní binec v databázi i na mapě. A jak říkáš, zrovna LPIS u zemědělské půdy líp kopíruje realitu. Spíš je to o tom hledat způsoby, jak ty RUIAN data rozumně využít, když už jsou k dispozici. Martin Dne 25.7.2014 21:54, Marián Kyral napsal(a): Ahoj, vypadá to hezky, ale fakt chceme mít v OSM přesný obraz KM? Sem tam si zemědělci něco přiorají, občas zase kus nechají a ten brzy zaroste nějakým křovím nebo lesem. Někde jsem zase viděl velkou zahradu, o kterou se už majitel nechtěl starat, tak jí kus pronajal sousedovi a ten si o to rozšířil své pole. Jak už tu padlo, v KM je zanesen právní stav, ale v OSM potřebujeme skutečnost. Z tohohle pohledu mi přijde pLPIS lepší. Plus to, že je dostupný pro celou republiku. Marián On 25. července 2014 21:22:23 CEST, Martin Švec - OSM o...@maatts.cz wrote: Ahoj, obrázky parcel od Petra Vejsady mi nějak nedaly spát, tak jsem včera v noci ubastlil skript na konverzi parcel do OSM. Skriptík nemá jiné ambice než vyzkoušet si natažení parcel do JOSM a vůbec se seznámit s VFR formátem RUIANu, takže nečekejte zázraky. Mj. nefungují multipolygony, beru jen polygony typu gml:LinearRing apod. Tagování jsem narychlo opsal z http://wiki.openstreetmap.org/wiki/Cs:RUIAN, knihovny na zpracování GML apod. jsem zatím nehledal. Vyžaduje perl, proj, Geo::Proj4 (http://search.cpan.org/dist/Geo-Proj4/), a grid jezek_czech08.llb přejmenovaný na czech (vyšťouráno tady v archívu, http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid). Pár obrázků: http://www.maatts.cz/obrazek/3/lomnice-ruian-parcely-png/ http://www.maatts.cz/obrazek/3/blansko-ruian-parcely-png/ http://www.maatts.cz/obrazek/3/brno-ruian-parcely-png/ Vyzkoušeno na uvedených třech obcích = na čtvrté klidně může zhavarovat. ;-) BACHA - ve velkých městech skript žere mraky paměti, optimalizacema jsem se netrápil. :-)) Třeba Brno (kód obce 582786) má ve výsledku 1.122.529 uzlů a 251.328 parcel, a skriptík na to potřebuje aspoň 12GB RAM a/nebo hodně swapu na SSD. Martin -- Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz -- Odesláno z mého telefonu s Androidem pomocí pošty K-9 Mail. Omluvte prosím moji stručnost. ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Skript na parcely RUIANu
Ahoj, ano, tak bych si představoval to rozumné využití RUIANu. Akorát mě nenapadlo, že je to až tak snadné. Asi je čas naučit se PostGIS ;-) Martin On 25.7.2014 22:25, Petr Vejsada wrote: Ahoj, ze 40 milionů drobných parcelek se dá jedním příkazem udělat 60 multipolygonů select druh_pozemku,zpusob_vyuziti_pozemku,st_union(hranice) from ruian.rn_parcela group by druh_pozemku,zpusob_vyuziti_pozemku a z nich dalším jedním či dvěma příkazy se dá udělat N polygonů, které budou sdružovat sousedící parcely se stejným druh_pozemku a zpusob_vyuziti_pozemku st_dump(hranice) ... atd. a toto zkombinovat s LPIS. LPIS by měl mát přednost, ano, a tam, kde LPIS není, protože se majitel půdy nezaregistroval či jde o landuse mimo zemědělství, tam použit RUIAN. ? Dne Pá 25. července 2014 22:04:50, Martin Švec - OSM napsal(a): No, poté co jsem si to vyzkoušel jsem si prakticky jistý, že 1:1 hromadný převod všech parcel do OSM není průchozí :-) Ty miliony rozdrobených parcelek by nadělaly solidní binec v databázi i na mapě. A jak říkáš, zrovna LPIS u zemědělské půdy líp kopíruje realitu. Spíš je to o tom hledat způsoby, jak ty RUIAN data rozumně využít, když už jsou k dispozici. -- Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import of farmland from LPIS
Dne 23.7.2014 2:43, Petr Vejsada napsal(a): Pořád mám v qgisu natažené to jedno KÚ a vidím tam velké překryvy v landuse=residential, vidím tam díry ve školce (skript vůbec neřeší), školka zasahuje do obytné oblasti, takže v těch dírách je co? Obytná oblast? Nevím, žádný dům tam nestojí. Oproti tomu jsem si všiml, že v louce je díra pro sloup elektrického vedení a dokonce to sedí na sloup, co je v OSM, super :-). Je tam i mezera pro silnici, ve které je silnice, taky super, ale na jednom kousku silnice leze do louky, takže někde bude nějaká nepřesnost. Pak tam vidím oblasti, které se částečně shodují s daty v OSM - v OSM je zemědělská půda. Nekryje se to přesně (tím nemyslím centimetry), ale prostě se to liší. Co s tím? Z toho co jsem viděl mi přijde, že LPIS data vznikly stejně jako OSM -- ručně se obkreslovaly KM a ortofoto položené přes sebe. Na volných plochách polygony LPISu víceméně odpovídají KM (s odchylkou centimetrů až metrů). Podél hranic lesa, kolem vesnic, kolem objektů uprostřed pole apod. je polygon nakreslený od oka podle ortofoto snímků. Což odpovídá podstatě OSM, ale bude se to špatně přilepovat k jiným datům. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] LPIS import
Dne 23.7.2014 7:08, Marián Kyral napsal(a): Jak to vidíte? Má tenhle modul vůbec smysl, když se teď rozjel hromadný import? Neházel bych flintu do žita :-) Ten Pavlův skript mi zatím přijde spíš jako užitečná pomůcka pro ruční kreslení. Ve složitějších KÚ vyrábí stovky errorů a warningů. Možná by to chtělo spíše nějaké nástroje na jednodušší řešení konfliktů oblastí - určit přesnější plochu a k té přichytit další, třeba přesahující plochu. Tohle by bylo super!! Bojuju v JOSM se základní úlohou: Jsou dány dva polygony (cesty). V prvním polygonu zruš/odpoj všechny existující uzly mezi A až B a místo nich se přilep na uzly od X po Y z druhého polygonu. Máte na to někdo nějakou fintu/plugin? Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import of farmland from LPIS
Ahoj,
cvičně jsem si taky zkusil tři KÚ, první dojmy:
* Skript by měl slučovat duplicitní uzly (triviální).
* Skript by měl eliminovat uzel v cestě, pokud je totožný jako předcházející
uzel (triviální).
* Musí se ručně řešit multipolygony.
* Spousta sousedících polygonů má překryvy, i v rámci jednoho KU.
* LPIS obsahuje jen zemědělskou půdu, takže v mapě vznikají ostrůvky polygonů
místo souvislé plochy.
* Podezřele hodně luk je označeno jako oplocených (kul. 71) -- skript
předpokládá, že každá pastvina má ohradník/plot?
* Jak už zaznělo, budou potíže na rozhraních s existujícími lesy.
* LPIS na řadě míst nekopíruje hranice parcel, takže budou nesoulady s daty
RUIANu, plochami kreslenými podle KM atd.
* Od pohledu mi přijde, že parcely RUIANu by byly kvalitnější zdroj pro plošné
mapování.
Na druhou stranu, už teď skript ušetří mraky ručního obkreslování, stačí jen v
JOSM doopravit problémy. :-)
(V příloze je skript s přidaným primitivním odstraňováním duplicitních uzlů.
Nicméně, Python vůbec neznám a z jeho syntaxe dostávám osypky, takže zbytek
nechám pythonistům :-))
Martin
On 22.7.2014 15:28, Pavel Machek wrote:
Hi!
I'd like to start import of LPIS farmland database, as we have very
good coverage of houses, forests and water, but farmland is very good
at places and completely missing at different places.
Import page is at https://wiki.openstreetmap.org/wiki/LPIS , import
script is attached to this email.
Best regards,
Pavel
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
#!/usr/bin/python
# http://www.lpis.cz/index.html
# Mapa:
# http://eagri.cz/public/app/lpisext/lpis/verejny/
# Vyzadat data na:
# http://eagri.cz/public/app/lpisext/lpis/verejny/exportDat.html
# Vyzadat: Pudni bloky
# Souradny systrem: wgs-84
# Aha, a ty cisla katastralnich uzemi jde dokonce vykoukat z osm, jako ref u
boundary=administrative, admin_level=10
# A... nefunguje jim dobre captcha, takze jde stahnout vic uzemi jednim
formularem.
# doubek: 631035
# babice: 600601
# for A in *.zip; do unzip $A; done
import sys
import shapefile
from pyproj import *
print ?xml version='1.0' encoding='UTF-8'?
print osm version='0.6' generator='pyshp'
#p1 = Proj(init='esri:102067')
p1 = Proj(init='EPSG:4326')
p2 = Proj(init='EPSG:4326')
sf = shapefile.Reader(sys.argv[1])
global field
field = {}
def a_field(num, name):
global field
i1, i2, i3, i4 = sf.fields[num]
if name != i1:
print 'Unexpected field name ', name
field[name] = num
a_field(1, 'ID_FB')
a_field(3, 'NKODFB')
a_field(6, 'PLATNYOD')
a_field(7, 'VYMERAM')
a_field(8, 'KULTURA')
a_field(9, 'KULTURA_KL')
a_field(10, 'KULTURAOD')
a_field(11, 'EKO')
a_field(21, 'VYSKA')
a_field(22, 'SVAZITOST')
a_field(26, 'KU_KOD')
global nodeid
nodeid = 0
global nodemap
nodemap = {}
def convert(point):
lon, lat = point
lon, lat = transform(p1, p2, lon, lat)
#lat += 50.013082018919185-50.013834
#lon += 14.748617781670555-14.749757
return lon, lat
def write_point(point):
global nodeid
global nodemap
lon, lat = convert(point)
nodekey = '%f/%f' % (lon, lat)
if nodekey in nodemap:
return nodemap[nodekey]
tags = 'tag k=created_by v=shpupload/'
tags += 'tag k=source v=lpis/'
nodeid -= 1
print 'node id=%d lon=%f lat=%f\%s/node' % ( nodeid, lon, lat,
tags )
nodemap[nodekey] = nodeid;
return nodeid
def attr(shrec, name):
return shrec.record[field[name]]
for shrec in sf.shapeRecords():
shape = shrec.shape
prevpt =
pts = []
for point in shape.points:
curpt = write_point(point)
if prevpt != curpt:
pts += [ curpt ]
prevpt = curpt
nodeid -= 1
print 'way id=%d' % nodeid
print ' tag k=created_by v=pyshp/'
print ' tag k=id_fb v=%s/' % attr(shrec, 'ID_FB')
print ' tag k=source v=lpis/'
print ' tag k=lpis:kultura v=%d/' % attr(shrec, 'KULTURA')
kul = attr(shrec, 'KULTURA')
if kul == 2:print ' tag k=landuse v=farmland/'
elif kul == 3: print ' tag k=landuse v=farmland/tag k=crop
v=hop/'
elif kul == 30: print ' tag k=landuse v=farmland/tag k=crop
v=hop/'
elif kul == 31: print ' tag k=landuse v=farmland/tag k=crop
v=hop/'
elif kul == 41: print ' tag k=landuse v=vineyard/tag k=barrier
v=fence/'
elif kul == 61: print ' tag k=landuse v=orchard/tag k=barrier
v=fence/'
elif kul == 62: print ' tag k=landuse v=orchard/'
elif kul == 7: print ' tag k=landuse v=meadow/tag k=meadow
v=agricultural/'
elif kul == 71: print ' tag k=landuse v=meadow/tag k=meadow
v=agricultural/tag k=barrier v=fence/'
elif kul == 72: print ' tag k=landuse v=meadow/tag k=meadow
v=agricultural/'
elif kul == 91: print ' tag k=landuse v=forest/tag k=barrier
v=fence/'
elif kul == 92: print ' tag
Re: [Talk-cz] Tracer - nová testovací verze
Potvrzuju, že to dělá až poslední verze. Předchozí sice vyráběla mnohem víc duplicitních bodů, ale žádné konflikty ;-) Nevím jestli je to stejný problém, ale reprodukovatelnou chybu jsem našel např. na https://www.openstreetmap.org/#map=19/49.24478/16.23263layers=N - když kliknu na dům č. 81 (par. 17/4) nebo č. 1 (par. 17/3), plugin smázne západní roh domu č. 35 (par. 17/2) a nevrátí ho zpět ani undo. Martin On 19.7.2014 13:35, jzvc wrote: Predchozi verze tohle nedelala = hledej v poslednich zmenach. Pokud jsem to dobre pochopil, tak vpodstate jde o to, ze plugin zmeni podkladova data, ale tu zmenu nezapise jako zmenu. Dne 18.7.2014 16:03, Marián Kyral napsal(a): Tak jsem si teď trochu poklikal v Jihlavě a podařilo se mi vyrobit 24 konfliktů :-( Budu muset vymyslet nějaký lepší debugging. Z aktuálního logu jsem nic zajímavého nevykoukal. Zatím řekněme, že Tracer není vhodný pro klikání v husté zástavbě :-D Marián -- Původní zpráva -- Od: Marián Kyral mky...@email.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 17. 7. 2014 13:55:43 Předmět: Re: [Talk-cz] Tracer - nová testovací verze -- Původní zpráva -- Od: jzvc j...@tpfree.net Komu: talk-cz@openstreetmap.org Datum: 17. 7. 2014 13:14:46 Předmět: Re: [Talk-cz] Tracer - nová testovací verze Dne 16.7.2014 23:28, Marián Kyral napsal(a): Ahoj, -- Původní zpráva -- Od: jzvc j...@tpfree.net Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 16. 7. 2014 23:00:58 Předmět: Re: [Talk-cz] Tracer - nová testovací verze Cus, nevim v cem to je, ale s libovolnym pouzitim mi vznikne konflikt. Je to na tema ze lokalne sem smazal bod kterej na serveru existuje. Vyresit se da jedine tak, ze aplikuju verzi ze serveru, pri pokusu o aplikovani lokalni verze se to cykli porad dokola. Navic pokud josm nekeca, tak ten koflikt vznikne na bodech budov, na ktery sem vubec nesahal = plugin zjevne ano. Divné, divné. Můžeš hodit nějaký příklad? Případně nějaké detaily? Zkoušel jsi původní, nebo aktualizovanou verzi? Cus, Zkousel sem posledni verzi na posledni verzi josm (7313). Budovy nesousedily. http://www.openstreetmap.org/relation/440427#map=18/49.40296/15.58466 pokud si pamatuju, protah sem pres plugin budovu 4340/6 (a par budov kolem nadrazi) a konflikt to hlasilo na budove 1472/15a (byl to mimo jiny dolni levy bod). Díky, vyzkouším (ale asi ne hned, teď budu týden mimo). Jak velkou oblast jsi měl staženou? Nebyla daná budova alespoň částečně mimo staženou oblast? To bych možná tušil (a asi bych to měl nějak omezit). Testil sem to jen zbezne, ale vypadalo to, ze pocet trasovanych budov nema temer zadny vliv. Nedetekuje plugin nejakou duplicitu i mimo zpracovanou oblast? No o co se tam pokouším je to, že někdy, po odpojení od sousední budovy, zůstanou na sousední budově již nepotřebné uzly. A já se je snažím detekovat a smazat. Beru vždy dva sousedící segmenty a snažím se zjistit, jestli prostřední bod leží na úsečce tvořené krajními body. Pokud zjistím, že to tak je, a prostřední bod není součástí dalšího objektu, tak jej smažu. No a asi to nefunguje jak by mělo. Ono totiž je to trochu komplikované. Všechny změny, které dělám, dělám na kopii objektů a zároveň zapisuji do fronty příkazy typu vytvoř bod Y, přesuň bod X na , Přidej bod do cesty W. A až úplně na konci se provede commit, který všechny tyto změny provede na vrstvě stažené v JOSM. Při mazání si pak musím sám hlídat, zda daný bod není součástí nějaké jiné cesty. Bohužel nemohu přímo zjistit, kolik cest je na konkrétní bod navázáno, ale musím procházet jednu cestu po druhé a ptát se, zda tento bod není jejich součástí. No a tady je obrovský prostor na chyby :-( Zatím to vidím tak, že nebudu sahat na body, které se nalézají mimo staženou oblast. No a pak se možná ještě jednou podívám, na ten algoritmus, co se snaží mazat nadbytečné body. Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Posunutá Jihlava
On 19.7.2014 13:32, jzvc wrote: Dne 19.7.2014 10:45, Pavel Machek napsal(a): On Wed 2014-07-16 22:27:49, jzvc wrote: Cus, nevim jakej je lokalni posun Bingu, ale narazim na to pomerne casto. Tohle vypada naprosto klasicky, ze bing byl pouzitej jako ten top presnej podklad. Snazim se ty lidi upozornit, ze Bing ma pomerne velkej rozpal a ze mame lepsi zdroje. Nic vic stim asi neudelas. Bohuzel pokud nekdo edituje jinde nez v josm ... tak asi nic jinyho nez Bing nema. Je cas udelat plugin, kterej bude posouvat bing zpet? Protoze, uprimne, kdyz dam lidem presny ale posunuty podklady, nemuzu se divit ze to podle nich zmapujou... Pavel To bys k tomu musel jeste udelat nejakou transformacni matici, protoze ten posun je pokazdy jinej. Parkrat sem si trebas bing posunul podle km a o par km vedle to uz bylo uplne mimo. A tak jako tak, to asi neporesis v online editorech. Plugin existuje: http://wiki.openstreetmap.org/wiki/Imagery_Offset_Database, akorát asi není moc používaný. Třeba já si radši seskládám vrstvy pro každé místo zvlášť podle KM, pokud je čeho se chytit. Satelitní podklady jsou taky snímané z různých úhlů, takže jsou různě zkřivené i v relativně malé oblasti. Ale hlavní potíž je, že spousta nováčků vůbec netuší, že existuje něco jako posun podkladů. Znám z vlastní zkušenosti :-) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer - nová testovací verze
Super, díky. :-) Akorát pořád nefunguje defaultní server, musím explicitně nastavit Vlastní RUIAN server na http://josm.poloha.net/tracer/. To je chyba, nebo mám něco špatně? Martin Švec Dne 11.7.2014 23:15, Marián Kyral napsal(a): Ahoj, vzhledem k tomu, že už nějakou dobu relativně bez problémů používán novou verzi Traceru a zjistil jsem, že opravdu nejsem schopen ji odladit na 100% (veškeré snahy o ladění stejně končí mapping party - viz moje neustále stoupající pořadí ve statistikách ;-) ), tak jsem se rozhodl vývoj ukončit a dát vám to k dispozici k otestování. Pokud by se našel nějaký programátor, co by pomohl s vývojem, je vítán. Pokud se nenajdou nějaké extra chyby, tak bych to po dovolené (začátek srpna), dal do oficiálního repozitáře JOSM. Jestli tady je někdo, kdo aktivně používá ještě původní Tracer plugin (lokální mono server), vyzkoušejtě prosím, jestli to ještě stále funguje. Tuhle část jsem nijak netestoval a nerad bych původní funkcionalitu rozbil ;-) Plugin je zde: http://www.kyralovi.cz/tmp/josm/beta/Tracer.jar Zdroje jako obvykle: https://github.com/mkyral/josm-tracer/commits/ruian Upozorňuji, že je to kompilováno oproti nejnovější dostupné verzi JOSM (josm-latest), takže to ve starších verzích JOSM nemusí jít nainstalovat. Změny: *) Plugin odstraňuje budovy, které se celé ocitnou uvnitř natrasované budovy. *) Snažím se řešit překrývající se budovy - nová budova ten přečnívající kus ukousne - myslel, že to funguje na sto procent, ale teď jsem našel jeden případ, kdy to nefunguje a zatím jsem to nevyřešil. *) Snažím se připojit sousedící budovy *) snažím se odstranit nadbytečné uzly *) Jo a klávesová zkratka je teď CTRL+SHIFT+T - je to stejné s PointInfo a taky mi Ctrl+T mezitím ukradli ;-( Komu to nevyhovuje, může si to dle libosti přenastavit v JOSM. Sice to nefunguje na 100%, ale rozhodně to funguje lépe než předchozí verze. Hlavně co se problému s duplicitami týká. Takže otestujte, hlaste problémy - možná je i opravím, když zatlačíte na to správné tlačítko ;-) Já se teď pokusím něco udělat s LPIS. Asi to bude další modul do Traceru plus uvažuji o možnosti nahrávat vše ve zvoleném Boxu. Ale to ještě uvidím, jestli to bude součást Traceru, nebo jako samostatný skript. Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer - nová testovací verze
Klikám, klikám, a všiml jsem si nesrovnalosti... Když se vykopírují a vloží tagy z pointinfa, start_date má formát 2003-11-05. Když přidává tagy tracer, start_date se vloží ve tvaru 05.11.2003. To by se asi mělo sjednotit do tvaru 2003-11-05... Martin Dne 11.7.2014 23:15, Marián Kyral napsal(a): Ahoj, vzhledem k tomu, že už nějakou dobu relativně bez problémů používán novou verzi Traceru a zjistil jsem, že opravdu nejsem schopen ji odladit na 100% (veškeré snahy o ladění stejně končí mapping party - viz moje neustále stoupající pořadí ve statistikách ;-) ), tak jsem se rozhodl vývoj ukončit a dát vám to k dispozici k otestování. Pokud by se našel nějaký programátor, co by pomohl s vývojem, je vítán. Pokud se nenajdou nějaké extra chyby, tak bych to po dovolené (začátek srpna), dal do oficiálního repozitáře JOSM. Jestli tady je někdo, kdo aktivně používá ještě původní Tracer plugin (lokální mono server), vyzkoušejtě prosím, jestli to ještě stále funguje. Tuhle část jsem nijak netestoval a nerad bych původní funkcionalitu rozbil ;-) Plugin je zde: http://www.kyralovi.cz/tmp/josm/beta/Tracer.jar Zdroje jako obvykle: https://github.com/mkyral/josm-tracer/commits/ruian Upozorňuji, že je to kompilováno oproti nejnovější dostupné verzi JOSM (josm-latest), takže to ve starších verzích JOSM nemusí jít nainstalovat. Změny: *) Plugin odstraňuje budovy, které se celé ocitnou uvnitř natrasované budovy. *) Snažím se řešit překrývající se budovy - nová budova ten přečnívající kus ukousne - myslel, že to funguje na sto procent, ale teď jsem našel jeden případ, kdy to nefunguje a zatím jsem to nevyřešil. *) Snažím se připojit sousedící budovy *) snažím se odstranit nadbytečné uzly *) Jo a klávesová zkratka je teď CTRL+SHIFT+T - je to stejné s PointInfo a taky mi Ctrl+T mezitím ukradli ;-( Komu to nevyhovuje, může si to dle libosti přenastavit v JOSM. Sice to nefunguje na 100%, ale rozhodně to funguje lépe než předchozí verze. Hlavně co se problému s duplicitami týká. Takže otestujte, hlaste problémy - možná je i opravím, když zatlačíte na to správné tlačítko ;-) Já se teď pokusím něco udělat s LPIS. Asi to bude další modul do Traceru plus uvažuji o možnosti nahrávat vše ve zvoleném Boxu. Ale to ještě uvidím, jestli to bude součást Traceru, nebo jako samostatný skript. Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tagování chyb RUIANu
Zdravím, trochu jsem zase zapracoval na nástřelu tagování chyb RUIANu a zahrnul poznámky od Mariána Kyrala, viz https://wiki.openstreetmap.org/wiki/User:Maatts A hlavně jsem začal přidávat konkrétní příklady (stačí projít dvě tři vesnice a materiálu je plno). Zatím jen to co bych z mého pohledu označil za chyby, podezřelé věci k prověření budou horší, tam je to subjektivní. (Teď vidím že pan Souček před chvíli poslal další užitečné informace, tak je tam později doplním.) Martin Švec On 19.6.2014 08:44, Marián Kyral wrote: -- Původní zpráva -- Od: Martin Švec - OSM o...@maatts.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 18. 6. 2014 20:36:10 Předmět: Tagování chyb RUIANu Ahoj, když jsem byl v předchozím threadu vyzván k prvnímu nástřelu k diskusi, tak mi to nedalo a něco málo jsem ještě dneska vyplodil: https://wiki.openstreetmap.org/wiki/User:Maatts Díky, měl bych pár poznámek ;-) TODO - není zbytečné evidovat v tagu typ objektu (building, addr) Není. Může se stát, že adresa bude přímo na budově, pak by jsi nevěděl, k čemu se daný problém vztahuje. Není to sice zcela korektní vzhledem co de dohodlo v ČR, ale občas to takto někdo dělá. Proto máme extra ruian id pro budovy a pro adresy (a výhledově i pro ostatní ruian objekty) TODO - parcely? Ty bych do toho zatím netahal. *missing* - objekt úplně chybí v RUIANu (= zároveň není ref:ruian vazba na ID v RUIANu RUAIN neobsahuje úplně všechny budovy. Pouze ty, které mají číslo popisné/evidenční nebo vybrané budovy bez cp/ce. Takže toto nemusí být nutně chyba. *missing-geo* - chybějící geometrie u SO - lze vůbec tagovat pokud není co? No můžeš tu budovu nakreslit podle Bingu/KM, v nejhorším uděláš bod kterému přiřadíš building=yes (a získáš pěknou ikonku -D ) *incomplete* - chybí část budovy, která je sice vidět v KM ale není zahrnuta v geometrii SO (chybějící přilehlý objekt, přístavba, garáž, věž u kostela...) Taková chybějící věž kostela je určitě problém, ale chybějící přístavba už problém být nemusí. V RUIAN není (a nebude) úplně všechno. Pouze to co definuje nějaký zákon (a který jsem nepochopil :-D) Evidence oprav * Datum by asi neškodilo (i když se dá při troše snahy dohledat v historii) * Stav bych evidoval, minimálně datum, kdy byla daná chyba nahlášena ČÚZK. * Po vyřešení určitě smazat * Falešně chybné objekty - nějak si nedokáži představit. Ale v každém případě by mělo stačit nechat poznámku v note=* - Ten je na to určen. Ale jak říkám, tohoto by se měli spíš chopit organizátoři importů z RUIANu. Já původně jen chtěl pomoct s vylepšováním vesniček, přes které se toulám o víkendech :-) Zatím jsem ani nezkoumal, jak to třeba řeší jiné importy. V každém případě díky za snahu. Asi by to měli řešit importéři, ale jistě to znáš, den má jen 24 hodin a člověk musí dělat i jiné věci a pak nastupují priority ;-) Marián Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tagování chyb RUIANu
Ahoj, On 21.6.2014 17:22, Petr Vejsada wrote: Ahoj, Dne So 21. června 2014 17:04:10, Martin Švec - OSM napsal(a): trochu jsem zase zapracoval na nástřelu tagování chyb RUIANu a zahrnul poznámky od Mariána Kyrala, viz https://wiki.openstreetmap.org/wiki/User:Maatts to je super shrnutí, díky. Jen si nejsem úplně jistý, zda je dobré dělat si z OSM skladiště našich interních poznámek obzvláště tehdy, kdy to s OSM vlastně až tak úplně nesouvisí. Například v OSM je zakreslená budova, v RUIAN je ocásek. Jaký vztah k OSM má přidání poznámky ruian:err ? IMO žádný. Řekl bych, že je to z pohledu OSM zaplevelování DB. Tušil jsem od začátku, že to by mohl být kámen úrazu. Proto jsem se snažil o minimum tagů, ideálně jeden max. dva. Hlavní argument pro tagy je jednoduchost a rychlost. Když uvidím v JOSM podezřelý objekt, tak mě zajímá: (a) už je nahlášený jako podezřelý? (b) pokud ne, jak ho můžu nahlásit. Obojí je tagováním v JOSM okamžitě řešitelné. Do jaké míry je to obhájitelné vůči OSM, to nevím. Ty tagy označují nejasnost/rozpor mezi různými zdroji, takže jsou trochu ekvivalentem fixme/note tagů. A měly by postupně mizet. Jestli hlášení chyb bude výrazně složitější než pár kliků v JOSM, vůle něco hlásit se asi brzo začne blížit nule. Děláme to pro zábavu, kdybych chtěl pracovat pro ČUZK, tak se tam nechám zaměstnat :) Můžu poskytnout ještě nějaký prostor pro tato data v postgre, pokud to nebudou GB, což při absenci geometrií určitě nebudou. Programovat časově nezvládám. To jsme dva. Programování mám v práci nad hlavu, ve volném čase chci dělat něco jiného ;-) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] RÚIAN - budova rozdělena na několik částí
Dobrý den pane Součku, děkuji za užitečné informace, něco jsem přepsal na wiki do https://wiki.openstreetmap.org/wiki/User:Maatts . Tam najdete i konkrétní příklady, co jsem myslel ocáskem, chybějící budovou a duchem. Definici ducha už poslal Petr Vejsada: budova, která má definiční bod a nemá geometrii hranic. Napadla mě otázka k SO bez geometrie, konkrétně Budova zapsaná v ISÚI/RÚIAN, ale ještě nebyla zapsána do ISKN (čeká na doručení příslušných listin na KÚ)** -- to se asi nedá nějak jednoduše poznat? U některých SO se dá odhadnout čerstvá novostavba podle údaje Technicko-ekonomické atributy/Datum dokončení (např. http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/77458133). Ale často tam žádné datum není. Martin Švec On 21.6.2014 17:24, Petr Souček wrote: Dobrý den, a ještě reakce zde * *. Petr Souček -Original Message- From: Petr Vejsada [mailto:o...@propsychology.cz] Sent: Wednesday, June 18, 2014 10:27 PM To: OpenStreetMap Czech Republic Subject: Re: [Talk-cz] RÚIAN - budova rozdělena na několik částí Ahoj, Dne St 18. června 2014 14:37:28, Marián Kyral napsal(a): * Byla vytvořena sada testů pro odhalení chyb v databázi - AM daleko od objektu, ulice, více staveních objektů na jednom místě, nebo podezřele blízko sebe a další - čeká se na spuštění interního systém na rozesílání těchto chyb. to je skvělá zpráva! Já se pořád hrabu v databázi, teď dokončuji program na (polo)automatickou aktualizaci už importovaných území a brzy s tím asi začnu. Při tom zkoumání jsem několikrát objevil, že ty nesmysly s dvojitými adresami na jedné budově či duch uvnitř budovy sem-tam mizí. Zatím to není nijak masivní, ale děje se to. Nevím, zda to jsou individuální aktivity územních orgánů či zda je to řízené shora, ale děje se tak. Tedy zase dobrá zpráva. * určitě by měly mizet. My (ČÚZK) na editory stále působíme a zveřejňujeme jim k tomu kontrolní sestavy, viz http://www.cuzk.cz/Uvod/Produkty-a-sluzby/RUIAN/3-Overeni-uplnosti-a-spravnosti-udaju-ISUI-RUIAN/Kontroly-dat-ISUI-RUIAN.aspx . Tahle věc se bude týkat kontrol SO, kde máme totožné definiční body, blízké definiční body, atd. viz http://www.cuzk.cz/Uvod/Produkty-a-sluzby/RUIAN/3-Overeni-uplnosti-a-spravnosti-udaju-ISUI-RUIAN/Kontroly-dat-ISUI-RUIAN/Kontrola-stavebnich-objektu.aspx * * Budova vůbec není v RUIANu, i když budovy kolem ní v RUIANu jsou (úplně chybějící objekty a/nebo duchové). Duchové jsou potřeba - nemůže existovat AM bez vazby na SO. Ale protože ještě nejsou zdigitalizována všechna území, dané SO nemají definovánu geometrii a proto se jeví jako duchové. Ovšem něco jiného je nezdigitalizovaná obec plná duchů - tam nemá hlášení smysl a něco jiného je jeden duch obklopený zdigitalizovanými budovami. Tam je hlášení na místě. pan Souček tady psal, že některé budovy geometrii v RUIAN nemají a nikdy mít nebudou. Nepamatuji si, jaké přesně budovy to mají být, jen že to tak je a tedy budova bez geometrie nemusí být nutně kandidátem na hlášení chyby. * viz odpověď v předchozím mailu. Obecně jsou to tři kategorie:* *1)**Budova vedená v ISKN v území, kde není digitální mapa* *2)**Budova, která není vedena v ISKN, ale je vedena v RÚIAN* *3)**Budova zapsaná v ISÚI/RÚIAN, ale ještě nebyla zapsána do ISKN (čeká na doručení příslušných listin na KÚ)* -- -p- ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] RÚIAN - budova rozdělena na několik částí
Zdravím, já měl dojem z archivu diskusí, že hlášení chyb RUIANu chce místní rada starších probrat se zástupci ČUZK právě na Geoinformatics 2014. Takže zatím vyčkávám s editacemi budov, jestli bude nějaký výstup :-) Namátkou co jsem za dva měsíce hraní s OSM našel: * Budova v RUIANu přepůlená na dva kusy jinou hranicí, většinou parcelou - je to chyba? * Budova v RUIANu nesmyslně protažena až k hranici parcely (různé ocásky apod.) * Přilehlý kus budovy sice je v KM, ale chybí v RUIANu (např. věž u kostela) - je to chyba? * Budova vůbec není v RUIANu, i když budovy kolem ní v RUIANu jsou (úplně chybějící objekty a/nebo duchové). * Geometrie / prostorová orientace budovy sice souhlasí s KM, ale vypadá dost podezřele oproti Bingu i dalším kontrolním zdrojům, např. i vůči prokliku na ortofoto ve vdp.cuzk.cz. (Chce ČUZK hlásit i problémy tohoto typu, nebo na prověřování podezřelostí nemají kapacity a zajímají je jen jasné chyby?) Další level problému je editování budov v OSM vůči RUIANu: * Kde je RUIAN nedůvěryhodný, má smysl ručně upravit tvar budovy? Řekl bych ano, ale měla by se nějak označit, ať to někdo další neopraví zpátky... * Má smysl Tracerem proklikávat existující budovy aby se srovnaly podle RUIANu a doplnily tagy? * Tam kde nesedí RUIAN a existující budova v OSM se zachovat jak? No a o chybách v AM už toho tady proběhlo dost... Pokud má být RUIAN dlouhodobě primární zdroj pro AM, SO a další, IMHO to chce přesně nadefinovat pravidla a postupy řešení chyb. Včetně evidence typických vzorů chyb. Například by se mi líbila smluvená sada tagů přímo u objektů v OSM, že tady je error/warning a objekt by si měl prověřit ČUZK. To se dá vyexportovat, poslat do ČUZK, vizualizovat na mapě atd. atd. Z druhé strany by pak byla zpětná vazba, že v RUIANu došlo k updatu takhle otagovaného objektu = někdo by to měl znova zkontrolovat v OSM a odstranit error tagy. Díky, Martin Dne 17.6.2014 23:05, Marián Kyral napsal(a): Zdravím, při editaci jsem narazil na oblast, kde jsou budovy uměle (nějakou hranicí) rozděleny na několik částí. Například tyto budovy: http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/49788027 http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/42852951 Ale v bezprostředním okolí jsou ještě další tři budovy se stejným problémem. Chtěl jsem se zeptat, zda to je chyba, nebo je to z nějakého důvodu správně. Pokud je to chyba, tušíte, proč toto vzniká a jaká je šance, že se to časem opraví - sjednotí do jedné budovy? Díky, Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] RÚIAN - budova rozdělena na několik částí
Ahoj, * Budova vůbec není v RUIANu, i když budovy kolem ní v RUIANu jsou (úplně chybějící objekty a/nebo duchové). Duchové jsou potřeba - nemůže existovat AM bez vazby na SO. Ale protože ještě nejsou zdigitalizována všechna území, dané SO nemají definovánu geometrii a proto se jeví jako duchové. Ovšem něco jiného je nezdigitalizovaná obec plná duchů - tam nemá hlášení smysl a něco jiného je jeden duch obklopený zdigitalizovanými budovami. Tam je hlášení na místě. Jo, měl jsem na mysli duchy v digitalizovaných obcích. Ale zrovna ty by mělo jít řešit automatizovaně, tipuju. * Geometrie / prostorová orientace budovy sice souhlasí s KM, ale vypadá dost podezřele oproti Bingu i dalším kontrolním zdrojům, např. i vůči prokliku na ortofoto ve vdp.cuzk.cz. (Chce ČUZK hlásit i problémy tohoto typu, nebo na prověřování podezřelostí nemají kapacity a zajímají je jen jasné chyby?) To by mne taky zajímalo. Kapacity asi nebudou. Ona odlišnost KM a Bing může být dána i odlišností základů budovy a plochou kterou zakrývá střecha. Pokud tedy střecha nějak významně přesahuje, vypadá stejná budova v KM a na Bingu velmi rozdílně. Je otázka, jak se vlastně mají budovy v OSM mapovat. Dle půdorysu? Dle obrysu ve 2m? Nebo dle střechy? Jasně, satelitní snímky jsou navíc zkreslené na X různých způsobů. Myslel jsem spíš když má barák podezřele odlišnou základní kostru, 45 stupňů odchylku proti sousedním budovám apod... * Tam kde nesedí RUIAN a existující budova v OSM se zachovat jak? Co myslíš tím nesedí? Obecně když se víc zdrojů neshoduje - někdo kdysi nakreslil v OSM budovu, v RUIANu má jinou geometrii a v Bingu je tam pole :-) Jestli do toho hrabat, nebo radši nechat být. Ale tam asi univerzální odpověď neexistuje. Btw, to mi připomíná - jde v tvém Traceru přetrasovat starou OSM budovu, aniž by se změnila její geometrie? To by se hodilo u budov, kde RUIAN je zjevně špatně a chci budově jen doplnit tagy z RUIANu. Například by se mi líbila smluvená sada tagů přímo u objektů v OSM, že tady je error/warning a objekt by si měl prověřit ČUZK. To se dá vyexportovat, poslat do ČUZK, vizualizovat na mapě atd. atd. Z druhé strany by pak byla zpětná vazba, že v RUIANu došlo k updatu takhle otagovaného objektu = někdo by to měl znova zkontrolovat v OSM a odstranit error tagy. Tahle sada by se mi taky líbila. Nechceš nahodit první nástřel k diskuzi? Jak jsem psal výše, tento postup při hlášení chyb je reálný, jen musíme počkat, až to na ČÚZK zrealizují. Ale má smysl se na to už teď připravit. Třeba tím, že si ty nalezené problémy označíme a pak je budeme postupně odesílat. Heh, no nevím jestli jsem ten nejpovolanější, s mými asi sedmi vesničkami :-) Čekal bych to spíš od úderníků, kteří cpou RUIAN data do OSM ve velkém. Ale zkusím se během zítřka zamyslet, aby se aspoň rozvinula diskuse. Fakt je, že v tuhle chvíli do mapy pořád dál přibývají budovy, které bude nutné později znova projít kvůli neexistenci označování chyb :-(( Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] Tagování chyb RUIANu
Ahoj, když jsem byl v předchozím threadu vyzván k prvnímu nástřelu k diskusi, tak mi to nedalo a něco málo jsem ještě dneska vyplodil: https://wiki.openstreetmap.org/wiki/User:Maatts Ale jak říkám, tohoto by se měli spíš chopit organizátoři importů z RUIANu. Já původně jen chtěl pomoct s vylepšováním vesniček, přes které se toulám o víkendech :-) Zatím jsem ani nezkoumal, jak to třeba řeší jiné importy. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Votice
Jojo, u spousty vesniček je to normální stav, co jsem si všiml. Hlavně kde jsou zdrojem jen scanované katastrální mapy + bing. Tam je to často věštění z křišťálové koule. Některé objekty typu kostel, fara apod. se ve starých KM obkreslovaly snad od Marie Terezie ;-) Horší je, že plno chyb je i v RUIANu -- někde až 5% budov má jasné chyby, dalších cca 10% je podezřelých. Záleží jak jde. Takže teď vyčkávám, jaký reporting chyb dohodne komunita s CUZK, než začnu prznit další vesničky. (Nejlíp asi tagovat přímo objekty v OSM. Ať se to dá hromadně vytáhnout, vizualizovat a pak synchronizovat opravy podle ref:ruian:* tagů. Zapisovat každou useknutou stodolu do wiki, na to fakt nemám. Taky je problém, že pokud existující data v OSM nesouhlasí, tak bez místní znalosti často nepoznám, jestli je chyba na straně OSM. A nebo to naopak někdo místní už opravil podle reality a nesmysly jsou v RUIANu.) Martin Dne 11.6.2014 00:11, Matěj Cepl napsal(a): Jenom něčemu nerozumím anebo Votice jsou z heldiska OSM docela katastrofa? Hledal jsem na OSM kostel svatého Václava vedle zámku a nenašel jsem ani kostel ani zámek (tedy ani jeden ze dvou zámků, abych byl přesný). Porovnejte http://goo.gl/maps/P0oRX a http://mapy.cz/s/a6u5 s tím co je na OSM http://osm.org/go/0Jxpws5hQ-- To je prostě podle mého jiné město, domy jsou jinak postavené a tak. Ne, nekopíruju nic z proprietárních map, jenom ukazuji v rámci QA jak moc jsme na tom špatně. Je někde seznam podobných katastrof? Tohle není jeden dva bugy, ale (minimálně) tenhle kus města se musí podle mého celý předělat. Matěj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] Mistni nazvy z cuzk:km - place=locality?
Ahoj, při přidávání lesních cest jsem začal opisovat z CUZK:KM lokální označení neobydlených míst (polesí, pole...) poblíž Brna. Zaplevelil jsem tím mapu trochu víc než jsem původně čekal, tak se chci ujistit, že nedělám něco nežádoucího. Viz http://www.openstreetmap.org/#map=14/49.2423/16.4198 Názvy jsou nody s tagem place=locality, po vzoru hopeta kousek severněji u Lažánek. Je to ok? Popis na wiki vcelku sedí (http://wiki.openstreetmap.org/wiki/Tag:place%3Dlocality), ale prý by těch tagů mělo spíš ubývat. Vhodnější označení jsem ale nenašel. Turistické mapy tyhle názvy běžně obsahují, ale nevím jak je zkousnou renderery OSM... Díky Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Mistni nazvy z cuzk:km - place=locality?
Díky za info, takže dejme tomu že je to v por(ádku ;-) Na polích kolem vesnic je ne(kdy pojmenovaný každý metr, takže s hustotou se musí opatrne(, to už jsem zjistil. Martin Dne 27.5.2014 21:17, Marián Kyral napsal(a): Taky to tak de(lám. Ale u nás to není tak nahusto. http://www.openstreetmap.org/node/2486910675 Marián On 27. kve(tna 2014 21:12:43 CEST, Jan Dudík jan.du...@gmail.com wrote: Zjevne( nejsi sám http://www.openstreetmap.org/#map=14/49.1242/14.3598 JAnD Dne 27. kve(tna 2014 20:42 Martin Švec - OSM o...@maatts.cz mailto:o...@maatts.cz napsal(a): Ahoj, pr(i pr(idávání lesních cest jsem zac(al opisovat z CUZK:KM lokální oznac(ení neobydlených míst (polesí, pole...) poblíž Brna. Zaplevelil jsem tím mapu trochu víc než jsem pu*vodne( c(ekal, tak se chci ujistit, že nede(lám ne(co nežádoucího. Viz http://www.openstreetmap.org/#map=14/49.2423/16.4198 Názvy jsou nody s tagem place=locality, po vzoru hopeta kousek severne(ji u Lažánek. Je to ok? Popis na wiki vcelku sedí (http://wiki.openstreetmap.org/wiki/Tag:place%3Dlocality), ale prý by te(ch tagu* me(lo spíš ubývat. Vhodne(jší oznac(ení jsem ale nenašel. Turistické mapy tyhle názvy be(žne( obsahují, ale nevím jak je zkousnou renderery OSM... Díky Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org mailto:Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz -- Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz -- Odesláno z mého telefonu s Androidem pomocí pošty K-9 Mail. Omluvte prosím moji struc(nost. ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
