Tracer - pLPIS

48 zpráv
Zpět na přehled

Tracer - pLPIS

48 zpráv MPPMJPJP 11 účastníků 58 min čtení
  1. Marián Kyral mkyral na email.cz #mc17d9c
    Ahoj, takže mám skoro dokončenou první verzi. Co to umí: umí získat geometrii a kulturu prvku a následně vytvořit cestu nebo multipolygon (pokud existují nějaké vnitřní prvky) a otagovat. Co to neumí: napojení na sousední pole (pokud se dané pole dotýkají), neřeší se konflikty, nekontroluje se existence daného objektu a zatím má každý modul samostatnou klávesovou zkratku. Než vám to dám k dispozici na otestování, potřebuji ještě chvíli na vlastní testování, ale hlavně vyřešit tyto "drobnosti" a) Mapování - to mám zatím takto: *"orná půda":* "landuse": "farmland" *"chmelnice":* "landuse": "farmland"; "crop": "hop" *"vinice":* "landuse": "vineyard" *"ovocný sad"*: landuse": "orchard" *"travní porost":* landuse": "meadow" *"porost RRD":* landuse": "forest" *"zalesněná půda":* landuse", "forest" *"rybník":* landuse": "reservoir" *"jiná kultura":* landuse": "farmland" *"jiná kultura (školka)":* landuse": "plant_nursery" *"jiná kultura (zelinářská zahrada)":* landuse": "farmland"; "crop": "vegetables" Bohužel si nejsem vůbec jistý, že vše dostanu přesně tak jak je to napsáno výše. Už jsem narazil u "zalesněno" a "zalesněná půda". Bohužel nevím, kde by se daly otestovat speciální případy. b) LPIS nebo pLPIS? Hlavně u tagu source a ref. Jestli do toho skriptu koukám správně, source se nastavuje na lpis a do ref se dá LPIS_ID. A dále se nastavuje lpis:kultura. Ve wiki ( http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap#pLPIS_-_ve.C5.99ejn.C3.BD_registr_p.C5.AFdy ) navrhuji "source=eagri:plpis" (podle vzoru: cuzk:km, cuzk:ruian...) Místo ref= bych nastavil ref:plpis (opět dle ruian) Mám taky nastavit pole *(p)lpis:kultura*? A co pole *kultura_od* namapovaná třeba na *start_date* ? Co myslíte? Marián
  2. Pavel Machek pavel na ucw.cz #mceebc8
    Ahoj!
    takže mám skoro dokončenou první verzi.
    Gratulace :-). Na imports@ mailing listu zadny velky rev nebyl, takze jsem zacal importovat okoli Mukarova abych videl, jak to bude vypadat. Vypada to o dost lip, nez veci co jsem delal rucne...
    Co to umí: umí získat geometrii a kulturu prvku a následně vytvořit cestu nebo multipolygon (pokud existují nějaké vnitřní prvky) a otagovat. Co to neumí: napojení na sousední pole (pokud se dané pole dotýkají), neřeší se konflikty, nekontroluje se existence daného objektu a zatím má každý modul samostatnou klávesovou zkratku. Než vám to dám k dispozici na otestování, potřebuji ještě chvíli na vlastní testování, ale hlavně vyřešit tyto "drobnosti" a) Mapování - to mám zatím takto: *"orná půda":* "landuse": "farmland" *"chmelnice":* "landuse": "farmland"; "crop": "hop" *"vinice":* "landuse": "vineyard" *"ovocný sad"*: landuse": "orchard" *"travní porost":* landuse": "meadow" *"porost RRD":* landuse": "forest"
    Tam jsem chtel davat natural=scrub, ale davam landuse=scrub. Opravim skript... ale ona na importovanem uzemi zrejme ta situace jeste nenastala...
    *"jiná kultura (školka)":* landuse": "plant_nursery"
    Tohle v tech cislech nevidim... aha, tak ne, je to tam, 91, taguju jako landuse=forest. Aha... ale dle obrazku: http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dplant_nursery Jsme si jisty ze tohle je nase "skolka"? Obrazek tomu uplne neodpovida...
    Bohužel si nejsem vůbec jistý, že vše dostanu přesně tak jak je to napsáno výše. Už jsem narazil u "zalesněno" a "zalesněná půda". Bohužel nevím, kde by se daly otestovat speciální případy. b) LPIS nebo pLPIS? Hlavně u tagu source a ref. Jestli do toho skriptu koukám správně, source se nastavuje na lpis a do ref se dá LPIS_ID. A dále se nastavuje lpis:kultura.
    Stat tomu rika "Veřejný registr půdy - LPIS", takze bych nechal lpis.
    Ve wiki ( http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap#pLPIS_-_ve.C5.99ejn.C3.BD_registr_p.C5.AFdy ) navrhuji "source=eagri:plpis" (podle vzoru: cuzk:km, cuzk:ruian...) Místo ref= bych nastavil ref:plpis (opět dle ruian)
    No, ja bych nechal ref, ale asi je to dost jedno...
    Mám taky nastavit pole *(p)lpis:kultura*? A co pole *kultura_od* namapovaná třeba na *start_date* ?
    V importovanejch uz lpis:kultura nenastavuju. Start date proc ne... Pavel
  3. Marián Kyral mkyral na email.cz #ma22d04
    Ahoj!
    takže mám skoro dokončenou první verzi.
    Gratulace :-). Na imports@ mailing listu zadny velky rev nebyl, takze jsem zacal importovat okoli Mukarova abych videl, jak to bude vypadat. Vypada to o dost lip, nez veci co jsem delal rucne...
    Evidentně si všichni užívají dovolenou, nebo to přehlédli ;-)
    Co to umí: umí získat geometrii a kulturu prvku a následně vytvořit cestu nebo multipolygon (pokud existují nějaké vnitřní prvky) a otagovat. Co to neumí: napojení na sousední pole (pokud se dané pole dotýkají), neřeší se konflikty, nekontroluje se existence daného objektu a zatím má každý modul samostatnou klávesovou zkratku. Než vám to dám k dispozici na otestování, potřebuji ještě chvíli na vlastní testování, ale hlavně vyřešit tyto "drobnosti" a) Mapování - to mám zatím takto: *"orná půda":* "landuse": "farmland" *"chmelnice":* "landuse": "farmland"; "crop": "hop" *"vinice":* "landuse": "vineyard" *"ovocný sad"*: landuse": "orchard" *"travní porost":* landuse": "meadow" *"porost RRD":* landuse": "forest"
    Tam jsem chtel davat natural=scrub, ale davam landuse=scrub. Opravim skript... ale ona na importovanem uzemi zrejme ta situace jeste nenastala...
    No právě proto je to potřeba sjednotit. Já taky zatím narazil jen na ornou půdu, travní porost a zalesněnou půdu. Místa, kde jsou školky nebo ovocné sady v LPIS nejsou.
    *"jiná kultura (školka)":* landuse": "plant_nursery"
    Tohle v tech cislech nevidim... aha, tak ne, je to tam, 91, taguju jako landuse=forest. Aha... ale dle obrazku: http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dplant_nursery Jsme si jisty ze tohle je nase "skolka"? Obrazek tomu uplne neodpovida...
    Tak ona lesní školka má několik oddělení - semínka, sazeničky a stromečky (v případě lesní školky). No a na obrázku jsou ty sazeničky. Navíc, když se koukneš na wiki, tak je tam dub. * species:en <http://wiki.openstreetmap.org/w/index.php?title=Key:species:en&action=edit&redlink=1>=White oak <http://wiki.openstreetmap.org/w/index.php?title=Tag:species:en%3DWhite_oak&action=edit&redlink=1>
    Bohužel si nejsem vůbec jistý, že vše dostanu přesně tak jak je to napsáno výše. Už jsem narazil u "zalesněno" a "zalesněná půda". Bohužel nevím, kde by se daly otestovat speciální případy. b) LPIS nebo pLPIS? Hlavně u tagu source a ref. Jestli do toho skriptu koukám správně, source se nastavuje na lpis a do ref se dá LPIS_ID. A dále se nastavuje lpis:kultura.
    Stat tomu rika "Veřejný registr půdy - LPIS", takze bych nechal lpis.
    Veřejný -> public -> pLPIS ;-) Ale jak tak koukám, pLPIS je jen ta webová prohlížečka a WMS/WFS služby jsou zvlášť. Takže to předělám na eagri:lpis. A nebo že by mze:lpis? Eagri je jen specializovaný portál mze.
    Ve wiki ( http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap#pLPIS_-_ve.C5.99ejn.C3.BD_registr_p.C5.AFdy ) navrhuji "source=eagri:plpis" (podle vzoru: cuzk:km, cuzk:ruian...) Místo ref= bych nastavil ref:plpis (opět dle ruian)
    No, ja bych nechal ref, ale asi je to dost jedno...
    No u importu z RUIANu se nám sešlo, že v některých případech může být na jednom objektu ID Stavebního objektu a zároveň i ID Adresy. Tak se to rozdělilo. To u LPIS asi nehrozí (i když kdo ví), ale z jednoduchého ref není jasné, co za číslo to je. Jestli LPIS ID, nebo nějaké úplně jiné ID. Myslím že ref:lpis je lepší.
    Mám taky nastavit pole *(p)lpis:kultura*? A co pole *kultura_od* namapovaná třeba na *start_date* ?
    V importovanejch uz lpis:kultura nenastavuju. Start date proc ne... Pavel
    OK. Jen právě nevím, jestli je start_date ta správná volba. Více by se mi líbilo: valid_from nebo něco takového. Ale na wiki jsem nic takového nenašel. Marián
  4. Pavel Machek pavel na ucw.cz #m9fe6eb
    Ahoj!
    Než vám to dám k dispozici na otestování, potřebuji ještě chvíli na vlastní testování, ale hlavně vyřešit tyto "drobnosti" a) Mapování - to mám zatím takto: *"orná půda":* "landuse": "farmland" *"chmelnice":* "landuse": "farmland"; "crop": "hop" *"vinice":* "landuse": "vineyard" *"ovocný sad"*: landuse": "orchard" *"travní porost":* landuse": "meadow" *"porost RRD":* landuse": "forest"
    Tam jsem chtel davat natural=scrub, ale davam landuse=scrub. Opravim skript... ale ona na importovanem uzemi zrejme ta situace jeste nenastala...
    No právě proto je to potřeba sjednotit. Já taky zatím narazil jen na ornou půdu, travní porost a zalesněnou půdu. Místa, kde jsou školky nebo ovocné sady v LPIS nejsou.
    Jsou; jeden sad jsem importoval mezi Masojedama a Doubravcicema.
    b) LPIS nebo pLPIS? Hlavně u tagu source a ref. Jestli do toho skriptu koukám správně, source se nastavuje na lpis a do ref se dá LPIS_ID. A dále se nastavuje lpis:kultura.
    Stat tomu rika "Veřejný registr půdy - LPIS", takze bych nechal lpis.
    Veřejný -> public -> pLPIS ;-) Ale jak tak koukám, pLPIS je jen ta webová prohlížečka a WMS/WFS služby jsou zvlášť. Takže to předělám na eagri:lpis. A nebo že by mze:lpis? Eagri je jen specializovaný portál mze.
    Prosim ciste source=lpis. Tak se jmenuje stranka importu, a tak jsou importovana existujici data.
    Ve wiki ( http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap#pLPIS_-_ve.C5.99ejn.C3.BD_registr_p.C5.AFdy ) navrhuji "source=eagri:plpis" (podle vzoru: cuzk:km, cuzk:ruian...) Místo ref= bych nastavil ref:plpis (opět dle ruian)
    No, ja bych nechal ref, ale asi je to dost jedno...
    No u importu z RUIANu se nám sešlo, že v některých případech může být na jednom objektu ID Stavebního objektu a zároveň i ID Adresy. Tak se to rozdělilo. To u LPIS asi nehrozí (i když kdo ví), ale z jednoduchého ref není jasné, co za číslo to je. Jestli LPIS ID, nebo nějaké úplně jiné ID. Myslím že ref:lpis je lepší.
    No, existujici data pouzivaji ref=, a jestli to neni jasne, jde to upresnit na wiki. Nechal bych cisty ref=.
    OK. Jen právě nevím, jestli je start_date ta správná volba. Více by se mi líbilo: valid_from nebo něco takového. Ale na wiki jsem nic takového nenašel.
    Ono asi v principu neni vylouceny dat tam vlastni tag. ref:lpis by taky byl vlastni tag... Pavel
  5. Marián Kyral mkyral na email.cz #m44bb41
    "Ahoj!
    Než vám to dám k dispozici na otestování, potřebuji ještě chvíli na vlastní testování, ale hlavně vyřešit tyto "drobnosti" a) Mapování - to mám zatím takto: *"orná půda":* "landuse": "farmland" *"chmelnice":* "landuse": "farmland"; "crop": "hop" *"vinice":* "landuse": "vineyard" *"ovocný sad"*: landuse": "orchard" *"travní porost":* landuse": "meadow" *"porost RRD":* landuse": "forest"
    Tam jsem chtel davat natural=scrub, ale davam landuse=scrub. Opravim skript... ale ona na importovanem uzemi zrejme ta situace jeste nenastala...
    No právě proto je to potřeba sjednotit. Já taky zatím narazil jen na ornou půdu, travní porost a zalesněnou půdu. Místa, kde jsou školky nebo ovocné sady v LPIS nejsou.
    Jsou; jeden sad jsem importoval mezi Masojedama a Doubravcicema. Špatně jsem se vyjádřil. Myslel jsem  to tak, že místa v okolí, o kterých vím, že tam ty ovocné sady a školky určitě jsou, v LPIS nejsou.
    b) LPIS nebo pLPIS? Hlavně u tagu source a ref. Jestli do toho skriptu koukám správně, source se nastavuje na lpis a do ref se dá LPIS_ID. A dále se nastavuje lpis:kultura.
    Stat tomu rika "Veřejný registr půdy - LPIS", takze bych nechal lpis.
    Veřejný -> public -> pLPIS ;-) Ale jak tak koukám, pLPIS je jen ta webová prohlížečka a WMS/WFS služby jsou zvlášť. Takže to předělám na eagri:lpis. A nebo že by mze:lpis? Eagri je jen specializovaný portál mze.
    Prosim ciste source=lpis. Tak se jmenuje stranka importu, a tak jsou importovana existujici data. A nebude to pak v kolizi? LPIS je obecná zkratka a kromě českého jsem našel i slovenský a evropský (a to asi nebudou všechny). Nebo budeme aplikovat princip, kdo dřív přijde, ten dřív mele? http://www.podnemapy.sk/lpis_verejnost/viewer.htm http://ies.jrc.ec.europa.eu/our-activities/support-for-member-states/lpis-iacs.html
    Ve wiki ( http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap#
    pLPIS_-_ve.C5.99ejn.C3.BD_registr_p.C5.AFdy
    ) navrhuji "source=eagri:plpis" (podle vzoru: cuzk:km, cuzk:ruian...) Místo ref= bych nastavil ref:plpis (opět dle ruian)
    No, ja bych nechal ref, ale asi je to dost jedno...
    No u importu z RUIANu se nám sešlo, že v některých případech může být na jednom objektu ID Stavebního objektu a zároveň i ID Adresy. Tak se to rozdělilo. To u LPIS asi nehrozí (i když kdo ví), ale z jednoduchého ref není jasné, co za číslo to je. Jestli LPIS ID, nebo nějaké úplně jiné ID. Myslím že ref:lpis je lepší.
    No, existujici data pouzivaji ref=, a jestli to neni jasne, jde to upresnit na wiki. Nechal bych cisty ref=. OK
    OK. Jen právě nevím, jestli je start_date ta správná volba. Více by se mi líbilo: valid_from nebo něco takového. Ale na wiki jsem nic takového nenašel.
    Ono asi v principu neni vylouceny dat tam vlastni tag. ref:lpis by taky byl vlastni tag... Pavel" To jo. Ale je otázka, jestli by to vůbec k něčemu bylo. Pořád čekám, jestli se vyjádří ostatní, ale buď jsou na dovolené, nebo u vody ;-) Marián
  6. Pavel Machek pavel na ucw.cz #me7f462
    Ahoj!
    b) LPIS nebo pLPIS? Hlavně u tagu source a ref. Jestli do toho skriptu koukám správně, source se nastavuje na lpis a do ref se dá LPIS_ID. A dále se nastavuje lpis:kultura.
    Stat tomu rika "Veřejný registr půdy - LPIS", takze bych nechal lpis.
    Veřejný -> public -> pLPIS ;-) Ale jak tak koukám, pLPIS je jen ta webová prohlížečka a WMS/WFS služby jsou zvlášť. Takže to předělám na eagri:lpis. A nebo že by mze:lpis? Eagri je jen specializovaný portál mze.
    Prosim ciste source=lpis. Tak se jmenuje stranka importu, a tak jsou importovana existujici data. A nebude to pak v kolizi? LPIS je obecná zkratka a kromě českého jsem našel i slovenský a evropský (a to asi nebudou všechny). Nebo budeme aplikovat princip, kdo dřív přijde, ten dřív mele?
    Kdo driv prijde, ten driv mele :-). Pokud polaci nebo slovaci zkusi import, tak zjisti ze stranka na wiki uz existuje, takze by si konfliktu meli vsimnout. A i kdyby nahodou ne, nebude to velky problem: importujem ta data jen na ceskym uzemi... Pavel
  7. Petr Vejsada osm na propsychology.cz #m28f22a
    Ahoj,
    OK. Jen právě nevím, jestli je start_date ta správná volba. Více by se mi líbilo: valid_from nebo něco takového. Ale na wiki jsem nic takového nenašel.
    To jo. Ale je otázka, jestli by to vůbec k něčemu bylo. Pořád čekám, jestli se vyjádří ostatní, ale buď jsou na dovolené, nebo u vody
    u vody jsem jen málokdy :-(, nicméně k tomuto - tento spam ;-) například u mnou nově trasovaných budov poctivě mažu a nechávám jen building=* a ref_ruian:building, protože z druhého jmenovaného lze vše ostatní, a nejen to, dovodit.
  8. Petr Vejsada osm na propsychology.cz #mc17aa3
    Ahoj,
    Špatně jsem se vyjádřil. Myslel jsem to tak, že místa v okolí, o kterých vím, že tam ty ovocné sady a školky určitě jsou, v LPIS nejsou.
    no protože v LPIS je jen to, co tam majitel chce zadat. Kde konkrétně tyto sady a školky jsou? Chci se podívat, jestli se jejich existence dá dovodit z RUIAN. A už je alespoň zhruba rozmyšlená možnost aktualizace? Pořád si myslím, že by bylo užitečné propojit LPIS s RUIAN, přesněji použít RUIAN a zpřesnit ho LPISem.
  9. Marián Kyral mkyral na email.cz #mbbc5f5
    Ahoj,
    Špatně jsem se vyjádřil. Myslel jsem to tak, že místa v okolí, o kterých vím, že tam ty ovocné sady a školky určitě jsou, v LPIS nejsou.
    no protože v LPIS je jen to, co tam majitel chce zadat. Kde konkrétně tyto sady a školky jsou? Chci se podívat, jestli se jejich existence dá dovodit z RUIAN.
    Jeden sad je tady: http://mapy.cz/zakladni?x=18.4293608&y=49.6726180&z=17&base=ophoto (alespoň to vypadá jako sad, když jedu kolem.) A lesní školka je tady: http://mapy.cz/zakladni?x=18.3937704&y=49.6623786&z=16&base=ophoto
    A už je alespoň zhruba rozmyšlená možnost aktualizace? Pořád si myslím, že by bylo užitečné propojit LPIS s RUIAN, přesněji použít RUIAN a zpřesnit ho LPISem.
    Já si hraji jen s pluginem do Traceru. A už to celkem obstojně funguje. Nevím proč, ale mám raději, když mám editaci pod kontrolou, než když se tam nahrne všechno najednou a pak možná někdy v budoucnu to někdo spasuje s okolím. A třeba taky nikdy. Jak by sis to propojení představoval? Mne nenapadá, jak by se to dalo udělat. Marián
  10. Marián Kyral mkyral na email.cz #mbeb9f3
    Takz(e pro zájemce bych tu me(l ochutnávku: http://www.kyralovi.cz/tmp/josm/beta/lpis/Tracer.jar Zdrojáky: https://github.com/mkyral/josm-tracer/tree/plpis Aktuální mapování je: https://github.com/mkyral/josm-tracer/blob/plpis/src/org/openstreetmap/josm/plugins/tracer/LpisRecord.java#L126 Plugin obsahuje poslední verzi RUIAN traceru a experimentální verzi LPIS. *Zdu*razn(uji*, z(e je to urc(eno hlavne( na proklikání a nahlás(ení pr(ípadných chyb nebo návrhu* na vyleps(ení. Plugin nic nespojuje (pokud se plochy dotýkají), ner(es(í pr(ekrývající se plochy ani vícenásobné trasování - kolikrát c(love(k klikne, tolik objektu* se vytvor(í. Na ne(jaká izolovaná pole je to dobr(e pouz(itelné, ale pokud je více polí, které tvor(í jeden lán, tak to zatím pouz(itelné není. Budu muset zevs(eobecnit kód, který pouz(ívám ke spojování budov tak aby dobr(e fungoval i s landuse. Uvidím jak to pu*jde. Moz(ná to nebude tak sloz(ité. Trochu jsem si poklikal, vypadá to pe(kne(, ale u takových te(ch "sloz(ených" lánu* to generuje stras(ne( moc malých polygonu*. Nevím jak moc to vadí, ale kdybych to slouc(il do jednoho, tak zase nevím, co s LPIS ID. Pouz(ít náhodné, nebo úplne( vyhodit? To by ale byl zase problém s aktualizací. Marián
  11. Dalibor Jelínek dalibor na dalibor.cz #m2a4f83
    Ahoj, jen k tomu znaceni importu z pLPIS. Taky bych hlasoval pro source=eagri:lpis, protoze pokud existuji jine LPIS registry v Evrope, tak at je jasne, z jakeho zdroje data pochazi. A hlasite hlasuji pro ref:lpis= misto nic nerikajiciho ref= Jak pak nejaky uzivatel u objektu pozna, k cemu se to referencni cislo vztahuje? V kazdem pripade by bylo vhodne to tagovani prodebatovat a popsat na wiki, ktera je teda velmi malo obsazna. Skoda, ze se nedodrzelo pravidlo, ze nejdrive se diskutuje, pak se dojde k nejakemu zaveru a pak se teprve importuje. Zdravi, Dalibor
  12. Marián Kyral mkyral na email.cz #mca705f
    Ahoj, jen k tomu znaceni importu z pLPIS. Taky bych hlasoval pro source=eagri:lpis, protoze pokud existuji jine LPIS registry v Evrope, tak at je jasne, z jakeho zdroje data pochazi. A hlasite hlasuji pro ref:lpis= misto nic nerikajiciho ref= Jak pak nejaky uzivatel u objektu pozna, k cemu se to referencni cislo vztahuje? Hurá, Dalibor dorazil z dovolené, už tu nejsem se svým názorem sám ;-) V kazdem pripade by bylo vhodne to tagovani prodebatovat a popsat na wiki, ktera je teda velmi malo obsazna. Skoda, ze se nedodrzelo pravidlo, ze nejdrive se diskutuje, pak se dojde k nejakemu zaveru a pak se teprve importuje. No hlavně je podivné to ticho po pěšině na imports na . Asi taky všichni na dovolené. S tím, jak je to teď popsáno na wiki to nemůže projít :-D Marián Zdravi, Dalibor Ahoj!
    Než vám to dám k dispozici na otestování, potřebuji ještě chvíli na vlastní testování, ale hlavně vyřešit tyto "drobnosti" a) Mapování - to mám zatím takto: *"orná půda":* "landuse": "farmland" *"chmelnice":* "landuse": "farmland"; "crop": "hop" *"vinice":* "landuse": "vineyard" *"ovocný sad"*: landuse": "orchard" *"travní porost":* landuse": "meadow" *"porost RRD":* landuse": "forest"
    Tam jsem chtel davat natural=scrub, ale davam landuse=scrub. Opravim skript... ale ona na importovanem uzemi zrejme ta situace jeste nenastala...
    No právě proto je to potřeba sjednotit. Já taky zatím narazil jen na ornou půdu, travní porost a zalesněnou půdu. Místa, kde jsou školky nebo ovocné sady v LPIS nejsou.
    Jsou; jeden sad jsem importoval mezi Masojedama a Doubravcicema. Špatně jsem se vyjádřil. Myslel jsem  to tak, že místa v okolí, o kterých vím, že tam ty ovocné sady a školky určitě jsou, v LPIS nejsou.
    b) LPIS nebo pLPIS? Hlavně u tagu source a ref. Jestli do toho skriptu koukám správně, source se nastavuje na lpis a do ref se dá LPIS_ID. A dále se nastavuje lpis:kultura.
    Stat tomu rika "Veřejný registr půdy - LPIS", takze bych nechal lpis.
    Veřejný -> public -> pLPIS ;-) Ale jak tak koukám, pLPIS je jen ta webová prohlížečka a WMS/WFS služby jsou zvlášť. Takže to předělám na eagri:lpis. A nebo že by mze:lpis? Eagri je jen specializovaný portál mze.
    Prosim ciste source=lpis. Tak se jmenuje stranka importu, a tak jsou importovana existujici data. A nebude to pak v kolizi? LPIS je obecná zkratka a kromě českého jsem našel i slovenský a evropský (a to asi nebudou všechny). Nebo budeme aplikovat princip, kdo dřív přijde, ten dřív mele? http://www.podnemapy.sk/lpis_verejnost/viewer.htm http://ies.jrc.ec.europa.eu/our-activities/support-for-member-states/lpis-iacs.html
    Ve wiki ( http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap#
    pLPIS_-_ve.C5.99ejn.C3.BD_registr_p.C5.AFdy
    ) navrhuji "source=eagri:plpis" (podle vzoru: cuzk:km, cuzk:ruian...) Místo ref= bych nastavil ref:plpis (opět dle ruian)
    No, ja bych nechal ref, ale asi je to dost jedno...
    No u importu z RUIANu se nám sešlo, že v některých případech může být na jednom objektu ID Stavebního objektu a zároveň i ID Adresy. Tak se to rozdělilo. To u LPIS asi nehrozí (i když kdo ví), ale z jednoduchého ref není jasné, co za číslo to je. Jestli LPIS ID, nebo nějaké úplně jiné ID. Myslím že ref:lpis je lepší.
    No, existujici data pouzivaji ref=, a jestli to neni jasne, jde to upresnit na wiki. Nechal bych cisty ref=. OK
    OK. Jen právě nevím, jestli je start_date ta správná volba. Více by se mi líbilo: valid_from nebo něco takového. Ale na wiki jsem nic takového nenašel.
    Ono asi v principu neni vylouceny dat tam vlastni tag. ref:lpis by taky byl vlastni tag... Pavel To jo. Ale je otázka, jestli by to vůbec k něčemu bylo. Pořád čekám, jestli se vyjádří ostatní, ale buď jsou na dovolené, nebo u vody ;-) Marián
  13. Pavel Machek pavel na ucw.cz #mc200f0
    Ahoj,
    Špatně jsem se vyjádřil. Myslel jsem to tak, že místa v okolí, o kterých vím, že tam ty ovocné sady a školky určitě jsou, v LPIS nejsou.
    no protože v LPIS je jen to, co tam majitel chce zadat. Kde konkrétně tyto sady a školky jsou? Chci se podívat, jestli se jejich existence dá dovodit z RUIAN.
    2 sady jsou mezi Doubravcicema a Masojedama, viz archiv.
    A už je alespoň zhruba rozmyšlená možnost aktualizace? Pořád si myslím, že by bylo užitečné propojit LPIS s RUIAN, přesněji použít RUIAN a zpřesnit ho LPISem.
    Nebude jednoddussi vybrat z RUIANu mista nepokryta LPISem, a zamerit se na jejich import? Pavel
  14. Pavel Machek pavel na ucw.cz #mf40516
    Ahoj, jen k tomu znaceni importu z pLPIS. Taky bych hlasoval pro source=eagri:lpis, protoze pokud existuji jine LPIS registry v Evrope, tak at je jasne, z jakeho zdroje data pochazi. A hlasite hlasuji pro ref:lpis= misto nic nerikajiciho ref= Jak pak nejaky uzivatel u objektu pozna, k cemu se to referencni cislo vztahuje?
    Podle source=lpis, a najde si to na wiki? Ted uz bych to nemenil.
    V kazdem pripade by bylo vhodne to tagovani prodebatovat a popsat na wiki, ktera je teda velmi malo obsazna. Skoda, ze se nedodrzelo pravidlo, ze nejdrive se diskutuje, pak se dojde k nejakemu zaveru a pak se teprve importuje.
    Ja myslim, ze jsem diskutoval docela dlouho, ale debata se jako obvykle strhla az kdyz jsem zacal import. Pavel
  15. Petr Vejsada osm na propsychology.cz #m77d120
    Ahoj,
    Jeden sad je tady: A lesní školka je tady:
    díky, v RUIAN je to jen prostá zemědělská půda, tedy taky nic.
    Jak by sis to propojení představoval? Mne nenapadá, jak by se to dalo udělat.
    No úplně přesně to nevím :). Napřed bych viděl úvahu, zda jednotlivá políčka (=parcely a LPIS polygony) sdružovat nebo ne. Na tom závisí i strategie aktualizací. Zatím mi přijde nemožné hlídat si podle ref:, zda se něco v LPIS změnilo a na změnu zareagovat. Nevíme, co se může měnit. Určitě druh kultury, možná i geometrie? Je možné, že tam, kde je teď 50 malých políček bude za 3 roky jen jedno velké či naopak? Nevíme. Opravdu je reálné změny v LPIS kopírovat do OSM? Myslím, že spíš ne.Pokud ne, pak nevidím smysl v importu malých polygonů, ale jen sdružených. Představuji si to tak, že by se vyrobily co největší polygony se stejným landuse, a to z parcel, LPIS půdy a LPIS krajinných prvků. Ty by pak bylo potřeba napasovat do OSM ;-). Určitě nemyslím je tam plácnout s tím, že se možná někdy napojí na stávající landuse. I spojení se stávajícími OSM daty by se dalo udělat. Jen by bylo potřeba vymyslet pravidla, tedy co dělat, když vznikne průnik pole z RUIAN/LPIS s lesem v OSM, zastavěná plocha v RUIAN s polem v OSM atd atd. Co dělat s případy dvojparcel, tedy kdy je jedna parcela se zahradou a uvnitř ní je jiná parcela se zastavěnou plochou, prostě barák uprostřed zahrady. Co máme či můžeme mít k dispozici: - polygony parcel z RUIAN, kde je 60 kombinací druh_pozemku a zpusob_vyuziti_pozemku - polygony z LPIS - polygony krajinných prvků z LPIS - polygony stávajících ploch v OSM Neříkám, že by to bylo jednoduché, naopak :-). Ostatně to vypadá, že k něčemu podobnému není vůle. Aktualizace dělat jednou za X let a byli bychom vlastně ve stejné situaci - na jedné straně landuse v OSM, na druhé straně sdružené polygony z RUIAN a LPIS. No, asi celé blbost ;-)
  16. jzvc jzvc na tpfree.net #m9960bb
    *"rybník":* landuse": "reservoir"
    Cus, pokud vim, voda je importovana odjinud, takze to bych nejspis vynechal, jinak totiz vznikne ohromny mnoztvi konfliktu. Leda vytvorit nejaky overlay pro porovnani. Mimochodem, ta importovana voda samo neni co se presnosti tyce zadna slava +- desitky metru sem tam ;D. V KM (pokud je) je to daleko presnejsi.
  17. Pavel Machek pavel na ucw.cz #m52fe39
    ahoj!
    Jak by sis to propojení představoval? Mne nenapadá, jak by se to dalo udělat.
    No úplně přesně to nevím :). Napřed bych viděl úvahu, zda jednotlivá políčka (=parcely a LPIS polygony) sdružovat nebo ne. Na tom závisí i strategie aktualizací. Zatím mi přijde nemožné hlídat si podle ref:, zda se něco v LPIS změnilo a na změnu zareagovat. Nevíme, co se může měnit. Určitě druh kultury, možná i geometrie? Je možné, že tam, kde je teď 50 malých políček bude za 3 roky jen jedno velké č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
  18. Pavel Machek pavel na ucw.cz #m4c8691
    Ahoj!
    se možná někdy napojí na stávající landuse. I spojení se stávajícími OSM daty by se dalo udělat. Jen by bylo potřeba vymyslet pravidla, tedy co dělat, když vznikne průnik pole z RUIAN/LPIS s lesem v OSM, zastavěná plocha v RUIAN s polem v OSM atd atd. Co dělat s případy dvojparcel, tedy kdy je jedna parcela se zahradou a uvnitř ní je jiná parcela se zastavěnou plochou, prostě barák uprostřed zahrady.
    No, co by pomohlo -- a co v podstate delam rucne: Pokud je maly prunik zemedelske pudy a lesa, je les nepresne, a je potreba ten prunik z lesa odstranit. Pokud je naly prunik zemedelske pudy a landuse=residential, je residential nepresne, reseni stejne. Pokud je zemedelska puda uprostred landuse=residential, slo by to udelat multipolygon=inner, ale spis radeji rucne opravit. Umi to nekdo snadno naprogramovat?
  19. Marián Kyral mkyral na email.cz #mb73c0d
    Ahoj,
  20. Marián Kyral mkyral na email.cz #macb4d8
    Ahoj, (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
  21. Pavel Kwiecien pavel.kwiecien na seznam.cz #m112a5f
    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 dobře, akorát import je potřeba vždy!!  projet  v JOSM validací, protože tracováním/vstupníma daty vzniká obrovské množství chyb a varování. Na dvě kliknutí se toho dá zbavit. Ještě pro neznalé. Je dobré si v JOSM nastavit třeba tuto WMS vrstvu: http://eagri.cz/public/app/wms/plpis.fcgi?FORMAT=image/gif&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&LAYERS=LPIS_FB_KUL&STYLES=&SRS={proj}&WIDTH= {width}&HEIGHT={height}&BBOX={bbox} aby bylo vidět, kde jsou LPIS data. Zdraví Pavel Kwiecien (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
  22. Marián Kyral mkyral na email.cz #m58b18d
    *"rybník":* landuse": "reservoir"
    Cus, pokud vim, voda je importovana odjinud, takze to bych nejspis vynechal, jinak totiz vznikne ohromny mnoztvi konfliktu. Leda vytvorit nejaky overlay pro porovnani.
    No u importu bych to asi taky vynechal. Ale Tracer by to mohl umět :-D Ale zatím jsem tady v okolí nic takového nepotkal.
    Mimochodem, ta importovana voda samo neni co se presnosti tyce zadna slava +- desitky metru sem tam ;D. V KM (pokud je) je to daleko presnejsi.
    No asi podobně jako lesy ne? Pokud je k dispozici přesnější zdroj, byla by škoda jej nevyužít. Marián
  23. Pavel Machek pavel na ucw.cz #m9678f2
    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. Pavel
  24. Pavel Machek pavel na ucw.cz #m515974
    Ahoj!
    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
    Pekne :-).
    Pokud by spojování nebylo automatické, tak nemá smysl se tím zabývat. Tracer funguje dobře, akorát import je potřeba vždy!!  projet  v JOSM validací, protože tracováním/vstupníma daty vzniká obrovské množství chyb a varování. Na dvě kliknutí se toho dá zbavit.
    Budeme nejak udrzovat http://wiki.openstreetmap.org/wiki/LPIS aby byl prehled, ktera katastralni uzemi jsou hotova? Pavel
  25. Pavel Machek pavel na ucw.cz #m57af5b
    Ahoj!
    *"rybník":* landuse": "reservoir"
    Cus, pokud vim, voda je importovana odjinud, takze to bych nejspis vynechal, jinak totiz vznikne ohromny mnoztvi konfliktu. Leda vytvorit nejaky overlay pro porovnani.
    No u importu bych to asi taky vynechal. Ale Tracer by to mohl umět :-D Ale zatím jsem tady v okolí nic takového nepotkal.
    Mimochodem, ta importovana voda samo neni co se presnosti tyce zadna slava +- desitky metru sem tam ;D. V KM (pokud je) je to daleko presnejsi.
    No asi podobně jako lesy ne? Pokud je k dispozici přesnější zdroj, byla by škoda jej nevyužít.
    Lesy byly presnejsi, ale delala se na nich generalizace, takze nejakeho vylepseni by slo dosahnout jejich znovunatazenim bez generalizace. Jestli to resi vsechny problemy by se ale muselo zkusit... (A jo, libilo by se mi v lesech mit informaci listnaty/jehlicnaty. V tech puvodnich datech byla). Pavel
  26. Marián Kyral mkyral na email.cz #m8a5647
    Ahoj!
    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
    Pekne :-).
    Jo jo, já si tady zatím klikám jen nanečisto a on to tady někdo rozjel ve velkém :-D
    Pokud by spojování nebylo automatické, tak nemá smysl se tím zabývat. Tracer funguje dobře, akorát import je potřeba vždy!! projet v JOSM validací, protože tracováním/vstupníma daty vzniká obrovské množství chyb a varování. Na dvě kliknutí se toho dá zbavit.
    Budeme nejak udrzovat http://wiki.openstreetmap.org/wiki/LPIS aby byl prehled, ktera katastralni uzemi jsou hotova?
    No ta wiki by v prvé řadě potřebovala doplnit - mapování, popis toho skriptu, popis plánovaných aktualizací a tak dále ;-) Marián
  27. Marián Kyral mkyral na email.cz #mc66212
    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? Marián
  28. Martin Švec - OSM osm na maatts.cz #m18362a
    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
  29. Pavel Kwiecien pavel.kwiecien na seznam.cz #mc88461
    Ahoj, prozatím jsem hlavní část tracování na "svém" území ukončil. Jde o území, které dlouhodobě upravuji a má celkem dobře zpracované různé landuse= residential apod, překryvy tedy nějaké jsou, ale jsou minimální. Pokud jse o tabulku se seznamem udělaných katastrálních území, v případě potřeby ji zpětně doplním. Jinak lesů je v LPIS pramálo, jde většinou o nějaké školky, rybníky jsem nezaznamenal. Zdraví Pavel Kwiecien
  30. Marián Kyral mkyral na email.cz #m94dbc2
    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é.
    No slučoval bych body pouze u polygonů s tagem landuse. Tedy elektrické vedení se bude ignorovat (stejně jako u budov).
    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.
    Pokud jde o slučování celých polygonů, tam souhlasím s Pavlem, raději zatím neslučovat.
    OK,
    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í.
    Jak na to dojde, všechno osekám, úplně všechno :-D Ne vážně, myslíš, že u ručně naklikaných residental a farmyard je lepší přesnost? Podle mne se to kliká od oka, podle bingu a KM. Takže pokud na bingu vidím, že ta je pole, lpis tam taky má pole tak mi přijde logické to oseknout. S největší pravděpodobností to bude správně. Něco jiného je celé pole uvnitř residental. Tam se nic sekat nebude a bude na uživateli, aby si z toho udělal multipolygon (pokud chce). Marián
  31. Martin Švec - OSM osm na maatts.cz #m1cb6f4
    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
  32. Marián Kyral mkyral na email.cz #mc7d38d
  33. Jan Dudík jan.dudik na gmail.com #mce92d4
    Dělám něco špatně? stáhl jsem si tracer z [1], k němu v JOSM dva vyžadované doplňky, na pozadí si zapnul požadovanou vrstvu wms abych vidě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 mačkáním T dosáhnu jediné změny, že se ani po kliku na budovu nic nestane [1] http://www.kyralovi.cz/tmp/josm/beta/lpis/Tracer.jar JAnD
  34. Michal Pustějovský Michal.Pustejovsky na seznam.cz #m3b24d8
    Máš spuštěný tracer server?
  35. Martin Švec - OSM osm na maatts.cz #m8a05df
    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
  36. Jan Dudík jan.dudik na gmail.com #mfd4384
    Díky, bylo to tím nastavením. Ale narazil jsem na plochy v LPIS, kterým tracer přiřadí pouze ref a source, žádné landuse. asi 6 jich je na relativně malé ploše v katastru Plav: http://www.openstreetmap.org/#map=16/48.9090/14.4976 např. http://www.openstreetmap.org/way/297894310 je to záměr nbeo chyba? --- Ing. Jan Dudík projekce dopravních staveb tel. 777082195
  37. Marián Kyral mkyral na email.cz #m3cb527
    Ahoj, bohužel nemám kompletní seznam toho, co můžu lpis očekávat. Takže někdy to nezafunguje a je potřeba mi to nahlásit a já to doplním do mapování. Nicméně, u tého konkrétní cesty se mi doplní "orná půda". Takže tím to není. Ale něco podobného jsem už viděl. Řešil jsem to s Honzou Mladým. Do odpovědi z WMS se nějakým záhadným způsobem dostaly podivné znaky. Vždy se vecpou na stejné místo a to, jestli se něco natrasuje správně nebo ne záleží jen na velikosti trasované plochy. Při určitém počtu uzlů se ty podivné znaky třefí právě do pole s kulturou a tracer pak nic nenajde. Ale proč se to děje netuším. U mně se tento problém nevyskytuje. A Honza je teď na dovolené, takže další zkoumání momentálně neprobíhá. Marián
  38. Jiří Parkan jparkan na gmail.com #m9ff9e0
    Ahoj, také jsem narážel na nějaké plochy kterým tracer nepřiřadil typ plochy. Na Třebíčsku to byla tak jedna z dvaceti. Včera jsem mapoval kousek okolo Plzně-Božkova a tam byly bez typu plochy naprosto všechny polygony. Parkis 2014-08-15 16:08 GMT+02:00 Marián Kyral <mkyral na email.cz>:
  39. Marián Kyral mkyral na email.cz #mac4315
  40. Jiří Parkan jparkan na gmail.com #mf0e5ee
    Ahoj, výstup url přikládám (7883723.xml), letmým pohledem se mi zdá ok. Pár příkladů lpis ID která nefungovala: 8570042, 9403951, 8570047 Jsou to políčka v téhle oblasti: http://osm.org/go/0JbF878yo--Přikládám také uložené xml jednoho z nich (8570042.xml), v prohlížeči se taky zdá v pořádku. Při trasování proběhne v konzoli JOSM chyba parsování xml a je tam vidět pomršená diakritika, viz obrázky. Možná je to ale jen chyba zobrazení v konzoli, netuším. Systém je Win7 home CZ. Parkis 2014-08-16 18:42 GMT+02:00 Marián Kyral <mkyral na email.cz>:
  41. Marián Kyral mkyral na email.cz #m31f64d
    Díky. Tak to je hodně divné. Vypadá to normálně a stejně se tam něco pokazí. Diakritika problém nebude. To by se přece nenatrasovalo nic. Ale někdy orná půda projde, jindy ne. :-( Marián
    Ahoj, výstup url přikládám (7883723.xml), letmým pohledem se mi zdá ok. Pár příkladů lpis ID která nefungovala: 8570042, 9403951, 8570047 Jsou to políčka v téhle oblasti: http://osm.org/go/0JbF878yo--Přikládám také uložené xml jednoho z nich (8570042.xml), v prohlížeči se taky zdá v pořádku. Při trasování proběhne v konzoli JOSM chyba parsování xml a je tam vidět pomršená diakritika, viz obrázky. Možná je to ale jen chyba zobrazení v konzoli, netuším. Systém je Win7 home CZ. Parkis 2014-08-16 18:42 GMT+02:00 Marián Kyral <mkyral na email.cz>:
    Ahoj, pošli mi prosím konkrétní body. Mám takové podezření, že to je nějaký problém s windows. Protože na linuxu to je bez problémů. Můžete mi prosím všichni zkusit v prohlížeči toto url:
    http://eagri.cz/public/app/wms/plpis_wfs.fcgi?VERSION=1.1.0&SERVICE=WFS&REQUEST=GetFeature&TYPENAME=LPIS_FB4&&featureID=LPIS_FB4.7883723&SRSNAME=EPSG:102067
    A případně mi poslat výstup? Mělo by to vypadat podobně jako na
    obrázku.
    Pokud atribut ms:kultura nevypadá takto: *<ms:kultura>orná půda</ms:kultura>* Tak je to špatně a musíme zjistit, kde je problém.
    V
    traceru není, ten už dostane špatná data. (je to ten příklad od Honzy níže, kdyby to chtěl někdo zkoumat). Marián Ahoj, také jsem narážel na nějaké plochy kterým tracer nepřiřadil typ
    plochy. Na
    Třebíčsku to byla tak jedna z dvaceti. Včera jsem mapoval kousek okolo Plzně-Božkova a tam byly bez typu
    plochy
    naprosto všechny polygony. Parkis 2014-08-15 16:08 GMT+02:00 Marián Kyral <mkyral na email.cz>:
    Ahoj, bohužel nemám kompletní seznam toho, co můžu lpis očekávat. Takže
    někdy
    to nezafunguje a je potřeba mi to nahlásit a já to doplním do
    mapování.
    Nicméně, u tého konkrétní cesty se mi doplní "orná půda". Takže tím
    to
    není. Ale něco podobného jsem už viděl. Řešil jsem to s Honzou
    Mladým. Do
    odpovědi z WMS se nějakým záhadným způsobem dostaly podivné znaky.
    Vždy se
    vecpou na stejné místo a to, jestli se něco natrasuje správně nebo
    ne
    záleží jen na velikosti trasované plochy. Při určitém počtu uzlů se
    ty
    podivné znaky třefí právě do pole s kulturou a tracer pak nic
    nenajde.
    Ale proč se to děje netuším. U mně se tento problém nevyskytuje. A
    Honza
    je teď na dovolené, takže další zkoumání momentálně neprobíhá. Marián Díky, bylo to tím nastavením. Ale narazil jsem na plochy v LPIS, kterým tracer přiřadí pouze ref a source, žádné landuse. asi 6 jich je na relativně malé ploše v katastru Plav: http://www.openstreetmap.org/#map=16/48.9090/14.4976 např. http://www.openstreetmap.org/way/297894310 je to záměr nbeo chyba? --- Ing. Jan Dudík projekce dopravních staveb tel. 777082195 Dne 11. srpna 2014 16:01 Martin Švec - OSM <osm na maatts.cz>
    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) Mačkat T a sledovat jak se mění kurzor myši, R = budovy z
    RUIANu,
    LP =
    půda z LPISu. Martin Máš spuštěný tracer server? Dělám něco špatně? stáhl jsem si tracer z [1], k němu v JOSM dva vyžadované doplňky,
    na
    pozadí si zapnul požadovanou vrstvu wms abych vidě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 mačkáním T dosáhnu jediné změ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.kwiecien na seznam.cz>
    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 dobře, akorát import je potřeba vždy!! projet v JOSM
    validací,
    protože tracováním/vstupníma daty vzniká obrovské množství chyb a varování. Na dvě kliknutí se toho dá zbavit. Ještě pro neznalé. Je dobré si v JOSM nastavit třeba tuto WMS
    vrstvu: http://eagri.cz/public/app/wms/plpis.fcgi?FORMAT=image/gif&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&LAYERS=LPIS_FB_KUL&STYLES=&SRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox}
    aby bylo vidět, kde jsou LPIS data. Zdraví Pavel Kwiecien Ahoj, ahoj!
    Jak by sis to propojení představoval? Mne nenapadá, jak by se
    to
    dalo
    udělat.
    No úplně přesně to nevím :). Napřed bych viděl úvahu, zda jednotlivá políčka (=parcely a LPIS polygony) sdružovat nebo ne. Na tom závisí i strategie aktualizací. Zatím
    mi
    přijde
    nemožné hlídat si podle ref:, zda se něco v LPIS změnilo a na
    změnu
    zareagovat. Nevíme, co se může měnit. Určitě druh kultury, možná
    i
    geometrie? Je možné, že tam, kde je teď 50 malých políček bude za 3 roky
    jen
    jedno
    velké č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: Slučovat nebo neslučovat polygony se
    stejným
    landuse vedle sebe? Třeba tady:
    http://www.openstreetmap.org/#map=17/49.66388/18.38023 by
    se
    sloučení hodilo. Ale když jsem experimentálně pár polygonů
    označil a
    nechal sloučit, tak z toho vylezl nějaký paskvil, protože ač jsou ty
    natrasované
    polygony vizuálně vedle sebe, ne vždy na sebe přesně navazují. 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? A pokud se bude slučovat (což bych v tomto konkrétním případě rád
    udělal),
    co udělat s ref? Já bych jej úplně vyhodil, nechal bych jen
    source=lpis,
    aby bylo jasné, odkud se to vzalo. A chybějící ref by znamenalo, že
    polygon
    vznikl sloučením menších polygonů. Nebo tam dát nějaký speciální
    tag?
    Třeba lpis=merged ? Pokud by ref zůstalo, nutně by to vedlo k něčemu takovému: ref=123;2231;2231;22455;875;646 Bylo by to k něčemu? Marián
    Talk-cz mailing
    ------------------------------------------------------------------------
    -- Odesláno z mého telefonu s Androidem pomocí pošty K-9 Mail. Omluvte prosím moji stručnost.
  42. Marián Kyral mkyral na email.cz #m506ec1
    Tak jsem ještě koukal na tu exception. Můžeš zkusit přidat tento parametr? -Dfile.encoding=UTF8 Možná to bude ono. Marián
    Ahoj, výstup url přikládám (7883723.xml), letmým pohledem se mi zdá ok. Pár příkladů lpis ID která nefungovala: 8570042, 9403951, 8570047 Jsou to políčka v téhle oblasti: http://osm.org/go/0JbF878yo--Přikládám také uložené xml jednoho z nich (8570042.xml), v prohlížeči se taky zdá v pořádku. Při trasování proběhne v konzoli JOSM chyba parsování xml a je tam vidět pomršená diakritika, viz obrázky. Možná je to ale jen chyba zobrazení v konzoli, netuším. Systém je Win7 home CZ. Parkis 2014-08-16 18:42 GMT+02:00 Marián Kyral <mkyral na email.cz>:
    Ahoj, pošli mi prosím konkrétní body. Mám takové podezření, že to je nějaký problém s windows. Protože na linuxu to je bez problémů. Můžete mi prosím všichni zkusit v prohlížeči toto url:
    http://eagri.cz/public/app/wms/plpis_wfs.fcgi?VERSION=1.1.0&SERVICE=WFS&REQUEST=GetFeature&TYPENAME=LPIS_FB4&&featureID=LPIS_FB4.7883723&SRSNAME=EPSG:102067
    A případně mi poslat výstup? Mělo by to vypadat podobně jako na
    obrázku.
    Pokud atribut ms:kultura nevypadá takto: *<ms:kultura>orná půda</ms:kultura>* Tak je to špatně a musíme zjistit, kde je problém.
    V
    traceru není, ten už dostane špatná data. (je to ten příklad od Honzy níže, kdyby to chtěl někdo zkoumat). Marián Ahoj, také jsem narážel na nějaké plochy kterým tracer nepřiřadil typ
    plochy. Na
    Třebíčsku to byla tak jedna z dvaceti. Včera jsem mapoval kousek okolo Plzně-Božkova a tam byly bez typu
    plochy
    naprosto všechny polygony. Parkis 2014-08-15 16:08 GMT+02:00 Marián Kyral <mkyral na email.cz>:
    Ahoj, bohužel nemám kompletní seznam toho, co můžu lpis očekávat. Takže
    někdy
    to nezafunguje a je potřeba mi to nahlásit a já to doplním do
    mapování.
    Nicméně, u tého konkrétní cesty se mi doplní "orná půda". Takže tím
    to
    není. Ale něco podobného jsem už viděl. Řešil jsem to s Honzou
    Mladým. Do
    odpovědi z WMS se nějakým záhadným způsobem dostaly podivné znaky.
    Vždy se
    vecpou na stejné místo a to, jestli se něco natrasuje správně nebo
    ne
    záleží jen na velikosti trasované plochy. Při určitém počtu uzlů se
    ty
    podivné znaky třefí právě do pole s kulturou a tracer pak nic
    nenajde.
    Ale proč se to děje netuším. U mně se tento problém nevyskytuje. A
    Honza
    je teď na dovolené, takže další zkoumání momentálně neprobíhá. Marián Díky, bylo to tím nastavením. Ale narazil jsem na plochy v LPIS, kterým tracer přiřadí pouze ref a source, žádné landuse. asi 6 jich je na relativně malé ploše v katastru Plav: http://www.openstreetmap.org/#map=16/48.9090/14.4976 např. http://www.openstreetmap.org/way/297894310 je to záměr nbeo chyba? --- Ing. Jan Dudík projekce dopravních staveb tel. 777082195 Dne 11. srpna 2014 16:01 Martin Švec - OSM <osm na maatts.cz>
    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) Mačkat T a sledovat jak se mění kurzor myši, R = budovy z
    RUIANu,
    LP =
    půda z LPISu. Martin Máš spuštěný tracer server? Dělám něco špatně? stáhl jsem si tracer z [1], k němu v JOSM dva vyžadované doplňky,
    na
    pozadí si zapnul požadovanou vrstvu wms abych vidě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 mačkáním T dosáhnu jediné změ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.kwiecien na seznam.cz>
    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 dobře, akorát import je potřeba vždy!! projet v JOSM
    validací,
    protože tracováním/vstupníma daty vzniká obrovské množství chyb a varování. Na dvě kliknutí se toho dá zbavit. Ještě pro neznalé. Je dobré si v JOSM nastavit třeba tuto WMS
    vrstvu: http://eagri.cz/public/app/wms/plpis.fcgi?FORMAT=image/gif&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&LAYERS=LPIS_FB_KUL&STYLES=&SRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox}
    aby bylo vidět, kde jsou LPIS data. Zdraví Pavel Kwiecien Ahoj, ahoj!
    Jak by sis to propojení představoval? Mne nenapadá, jak by se
    to
    dalo
    udělat.
    No úplně přesně to nevím :). Napřed bych viděl úvahu, zda jednotlivá políčka (=parcely a LPIS polygony) sdružovat nebo ne. Na tom závisí i strategie aktualizací. Zatím
    mi
    přijde
    nemožné hlídat si podle ref:, zda se něco v LPIS změnilo a na
    změnu
    zareagovat. Nevíme, co se může měnit. Určitě druh kultury, možná
    i
    geometrie? Je možné, že tam, kde je teď 50 malých políček bude za 3 roky
    jen
    jedno
    velké č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: Slučovat nebo neslučovat polygony se
    stejným
    landuse vedle sebe? Třeba tady:
    http://www.openstreetmap.org/#map=17/49.66388/18.38023 by
    se
    sloučení hodilo. Ale když jsem experimentálně pár polygonů
    označil a
    nechal sloučit, tak z toho vylezl nějaký paskvil, protože ač jsou ty
    natrasované
    polygony vizuálně vedle sebe, ne vždy na sebe přesně navazují. 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? A pokud se bude slučovat (což bych v tomto konkrétním případě rád
    udělal),
    co udělat s ref? Já bych jej úplně vyhodil, nechal bych jen
    source=lpis,
    aby bylo jasné, odkud se to vzalo. A chybějící ref by znamenalo, že
    polygon
    vznikl sloučením menších polygonů. Nebo tam dát nějaký speciální
    tag?
    Třeba lpis=merged ? Pokud by ref zůstalo, nutně by to vedlo k něčemu takovému: ref=123;2231;2231;22455;875;646 Bylo by to k něčemu? Marián
    Talk-cz mailing
    ------------------------------------------------------------------------
    -- Odesláno z mého telefonu s Androidem pomocí pošty K-9 Mail. Omluvte prosím moji stručnost.
  43. Jiří Parkan jparkan na gmail.com #m1d174b
    Bingo! s tímhle parametrem už to funguje, přidám si ho do spouštěcí dávky. Díky! 2014-08-16 21:43 GMT+02:00 Marián Kyral <mkyral na email.cz>:
  44. Petr Schönmann pschonmann na gmail.com #mfbcbd1
    Ahoj, výstup url přikládám (7883723.xml), letmým pohledem se mi zdá ok. Pár příkladů lpis ID která nefungovala: 8570042, 9403951, 8570047 Jsou to políčka v téhle oblasti: http://osm.org/go/0JbF878yo--Přikládám také uložené xml jednoho z nich (8570042.xml), v prohlížeči se taky zdá v pořádku. Při trasování proběhne v konzoli JOSM chyba parsování xml a je tam vidět pomršená diakritika, viz obrázky. Možná je to ale jen chyba zobrazení v konzoli, netuším. Systém je Win7 home CZ. Parkis 2014-08-16 18:42 GMT+02:00 Marián Kyral <mkyral na email.cz <mailto:mkyral na email.cz>>: Ahoj, pošli mi prosím konkrétní body. Mám takové podezření, že to je nějaký problém s windows. Protože na linuxu to je bez problémů. Můžete mi prosím všichni zkusit v prohlížeči toto url: http://eagri.cz/public/app/wms/plpis_wfs.fcgi?VERSION=1.1.0&SERVICE=WFS&REQUEST=GetFeature&TYPENAME=LPIS_FB4&&featureID=LPIS_FB4.7883723&SRSNAME=EPSG:102067 A případně mi poslat výstup? Mělo by to vypadat podobně jako na obrázku. Pokud atribut ms:kultura nevypadá takto: *<ms:kultura>orná půda</ms:kultura>* Tak je to špatně a musíme zjistit, kde je problém. V traceru není, ten už dostane špatná data. (je to ten příklad od Honzy níže, kdyby to chtěl někdo zkoumat). Marián
    Ahoj, také jsem narážel na nějaké plochy kterým tracer nepřiřadil typ plochy. Na Třebíčsku to byla tak jedna z dvaceti. Včera jsem mapoval kousek okolo Plzně-Božkova a tam byly bez typu plochy naprosto všechny polygony. Parkis 2014-08-15 16:08 GMT+02:00 Marián Kyral <mkyral na email.cz <mailto:mkyral na email.cz>>: Ahoj, bohužel nemám kompletní seznam toho, co můžu lpis očekávat. Takže někdy to nezafunguje a je potřeba mi to nahlásit a já to doplním do mapování. Nicméně, u tého konkrétní cesty se mi doplní "orná půda". Takže tím to není. Ale něco podobného jsem už viděl. Řešil jsem to s Honzou Mladým. Do odpovědi z WMS se nějakým záhadným způsobem dostaly podivné znaky. Vždy se vecpou na stejné místo a to, jestli se něco natrasuje správně nebo ne záleží jen na velikosti trasované plochy. Při určitém počtu uzlů se ty podivné znaky třefí právě do pole s kulturou a tracer pak nic nenajde. Ale proč se to děje netuším. U mně se tento problém nevyskytuje. A Honza je teď na dovolené, takže další zkoumání momentálně neprobíhá. Marián Díky, bylo to tím nastavením. Ale narazil jsem na plochy v LPIS, kterým tracer přiřadí pouze ref a source, žádné landuse. asi 6 jich je na relativně malé ploše v katastru Plav: http://www.openstreetmap.org/#map=16/48.9090/14.4976 např. http://www.openstreetmap.org/way/297894310 <tel:297894310> je to záměr nbeo chyba? --- Ing. Jan Dudík projekce dopravních staveb tel. 777082195 <tel:777082195> Dne 11. srpna 2014 16:01 Martin Švec - OSM <osm na maatts.cz
    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) Mačkat T a sledovat jak se mění kurzor myši, R =
    budovy z RUIANu, LP =
    půda z LPISu. Martin Máš spuštěný tracer server? ---------- Původní zpráva ---------- Od: Jan Dudík <jan.dudik na gmail.com
    <mailto:jan.dudik na gmail.com>>
    Komu: OpenStreetMap Czech Republic Datum: 11. 8. 2014 14:45:35 Předmět: Re: [Talk-cz] Tracer - pLPIS Dělám něco špatně? stáhl jsem si tracer z [1], k němu v JOSM dva
    vyžadované doplňky, na
    pozadí si zapnul požadovanou vrstvu wms abych vidě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 mačkáním T dosáhnu jediné změ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.kwiecien na seznam.cz
    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 dobře, akorát import je potřeba vždy!! projet
    v JOSM validací,
    protože tracováním/vstupníma daty vzniká obrovské
    množství chyb a
    varování. Na dvě kliknutí se toho dá zbavit. Ještě pro neznalé. Je dobré si v JOSM nastavit třeba
    tuto WMS vrstvu: http://eagri.cz/public/app/wms/plpis.fcgi?FORMAT=image/gif&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&LAYERS=LPIS_FB_KUL&STYLES=&SRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox} <http://eagri.cz/public/app/wms/plpis.fcgi?FORMAT=image/gif&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&LAYERS=LPIS_FB_KUL&STYLES=&SRS=%7Bproj%7D&WIDTH=%7Bwidth%7D&HEIGHT=%7Bheight%7D&BBOX=%7Bbbox%7D> >>
    aby bylo vidět, kde jsou LPIS data. Zdraví Pavel Kwiecien ---------- Původní zpráva ---------- Od: Marián Kyral <mkyral na email.cz
    <mailto:mkyral na email.cz>>
    Komu: OpenStreetMap Czech Republic Datum: 8. 8. 2014 9:08:35 Předmět: Re: [Talk-cz] Tracer - pLPIS Ahoj, ---------- Původní zpráva ---------- Od: Pavel Machek <pavel na ucw.cz <mailto:pavel na ucw.cz>> >> Komu: OpenStreetMap Czech Republic Datum: 5. 8. 2014 23:19:28 Předmět: Re: [Talk-cz] Tracer - pLPIS ahoj!
    Jak by sis to propojení představoval? Mne nenapadá,
    jak by se to dalo
    udělat.
    No úplně přesně to nevím :). Napřed bych viděl úvahu, zda jednotlivá políčka
    (=parcely a LPIS
    polygony) sdružovat nebo ne. Na tom závisí i strategie
    aktualizací. Zatím mi přijde
    nemožné hlídat si podle ref:, zda se něco v LPIS
    změnilo a na změnu
    zareagovat. Nevíme, co se může měnit. Určitě druh
    kultury, možná i
    geometrie? Je možné, že tam, kde je teď 50 malých políček bude
    za 3 roky jen jedno
    velké č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: Slučovat nebo neslučovat
    polygony se stejným
    landuse vedle sebe? Třeba tady:
    http://www.openstreetmap.org/#map=17/49.66388/18.38023 by se
    sloučení hodilo. Ale když jsem experimentálně pár
    polygonů označil a
    nechal sloučit, tak z toho vylezl nějaký paskvil, protože ač
    jsou ty natrasované
    polygony vizuálně vedle sebe, ne vždy na sebe přesně
    navazují.
    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? A pokud se bude slučovat (což bych v tomto konkrétním
    případě rád udělal),
    co udělat s ref? Já bych jej úplně vyhodil, nechal
    bych jen source=lpis,
    aby bylo jasné, odkud se to vzalo. A chybějící ref by
    znamenalo, že polygon
    vznikl sloučením menších polygonů. Nebo tam dát nějaký
    speciální tag?
    Třeba lpis=merged ? Pokud by ref zůstalo, nutně by to vedlo k něčemu takovému: ref=123;2231;2231;22455;875;646 Bylo by to k něčemu? Marián -- (english) http://www.livejournal.com/~pavelmachek
    <http://www.livejournal.com/%7Epavelmachek>
    (cesky, pictures)
    http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html <http://atrey.karlin.mff.cuni.cz/%7Epavel/picture/horses/blog.html> >>
    _______________________________________________ _______________________________________________ _______________________________________________
    _______________________________________________ _______________________________________________ _______________________________________________
    Nemáš Javu 8 ? Mě se děje stejná věc. Na linuxu s j7 ok
  45. Marián Kyral mkyral na email.cz #m8400e0
    Bingo! s tímhle parametrem uz( to funguje, pr(idám si ho do spous(te(cí dávky. Díky!
    Tak to je fajn. Kouknu, co je tr(eba nastavit, aby to fungovalo samo. C(love(k tak ne(jak pr(edpokládal z(e kdyz( má soubor v hlavic(ce UTF-8 kódování, z(e to bude fungovat. Bohuz(el na windows to neplatí. Uz( by si v Microsoftu mohli uve(domit, z(e se pís(e rok 2014 a uz( nejakou dobu je UTF-8 standard ;-) Marián
  46. Marián Kyral mkyral na email.cz #mbc9fb4
    Nemás( Javu 8 ? Me( se de(je stejná ve(c. Na linuxu s j7 ok
    Viz http://stackoverflow.com/a/25044652 Marián
  47. Petr Schönmann pschonmann na gmail.com #mb691b4
    Posílal jsem ti Mariáne report https://github.com/mkyral/josm-tracer/issues/5
  48. Marián Kyral mkyral na email.cz #m1bc633
    Jo, on je trochu problém, že se mi ty bugreporty z gitubu namíchají do talk-cz a já si ani nevšimnu, že to nevede na konferenci :-D Opravu už mám, ale momentálně mám Tracer rozvrtaný, takže nechci vydat novou verzi dříve, než to dodělám. Marián
Napsat odpověď e-mailem… Odpovědět

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