Administrativni hranice z RUIAN

36 zpráv
Zpět na přehled

Administrativni hranice z RUIAN

36 zpráv PLMMJHMP 9 účastníků 31 min čtení
  1. "Petr Morávek [Xificurk]" petr na pada.cz #m0cc549
    Ahoj, spichnul jsem programek na porovnani hranic, co mame nyni v OSM, s hranicemi v RUIAN. Překvapením je, že u zhruba 1500 (10%) KÚ se průběh hranic liší o 100m a více. Takže jsem spíchnul skript, který dokáže automaticky hranice opravit (nahradit) podle dat v RUIAN, malý test [1]. Co to (ne)umí: - opravuje hranice po jednotlivých KÚ. - nešahá na KÚ, která jsou na hranici ČR. - nešahá na KÚ, u kterých se změnily sousedi (např. RUIAN říká, že hranice KÚ X sousedí s KÚ A,B,C, ale v OSM máme, že sousedí s A,B,C,D). - vytvoří nové body a cesty podle RUIAN, updatne relace hranic a na závěr se pokusí smazat staré body a cesty. Než to pustím nějak ve větším chtěl jsem to trochu prodiskutovat, jestli takhle ano, příp. co změnit. Především mě zajímá jaký máte názor na zjednodušení geometrie importovaných cest (momentálně se žádné neprovádí)? Zdraví, Petr Morávek aka Xificurk [1] http://www.openstreetmap.org/browse/relation/426320 http://www.openstreetmap.org/browse/changeset/12878890 http://www.openstreetmap.org/browse/changeset/12878888
  2. Miroslav Šulc fordfrog na fordfrog.com #m317b99
    no, zní to pěkně :-) do hranic ale nevidím, tak se k tomu radši nebudu vyjadřovat. nicméně sem se chtěl zeptat, jestli si tu rúian databázi aktulizuješ a jestli ti to taky začalo shazovat postgis od určité verze updatu. já na tom v postatě stojím, nejsem schopný databázi aktualizovat. ff
  3. "Petr Morávek [Xificurk]" petr na pada.cz #m240375
    no, zní to pěkně :-) do hranic ale nevidím, tak se k tomu radši nebudu vyjadřovat. nicméně sem se chtěl zeptat, jestli si tu rúian databázi aktulizuješ a jestli ti to taky začalo shazovat postgis od určité verze updatu. já na tom v postatě stojím, nejsem schopný databázi aktualizovat. ff
    Neaktualizuju, na souborech z konce července to začlo padat (kompletně celá databáze). Ale zatím mě to moc netrápilo - je celkem jedno na jakých datech testuju skripty. Petr
  4. LM_1 flukas.robot+osm na gmail.com #me05fd9
    Dobrý nápad. Geometrii bych určitě nezjednodušoval, to je celkem zbytečná nepřesnost. Staré uzly a cesty bych mazal jen pokud nemají kromě hranice žádný jiný tag. S těmi co mají bych možná vůbec nehýbal automaticky (hranice vedoucí středem řeky apod.) Lukáš Matějka (LM_1)
  5. "Petr Morávek [Xificurk]" petr na pada.cz #mcc330e
    Staré uzly a cesty bych mazal jen pokud nemají kromě hranice žádný jiný tag. S těmi co mají bych možná vůbec nehýbal automaticky (hranice vedoucí středem řeky apod.)
    Dobrá připomínka, tuhle kontrolu přidám... Ale chování bych viděl spíš takové, že se ze staré cesty odstraní tagy boundary a admin_level, a uploadne se nová cesta. Jinak by se mohlo stát, že někde náhodně přidaný tag zablokuje update. Nelze spoléhat na to, že pokud někdy vedla hranice středem potoka, tak takhle povede vždycky... navíc toky potoků a řek se mění, ale vymezení adm. hranic je dáno "přesně" zaměřenými body. Zdraví, Petr Morávek aka Xificurk
  6. LM_1 flukas.robot+osm na gmail.com #m47e182
    To je otázka, která mě už delší zajímá, ale zatím jsem nenašel uspokojivou odpověď - Kde jsou definované hranice (od katastrálního území po státní)? Je opravdu hranice dána definičně řadou souřadnic nebo spíš popsána pomocí fyzických objektů (řeka, hřeben, silnice, hraniční kámen...) a ty souřadnice jsou jen odvozeným vyjádřením pro praktické účely? LM
  7. hanoj ehanoj na gmail.com #m1945fe
    Geometrii bych určitě nezjednodušoval, to je celkem zbytečná nepřesnost.
    *** uplne bych se tomu nebranil, presna hranice ma smysl pokud pracuji s katastralni mapou (aby 1 parcela nebyla ve 2 k.u.). Chyba 1 metr je v nasich potrebach dostacujici.
    Staré uzly a cesty bych mazal jen pokud nemají kromě hranice žádný jiný tag. S těmi co mají bych možná vůbec nehýbal automaticky (hranice vedoucí středem řeky apod.)
    *** to doufam nemaji, hranice byly vytvoreny jako balik autonomnich entit tj. nezavisly na fyzickych prvcich mapy. A pokud se tak v editacich useru stalo, mela by se data opet stat autonomni. ha hanoj
  8. "Petr Morávek [Xificurk]" petr na pada.cz #mfe4157
    Geometrii bych určitě nezjednodušoval, to je celkem zbytečná nepřesnost.
    *** uplne bych se tomu nebranil, presna hranice ma smysl pokud pracuji s katastralni mapou (aby 1 parcela nebyla ve 2 k.u.). Chyba 1 metr je v nasich potrebach dostacujici.
    Já si zas říkám, že ty nody se dají případně zrecyklovat i na další věci (vzhledem k tomu, že vedou po hranicích parcel). Jestliže vede hranice přesně se zdí domu, tak by zjednodušení mohlo způsobit, že najednou bude roh domu na jedné straně zbytek na druhé straně hranice. V podstatě jediný důvod pro zjednodušení je redukce většího množství nodů... což mi nepřijde jako příliš silný argument.
    Staré uzly a cesty bych mazal jen pokud nemají kromě hranice žádný jiný tag. S těmi co mají bych možná vůbec nehýbal automaticky (hranice vedoucí středem řeky apod.)
    *** to doufam nemaji, hranice byly vytvoreny jako balik autonomnich entit tj. nezavisly na fyzickych prvcich mapy. A pokud se tak v editacich useru stalo, mela by se data opet stat autonomni.
    Občas bohužel mají... už jsem na to v minulosti při opravách narazil. Zdraví, Petr Morávek aka Xificurk
  9. Martin Kokeš shr3k na typo3-hosting.com #m96b80a
    Jsem stejného názoru. Pracuju s daty z RÚIAN a WSDP ISKN v CouchDB, kde mám uložené přesně transformované souřadnice přes nadgrids=czech a pro výstup v GeoJSON je lehce generalizuju. Když tu ty data jsou, tak proč je nemít přesná. MK
  10. LM_1 flukas.robot+osm na gmail.com #m73019f
    Geometrii bych určitě nezjednodušoval, to je celkem zbytečná nepřesnost.
    *** uplne bych se tomu nebranil, presna hranice ma smysl pokud pracuji s katastralni mapou (aby 1 parcela nebyla ve 2 k.u.). Chyba 1 metr je v nasich potrebach dostacujici.
    To bych netvrdil. Tam, kde jsou přesné katastrální mapy je přesnost mnohem vyšší než v metrech a očekával bych, že se bude spíš zvyšovat.
    Staré uzly a cesty bych mazal jen pokud nemají kromě hranice žádný jiný tag. S těmi co mají bych možná vůbec nehýbal automaticky (hranice vedoucí středem řeky apod.)
    *** to doufam nemaji, hranice byly vytvoreny jako balik autonomnich entit tj. nezavisly na fyzickych prvcich mapy. A pokud se tak v editacich useru stalo, mela by se data opet stat autonomni.
    S tím nesouhlasím. Úplně nezávislou vrstvu dat by si ostatně mohl každý použít přímo ze zdroje. To, že se data spojí - hranice vedoucí plotem nebo zdí domu - je přidaná hodnota. Navíc je tím zajištěno zarovnání. Žádný balík autonomních entit nemá v osm moc co dělat, jak se jednou importuje tak splývá s ostatními daty. Něco jako Co jednou peklo schvátí, to už nikdy nenavrátí. :) LM
  11. Petr Kadlec petr.kadlec na gmail.com #m6feed9
    2012/8/27 LM_1 <flukas.robot+osm na gmail.com>:
    To je otázka, která mě už delší zajímá, ale zatím jsem nenašel uspokojivou odpověď - Kde jsou definované hranice (od katastrálního území po státní)? Je opravdu hranice dána definičně řadou souřadnic nebo spíš popsána pomocí fyzických objektů (řeka, hřeben, silnice, hraniční kámen...) a ty souřadnice jsou jen odvozeným vyjádřením pro praktické účely?
    U státní hranice může být pravda obojí, záleží, jak je přesně hranice definována v příslušných mezinárodních smlouvách, resp. hraničním dokumentárním díle: může to být jak pomocí lomových bodů (potažmo hraničních znaků), tak hraničním vodním tokem, hraniční cestou atp. (viz zákon č. 312/2001 Sb.). Některé části hranice jsou tak nepohyblivé, některé se mohou pohybovat např. přirozenou změnou polohy koryta hraničního vodního toku (viz např. 246/1997 Sb.). -- Petr Kadlec / Mormegil
  12. "Petr Morávek [Xificurk]" petr na pada.cz #mc8b711
    2012/8/27 LM_1 <flukas.robot+osm na gmail.com>:
    To je otázka, která mě už delší zajímá, ale zatím jsem nenašel uspokojivou odpověď - Kde jsou definované hranice (od katastrálního území po státní)? Je opravdu hranice dána definičně řadou souřadnic nebo spíš popsána pomocí fyzických objektů (řeka, hřeben, silnice, hraniční kámen...) a ty souřadnice jsou jen odvozeným vyjádřením pro praktické účely?
    U státní hranice může být pravda obojí, záleží, jak je přesně hranice definována v příslušných mezinárodních smlouvách, resp. hraničním dokumentárním díle: může to být jak pomocí lomových bodů (potažmo hraničních znaků), tak hraničním vodním tokem, hraniční cestou atp. (viz zákon č. 312/2001 Sb.). Některé části hranice jsou tak nepohyblivé, některé se mohou pohybovat např. přirozenou změnou polohy koryta hraničního vodního toku (viz např. 246/1997 Sb.).
    Státní hranice je trochu spešl případ, proto na ni také radši nechci moc šahat. Na mnoha místech příliš nesedí s tím, co je v RUIAN. Třeba německá a rakouská hranice se zdá, že je importovaná z nějakého jejich zdroje, takže by časem bylo dorbé zjistit, jestli je přesnější jejich nebo náš RUIAN (jestli to vůbec lze rozhodnout vzhledem k charakteru definice státních hranic). Ale uvnitř státu máme snad vše rozparcelováno a definováno relativně přesně pomocí polygonů, tak jak to je v RUIAN, tj. nezávisle na tom kudy zrovna vede cesta nebo teče potok. Zdraví, Petr Morávek aka Xificurk
  13. hanoj ehanoj na gmail.com #m81014a
    Staré uzly a cesty bych mazal jen pokud nemají kromě hranice žádný jiný tag. S těmi co mají bych možná vůbec nehýbal automaticky (hranice vedoucí středem řeky apod.)
    *** to doufam nemaji, hranice byly vytvoreny jako balik autonomnich entit tj. nezavisly na fyzickych prvcich mapy. A pokud se tak v editacich useru stalo, mela by se data opet stat autonomni.
    S tím nesouhlasím. Úplně nezávislou vrstvu dat by si ostatně mohl každý použít přímo ze zdroje.
    *** muze, nemusi. Proc by nemohlo byt osm vse v jednom?
    To, že se data spojí - hranice vedoucí plotem nebo zdí domu - je přidaná hodnota. Navíc je tím zajištěno zarovnání.
    *** pridana hodnota to je v datovych modelech, kde existuji striktni topologicka pravidla. V OSM se fakticky nedodrzuji ani ta zakladni. K cemu jsou mi data o jednom fenomenu, ktera nabyvaji ruznych forem, vztahu, tagu, vazeb, relaci, primitiv, pokryti a kvality.
    Žádný balík autonomních entit nemá v osm moc co dělat, jak se jednou importuje tak splývá s ostatními daty.
    *** proc by ne, kdyz neni dalsi zdroj relevantnich informaci, ktere k nemu dodat. ha hanoj
  14. LM_1 flukas.robot+osm na gmail.com #m2ca659
    Staré uzly a cesty bych mazal jen pokud nemají kromě hranice žádný jiný tag. S těmi co mají bych možná vůbec nehýbal automaticky (hranice vedoucí středem řeky apod.)
    *** to doufam nemaji, hranice byly vytvoreny jako balik autonomnich entit tj. nezavisly na fyzickych prvcich mapy. A pokud se tak v editacich useru stalo, mela by se data opet stat autonomni.
    S tím nesouhlasím. Úplně nezávislou vrstvu dat by si ostatně mohl každý použít přímo ze zdroje.
    *** muze, nemusi. Proc by nemohlo byt osm vse v jednom?
    V OSM má být vše v jednom, můj nesohlas směřuje proti existenci chráněných, nedotknutelných "vrstev".
    To, že se data spojí - hranice vedoucí plotem nebo zdí domu - je přidaná hodnota. Navíc je tím zajištěno zarovnání.
    *** pridana hodnota to je v datovych modelech, kde existuji striktni topologicka pravidla. V OSM se fakticky nedodrzuji ani ta zakladni. K cemu jsou mi data o jednom fenomenu, ktera nabyvaji ruznych forem, vztahu, tagu, vazeb, relaci, primitiv, pokryti a kvality.
    Když hledám hranici a v mapě je na stejné cestě jako plot, bude se mi líp hledat v realitě. Spojení s dalšími údaji hranice negativně neovlivní, stejně jsou to relace a o žádných kolizích tagů taky nevím. To, že se něco dělá špatně, je důvod to začít dělat správně a ne dělat špatně i všechno okolo. Nestejnoměrná, ale rostoucí, kvalita je obecnou vlastností OSM, v tom není rozdíl.
    Žádný balík autonomních entit nemá v osm moc co dělat, jak se jednou importuje tak splývá s ostatními daty.
    *** proc by ne, kdyz neni dalsi zdroj relevantnich informaci, ktere k nemu dodat.
    Bavíme se samozřejmě o případech, kdy relevantní informace existují. To, že někde vede hranice samozřejmně neznamená, že na ni naplácám všechno co je v okolí (stylem cesta tvořící silnici je zároveň okrajem lesa). LM
  15. Jakub j na kub.cz #m899e3b
    Staré uzly a cesty bych mazal jen pokud nemají kromě hranice žádný jiný tag. S těmi co mají bych možná vůbec nehýbal automaticky (hranice vedoucí středem řeky apod.)
    *** to doufam nemaji, hranice byly vytvoreny jako balik autonomnich entit tj. nezavisly na fyzickych prvcich mapy. A pokud se tak v editacich useru stalo, mela by se data opet stat autonomni.
    S tím nesouhlasím. Úplně nezávislou vrstvu dat by si ostatně mohl každý použít přímo ze zdroje. To, že se data spojí - hranice vedoucí plotem nebo zdí domu - je přidaná hodnota. Navíc je tím zajištěno zarovnání. Žádný balík autonomních entit nemá v osm moc co dělat, jak se jednou importuje tak splývá s ostatními daty. Něco jako Co jednou peklo schvátí, to už nikdy nenavrátí. :)
    V tomto souhlasím s LM, že pokud spojení dat je přidaná hodnota a tam kde to tak je by se neměly cesty mazat, ale upravovat. Hranice rozhodně autonomní entity nejsou, mohou přece mimo fyzických věcí koincidovat i s jinými "abstraktními" geoinformacemi - jako hranice psč nebo něco takového a pokud z nějaké vyhlášky koincidují tak je obrovská přidaná hodnota, že budou v OSM koincidovat. Navíc i koincidence s objekty jako ploty, zdi, přírodní útvary a podobně je také přidaná hodnota, často i pro upřesnění polohy těchto objektů. Mimochodem jak je to tedy s tou definicí hranic jak se ptal LM? Jsou vždy definované body, nebo jsou někde oficiálně navázány na nějaké fyzické objekty. Jakub
  16. "Petr Morávek [Xificurk]" petr na pada.cz #mcccc50
    V tomto souhlasím s LM, že pokud spojení dat je přidaná hodnota a tam kde to tak je by se neměly cesty mazat, ale upravovat. Hranice rozhodně autonomní entity nejsou, mohou přece mimo fyzických věcí koincidovat i s jinými "abstraktními" geoinformacemi - jako hranice psč nebo něco takového a pokud z nějaké vyhlášky koincidují tak je obrovská přidaná hodnota, že budou v OSM koincidovat. Navíc i koincidence s objekty jako ploty, zdi, přírodní útvary a podobně je také přidaná hodnota, často i pro upřesnění polohy těchto objektů.
    S tím upravováním starých cest to není tak jednoduché. Není úplně jednoduché analyzovat, jaké části hranice se jak změnily, a rozhodnout, jestli se hranice posunula někam jinam, nebo jde jen o nepřesnost určení polohy té staré. Obecně asi takových případů příliš nebude. Upravil jsem skript podle připomínky Lukáše, aby nemazal cesty/nody s jinými tagy, tento konflikt mi hlásí v logu. Přijde mi jednodušší se po aktualizaci na dané místo podívat ručně a případně daný objekt znovu sloučit s hranicí.
    Mimochodem jak je to tedy s tou definicí hranic jak se ptal LM? Jsou vždy definované body, nebo jsou někde oficiálně navázány na nějaké fyzické objekty.
    Pokud vím, tak máme celou republiku rozparcelovanou, polygony parcel jsou na příslušných katastrálních úřadech (resp. v různých registrech jako třeba RUIAN), parcely se skládají do katastrálních území, katastrální území do obcí... Jediný "problém" může být státní hranice. Zdraví, Petr Morávek aka Xificurk
  17. Mike mike na mikecrash.com #m57a4fb
    Co jsem tak vysledoval, tak to máme přesněji než třeba Němci, kteří to importovali z nějakého soukromého mapového zdroje, ne moc přčsného. Ale stejně - onehdá jsem hejbnul kouskem hranice, protože byla očividně mimo a to bylo křiku... Tak hodně štěstí. Mike
  18. Mike mike na mikecrash.com #mf6a36a
    Jenže ono to tak často je, že dům stojí na dvou katastrálních územích. Raději bych to nezačleňoval do jiných prvků, ať se s tím dá v budoucnu lépe manipulovat.
  19. Mike mike na mikecrash.com #m2545d3
    Geometrii bych určitě nezjednodušoval, to je celkem zbytečná nepřesnost.
    *** uplne bych se tomu nebranil, presna hranice ma smysl pokud pracuji s katastralni mapou (aby 1 parcela nebyla ve 2 k.u.). Chyba 1 metr je v nasich potrebach dostacujici.
    To bych netvrdil. Tam, kde jsou přesné katastrální mapy je přesnost mnohem vyšší než v metrech a očekával bych, že se bude spíš zvyšovat.
    Staré uzly a cesty bych mazal jen pokud nemají kromě hranice žádný jiný tag. S těmi co mají bych možná vůbec nehýbal automaticky (hranice vedoucí středem řeky apod.)
    *** to doufam nemaji, hranice byly vytvoreny jako balik autonomnich entit tj. nezavisly na fyzickych prvcich mapy. A pokud se tak v editacich useru stalo, mela by se data opet stat autonomni.
    S tím nesouhlasím. Úplně nezávislou vrstvu dat by si ostatně mohl každý použít přímo ze zdroje. To, že se data spojí - hranice vedoucí plotem nebo zdí domu - je přidaná hodnota. Navíc je tím zajištěno zarovnání. Žádný balík autonomních entit nemá v osm moc co dělat, jak se jednou importuje tak splývá s ostatními daty. Něco jako Co jednou peklo schvátí, to už nikdy nenavrátí. :)
    S tím zase nesouhlasím já. Je naprosto běžné, skoro pravidlem, že plot se postavil podle starého zaměření, podle nového je ale o metr vedle, než vede hranice. Další příklad - u nás se teď má přesouvat potok o cca 3 metry, takže posunu potok a co ta hranice? Tu přece nemůžu posunout...
  20. "Petr Morávek [Xificurk]" petr na pada.cz #md9ef7c
    Jenže ono to tak často je, že dům stojí na dvou katastrálních územích.
    Jenže o tomhle případu jsem já vůbec nepsal. ;-) Zopakuji, co jsem napsal už dříve: JESTLIŽE vede hranice přesně se zdí domu, tak by zjednodušení mohlo způsobit, že najednou bude roh domu na jedné straně a zbytek na druhé straně hranice. A přidám: JESTLIŽE vede hranice skrz dům, tak by zjednodušení mohlo způsobit, že najednou bude celý dům jen na jedné straně hranice. To samé platí o tvé připomínce k plotu z druhého mailu: JESTLIŽE plot vede po hranici, tak je spojení obou objektů naprosto v pořádku a dává dodatečnou informaci. JESTLIŽE vede plot vedle hranice, tak je spojení samozřejmě špatně. Opravdu si myslím, že když už ta přesná data máme, tak bysme je neměli zbytečně "znehodnocovat". Ad zjednodušení geometrií: Dělal jsem ještě nějaké testy na datech RUIANu a zdá se, že pokud provedu zjednodušení (Douglas-Peucker) s přesností na 1cm (což je taky zhruba přesnost s jakou jsou data v OSM uložena), tak počet nodů jde dolu o zhruba 17%. To je myslím celkem slušná redukce bez výrazné ztráty informace. Jen pro úplnost: přesnost 0.1m dává redukci 22%, 1m potom 39%. Zdraví, Petr Morávek
  21. Martin Kokeš shr3k na typo3-hosting.com #m679e02
    Doufám, že to pak po jednoduchém simplify nevypadá jako na třetím obrázku... :-) http://trac.osgeo.org/postgis/wiki/UsersWikiSimplifyPreserveTopology MK
  22. Mike mike na mikecrash.com #m225c28
    -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Vesměs s tebou souhlasím, ale píšu to z toho důvodu, že za rok dojde k aktualizaci dat v CUZK, budou se zase aktualizovat data v OSM a najednou se zjistí, že ten plot opravdu nevede po hranici, že barák opravdu je rozdělen, přestože před tím nebyl a zase se bude řešit, co s tím. Vždyť je to pořád dokola. Současná data jsou také import, který měl být přesný, ale není, prostě věci se mění. Nehledě na to, že si někdo nevšimne, že potok je součástí relace hranice, rozdělí ho, kus tam vloží a už nepřidá do relace a hned je hranice rozbitá, což zase rozbije vyhledávače a různé jiné programy, než si toho někdo/něco všimne. Podle mne administrativní a fyzické objekty se nemají mixovat dohromady z těchto důvodů, přestože to zní lákavě.
    Jenže ono to tak často je, že dům stojí na dvou katastrálních územích.
    Jenže o tomhle případu jsem já vůbec nepsal. ;-) Zopakuji, co jsem napsal už dříve: JESTLIŽE vede hranice přesně se zdí domu, tak by zjednodušení mohlo způsobit, že najednou bude roh domu na jedné straně a zbytek na druhé straně hranice. A přidám: JESTLIŽE vede hranice skrz dům, tak by zjednodušení mohlo způsobit, že najednou bude celý dům jen na jedné straně hranice. To samé platí o tvé připomínce k plotu z druhého mailu: JESTLIŽE plot vede po hranici, tak je spojení obou objektů naprosto v pořádku a dává dodatečnou informaci. JESTLIŽE vede plot vedle hranice, tak je spojení samozřejmě špatně. Opravdu si myslím, že když už ta přesná data máme, tak bysme je neměli zbytečně "znehodnocovat". Ad zjednodušení geometrií: Dělal jsem ještě nějaké testy na datech RUIANu a zdá se, že pokud provedu zjednodušení (Douglas-Peucker) s přesností na 1cm (což je taky zhruba přesnost s jakou jsou data v OSM uložena), tak počet nodů jde dolu o zhruba 17%. To je myslím celkem slušná redukce bez výrazné ztráty informace. Jen pro úplnost: přesnost 0.1m dává redukci 22%, 1m potom 39%. Zdraví, Petr Morávek _______________________________________________ Talk-cz mailing
    -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlA/QQIACgkQkWJlWekVrbI9IgCfSACRG2ShFMSEkVhGEyGjTPUh M74AoIg88D0r98cG9IuxWube36ls0FtW =T8UI -----END PGP SIGNATURE-----
  23. "Petr Morávek [Xificurk]" petr na pada.cz #maa5b9d
    Vesměs s tebou souhlasím, ale píšu to z toho důvodu, že za rok dojde k aktualizaci dat v CUZK, budou se zase aktualizovat data v OSM a najednou se zjistí, že ten plot opravdu nevede po hranici, že barák opravdu je rozdělen, přestože před tím nebyl a zase se bude řešit, co s tím. Vždyť je to pořád dokola. Současná data jsou také import, který měl být přesný, ale není, prostě věci se mění.
    Zas tak černě bych to neviděl. Starý import probíhal z řádově méně přesných data. Teď máme konečně k dispozici rozumně přesný (a udržovaný) zdroj dat ve vhodném formátu. Hájím přístup, že pokud se zjistí (větší) změna hranice, tak se prostě hranice nahraje znova a staré cesty/body se ponechají jen pokud nesou nějakou jinou informaci. Takhle, když někdo spojí plot s hranicí (protože tam prostě ta hranice vede), tak ten plot zůstane spojený tak dlouho, dokud se průběh hranice výrazně nezmění... a až se změní, tak se prostě ta hranice posune na nové místo a plot zůstane. Žádné řešení stejného problému pořád dokola.
    Nehledě na to, že si někdo nevšimne, že potok je součástí relace hranice, rozdělí ho, kus tam vloží a už nepřidá do relace a hned je hranice rozbitá, což zase rozbije vyhledávače a různé jiné programy, než si toho někdo/něco všimne.
    Tuhle připomínku už jsem párkrát slyšel a můj názor je, že tohle by měl řešit editor! Asi jsem rozmazlený z Merkaartoru, kde při rozdělení cesty, která je součástí nějaké relace, se automaticky do dané relace přidá i nově vytvořený úsek. Jestliže tohle nějaký editor neumí, tak by to asi chtělo dát vědět autorům, že taková funkce chybí. A zrovna u těch administrativních hranic, můžu s celkem slušnou jistotou říct, že si takových chyb všimnu ;-) Zdraví, Petr Morávek aka Xificurk
  24. LM_1 flukas.robot+osm na gmail.com #m9ff957
    JOSM i Potlatch přidají do relace obě výsledné cesty po rozdělění. Tam by problém být neměl. Hranice (nebo jiné objekty) se v OSM mění když se změní v realitě nebo když jsou zpřesněny. Druhá varianta je u hranic (tam kde jsou obnovené katastrální mapy) celkem nepravděpodobná a první variantu řeší dobře přístup změny jen tagů a relacích patřících ke hranici. Dost dobře si nedovedu představit jak by měla vypadat přesná mapa s nezávislými hranicemi - různé body přes sebe? náhodná odchylka aby přes sebe nebyly? sdílené jen body (už nejsou nezávislé)? Co se týče zjednodušení tak přesnost 1cm by určitě neměla být problém (akorát se tím posunou některé body a některé zmizí, což by mohlo působit problémy při aktualizaci - po změně jednoho uzlu v nezjednodušených datech by mohl algoritmus dojít k celkové změně, která by ovlivnila mnohem větší oblast. Lukáš Matějka (LM_1)
  25. "Petr Morávek [Xificurk]" petr na pada.cz #m9caee7
    Co se týče zjednodušení tak přesnost 1cm by určitě neměla být problém (akorát se tím posunou některé body a některé zmizí, což by mohlo působit problémy při aktualizaci - po změně jednoho uzlu v nezjednodušených datech by mohl algoritmus dojít k celkové změně, která by ovlivnila mnohem větší oblast.
    Kandidáty na aktualizaci vybírám podle toho, jestli se OSM hranice a RUIAN hranice liší o více než x metrů. V první fázi jsem to pouštěl pro x=100, abych podchytil ty největší excesy. Do budoucna bych chtěl postupně opravit i hranice s menší chybou až do řádově několika metrů. Taková vzdálenost celkem spolehlivě zaručuje, že "zaokrouhlovací" chyba, kterou zmiňuješ, aktualizaci nespustí. A zrovna tak ji nespustí drobné posunutí pár bodů uživatelem. Zdraví, Petr Morávek aka Xificurk
  26. LM_1 flukas.robot+osm na gmail.com #mb54e98
    V tom případě je to bez problému. U hranic s odchylkou přes metr bych nečekal ani spojení s plotem, hranicí lesa apod. LM
  27. jzvc jzvc na tpfree.net #mb680dd
    -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Vesměs s tebou souhlasím, ale píšu to z toho důvodu, že za rok dojde k aktualizaci dat v CUZK, budou se zase aktualizovat data v OSM a najednou se zjistí, že ten plot opravdu nevede po hranici, že barák opravdu je rozdělen, přestože před tím nebyl a zase se bude řešit, co s tím. Vždyť je to pořád dokola. Současná data jsou také import, který měl být přesný, ale není, prostě věci se mění. Nehledě na to, že si někdo nevšimne, že potok je součástí relace hranice, rozdělí ho, kus tam vloží a už nepřidá do relace a hned je hranice rozbitá, což zase rozbije vyhledávače a různé jiné programy, než si toho někdo/něco všimne. Podle mne administrativní a fyzické objekty se nemají mixovat dohromady z těchto důvodů, přestože to zní lákavě.
    Mas i nemas pravdu ... na spouste mistech je ta hranice urcena prave trebas tou zdi domu, nikoli naopak ... a to ze by se administrativni hranice posunula do domu je velmi, ale opravdu velmi nepravdepodobne ... spis sem videl spoustu mist, kde pekne klickuje po jednotlivych domech, tak, aby vzdy cely dum byl soucasti jednoho ku. A jelikoz mam sousedku, co dela na katastru, a mimo jine dlouhodobe resi prave ruzny slucovani parcel ... tak vim ze na spouste mist posunovaly hranice prave kvuli tomu, aby dum nebyl na dvou ku. Mozna by nebylo od veci pred pripadnym updatem, zkusit zjistit kolik % hranic vede soubezne s necim jinym (rozdelil bych to jeste na dva pripady - soubezna way/priblizne (+-10m rekneme)). A kdyz uz sem pisu, ad statni hranice - rozhodne mame presnejsi nez sousedi, na par mistech sem ruco zpresnoval (samo je to mravenci prace a vopruz), zpresnena hranice pak vizuelne kopirovala spravne ... (orthofoto ....), takze bych se nebal je updatnout taktez. Rozhodne pak nezjednodusovat, cim presnejsi tim lepsi, navic zjednodusovani by vedlo k tomu, ze si tu hranici ja nebo nekdo dalsi nekde posune tak aby byla presne = zbytecne vygenerovana zmena, ktera povede k problematicke aktualizaci.
  28. jzvc jzvc na tpfree.net #m6507fd
    V tomto souhlasím s LM, že pokud spojení dat je přidaná hodnota a tam kde to tak je by se neměly cesty mazat, ale upravovat. Hranice rozhodně autonomní entity nejsou, mohou přece mimo fyzických věcí koincidovat i s jinými "abstraktními" geoinformacemi - jako hranice psč nebo něco takového a pokud z nějaké vyhlášky koincidují tak je obrovská přidaná hodnota, že budou v OSM koincidovat. Navíc i koincidence s objekty jako ploty, zdi, přírodní útvary a podobně je také přidaná hodnota, často i pro upřesnění polohy těchto objektů.
    S tím upravováním starých cest to není tak jednoduché. Není úplně jednoduché analyzovat, jaké části hranice se jak změnily, a rozhodnout, jestli se hranice posunula někam jinam, nebo jde jen o nepřesnost určení polohy té staré. Obecně asi takových případů příliš nebude. Upravil jsem skript podle připomínky Lukáše, aby nemazal cesty/nody s jinými tagy, tento konflikt mi hlásí v logu. Přijde mi jednodušší se po aktualizaci na dané místo podívat ručně a případně daný objekt znovu sloučit s hranicí.
    Aktualni stav hranic je, ze jsou dost nepresne (+- metry az desitky metru). Par useku sem zpresnil jak se dalo (dle KM) a je na nich note "nesahat, presne ..." (prevazne okres teplice). Predpokladam, ze pokud je bod hranice do rekneme tech 10m od bodu v RUIAN, a "sirokodaleko" neni zadnej jinej, lze jej prohlasit za "ten bod" a posunout jej do nove pozice. Na useky mezi takto detekovanymi body bych pak asi doplnil chybejici z RUIAN. Vyhoda je, ze nebudu nic delat s vlastni way = zadny aktualizace relaci ... Pokud takovy (posunovany) body jsou soucasti neceho dalsiho (budova, plot, ....) je to stejne asi na nejaky polomanuelni proces. Samo, vytvorit novou hranici a starou odstranit by bylo jednoduchy, ale jak bylo receno, ztraci se informace, ktera muze a nemusi odpovidat stavajicimu stavu (plot, vodni tok, ...) Asi bych navrhnul zjistit: 1) pocet hranic, ktere jsou vedeny jako ciste samostatne objekty (= nikde nesdili zadny usek ani body s nicim jinym). U tech bude aktualizace asi celkem bezproblemova. 2) pocty hranic se soubeznyma cestama - mozna rozpadnout na ruzne typy (voda/silnice/...) A podle toho kolik z toho vypadne bych resil co s tim dal. Podle me bude drtiva vetsina hranic vzhledem k predchozimu importu nenapojena nikam a tech problematickych useku by nemuselo byt mnoho.
  29. "Petr Morávek [Xificurk]" petr na pada.cz #m81b75c
    Aktualni stav hranic je, ze jsou dost nepresne (+- metry az desitky metru). Par useku sem zpresnil jak se dalo (dle KM) a je na nich note "nesahat, presne ..." (prevazne okres teplice). Predpokladam, ze pokud je bod hranice do rekneme tech 10m od bodu v RUIAN, a "sirokodaleko" neni zadnej jinej, lze jej prohlasit za "ten bod" a posunout jej do nove pozice. Na useky mezi takto detekovanymi body bych pak asi doplnil chybejici z RUIAN. Vyhoda je, ze nebudu nic delat s vlastni way = zadny aktualizace relaci ...
    Nahradit v relaci jednu cestu za novou není žádný problém. Naopak provést poctivě analýzu, jakou navrhuješ je řádově složitější problém (a taky mnohem náchylnější na chyby).
    Pokud takovy (posunovany) body jsou soucasti neceho dalsiho (budova, plot, ....) je to stejne asi na nejaky polomanuelni proces. Samo, vytvorit novou hranici a starou odstranit by bylo jednoduchy, ale jak bylo receno, ztraci se informace, ktera muze a nemusi odpovidat stavajicimu stavu (plot, vodni tok, ...) Asi bych navrhnul zjistit: 1) pocet hranic, ktere jsou vedeny jako ciste samostatne objekty (= nikde nesdili zadny usek ani body s nicim jinym). U tech bude aktualizace asi celkem bezproblemova. 2) pocty hranic se soubeznyma cestama - mozna rozpadnout na ruzne typy (voda/silnice/...) A podle toho kolik z toho vypadne bych resil co s tim dal. Podle me bude drtiva vetsina hranic vzhledem k predchozimu importu nenapojena nikam a tech problematickych useku by nemuselo byt mnoho.
    Bez obalu řeknu, že se mi příliš do téhle analýzy nechce... nějaký jiný dobrovolník? Ale už nějakou dobu se snažím udržovat hranice v konzistentním stavu, takže mám trochu přehled - objekty napojené na hranice jsou spíše výjimkou. Obecně mi není moc jasné, jaký problém se snažíš vyřešit - že se při aktualizaci ztratí informace o napojení? Rozhodnout, jestli napojení stále platí nebo ne, stejně musí člověk. Třeba tak, že se podle logu aktualizace podívám ručně na danou oblast. Plně automaticky to rozhodnout fakt nejde. Nevidím žádný přínos v zesložiťování nastíněného algoritmu aktualizace. Zdraví, Petr Morávek aka Xificurk
  30. jzvc jzvc na tpfree.net #m4a8624
    Aktualni stav hranic je, ze jsou dost nepresne (+- metry az desitky metru). Par useku sem zpresnil jak se dalo (dle KM) a je na nich note "nesahat, presne ..." (prevazne okres teplice). Predpokladam, ze pokud je bod hranice do rekneme tech 10m od bodu v RUIAN, a "sirokodaleko" neni zadnej jinej, lze jej prohlasit za "ten bod" a posunout jej do nove pozice. Na useky mezi takto detekovanymi body bych pak asi doplnil chybejici z RUIAN. Vyhoda je, ze nebudu nic delat s vlastni way = zadny aktualizace relaci ...
    Nahradit v relaci jednu cestu za novou není žádný problém. Naopak provést poctivě analýzu, jakou navrhuješ je řádově složitější problém (a taky mnohem náchylnější na chyby).
    Pokud takovy (posunovany) body jsou soucasti neceho dalsiho (budova, plot, ....) je to stejne asi na nejaky polomanuelni proces. Samo, vytvorit novou hranici a starou odstranit by bylo jednoduchy, ale jak bylo receno, ztraci se informace, ktera muze a nemusi odpovidat stavajicimu stavu (plot, vodni tok, ...) Asi bych navrhnul zjistit: 1) pocet hranic, ktere jsou vedeny jako ciste samostatne objekty (= nikde nesdili zadny usek ani body s nicim jinym). U tech bude aktualizace asi celkem bezproblemova. 2) pocty hranic se soubeznyma cestama - mozna rozpadnout na ruzne typy (voda/silnice/...) A podle toho kolik z toho vypadne bych resil co s tim dal. Podle me bude drtiva vetsina hranic vzhledem k predchozimu importu nenapojena nikam a tech problematickych useku by nemuselo byt mnoho.
    Bez obalu řeknu, že se mi příliš do téhle analýzy nechce... nějaký jiný dobrovolník? Ale už nějakou dobu se snažím udržovat hranice v konzistentním stavu, takže mám trochu přehled - objekty napojené na hranice jsou spíše výjimkou. Obecně mi není moc jasné, jaký problém se snažíš vyřešit - že se při aktualizaci ztratí informace o napojení? Rozhodnout, jestli napojení stále platí nebo ne, stejně musí člověk. Třeba tak, že se podle logu aktualizace podívám ručně na danou oblast. Plně automaticky to rozhodnout fakt nejde. Nevidím žádný přínos v zesložiťování nastíněného algoritmu aktualizace.
    Vidim problem v tom, ze takhle vyrobis cosi jako totalne oddelenou vrstvu, sniz kdokoli cokoli spoji, tak ty mu to smaznes. => muzem vytvorit to co tu bylo zmineno, bitmapu z RUIAN, prohlasit "tohle sou hranice" a neni co resit. A bylo by zahodno nejen zpresnit stavajici stav, ale umoznit i potencielni aktualizace do budoucnosti. Ze je to slozitejsi - no to je. BTW: Zrovna nedavno sem opravoval hranice s polskem aspon co se lv tejce (a pak sem opravil i statni hranice polakum a doplnil kus hranice na slovensku), protoze to bylo totalne rozjebly ... at zije zmena licence ... a to slovaci pokud vim ty hranice taky z neceho importovali ...
  31. "Petr Morávek [Xificurk]" petr na pada.cz #md20dc0
    Vidim problem v tom, ze takhle vyrobis cosi jako totalne oddelenou vrstvu, sniz kdokoli cokoli spoji, tak ty mu to smaznes.
    Ale vždyť už jsem několikrát psal, že jako nejlepší řešení vidím, že se podle logu na těch pár spojených starých objektů podívám ručně, a pokud to bude vhodné, tak je spojím zpět. Můžeš napsat konkrétně, co se ti na tomhle postupu nezamlouvá? Tohle podle mě fakt jinak než ručně (člověkem) rozhodnout nejde, pokud máš opačný názor, popiš prosím rozhodovací algoritmus (stačí slovně), který by tento problém spolehlivěe automaticky řešil. Zdraví, Petr Morávek aka Xificurk
  32. "Petr Morávek [Xificurk]" petr na pada.cz #m3ac743
    Jsem stejného názoru. Pracuju s daty z RÚIAN a WSDP ISKN v CouchDB, kde mám uložené přesně transformované souřadnice přes nadgrids=czech a pro výstup v GeoJSON je lehce generalizuju. Když tu ty data jsou, tak proč je nemít přesná. MK
    V souvislosti se zjednodušováním geometrie, mi až teď došlo, že zatím jsem používal sedmiprvkovou transformaci s klíčem "+towgs", která nemá úplně nejlepší přesnost. Můžete mě prosím někdo nasměrovat na vhodný soubor s českým gridem? Zdraví, Petr Morávek aka Xificurk
  33. Martin Kokeš shr3k na typo3-hosting.com #m136b20
    wget http://git.zcu.cz/grid/czech.lla nad2bin < czech.lla /usr/share/proj/czech 2065 mi pak funguje jako '+proj=krovak +lat_0=49.5 +lon_0=42.5 +alpha=30.28813972222222 +k=0.9999 +x_0=-0 +y_0=-0 +ellps=bessel +nadgrids=czech +pm=ferro +to_meter=-1 +no_defs' resp. zkráceně, definice toWGS se nahradí za definici nadgrids MK
  34. "Petr Morávek [Xificurk]" petr na pada.cz #mfdf8c9
    Ahoj, spichnul jsem programek na porovnani hranic, co mame nyni v OSM, s hranicemi v RUIAN. Překvapením je, že u zhruba 1500 (10%) KÚ se průběh hranic liší o 100m a více. Takže jsem spíchnul skript, který dokáže automaticky hranice opravit (nahradit) podle dat v RUIAN, malý test [1]. Co to (ne)umí: - opravuje hranice po jednotlivých KÚ. - nešahá na KÚ, která jsou na hranici ČR. - nešahá na KÚ, u kterých se změnily sousedi (např. RUIAN říká, že hranice KÚ X sousedí s KÚ A,B,C, ale v OSM máme, že sousedí s A,B,C,D). - vytvoří nové body a cesty podle RUIAN, updatne relace hranic a na závěr se pokusí smazat staré body a cesty. Než to pustím nějak ve větším chtěl jsem to trochu prodiskutovat, jestli takhle ano, příp. co změnit. Především mě zajímá jaký máte názor na zjednodušení geometrie importovaných cest (momentálně se žádné neprovádí)? Zdraví, Petr Morávek aka Xificurk [1] http://www.openstreetmap.org/browse/relation/426320 http://www.openstreetmap.org/browse/changeset/12878890 http://www.openstreetmap.org/browse/changeset/12878888
    Ahoj, vzhledem k tomu, že se žádné zásadní námitky neobjevily, tak skript pustím na relativně malé (~300) množině KÚ, kde se hranice liší nejvíce. Pokud se neobjeví nějaký nečekaný problém, tak budu pokračovat dál a postupně zpřesňovat hranice v OSM. Zdraví, Petr Morávek aka Xificurk
  35. "Petr Morávek [Xificurk]" petr na pada.cz #m338415
    Ahoj, malý update o stavu aktualizace hranic a jedna prosba o pomoc. 1) Navázané objekty na hranice: Ukázalo se, že navázaných objektů opravdu není moc - většinou náhodné osamocené nody, které byly na cesty hranic napojeny spíše náhodou při editaci než že by nesly nějakou dodatečnou informaci. Nicméně sem tam se objeví něco, co by stálo za to zpětně navázat - seznam si udržuju a po dokončení aktualizace hranic zpětně sloučím. Pokud jich bude hodně, tak někde vystavím seznam a požádám o pomoc s "úklidem". Ale to všechno až bude aktualizace hranic dokončena, zatím prosím pozdržte jejich případné napojování. 2) Ukázalo se, že existuje dost hranic KÚ, které mají oproti RUIAN jinou topologii (at už v důsledku zmeny hranice, nebo nepresnosti původního importu), což způsobuje, že skript na jejich aktualizaci selže. Postupně tyto problémy ručně opravuju, ale pokud chcete pomoci s aktualizací hranic, tak se můžete přidat. Co je potřeba opravit? Jde o to, aby každé KÚ sdílelo úseky hranice se správnými sousedy. Příklad: https://www.dropbox.com/s/beg7fx36jdfqbx7/before.png je třeba opravit na: https://www.dropbox.com/s/sqifntwkt9rh9zq/after.png viz: http://www.openstreetmap.org/browse/changeset/12958746 Zdraví, Petr Morávek aka Xificurk
  36. "Petr Morávek [Xificurk]" petr na pada.cz #m9c94bd
    PS: http://tools.geofabrik.de/osmi/?view=boundaries&lon=15.30692&lat=50.28099&zoom=17&overlays=coastline,boundary_relations_1,boundary_relations_2,boundary_relations_3,boundary_relations_4,boundary_ways_1,boundary_ways_2,boundary_ways_3,boundary_ways_4,boundary_ways_with_unknown_admlvl,non_simple_boundary_ways Jeste se importuje nebo uz je to hotovo? Na uvedenym linku je nejakej bordelismus.
    Jeste se "importuje" - resim poslednich par pripadu uvnitr statu, kde update selhal. Tenhle příklad (+5 dalších ve stejné kategorii) je nejaky divny. Zda se, ze self-intersection pochazi z RUIAN dat. Ale jeste jsem presne nevypatral, kde presne je chyba... pracuju na tom. Petr Morávek aka Xificurk
Napsat odpověď e-mailem… Odpovědět

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