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

[Talk-cz] Administrativni hranice z RUIAN

Vlákno 27.8. - 24.9.2012, počet zpráv: 39


27.8.2012 03:24:26 (#1)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
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

27.8.2012 03:34:00 (#2)
gravatar

Miroslav Šulc

<fordfrog at fordfrog.com>
101
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 Dne 27.8.2012 15:24, "Petr Morávek [Xificurk]" napsal(a): zobrazit citaci
> 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 > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz
------------- další část --------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4475 bytes Desc: Elektronicky podpis S/MIME URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20120827/109a5113/attachment.bin>

27.8.2012 03:40:41 (#3)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
Miroslav Šulc wrote: zobrazit citaci
> 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

27.8.2012 09:56:18 (#4)
gravatar

LM_1

<flukas.robot+osm at gmail.com>
103
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) Dne 27. srpna 2012 15:40 "Petr Morávek [Xificurk]" <petr na pada.cz> napsal(a): zobrazit citaci
> Miroslav Šulc wrote: >> 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 > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

27.8.2012 10:16:30 (#5)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
LM_1 wrote: zobrazit citaci
> 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

27.8.2012 10:42:23 (#6)
gravatar

LM_1

<flukas.robot+osm at gmail.com>
103
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 Dne 27. srpna 2012 22:16 "Petr Morávek [Xificurk]" <petr na pada.cz> napsal(a): zobrazit citaci
> LM_1 wrote: >> 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 > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

28.8.2012 07:24:45 (#7)
gravatar

hanoj

<ehanoj at gmail.com>
717
zobrazit citaci
> 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. zobrazit citaci
> 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

28.8.2012 09:06:49 (#8)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
hanoj wrote: zobrazit citaci
>> 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. zobrazit citaci
>> 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

28.8.2012 09:33:53 (#9)
gravatar

Martin Kokeš

<shr3k at typo3-hosting.com>
135
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 ----- Original Message ----- From: "Petr Morávek [Xificurk]" [mailto:petr na pada.cz] To: OpenStreetMap Czech Republic [mailto:talk-cz na openstreetmap.org] Sent: Tue, 28 Aug 2012 09:06:49 +0200 Subject: Re: [Talk-cz] Administrativni hranice z RUIAN zobrazit citaci
> hanoj wrote: >> 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 zobrazit citaci
> ty nody se dají případně zrecyklovat i na další věci
(vzhledem k zobrazit citaci
> tomu, že vedou po hranicích parcel). Jestliže vede hranice
přesně se zobrazit citaci
> zdí domu, tak by zjednodušení mohlo způsobit, že najednou bude
roh domu zobrazit citaci
> na jedné straně zbytek na druhé straně hranice.
V podstatě jediný zobrazit citaci
> důvod pro zjednodušení je redukce většího množství
nodů... což mi zobrazit citaci
> nepřijde jako příliš silný argument.
zobrazit citaci
>> 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 zobrazit citaci
> bohužel mají... už jsem na to v minulosti při opravách > narazil.
Zdraví, Petr Morávek aka zobrazit citaci
> Xificurk
_______________________________________________ Talk-cz mailing zobrazit citaci
> list
Talk-cz na openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz

28.8.2012 10:10:08 (#10)
gravatar

LM_1

<flukas.robot+osm at gmail.com>
103
Dne 28. srpna 2012 7:24 hanoj <ehanoj na gmail.com> napsal(a): zobrazit citaci
>> 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. zobrazit citaci
> >> 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 zobrazit citaci
> > ha > hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

28.8.2012 10:43:30 (#11)
gravatar

Petr Kadlec

<petr.kadlec at gmail.com>
219 1012
2012/8/27 LM_1 <flukas.robot+osm na gmail.com>: zobrazit citaci
> 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

28.8.2012 04:40:51 (#12)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
Petr Kadlec wrote: zobrazit citaci
> 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

29.8.2012 01:17:20 (#13)
gravatar

hanoj

<ehanoj at gmail.com>
717
zobrazit citaci
>>> 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? zobrazit citaci
> 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. zobrazit citaci
> Žá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

29.8.2012 01:32:15 (#14)
gravatar

LM_1

<flukas.robot+osm at gmail.com>
103
Dne 29. srpna 2012 1:17 hanoj <ehanoj na gmail.com> napsal(a): zobrazit citaci
>>>> 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". zobrazit citaci
> >> 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. zobrazit citaci
> >> Žá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 zobrazit citaci
> > ha > hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

29.8.2012 10:19:25 (#15)
gravatar

Jakub

<j at kub.cz>
33 3892
zobrazit citaci
>>> 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

29.8.2012 10:33:10 (#16)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
Jakub wrote: zobrazit citaci
> 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í. zobrazit citaci
> 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

30.8.2012 11:07:48 (#17)
gravatar

Mike

<mike at mikecrash.com>
198
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 On 28.8.2012 16:40, "Petr Morávek [Xificurk]" wrote: zobrazit citaci
> Petr Kadlec wrote: >> 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 > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

30.8.2012 11:09:53 (#18)
gravatar

Mike

<mike at mikecrash.com>
198
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. On 28.8.2012 9:06, "Petr Morávek [Xificurk]" wrote: zobrazit citaci
> hanoj wrote: >>> 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 > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

30.8.2012 11:14:03 (#19)
gravatar

Mike

<mike at mikecrash.com>
198
On 28.8.2012 10:10, LM_1 wrote: zobrazit citaci
> Dne 28. srpna 2012 7:24 hanoj <ehanoj na gmail.com> napsal(a): >>> 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...

30.8.2012 12:12:14 (#20)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
Mike wrote: zobrazit citaci
> 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

30.8.2012 12:23:07 (#21)
gravatar

Martin Kokeš

<shr3k at typo3-hosting.com>
135
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 ----- Original Message ----- From: "Petr Morávek [Xificurk]" [mailto:petr na pada.cz] To: OpenStreetMap Czech Republic [mailto:talk-cz na openstreetmap.org] Sent: Thu, 30 Aug 2012 12:12:14 +0200 Subject: Re: [Talk-cz] Administrativni hranice z RUIAN zobrazit citaci
> Mike wrote: > 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 zobrazit citaci
> nepsal. ;-)
Zopakuji, co jsem napsal už dříve: JESTLIŽE vede hranice zobrazit citaci
> přesně se zdí domu, tak by zjednodušení mohlo
způsobit, že najednou zobrazit citaci
> bude roh domu na jedné straně a zbytek na druhé
straně hranice. A zobrazit citaci
> přidám:
JESTLIŽE vede hranice skrz dům, tak by zjednodušení mohlo zobrazit citaci
> způsobit, že
najednou bude celý dům jen na jedné straně hranice. To zobrazit citaci
> samé platí o tvé připomínce k plotu z druhého mailu:
JESTLIŽE plot zobrazit citaci
> vede po hranici, tak je spojení obou objektů naprosto v
pořádku a dává zobrazit citaci
> dodatečnou informaci.
JESTLIŽE vede plot vedle hranice, tak je spojení zobrazit citaci
> samozřejmě špatně.
Opravdu si myslím, že když už ta přesná data zobrazit citaci
> máme, tak bysme je neměli
zbytečně "znehodnocovat". Ad zjednodušení zobrazit citaci
> geometrií:
Dělal jsem ještě nějaké testy na datech RUIANu a zdá se, zobrazit citaci
> že pokud
provedu zjednodušení (Douglas-Peucker) s přesností na 1cm zobrazit citaci
> (což je taky
zhruba přesnost s jakou jsou data v OSM uložena), tak počet zobrazit citaci
> nodů jde
dolu o zhruba 17%. To je myslím celkem slušná redukce bez zobrazit citaci
> výrazné ztráty
informace. Jen pro úplnost: přesnost 0.1m dává redukci zobrazit citaci
> 22%, 1m potom 39%.
Zdraví, Petr zobrazit citaci
> Morávek
_______________________________________________ Talk-cz mailing zobrazit citaci
> list
Talk-cz na openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz

30.8.2012 12:31:30 (#22)
gravatar

Mike

<mike at mikecrash.com>
198
-----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ě. On 30.8.2012 12:12, "Petr Morávek [Xificurk]" wrote: zobrazit citaci
> Mike wrote: >> 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 > list Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >
-----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-----

30.8.2012 01:39:34 (#23)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
Mike wrote: zobrazit citaci
> 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. zobrazit citaci
> 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

30.8.2012 02:26:22 (#24)
gravatar

LM_1

<flukas.robot+osm at gmail.com>
103
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) Dne 30. srpna 2012 13:39 "Petr Morávek [Xificurk]" <petr na pada.cz> napsal(a): zobrazit citaci
> Mike wrote: >> 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 > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

30.8.2012 04:20:53 (#25)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
LM_1 wrote: zobrazit citaci
> 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

30.8.2012 04:55:00 (#26)
gravatar

LM_1

<flukas.robot+osm at gmail.com>
103
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 Dne 30. srpna 2012 16:20 "Petr Morávek [Xificurk]" <petr na pada.cz> napsal(a): zobrazit citaci
> LM_1 wrote: >> 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 > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

30.8.2012 05:12:28 (#27)
gravatar

jzvc

<jzvc at tpfree.net>
554
Dne 30.8.2012 12:31, Mike napsal(a): zobrazit citaci
> -----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. zobrazit citaci
> > On 30.8.2012 12:12, "Petr Morávek [Xificurk]" wrote: >> Mike wrote: >>> 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 >> list Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > -----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----- > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

30.8.2012 05:28:49 (#28)
gravatar

jzvc

<jzvc at tpfree.net>
554
Dne 29.8.2012 10:33, "Petr Morávek [Xificurk]" napsal(a): zobrazit citaci
> Jakub wrote: >> 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. zobrazit citaci
> >> 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 > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

30.8.2012 05:56:11 (#29)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
jzvc wrote: zobrazit citaci
> 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). zobrazit citaci
> 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.8.2012 10:56:27 (#30)
gravatar

jzvc

<jzvc at tpfree.net>
554
Dne 30.8.2012 17:56, "Petr Morávek [Xificurk]" napsal(a): zobrazit citaci
> jzvc wrote: >> 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 ... zobrazit citaci
> > Zdraví, > Petr Morávek aka Xificurk > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

30.8.2012 11:37:52 (#31)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
jzvc wrote: zobrazit citaci
> 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

31.8.2012 02:06:26 (#32)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
Martin Kokeš wrote: zobrazit citaci
> 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

31.8.2012 03:21:17 (#33)
gravatar

Martin Kokeš

<shr3k at typo3-hosting.com>
135
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 ----- Original Message ----- From: "Petr Morávek [Xificurk]" [mailto:petr na pada.cz] To: OpenStreetMap Czech Republic [mailto:talk-cz na openstreetmap.org] Sent: Fri, 31 Aug 2012 14:06:26 +0200 Subject: Re: [Talk-cz] Administrativni hranice z RUIAN zobrazit citaci
> Martin Kokeš wrote: > 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 zobrazit citaci
> zjednodušováním geometrie, mi až teď došlo, že zatím
jsem používal zobrazit citaci
> sedmiprvkovou transformaci s klíčem "+towgs", která nemá
úplně zobrazit citaci
> nejlepší přesnost.
Můžete mě prosím někdo nasměrovat na vhodný zobrazit citaci
> soubor s českým gridem?
Zdraví, Petr Morávek aka zobrazit citaci
> Xificurk
_______________________________________________ Talk-cz mailing zobrazit citaci
> list
Talk-cz na openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz

2.9.2012 09:26:39 (#34)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
"Petr Morávek [Xificurk]" wrote: zobrazit citaci
> 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

2.9.2012 09:44:24 (#35)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
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

4.9.2012 06:33:07 (#36)
gravatar

"Petr Morávek [Xificurk]"

<petr at pada.cz>
139
Mike wrote: zobrazit citaci
> 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
Ahoj, koukal jsem jak moc se liší státní hranice v OSM oproti RUIAN verzi. Vygeneroval jsem vizualizaci [1] úseků hranice, kde byla výraznější odchylka (>50m). Pokud někdo trochu znáte některý ze zvýrazněných úseků, zkuste se mrknout která verze je přesnější. Pokud to bude ta naše z RUIAN, tak zkusím kontaktovat sousedy a poradit se, jak s případnou aktualizací. Předem díky, Petr Morávek aka Xificurk [1] http://osm.pada.cz/cr.html

4.9.2012 09:23:22 (#37)
gravatar

jzvc

<jzvc at tpfree.net>
554
Dne 4.9.2012 18:33, "Petr Morávek [Xificurk]" napsal(a): zobrazit citaci
> Mike wrote: >> 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 > Ahoj, > > koukal jsem jak moc se liší státní hranice v OSM oproti RUIAN verzi. > Vygeneroval jsem vizualizaci [1] úseků hranice, kde byla výraznější > odchylka (>50m). > Pokud někdo trochu znáte některý ze zvýrazněných úseků, zkuste se > mrknout která verze je přesnější. Pokud to bude ta naše z RUIAN, tak > zkusím kontaktovat sousedy a poradit se, jak s případnou aktualizací.
Cus, Koukal sem na to zbezne, u nekterych sem dokonce jako autor uveden ja ... (nevim proc, zjevne kvuli relicenc bootovi), napr hranici s Nemeckem za hrenskem sem 100% posunoval do pozice, kde je na KM a ten bot to nejspis zmenil zpet, protoze takhle blbe sem ji urcite nedelal ... Celkem se da rict, ze ty marknuty useky = prevazne hranice je vedena v ose vodniho toku, kterej sam o sobe neni importovanej nijak zvlast presne, ale stavajici hranice v OSM ho jen +- kopiruje, kdezto data v KM/RUIAN ho kopirujou daleko presnejs. Jak sem psal, nebal bych se to modnout vsechno, dost pochybuju ze bude nekdo ze sousedu mit presnejsi zdroj. Navic, pokud je mi znamo, tak statni hranice pochazeji (a tudiz z jiste 90%) z predchoziho obkreslovani(pomoci bota) nasi KM. Jen budes muset poresit relace, nektery useky budou mozna v 10+ relacich. zobrazit citaci
> > Předem díky, > Petr Morávek aka Xificurk > > [1] http://osm.pada.cz/cr.html > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

5.9.2012 03:28:07 (#38)
gravatar

Butrus Damaskus

<butrus.butrus at gmail.com>
31
2012/9/4 "Petr Morávek [Xificurk]" <petr na pada.cz>: zobrazit citaci
> Mike wrote: >> 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 > > Ahoj, > > koukal jsem jak moc se liší státní hranice v OSM oproti RUIAN verzi. > Vygeneroval jsem vizualizaci [1] úseků hranice, kde byla výraznější > odchylka (>50m). > Pokud někdo trochu znáte některý ze zvýrazněných úseků, zkuste se > mrknout která verze je přesnější. Pokud to bude ta naše z RUIAN, tak > zkusím kontaktovat sousedy a poradit se, jak s případnou aktualizací. > > Předem díky, > Petr Morávek aka Xificurk > > [1] http://osm.pada.cz/cr.html
Zdar, anžto jsem trvale v talk-de, poslal jsem tam krátký mail a popsal situaci. Uvidím, co odepíšou. Petr

24.9.2012 10:25:02 (#39)
gravatar

Butrus Damaskus

<butrus.butrus at gmail.com>
31
2012/9/5 Butrus Damaskus <butrus.butrus na gmail.com>: zobrazit citaci
> 2012/9/4 "Petr Morávek [Xificurk]" <petr na pada.cz>: >> Mike wrote: >>> 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 >> >> Ahoj, >> >> koukal jsem jak moc se liší státní hranice v OSM oproti RUIAN verzi. >> Vygeneroval jsem vizualizaci [1] úseků hranice, kde byla výraznější >> odchylka (>50m). >> Pokud někdo trochu znáte některý ze zvýrazněných úseků, zkuste se >> mrknout která verze je přesnější. Pokud to bude ta naše z RUIAN, tak >> zkusím kontaktovat sousedy a poradit se, jak s případnou aktualizací. >> >> Předem díky, >> Petr Morávek aka Xificurk >> >> [1] http://osm.pada.cz/cr.html > > Zdar, > > anžto jsem trvale v talk-de, poslal jsem tam krátký mail a popsal > situaci. Uvidím, co odepíšou. > > Petr
Tak se omlouvám, ale nedostal jsem se k tomu dřív. Tady je to vlákno v talk-de: http://www.mail-archive.com/talk-de na openstreetmap.org/msg96611.html

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