Re: [Talk-cz] Ruian jako zdroj dat

[Petr Morávek [Xificurk]]

Dne 6.12.2013 12:15, Pavel Machek napsal(a):
> Ahoj!
> 
>> a co je to "to"?
>> addr:city?
>> nebo myslis i addr:country? 
> 
> Oboji.
> 
> Nastavit to podle obrysu zeme / mesta je relativne jednoduchy, ale
> dava smysl mit to v databazi -- at to nemusi kazdy delat znovu.
> 
> Vsimnete si, ze treba navigacni software (navit, monav) ma problem s
> urcenim ve kterym meste je ulice. Ano, na velkym PC je to asi nejaky
> jednoduchy dotaz na spatiallite, ale databaze pro navigaci ma vyrazne
> jinou strukturu (a v navigaci neni dost RAM/disku na spatiallite).
> 
> K tomu melo byt is_in... ale to je nestastne bez struktury. Davalo by
> smysl mit addr:city / addr:country na ulicich?
> 
>   Pavel

Ahoj,

přiznám se, že konkrétní zkušenosti s těmito prográmky nemám, ale přijde
mi, že není problém ten index vytvořit ve chvíli, kdy exportuju data z
OSM pro navigaci, ne?

Osobně mi přijde jako nesmysl mnohokrát duplikovat ta samá data v OSM,
jen aby to trochu usnadnilo všechny myslitelné i nemyslitelné způsoby
jejich použití...

Petr


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Fwd: rozdělení multipolygonu

[Petr Morávek [Xificurk]]

Dne 4.12.2013 09:34, Zdeněk Pražák napsal(a):
> opravuji číslo cesty 26019351
> Pražák

A tady dokonce už ta multipolygon relace existuje (24038)...
Jen teda všechny tagy, které patří celému území vymezenému
multipolygonem (landuse=forest), by měly být na relaci a už ne na
jednotlivých cestách.

Zdraví,
Petr Morávek aka Xificurk

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Fwd: rozdělení multipolygonu

[Petr Morávek [Xificurk]]

Dne 4.12.2013 09:30, Zdeněk Pražák napsal(a):
> Dobrý den, při kreslení budov zároveň upřesnuji zakreslení lesů.
> Při tom jsem narazil na les (cesta č. 26016351) po jehož úpravách mi
> JOSM píše, že počet uzlů v této cestě přesahuje maximální povolený počet
> uzlů 2000 a nechce provedené změny nahrát.
> Jak mám rozdělit tento multipolygon?
> Pražák

Cesty rozdělit (na dva, příp. více částí), vytvořit multipolygon relaci
a přidat do ní tyto cesty, viz

http://wiki.openstreetmap.org/wiki/Multipolygon

Zdraví,
Petr Morávek aka Xificurk

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Ruian jako zdroj dat

[Petr Morávek [Xificurk]]

Ahoj,

Dne 3.12.2013 16:38, Dalibor Jelínek napsal(a):
>> U části obce bez pojmenovaných ulic to jde a žádná informace se neztratí. 
>> Tedy jsem pro.
>> addr:city = obec
>> addr:place = část obce
> Tohle se mi asi nelíbí, ale nejsem si jist. Máš nějaký příklad?
> Pointa addr:place je, že se pak dá najít adresa v obci bez ulic.
> A co budou uživatelé hledat více "obec nnn" nebo "část obce nnn"?
> Jestli to první, pak je potřeba do addr:place dávat obec
> a část obce dát někam jinam (třeba addr:is_in?).

Obecně čemukoliv, co obsahuje "is_in" bych se snažil vyhnout. Název tagu
by měl lépe popisovat, co to vlastně obsahuje za data - "is_in" (příp.
"addr:is_in") je strašně obecné. To je ostatně taky jeden z důvodů, proč
je "is_in" v současné době naprosto nepoužitelný - každý si tam cpe, co
chce.

Myslím, že by bylo dobré nějakým způsobem do všech adresních bodů dostat
jméno části obce, a to protože:
1) č.p. je unikátní jen a právě v rámci tohoto administrativním celku
2) část obce není vymezena geografickou hranicí, ale právě výčtem
adresních bodů
Osobně mi přijde "addr:place" jako celkem rozumná volba.


>> addr:city = obec
> Tady si nejsem jist, páč naše wiki říká, že je to název vesnice za PSČ
> Skutečně je to vždy stejné jako hranice obce a dá se to odvodit z mapy?

Tady pozor! Ta skladebnost funguje trochu jinak.

Obec je tvořena 1 a více částí obce.
Část obce je vymezena výčtem adresních bodů, které do ní patří.

Vedle toho stojí PSČ, které je AFAIK více méně číselným identifikátorem
pošty. Vztah pošty (potažmo tedy PSČ) a části obce je N:M.

Zdraví,
Petr Morávek aka Xificurk

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Opravdu není žádná shoda o adresních bodech?

[Petr Morávek [Xificurk]]

Ahoj,

tohle je takový dvousečný argument - ona ta duplikace zase na druhou
stranu umožňuje odhalit chyby v datech, které vzniknou třeba překlepem
nebo jiným druhem "neopatrné" editace ;-)

Jak už jsem psal, tak si nemyslím, že by existovalo ideální řešení přímo
v datovém modelu OSM. Když totiž řekneme, že se vydáme cestou duplikace
adresních tagů, tak to sice umožní snadnější hledání ve směru
POI>adresa, ale zase to zkomplikuje jiné věci - co by mělo být výsledkem
hledání konkrétní adresy? Pět POI, jeden čistě adresní bod a tři budovy?
To asi není to, co uživatel očekává.
Sice nebude nikdo muset dělat žádný pre-processing aby dostal vazbu
POI-adresa, ale bude potřeba dělat nějaký pre-processing aby člověk
dostal vazbu adresa-lokace.

Zdraví,
Petr Morávek aka Xificurk

Dne 16.10.2013 12:42, Jakub Sykora napsal(a):
> Jakmile je někde něco vícekrát, tak dříve nebo později vždycky dojde k
> nekonzistenci [1] - tedy k tomu, že se upraví pouze jeden bod a ostatní
> ne. A pak si vyber, co je vlastně správně a co ne.
> 
> Proto je to fuj fuj a snažíme se tomu téměř za každou cenu vždycky
> zabránit.
> 
> [1] http://cs.wikipedia.org/wiki/Nekonzistence
> 
> Dne 15.10.2013 09:47, Dalibor Jelínek napsal(a):
>> Jaký problém v tom vidíš, že je to fuj? Kromě zjevné duplikace dat,
>> což si myslím, že zas tak velký problém není. Něco mi uniká?
>>
>> Zdraví,
>>   Dalibor
an

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Opravdu nen? ??dn? shoda o adresn?ch bodech?

[Petr Morávek [Xificurk]]

Dne 12.10.2013 17:21, Pavel Machek napsal(a):
> Hi!
> 
>> Pokud se nepletu, hanoj tady pred nedavnem psal, jak se tyhle veci
>> resi efektivne pomoci databaze - je to jeden dotaz nad
>> geoprostorovou databazi, ktera se z OSM dat da naplnit skriptem za
>> par sekund. Pokud to samozrejme chces resit algorimticky bez
>> databaze, je to slozitejsi. Je to tedy spis diskuze o prostredcich a
>> pripadne o jejich znalosti a neznalosti. Ale urcite neni geodatabaze
>> nejake scifi, co by neumel nikdo pouzit - s navodem na wiki jsem si
>> ji sam rozbehl a co rict - funguje to.
> 
> Uz se tesim jak budu na telefonu rozbihat postgresql, nebo cim se to zrovna
> dneska dela...
> 
> Ja nerikam ze to nejde, ja rikam ze je to blbe a ze kazdy kdo to bude 
> delat v tom bude mit jiny chyby... a ze by davalo smysl projet to skriptem
> (jednou, referencne) a ulozit to v databazi explicitne.

Ahoj,

tenhle problém podle mě nemá jednoduché řešení přímo v datovém modelu OSM.

Problémy jsou následující:
1) vazba adresa - OSM budova je typu N:M
2) více POI může sdílet jednu adresu
3) více POI často nemůže mít tagy na jednom OSM objektu kvůli jejich kolizím
4) vazba OSM budova - reálná budova je typu N:M

Duplikovat adresní tagy na více místech je imho fuj, fuj.

Řešením podle mě je, jak ostatně píše i ty, nějaký pre-processing
surových OSM dat do podoby, která bude vyhovovat konkrétním požadavkům.
Data OSM jsou různorodé kvality a mixují různé druhy tagování - snažit
se všechny donutit k nějaké konformitě v tagování je bohužel dost nereálné.

Ano, je tu šance, že tu bude více nástrojů snažících se o to samé a
každý bude dávat trochu jiné výsledky... no a?

Zdraví,
Petr Morávek aka Xificurk

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Opravdu nen? ??dn? shoda o adresn?ch bodech?

[Petr Morávek [Xificurk]]

Dne 10.10.2013 09:53, Petr Holub napsal(a):
> Ahoj,
> 
>> Doufám, že jsem ten dotaz na overpass pochopil správně:
>>
>> ten dotaz zněl: vypiš všechny body typu cykloshop v areaXY, kde areaXY
>> byla area města Brna.
>>
>> Když bychom řekli, že chceme adresní body uvnitř jiné area, je to stejné.
> 
> doplnujici dotaz :) - dokazal bych pres Overpass API udelat query,
> ktere by mi vratili v dane oblasti (napr. Brno) vsechny cykloobchody
> a jejich adresy? To mi prijde jako zajimavejsi - protoze to znamena,
> ze v dane oblasti musim najit vsechny body typu cykloshop a pro
> kazdy z nich najit adresni bod, ktery je umisten ve stejne budove
> (za predpokladu, ze tedy cykloshop je umisten uvnitr budovy).
> V pripade, ze dana budova ma vice jak jednu adresu, tak vypsat
> vsechny adresy.
> 
> Docela by mne zajimalo, jak na to. :)
> 
> Diky,
> Petr

Ahoj,

na tohle úplně Overpass API není určené... jeho primární účel je výběr
dat z databáze podle zadaných kritérií. Můžeš tedy vybrat vsechny cyklo
obchody + vsechny adresní body, které jsou max. X metrů vzdálené od
nějakého obchodu.
Napárování "obchod č. 42 - adresa č. 6", si už musíš udělat sám...

Zdraví,
Petr Morávek aka Xificurk


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] číslo evidenční v addr:housenumber

[Petr Morávek [Xificurk]]

Dne 2.10.2013 10:34, Dalibor Jelínek napsal(a):
>> byly tu vášnivé diskuse na téma jak máme dodržovat každou pikatchovinu co
> si zrovna ÚJČ vycucá z palce, 
>> ale toto flagrantní porušení pravidel najednou nevadí?
> Většině lidí zjevně nevadí, mně se to zdá hezčí bez mezery a i pravidla
> říkají,
> že výjimečně se tam mezera nepíše, tak se na to můžeme dívat jako na další
> výjimku. ;-)

Cože?!? A to prosím kde?

(Ale jinak chápu argument se změnou několika desítek nodů vs. několika
stovek tisíc... škoda že převažuje ta špatná verze)


Zdraví,
Petr Morávek aka Xificurk


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] číslo evidenční v addr:housenumber

[Petr Morávek [Xificurk]]

Dne 27.9.2013 14:05, Dalibor Jelínek napsal(a):
> Umíte někdo vytáhnout z Overpass API sestavu všech bodů s
> addr:provisionalnumber?
> Když zvolím takový obdélník, že je v něm celá ČR, tak mi to browser
> nezvládne.

Na http://www.overpass-api.de/query_form.html zadej tohle:


  
  



Zdraví,
Petr Morávek aka Xificurk

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] footway vs. path vs. bridleway

[Petr Morávek [Xificurk]]

Ahoj,

Dne 1.9.2013 18:32, Pavel Machek napsal(a):
> Ahoj!
> 
>> myslim ze celkove je problem v tom ze doporuceni je treba trochu vice hledat
>> (wiki, talk, help) - byt se lecos opravdu najit da, uplne idealni by bylo
>> mit nejaka best practices a varovani pred nejcastejsimi problemy na jednom
> 
> Tady je problem ze doporuceni v ceske a anglicke versi si odporuji.

Jestli si dobre vzpominam, tak tenhle rozpor vznikl tim, ze se zmenila
anglická verze. Nevim, presne kdy a kym. Ale kdyz jsem pred par lety
zacinal, tak rozliseni path vs. footway vychazelo z anglickych zvyklosti
- bylo to neco jako, ze footway je pro cesty, ktere jsou
zakonem/vyhlaskou urceny pro chodce, path pro cesty, ktere naopak v
zakone namaji oporu. A tohle rozliseni bylo/je u nas prakticky
neaplikovatelne.

Osobne se v tomto rozliseni (vcetne briddleway vs. track) naprosto
ztotoznuji s tim, co napsal Pavel Bokr.

Asi by to chtelo opravit lokalizaci v editorech (footway = chodník, path
= pěšina).

Zdraví,
Petr Morávek aka Xificurk

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] nepoužitelná historie změn kvůli obřím oblastem?

[Petr Morávek [Xificurk]]

K tomu, co již napsali jiní, přidám ještě tip na jeden dobrý nástroj pro
zkoumání historie objektů:
http://osm.mapki.com/history/

Ukazuje historii změn konkrétního uzlu/cesty/relace - kdy, kdo co.

Sice to není úplně odpověď na otázku, co jsi pokládal, ale občas se to
hodí a mám pocit, že to moc lidí nezná.

Petr Morávek aka Xificurk

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] [okfn-cz] ŘSD stále odmítá vydat mapy

[Petr Morávek [Xificurk]]

Dne 2.7.2013 08:21, Jachym Cepicky napsal(a):
> * těch 210 000 odhaduju cenu licence k nějakému softu, která je potřeba
> na to, aby se něco převedlo z CAD do GIS formátu? Myslím, že je-li to v
> CADu a dali-li by to v CADu, nikdo by nemohl nic říct.
> 
> * pokud existuje WMS, musí pod tím existovat datový soubor nebo
> databáze, nad kterým to jede - tečka. Cena za skopírování souboru je 210
> 000? Cena za jedno SQL je 210 000? Tuhle práci chci dělat!

V tom zamítnutí je to napsaný - za 210k za tebe udělají to měření ve
WMS... Úplně vidím, jak nějaký úředník sedí dva týdny u mapy a dává
pořád dokola změřit, copy+paste souřadnice... :-)

Petr

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Dotaz na alej stromu

[Petr Morávek [Xificurk]]

Dalibor Jelínek wrote:
> Ahoj,
> 
> muzete mi prosim poradit, jak se ma spravne delat alej stromu?
> 
> Prosel jsem a zakresil Alfredovskou alej
> 
> http://www.openstreetmap.org/edit?lat=49.68752&lon=13.02831&zoom=17
> 
> Je to polni cesta a okolo dve rady stromu, jak uz to byva.
> 
> Tak jsem ji udelal jako highway=track a taky natural=tree_row
> 
> Jenze JOSM se to nelibi a tahle kombinace mu prijde podezrela.
> 
> Mam to ignorovat, nebo je zvykem kreslit aleje jinak?
> 
> Treba delat dve cesty stromu okolo skutecne cesty?
> 
>  
> 
> Diky za radu,
> 
> Dalibor

Ahoj,

podle wiki bych řekl, že tree_row je zamýšleno trochu obecněji... prostě
řada stromů. Takže klasická alej by asi měla být značena třemi cestami:
 natural=tree_row
 highway=track
 natural=tree_row

Zdraví,
Petr Morávek aka Xificurk

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] Náhrada za statistiku obyvatel z UIR-ZSJ

[Petr Morávek [Xificurk]]

Ahoj,

až teď jsem si všimnul jedné větičky na stránkách UIR-ZSJ:
> Se spuštěním základního registru veřejné správy od 1.7.2012 se referenčním 
> zdrojem územních číselníků stane Registr územních identifikací, adres a 
> nemovitostí a toky dat se změní.

Vzhledem k tomu, že poslední aktualizace je skoro rok stará, tak se
začínám bát, že to znamená, že další už asi nepřijde...

Naprostá většina dat je dostupná z RUIAN (a v lepším formátu :-)), ale
nepodařilo se mi dohledat odpovídající náhradu za údaje o obyvatelstvu,
které v UIR-ZSJ byly velmi podrobné. Nevíte někdo o nějakém
rejstříku/databázi, který by mohl sloužit jako náhrada tohoto zdroje?

Zdraví,
Petr Morávek aka Xificurk

[1] http://www.czso.cz/csu/rso.nsf/i/prohlizec_uir_zsj

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Průjezdy a další dotazy

[Petr Morávek [Xificurk]]

Ahoj,

Marián Kyral wrote:
> 1) Průjezdy
> Tady k Náměstí Evropy vede příjezdová cesta pod domem č. 612. Ač mám na
> cestě nastaveno, že je to tunel, layer=-1, budova má layer=2, tak se na
> mapě cesta zobrazuje přes budovu. Buď dělám něco špatně, nebo je v
> zobrazení nějaká chyba.
> 
> http://www.openstreetmap.org/?lat=49.670575&lon=18.347444&zoom=18&layers=M

Obecně - tag layer není příkazem pro renderer, jak věci vykreslit, ale
používá se pro označení, jak je více obejektů nad/pod sebou vertikálně
uspořádáno. Jak se věci nakonec vykreslí je starostí autora mapy. Mapa
na hlavní straně OSM vykresluje tunely highway=service (a některé další)
přes budovy... nicméně zdá se, že na tom zoomu 18 to ještě není
překresleno podle aktuálních dat.

> 2) Pořád Náměstí Evropy: Uprostřed je obrovský podstavec a kus trávníku.
> Nakreslil jsem podstavec (mimochodem, je to budova?), trávník a udělal
> jsem z nich a z náměstí multipolygon. Podstavec se na mapě zobrazuje,
> trávník ne. To mě mate, měla by tam být díra přes kterou se trávník zobrazí.

Hádám, že je to tím, že vnější cesta (199481722) je otagována jako
náměstí a tak se vlastně vykraslují dvě plochy přes sebe - trávník,
multipolygon jako náměstí s dírama, pak to celé překryje plocha
(199481722) jako náměstí a nakonec budova. (Toto pořadí je opět
definováno autorem mapy.)
Pokud chceš mapovat nějakou plochu s dírama jako multipolygon, tak taky
této plochy patří jen na relaci multipolygonu, jednotlivé cesty mohou
nést další tagy, které se vztahují jen a pouze na ty cesty samotné.

> 3) Na tom podstavci je šutr symbolizující Evropu. Dal jsem to jako
> památník (když tak nad tím přemýšlím, asi to bude jen socha) a ten se
> nezobrazuje. Ale vedle je památník na trávě a ten se zobrazí.

Tohle je "nedostatek" v tom, co se vykresluje na mapě...
historic=monument (tvůj památník) se nezobrazuje, historic=memorial
(památník vedle) se zobrazuje.
Osobně si myslím, že se historic=monument nadužívá - já jsem pod tímhle
tagem vždycky rozumněl skutečně velké památníky typu Socha Svobody.

> 4) Kousek dál mám stejný problém:
> 
> http://www.openstreetmap.org/?lat=49.679487&lon=18.347487&zoom=18&layers=M

Stejný problém jako výše.

> Mezi hlavní třídou a parkovištěm u haly je velká terasa na které je
> další památník. Ten se taky nezobrazí. Vypadá to, jako by highway s
> array=yes měl maximální prioritu a překryje úplně vše co je pod ním.
> 
> K té terase vedou z parkoviště po celé šířce schody. Nevím jak to
> zakreslit. Na plochu nejde přidat highway=steps a když tam dám bod
> kterému ty schody přiřadím, tak se to zase na mapě nezobrazí. A to je
> podle mně dost důležitá informace.

Jo, schody jako plocha nebo bod se nevykreslují... ani vlastně nevím,
jak by se vykreslovat měly - v takovém případě není totiž vůbec jasné,
jak jsou orientované.

Zdraví,
Petr Morávek aka Xificurk


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] chyby v RUIAN

[Petr Morávek [Xificurk]]

Ahoj,

sice to souvisí s OSM jen okrajově, ale je tu spousta chytrých a lépe
informovaných lidí, tak snad někdo poradí.

V průběhu "hraní" si s administrativními hranicemi jsem narazil na
několik problémů v RUIAN datech. Nepodařilo se mi najít způsob, jak
rozumně tyto chyby nahlásit - jediný kontakt, co jsem dohledal bylo
podp...@cuzk.cz. Než se pustím do boje s úředníky, tak jsem se chtěl
poradit tady, jestli někdo nevíte vhodný způsob, jak (a jestli) ty chyby
nahlásit.

1) Často nesedí geometrie hranice obce na hranice jednotlivých území,
tj. součet polygonů k.ú. není shodný s polygonem obce.
V posledním úplném dump z konce srpna tímto problémem trpí skoro
čtvrtina obcí. Většinou obě hraniční čáry jdou blízko sebe (jednotky až
desítky metrů), ale občas se taková plocha posčítá do celkem slušné
chyby. Nejextrémnějším případem je Stráž nad Nežárkou, kde plocha
konfliktního území je přes 14 ha.

2) Našel jsem 7 k.ú., kde je pošahaný polygon hranice - je k němu
přilepený lineární segment... špatně se to popisuje, takže radši
obrázkem [1] ;-)

3) Minimálně v Pardubicích jsou na některých místech špatně zanesený
budovy [2] - z několikavchodové bytovky je jako dům zakreslen jen jeden
vchod a zbytek obrysu skutečného domu je v RUIAN jen jako zastavěná plocha.

Zdraví,
Petr Morávek aka Xificurk

[1]
http://osm.pada.cz/hradcany-u-zehune.html?zoom=18&lat=50.15428&lon=15.252&layers=B0T
[2]
http://maps.fordfrog.com/?zoom=18&lat=50.02506&lon=15.77702&layers=B00FFF

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] Stav administrativnich hranic

[Petr Morávek [Xificurk]]

Ahoj,

tak nakonec proběhla (téměř?) kompletní aktualizace administrativních
hranic z RUIAN dat.
Momentálně žádná hranice nemá odchylku větší než 5m, tento stav budu
nadále pravidelně kontrolovat a udržovat. Tzn. pokud se hranice změní v
RUIAN, nebo se někdo sekne při editaci a přesune v OSM datech hranici
příliš daleko, tak aktualizuji hranici dotčeného KU z RUIAN.

Všechno výše napsané platí pro hranice uvnitř státu, státní hranice
zůstala více méně, jak byla. Nevím, kdy se k tomu dostanu, ale výhledově
bych určitě chtěl upravit skript a sepsat plán aktualizace i pro státní
hranici a oslovit s ním naše sousedy.

A teď bych chtěl všechny poprosit o pomoc s trochou dočišťovacích prací:
Některé objekty, které byly napojené na cesty hranic jsem už vyřešil,
ale spousta jich zbývá. Sepsal jsem malý komentář a seznam na wiki [1].
Už jsem odfiltroval objekty, které na novou hranici vůbec neseděly,
příp. nedávalo smysl je zpátky slučovat (cesty jdoucí kolmo na hranici
apod.). Neříkám, že všechno, co je v seznamu je vhodné nebo nutné
sloučit zpět na hranici, jde opravdu o oblasti, které je potřeba ručně
projít a používat při tom hlavu! ;)


Zdraví,
Petr Morávek aka Xificurk

[1] http://wiki.openstreetmap.org/wiki/Czechreg/Objekty_ke_kontrole

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] administrativni hranice z RUIAN

[Petr Morávek [Xificurk]]

jzvc wrote:
> 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

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Jak zabanovat škůdce?

[Petr Morávek [Xificurk]]

Petr Balíček wrote:
> Zdravim,
>  už mi dochází trpělivost s maperem »Waldschwamm«, kterej dělá převážně na 
> německý, ale i na český straně Šumavy neskutečnej bordel. Myslim tim hlavně 
> zneužívání tagů »name«, »width« a jiných, ignorování český diakritiky, atd., 
> atd.. Je toho fakt plno, mapuje ve velkým a docela pochybuju, že čerpá z 
> legálních zdrojů. Už sem ho několikrát upozorňoval, ale ze začátku 
> argumentoval, že potřebuje, aby se mu to zobrazovalo v jeho přístroji a kdesi 
> cosi, teď už mě ignoruje a jede si dál. Sice to dělá asi v dobrý vůli, ale 
> uniká mu, že by měl dodržovat jakýsi standardy. Kvůli takovýmhle iniciativním 
> pablbům mam fakt chuť se na celý mapování vys*t.
> Buď se mu někdo pokuste domluvit (nejlíp asi německy), nebo nevim.
> 
> PB

Tak už jsem mu v minulosti párkrát psal... anglicky fakt neumí :)

Jinak nejlepší bude asi shromáždit příklady problematických změn a
kontaktovat nejprve talk-de ať se mu to někdo pokusí v mateřštině
vysvětlit. Při nejhorším potom řešit přes Data Working Group.

Zdraví,
Petr Morávek aka Xificurk


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Administrativní hranice z RUIAN (bylo: Cesta sdilena vice vlastnostmi)

[Petr Morávek [Xificurk]]

LM_1 wrote:
> Hýbalo se i přesnými (+- 10 cm) hranicemi, nebo tam byla nějaká
> nepřesnost, při které se nic neměnilo?

Aktualizace probíhá po jednotlivých KÚ. Začal jsem postupně od těch, kde
byly odchylky největší, a postupuju k těm "přesnějším". Momentálně mám v
plánu dojet tento proces až do odchylky 5m a vyhlásit prozatím hotovo.
Současný stav je, že je aktualizována většina KU, kde byla odchykla
větší než 10m s výjimkou pár (zatím) ručně neopravených případů, kde se
změnila topologie hranic + státní hranice.
Vzhledem k tomuto postupu se jistě změnily i některé cesty, které byly
celkem přesné (protože aktualizaci spustila chyba v jiném úseku hranice
KU). A podle logu se zdá, že konečný stav bude prakticky kompletní
update hranic.

Zdraví,
Petr Morávek aka Xificurk

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Cesta sdilena vice vlastnostmi

[Petr Morávek [Xificurk]]

LM_1 wrote:
> Obvykle
> ale hranice probíhá po okraji silnice a tak  je sloučení fakticky
> nesprávné.

Toto je typicky pravda pro administrativní hranice. Cestu v OSM sice
značíme jenom čarou s nulovou šířkou, ale reálně nějakou šířku má a v
naprosté většině případů leží na jedné nebo druhé straně hranice.
Obecně bych řekl, že v naprosté většině případů je sloučení cesty a
administrativní hranice špatně.

Naopak hranice CHKO, NP, ... jsou typicky definovány výčtem objektů,
který ji tvoří. Nejlepší je asi podívat se do příslušného právního
předpisu, co tam je - a pokud je tam napsáno něco jako "hranici tvoří
lesní cesta od X k Y", tak je podle mě nejlepším řešením přidat do
relace hranice přímo tu cestu a nekreslit tam žádnou další čáru.

Zdraví,
Petr Morávek

PS: Prosím ještě pár dnů neslučujte objekty na administrativní hranice.
Jejich aktualizace z RUIAN se pomalu chýlí ke konci. Udržuji seznam
objektů, které dříve nějakým způsobem na hranice byly napojeny a
pravděpodobně by bylo vhodné je sloučit zpět... a vzhledem k rozsahu to
určitě nezvládnu sám ;)

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] OSMonitor

[Petr Morávek [Xificurk]]

Ahoj,

naši sousedé v Polsku v rámci licenčního přemapování vyvinuli celkem
zajímavý nástroj [1].

Primárně se jedná o analýzu silniční sítě, ale dneska jsem na IRC mluvil
s autorem a v plánu je rozšíření i na další trasy (cyklostezky atd.).
Nástroj je momentálně v experimentální fázi, ale autor plánuje ještě pár
vylepšení, aby to bylo víc "user-friendly" a sepsat lepší dokumentaci...
a následně zkusit rozšířit analýzu i na další země (třeba ČR ;-)).

Proč to sem píšu?
1) V minulosti se tu několikrát probíralo, že jsou silnice (jejich jména
a ref tagy) v OSM vedeny na špatné úrovni abstrakce a bylo by vhodné
tuto informaci udržovat jen na jednom místě - na relaci.
(Nejen) v Polsku začali vytvářet relace [2] pro hlavní silnice, na
kterých jsou uvedeny některé informace platné kompletně pro celou trasu.
Jako úplná náhrada současného systému tagování na mezinárodní úrovni se
tento koncept vzhledem k dlouhé a vyostřené diskuzi v talk@ zdá silně
neprůchozí. Dokonce byl velký odpor i k tak triviální změně jako
neuvádět ref tag na jednotlivých cestách, pokud je uveden na relaci.
Nicméně si myslím, že snaha mít pěkně celé silnice shromážděné v jedné
relaci, by se mohla podpořit i u nás.
2) Pro plnohodnotné fungování potřebuje OSMonitor základní referenční
data - seznam tras + jejich délek. Máte někdo tušení, jestli je možné se
někde k těmto údajům pro silniční/(cyklo)turistickou síť dostat?

Experimentální výstup pro české dálnice a rychlostní silnice je na [3].

Zdraví,
Petr Morávek aka Xificurk

[1] http://wiki.openstreetmap.org/wiki/OSMonitor
[2] http://www.openstreetmap.org/browse/relation/114014
[3] http://wiki.openstreetmap.org/wiki/OSMonitor/Czech_Republic_Major_Roads

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] státní hranice vs. RUIAN

[Petr Morávek [Xificurk]]

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

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Administrativni hranice z RUIAN

[Petr Morávek [Xificurk]]

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

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Administrativni hranice z RUIAN

[Petr Morávek [Xificurk]]

"Petr Morávek [Xificurk]" wrote:
> 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/1287

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


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Administrativni hranice z RUIAN

[Petr Morávek [Xificurk]]

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 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

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Administrativni hranice z RUIAN

[Petr Morávek [Xificurk]]

jzvc wrote:
> 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

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Administrativni hranice z RUIAN

[Petr Morávek [Xificurk]]

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.

Zdraví,
Petr Morávek aka Xificurk

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Administrativni hranice z RUIAN

[Petr Morávek [Xificurk]]

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@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Administrativni hranice z RUIAN

[Petr Morávek [Xificurk]]

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@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Administrativni hranice z RUIAN

[Petr Morávek [Xificurk]]

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@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Administrativni hranice z RUIAN

[Petr Morávek [Xificurk]]

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í.

> 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@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Administrativni hranice z RUIAN

[Petr Morávek [Xificurk]]

Petr Kadlec wrote:
> 2012/8/27 LM_1 :
>> 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@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Administrativni hranice z RUIAN

[Petr Morávek [Xificurk]]

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@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Administrativni hranice z RUIAN

[Petr Morávek [Xificurk]]

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@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Administrativni hranice z RUIAN

[Petr Morávek [Xificurk]]

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@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] Administrativni hranice z RUIAN

[Petr Morávek [Xificurk]]

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/1287

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] rúian - struktura dat adresních bodů

[Petr Morávek [Xificurk]]

jzvc wrote:
> To bude tim, ze Cp/Ce bude v ramci obce unikatni. Takze pokud "nejak"
> identifikujes tu obec, at uz nazvem obce nebo jeji casti (coz je celkem
> sumafuk), tak se vi, kam to poslat.

Bohužel nemáš pravdu, č.p. je unikátní v rámci části obce, nikoliv obce
(teď myslím to, co máme jako admin_level=8).

To, že je naše pošta flexibilní a doručí i zásilky skoro nedoručitelné,
je prima věc, ale v tom, jak správně importovat adresy do OSM nám to
bohužel moc nepomůže :/

Zdraví,
Petr Morávek aka Xificurk

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] rúian - struktura dat adresních bodů

[Petr Morávek [Xificurk]]

Ahoj,

Libor Pechacek wrote:
> Navázal jsem na Tvůj výrok, že ti "přijde zbytečné tam znova
> vypisovat informaci, která už je jednou na relacích hranic".  Názvy
> katastrálních území se od názvů obcí nepatrně liší.  Co jsem se teď díval, tak
> názvy KÚ mají často ještě nějaký místopisný přílepek - Doksy u Máchova jezera
> (normální smrtelníci znají jen jako Doksy), Obora v Podbezdězí (Obora) nebo
> Břevniště pod Ralskem.
> 
> Když tedy například zkusíš rekonstruovat is_in bodu
> http://www.openstreetmap.org/browse/node/983573832 z relací administrativních
> hranic, dojdeš k trochu jinému výsledku:
> současné is_in = Břevniště, Hamr na Jezeře, Liberecký kraj, CZ
> vs
> odvozené is_in = Břevniště pod Ralskem, Hamr na Jezeře, Liberecký kraj, CZ
> 
> Nejsem si jist, který z názvů je správný, nicméně jsem si celkem jist, jak sám
> hledám sídla v mapě. ;)

Proto jsem už v prvním mailu psal "alespoň pro administrativní jednotky
od obce výš", tím jsem myslel, že je zbytečné uvádět část "okres Česká
Lípa, Liberecký kraj, Severovýchod, CZ".
Nic z toho se "na obálku" nepíše. Zároveň se to dá komplet odvodit z
relací hranic, kdyby to někdo přeci jen k něčemu potřeboval.

Jméno části obce by se rozhodně mělo do importovaných dat nějakým
způsobem dostat, nejsem si jistý jestli is_in tag je nejvodnější místo,
ale pokud se tak dohodnem, budiž.

>> 3) Osobně si myslím, že addr:city by mělo obsahovat jméno obce a to sice
>> z čistě praktických důvodů - je to položka, která se typicky "píše na
>> obálku", máme netriviální počet "přesahů", kdy adresní body patřící pod
>> obec A, leží na území obce B (sice se tyhle anomálie pomalu odstraňují,
>> ale existují).
> 
> Vložení názvu části do "addr:city" podle mě problém systémově vyřeší alespoň
> pro ČR - jméno části obce (ve smyslu §27 odst. 2 zákona o obcích) je podle
> mých dosavadních zkušeností v rámci KÚ jednoznačné a nemá další dělení.

Ne, v addr:city by skutečně měl být název obce, nikoliv části obce.

Kdyby mi někdo posílal dopis na adresu.
Benešovo nám. ***
Zelené Předměstí [takhle se jmenuje část obce]
53002
tak by se s tím pošta asi nakonec nějak poprala, ale není to zrovna
preferovaný zápis mojí adresy, tím je:
Benešovo nám. ***
Pardubice
53002

Petr



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] rúian - struktura dat adresních bodů

[Petr Morávek [Xificurk]]

Ahoj,

Libor Pechacek wrote:
> Například Cvikov 
> (http://www.openstreetmap.org/?lat=50.7743&lon=14.6371&zoom=14&layers=M)
> má části Cvikov I a Cvikov II.  Avšak čára, kde mezi nimi vede hranice není v 
> mapě.

To je tím, že žádná taková čára neexistuje, části obce _nejsou_
definovány územím, ale výčtem adresních bodů (ze kterých potom můžeš
zpětně vygenerovat nějaké přibližné obalové křivky).

Petr



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] rúian - struktura dat adresních bodů

[Petr Morávek [Xificurk]]

Libor Pechacek wrote:
> Ahoj Petře,
> 
> Jak už jsem psal dříve, is_in obsahuje informaci z mapy katastrálních území
> neodvoditelnou.  Jednak někdy KÚ obsahuje více obcí, druhak se někdy obec
> jmenuje trochu jinak něž katasrální území.  Je ke zvážení, jestli je addr:city
> plnohodnotnou náhradou.
> 
> Libor

Ahoj,

asi budu potřebovat trochu vyjasnit, co jsi měl namysli...

1) KÚ je "vždy" součástí jenom jedné obce. Jedinou výjimkou je obec
Strýčice, která nemá žádné KÚ a leží na území obce Radošovice.

2) Název KÚ je pro adresní body "irelevantní" - v žádném formátu adresy
se neuvádí, pokud se nepletu, č.p. by měla být unikátní v rámci části
obce, jméno KÚ do toho nikde nevstupuje.

3) Osobně si myslím, že addr:city by mělo obsahovat jméno obce a to sice
z čistě praktických důvodů - je to položka, která se typicky "píše na
obálku", máme netriviální počet "přesahů", kdy adresní body patřící pod
obec A, leží na území obce B (sice se tyhle anomálie pomalu odstraňují,
ale existují).

Tag is_in zabilo jeho nadužívání (až zneužívání) pro vše možné i
nemožné, takže nikdo přesně neví, co vlastně jeho obsah má znamenat,
proto bych se mu snažil vyhnout.
Přijde mi celkem zbytečné psát třeba:
is_in="Pardubice, okres Pardubice, Pardubický kraj, Severovýchod, Česká
republika"
když to samé získám prostým pohledem (dotazem do databáze) na hranice,
které máme komplet. I nominatim, který se používá na openstreetmap.org
tohle obstojně zvládá. (Předpokládám, že počet meziokresních, nedej bože
mezikrajských, "přesahů" bude řádově menší než meziobecních... víte
vůbec někdo o takovém případě? Kolik jich v republice je?)

Když už něco dávat do is_in, tak jméno části obce... a to říkám jen
proto, že mě momentálně nenapadá lepší tag ;-)

Pěkný večer,
Petr Morávek aka Xificurk

PS: Ah, až teď když jsem to všechno dopsal, tak mě trklo, že jsi možná
pod pojmem "obec" neměl namysli pojem ze zákona č. 128/2000 Sb. (O
obcích), ale obecně "sídlo". Je to tak? Můžeš prosím vyjasnit?



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] import budov

[Petr Morávek [Xificurk]]

Martin Kokeš wrote:
> Bohužel v metrech. :-) Např. Pardubice cca 20 metrů SV-JZ.
> 
> MK

Určitě? V porovnání s čím?
Sice mám v tomhle směru fakt limitované znalosti, ale když jsem stáhnul
grid [1] a zkusil transformovat pár bodů z Ostravska, tak se výsledek
oproti definici [2] lišil cca o 0.5m (plus opačná znaménka).

Petr

[1] http://grass.fsv.cvut.cz/wiki/index.php/S-JTSK-Grid
[2] http://spatialreference.org/ref/sr-org/czech-s-jtsk-epsg2065/proj4/



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] import budov

[Petr Morávek [Xificurk]]

Martin Kokeš wrote:
> Předpokládám, že tehdy při importu UIR-ADR nikdo chybu při převodu JTSK>WGS84 
> neřešil. :-)
> 
> http://grass.fsv.cvut.cz/wiki/images/c/c6/Dopnul_wgs84_jtsk_xyerr.png
> 
> MK

Ahoj,

to jsou odchykly v centimetrech, ne? To je/bylo pro import adresních
bodů celkem irrelevantní.
U importu budov už by možná mělo smysl přemýšlet nad přesnější
transformací s nadgrids=czech. Na některých místech by ten necelý metr
už mohl být znát, ale i tak by to asi nebyla žádná velká tragédie.

Petr
<>

signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] import budov

[Petr Morávek [Xificurk]]

hanoj wrote:
>> ony ty registry občas taky obsahují blbosti. Můj oblíbený příklad je KÚ
>> z UIR-ZSJ jménem "Krupá u Kostelce nad Černýni Lesy" ;-)
> *** to neni blbost, to je fakt. KU maji unikatni nazvy napric CR.

Blbost to je, i když snadno přehlédnutelná, diffni si tyhle dva řetězce:

Krupá u Kostelce nad Černýni Lesy
Krupá u Kostelce nad Černými lesy

Petr
<>

signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] import budov

[Petr Morávek [Xificurk]]

Libor Pechacek wrote:
> Zkratky a neaktuální názvy jdou na účet MVČR, nesprávně malá/velká písmena 
> jsou
> chybou importovacího softwaru.  Sice jsem software opravil, ale původní názvy
> už v mapě zůstaly. ;)

Ahoj,
ony ty registry občas taky obsahují blbosti. Můj oblíbený příklad je KÚ
z UIR-ZSJ jménem "Krupá u Kostelce nad Černýni Lesy" ;-)

Petr Morávek aka Xificurk



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] import budov

[Petr Morávek [Xificurk]]

Jan Bilak wrote:
> Otázka je, jak by měla vypadat ta připravená data. V případě importu
> nových věcí tak, kde žádné nebyly, je to celkem primitivní. Ale mnohem
> náročnější bude import do míst, kde již nějaká data jsou. Tam bude
> třeba něco starého odstranit, něco modifikovat, něco přidat... Lze v
> OSM formátu postihnout nějak všechny tyto typy změn (odstranění,
> modifikace, přidání nových objektů)? A pokud lze, je možné to pak
> nějak rozumně vizualizovat, aby to člověk mohl projít a rozhodovat
> "tohle je ok, tohle zamítnu a zůstane při starém, tohle bude ještě
> trochu jinak..." pomocí stávajících nástrojů? Nevím, jaké jsou
> možnosti.

V OSM se používají v podstatě dva formáty:
1) osm: XML soubor s jednotlivými prvky.
2) osc (osmChange): XML soubor obsahující změny dat (obsah changesetu),
v podstatě se jedná o seznam prvků delete, modify, create, kde každý z
nich obsahuje změněné prvky. Jestli existuje nějaký rozumný prohlížeč
tohoto formátu netuším.
(více viz wiki)

Už nějakou dobu vyvíjím pythoní knihovnu [1] pro práci s OSM daty, mj.
jsem používal pro import sídel z UIR-ZSJ. Tam jsem taky používal metodu,
která diffne dva osm souboru a vytvoří z nich osc vhodný k uploadu
(proto byl postup - otevři vygenerovaný osm soubor, uprav dle chuti,
ulož, spusť skript pro upload).

> Např. u adresních bodů by bylo podle mě vhodné, aplikace provedla
> nějaké "inteligentní" matchování adresních bodů v OSM a RUIAN,
> zobrazovala původní a nový bod vizuálně propojený šipkou, jinak
> vyznačené body, které jsou pouze v OSM a naopak jinak vyznačené body,
> které jsou pouze v RUIAN. Uživatel by mohl vždy zvolit, zda ponechat
> novou nebo starou polohu bodu (zde by bylo možné i volit vlastní
> polohu - jde o primitivní úkon) atd. Nakonec by aplikace vytvořila OSM
> patch, který by obsahoval požadované úpravy včetně vhodně zmergovaných
> tagů (ty by možná bylo třeba také kontrolovat v aplikaci) atd.

Pokud se shodneme, že budem adresní body skutečně do OSM dávat jako
jednotlivé body (ale mám pocit, že tahle otázka se ještě definitivně
nerozřešila), tak by se asi dala zrecyklovat značná část logiky z
importu UIR-ZSJ. Troufám si tvrdit, že v takovém připadě by se dala
synchronizace OSM a RUIAN prakticky úplně zautomatizovat.

Ale teď se odhodlávám podívat se na to, v jaké formě obsahuje RUIAN
hranice a jestli by se nedala nějak zautomatizovat jejich aktualizace v
OSM (co jsem koukal, tak na některých místech se změnilo docela dost).

Zdraví,
Petr Morávek aka Xificurk

[1] https://github.com/xificurk/osmapis



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] MHD relace brání v editaci cest?

[Petr Morávek [Xificurk]]

Petr Stehlik wrote:
>Je někde nějak vizualizováno, co všechno jsme ztratili?

http://tools.geofabrik.de/osmi/?view=redactionbot

> Jaký bude postup oprav?

Zdá se mi, že každý (re)mapuje, co ho nejvíc pálí, stejně jako tomu bylo
vždycky v minulosti.

> A co jsem to slyšel o forku?

http://fosm.org/

Petr Morávek aka Xificurk



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Pěkná kupka práce

[Petr Morávek [Xificurk]]

jzvc wrote:
> Dne 25.7.2012 11:10, "Petr Morávek [Xificurk]" napsal(a):
>> jzvc wrote:
>>> To tam mohlo bejt 100x, pravne je to stejne neobhajitelny, protoze
>>> nemuzes souhlasit s necim co neznas - ze zakona. A pocitam ze podobne to
>>> bude ve vetsine statu EU.
>> Tenhle nesmysl tu muzes omylat zas a znova az do zblbnuti, ale nic to
>> nemeni na tom, co lidi v CT skutecne odsouhlasili:
> 
> A ty tu muzes 100x dokola omilat tuhle kravinu, protoze cokoli co je
> mimo zakon neni platny a to plati pro libovolnou smlouvu. Celou ODBL ti
> rozcupuje na cary libovolnej pravnik. Kdyz se ja ted rozhodnu, ze menim
> licenci ke vsem svym editacim, tak mi v tom nikdo nijak nezabrani a
> klidne si pravne vynutim odstraneni tech editaci z mapy.

http://lists.openstreetmap.org/pipermail/talk-cz/2012-January/007150.html





signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Pěkná kupka práce

[Petr Morávek [Xificurk]]

jzvc wrote:
> To tam mohlo bejt 100x, pravne je to stejne neobhajitelny, protoze
> nemuzes souhlasit s necim co neznas - ze zakona. A pocitam ze podobne to
> bude ve vetsine statu EU.

Tenhle nesmysl tu muzes omylat zas a znova az do zblbnuti, ale nic to
nemeni na tom, co lidi v CT skutecne odsouhlasili:

Rights Granted

2. Subject to Section 3 and 4 below, You hereby grant to OSMF a
worldwide, royalty-free, non-exclusive, perpetual, irrevocable licence
to do any act that is restricted by copyright, database right or any
related right over anything within the Contents, whether in the original
medium or any other. These rights explicitly include commercial use, and
do not exclude any field of endeavour. These rights include, without
limitation, the right to sub-license the work through multiple tiers of
sub-licensees and to sue for any copyright violation directly connected
with OSMF's rights under these terms. To the extent allowable under
applicable local laws and copyright conventions, You also waive and/or
agree not to assert against OSMF or its licensees any moral rights that
You may have in the Contents.

3. OSMF agrees that it may only use or sub-license Your Contents as part
of a database and only under the terms of one or more of the following
licences: ODbL 1.0 for the database and DbCL 1.0 for the individual
contents of the database; CC-BY-SA 2.0; or such other free and open
licence (for example, http://www.opendefinition.org/okd/) as may from
time to time be chosen by a vote of the OSMF membership and approved by
at least a 2/3 majority vote of active contributors.



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] d?ry nejen v silnic?ch I. t??dy

[Petr Morávek [Xificurk]]

Jakub wrote:
> 
>> 1) mel bys brat v potaz, zda je to uvnitr hranic - pro tenhle ucel by
>> ti melo stacit vzit statni hranice, zjednodusit je nejak (teda zalezi
>> na tom, kolik vypocetniho vykonu chces investovat) a brat jen prvky,
>> ktere jsou cele uvnitr.
> Nevám jako v overpass api rychle zjistit že je něco v ČR a nějaké
> sofistikované zjišťovátko se mi psát nechce. Budu rád za hint.

Mrkni na area-query, nebo tak nějak... určitě lze filtrovat podle
"oblasti", kde oblast je definována různými způsoby a jeden z nich je
relace hranic.

Petr Morávek aka Xificurk
<>

signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Pěkná kupka práce

[Petr Morávek [Xificurk]]

hanoj wrote:
>> No já furt nevím - BOT označuje jako problematické i objekty kde je odmítač
>> jen jako první v řadě
> *** BOT vraci pomoci verzovani kazdy objekt za posledniho
> odmitace(nebo nevyjadreneho). To muze znamenat i smazani objektu
> celeho (POI, way) nebo jeho casti (lomovy bod), je-li prvnim
> vlastnikem odmitac.

Ještě trochu chytřeji - dívá se na jednotlivé atributy objektu, tj.
tagy, souradnice u nodu, jednotlive nody v cestach, cleny relaci. Pokud
nejaky atribut byl pridan/zmenen odmitacem, je tento atribut vracen na
predchozi kompatibilni verze. Pokud byl poslednim editujicim daneho
atributu souhlasici clovek, tak je ponechan. Takto je "zkompilovana"
nova verze objektu, kterou bot nahraje do databaze a spinavou historii
zamaskuje. V extremnim pripade, kdy opravdu vsechny atributy byly
pridany odmitacem, je objekt kompletne smazan.

>> navíc snad nikdo ještě nestanovil nějaké datum kdy dojde k
>> "přepnutí" licencí (plán byl duben 2012), takže je otázka jak dlouho
>> aktuální stav potrvá.
> *** To prepnuti je ptace BOTa, ne?

Ne, databaze jako celek je stale oficialne distribuovana pod CC.
Momentalne bezi, redaction bot, ktery odstranuje nekompatibilni data z
databaze (predpokladana doba behu je cca mesic). Az svou praci dodela,
tak bude moci dojit k oficialnimu prepnuti licence na ODbL.

---
Opakovani je matka moudrosti, takze jeste jednou: BADMAP NEZOBRAZUJE
OBJEKTY, KTERE BUDOU SMAZANY! Jsou tam zobrazeny objekty, ktere byly
vytvoreny odmitaci, ale vzhledem k tomu, jak bot pracuje (viz vyse), to
jeste neznamena, ze budou opravdu vsechny smazany.

Petr Morávek aka Xificurk



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Cesta zakreslena

[Petr Morávek [Xificurk]]

Otakar Novák wrote:
> Co nechápu je celý ten princip - někdo v dávné minulosti něco nakreslil,
> mezitím několik dalších lidí provedlo editace a jen proto že ten první
> "něco" neodsouhlasil se smaže všechno? 

Ne.



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Cesta zakreslena "odmitacem" - jak spravne postupovat?

[Petr Morávek [Xificurk]]

Otakar Novák wrote:
> Ahoj,
> jsem tu novy (a v OSM skoro novy) a zatim docela nezkuseny takze mozna
> zbytecny dotaz:
> Dnes jsem narazil na problematiku mazani dat "odmitacu" a protoze jsem v
> lokalite ktera me zajima nasel jednu docela dulezitou cestu ktera je
> zahrnuta do tech problematickych tak se radeji zeptam jak spravne
> postupovat: mam danou cestu smazat a znovu nakreslit a otagovat nebo je
> nejaky jiny spravny postup?
> Diky

Myslím, že zrovna teď je nejlepší pár hodin/dnů počkat a podívat se pak,
co tam zbylo po průchodu bota. Opravit a doplnit objekty z licenčně
kompatibilních zdrojů, nebo vlastní GPS dat, tak jako by člověk editoval
jakoukoliv jinou oblast.

Petr Morávek aka Xificurk



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Praha bude brzy děravá :-(

[Petr Morávek [Xificurk]]

Zbynek Datinsky wrote:
> 
> dívám se na škodu co to napáchá a šťastný z toho nejsem
> 
> a tak mě napadá určitý workaround jak bota obelhat... co takhle načíst
> do JOSM určitou oblast nechat si pomocí filtru označit (otázka je zatím
> jak) všechny problematické objekty a posunout je o 1pixel... čímž tímto
> objekty sice nepatrně znepřesním ale převezmu vlastnictví na sebe a tím
> data "zachráním" vím že právně to asi OK není, nicméně měl by
> zvítězit zdravý rozum...
> 
> Datin

Ano, právně to není ok a s takovými daty by se zacházelo jako s
jakýmikoliv jinými OSM daty, které porušují copyright - smazaly by se
komplet.
Takže prosím, ať zvítězí zdravý rozum a nikdo nedělá takové pitomosti.
Děkuji.

Petr Morávek aka Xificurk



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Praha bude brzy děravá :-(

[Petr Morávek [Xificurk]]

jzvc wrote:
> Mno tomu se rika ucta k praci jinych.
> 
> Mimochodem, chapu spravne ze nam zmizi cela severni cast statni hranice?

Chapes spatne... Zrovna hranice jsem uz pred par mesici prochazel a v
tech nekolika malo pripadech, kde do toho hrabnul nejaky odmitac, jsem
dany usek naimportoval podle CUZK znova.

V BADMAP se pokud vim renderuji jen a pouze objekty vytvorene odmitaci.
To ovsem neznamena, ze je bot kompletne smaze. Napr. pokud se uplne
zmenily vsechny vlastnosti objektu (nody v ceste + tagy), tak objekt
zustane tak jak je. Obecne - bot odstrani vsechny prezivajici editace
odmitacu.

Ta severni hranice se tam asi dostala protoze je soucasti nejake nemecke
relace, kterou vytvoril odmitac.

Trochu nestastnym dusledkem toho, ze se bot snazi zachranit, co nejvice
informaci, je to, ze po jeho pruchodu zustavaji napr. opustene nody bez
tagu (nody byly ciste, ale cesta jejiz byly soucasti ne).

Panikarit ted je uz/jeste zbytecne, jeste bych s tim par hodin pockal :-)

Petr Morávek aka Xificurk



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Praha bude brzy děravá :-(

[Petr Morávek [Xificurk]]

Jan Bilak wrote:
> Ahoj, to mě také zaráží. V takovém případě by snad mělo smysl použít
> poslední licenčně použitelnou verzi, případně selektivně odstranit
> licenčně problematické tagy apod.
> 
> Honza

Ano takto nějak (ještě trochu chytřeji) bot pracuje... Ale žádný nástroj
upozorňující na "špinavá" data nemá implementovanou úplnou logiku bota,
takže všechny zobrazují i věci, které (částečně) přežijí.


Petr Morávek aka Xificurk
<>

signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] převod dat z rúian do postgresql

[Petr Morávek [Xificurk]]

Miroslav Šulc wrote:
> ahoj,
> 
> díky za tip. vypadal slibně do té doby, než jsem zjistil, že mi postgis
> nefunguje jak má. instaloval jsem ho poprvé, takže chyba může být i na
> mé straně, ale netuším, kde jsem jakou mohl udělat.
> 
> st_geomfromgml mi vrací chybu "ERROR:  invalid GML representation",
> dokonce i když použiju příklad z té referenční stránky:
> 
> ruian-test=# SELECT ST_GeomFromGML('
> 
> 
> -71.16028,42.258729 -71.160837,42.259112 -71.161143,42.25932
> 
> ');
> ERROR:  invalid GML representation
> KONTEXT:  SQL function "st_geomfromgml" statement 1

Tohle bude asi chyba v dokumentaci. Testnul jsem to u sebe a přišel na
to, že musíš uvést namespace, tj.

osm=> SELECT ST_GeomFromGML('
http://www.opengis.net/gml"; srsName="EPSG:4269">

-71.16028,42.258729 -71.160837,42.259112 -71.161143,42.25932

');

nebo ho poctivě odstranit na všech elementech:

osm=> SELECT ST_GeomFromGML('


-71.16028,42.258729 -71.160837,42.259112 -71.161143,42.25932

');

Petr Morávek aka Xificurk



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] Fwd: [OSM-talk] Redaction progress

[Petr Morávek [Xificurk]]

 Original Message 
Subject: [OSM-talk] Redaction progress
Date: Sun, 15 Jul 2012 11:46:40 +0100
From: Richard Fairhurst 
To: talk-gb OSM List (E-mail) ,
annou...@openstreetmap.org, t...@openstreetmap.org

[posted to talk-gb@, announce@ and talk@; please choose follow-ups
carefully; please also translate and forward to your local mailing list
if relevant]

The redaction bot has started on the 'Western Europe' area. Because
continents are annoyingly not shaped like rectangles, this inevitably
includes some overlap with North Africa etc. The UK is finishing off as
we speak.

You can monitor its current location at a site set up by Harry:

http://harrywood.dev.openstreetmap.org/license-change/botprocessing.php

As you'll see, the internal checks of the bot and the API occasionally
throw up errors which cause a region (1 degree square) not to be fully
processed. The coders working on the bot are tracking these failures
down and fixing them as we go: if you'd like to help or find out more,
they're in #osm-dev on IRC (irc.oftc.net). When a failure is fixed then
the bot is rerun for that area.

cheers
Richard

---
Překlad:

Redaction bot [pozn.: bot čistící OSM databázi do CT/ODbL
nekompatibilních dat] začal pracovat na oblasti "západní Evropy".
Protože kontinenty obvykle nejsou ve tvaru obdélníku, tak tato oblast
obsahuje i část Severní Afriky atd. Oblast Velké Británie se dokončuje
právě teď.

Postup bota můžete sledovat na Harryho stránce:

http://harrywood.dev.openstreetmap.org/license-change/botprocessing.php

Jak uvidíte, vnitřní kontroly bota nebo API občas vyhodí nějakou chybu,
která způsobí, že region (1 čtvereční stupeň) není kompletně zpracován.
Programátoři pracující na botovi tyto chyby sledují a opravují za chodu:
Pokud chcete pomoci, nebo zjistit více informací, tak je můžete nají v
IRC kanálu #osm-dev na irc.oftc.net. Po opravení chyby je bot puštěn na
daný region znova.

s pozdravem,
Richard
---

ČR je kompletně obsažena v oblasti "západní Evropy", pokud bude bot
postupovat jako do teď od jihu k severu a neobjeví se nějaké zásadní
nepředvídatelné chyby, tak by k nám měl dorazit maximálně během několika
následujících dnů.

Petr Morávek aka Xificurk
<>

signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] převod dat z rúian do postgresql

[Petr Morávek [Xificurk]]

Ahoj,
kód jsem nezkoumal, takže jen pár rychlých poznámek...

Miroslav Šulc wrote:
> myslím, že by se ten prográmek mohl hodit (nejenom) k testování
> použitelnosti rúian dat pro aktualizace map. momentálně to importuje
> všechny informace ze základní datové sady. ještě to neumí importovat
> hranice a definiční čáry ulic. gml mi nic neříká a neměl jsem čas se do
> toho nějak víc ponořit

Pokud máš v postgresql i postgis, tak by to mělo být velice jednoduché,
viz http://www.postgis.org/docs/ST_GeomFromGML.html

> v souvislosti s tím jsem se chtěl zeptat, jestli se dá nějak jednoduše z
> těch dat vygenerovat mapová vrstva (například s adresními body, ale až
> to bude umět importovat i hranice a ulice, tak i s těmi), která by se
> dala načíst třeba do josm. myslím, že pro vizuální kontrolu rúian dat vs
> osm by to bylo fajn.

"Jednoduše" je v tomto případě relativní... o hotovém skriptu nevím, ale
v případě bodů by to mělo být poměrně triviální. Stačí načíst z databáze
latlon souřadnice bodu a připojené atributy převést na tagy, pak už jen
vypsat v osm formátu.
Trochu komplikovanější by to bylo v případě exportu cest.

Petr Morávek aka Xificurk




signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Data RUIAN - výměnný formát

[Petr Morávek [Xificurk]]

jzvc wrote:
> Proto si myslim, ze je lepsi dat adresu na budovu. Navrch (kdyz uz sme u
> toho) vetsinou se tu kupodivu propaguje datove spravne reseni, coz v
> tomto pripade neni - nic jako adresa bodu neexistuje.  Az si nekdo
> vzpomene, ze bude do OSM davat cisla parcel, tak sme opet u toho, ze
> zase nekam flaknu bod misto abych oznacil hranici? Je to stejny jako s
> KU - proc markovat hranice KU, kdyz nekam dovnitr muzu flaknout bod.

Mně by se taky líbílo dávat adresu spíše na budovu, ale vidím tu dva
"problémy":
1) Občas má jedna (reálná) budova více adres a občas je v OSM budova
zakreslena pomocí více cest (např. pro možnost označení nižší/vyšší
části jedné budovy), takže vztah OSM budova:adresní bod je obecně N:M a
nevím, jak to elegantně vyřešit.
2) Aktualizace bodů je řádově jednodušší než cest.

Jak tagování pomocí bodů, tak i cest má svá pro a proti... možná bysme
to mohli začít sepisovat někde na wiki, včetně návrhů řešení.

Petr Morávek aka Xificurk



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Duplicity administrativních hranic

[Petr Morávek [Xificurk]]

Mirek Dlask wrote:
> Díky za objasnění, jenom se mi nelíbí třikrát opakované (jakoby) názvy obcí.
> 
> Například Bílá, a nedaleko v poli Bílá a ještě Bílá u Českého Dubu
> 
> http://www.openstreetmap.org/?zoom=15&lat=50.66293&lon=15.03459&layers=FB00

Mně taky ne, ale je problém dokopat někoho oprávněného, aby to v hlavním
stylu mapniku změnil, viz

https://trac.openstreetmap.org/ticket/3069

Petr Morávek aka Xificurk

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Duplicity administrativních hranic

[Petr Morávek [Xificurk]]

Mirek Dlask wrote:
> Zdravím,
> jestli to dobře chápu jsou hranice (katastru?) )některých obcí zdvojeny.
> 
> Například Branžež
> 
> původní relace
> http://www.openstreetmap.org/browse/relation/426610/history
> 
> nová, opakovaně upravovaná
> http://www.openstreetmap.org/browse/relation/441968/history
> 
> Není to jenom Branžež, viz sady změn.
> 
> Mirek

Ahoj,

zdvojeny ve smyslu 2x opravdu úplně ta samá data by žádné být něměly.
Tebou uvedený příklad je obec (441968), která má jen jediné podřízené KÚ
(426610) a tím pádem mají stejnou hranici. Ale každá z těch relací
reprezentuje jinou entitu.

Petr Morávek aka Xificurk

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] DIBAVOD Import - which license?

[Petr Morávek [Xificurk]]

malenki wrote:
> Hi, 
> 
> because of disagreeing user Pavel I stumbled over the DIBAVOD import
> today.
> Although the google translation seemed to show that the DIBAVOD data
> seems quite freely licensed it would be nice to have an exact
> declaration under which conditions and/or which license the Data was
> donated.
> 
> It would be kind to add a regarding line here:
> http://wiki.openstreetmap.org/wiki/Import/Catalogue
> 
> Best regards
> Thomas
> (malenki)

Hello,

as far as I know the license is not clearly stated on the dibavod
webpage. Our czech wiki page with free datasources [1] states that it's
free (as cost) and without any license restrictions - personally
confirmed by the head of GIS department. I'm not sure who exactly
checked this, but we could probably dig this up in the talk-cz archive.

I'll add this item to the catalogue.

Best regards,
Petr Morávek aka Xificurk

[1]
http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap#Vodstvo_.28DIBAVOD.29
<>

signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] czech republic: data wrongly marked as ODbL compatible was Re: Hromadné importy & změna licence

[Petr Morávek [Xificurk]]

Pavel Machek wrote:
>> If this is that case, I personally volunteer to help track down your
>> changesets containing the incompatible imports.
> 
> Thanks!
> 
>> The only two are the wikipedia imports of places and railway stations,
>> is this correct?
> 
> I think so.
>   Pavel

Hello,

I went through Pavel's changesets and I think I've found all the tainted
data. Here is what I did:

1) I went through Pavel's changesets (except the big ones already
identified as ODbL compatible imports).
2) Counted the number of created or modified nodes that had tags place=*
or railway=station,halt,tram_stop. This gave me 17 changesets that have
at least 10 such nodes.
3) Then I checked them manually and identified the mass imports.

Pavel's tainted changesets incompatible with ODbL+CT:
720911, 720263, 187327, 189654, 188101, 197352, 593595

Special case of changeset 473203: contains mostly import of forests, but
also 12 place nodes from wikipedia,etc., only 3 of them (27716,
27734, 27739) are still in the database. I would suggest we keep
this changeset and remove only those 3 offending nodes when the database
comes from read-only mode.

In the process I've found another changeset with import of places from
wikipedia,geonames,etc. performed by Bilbo. This should be marked for
removal as well:
312633


I would like to thank Pavel for his decision to allow the relicensing of
his work and sincerely apologize for my harsh words in my initial reply.

Best regards,
Petr Morávek aka Xificurk



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] czech republic: data wrongly marked as ODbL compatible was Re: Hromadné importy & změna licence

[Petr Morávek [Xificurk]]

Pavel Machek wrote:
> Hi!
> 
> So lets start by saying that I don't like ODbL and I hate CT.
>  
> There are three classes of data I uploaded to osm:
>  
> a) Hand created data, most important paths in the woods. CT+ODbL, is
> okay for those.
>  
> b) ODbL compatible - mass imports. CT+ODbL is okay for those, provided
> data from a) are kept. Richard convinced me that CT is not meant to be
> evil, and I can live with that.
>  
> c) ODbL incompatible mass imports. Obviously these need to be
> removed. I have no power to change this. Mass imports were cities 
> from wikipedia (place=*) and railway stations from around
> 
> http://www.openstreetmap.org/browse/changeset/188101
> 187327
> 
> I hope this helps, and I'd like to see some reply, thanks,
> 
>   Pavel

Hi,

I admit that I'm pretty confused right now... Are you saying that you've
changed your mind and are willing to agree to ODbL+CT, except for the
changesets containing imports of incompatible data? That would be really
great!

If this is that case, I personally volunteer to help track down your
changesets containing the incompatible imports.
The only two are the wikipedia imports of places and railway stations,
is this correct?

Best regards,
Petr Morávek aka Xificurk

PS: I've added to CC rebuild@ as well, just to let the guys there know
that there could be a last-minute request for keeping most of the data
from Pavel. Sorry, to all that will get this mail multiple times.



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] czech republic: data wrongly marked as ODbL compatible was Re: Hromadné importy & změna licence

[Petr Morávek [Xificurk]]

Hi,

Karel Volný wrote:
> what do I remember Pavel saying, and I can refer to the "OSM Inspector a stav 
> přijetí licence" talk-cz mailinglist thread, the closest thing to "maximising 
> the damage" is just that he is not going to do someone else's work (he even 
> *constructively* responded to some emails about what to do next, which is 
> better than acting like dead, so you really hardly can speak about 
> "maximising 
> the damage")
He was never asked to do someone else's work (regarding the license
change), the work of tracking down the bulk import changesets was done
by hanoj... All that was asked of Pavel was to formally agree that the
list of changesets contains "clean" data.

> so I don't hesitate to call you a liar

Yep, I'm terrible liar with links to talk-cz archive...

[1] Reaction to Frederik's suggestion regarding the overrides:
>> You have four options:
>> 1. Ideally, pavel would agree that these changesets come from a free  
>> source and are not affected by his general rejection of the Contributor  
>> Terms...[shortened]
> 
> I don't like the license change, nor the new contributor terms and so
> I don't want to make license change easy.

[2] Older discussion (in Czech, sorry) about license change, where Pavel
was asked essentially the same question and translation of the end of
his reaction:
> Relicensing the import and keeping the original data does not make sense,
> sorry. By that I would cause that most of the users would remain on
> osm.org and I could work in peace on fosm.org... alone.
> Which is not quite what I want.
> 
> So far I have a feeling it would be best not to change the license to OdBL.

I really don't know what other interpretation there can be, than
"maximising the damage" to OSM, so that more users would get upset and
convert to FOSM.

Best regards,
Petr Morávek aka Xificurk

[1]
http://lists.openstreetmap.org/pipermail/talk-cz/2011-December/006966.html
[2] http://lists.openstreetmap.org/pipermail/talk-cz/2011-July/006635.html

PS: I'm sorry for pouring more oil into the flames, but I just had to
make my case... Anyone interested in the real facts can go through
mailing list archives and find out for himself, but I would like to stop
with this here in talk-cz (and legal). So, don't expect me to react any
more in this thread, _unless_ Pavel comes with specific claims.



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] czech republic: data wrongly marked as ODbL compatible was Re: Hromadné importy & změna licence

[Petr Morávek [Xificurk]]

Pavel Machek wrote:
> So lets start by saying that I don't like ODbL and I hate CT.
> 
> Now, there's list of imports I did to OSM, with intention of marking
> them "OK to switch to CT+ODbL". Sorry, but you may not do that without
> my agreement. I believe I own copyright in most of those.
> 
> There are three classes of data I uploaded to osm:
> 
> a) Hand created data, most important paths in the woods. CT+ODbL, is
> okay for those.
> 
> b) ODbL compatible - mass imports. I'd be willing to be convinced that
> ODbL is okay for those, as long data from a) are kept. CT is
> not. Those imports were lot of work, and saying "you have to update
> OSM every once in a while to be even able to vote about licensing" is
> double-plus impolite.
> 
> c) ODbL incompatible mass imports. Obviously these need to be
> removed. I have no power to change this.

Pavel,

I'm sorry, but I'm starting to loose my patience. It's the same story
over and over again.

You've already clearly stated, that you don't like license change and
want to maximize the damage to OSM community, nothing new here.
(The fact that you haven't responded for almost two months, but
miraculously woke up a day before the announced license change is just a
coincidence, right?)

If you have any specific objections to the list of changesets that were
marked ODbL/CT OK, please share with us.
But the repeated vague (and completely irrelevant) statements about ODbL
incompatible imports, handcrafted data etc. are getting really really
old. For God's sake, I've already told you several times:
WE DON'T CARE ABOUT THOSE!
WE'RE TALKING ABOUT SPECIFIC SET OF CHANGESETS WITH BULK IMPORTS OF
ODBL/CT COMPATIBLE DATA.

I really don't know how to make this more clear.

There is a list of your changesets that we want to keep after the
license change:
http://wiki.openstreetmap.org/wiki/Quick_History_Service/Changeset_Lists#Pavel_imports_in_Czech_Republic
If you don't agree with this, _please_, state the number of the
changeset and the reason why it can't/shouldn't be kept after the
license change. Or be quite. Thank you!

Petr Morávek aka Xificurk



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import chráněných území z EEA

[Petr Morávek [Xificurk]]

Jan Kučera wrote:
> Ahoj,
> 
> jednalo se o import tohoto souboru:
> http://www.2shared.com/file/GAH9id2X/CR_final_UTF-8_NPP_2.html
> 
> tento skript
> http://svn.openstreetmap.org/applications/utils/import/bulk_upload_06/bulk_upload_sax.py
> 
> vyhodil tento output
> http://pastebin.com/5eQTe1Bv
> 
> s vysledkem techto 2 changesetu
> http://www.openstreetmap.org/user/Kozuch-EEA/edits
> 
> Chapu, ze by bylo lepsi udelat diff, ale momentalne neznam cestu, jak
> z .osm souboru takovy diff udelat... respektive jak to rozsekat na
> uploady treba po jednotlivych relacich...
> 
> Kozuch

Mohl bych se na to podívat a zkusit to nějak rozsekat a uploadovat, ale
teď toho mám až nad hlavu... nejdřív se k tomu dostanu za pár týdnů.

Mám aspoň revertovat ty dva changesety s nody, nebo už se to řeší jinak?


Petr Morávek aka Xificurk



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import chráněných území z EEA

[Petr Morávek [Xificurk]]

Jan Kučera wrote:
> Ahojte,
> 
> bohužel jsem při pokusu o import další části chr. území narazil na
> softwarové problémy - JOSM nebyl schopen dokončit import cca 12000
> uzlů najednou (zkošeno několikrát). Možná to bylo tím, že jsem
> rozdělil import na části po cca 2000 uzlech. Kdosi mi pak na
> help.osm.org doporučil importovat pouze v celku, tedy vše najednou,
> nicméně to jsem zkoušel v úplných začátcích a úspěšnost byla takřka
> 0%.
> 
> Zkusil jsem skript bulk_upload_sax.py
> (http://wiki.openstreetmap.org/wiki/Bulk_upload.py) na Xubuntu 11.10 -
> ten se mi choval pro změnu zase dosti šíleně a z mého .osm souboru o
> 12k uzlech vykouzlil dva changesety po cca 25k uzlech (viz
> http://www.openstreetmap.org/user/Kozuch-EEA/edits - pravděpodobně
> budu muset revertovat...) ... nechápu, kde ty uzly vzal. Nevíte někdo,
> co s tím?
> 
> Jaký SW používáte pro importy?
> 
> Zdravím,
> Kozuch

UIR-ZSJ jsem importoval pomocí vlastní pythoní knihovny [1], ale to byly
changesety řádově o stovkách uzlů (a pokud si dobře vzpomínám, tak
upload trval klidně i minuty).

Ono je v podstatě jedno, jaký software se použije. To podstatné je, že
musí udržet otevřené HTTP spojení dostatečně dlouho než to API přežvýká.

Imho by bylo nejrozumější to uploadovat po menších částech, ale
jednotlivé části stále jako "diff upload".
"Menších" tak, aby jednotlivé uploady proběhly v rozumném čase, tzn.
řádově asi ty stovky nodů.
Jako "diff upload" z toho důvodu, aby se v mapě nejdřív neobjevily jen
samotné uzly, do kterých by mohl někdo hrábnout a způsobit tak selhání
uploadu cest.

Rozdělení na menší části už nesouvisí s uploadem... otázkou je, jakou
strukturu mají data? Patří každý uzel jen do jedné cesty (krom
koncových)? Je možné to nějak rozsekat (teď neřeším technické provedení,
jen možnost)?

Petr Morávek aka Xificurk

[1] https://github.com/xificurk/osmapis

<>

signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] vícejazyčné názvy

[Petr Morávek [Xificurk]]

jzvc wrote:
> Jiste, takze budeme mit name=Praha/Prague/... ??? (minimalne cesky,
> slovensky, nemecky, anglicky, nejspis rusky ...) no to by byl bordel ...
> Prave proto, ze je mapa pro vsechny je mozny pouzivat name:lang, nikdo
> nikomu nebrani si pak celou mapu prepnout do svyho jazyka.

NE!! Já už fakt nevím, jak to lépe napsat...
http://lists.openstreetmap.org/pipermail/talk-cz/2012-February/007297.html

Čtete vůbec CO jsem napsal v těle mailů, nebo jste se zasekli na
předmětu "vícejazyčné názvy"?

Petr Morávek aka Xificurk



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] vícejazyčné názvy

[Petr Morávek [Xificurk]]

Karel Volný wrote:
>> Osobně si myslím, že hodnota tagu name by měla být stejná jako to, co je
>> v terénu napsáno na ceduli na začátku/konci obce (NEmyšleno ve významu
>> administrativním, ale obecně jakéhokoliv "sídla"). Ostatní názvy se
>> můžou dávat do official_name, alt_name atp.
> 
> +1

A ten obsah je v _některých_ místech dvojjazyčný ;-)

> do háje s menšinama, máme tu nějaký úřední jazyk, já fakt nestojím o to mít 
> mapu zadělanou nesmyslama typu "Karlovy Vary / Karlsbad / Столи́ца ма́фии"

O to taky "fakt nestojím"... a víš proč? Protože takhle Karlovy Vary
značené nejsou.


Já nevím, jestli jsem se špatně vyjádřil, nebo co... ale přijde mi, že
to tu někteří berou jako, že navrhuji aby se do name Prahy daly všechny
možné překlady, protože tam určitě žije pár Španělů, Italů, Slovinců,
Rusů, Němců... To vážně ne!
Ale jsou obce, kde výrazná část obyvatel prostě Češi/Moravané/Slezané
nejsou a nejen na dopravním značení je uveden název dvojjazyčně; dalším
příkladem můžou být různé turistické trasy vedoucí po hranici a názvy
jejich rozcestníků (povětšinou place=locality) a vrcholů(*). Přijde mi
zcela přirozené dát do tagu name názvy oba, POKUD je to tak označeno.
Když chce někdo čistě českou / německou / ... mapu, tak ji tak může
renderovat, name by měl obsahovat primárně to, co je v terénu a ne že ho
definujeme jako name=name:cs uvnitř polygonu ČR, name=name:de uvnitř
polygonu Německa...

(*) Schválně jsem se podíval na Sněžku:
name=Sněžka (Schneekoppe / Śnieżka)
Třeba tady konkrétně mi přijde německý (narozdíl od českého a polského)
název v name jako nesmysl. A určitě by se hodilo doplnit name:cs, ale
zatím jsem do toho nešahal.


Petr Morávek aka Xificurk



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] vícejazyčné názvy

[Petr Morávek [Xificurk]]

Mike wrote:
> Dvojjazyčné názvy bych rozhodně nezaváděl, nejsme protektorát. Obec má své
> oficiální jméno a to se používá všude, je jedno, zda je u hranic. Mapa je pro
> všechny, ne jen pro ty v okolí.

No právě, mapa je pro všechny ;-)

V oblastech s početnějšími národnostními "menšinami" se uvádí názvy
nejen na dopravním značení dvojjazyčně  (mj. to ukládá zákon o právech
příslušníků národnostních menšin a o změně některých zákonů). Stejný
obsah bych očekával v obecném tagu name.
Různé tagy pro jméno mají svůj důvod a přijde mi dost arogantní pokládat
rovnítko mezi name, name:cs a official_name jen proto, že je dané jméno
uvedeno v nějakém úředním rejstříku.

Petr Morávek aka Xificurk



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import UIR-ZSJ: Hněvkovice na levém břehu Vltavy

[Petr Morávek [Xificurk]]

Mike wrote:
> Ahoj,
> 
> ale vždyť to tak má být. I v mapách seznamu [1] to tak je a pokud to tak
> je i podle UIR, tak bych to tak nechal.
> 
> Mike
> 
> [1] http://www.mapy.cz/#x=14.446173&y=49.197222&z=13&c=23-31-14-30-28-29-27

Sice to nemám nikde oficiálně potvrzeno, ale vsadil bych boty, ze
zdrojem dat pro mapy.cz je právě UIR-ZSJ.

Osobně si myslím, že hodnota tagu name by měla být stejná jako to, co je
v terénu napsáno na ceduli na začátku/konci obce (NEmyšleno ve významu
administrativním, ale obecně jakéhokoliv "sídla"). Ostatní názvy se
můžou dávat do official_name, alt_name atp.
Dokonce bych se vůbec nebránil tomu, aby v name bylo pojmenování
dvojjazyčně - samozřejmě jen v některých pohraničních oblastech, kde to
je obvyklé i v terénu. A samostatná jména se pak můžou dát do
konkrétnějších tagů name:cs, name:de, name:pl...

Petr Morávek aka Xificurk



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import UIR-ZSJ: Hněvkovice na levém břehu Vltavy

[Petr Morávek [Xificurk]]

LM_1 wrote:
> Proč přejmenovávat, jestli se ta obec takto jmenuje? Určitě bych to
> nedělal jen na základě toho, že to zní divně. Spousty měst mají v
> názvu relativní poluhu k nějaké řece a nikdo to nezpochybňuje, i když
> obyvatelé Ústí nad Labem o něm asi budou mluvit jen jako o Ústí...
> Lukáš Matějka (LM_1)

Samozřejmě jsem to tak myslel - přejmenovat POKUD se tak obec nejmenuje...
Z toho, že tam je i stejnojmenná ZSJ "na pravém břehu", která jen patří
administrativně pod jinou část obce, tipuju že to "skutečný" název obce
není... ale každopádně bude nejlepší, když se na to mrkne někdo místně
znalý.

Petr
<>

signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import UIR-ZSJ: Hněvkovice na levém břehu Vltavy

[Petr Morávek [Xificurk]]

Václav Řehák wrote:
> Ahoj,
> 
> narazil jsem náhodou část obce "Hněvkovice na levém břehu Vltavy":
> http://www.openstreetmap.org/browse/node/1599120653
> 
> V UIR to tak opravdu je:
> http://uir.cz/casti-obce/172197/Hnevkovice-na-levem-brehu-Vltavy
> http://uir.cz/zsj/17219/Hnevkovice-na-levem-brehu-Vltavy
> http://uir.cz/zsj/02808/Hnevkovice-na-pravem-brehu-Vltavy
> 
> ale laicky mi to moc smysl nedává, resp. jsem v běžné mapě nic
> takového neviděl. Myslíte, že je to v pořádku?
> 
> Vašek

Hehe, to je docela vtipné pojmenování...
Ona je pak v registru ještě ZSJ "Hněvkovice na pravém břehu Vltavy"
(028088), ale ta uz patří do části obce Týn nad Vltavou.

Předpokládám, že tam tomu tak nikdo neříká, ani tam nemají ceduli s
podobně dlouhým názvem (i když kdo ví? :)), takže by asi bylo na místě
to prostě přejmenovat na Hněvkovice.

Petr Morávek aka Xificurk



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] dotaz na aktualizace keep right

[Petr Morávek [Xificurk]]

Zdeněk Pražák wrote:
> Minulý týden jsem provedl odstranění duplicitních potoků v okolí Hradce
> Králové a Pardubic.
> Když jsem se však dnes podíval na stránku keep right (
> keepright.ipax.at/report_map.php?lang=cs&number_of_tristate_checkboxes=6&highlight_error_id=0&highlight_schema=0&lat=50.04656&lon=15.77548&zoom=8&show_ign=1&show_tmpign=1&layers=B00T&ch=0%2C194
> 
> ) tak se zde pořád objevují duplicitní zkřížené potoky.
> Chtěl jsem se zeptat jak často se tyto duplicity na keep right aktualizují
> 
> Pražák

Už jsem podle keep right! delší dobu nic neopravoval... ale vzpomínám
si, že se změny projevovaly po celkem dlouhé době (řádově týdny)...
takže bych se moc neznepokojoval ;)

Petr Morávek aka Xificurk



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import chráněných území z EEA

[Petr Morávek [Xificurk]]

Jan Kučera wrote:
> Zdravím,
> 
> s většinou, co bylo dosud řečeno, souhlasím. Na wiki jsem vytvořil
> stránku o importu
> 
> http://wiki.openstreetmap.org/wiki/EEA:Nationally_designated_areas

Měl bych pár připomínek:
eea:cdda:sitecode - nahradil bych něčím jako 'ref:cdda'
eea:cdda:objectid - nevím jestli je nutné... stejně bude výsledek jako
relace a rozdělení na jednotlivé cesty se pravděpodobně s časem změní.
eea:cdda:parentiso - je zbytečné, kde se daná oblast nachází vyplývá
přímo z její polohy.
area:ha - je zbytečné, rozloha je dána vymezením geometrie
start_date - na zváženou, viz odpověď LM_1


> Rendering protected_area by bylo potřeba
> urgentně pořešit, osobně jsem měl za to, že se již renderuje úplně
> stejně jako "national_park" - viděl jsem v tom jistou výhodu oproti
> "spamovacímu" tagu NR, který dává plošně text "NR" do území, myslel
> jsem, že to bylo výsledkem přirozeného vývoje v této oblasti. Bohužel
> dle mých krátkých zkušeností jsou změny nastavení mapniku asi těžko
> průchozí, že? Chtělo by to alespoň zatlačit ne nějakého patřičného
> kret*na, co to má nahoře nastarosti...

Asi nejrychlejším řešením (které zvažuji i v souvislosti s
double-renderingem názvů KÚ, obcí atd.) je poslat přímo návrh na změnu
stylu jako pull-request na githubu [1].


[1] https://github.com/openstreetmap/mapnik-stylesheets
<>

signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import chráněných území z EEA

[Petr Morávek [Xificurk]]

LM_1 wrote:
>>  - valid_from - pro rok vytvoření
> Použil bych spíš start_date, je rozšířenější.
V kombinaci s boundary=protected_area není... Můj návrh byl motivován
zmínkou daného tagu na wiki a jeho použitím při podobném importu ve Francii.

>> Pro NP možná použít kvůli kompatibilitě (aspoň dokud to nezačně mapnik
>> renderovat) boundary=national_park.
> Když se budou dělat změny kvůli kompatibilitě s mapnikem tak nebude
> mít mapnik moc motivaci být měněn.
V tomhle jsem osobně opravdu na vážkách - ty čtyři parky v ČR to vážně
nevytrhnou (narozdíl od stovek dalších chráněných území)... prozatím by
se aspoň vykraslovaly, jakožto nejdůležitější chráněná území v ČR, a po
změně stylu pro mapnik by stačilo jen změnit boundary=national_park ->
boundary=protected_area

>> Ještě pár dalších věcí k NP:
>> Jak se vypořádat s ochrannými pásmy vs. vnitřními zónami NP? Já bych byl
>> pro to, aby se jako hranice NP označila hranice vnitřních zón a ochranné
>> pásmo označilo pomocí zvláštní relace podobně jako CHKO - ostatně třeba
>> na Šumavě ochranné pásmo je CHKO.
> Na wiki je to popsané (site_zone), přidržel bych se toho
Osobně moc nerozumím tomu popisu na wiki a jak konkrétně ho převést do
praxe, pokud mi to po lopatě někdo vysvětlí (a ukáže, že se to takto
vážně aspoň trochu používá), tak to uvítám.

Zdraví,
Petr Morávek aka Xificurk
<>

signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import chráněných území z EEA

[Petr Morávek [Xificurk]]

Ahoj,
koukal jsem na současný stav a tagování... tady je pár mých postřehů.

V OSM jsou chráněná území momentálně tagována převážně třemi způsoby
leisure=nature_reserve, boundary=national_park a potom novější obecnější
způsob boundary=protected_area (bohužel oficiální mapnik zatím nekreslí).
Navrhoval bych se přidržet systému boundary=protected_area [1] s
použitím dalších tagů:
  - protection_title - celými slovy NP, CHKO, NPR, PR, NPP, PP; toto
označení by pak už nemělo být v tagu name (s výjimkou NP?)
  - protect_class
  - ref
  - iucn_level
  - valid_from - pro rok vytvoření
Pro NP možná použít kvůli kompatibilitě (aspoň dokud to nezačně mapnik
renderovat) boundary=national_park.

Ještě pár dalších věcí k NP:
Jak se vypořádat s ochrannými pásmy vs. vnitřními zónami NP? Já bych byl
pro to, aby se jako hranice NP označila hranice vnitřních zón a ochranné
pásmo označilo pomocí zvláštní relace podobně jako CHKO - ostatně třeba
na Šumavě ochranné pásmo je CHKO.

Současný stav zmapování NP:
* KRNAP
Relace obsahovala mix cest hranic bez/s ochranného pásma; prozatím jsem
relaci upravil tak, aby to aspoň byl platný polygon - ponechal jsem
kompletnější hranice včtně ochranného pásma.
Je potřeba upřesnit hranice ochranného pásma především okolo Vrchlabí,
Některé cesty pro hranici vnitřních zón v databázi jsou, ale
není jich moc.

* Podyjí
V OSM je dvakrát:
- Nová relace (hranice včetně ochranného pásma).
- Rozdělaný polygon (hranice bez ochranného pásma), kde chybí díra na
Čížov, který je jen v ochranném pásmu.

* Šumava, České Švýcarsko
Vypadají celkem kompletně.

Zdraví,
Petr Morávek aka Xificurk

[1] http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] Problem with OSM Inspector License View/WTFE

[Petr Morávek [Xificurk]]

Hello,

I've come across a few weird things in OSMI License View - I was
wondering how is it possible that in Prague there is a lot of "created"
ways but their nodes seem ok.

Take a look for example here:
goo.gl/yANXl

There is a building that was created by jkjk (decliner):
http://www.openstreetmap.org/browse/way/51137581

But the nodes seem ok, so let's take a look:

http://www.openstreetmap.org/browse/node/652409854
http://wtfe.gryph.de/report/node/652409854

The creation of node (by jkjk) is marked as "harmless".


1) Why is not displayed the "harmless" status on OSMI?

2) Until know I thought that all v1 objects created by decliners will go
away, but it seems (at least for nodes) the WTFE logic is different.

3) It's a bit funny that the v1 "taintiness" coming from the position of
node is removed by v2 "changed position < 1m" (harmless contribution).
Is this really OK from the copyright and license point of view?


Best regards,
Petr Morávek aka Xificurk



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import chráněných území z EEA

[Petr Morávek [Xificurk]]

Pavel Machek wrote:
> Ahoj!
> 
>> 7) Je na zváženou, zda s importem ještě chvíli nepočkat a provést jej až
>> po změně licence, aby někdo nechtěně čerstvou cestu "neotrávil" licenčně
>> nekompatibilním uzlem, relaci cestou apod.
> 
> OSM uz zakazal pristup vsem kdo nesloushlasili s CL/OdBL.
>   Pavel

To sice ano, ale s daty, která "půjdou pryč" se dá stále manipulovat,
tzn. je tu možnost přidat uzel, který brzo zmizí do cesty/cestu do relace.

Petr Morávek aka Xificurk



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import chráněných území z EEA

[Petr Morávek [Xificurk]]

Jan Kučera wrote:
> CHKO jsou již hotové.

Páráda, na pár místech jsem si už všiml, teď koukám i na další místa...


> Dataset pro celou Evropu je dostupný zde:
> 
> http://www.eea.europa.eu/data-and-maps/data/nationally-designated-areas-national-cdda-5
> jedná se o soubor CDDA_v9_polygons.zip
> 
> Jedná se o shapefile, který má hezká metadata. Předpokládám, že máme u
> nás pouze minimum těchto území zpamovaných a duplicity budou tedy
> spíše vyjímkou a bude možné je časem pořešit.
> 
> Snad nikdo nepředloží výrazně závažný důvod bránící importu.

Já bych měl pár připomínek/námětů obecně k importu a tagování.

1) Tag name na cestách - je zbytečné a dokonce bych řekl nežádoucí dávat
tag name na cestu hranice, ten patří na relaci. Už třeba proto, že části
hranic jsou sdílené více oblastmi stejného druhu.

2) Sdílené hranice - souvisí s předchozím. Nemělo by vést více hranic
přes stejné body. Lepší je rozsekat jeden megapolygon do více cest a
přidat je do příslušných relací hranic - viz poměrně dlouhá zdvojená
hranice mezi CHKO Železné hory a Žďárské vrchy.
(Námět pro ty, co se nudí: sloučení s cestami administrativních hranic
na úsecích, které jsou totožné).

3) Více metadat - když už tam jsou taková pěkná metadata, použijme je;
inspirace pro tagování [1]. A stejným způsobem je i doplnit zpětně i na
CHKO a NP.
Co si myslím, že by bylo dobré:
- ref tagy pro snažší aktualizace v budoucnosti
- důsledně používat protection_title=NP,CHKO,NPP,... (samozřejmě celými
slovy) a pravděpodobně to vyhodit z tagu name.
- tag protect_class
- vymyslet tag, do kterého by se dal rok vyhlášení

4) Mysleme trochu do budoucna - zdá se, že tento datový zdroj bude
udržován mimo OSM i v budoucnosti. Zkusme provést import tak, aby jej
bylo možné v budoucnosti snadno aktualizovat.

5) Detekce duplicit - i když jich (asi) nebude mnoho, tak by nám import
měl dát alespoň jejich seznam, aby bylo jasné co a kde opravovat.

6) Provést import tak, jak by se mělo - pod spešl účtem.

7) Je na zváženou, zda s importem ještě chvíli nepočkat a provést jej až
po změně licence, aby někdo nechtěně čerstvou cestu "neotrávil" licenčně
nekompatibilním uzlem, relaci cestou apod.

Zdraví,
Petr Morávek aka Xificurk

[1] http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area
<>

signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

[Talk-cz] Hromadné importy & změna licence

[Petr Morávek [Xificurk]]

Ahoj,
právě jsem si všimnul, že nám v OSM Inspectoru [1] republika trochu
"odčervenala". Zdá se, že zatím byly changesety s importy, které dělal
pavel [2], označeny za čisté pouze v rámci OSM Inspectoru.

LWG chystá v brzké době převod těchto changesetů na jiný účet, kde budou
dále žít jako "licenčně čisté" [3].
Pavle, pokud máš k tomuto kroku nějaké konkrétní námitky, směřuj je tam
nebo/a LWG; případně, kdybys chtěl připojit k seznamu nějaké další své
changesety, které můžou žít v OSM i pod CT+ODbL, určitě budeme všichni rádi.

Zdraví,
Petr Morávek aka Xificurk

[1] http://tools.geofabrik.de/osmi/?view=wtfe
[2]
http://wiki.openstreetmap.org/wiki/Quick_History_Service/Changeset_Lists#Pavel_imports_in_Czech_Republic
[3]
http://lists.openstreetmap.org/pipermail/rebuild/2012-February/45.html
<>

signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] river/stream

[Petr Morávek [Xificurk]]

jzvc wrote:
> Obavam se, ze libovolna licence neni kompatibilni s moznosti zmeny
> licence OSM.

Spousta geodat je "bez omezení" (public domain), což kompatibilní je ;-)
Případně je vždycky možnost, že vlastník dá na požádání explicitní
souhlas s použitím v rámci OSM, byť třeba s dodatečnou podmínkou jako
zmínění instituce jako přispěvatele na webu OSM (jako např. australské
importy ze státních databází [1]).

Petr Morávek aka Xificurk

[1]
http://lists.openstreetmap.org/pipermail/talk-au/2011-September/008453.html
<>

signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] river/stream

[Petr Morávek [Xificurk]]

Karel Volný wrote:
> 
> zdar,
> 
>> Je možný použít data z webů povodí řek? Konkrétně "průměrný roční průtok",
>> např. "http://voda.chmi.cz/hpps/prf_bk_createpage.php?seq=2505280";
> 
> tipuju (!) že ano, nicméně stejná data jsou i na Wikipedii, takže ... 
> kdybychom jeli pod CC, tak řeknu, že je můžeš opsat bez skrupulí odtamtud, 
> leč 
> s novým licencováním je to nejspíše neslučitelné (především pokud licence 
> může 
> být libovolně měněna)

Tohle se asi vyřeší jedině dotazem na konkrétní licenční podmínky
použití dat, bohužel jsem je na webu na první pohled nenašel.

> c) limit 1 m³ je příliš přísný ... moje představa o tom, co už je řeka, by se 
> dala vyjádřit _také_ tím, odkud je to (aspoň zjara) splavné pro normální loď, 
> nikoli jen pro šílence honící prvosjezdy na ultrakrátkých rodeovkách
> 
> s průměrným průtokem 0,60 m³/s v Batelově by z toho tak vypadla například 
> Jihlava nad soutokem s Třešťským potokem, kterou jsme ovšem celkem bez 
> problémů jeli na Orlici (a to je nějakej koráb) z Dolní Cerekve ... a věř mi, 
> že tam ji rozhodně nepřeskočíš, to jde tak maximálně do Horní Vsi, možná do 
> Horní Cerekve (místní znalci mě doplní, já už si to tak přesně nepamatuju)
> 
> no a nebo třeba Rokytná, jeli jsme ji od Jaroměřic, přičemž v Příšťpu má 
> průměr 0,75 m³/s ... neznám, jak vejš, ale v těch Jaroměřicích bych ji určitě 
> přeskakovat nechtěl

Tagovat podle jen podle průtoku skutečně není šťastné, ale když se zvolí
limit naopak dostatčně nízký a použije se pouze pro změnu river->stream
a ne naopak, tak výsledek bude rozhodně lepší než současný stav... a až
se najde někdo místně znalý (nebo ochotný to vykoukat z leteckých
snímků), tak ten bod zlomu stream/river zpřesní.

Petr Morávek aka Xificurk
<>

signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] OSM Inspector a stav přijetí licence

[Petr Morávek [Xificurk]]

Ahoy,

Pavel Machek wrote:
> (tato debata necht je verejna)
pardon, nejak jsem prehledl obsah TO/CC policek :D

>>> Pak tam bylo jeste 
>>>
>>> 5) automaticke pojmenovavani ulic pomoci nameit.
>>
>> Jsou k tomu někde informace? Na wiki nic nevidím.
> 
> Melo by to jit najit v praze, nekde v poznamce bude "nameit".
Data se asi dohledají, mně šlo spíše o zdroj, licenci, průběh importu.

> S CT+ODbL souhlasit nemuzu, uz treba kvuli ty wikipedii. Treba kvuli
> tomu ze jsme zdrojum slibovali konkretni licenci, a s CT uz to nemuzem
> zarucit.
Tomu rozumím a chápu to... Řešení existuje: požádat o převedení
závadných (nebo naopak nezávadných, podle toho co se dohledává snáze)
changesetů na jiný účet a na tom nezávadném odsouhlasit CT+ODbL. Chápu,
že se ti do toho nechce, protože nesouhlasíš se změnou licence a jsi
naštvaný na OSMF, ALE...
V tomto vlákně je řeč o vybraných changesetech (které vypátral hanoj),
které obsahují importy z PD zdrojů! Aniž bych chtěl nějak hanět tvoje
zásluhy, tak u některých částí zmíněných importů jsi byl pouhým
uploaderem, což tě na první pohled staví do pozice člověka držícího
autorská práva na dané příspěveky, ale když by se do toho začlo šťourat,
tak už to tak jednoduché nebude.
Tomáš Kolda už nabídl, že některá data, na kterých pracoval, má a
případně je poskytne k re-importu.
Jediné, o co tě chceme poprosit je, abys kývnul - "jo, tyhle data jsou
ok". Z právního hlediska v tom skutečně nevidím nejmenší problém...
zmizelá (po dokončení přechodu na odbl) data se dají vždycky
re-importovat; nanejvýš tedy dosáhneš toho, že bude zahozena práce
spousty lidí, kteří původní import dále opravovali a vylepšovali.

Petr Morávek aka Xificurk



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] OSM Inspector a stav přijetí licence

[Petr Morávek [Xificurk]]

Pavel Machek wrote:
> ODBL narozdil od CC umoznuje renderovat nekopirovatelny mapy na
> zaklade OSM. Me to prijde jako zmena GPL->BSD. A nelibi se mi.

Když už je tu snaha přirovnávat změnu v OSM ke změně SW licencí, tak
změna CC->ODbL nejelépe odpovídá GPL->LGPL.
GPL->BSD by odpovídalo převodu OSM databáze do public domain (což se
opravdu neděje).

Já osobně beru možnost používat OSM pro renderování map zatížených
nějakou netriviální licencí jako plus. Pro OSM to otvírá cestu do míst,
kam se za současných podmínek prostě dostat nemůže -> větší rozšíření ->
více maperů -> lepší data. Bude možné renderovat mashupy OSM dat s
datasetem, který není "svobodný" (ať už je k tomu jakýkoliv důvod).

Petr Morávek aka Xificurk
<>

signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] OSM Inspector a stav přijetí licence

[Petr Morávek [Xificurk]]

jzvc wrote:
>> Cílem je v budoucnu publikovat konzistentní geodata pod hlavičkou jedné
>> entity (OSMF), která jsou chráněná ODbL.
> Nejsou chranena nicim. Proto mi vadi,z e kvuli NICEMU se tu likviduje
> prace spousty lidi.

Když "nejsou chráněna ničím", tak není nic snažšího - sežeň pár lidí,
založte projekt, který vezme poslední vydání CC dat a pak bude kopírovat
nové (ODbL only) changesety z OSM databáze... uvidíme, jak dlouho takový
projekt přežije.

Petr Morávek aka Xificurk

PS: Nemyslím si, že bysme pokračováním této debaty něco zásadního
změnili. Situace bohužel není ideální (kéž bysme na světě právníky
nepotřebovali :)), ale radši budu věnovat úsilí "záchraně" a vylepšování
dat v rámci vymezených možností.



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] OSM Inspector a stav přijetí licence

[Petr Morávek [Xificurk]]

jzvc wrote:
> Staci i trivialni cast, proste pokud se nekdo citi poskozen a
> poskozovatel pouziva jeho data, muze ho zalovat.

Žalovat si může kdo chce koho chce za co chce... Otázka je s jakou
úspěšností.

> Nehlede na to, ze pokud
> nekdo vyuzije data v rozporu s novou licenci, muze klidne tvrdit, ze mu
> to jednotlivi prispevatele povolili a sem moc zvedav, jak bude nekdo
> dokazovat opak. Opet nezbude nez se obratit na prispevatele s tim, aby
> potvrdili/vyvratili toto tvrzeni.

Cože?!? Sice, jak už jsem psal, nejsem právník, ale předpokládám, že
"důkazní" břemeno je na straně toho, kdo ta data "zneužívá". Aby je mohl
používat, jak píšeš, tak by musel provést přesně to, co nyní dělá OSMF -
vyžádat si souhlas od všech přispěvatelů.


Nějak se začínám ztrácet v tom, co ti vlastně vadí - mazání dat?
Cílem je v budoucnu publikovat konzistentní geodata pod hlavičkou jedné
entity (OSMF), která jsou chráněná ODbL.
Pro dosažení tohoto cíle je bohužel nezbytné v nějakém bodě odstřihnout
data nekompatibilní.
Dokud se tento krok neprovede, tak např. cestu, která bude tvořena
starými uzly (pouze pod CC) a zároveň novými (pouze pod ODbL), nebude
možné použít ani pod CC, ani pod ODbL.
Pokud by byla nová data dual-license ODbL+CC (což je současný přechodný
stav), tak ODbL verze bude stále "nepoužitelná", narozdíl od CC verze,
která bude kompletní. Tím pádem by se ale po právní stránce nic
nezměnilo - stále bychom byli u OSM pod CC.
Takže jediné, o čem se dá diskutovat je, zda tento krok má smysl a
jestli ODbL (+CT) ochrání databázi lépe než CC. Ale vzhledem k tomu, že
většina z nás postrádá potřebné právnické vzdělání, tak to velmi
pravděpodobně dopadne asi jako když by se slepice v kurníku začli
dohadovat o nadsvětelných neutrinech a narušení Lorentz invariance.

Petr Morávek aka Xificurk
<>

signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] OSM Inspector a stav přijetí licence

[Petr Morávek [Xificurk]]

jzvc wrote:
> Jaky zase vetve?

No přeci tyhle:
> jednoduse stavajici stav, kdo chce data pouzivat pod
> odbl, at si sam vymaze ta, ktera licenci neodpovidaji, kdo chce pouzit
> puvodni licenci, voiala .. at to tak pouzije, pripadne at si prozmenu
> smaze data pod novou licenci.
Pokud bude každý přispívat pod jinou licencí, tak ve výsledku nebude
použitelná ani jedna verze.

> Nevidim v tom absolutne zadnej problem,
> uplne stejne je licencovana spousta SW pod nekolika naprosto si
> odporujicima licencema a taky v tom neni zadnej problem.

Takže by se ti líbilo, kdyby celá databáze byla dual-license? Nebo jak
si to představuješ? To by ale tak nějak popřelo ten primární účel změny
(tj. lepší ochrana z právního hlediska).

> BTW: Jen tak pro zajimavost, podle naseho AZ muze kdokoli kdykoli
> licenci na sve vytvory zmenit => v principu muze kdokoli i expost
> prohlasit, ze nadale nesouhlasi s touhle licenci a pozadovat odstraneni
> vsech svych editaci.

Vážně? Vskutku zajímavá informace... Ale tím spíš mi přijde rozumné
opustit CC a nahradit to CT+ODbL, která se snaží data chránit i dalšími
prostředky. Jak tomu rozumím, tak odsouhlasení CT by mělo zabránit
případné "sabotáži" stylem, co jsi popsal.

Petr Morávek



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] OSM Inspector a stav přijetí licence

[Petr Morávek [Xificurk]]

Martin Mares wrote:
> Zdravím!
> 
>> http://wiki.openstreetmap.org/wiki/CS:ODbL/We_Are_Changing_The_License
>> Fakt nemá cenu to vypisovat každému zvlášť do mailu ;-)
> 
> Tato stránka nicméně neříká jednu velmi podstatnou věc, totiž že účinnost
> ODbL na dílo veřejně šířené je sporná a nikdy žádným soudem netestovaná.

To je argument, který jsem slyšel víckrát... a já bych si ho dovolil
obrátit - CC je soudem otestovaná? Na kreativních dílech asi ano
(skutečně?), ale na nějakém podobném databázovém díle jako OSM?

Ať už je to jakkoliv, tak se domnívám, že i kdyby tyto výtky byly
oprávněné, tak ODbL poskytuje ochranu alespoň na stejné úrovni jako CC.

>> Primární motivící je udělat trochu pořádek po právní stránce - viz např.
>> co psal vedle Lukáš (LM_1). Je pravda, že tohle opravdu nikoho teď
>> zrovna netrápí a trápit nebude dokud se nestane nějaký průser... v
>> podstatě jde tedy o preventivní opatření.
> 
> Jaký průser by například mohl nastat?
> 
> Jak praví staré přísloví: "Co není rozbité, neopravuj."

Třeba právě ten, že CC nefunguje na díla tohoto typu :)

> Mně samotnému změna licence nevadí (byť v ní nevidím žádnou výhodu),
> co mi vadí daleko více, je dát někomu neomezenou možnost (respektive
> omezenou jen velmi vágním způsobem) měnit licenci k mému dílu bez
> mého souhlasu. Já se tomu se skřípěním zubů přizpůsobím, ale chápu
> lidi, kterým je tento přístup proti srsti a odmítají s ním souhlasit.

Tohle je ale otázka CT, nikoliv licence... viz bod 1) z mailu od Lukáše
(LM_1).

> Vůbec ovšem nerozumím, jaký důvod vede k mazání dat uživatelů, kteří
> se změnou licence nesouhlasili. K čemu je to dobré? Vždyť by stačilo
> data v databázi patřičně označit a například je jen odfiltrovat
> z některých výstupů.

Jak bys řešil konzistenci dat mezi jednotlivými větvemi?

Petr Morávek aka Xificurk
<>

signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] OSM Inspector a stav přijetí licence

[Petr Morávek [Xificurk]]

Jan Bilak wrote:
> Zdravím,
> 
> mám několik dotazů:
> 
> 1) Změna licence má nějaké klady a nějaké zápory. Mezi zápory jistě
> patří ztráta dat z OSM map. To je celkem podstatný zápor. Otázka tedy
> zní, jaké jsou ty konkrétní podstatné klady, které mají převážit
> zápory?

http://wiki.openstreetmap.org/wiki/CS:ODbL/We_Are_Changing_The_License
http://google.com
Fakt nemá cenu to vypisovat každému zvlášť do mailu ;-)

> 3) Pokud někdo bude po rozdělení na OSM a FOSM příspívat do OSM, může
> tyto změny přebírat FOSM (po stránce licence)?

Ne.

> 4) Pokud někdo bude po rozdělení na OSM a FOSM příspívat do FORM, může
> tyto změny přebírat OSM (po stránce licence)?

Ne.

> 5) Jaké praktické důsledky změna licence má? Co někdo dříve mohl a
> nově nemůže a naopak? Myslím, že už jsem se jednou na to ptal, ale
> nedostal jasnou odpověď (z čehož jsem usoudil, že to asi není moc
> jasné nebo o tom spousta lidí neví).

Viz (1).
Primární motivící je udělat trochu pořádek po právní stránce - viz např.
co psal vedle Lukáš (LM_1). Je pravda, že tohle opravdu nikoho teď
zrovna netrápí a trápit nebude dokud se nestane nějaký průser... v
podstatě jde tedy o preventivní opatření.
Z praktického pohledu je pak nejvýraznější změna ohledně odvozených děl,
kdy někdo vezme OSM data, nějakým způsobem je vylepší (třeba něco
přidá), vykreslí a publikuje mapu. V případě CC je povinen dát výslednou
mapu k dispozici pod CC, ale už nemusí publikovat provedená vylepšení;
ODbL nařizuje praví opak, tj. mapu si dej pod licencí jakou chceš, ale
publikuj vylepšenou verzi dat.

> 6) V čem bude OSM lepší než FOSM? FOSM bude obsahovat více dat,
> protože žádná neztratí, ne?

Letmým pohledem na statistiky - především velikostí komunity, tj.
rychlostí zlepšování databáze.

Petr Morávek aka Xificurk



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] OSM Inspector a stav přijetí licence

[Petr Morávek [Xificurk]]

jzvc wrote:
> Je to totez, jako kdybych
> zacal stavet rodinej domek a v pulce stavby si vzpomel, ze vlastne
> nechci domek ale bazen, pricemz by mi ten domek staveli pribuzny gratis.

Proboha, tohle přirovnání selhává na tolika úrovních, že je nemá ani
smysl začít vyjmenovávat...


Změna licencování (jakéhokoliv projektu) _vždycky_ přináší nějaké
množství problémů, které by se jinak řešit nemusely, o tom žádná. Otázka
je, zda jsou tyhle problémy převáženy těmi pozitivními věcmi, co nová
licence přinese... A o tom můžeme debatovat hodně dlouho a jsem si
celkem jistý, že se na jedné odpovědi neshodnem, poněvadž každý si cení
různých věcí různě.

Já do OSM připsívám, protože chci pomoct vylepšit free mapová data - a
je mi srdečně jedno jestli jsou pod CC, ODbL nebo něčím jiným podobného
ražení...
Jiní lidé mají/měli pravděpodobně jinou motivaci, třeba pro ně bylo
naprosto podstatné, že data jsou pod CC licencí... já jim to neberu. A
každý má samozřejmě právo chystané změny odmítnout; a pokud si myslí, že
dokáže vytvořit lepší projekt, tak ať se do toho klidně pustí... Ale jak
psal už před časem hanoj, "Pri odchazeni nemusim preci palit mosty,
abych mohl zbudovat mesto naproti pres reku."

Petr Morávek aka Xificurk



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] OSM Inspector a stav přijetí licence

[Petr Morávek [Xificurk]]

OK, tedy shrnutí importů a lidí, kteří na nich pracovali:

1) HS-RS
- Jachym Cepicky - dodání shapefilů
- hanoj - kontrola a čištění dat (duplicity)
- Pavel Machek (pavel) - shp2osm & upload

2) UIR-ADR
- Tomáš Kolda - příprava dat
- Pavel Machek (pavel) - upload

3) UHUL WMS
- Tomáš Kolda - příprava dat
- Pavel Machek (pavel) a další uživatelé - upload

4) dibavod
- Tomáš Kolda - zpracování dat, importní skripty
- Pavel Machek (pavel) - shp2osm na části datasetů
- Pavel Machek (pavel) a další uživatelé - upload

LWG by rádo slyšela explicitní vyjádření výše uvedených lidí, že import
byl společnou prací a zúčastnění souhlasí s tím, aby data zůstala
publikovaná v OSM dokud bude pod "svobodnou a otevřenou" licencí (tj.
jedno jestli pod CC-BY-SA 2.0, ODbL 1.0, nebo jinou podobného ražení).

Jachym Cepicky se již v tomto duchu vyjádřil [1]. Chtěl bych o podobný
krok poprosit i ostatní.
Pavle, sice jsi jasně napsal, že nehodláš spolupracovat, ale chtěl bych
se zeptat - můžeme alespoň předpokládat, že nebudeš protestovat a
bojovat proti zachování dat, pokud LWG sezná, že můžou v OSM dále existovat?

Pokud se všichni účastníci importu vyjádří kladně a Pavel nebude bojovat
proti, tak LWG changesety uvedené na wiki [2] převede na jiný účet a
data budou moci být zachována i po změně licence.

Zdraví,
Petr Morávek aka Xificurk

[1]
http://lists.openstreetmap.org/pipermail/talk-cz/2011-September/006826.html
[2]
http://wiki.openstreetmap.org/wiki/Quick_History_Service/Changeset_Lists#Pavel_imports_in_Czech_Republic



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] OSM Inspector a stav přijetí licence

[Petr Morávek [Xificurk]]

jzvc wrote:
> Jenze v principu ma pravdu, protoze kvuli tyhle kravine bude znicena
> prace spousty lidi

Ale houby! Práce spousty lidí nebude zničena proto, že se mění licence,
ale proto, že pavel momentálně zaujal postoj - "chci zničit co nejvíc
dat OSM, aby lidi přešli na FOSM".
Ono, když se podíváte na statistiky, tak nebýt rozhodnutí pavla a jkjk,
tak ztráta dat je prakticky nulová... Ale mají na to rozhodnutí právo, a
zbytek komunity se holt bude muset nějak se vzniklou situací vypořádat.

Petr Morávek aka Xificurk
<>

signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] OSM Inspector a stav přijetí licence

[Petr Morávek [Xificurk]]

Petr Holub wrote:
>> (vrstva license change). Příp. trochu názorněji Cleanmap [2] - obsahuje
>> vyrenderované vrstvy pouze čistá data a také pouze data ODbL
>> nekompatibilní.
> 
> Musim rict, ze pohled na Cleanmap je pro mne docela frustrujici,
> protoze jen diky tomu, ze se v historii objevil nekdo, kdo licenci
> neprijme, zmizi i spousta me prace. Celkem mne to vede na premysleni,
> jestli do OSM jeste prispivat...
> 
> Petr

Já bych zbytečně nepředbíhal... Jednak naprostá většina momentálně
označená jako závadná je kvůli pavlovým importům a jsem celkem
optimistický, že ty importy (na kterých konec konců nepracoval jen on
sám) se zachovají. Navíc, jestli se nepletu, tak cleanmap nerozlišuje
mezi objekty, které se smažou a těmi, co se "jen" revertují do nějakého
staršího stavu - tzn. ukazuje věci v horším světle než nakonec dopadnou.

Petr Morávek aka Xificurk
<>

signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] OSM Inspector a stav přijetí licence

[Petr Morávek [Xificurk]]

Tomáš Kratina wrote:
> kdyz tu licenci nepotvrdi tak se to musi smazat, ze ? o co vsechno
> mozem eventuelne prijit ?

Existuje plugin pro josm, ktery to dokaze zobrazit (zkusenosti nemam,
pouzivam merkaartor). Dale je možnost na to mrknout v OSM Inspectoru [1]
(vrstva license change). Příp. trochu názorněji Cleanmap [2] - obsahuje
vyrenderované vrstvy pouze čistá data a také pouze data ODbL
nekompatibilní.

Petr Morávek aka Xificurk

[1] http://tools.geofabrik.de/osmi/
[2] http://cleanmap.poole.ch/
<>

signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] OSM Inspector a stav přijetí licence

[Petr Morávek [Xificurk]]

Tak už se ozvali - odpověď nebyla úplně optimistická... konečné
rozhodnutí možná bdue muset být na nějakém právníkovi :/
Co je potřeba teď:

1) Přesně popsat jak import dat probíhal - tj. kdo všechno data
upravoval a připravil pro import (a jakými nástroji). To je potřeba pro
rozhodnutí jestli si pavel může nárokovat copyright, viz:
> Can you tell me if he wrote the import scripts or used an existing program? 
> ... that might help establish the "creative" effort involved.  Also, was it 
> just him or did several people bulk import using the pavel account?

Na něco si vzpomínám, něco jsem vyčetl z wiki, prosím o doplnění/opravení:

* HS-RS - Jachym Cepicky dodal shapefily, hanoj vyfiltroval duplicity a
Pavel Machek data zkonvertoval do .osm formatu a uploadoval. [wiki]
Bylo to něco víc než shp2osm + upload?

* UHUL WMS - Tomáš Kolda připravil data v osm formátu a ty pak více lidí
(včetně pavla) importovalo.

* UIR-ADR - ???

* dibavod - Tomáš Kolda napsal skripty pro zpracování dat a připravil
data pro import rybníků, které pak importovalo více lidí (včetně pavla).
Vodní toky pomocí těch skriptů připravil a uploadnul pavel.


2) Padl dotaz na jkjk (2. největší přispěvatel v ČR odmítající ODbL),
jestli by pomohlo kdyby mu napsali osobně, nebo je podobně jako pavel
utvrzený ve svém "ne". Máte někdo tušení jestli se ještě někde okolo OSM
vyskytuje? Nedělal také některé importy podobně jako pavel?


Petr Morávek aka Xificurk



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] OSM Inspector a stav přijetí licence

[Petr Morávek [Xificurk]]

hanoj wrote:
> Dne 23. ledna 2012 12:31 "Petr Morávek [Xificurk]"
>  napsal(a):
>> Pavel Machek wrote:
>>>> 2. You could talk to LWG and ask them to investigate the situation; if
>>>> they say "yep, these edits can be kept even if pavel is against it" then
>>>> the data is safe and I could mark it as such on OSMI. But this might
>>>> take a while.
>>>
>>> Please do this.
>>>
>>>   Pavel
> 
>> už někdo zkoušel psát LWG, nebo tohle zamrzlo z důvodu chybějícího
>> dobrovolníka, který by oslovil LWG?
> 
> *** myslim ze tak nikdo neucinil.

OK, napíšu jim a dám vědět výsledek...

btw, při psaní dotazu jsem si všiml, že jsi na wiki uvedl i changeset
473203, což byl import sídel - tam byla mezi zdroji mj. Wikipedia, takže
to kompatibilní s ODbL není. Teď už by stejně naprostá většina těch uzlů
měla být nahrazena importem UIR-ZSJ, takže jsem tento changeset ze
seznamu [1] odstranil.

Petr Morávek aka Xificurk

[1]
http://wiki.openstreetmap.org/wiki/Quick_History_Service/Changeset_Lists#Pavel_imports_in_Czech_Republic
<>

signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] OSM Inspector a stav přijetí licence

[Petr Morávek [Xificurk]]

Pavel Machek wrote:
>> 2. You could talk to LWG and ask them to investigate the situation; if  
>> they say "yep, these edits can be kept even if pavel is against it" then  
>> the data is safe and I could mark it as such on OSMI. But this might  
>> take a while.
> 
> Please do this.
> 
>   Pavel

Zdar,
už někdo zkoušel psát LWG, nebo tohle zamrzlo z důvodu chybějícího
dobrovolníka, který by oslovil LWG?

Petr Morávek aka Xificurk



signature.asc
Description: OpenPGP digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz