Re: [Talk-cz] Aplikace pro pořizování základních dat v terénu

[LM_1]

Já pro záznamy používám Maverick - umí pro offline použití uchovat více
různých renderů mapy, jednoduché ovládání, možnost POI. Místo poznámek
raději fotky se zeměpisnými souřadnicemi.
LM

Dne 4. března 2016 8:54 Marián Kyral  napsal(a):

> OsmAnd mám nainstalovaný, ale vykreslování mi, i po všech těch
> optimalizacích, stále přijde dost pomalé. Hlavně když si člověk zapne
> vrstevnice a stínování kopců.
>
> Většinu času používám GDAK (aplikace na geocaching), který má rychlejší
> vykreslování (asi toho nevykresluje tolik) v kombinaci s maps.me a mapy.cz.
> To mi bohatě stačí. Navigaci téměř nepoužívám, většinou mi stačí před
> cestou mrknout na mapu a použít manželku s autoatlasem jako zálohu :-D
>
> Na poznámky z mapování používám osmtracker. Zabudovanou podporu OSM v
> OsmAnd jsem zkoušel, ale přijde mi rychlejší udělat si krátkou textovou
> poznámku nebo uložit fotku a následně to zpracovat doma v editoru než v
> terénu vyplňovat data o POI přes dotykovou klávesnici.
>
> Marián
>
>
> -- Původní zpráva --
> Od: Jan Breuer 
> Komu: OpenStreetMap Czech Republic 
> Datum: 3. 3. 2016 18:40:39
> Předmět: Re: [Talk-cz] Aplikace pro pořizování základních dat v terénu
>
> Ahoj,
> ještě tu nikdo nezmínil OsmAnd. Máte k němu nějakou averzi? Všichni
> preferujete Locus. Před x lety jsem si koupil Locus Pro, pak ještě chvíli
> používal a pak mě tam pořád chyběla spousta funkcí, které autor sliboval že
> udělá, že jsem to nakonec odinstaloval. Teď po dlouhé době jsem si ho zas
> nainstaloval, zjistil že to pořád umí to stejné co předtím, jen hůř. Jen
> abych to vůbec mohl používat, tak si musím pořídit Locus dolary a vše ještě
> extra dokupovat. Chválím tedy jen parádní a rozsáhlou dokumentaci a
> jednoduché ovládání základních funkcí a opět odinstalovávám.
>
> Zpět k OsmAnd
> Z toho co bylo požadováno umí:
>  - záznam trasy
>  - přidávání bodů do trasy, pořizování fotek
>  - export do gpx nebo přímo na osm.org
>  - umí i nějaké užší navázání na OSM, ale to jsem nikdy nepoužíval
>  - mapové podklady offline včetně vyhledávání, navigace, různá témata mapy
>
> Co neumí:
>  - jiné než OSM mapy
>  - práci s externí GPS
>
> Honza
>
> Dne 3. března 2016 18:15 Jakub Konečný  napsal(a):
>
> Locus má výbornou knowledge base. O exportu se píše tady
> http://docs.locusmap.eu/doku.php?id=manual:user_guide:tracks:export a
> pokud chceš automatický export, tak ho lze nastavit v profilu záznamu
>
> http://docs.locusmap.eu/doku.php?id=manual:user_guide:tracks:recording:profiles_settings
>
> Já mám třeba profil pojmenovaný OSM s častější frekvencí ukládání bodů
> a právě automatickým exportem.
>
> Další užitečná věc, co v Locusu používám a souvisí s OSM je, že umí
> přidávat rychlý waypoint s fotkou (několika fotkami) a tuhle funkci
> mám připlou na postranním panelu v Locusu
> (http://docs.locusmap.eu/doku.php?id=manual:user_guide:functions:panel)
> - dobré na focení rozcestníků a všeho možného. Taky se mi líbí, že má
> pěkné vestavěné turistické téma.
>
> Kuba
>
> Dne 3. března 2016 17:58 Tom Ka  napsal(a):
> > Dne 3. března 2016 15:35 Jakub Konečný  napsal(a):
> >> A když se tady řešila jednoduchost exportu do OSM, tak Locus to umí i
> >> automaticky při ukončení záznamu trasy, tzn. bez jediného kliknutí,
> >
> > mas nekde odkaz na manual kde se o tom mluvi, to by mne zajimalo?
> >
> >> ale to už myslím chce placenou verzi. Je docela drahá, ale párkrát do
> >> roka bývá v akci kolem 100 Kč.
> > vyplati se, zas takova palka to neni a je to vyborny SW.
> >
> > Diky
> >
> > ___
> > Talk-cz mailing list
> > Talk-cz@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-cz
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Znakové klíče

[LM_1]

To, že je něco na uložto ještě neznamená, že je to licenčně v pořádku.
Použít podobné barvy by problém být neměl, u sady symbolů by mohla do hry
vstoupit práva k databázi.
LM

Dne 19. ledna 2016 0:00 Mikoláš Štrajt  napsal(a):

> > Viz
> > https://lists.openstreetmap.org/pipermail/talk-cz/2015-June/012003.html
> 
> > AZ chrání u kartografického díla *především* grafickou podobu. IANAL ale
> pokud se volně inspiruješ a použiješ
> > podobné klíče, tak je to OK (ona např. ikona pro jeskyni bude mít asi
> vždy trochu kulatý tvar přimoníjící díru),
>
> (jde mi hlavně o barevná schémata, ono vyladit barevné schéma, aby mělo
> kontrast a nebolely z něj oči je věda)
>
> > kopii 1:1 bez
> > svolení samozřejmě nesmíš.
>
> jasně... ta filosofie je z dob, kdy kopírování map přicházelo v úvahu
> především (poly)grafickou cestou...
>
> > Jinak ptal jsem se na tuto problematiku jedno právníka a jednoho soudce
> a odpověď byla, že tyhle případy jsou
> > vysoce
> > individuální a spravně by ti to měl posoudit právník kus od kusu a i
> jeho rada je taková naprd a v reálu by to u soudu
> > mohlo dopadnout úplně jinak.
>
> jinak koukal jsem na tu vojenskou topografickou mapu:
>
> to by zrovna mohla být u soudu zajímavá věc, protože má „krutou“ licenci
> (verze z http://geoportal.gov.cz):
>
> > Jen pro pořeby resortu Ministerstva životního prostředí, neposkytovat
> třetím osobám, zákaz komerčního šíření, nesmí opustit území ČR
>
> tudíž kdybych udělal napodobující vrstvu a přidal ukázku originálu, mohl
> by to teoreticky být celkem průšvih
>
> (prakticky asi ne, starší verzi té mapy lze stáhnout bez řečí z ulož.to
> )
>
> --
> Mikoláš Štrajt
> (Severák)
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

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

[LM_1]

Jestli to vyhledávání funguje vždy od začátku bloku s mezerou (u jmen to
tak je, nevím jak u čísel) tak by ideální bylo ev. 3 (líp vypadá, dokonce
jsem ho i viděl na cedulkách, fungovalo by hledání)
Lukáš Matějka (LM_1)


Dne 26. září 2013 18:02 Nejedli p...@nejedli.cz napsal(a):

 Hmm, když jsem bydlel v domě s evidenčním číslem, na poště mi řekli, že
 mám do adresy psát E8, ale myslím, že jsem většinou používal 8 e.

 A jestli si to dobře pamatuji, narazil jsem na web, co mě nenechal do
 kolonky číslo napsat E8, ale 8 e fungovalo.

 8 e, popř. 8E by se dobře renderovalo a hledalo, ale zas by to trochu
 kolidovalo s vchodem E paneláku č.p. 8


  Sent from my BlackBerry 10 smartphone.
   *From: *Karel Volný
 *Sent: *Thursday, September 26, 2013 5:29 AM
 *To: *OpenStreetMap Czech Republic
 *Reply To: *OpenStreetMap Czech Republic
 *Subject: *Re: [Talk-cz]číslo evidenční v addr:housenumber



 ehm, pár poznámek, mám pocit, že poněkud uniká původní pointa ...

 1) nemluvím o obsahu addr:provisionalnumber ale o tagu addr:housenumber

 dávat do prvního cokoli mimo čísla je blbost, protože to, že jde o číslo
 evidenční je jasně určeno již názvem a definicí tagu

 2) diskuse není o (nebylo mým cílem diskutovat o) tom, jestli prefixem v
 addr:housenumber má být E nebo 0 nebo ev. č., nýbrž jestli tam vůbec
 nějaký prefix musí být

 chápu snahu reflektovat realitu a mít tam přesně to, co je na domě na
 tabulce,
 ale činí to potom problémy při dalším zpracování (např. to zmíněné
 vyhledávání), neboť vzhledem k odlišnosti zvyklostí nelze bez místní
 znalosti
 předem odhadnout, co tam vlastně má být

 navíc používání prefixu v případě čísla evidenčního není konsistentní s
 doporučením pro číslo popisné a orientační, kde se nepoužívá

 jinými slovy, když dostanu adresu ve stylu Horní Dolní 3, bylo by
 skvělé,
 kdyby mi vyhledávání vyhodilo všechny tři baráky, pro které je to
 relevantní,
 tj.

 a) Horní Dolní ev. č. 3
 b) Horní Dolní č.p. 3 / č.o. 5
 c) Horní Dolní č.p. 1 / č.o. 3

 momentální situace je taková, že a) se nematchne protože 3 neodpovídá
 začátku E3

 můžeme se sice hádat, že jde o chybu vyhledávače, že nevyhledává
 podřetězec od
 libovolné pozice, na druhou stranu ale zase nestojím o to, aby mě to
 zahltilo
 i domy číslo 13, 23 ...

 nalezení a) můžeme pomoci tak, že se na prefix E prostě vykašleme a
 nebudeme
 ho tam dávat ...

 K.

 Dne St 25. září 2013 18:36:41, Dalibor Jelínek napsal(a):
  No jo, ale kdyz se podivas na Wikipedii, tak uvidis, ze se tam taky dava:
  nula
  ev.
  evidenční
  Zajimavý je, že ja osobně jsem viděl všechny tam vyobrazené varianty,
 kromě
  právě toho samotného E (asi nějaké krajové špecifikum). Proto se mi
 volba E
  libí nejméně a navíc není moc samovysvětlující. ev. se mi líbí víc. ev.č.
  je ješte lepší, ale psát před číslo, že je to číslo, mi už zas připadá
  trochu moc.
 
  Dalibor
 
  Sent from my HTC
 
  - Reply message -
  From: Tomáš Tichý t.ti...@post.cz
  To: OpenStreetMap Czech Republic talk-cz@openstreetmap.org
  Subject: [Talk-cz]číslo evidenční v addr:housenumber
  Date: Wed, Sep 25, 2013 16:51
 
  E se tam dává, protože bývá na tabulkách na domech.
  TT
  Dne 25. 9. 2013 15:16 Dalibor Jelínek dali...@dalibor.cz napsal(a):
  Čau,
 
  už jsem se tady na něco o čísle evidenčním před nějakou dobou ptal, ale
 bez
 
  odezvy.
 
  I mě přijde ta konvence s E hloupá, hlavně proto, že se mi zdá, že ji
 
  málokdo dodržuje.
 
  Docela by mě zajímalo, kdyby někdo uměl vytáhnout statistiku z
 
  ProvisionalNumber
 
  pro ČR, jaké by bylo rozložení tvarů. Myslím, že se používá ev. N,
 ev.č.
 
  N, EN, ale nevím jak moc která varianta.
 
  Viděl bych jako vhodné se domluvit na jednom tvaru a pak to dávkou změnit
 
  všude,
 
  což by mělo být lehké (si myslím, ale neumím to).
 
 
 
  Ale jsem proti tomu tam nedávat žádný prefix. Myslím, že většina map
 
  zobrazuje
 
  prostě HouseNumber a na ProvisionalNumber kašle. Pak by vznikal pro
 
  uživatele spíše chaos.
 
  Hlasoval bych za tvar ev. NNN.
 
 
 
  Zdraví,
 
  Dalibor
 
 
 
  -Original Message-
 
  From: Karel Volný [mailto:ka...@seznam.cz]
 
  Sent: Wednesday, September 25, 2013 1:57 PM
 
  To: 'OpenStreetMap Czech Republic'
 
  Subject: [Talk-cz] číslo evidenční v addr:housenumber
 
 
 
 
 
  zdar,
 
 
 
  teď jsem si otagoval jeden areál s číslem evidenčním podle
 
 
 http://wiki.openstreetmap.org/wiki/Cs:WikiProject_Czech_Republic/Address_sys
 
  tem#Kl.C3.AD.C4.8D_housenumber
 
 
 
  a zjistil jsem, že vyhledávání (Nominatim) mi to jako běžně zadanou
 adresu
 
  nenajde ... přitom chudák uživatel, když někde na webu najde adresu, tak
 se
 
  dost často nedozví, o jaké číslo jde, jestli
 popisné/orientační/evidenční, a
 
  i když se to dozví, tak asi nezná tuto konvenci, že před číslo evidenční
 má
 
  dát velké E
 
 
 
  nevím, jestli existuje nějaký feature request, aby se to číslo
 vyhledávalo
 
  jako podřetězec, nicméně jako účelnější by se mi jevilo změnit
 doporučení na
 
  tagování a to E

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

[LM_1]

S editorem to nemá sž tak mos společného, stačí když jsou změny nahrané v
jednom changesetu, takže například když na opačných stranách Zeměkoule
stáhnu a upravím oblasti o rozloze několika metrů vznikne tento nesmysl.

Zkus třeba http://owl.openstreetmap.org/ - tam už se zobrazjí změny podle
oblasti a ne podle boundingboxu changesetu.
Lukáš Matějka (LM_1)


Dne 17. července 2013 12:57 Petr Stehlik psteh...@sophics.cz napsal(a):

 Ahoj,

 ještě jeden základní dotaz (možná FAQ, nevím): když se chci podívat na
 historii změn nějaké konkrétní ulice či chodníčku (na
 osm.org/browse/changesets), vyskáčí na mě stovky či tisíce změn všeho
 možného po celém světě, co se mého místa, na které se zrovna dívám,
 naprosto nijak netýká - až na to, že ten panáček, co editoval jakousi
 zatáčku na Jakartě, nebo ten mimoň, co upravoval kostelík uprostřed
 jižní Afriky, z nějakého důvodu editovali v obdélníku desetitisíce
 kilometrů krát desetitisíce kilometrů, takže prý zasáhli i tu oblast na
 Valašsku, kterou se snažím analyzovat.

 Dá se s tímto něco dělat? Vyfiltrovat tu historii tak, aby ukazovala jen
 skutečné změny v oblasti, která mě zajímá? Zastřelit autory editorů,
 které dovolují editovat tak velké oblasti?

 Díky,

 Petr

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

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

Re: [Talk-cz] jmena cest jako relace

[LM_1]

Jsem pro všema deseti


2013/6/7 Petr Holub ho...@ics.muni.cz

 Ahoj,

 uz to tady problesklo pri diskusi u znamek a podobnych veci - co kdybychom
 do standardu pro CZ zanesli moznost pojmenovavani ulic a cest obecne pomoci
 relaci? V tomto smeru uz v OSM existuji minimalne dve (! :( ) relace k tomu
 urcene:
 http://wiki.openstreetmap.org/wiki/Relation:associatedStreet
 http://wiki.openstreetmap.org/wiki/Relation:street
 plus obdobna vec existuje i pro waterway
 http://wiki.openstreetmap.org/wiki/Relation:waterway

 Petr


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

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

Re: [Talk-cz] Společné hranice ploch

[LM_1]

Dělení velkých multipolygonů (JOSM+relation toolbox):
- Nakreslím hranici, v místech, kde končí (dotýká se hranic stávajícího
multipolygonu) rozdělit cesty, pokud už nejsou - původní multipolygon je
buď stejný, nebo se uvnitř něk rozdělily cesty ale pořád funguje jako
předtím.
- Vyberu si, jednu ze dvou nových oblastí - tu která zůstane v současném
multipolygonu.
Postupně klikám na úseky které nejsou hranicí této oblasti a na [-] -
odstraním je z relace, stejně tak vyberu novou hranici a kliknu na [+] -
přidám novou hranici. Ve vlastnostech původní relace nechám seřadit úseky
za sebou - měl by se ukázat uzavřený ovál přes všechny úseky.
- Vyberu všechny úseky / hranice nově vytvářeného multipolygonu a kliknu na
[multipolygon] v toolboxu - vytvoří se nový multipolygon, na něj přidám
tagy podle potřeby.

Jestli to stále zní složitě tak zkusím udělat návod s obrázkama.
LM


Dne 24. května 2013 12:50 Zdeněk Pražák zpra...@seznam.cz napsal(a):

 No zde se řeší vytváření relací multi polygonů
 ale mne více trápí případ pro rozdělení polygonu na multipolygon s
 vniřními polygony, například když chci rozdelit polygon lesa na část
 tvořenou smíšeným lesem, část tvořenou jehličnatým lesem, ve kterém bude
 rybník, případně mýtina či louka.
 Pokud se bude jednat o malý objekt tak to v JOSM nakreslím snadno, horší
 je to v případě většího lesa již vytvořeného jako multipolygon - zde se mi
 mnohdy stane přestože používám editor relací v JOSM, že výsledek se nějak
 zamotá a musím jej smazat.
 Existuje nějaký jednoduchý postup na dělení velkých multipolygonů?
 Pražák


 Dne 24. května 2013 10:41 jan lana lana@gmail.com napsal(a):

 Dne 24. května 2013 9:15 Milan Vancura mi...@ucw.cz napsal(a):

 On Fri 24-05-13 07:33:13, Pavel Moravec wrote:
  multipolygon potřebuje uzavřené křivky, nebo ne?
  Kupodivu nepotrebuje, jen je treba seradit useky cest za sebou tak,
  aby tu uzavrenou krivku tvorily (a velka cast rendereru si to umi

 On Fri 24-05-13 07:11:57, LM_1 wrote:
  Multipolygon právě umožňuje udělat oblast z různých, rozdělených
 úseků. Já
  bych to udělal takto:
  první cesta: e--f--a--b--c (žádný tag kromě source)
  druhá cesta: c--d--e (plot, source)
  multipolygon obsahující obě cesty (les)

 Díky vám oběma, zase vím něco víc. Takže ta část relace pro trasu linky
 MHD,
 kde jsou cesty, je vlastně něco podobného (cesty seřazené za sebou).
 A teď ještě jakou to má výhodu oproti tomu znovupoužití bodů? Že je to
 mnohem
 univerzálnější princip?


 kreslit s pomoci relaci je (mozna) pracnejsi, ale mnohem lepe se pak
 edituje - kdyz mam napriklad nakreslit les a pole vedle sebe


   a---b---c---d---e
   | Pole  | Les   |
   |   f---g
   |   |
   h---i

 Bez relaci to lze namalovat jako dve cesty

 C1: a-b-c-f-i-h-a (tag source,pole)
 C2: a-d-e-g-f-c (tag source, les)

 Kdyz to maluji jako relaci, nejdriv vyrobim tri cesty

 E1: c-b-a-h-i-f (tag source)
 E2: c-f (tag source)
 E3: c-d-e-g-f   (tag source)

 (ve skutecnosit v JOSM namaluju C1, pak vyberu body c a f a dam split a
 pak namaluju E3, takze to jde stejne rychle)

 a pak udelate dva multipolygony

 M1: C1+C2 (tag pole)
 M2: C2+C3 (tag les)

 Vysledek je stejny.

 Ale kdyz treba chcete zpresnit hranici c--f (protoze to puvodne bylo
 treba moc hrube), tak ve variante s relacemi jen pridame par bodu do cesty

 E2': c-x-y-z-f

  a je hotovo. U varianty bez relaci to znamena ... no, vlastne nevim,
 asi pridat ty body do C1 a pak nejak pridat ty stejne body i do C2.

 Vychytavka JOSM je v tom, ze kdyz rozdelite cestu, tak automaticky upravi
 vsechny relace ktere tu cestu obsahuji, takze kdyz si pak treba vsimnu, ze
 v bode f je rybnicek, tak jen rozdelim

 E1 v bode i na E1a a E1b
 E3 v bode g, na E3a a E3b

 namaluju cestu

 E4: i-g (tag source)

 a vyrobim multipolygon

 M3: E1a+E3a+E4 (tag rybnik)

 (s temi vsemi pismenky a indexy to vypada slozite, ale v JOSM je to jen
 par kliku, zkuste si to).

 - Jenda



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



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


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

Re: [Talk-cz] Společné hranice ploch

[LM_1]

Přiznám se, že jsem to nikdy nezkoušel, ale není ten problém s exportem
ploch v tom, že je tolik způsobů jejich reprezentace?
- uzavřená cesta s typickým tagam pro oblast
- uzavřená plocha s typickým liniovým tagem a area=yes
- multipolygon
- ...?

LM_1


Dne 23. května 2013 8:50 hanoj eha...@gmail.com napsal(a):

  Někdo by mohl nesouhlasit, ale podle mě: na hranici mezi loukou a lesem
 jen
  jedna cesta (way) s tagem source, případně plotem nebo jinou fyzickou
  hranicí apod., která je členem dvou multipolygonů - jednoho pro les,
 jednoho
  pro louku, na kterých jsou všechny příslušné tagy. Více čar přes sebe
 (byť
  se stejnými body) obvykle komplikuje editaci.
 *** Já se také snažím vyhýbat multipolygonům. Datový model by měl být
 služka ne pán a multipolygon je nyní často pánem. Někdy je použití
 naopak vhodné, jako je dnešní administrativní členění územních celků.
 Je zajímavé, že dodnes, díky multipolygonům, nelze z OSM rozumně
 exportovat plochy, což považuji za velký handicap.

 Je zajímavé, že běžně užívané datové modely v GIS naše úsporné
 problémy neřeší,



 prostě každá plocha má nejen svou hranu na hranici,
 ale také své lomové body.

Tomu nerozumím, ocenil bych vysvětlení.


 Tedy ten luxus v OSM, že nody jsou jen
 jednou v běžných formátech GIS neznám. (Aby nedocházelo ke smyčkám a
 překryvům při editaci může fungovat nadstavba mezi uživatelem a
 modelem, která to neumožní.) Přesto formáty GIS zpravidla umožňují
 definovat polygonu exklávu nebo enklávu.

 hranice polygonů v GIS (ESRI Shapefile):
 a-b-c-d
 g-h-i-j

 hranice polygonů v OSM bez relací:
 a-b-c-d
 a-b-c-d

 hranice polygonů v OSM s relací:
 a-b-c-d + rel1 +rel2


 ha
 hanoj

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

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

Re: [Talk-cz] Společné hranice ploch

[LM_1]

Zrovna v případě silnic/řek apod. základní pravidlo existuje - jeden objekt
v realitě - jeden objekt v osm. Z toho by vyplývalo, že v osm by měl být
jen jeden objekt s ref=D1 a to by nutně byla relace, proti kterým existuje
značný (pro mě nepochopitelný) odpor.
Stejně tak u školy bych tyto informace dával do relace - je to
univerzálnější v případě, že škola má víc budov/hřišť/celý areál, zároveň
funguje i pro jednodomkovou vesnickou školu.
LM_1


Dne 23. května 2013 14:07 jzvc j...@tpfree.net napsal(a):

  Dne 23.5.2013 10:48, LM_1 napsal(a):

 Přiznám se, že jsem to nikdy nezkoušel, ale není ten problém s exportem
 ploch v tom, že je tolik způsobů jejich reprezentace?
 - uzavřená cesta s typickým tagam pro oblast
 - uzavřená plocha s typickým liniovým tagem a area=yes
 - multipolygon
 - ...?


 To spolu souvisi ;D, a je to zcela obecnej problem OSM, nejen problem
 ploch. Jen si bohuzel moc nedokazu predstavit zpusob, jak to vyresit. Tech
 problemu je samo vic ... trebas vazby virtualnich prvku na realny (hranice
 vs silnice, silnice vs jeji oznaceni ...). Vem si, ze mas klasickou
 dvouprodouvou dalnici ... vetsinou se to kresli jako dve silnice ... a
 vetsinou se to dava do relace ...

 A ted ... das oznaceni (ref=..D1...) na ty cesty nebo az do relace? = je
 to jak kde a jak kdy a je to cim dal horsi, cim vic ruznych prvku se v mape
 objevuje. A samo, nekdy reneder bere info z relace v potaz, nekdy ne ...
 pro priklad, mam tu budovu skoly, a vedle druhou budovu, ktera je jako
 moltipolygon. V prvnim pripade jsou tagy primo na ceste = renederuje se
 jako skola, ve druhym jsou na relaci = renederuje se jako obyc barak ...

 Potiz vidim v tom, ze jaksi neexistuje ani nejaky zakladni desatero co kam
 patri.


  LM_1


 Dne 23. května 2013 8:50 hanoj eha...@gmail.com napsal(a):

  Někdo by mohl nesouhlasit, ale podle mě: na hranici mezi loukou a lesem
 jen
  jedna cesta (way) s tagem source, případně plotem nebo jinou fyzickou
  hranicí apod., která je členem dvou multipolygonů - jednoho pro les,
 jednoho
  pro louku, na kterých jsou všechny příslušné tagy. Více čar přes sebe
 (byť
  se stejnými body) obvykle komplikuje editaci.
  *** Já se také snažím vyhýbat multipolygonům. Datový model by měl být
 služka ne pán a multipolygon je nyní často pánem. Někdy je použití
 naopak vhodné, jako je dnešní administrativní členění územních celků.
 Je zajímavé, že dodnes, díky multipolygonům, nelze z OSM rozumně
 exportovat plochy, což považuji za velký handicap.

 Je zajímavé, že běžně užívané datové modely v GIS naše úsporné
 problémy neřeší,



 prostě každá plocha má nejen svou hranu na hranici,
 ale také své lomové body.

 Tomu nerozumím, ocenil bych vysvětlení.


 Tedy ten luxus v OSM, že nody jsou jen
 jednou v běžných formátech GIS neznám. (Aby nedocházelo ke smyčkám a
 překryvům při editaci může fungovat nadstavba mezi uživatelem a
 modelem, která to neumožní.) Přesto formáty GIS zpravidla umožňují
 definovat polygonu exklávu nebo enklávu.

 hranice polygonů v GIS (ESRI Shapefile):
 a-b-c-d
 g-h-i-j

 hranice polygonů v OSM bez relací:
 a-b-c-d
 a-b-c-d

 hranice polygonů v OSM s relací:
 a-b-c-d + rel1 +rel2


 ha
 hanoj

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




 ___
 Talk-cz mailing 
 listTalk-cz@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-cz



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


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

Re: [Talk-cz] Společné hranice ploch

[LM_1]

Dne 23. května 2013 15:24 Milan Vancura mi...@ucw.cz napsal(a):

 On Thu 23-05-13 14:51:46, LM_1 wrote:
  Zrovna v případě silnic/řek apod. základní pravidlo existuje - jeden
 objekt
  v realitě - jeden objekt v osm. Z toho by vyplývalo, že v osm by měl být
  jen jeden objekt s ref=D1 a to by nutně byla relace, proti kterým
 existuje
  značný (pro mě nepochopitelný) odpor.
  Stejně tak u školy bych tyto informace dával do relace - je to
  univerzálnější v případě, že škola má víc budov/hřišť/celý areál, zároveň
  funguje i pro jednodomkovou vesnickou školu.

 Problém je, že pak bys musel zavést pravidlo, že (téměř) všechno je až v
 relacích. Proč by škola měla být výjimkou? Navíc to dává už teď v mnoha
 jiných
 případech dobrý smysl.


Kdyby to bylo jen na mě tak bych ho zavedl.


 Např. ulice. Dnes jsou tak rozkouskované, mimo jiné kvůli (zase jiným)
 relacím,
 že u mnoha ulic už neexistuje jeden objekt ulice, který by ji obsahoval
 celou. Pak z toho plynou různé problémy. Nejsnáz/okamžitě je to vidět
 třeba na
 popiscích v mapě, jak jsou často nelogicky a hustě v místech, kde by je
 člověk
 v mapě fakt nečekal a nechtěl. Např. na mostě či v tunelu. Proč tam jsou?
 Protože ten úsek (např. v tunelu) je samostatný objekt, a to se jménem.


 Relace = přítel člověka


 Ale to by bylo nových relací... A úplně nová pravidla pro editaci OSM. A
 asi
 sousta feature requestů na JOSM, protože aspoň mně teda přijde, že editovat
 relace (zkoušel jsem pražskou MHD) je za trest.


Používám toto
http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Relation_Toolbox a relace
jsou za odměnu. :-)


 Milan

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

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

Re: [Talk-cz] Společné hranice ploch

[LM_1]

@hanoj:
...každá plocha má nejen svou hranu na hranici, ale také své lomové body.
Má tento výrok ještě jiný význam, než že hranice mezi dvěma objekty není
vždy rovná čára, ale někdy i lomená? Jestli ne, je všechno jasné.
LM_1

Dne 23. května 2013 15:04 hanoj eha...@gmail.com napsal(a):

  Přiznám se, že jsem to nikdy nezkoušel, ale není ten problém s exportem
  ploch v tom, že je tolik způsobů jejich reprezentace?
  -1 uzavřená cesta s typickým tagam pro oblast
  -2 uzavřená plocha s typickým liniovým tagem a area=yes
  -3 multipolygon
  - ...?
 *** ano, exportovat variantu -1 případně -2 není problém. Multipolygon
 už není jen o změně zápisu přes nějaké API ale o celkové
 přeformulování formy objektu.

  Je zajímavé, že běžně užívané datové modely v GIS naše úsporné
  problémy neřeší,
  prostě každá plocha má nejen svou hranu na hranici,
  ale také své lomové body.
 
  Tomu nerozumím, ocenil bych vysvětlení.
 *** viz srovnání níže

 hranice dvou polygonů v GIS (ESRI Shapefile):
 a-b-c-d
 g-h-i-j

 hranice dvou polygonů v OSM bez relací:
 a-b-c-d
 a-b-c-d

 hranice dvou polygonů v OSM s relací:
 a-b-c-d + rel1 +rel2

 ha
 hanoj

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

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

Re: [Talk-cz] Společné hranice ploch

[LM_1]

Už je mi to jasné. :)


Dne 23. května 2013 17:02 hanoj eha...@gmail.com napsal(a):

 ...každá plocha má nejen svou hranu na hranici, ale také své lomové
 body.
  Má tento výrok ještě jiný význam, než že hranice mezi dvěma objekty není
  vždy rovná čára, ale někdy i lomená? Jestli ne, je všechno jasné.
 *** Nerozumím otázce ;)
 *** Dva sousedíci polygony mají společnou společnou hranici (tj.
 dotýkají se v úsečkách). Pak v datovém modelu:
 * v GIS má každý polygon své originální lomové body (respektivé své hrany)
 * v OSM má každý polygon svou hranu po společných bodech
 * v OSM s relací má každý polygon společnou hranu i body

 ha
 hanoj

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

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

Re: [Talk-cz] Společné hranice ploch

[LM_1]

Body se neduplikují a více cest vedoucích jedním bodem se u průběžných
hranic používá docela v hojné míře.
V případě oploceného lesa bych nakreslil jen plot a použil ho pro
multipolygon lesa v roli outer (stejně jako případnou sousedící louku) - o
tom jestli to tak má být je podstatná část předchozí diskuse.
LM_1


Dne 23. května 2013 17:07 Milan Vancura mi...@ucw.cz napsal(a):

 On Thu 23-05-13 17:02:12, hanoj wrote:
  ...každá plocha má nejen svou hranu na hranici, ale také své lomové
 body.
   Má tento výrok ještě jiný význam, než že hranice mezi dvěma objekty
 není
   vždy rovná čára, ale někdy i lomená? Jestli ne, je všechno jasné.
  *** Nerozumím otázce ;)
  *** Dva sousedíci polygony mají společnou společnou hranici (tj.
  dotýkají se v úsečkách). Pak v datovém modelu:
  * v GIS má každý polygon své originální lomové body (respektivé své
 hrany)
  * v OSM má každý polygon svou hranu po společných bodech
  * v OSM s relací má každý polygon společnou hranu i body

 Jo, tohle jsem nepochopil, jak se to v praxi používá. Např. když kolem
 části
 lesa vede plot, můžu použít stejné body a obtáhnout část jeho hranice
 novou
 cestou barrier=fence nebo musím duplikovat body? Minimálně u budov mi
 přijde,
 že se body duplikují a faktu, že bod může být součástí více cest, se
 nevyužívá.

 Milan

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

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

Re: [Talk-cz] Společné hranice ploch

[LM_1]

Multipolygon právě umožňuje udělat oblast z různých, rozdělených úseků. Já
bych to udělal takto:
první cesta: e--f--a--b--c (žádný tag kromě source)
druhá cesta: c--d--e (plot, source)
multipolygon obsahující obě cesty (les)
LM


Dne 24. května 2013 0:18 Milan Vancura mi...@ucw.cz napsal(a):

 On Thu 23-05-13 20:31:59, LM_1 wrote:
  Body se neduplikují a více cest vedoucích jedním bodem se u průběžných
  hranic používá docela v hojné míře.
  V případě oploceného lesa bych nakreslil jen plot a použil ho pro
  multipolygon lesa v roli outer (stejně jako případnou sousedící louku) -
 o
  tom jestli to tak má být je podstatná část předchozí diskuse.

 Teda nechci se hádat, ale tohle mám pocit nemůže technicky projít. Asi
 jsme si
 nerozuměli, klíčové bylo, že ten plot NEjde kolem celého lesa, čili zatímco
 hranice lesa je uzavřená křivka a--b--c--d--e--f--a, tak plot je např.
 c--d--e
 a jinde není pro jednoduchost vůbec nic (sousedícího). Podle mě relace typu
 multipolygon potřebuje uzavřené křivky, nebo ne?

 Takže s mmi dnešními znalostmi bych to řešil tak, že bych zavedl body a,
 b, c,
 d, e a f, pak vyrobil první cestu a--b--c--d--e--f--a a otagoval bych jí
 jako
 les a naposledy druhou cestu, neuzavřenou, c--d--e a otagoval bych ji jako
 plot. A tto je ta otázka, co mě zajímá: děláte to také tak? :-)
 Nebo se dokonce pletu a jdou na to nějak napasovat ty multipolygony?

 Milan

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

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

Re: [Talk-cz] Společné hranice ploch

[LM_1]

Kromě toho, že ve skutečnosti existuje jen jedna hranice a proto není důvod
aby jich v datech bylo víc:


Dne 22. května 2013 12:49 jzvc j...@tpfree.net napsal(a):

  Dne 22.5.2013 10:17, LM_1 napsal(a):

 Někdo by mohl nesouhlasit, ale podle mě: na hranici mezi loukou a lesem
 jen jedna cesta (way) s tagem source, případně plotem nebo jinou fyzickou
 hranicí apod., která je členem dvou multipolygonů - jednoho pro les,
 jednoho pro louku, na kterých jsou všechny příslušné tagy. Více čar přes
 sebe (byť se stejnými body) obvykle komplikuje editaci.
 Lukáš Matějka (LM_1)


 Potiz je, ze na to musis vyrabet relace a s relacema se ani pres veskerou
 snahu nepracuje zrovna nativne a pohodlne. Viz budovy, kdyz mas dve vedle
 sebe, tak mezi nima je nejspis jedna zed ne dve ... presto se budovy kresli
 tak, ze maji soubezne hranicni cesty. Stejne se pak kresli drtiva vetsina
 ploch, a do relaci se to dava spis vyjimecne - tam kde to ma nejaky zcela
 zasadni smysl nebo to jinak udelat nejde.


 U budov je to většinou jen pár segmentů, navíc obvykle jsou tam opravdu
dvě stěny (kromě řadových garáží). To ale nic neznamená, kreslí se obrys
budovy, ne konstrukční řešení.
Ohledně komfortu práce s relacemi nesouhlasím, mě se s relací pracuje
mnohem lépe než bez nich (JOSM + relation Toolbox)


 To by se totiz editory musely chovat tak, ze z toho tu relaci vyrobi
 automaticky, aniz by do toho kreslic musel nejak hrabat ... a idealne aniz
 by to nekde videl. Navic by takovych automatismu musel abyt cela rada ...
 co treba, kdyz najdu na hranici nejakych dvou ploch nejakou dalsi, jinou
 plochu ... pokud to nejsou relace, tak proste ty dve cary odtahnu od sebe a
 vepisu tam to co tam je... kdyz to bude relace... je to sr..ni na pul dne.


Odtáhnout dvě čáry od sebe je v připadě, že sdílejí uzly, náročnější než
nakreslit novou čáru a  dosadit ji jako člena relace - nebo se pletu?


 Plati (bohuzel) zcela obecne ... o vsech pripadech vyuziti relaci.
 Pridelal sem odbocku k silnici, puvodni tam roztrch, abych moh doplnit
 zakazy odboceni ... z zjistil, ze puvodni uz v nekolika odbocovacich
 relacich byla ... nekde jinde ...= rucne sem je musel spravovat ... a to
 sem v tomhle pripade vedel, jak ta relace datove ma vypadat, protoze i
 JOSM to sice umi nastrojem vyrobit, ale to je tak vsechno. V tomhle pripade
 by editor mel zcela automaticky z ty relace vyhodit segmenty, ktere nejsou
 pripojeny k definovanemu krizeni. Je spousta relaci se slozitou strukturou,
 ktery se nijak rozumne rucne editovat nedaj, ale rozbit se daj velmi snadno
 libovolnym zasahem v okoli. Velmi vyjimecne se editor aspon zepta (napr pri
 otoceni smeru cesty a jednosmerce ...)

 = osobne se snazim relacim vyhybat, pokud to jen jde.


 Dne 22. května 2013 10:08 Lukas Kohout l...@luko.name napsal(a):

 Ahoj,

 při čtení diskuze o lesích bych měl otázku ohledně jejich hranic s
 jinými plochami. Plochy s různým využitím mají mít společné a nebo oddělené
 hranice? Například les sousedící s polem, uprostřed pole remízek, uprostřed
 lesa mýtina, nebo lom či zahrádkářská kolonie atd. Nyní je to v některých
 oblastech naházené přes sebe se spoustou překryvů a v moři čar se občas při
 editaci docela těžce orientuje. Je na to nějaká doporučená best practice?
 Díky.

 LuKo





 On 22.5.2013 9:45, jzvc wrote:

 Dne 19.5.2013 12:14, Pavel Machek napsal(a):

 Ahoj!

  6. Potreboval bych rozdelit obrovsky multipolygon lesa, abych mohl u
 casti vyznacit typ lesa. U hranic se Slovenskem, kde to delalo

 V puvodnich uhulich datech typ lesa byl, jen jsme ho neimportovali
 :-(. Mozna by davalo smysl to importovat znovu, s typem lesa, a bez
 generalizace?


 Pavel

  Probuh, jen to ne ... ty lesy jsou i tak neuveritelne nepresny ... ale
 je tam bambilion rucnich zmen, ktery bys tim naprosto vsechny zahodil.

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



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




 ___
 Talk-cz mailing 
 listTalk-cz@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-cz



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


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

Re: [Talk-cz] Turistické známky

[LM_1]

I když je to komplikovanější, přimlouval bych se za to, aby TZ nebyla
samostatným uzlem téměř nikdy - co vím tak je vždycky svázaná s nějakým
objektem, který v mapě už je - a turistická známka by měla být jen další
informací o takovém objektu.
Lukáš Matějka (LM_1)


Dne 21. května 2013 9:45 Marián Kyral mky...@email.cz napsal(a):

 Zkouším poslat znovu, napoprvé neprošlo - prý spamuji :-(

 Marián

 -- Původní zpráva --
 Od: Marián Kyral mky...@email.cz
 Datum: 21. 5. 2013
 Předmět: Turistické známky

 Jednou z věcí, které mi na OSM (a následně na turistických mapách) chybí,
 jsou turistické známky. Jsou neocenitelné při plánování výletu, člověk
 alespoň vidí, kde je co zajímavého.

 Už nějakou dobu si pohrávám s myšlenkou importu TZ (na komíny jsem
 nezapomněl, jsou ve frontě a počítám, že pokud se povede jeden import,
 druhý se bude dělat obdobně).

 Na webu TZ je k dispozici seznam všech českých TZ ve třech formátech:

 1) txt - pouze seznam, nepoužitelné (
 http://www.turisticke-znamky.cz/export.php)
 2) csv - jedna známka na řádek - obsahuje GPS souřadnice - použitelné (
 3) csv - totéž co předchozí, pouze je jedna známka rozdělena na více
 řádků, odděleno prázdným řádkem

 Viz http://www.turisticke-znamky.cz/seznam.php (Aktuální seznam TZ ke
 stažení)*

 *U souborů není uvedena licence, proto jsem poslal dotaz na TZ, zda by
 bylo možné soubory využít a obdržel jsem následující odpověď:

 ==
 Dobrý den,

 díky za Váš mail a za zájem o Turistické známky.
 Beze všeho použijte csv soubory, které máme na webu, pokud budou existovat
 linky na jednotlivé známky na našem webu, bude to jen přínos.
 Momentálně pracujeme na kompletním seznamu všech TZ, i těch zahraničních.
 Vyvěsíme ho na web do konce května.

 Hodně zdraví
 za Turistické známky s.r.o.
 David Holub
 ==

 Takže z tohoto pohledu to vypadá, že není problém a zbývá jen vyřešit pár
 drobností B-)

 1) Definovat, jak TZ zadat do OSM, doplnit na wiki, udělat nějaký preset
 pro JOSM
 2) Připravit úvodní import
 3) Připravit nějaký nástroj pro aktualizaci

 *Ad 1) Definice TZ na OSM*

 V souboru jsou k dispozici následující informace:
 (*) Číslo TZ
 (*) Název
 (*) Kategorie - (turistická oblast (Jeseníky, Beskydy...), muzeum, zoo,
 rozhledna...)
 (*) Okres
 (*) Uveřejněno - U starších známek nevyplněno
 (*) 1. prodejní místo
 (*) www - url 1. prodejní místo
 ...
 (*) 13. prodejní místo
 (*) www
 (*) GPS - GPS souřadnice

 (Poznámka: je docela pravděpodobné, že nové soubory budou vypadat trochu
 jinak - uvidí se až budou k dispozici)

 Mapování na OSM tagy bych si po prvotním průzkumu představoval nějak takto:

 tourism=attraction - poznámka: zatím nemá wiki stránku
 attraction=stamp (nový tag)
 name=Název (případně TZ: Název)
 description=Kategorie a jednotlivá prodejní místa + www
 website=http://www.turisticke-znamky.cz/znamka_.php?id=Číslo
 ref=TZCZ:číslo
 source=tz (nebo turisticke-znamky.cz?)

 _Příklad:_
 27;Zdobnice;ORLICKÉ HORY;Rychnov nad Kněžnou;;Chata Jitřenka,
 Zdobnice v Orlických horách;;Chata Kovárna, Zdobnice;
 http://chatakovarna.cz;;;50,238611;16,
 408611

 tourism=attraction
 attraction=stamp
 name=Zdobnice
 description=ORLICKÉ HORY; Chata Jitřenka, Zdobnice v Orlických horách;
 Chata Kovárna, Zdobnice (http://chatakovarna.cz)
 website=http://www.turisticke-znamky.cz/znamka_.php?id=27
 ref=TZCZ:27
 source=tz

 Předpokládám, že TZ bude vždy jako samostatný uzel.

 Prosím o revizi. Jediné, co by bylo dobré zachovat je nějaká jednoznačná
 rozlišitelnost pro následné aktualizace.

 *Ad 2) Úvodní import*
 Co jsem tak koukal, jak to dělá josm, stačí vygenerovat  xml soubor a ten
 následně nějak dostat do OSM. Dalo by se použít JSOM, ale raději bych to
 udělal napřímo, přes API pomocí nějaké šikovné utilitky.

 Vygenerovat XML z csv je celkem triviální úkol, na to by stačil jednoduchý
 shell script. Taktéž by neměl být problém s duplicitami, TZ v OSM zatím
 nejsou (opravte mě pokud se mýlím).

 *Ad 3) Aktualizace*
 Seznam turistických známek se stále mění, nové známky přibývají, některé
 staré se ruší (a číslo se pak použije u nějaké nové známky). Jednou z
 možností je dělat aktualizace ručně, dle email listu. Ale to se mi jednak
 nechce a taky to nepodchytí všechny změny, hlavně změny prodejních míst.

 Takže nejlepší bude nějaký robot, který si stáhne aktuální seznam z webu
 TZ, následně si stáhne seznam TZ z OSM přes overpass API, oba soubory
 porovná, vygeneruje xml soubor se změnama a ten následně nahraje na OSM
 (úplně stejně jako u importu).

 Tohle už shellem řešit nepůjde (zpracovávat XML pomocí shellu není právě
 triviální), takže předpokládám, že opráším python a udělal bych to v něm.
 Co jsem koukal, nějaké python moduly pro obsluhu OSM API existují.

 Teď už jen zbývá otázka, co všechno aktualizovat. Měla by se aktualizovat
 i poloha? Tedy pokud ji nějaký uživatel omylem přesune, známka se vrátí
 zpátky. Ale co

Re: [OSM-talk] Why do we have so many registered users with zero edits ?

[LM_1]

I found osm by accident when searching for a map editing tool. The first
experience was not great - what I got was a Potlatch centred on one line -
representing a street. What do I do now? Move the street - where? Potlatch
has quite minimalistic UI - that makes is simple, but also hides a lot of
its real possibilities. Showing JOSM as the first edit tool would probably
attract more advanced computer users, but discourage many who are less
friends with IT.
Immediately after registering one usually does not have any gps tracks or
specific information to put in. There is a lot of tools that search for
errors - why not to suggest the first few edits - it might make the first
steps easier.
Maybe something like http://play.kort.ch should be the first thing new
users see instead of Potlatch.

Lukáš Matějka (LM_1)

2013/4/12 Richard Fairhurst rich...@systemed.net

 Cartinus wrote:
  Most of these are people who didn't read what Openstreetmap was
  about before they registered. They most likely thought they would
  need to register to _USE_ all the features of Openstreetmap, not
  contribute to it.

 +1. You'd be surprised how common this is. Our village website only
 requires
 registration to post (you can read everything without registering), and the
 posting UI is incredibly simple, yet the great majority of registered users
 have never posted.

 cheers
 Richard





 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Why-do-we-have-so-many-registered-users-with-zero-edits-tp5756797p5756845.html
 Sent from the General Discussion mailing list archive at Nabble.com.

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

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

Re: [OSM-legal-talk] OSM data on copy-protected storage

[LM_1]

Even if keeping their data proprietary goes against the nature of OSM, yes
OSM data can be used as described - that is if the data is not mixed with
mentioned proprietary data. Copyright attribution is still required.

LM_1


2013/4/9 andrzej zaborowski balr...@gmail.com

 Hi,

 I'm relaying a license question from a company that collects lake
 bathymetry data and sells specialised GPS devices to fishers and
 sailors.  They don't make the software on those devices and have to
 pay to get their data converted to the format understood by that
 software.  They'd like to add layers of OpenStreetMap data to the
 storage cards shipped with a new device, but they'd like to keep their
 bathymetry and coastline data proprietary.  The cards are
 copy-protected (encrypted, I believe).  Their question is whether
 OpenStreetMap data can be distributed encrypted on those cards
 together with their own data.  The company can publish, e.g. on their
 website, whatever files are necessary but they can't publish the
 conversion process or their own data unencrypted.

 My understanding is that if their coastline data is not merged with
 OSM coastline data (one or the other is shown), and if they publish
 raw OSM data or information on how they extracted it, then they are
 fine.  But I will appreciate any comment from someone who deals with
 OSM licensing more.

 Cheers

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

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

Re: [Talk-cz] Nemehlo

[LM_1]

ad neexistující železniční trať: může tam pořád být podloží (bez kolejí a
pražců) a takový objekt se obecně bere jako přípustný.
LM_1


Dne 8. dubna 2013 11:39 Michal Tauchman michal.tauch...@gmail.comnapsal(a):


  IOW to ze vyrobim chybu na keepright neni nutne spatne.

 Ano, někdy KeepRight hlásí nesmysly, taky nedělám to, že nuceně předělávám.
 Pokud vím nebo zjistím, že hlášená chyba není chybou, označím to jako
 falešný poplach a napíšu do poznámky, že se nejedná o chybu, ale reálný
 stav.

 To nemění nic na tom, že tento uživatel prostě nakreslil hromady cest přes
 sebe bez křížení, cesty kolidovaly s vodou, bylo jich několik v sobě,
 konec cesty končil poblíž jiné, takže plavala ve vzduchu atp.

 A takových je víc, bohužel. Ano, je fajn, že čím více lidí, tím kvalitnější
 mapy, ale pokud se to dělá bez rozmyslu nebo přečtení aspoň základních
 informací, napáchá se spíše více škody než užitku.

 No zrovna ho zkouším kontaktovat, jsem zvědavý, co mi na to řekne.

 A zeptám se, pokud by se jednalo o historický stav, tak to stejně nemá na
 mapě co dělat, ne? K čemu potřeba mít zobrazené neexistující prvky, jen
 to mate.
 Ono už jsem objevil od tohoto uživatele zakreslenou vlakovou trať,
 tag abadnoned, a po přezkoumání v Google Earth jsem viděl, že tam žádné
 koleje už nejsou (jestli byly), takže taky asi historická záležitost.



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

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

Re: [OSM-talk] Imagery Boundary?

[LM_1]

That idea seems good to me: reasonably simple - not a new database for each
usecase, but giving place to all that potentially useful data that is seen
as unworthy for the main database.
Some categories (category=sport/birds/metadata/...) would likely have to be
created to allow filtering only some features in JOSM, otherwise it would
be unusable.
Lukáš Matějka (LM_1)

2013/4/7 Dave Sutter sut...@intransix.com

 Creating another instance of the OSM database and server is a very
 good idea. I would propose we make the purpose of this database to
 allow people post ANY geo data that is NOT part of the base map. It
 would be an open database for general GIS data.

 Some examples of random things people could do with this database:
 - The high resolution imagery outlines discussed in this thread
 - Migratory patterns of birds (I can't find the post where someone was
 requesting where to do this...)
 - GPS tracking for running, hiking, cycling and other recreation,
 similar to Strava or MapMyRun (see
 http://wiki.openstreetmap.org/wiki/OpenSportMap)
 - GIS Management for operations like Haiti OSM team

 The official OpenStreetMap database is for the basemap and this new
 instance would be for operational data.

 Of course there could be many different operational layer databases,
 and different layers have been discussed many times. For starters, we
 could just make one database and let people use it for any such
 purpose.

 Also, when there is talk of alternate databases there is talk of
 linking between databases. For starters we would not have any
 provision for this. This would just be a separate GEO database.

 How do we do this? I'd like to reference a post by Jason Remillard,
 http://lists.openstreetmap.org/pipermail/talk/2013-February/066301.html

 We apparently have a lots extra bandwidth and disk space on our US
 OSM servers. Requests have gone out asking for ideas...

 So perhaps it could be hosted on US OSM servers.

 Dave

 On Sat, Apr 6, 2013 at 8:08 PM, Steve Bennett stevag...@gmail.com wrote:
  On Sun, Apr 7, 2013 at 2:15 AM, Janko Mihelić jan...@gmail.com wrote:
  I think this boundaries can be useful, but should be in some other
 database.
 
 
  Are there any other appropriate databases? That is, something with the
  same form (an OSM database) for stuff related to the OSM project, but
  not containing actual OSM content. I'm thinking Wikipedia has talk
  pages, project pages, and meta.wikimedia.org; Stack Overflow has
  meta - would some kind of meta OSM database be appropriate?
 
  Steve
 
  ___
  talk mailing list
  talk@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk

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

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

Re: [Talk-cz] Nemehlo

[LM_1]

Dobré, akorát bych doplnil i odkaz na help.osm.org (hlavně anglicky ale
mnohem příjemnější prostředí než mailing list a vhodnější pro
otázky-odpovědi) nebo komunitu na G+ (https://plus.google.com/u/0/
communities/111981115616957848548)

Lukáš Matějka (LM_1)


Dne 7. dubna 2013 14:53 Petr Holub ho...@ics.muni.cz napsal(a):

  Já to dokážu pochopit, nejsem ras, ale proč tam kreslí nějakou vodní
 plochu,
  která nejspíš neexistuje? Opravdu mi to nejde do hlavy. Nepochopení
 křížení
  apod. dokážu pochopit, ale tohle? Jak říkám, neznám tu v okolí každý
 metr,
  ale na jakýchkoli ortofoto mapách vidím, že tam žádná voda není, ani
 nevím,
  proč by tam někdo dělal skutečný rybník, podle mne by to ani nešlo. Ani
  netuším, co by to mohlo být jiného. No asi ho zkusím kontaktovat, nic mi
  jinak nezbývá, ale moc se do toho neženu. Nerad někoho kárám, samotnému
  mi to nedělá dobře, ale když není zbytí...

 Co kdybychom si pro tyhle pripady nachystali do wiki nejaky standardizovany
 text emailu, ktery by znel rozumne povzbudive a nikoli negativisticky, aby
 to clovek nemusel vymyslet pokazde znova (zvlaste, kdyz nerad kara apod :))
 Neco jako

 ---
 Vážený uživateli,

 všimli jsme si Vašich příspěvků do projektu OpenStreetMap (OSM). Vážíme si
 každého,
 kdo je ochoten věnovat svůj čas budování největší otevřené databáze geodat
 a z nich generovaných mapových podkladů. Bohužel se ale ve Vašich
 příspěvcích
 objevily následující problémy:
 - ...
 - ...
 Rádi bychom Vám proto nabídli pomocnou ruku, aby Váš čas investovaný do
 projektu
 OSM byl co nejefektivněji využit. Prosím, dbejte na to aby Vaše data byla
 co možná
 nejaktuálnější a nejpřesnější. Pokud data z něčeho odvozujete, nepoužívejte
 jiné než komunitou schválené otevřené zdroje
 (https://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap)
 jinak by projekt mohl mít v budoucnu velké právní problémy.

 Základní informace o tom, jak sbírat, vkládat a upravovat data najdete zde:
 - http://www.marekp.cz/jak-vkladat-turisticke-informace-na-osm
 - https://wiki.openstreetmap.org/wiki/CS:Beginners_Guide
   (tady s tím mám trochu problém, protože si myslím, že zejména úvodní
 stránka
   je příliš technická a detailní s vysvětlováním pojmů jako je
 WMS/TMS/slippy map
   a podobně; akorát asi nejsem momentálně schopen to napsat líp :-(( )

 Pokud si nejste něčím jist, tak mne kontaktujte přímo emailem, případně se
 příhlašte do konference talk-cz@openstreetmap.org, kde Vám zkušení
 kolegové
 mappeři rádi poradí a vysvětlí nejasnosti.

 S pozdravem
 Z
 ---

 Co vy na to? Doplnujte, prepisujte, nebo strhejte... :-)

 Petr


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

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

Re: [Talk-cz] Nemehlo

[LM_1]

Mnohokrát se probíralo, že spousta uživatelů - nováčků neví, že opravdu
upravují skutečnou mapu a bez zlých záměrů se chovají jako na pískovišti...
LM_1


Dne 7. dubna 2013 2:13 Michal Tauchman michal.tauch...@gmail.comnapsal(a):

 Lukas Kohout luko@... writes:

 
 
  Souhlasím. Také se mi tu objevil jeden
takový aktivní blbec, který v krátkém čase vygeneroval obrovské
množství nových cest, ploch a bodů. Mlátil to do editoru, jak mu
to přišlo pod ruku, cesty a plochy náhodně přes sebe, různé
cestičky nenapojené na existující silnice, nové cesty by nejradši
v celé mapě namaloval jedním tahem se všemi důsledky z toho
plynoucími (např. u slepé cesty se jednoduše vrátil bez přerušení
kreslení). Keepright předtím poměrně čistý po něm hrál všemi
barvami. Při kontaktu z něj vypadlo, že OSM objevil a do editace
se pustil, aniž by si přečetl jakoukoli nápovědu. Občas to není o
tom, že to ti lidé dělají naschvál, ale jednoduše nezvládnou
nadšení z možnosti přímo editovat mapu v kombinaci s obrovskou
škálou možností a voleb, které v editoru mají k dispozici.
LuKo
 
On 6.4.2013 21:21, LM_1 wrote:
 
 
Předně bych ho zkusil kontaktovat. Třeba ani neví
  co dělá...
  Lukáš Matějka (LM_1)

 Já to dokážu pochopit, nejsem ras, ale proč tam kreslí nějakou vodní
 plochu,
 která nejspíš neexistuje? Opravdu mi to nejde do hlavy. Nepochopení křížení
 apod. dokážu pochopit, ale tohle? Jak říkám, neznám tu v okolí každý metr,
 ale na jakýchkoli ortofoto mapách vidím, že tam žádná voda není, ani nevím,
 proč by tam někdo dělal skutečný rybník, podle mne by to ani nešlo. Ani
 netuším, co by to mohlo být jiného. No asi ho zkusím kontaktovat, nic mi
 jinak nezbývá, ale moc se do toho neženu. Nerad někoho kárám, samotnému
 mi to nedělá dobře, ale když není zbytí...


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

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

Re: [Talk-cz] Podklad Bing v Praze

[LM_1]

Debata zajímavá, i když argumenty trochu chybí. Každopádně moc
nepomáhá původnímu tazateli.
Jestli používáš JOSM, podívej se do nastavení podkladů. Analogicky k
tomu co tam je bych zkusil třeba bing[18]:http://www.bing.com/maps;
jako TMS (v hranaté závorce je maximální zoom, [min,max] by asi taky
fungovalo).
Lukáš Matějka (LM_1)

Dne 8. ledna 2013 16:16 Libor Pechacek lpecha...@gmx.com napsal(a):
 On Sun 06-01-13 15:10:20, hanoj wrote:
  ... jinak ta orthofoto
  je by default dostupna pro nekomercni ucely(maj to napsany na webu),
  predpokladam ze komercne ji nevyuzivas = z myho pohledu i pro mapovani OK.
  Vubec nemluve o tom, ze jde (pokud vim) o uredni dilo (vyrobeno z nasich
  dani).
 *** az zase vymyslis nejakou podobnou blbost, udelej primo amnestii,
 ale nepis nam o tom do konference...

 +1, i kdyz bych volil jina slova

 Libor
 --

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

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

Re: [Talk-cz] Značení chatových oblastí

[LM_1]

Podle mě je landuse=residential odpovídající. To že se tam nebydlí
trvale nevadí.
Lukáš Matějka (LM_1)

Dne 22. prosince 2012 20:12 Marcel Dopita m...@rcel.cz napsal(a):
 Dobrý den,

 už delší dobu přemýšlím a stále nenacházím žádné informace o tom, jak (a
 jestli) značit tag landuse u různých chatových oblastí. Zahrádkářské kolonie
 tag mají, ale chatové oblasti jsou přeci jen specialita ČR.
 Měla by se tedy správně nějak značit oblast, která je v územním plánu
 značena jako rekreační zástavba (jsou na ní postaveny klasické pevné domy,
 plotem oddělené zahrady a je několik čísel popisných)?

 S pozdravem,
 Marcel

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


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

Re: [Talk-cz] Cesta sdilena vice vlastnostmi

[LM_1]

Dne 19. září 2012 7:59 Petr Morávek [Xificurk] p...@pada.cz napsal(a):
 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.


Přesně to jsem myslel.


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

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



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

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

Re: [Talk-cz] Cesta sdilena vice vlastnostmi

[LM_1]

Zdravím,
oficiální postoj OSM je, že žádný není, kromě pár pravidel pro řešení sporů.
Je to vhodné, pokud hranice opravdu probíhá středem silnice. Obvykle
ale hranice probíhá po okraji silnice a tak  je sloučení fakticky
nesprávné.
Kdyby byla vyznačená i plocha silnice, pak by měla společnou hranici s
okrajem lesa. V tom případě bych se snažil použít multipolygon,
protože víc cest přes sebe nejde dost dobře editovat.
V uváděném případě je možné/pravděpodobné, že hranice CHKO je společná
s hranicí lesa nebo louky, tam bych se spojení nebránil.
Jinými slovy: pokud je hranice opravdu identická (v zákoně se píše
středem silnice) tak slučovat, jinak ne.
Analogicky u lesních cest tvořících hranice je vhodné je sloučit,
pokud cesta vede vedle/podél hranice tak neslučovat.

Lukáš Matějka (LM_1)

Dne 18. září 2012 23:23 Martin Krupicka mar...@bhpromo.cz napsal(a):
 Dobry vecer,
  pustil jsem se do uprav a chtel bych se zeptat na oficialni postoj ke
 slucovani vlastnosti na jedne ceste.
 Konkretni priklad - hranice CHKO (v mem pripade Beskydy) probiha podel
 silnice. Je tedy dano, napriklad, ze napravo od silnice CHKO je, nalevo
 neni. V mape jsou zaneseny dve cesty, jedna pro silnici, druha pro hranici
 CHKO. Bylo by formalne spravne je sloucit, pripadne, nemelo by to neblahy
 vliv na renderovani?

 Z podobneho soudku - RUIAN hranice velmi casto probihaji po lesnich cestach,
 ktere ovsem v mape zatim nejsou. Je vhodne k existujici ceste RUIAN pridat v
 adekvatnich usecich tag, ze jde o lesni cestu?

 Martin



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

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

Re: [Talk-cz] KeepRight!

[LM_1]

Překřížení bez/s křižovatkou ve smyslu společného uzlu by mělo záviset
na tom, jestli tam křižovatka je. Takže zrovna u řek a potoků z
dibavod obvykle společný uzel nebude (kromě brodů). Řešení je
jednoduché - kde jsou mosty tak je kreslit, kde je trubka pod silnicí
tak tunnel=culvert (na zatrubkované části potoka). K tomu správné
výškové úrovně.

LM

Dne 6. září 2012 11:54 Michal Tauchman michal.tauch...@gmail.com napsal(a):
 Zdravím,
 mám dotaz ohledně KeepRight. Podle tohoto opravuji mapy, často vidím, že 
 autoři
 nespojují cesty které vytvářejí, tedy že bod končí kousek od cesty, od které 
 měl
 být napojen.

 Pro zobrazení mapy to nevadí, většinou to vůbec není vidět, ale pro navigační
 software je to konec. Bohužel koukám, že hodně přispěvovatelů si nedává na 
 toto
 pozor.

 Což není ale hlavní gro, na co jsem se chtěl zeptat. Jak to řešit s 
 překřížením
 bez křižovatky? Těch je na mapě neuvěřitelně moc, většinou u importu 
 dibavodu.
 Jak o řešit?

 Ignorovat a vypnout zobrazení? Někde jdou nakreslit mosty, které tam
 jsou, jinde se jedná o podzemní tok. Jak to řešit, zda vůbec nějak?


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

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

Re: [Talk-cz] Evropsky významné lokality

[LM_1]

Myslím, že v tomto případě není potřeba se namáhat vymýšlením. Systém
mapování chráněných oblastí vypadá celkem propracovaně:
http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area

LM_1

Dne 4. září 2012 9:11 hanoj eha...@gmail.com napsal(a):
 spíš bych se přiklonil k tomu, dát existujícímu území další atribut,
 něco jako evl=yes případně natura2000=yes
 *** evil=yes ;)


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

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

Re: [Talk-cz] Zmeny v Prazske MHD od 1.9.2012

[LM_1]

Používáš oba zdroje, takže bys měl uvést oba. Práce navíc to není,
stejně se to po prvním napsání vypisuje samo.
Pokud je linka zrušená trvale tak bych ji klidně smazal - stejně jako
zbořenou budovu. Kdyby někomu moc chyběla tak jde vždycky dohledat v
historii a obnovit (po delší době problém, u zrušené linky nečekám).
Lukáš Matějka (LM_1)

Dne 1. září 2012 17:24  seznam.r...@seznam.cz napsal(a):
 Zdravim, 1.9. dojde k velkym zmenam v MHD a nektery linky budou zruseny. Tak 
 bych se rad zeptal, jestli je muzu natvrdo vymazat (coz mi neprijde uplne 
 cisty s ohledem na to, ze si s tim nekdo dal v minulosti praci) nebo to mam 
 oznacit nejakym tagem jako zrusenou linku? Jakym?

 A druhy dotaz: co mam napsat do source tagu, kdyz pouzivam Bing mapy, kterym 
 upravuju offset podle ČÚZK ortofotomapy? Staci jen Bing nebo bych tam mel 
 nejak vecpat CZUK? Jak presne?

 Diky, viduka

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

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

Re: [Talk-cz] Zmeny v Prazske MHD od 1.9.2012

[LM_1]

Dne 1. září 2012 23:20 hanoj eha...@gmail.com napsal(a):
 Používáš oba zdroje, takže bys měl uvést oba. Práce navíc to není,
 stejně se to po prvním napsání vypisuje samo.
 *** to je samozrejme spatne.
 jednak cuzk:ortofoto neni legalni k odvozovani dat pouzivat a druhak
 Viduka pise ze ho k tomu ani nepouziva, offset. takze uvest prave
 bing.


Ono to špatně samozřejmě není. Použitím zdroje pro zarovnání se
získává poloha, což je pro mapu dosti podstatná věc. A poloha po
upravení offsetu bude odpovídat tomu zdroji zarovnání, naopak podle
bingu nebude odpovídat ani trochu.
Pokud zdroj použít nejde tak je potřeba ho nepoužít a ne ho zatlouct.
To nepomáhá.
Kromě toho samozřejmě můžeme vést debatu, jestli by nebylo lepší
použít pro zarovnání vhodnější zdroj - třeba katastrální mapu.
LM

 ha
 hanoj

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

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

Re: [Talk-cz] Administrativni hranice z RUIAN

[LM_1]

JOSM i Potlatch přidají do relace obě výsledné cesty po rozdělění.
Tam by problém být neměl.
Hranice (nebo jiné objekty) se v OSM mění když se změní v realitě nebo
když jsou zpřesněny. Druhá varianta je u hranic (tam kde jsou obnovené
katastrální mapy) celkem nepravděpodobná a první variantu řeší dobře
přístup změny jen tagů a relacích patřících ke hranici.
Dost dobře si nedovedu představit jak by měla vypadat přesná mapa s
nezávislými hranicemi - různé body přes sebe? náhodná odchylka aby
přes sebe nebyly? sdílené jen body (už nejsou nezávislé)?
Co se týče zjednodušení tak přesnost 1cm by určitě neměla být problém
(akorát se tím posunou některé body a některé zmizí, což by mohlo
působit problémy při aktualizaci - po změně jednoho uzlu v
nezjednodušených datech by mohl algoritmus dojít k celkové změně,
která by ovlivnila mnohem větší oblast.

Lukáš Matějka (LM_1)

Dne 30. srpna 2012 13:39 Petr Morávek [Xificurk] p...@pada.cz napsal(a):
 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

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

Re: [Talk-cz] Administrativni hranice z RUIAN

[LM_1]

V tom případě je to bez problému. U hranic s odchylkou přes metr bych
nečekal ani spojení s plotem, hranicí lesa apod.
LM

Dne 30. srpna 2012 16:20 Petr Morávek [Xificurk] p...@pada.cz napsal(a):
 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

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

Re: [Talk-cz] Administrativni hranice z RUIAN

[LM_1]

Dne 28. srpna 2012 7:24 hanoj eha...@gmail.com napsal(a):
 Geometrii bych určitě nezjednodušoval, to je celkem
 zbytečná nepřesnost.
 *** uplne bych se tomu nebranil, presna hranice ma smysl pokud pracuji
 s katastralni mapou (aby 1 parcela nebyla ve 2 k.u.). Chyba 1 metr je
 v nasich potrebach dostacujici.
To bych netvrdil. Tam, kde jsou přesné katastrální mapy je přesnost
mnohem vyšší než v metrech a očekával bych, že se bude spíš zvyšovat.


 Staré uzly a cesty bych mazal jen pokud nemají
 kromě hranice žádný jiný tag. S těmi co mají bych možná vůbec nehýbal
 automaticky (hranice vedoucí středem řeky apod.)
 *** to doufam nemaji, hranice byly vytvoreny jako balik autonomnich
 entit tj. nezavisly na fyzickych prvcich mapy. A pokud se tak v
 editacich useru stalo, mela by se data opet stat autonomni.

S tím nesouhlasím. Úplně nezávislou vrstvu dat by si ostatně mohl
každý použít přímo ze zdroje. To, že se data spojí - hranice vedoucí
plotem nebo zdí domu - je přidaná hodnota. Navíc je tím zajištěno
zarovnání.
Žádný balík autonomních entit nemá v osm moc co dělat, jak se jednou
importuje tak splývá s ostatními daty.
Něco jako Co jednou peklo schvátí, to už nikdy nenavrátí. :)

LM


 ha
 hanoj

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

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

Re: [Talk-cz] Administrativni hranice z RUIAN

[LM_1]

Dne 29. srpna 2012 1:17 hanoj eha...@gmail.com napsal(a):
 Staré uzly a cesty bych mazal jen pokud nemají
 kromě hranice žádný jiný tag. S těmi co mají bych možná vůbec nehýbal
 automaticky (hranice vedoucí středem řeky apod.)
 *** to doufam nemaji, hranice byly vytvoreny jako balik autonomnich
 entit tj. nezavisly na fyzickych prvcich mapy. A pokud se tak v
 editacich useru stalo, mela by se data opet stat autonomni.

 S tím nesouhlasím. Úplně nezávislou vrstvu dat by si ostatně mohl
 každý použít přímo ze zdroje.
 *** muze, nemusi. Proc by nemohlo byt osm vse v jednom?
V OSM má být vše v jednom, můj nesohlas směřuje proti existenci
chráněných, nedotknutelných vrstev.


 To, že se data spojí - hranice vedoucí
 plotem nebo zdí domu - je přidaná hodnota. Navíc je tím zajištěno
 zarovnání.
 *** pridana hodnota to je v datovych modelech, kde existuji striktni
 topologicka pravidla. V OSM se fakticky nedodrzuji ani ta zakladni. K
 cemu jsou mi data o jednom fenomenu, ktera nabyvaji ruznych forem,
 vztahu, tagu, vazeb, relaci, primitiv, pokryti a kvality.
Když hledám hranici a v mapě je na stejné cestě jako plot, bude se mi
líp hledat v realitě.
Spojení s dalšími údaji hranice negativně neovlivní, stejně jsou to
relace a o žádných kolizích tagů taky nevím.
To, že se něco dělá špatně, je důvod to začít dělat správně a ne dělat
špatně i všechno okolo.
Nestejnoměrná, ale rostoucí, kvalita je obecnou vlastností OSM, v tom
není rozdíl.


 Žádný balík autonomních entit nemá v osm moc co dělat, jak se jednou
 importuje tak splývá s ostatními daty.
 *** proc by ne, kdyz neni dalsi zdroj relevantnich informaci, ktere k
 nemu dodat.
Bavíme se samozřejmě o případech, kdy relevantní informace existují.
To, že někde vede hranice samozřejmně neznamená, že na ni naplácám
všechno co je v okolí (stylem cesta tvořící silnici je zároveň okrajem
lesa).


LM


 ha
 hanoj

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

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

Re: [Talk-cz] Administrativni hranice z RUIAN

[LM_1]

Dobrý nápad. Geometrii bych určitě nezjednodušoval, to je celkem
zbytečná nepřesnost. Staré uzly a cesty bych mazal jen pokud nemají
kromě hranice žádný jiný tag. S těmi co mají bych možná vůbec nehýbal
automaticky (hranice vedoucí středem řeky apod.)
Lukáš Matějka (LM_1)

Dne 27. srpna 2012 15:40 Petr Morávek [Xificurk] p...@pada.cz napsal(a):
 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 mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Administrativni hranice z RUIAN

[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?
LM

Dne 27. srpna 2012 22:16 Petr Morávek [Xificurk] p...@pada.cz napsal(a):
 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

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

[LM_1]

Námět: Regiony soudržnosti se zobrazují na hlavní stránce při zoomu 7,
takže v OSM zcela jistě jsou.
LM_1

Dne 5. srpna 2012 18:10 Miroslav Šulc fordf...@fordfrog.com napsal(a):
 ahoj,

 pustil jsem se do toho bota nad rúian daty. z analýzy rúian dat mi vyplývá,
 že sestavení adresy lze udělat následovně:
 - adresní místa s vazbou na ulici mají definovanou ulici
 - adresní místa bez vazby na ulici nemají asociovanou žádnou ulici
 - určení obce adresního místa vazbou na stavební objekt a u něj přes vazbu
 na část obce až na samotnou obec (a následně na nějaký vyšší územní celek -
 okres, region)

 k tomu připojuju ilustrační tabulku (typ_kod 1 = má číslo domovní, 2 = má
 číslo evidenční; has_ulice f = nemá definovanou vazbu na ulici, t = má
 definovanou vazbu na ulici; count = počet adresních míst; has_cobce = má
 vazbu na část obce; has_momc = má vazbu na městský obvod/městskou část;
 has_parcela = má vabzu na parcelu):

 ruian_new=# select so.typ_kod, am.ulice_kod is not null has_ulice, count(*),
 count(cobce_kod) has_cobce, count(momc_kod) has_momc,
 count(identifikacni_parcela_id) has_parcela from rn_adresni_misto am left
 join rn_stavebni_objekt so on am.stavobj_kod = so.kod group by typ_kod,
 has_ulice order by typ_kod, has_ulice;
  typ_kod | has_ulice |  count  | has_cobce | has_momc | has_parcela
 -+---+-+---+--+-
1 | f | 1098413 |   1098413 | 2190 | 1048078
1 | t | 1350292 |   1350292 |   266197 | 1310712
2 | f |  353978 |353978 |31947 |  273816
2 | t |  112828 |112828 |16215 |   81166
3 | f |   3 | 0 |0 |   3
3 | t |   1 | 0 |0 |   1
 (6 rows)

 z ní vyplývá, že všechny adresní body typu 1 (má číslo domovní) a 2 (má
 číslo evidenční) mají v tabulce stavebních objektů vazbu na část obce.
 problematika určení parametrů adresního bodu by tedy měla být až potud
 jasná. (možná se lze ještě pozastavit nad otázkou, zda do informací o
 adresních bodech zahrnout i městský obvod/městskou část).



 další oblastí je tagování adresních bodů. když se podívám třeba tady u nás
 na adresní body, tak jejich otagování se dost různí (nevím, jestli jsem
 postihnul všechny případy, ale asi ne):

 1) číslo domovní bez tagu addr:city
 addr:conscriptionnumber=666
 addr:country=CZ
 addr:housenumber=666
 addr:street=Lesní
 is_in=Doksy, Liberecký kraj, CZ
 source:addr=mvcr:adresa
 source:loc=cuzk:km

 2) evidenční číslo bez tagu addr:city a addr:street
 addr:country=CZ
 addr:housenumber=ev.479
 addr:provisionalnumber=479
 is_in=Staré Splavy, Doksy, Liberecký kraj, CZ
 note=Nekonzistence cuzk:km a mvcr:adresa
 source=cuzk:km

 3) evidenční číslo s tagem addr:street, ale bez addr:city
 addr:country=CZ
 addr:housenumber=ev.399
 addr:provisionalnumber=399
 addr:street=Klůček
 is_in=Doksy, Liberecký kraj, CZ
 source:addr=mvcr:adresa
 source:loc=cuzk:km

 4) očekával bych adresní body typu 1) včetně tagu addr:city, ale u nás jsem
 je nenašel

 takže otázkou je, jaké tagy má mít adresní bod s číslem domovním a s číslem
 evidenčním (v obci a mimo obec). osobně bych očekával u všech adresních bodů
 následující tagy:
 addr:city=Litovel
 addr:conscriptionnumber=678
 addr:country=CZ
 addr:housenumber=678/1
 addr:postcode=78401
 addr:street=Mlýnská
 addr:streetnumber=1
 is_in=Litovel, Olomoucký kraj, CZ
 source:addr=ruian
 ref:ruian=123456789

 případně lze ještě přidat tag s částí obce. tady je odkaz na addr tag na
 osm: http://wiki.openstreetmap.org/wiki/Key:addr



 poslední věc, na kterou jsem narazil, je, že kraje, které jsou použité v osm
 datech, dnes již neexistují. co jsem pochopil z dokumentace rúian, tak se
 nyní používají tzv regiony soudržnosti, jejichž názvy jsou víceméně totožné
 s kraji (nicméně ne s těmi v osm). tady je seznam regionů:

 ruian_new=# select nazev from rn_region_soudrznosti;
   nazev
 -
  Praha
  Střední Čechy
  Jihozápad
  Severozápad
  Severovýchod
  Jihovýchod
  Střední Morava
  Moravskoslezsko
 (8 rows)

 takže např liberecký kraj zmíněný v příkladech nahoře neexistuje, stejně tak
 olomoucký. tady je pak otázka, jakou identifikaci použít v is_in, zda použít
 regiony soudržnosti (jako náhradu krajů), nebo pro lepší identifikaci použít
 raději okresy.


 takže když to shrnu, tak:
 - identifikace adresních bodů je asi jasná (co s momc?)
 - je potřeba domluvit se, jaké tagy budou adresní body obsahovat
 - je potřeba najít náhradu za kraje

 dotazy/připomínky/náměty?

 ff

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


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

Re: [Talk-cz] import budov

[LM_1]

O jakých chybách se tady bavíme? V Brně bylo spostu adresních bodů
pěkně vyplněných, ale posunutých o třy čtyři domy vedle. Pro navigaci
lepší než nic, ale pro opravy celkem peklo (navíc oproti prázdnotě
hledání původního bodu).
LM

Dne 2. srpna 2012 16:20 Jakub Sykora kub...@kbx.cz napsal(a):
 Ja si myslim, ze se automatizovanemu importu nevyhneme. Tohle fakt rucne
 delat asi nejde :)

 K

 Dne 2.8.2012 15:18, hanoj napsal(a):

 Já jsem pro hromadný import, případně následně pro vytvoření robota na
 údržbu. Minimálně u adresních bodů.

 MK


 A dopadne to jako potoky, ktery nejsou spraveny doted.

 *** Jestli si mam vybrat mezi:
 * rucne s chybami=nikdy
 * import s chybami=letos

 tak vyber je jasnej

 h.
 hanoj

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


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

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

Re: [Talk-cz] Značení uzavírky a objízdných tras

[LM_1]

Obvykle se kácí dospělý/dorostlý les - celý. Čas se pravděpodobně dá
odhadnout s přesností na roky. Hranici kácení bych u soukromých lesů
očekával shodnou s hranicí parcel podle katastru.
Problém rozdílu mezi lesním pozemkem a místem pokrytým stromy se mimo
jiné snaží vyřešit návrhy jako
http://wiki.openstreetmap.org/wiki/User:Imagic/landcover

LM


Dne 2. srpna 2012 17:37 f.remenstech f.remenst...@gmail.com napsal(a):
 Dne 2. srpna 2012 13:29 jzvc j...@tpfree.net napsal(a):
 Dne 1.8.2012 10:32, Petr Kadlec napsal(a):
 2012/7/31 LM_1 flukas.robot+...@gmail.com:
 Rozumím tomu, proč bych jako řidič chtěl vědět, kudy vede oficiální
 objízdná trasa, ale co vím tak žádná navigace tuto možnost
 nepodporuje.
 V Německu mají takové ty trvalé předpřipravené objízdné trasy, kde
 beru, že asi dává smysl je mít v mapě nějak reprezentované. A vskutku:
 http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Bedarfsumleitung

 Ale nejsem si jist, jestli dává nějaký velký smysl mapovat běžné ad
 hoc objížďky, ani se nedivím navigacím, že takovou potřebu nemají.

 Tohle uz se tu taky tusim nekdy resilo. OSM je navrhovana na trvale
 platne mapovani, aktualne nema zadnou vrstvu s docasnymi daty, coz by
 prave podobny veci pokryvalo.
 Chtelo by to podobnou vrstvu nad temi daty, ktera by nebyla beznou
 soucasti dat, a kazdy zaznm by tam mel nejak omezenou platnost (od:do),
 a po skonceni platnosti se sam vyhodil.

 Silnici lze sice zavrit, ale stejne si to sosne jen minimum navigaci,
 specielne pokud je to opravdu jen kratkodoby (14dnu ...). Kdyby
 existovala da docasna vrstva, tak jelikoz bude mit radove min dat, daj
 se aktualizace sosat i pres nase uzasne FUPy (a navic by se do toho daly
 ladovat nejspis i data o nehodach ...).

 Dočasně by šlo mapovat les. Teď je to mýtina, za 3 roky hustník,
 po dalších X letech les (jde zjistit statisticky?). Po vykácení stejné
 části lesa někdo oblast resetuje na mýtinu... Předpokládám, že se
 nekácí náhodné kusy lesa?

 F.

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

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

Re: [Talk-cz] import budov

[LM_1]

Pokud jde o srovnávání importované vrstvy a stávajího stavu, toto je
cílem pluginu conflation. Jak moc to funguje nevím, naposledy když
jsem to zkoušel tak nic moc.
LM

 Dobrý nápad, jenže pokud budu chtít zmapovat budovy v celém městě/vesnici,
 kde zatím vůbec žádné nejsou, bude to stále ještě hodně pracné. Nebylo by
 pro tyto případy lepší provést tento import podobně jako import UIR-ZSJ?
 Pomocí skriptu by se vytvořil .osm soubor obsahující budovy z RÚIAN z daného
 katastru. Otevřel by se v JOSM jako nová vrstva. Tato vrstva by se porovnala
 s jinými zdroji a nesrovnalosti by se ručně opravily. Soubor by se uložil a
 dalším skriptem (který by doplnil source=ruian apod.) poslal do databáze
 OSM.
 O programování toho ale moc nevím, takže možná navrhuju něco, co není
 prakticky proveditelné.


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


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

Re: [Talk-cz] import budov

[LM_1]

Uvažoval jsem přesně takto.
Není i dnes většina adresních bodů z importů? Ty ručně dělané budou
pravděpodobně správně...
LM

Dne 1. srpna 2012 13:05 Miroslav Šulc fordf...@fordfrog.com napsal(a):
 Dne 1.8.2012 01:08, LM_1 napsal(a):
 Vlastní tagy obecně nejsou problém, ale měly by být popsané. Určitě
 bych byl pro zachování nějaké jednoznačné identifikace ruian:id nebo
 ref:ruian, to je jedno.
 Ty tagy pro bota se mi moc nelíbí proto, že nevypovídají nic o objektu
 na kterém jsou a není to ani dočasné řešení jako bylo odbl=clean.
 Srozumitelnost existujícího tagu pro neseznámené by asi byla jasná,
 ale způsob způsob jak dojít od bodu který se mi občas někam chybně
 přesune k tomu, že mám použít zvláštní tag už tak jasná není. Možá
 bych volil kompromis, že by bot hlídal posledního autora (to by
 nemuselo být tak složité) a nebo svůj bot=yes tag, který by při
 editaci odstranil - stal by se posledním autorem a nebyl by už
 potřeba. Nikomu by neutíkaly body.

 jestli jsem to dobře pochopil, tak navrhuješ, že pro bota by znamenalo,
 že se o bod má starat v případě, že buď je posledním editorem nebo je na
 bodu tag ruian:bot=yes. takže jakákoliv editace bodu by znamenala, že
 se o něj bot přestane starat. pro navrácení bodu botovi by pak bylo
 nutné přidat ruian:bot=yes. to podle mě zní rozumně. sice to postrádá
 tu úplnou jednoduchost, letmým pohledem není zřejmé, jestli se bot o ten
 bod stará nebo ne (člověk musí znát pravidlo o posledním editorovi, což
 většina mapperů asi vědět nebude), ale na druhou stranu mapper o botovi
 nemusí vůbec vědět a i tak by vše mělo fungovat správně, tj pokud je bod
 umístěný špatně, tak ho mapper zedituje a tím ho vyjme z kontroly bota.
 jak ho vrátit botovi už vědět nebude, ale to se dá někde popsat (třeba v
 tom mailu, který bude bot generovat). výhoda je určitě ta, že se u
 většiny bodů nebudou osm data zanášet dalším tagem. akorát při prvotním
 importu bude muset bot tohle pravidlo ignorovat, jinak by nic neudělal.
 a před importem bude potřeba ručně otagovat body, které jsou v rúian
 špatně umístěné, tagem ruian:bot=no.

 ff

 LM

 Dne 1. srpna 2012 0:56 Miroslav Šulc fordf...@fordfrog.com napsal(a):
 ono by se to třeba i dalo nějak vymyslet, aby to fungovalo bez tagu, ale
 postrádalo by to jednu důležitou vlastnost - jednoduchost. jednak bot by
 se musel rozhodovat na základě složitějších pravidel než jen bot=yes
 = můžu měnit, bot=no = nesahat, což by mohlo způsobovat
 chyby/nedorozumnění/mylné předpoklady. a to samé by se týkalo i mapperů.
 nikdo si nebude pamatovat složitá pravidla, na základě jakých se bot o
 body stará. ale jednoduché pravidlo bot=yes = bot se o bod stará,
 bot=no = bot na bod sahat nebude, pouze pošle info pro případný ruční
 zásah, to si myslím z toho tagu vyplývá samo a i nový mapper bota
 neznající by měl bez problému tenhle závěr z toho tagu vyvodit.

 píšu tu o tagu bot, ale v praxi by to možná mohl být spíš tag
 ruian:bot=yes|no. z toho by bylo zřejmé, že tag se týká jen a pouze
 bota, který pracuje nad rúian daty. stejně tak by asi mohl existovat tag
 ruian:id=kod z ruian (jeho asi jediný přínos ale vidím v tom, že v
 případě přejmenování ulice/změny čísla by se zachovala historie, jinak
 pro fungování bota asi není nezbytný). nicméně zatím nevím, jak je to
 přesně s custom tagy, sice jsem něco na osm wiki našel, ale nevyplynulo
 mi z toho nějaké pravidlo nebo předepsaný postup.

 ff

 Dne 31.7.2012 23:00, LM_1 napsal(a):
 Dalo by se uvažovat o posuzování jednotlivých argumentů (tagů, pozice)
 individuálně (člověk posune - bot už hýbat nebude, ale klidně změní
 číslo při přečíslování ulice nebo název při změně názvu)

 Změna ve zdrojových datech by mohla sloužit pro navrácení dané hodnoty
 do správy botovi - když se změní hodnota ve zdrojových datech,
 předpokládáme i změnu v realitě a tím zneplatnění původní lidské
 úpravy. To by mělo vyloučit většinu soubojů mezi člověkem a strojem.

 Lukáš Matějka (LM_1)

 Dne 31. července 2012 14:44 Miroslav Šulc fordf...@fordfrog.com 
 napsal(a):
 o tomhle jsem taky uvažoval, má to ale jednu nevýhodu. neumožňuje to bod
 vrátit do správy botovi. stejně tak pokud by někdo jen přidal nějaký
 další tag k adresnímu bodu, tak by se bot taky přestal o ten bod starat,
 i když by se o něj měl starat dál.

 ff

 Dne 31.7.2012 14:15, LM_1 napsal(a):
 Nejsou systémy s tagováním bot/nobot moc komplikované? Co kdyby se bot
 podíval na autora poslední změny daného bodu a pokud by to byl on sám
 tak by ho upravil podle potřeby, pokud by to byl někdo jiný tak by jen
 vygeneroval upozornění.
 LM_1
 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-cz

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

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

Re: [Talk-cz] import budov

[LM_1]

Nejsou systémy s tagováním bot/nobot moc komplikované? Co kdyby se bot
podíval na autora poslední změny daného bodu a pokud by to byl on sám
tak by ho upravil podle potřeby, pokud by to byl někdo jiný tak by jen
vygeneroval upozornění.
LM_1

Dne 30. července 2012 11:33 Miroslav Šulc fordf...@fordfrog.com napsal(a):
 Dne 30.7.2012 03:02, Lukas Kohout napsal(a):

 On 30.7.2012 2:20, Miroslav Šulc wrote:

 Dne 30.7.2012 00:59, Lukas Kohout napsal(a):

  On 28.7.2012 23:15, Miroslav Šulc wrote:

 možná nejlepší řešení by bylo adresní body naimportovat/zaktualizovat
 automaticky, akorát případy, kdy už adresní bod existuje a je od toho v
 rúian vzdálený víc než x jednotek by se řešily poloautomaticky. možná by
 nebylo špatné napsat si nějaký testovací skript, který by zjistil, jak
 moc se aktuální data v osm liší od rúian. z toho by se pak dalo ledaco
 vyčíst. až se mi doimportují osm data do db, tak to můžu zkusit napsat a
 uvidíme, co tu vlastně řešíme.

 Zdravím, navrhuji udělat možnost vyřadit oblast z automatického
 importu/aktualizace. V naší vesnici jsou některé adresní body chybně
 umístěné, některé chybí úplně. Asi bych nebyl nadšený, kdyby mi je
 nějaký bot stále dokola automaticky přesouval/mazal (zrovna dnes jsem
 doplňoval jedno č.p. podle nálepky na popelnici, což je možné jen v
 neděli večer :) )

 chybně umístěné znamená co přesně? posunuté o kolik metrů? podle my bě
 skript neměl měnit body, které jsou od sebe vzdáleny víc jak x metrů (tj
 rúian vs osm), ale měl by je někam vypsat. tyhle by se pak museli
 zkontrolovat ručně. kolik jich bude, by mělo vyplynout z analýzy rozdílů
 mezi rúian a osm, kterou mám v plánu udělat.

 k těm chybějícím bodům? znamená to, že tam máte nějaká čp, o kterých
 rúian neví?

 Materiály ke zkoumání:
 http://maps.fordfrog.com/?lat=50.05843lon=15.19497zoom=18layers=0B0FTF
 (nástroj špatně zpracovává permalink...


 ten permalink jsem opravil. včera jsem předělával zobrazení souřadnic, aby
 bylo v epsg:4326 (tj stejné jako osm) a rozbil jsem tím permalink.


 Do pozornosti doporučuji čísla 125, 126, 127, 133, 162 (ty 3 rozestavěné
 domy u hlavní jsou již minimálně rok obydlené, zítra je obejdu se psem) a ve
 střední části vesnice pak 16, 7, 9, 10 - tam rúian označuje čísla
 (zbořených) stodol.


 ty posuny jsou dost znatelné, to by se mělo dát odchytit. co se týká těch
 čísel nezanesených do rúian, tam bych asi volil nějaký tag typu nobot,
 který by bod chránil před botem. body tohohle typu by navíc měly vyjet z
 toho porovnávacího skriptu, takže by se daly před importem ručně
 odkontrolovat (pokud jich nebude moc) a otagovat tagem nobot, aby na ně
 bot nesahal.



 Naopak ve vedlejší obci je předchozí import nějak rozházený, něco tam i
 chybí a tam by změna podle rúian znamenala značné zlepšení:
 http://maps.fordfrog.com/?lat=50.05772lon=15.21386zoom=18layers=0B0FTF


 koukám, že ta tvoje oblast je ideální na příklady nesrovnalostí :-)


 jinak někde na osm wiki jsem četl o tagu bot nebo tak nějak (teď to
 nemůžu najít). podle mě automaticky spravované adresní body by měly
 tenhle tag mít. pokud by pak někdo bod přesunul, protože je umístěný
 špatně, tak by mu ten tag smazal a tím pádem by skript ten bod přestal
 aktualizovat, max by někam vypsal změny pro daný bod, pokud k nim dojde.
 takových bodů bude v porovnání s těmi cca třemi miliony minimum, takže
 případné změny (kterých taky asi bude minimum) by se daly zvládat ručně,
 pokud bude potřeba je do osm zanést.

 LuKo

 ff

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


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

Re: [Talk-cz] Značení uzavírky a objízdných tras

[LM_1]

Objízdné trasy (oražovými značkami vymezená trasa po existující
silnici, ne provizorně budované nové silnice) by nemělo být potřeba
zakreslovat, navigace by měla sama zvolit vhodnou objízdnou trasu.
Kudy vedou doporučené průjezdní trasy (ve větších městech) taky v mapě
není. A navigace často zvolí jinou trasu (třeba kratší přes město,
odkud má značená trasa odvést dopravu)

Lukáš Matějka (LM_1)

Dne 31. července 2012 15:11 Lukas Kohout l...@luko.name napsal(a):
  Zdravím,

 stále se v OSM rozkoukávám a nyní řeším, jak zpracovat poměrně zásadní
 dvouměsíční uzavírku I/38 v Kolíně. Viz
 http://www.mukolin.cz/cz/o-meste/06598-planovana-uzavirka-silnice-c-i-38-vjezd-do-kolina-od-kutne-hory.html
 . Vytvořit uzavírku (snad) umím. Dají se do mapy vložit i objízdné trasy,
 aby s nimi počítala navigace? Díky za případnou radu či nakopnutí směrem k
 tématu, kde se to již řešilo (zatím jsem nebyl v hledání úspěšný).

 LuKo

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

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

Re: [Talk-cz] import budov

[LM_1]

Dalo by se uvažovat o posuzování jednotlivých argumentů (tagů, pozice)
individuálně (člověk posune - bot už hýbat nebude, ale klidně změní
číslo při přečíslování ulice nebo název při změně názvu)

Změna ve zdrojových datech by mohla sloužit pro navrácení dané hodnoty
do správy botovi - když se změní hodnota ve zdrojových datech,
předpokládáme i změnu v realitě a tím zneplatnění původní lidské
úpravy. To by mělo vyloučit většinu soubojů mezi člověkem a strojem.

Lukáš Matějka (LM_1)

Dne 31. července 2012 14:44 Miroslav Šulc fordf...@fordfrog.com napsal(a):
 o tomhle jsem taky uvažoval, má to ale jednu nevýhodu. neumožňuje to bod
 vrátit do správy botovi. stejně tak pokud by někdo jen přidal nějaký
 další tag k adresnímu bodu, tak by se bot taky přestal o ten bod starat,
 i když by se o něj měl starat dál.

 ff

 Dne 31.7.2012 14:15, LM_1 napsal(a):
 Nejsou systémy s tagováním bot/nobot moc komplikované? Co kdyby se bot
 podíval na autora poslední změny daného bodu a pokud by to byl on sám
 tak by ho upravil podle potřeby, pokud by to byl někdo jiný tak by jen
 vygeneroval upozornění.
 LM_1

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


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

Re: [Talk-cz] Značení uzavírky a objízdných tras

[LM_1]

Rozumím tomu, proč bych jako řidič chtěl vědět, kudy vede oficiální
objízdná trasa, ale co vím tak žádná navigace tuto možnost
nepodporuje.
LM

Dne 31. července 2012 23:36 Lukas Kohout l...@luko.name napsal(a):
  Právě z důvodu, že jsou objížďky kvůli kamionům tak dlouhé (viz
 http://www.mukolin.cz/prilohy/Zpravy/598/37dio_kolin_i_38_vedeni_objizd_tras.pdf),
 jsem chtěl o nich dát vědět řidičům předem. Jeli by pak třeba rovnou po
 Černokostelecké a zbytečně nezatěžovali již tak přetížené objízdné trasy.
 Navigace sama může najít krátkou objížďku, která je příjezdová do pískovny a
 jezdí tam těžké kamiony, avšak nyní tam bude omezení na 7 tun.

 LuKo




 On 31.7.2012 22:54, LM_1 wrote:

 Objízdné trasy (oražovými značkami vymezená trasa po existující
 silnici, ne provizorně budované nové silnice) by nemělo být potřeba
 zakreslovat, navigace by měla sama zvolit vhodnou objízdnou trasu.
 Kudy vedou doporučené průjezdní trasy (ve větších městech) taky v mapě
 není. A navigace často zvolí jinou trasu (třeba kratší přes město,
 odkud má značená trasa odvést dopravu)

 Lukáš Matějka (LM_1)

 Dne 31. července 2012 15:11 Lukas Kohoutl...@luko.name  napsal(a):

   Zdravím,

  stále se v OSM rozkoukávám a nyní řeším, jak zpracovat poměrně
 zásadní
 dvouměsíční uzavírku I/38 v Kolíně. Viz

 http://www.mukolin.cz/cz/o-meste/06598-planovana-uzavirka-silnice-c-i-38-vjezd-do-kolina-od-kutne-hory.html
 . Vytvořit uzavírku (snad) umím. Dají se do mapy vložit i objízdné trasy,
 aby s nimi počítala navigace? Díky za případnou radu či nakopnutí směrem
 k
 tématu, kde se to již řešilo (zatím jsem nebyl v hledání úspěšný).

  LuKo

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

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



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

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

Re: [Talk-cz] import budov

[LM_1]

Vlastní tagy obecně nejsou problém, ale měly by být popsané. Určitě
bych byl pro zachování nějaké jednoznačné identifikace ruian:id nebo
ref:ruian, to je jedno.
Ty tagy pro bota se mi moc nelíbí proto, že nevypovídají nic o objektu
na kterém jsou a není to ani dočasné řešení jako bylo odbl=clean.
Srozumitelnost existujícího tagu pro neseznámené by asi byla jasná,
ale způsob způsob jak dojít od bodu který se mi občas někam chybně
přesune k tomu, že mám použít zvláštní tag už tak jasná není. Možá
bych volil kompromis, že by bot hlídal posledního autora (to by
nemuselo být tak složité) a nebo svůj bot=yes tag, který by při
editaci odstranil - stal by se posledním autorem a nebyl by už
potřeba. Nikomu by neutíkaly body.
LM

Dne 1. srpna 2012 0:56 Miroslav Šulc fordf...@fordfrog.com napsal(a):
 ono by se to třeba i dalo nějak vymyslet, aby to fungovalo bez tagu, ale
 postrádalo by to jednu důležitou vlastnost - jednoduchost. jednak bot by
 se musel rozhodovat na základě složitějších pravidel než jen bot=yes
 = můžu měnit, bot=no = nesahat, což by mohlo způsobovat
 chyby/nedorozumnění/mylné předpoklady. a to samé by se týkalo i mapperů.
 nikdo si nebude pamatovat složitá pravidla, na základě jakých se bot o
 body stará. ale jednoduché pravidlo bot=yes = bot se o bod stará,
 bot=no = bot na bod sahat nebude, pouze pošle info pro případný ruční
 zásah, to si myslím z toho tagu vyplývá samo a i nový mapper bota
 neznající by měl bez problému tenhle závěr z toho tagu vyvodit.

 píšu tu o tagu bot, ale v praxi by to možná mohl být spíš tag
 ruian:bot=yes|no. z toho by bylo zřejmé, že tag se týká jen a pouze
 bota, který pracuje nad rúian daty. stejně tak by asi mohl existovat tag
 ruian:id=kod z ruian (jeho asi jediný přínos ale vidím v tom, že v
 případě přejmenování ulice/změny čísla by se zachovala historie, jinak
 pro fungování bota asi není nezbytný). nicméně zatím nevím, jak je to
 přesně s custom tagy, sice jsem něco na osm wiki našel, ale nevyplynulo
 mi z toho nějaké pravidlo nebo předepsaný postup.

 ff

 Dne 31.7.2012 23:00, LM_1 napsal(a):
 Dalo by se uvažovat o posuzování jednotlivých argumentů (tagů, pozice)
 individuálně (člověk posune - bot už hýbat nebude, ale klidně změní
 číslo při přečíslování ulice nebo název při změně názvu)

 Změna ve zdrojových datech by mohla sloužit pro navrácení dané hodnoty
 do správy botovi - když se změní hodnota ve zdrojových datech,
 předpokládáme i změnu v realitě a tím zneplatnění původní lidské
 úpravy. To by mělo vyloučit většinu soubojů mezi člověkem a strojem.

 Lukáš Matějka (LM_1)

 Dne 31. července 2012 14:44 Miroslav Šulc fordf...@fordfrog.com napsal(a):
 o tomhle jsem taky uvažoval, má to ale jednu nevýhodu. neumožňuje to bod
 vrátit do správy botovi. stejně tak pokud by někdo jen přidal nějaký
 další tag k adresnímu bodu, tak by se bot taky přestal o ten bod starat,
 i když by se o něj měl starat dál.

 ff

 Dne 31.7.2012 14:15, LM_1 napsal(a):
 Nejsou systémy s tagováním bot/nobot moc komplikované? Co kdyby se bot
 podíval na autora poslední změny daného bodu a pokud by to byl on sám
 tak by ho upravil podle potřeby, pokud by to byl někdo jiný tak by jen
 vygeneroval upozornění.
 LM_1
 ___
 Talk-cz mailing list
 Talk-cz@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-cz

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


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


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

Re: [OSM-talk] Naming disputes in Ukraine

[LM_1]

1. No, in this case Russian name should be in name:ru only. Since the
official language is Ukrainian this should be used.
2. The area should not be limited by sq km but by independent
administrative body (country or its autonomous part). If there is
official language, this should be used, if there is not one the most
common should be it.

Generally only name:language keys should be used in my opinion. It
does not cause editing wars - this issue is moved to rendering, which
is far easier to control. Even in undisputed areas there is added
information about the language...

LM_1

2012/7/25 Peteris Krisjanis pec...@gmail.com:
 (Skipping all this, because obviously you are not that well informed
 about how this situation with Ukraine came into being)


 So, my questions to you are

 1. The concrete question: Should all name tag in the Crimea be in
 Russian (with appropriate name:uk tags of course), even though the
 official language in Ukraine is Ukrainian?

 Oficial language in Ukraine is Ukrainian. Even Russia doesn't dispute
 that. So, *in my opinion*, no.

 2. The general question: What exactly is the local language in an area
 - can we come up with some rule of thumb that says if X% of people in
 an area of at least Y sq km use the language... or so?

 I think it always have been local *official* language.

 As always, for other languages, including Russian, there is name:ru=*
 tag.

 Cheers,
 Peter.




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

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

Re: [OSM-talk] Naming disputes in Ukraine

[LM_1]

2012/7/25 Miloš Komarčević kmi...@gmail.com:
 Hi,

 We had similar discussions in Serbia as well, since we need to support
 two writing systems at the same time (Cyrillic and Latin), and any
 official ethnic minority languages in areas where they are used.

 On Wed, Jul 25, 2012 at 11:39 AM, Volker Schmidt vosc...@gmail.com wrote:
 Basically the outcome - I hope I am summing up correctly - is that the name
 tags in Italy should contain the official names, which in Italy's bi- or
 sometimes multi-lingual areas appear in several languages on the official
 road signs.
 So the road sign says Bolzano-Bozen, hence the name tag is
 name=Bolzano/Bozen. In addition there will be name tags name:de=Bozen
 name:it=Bolzano.

 While this might reflect signs on the ground, it's bad from data
 structure point of view because there is no clue to what languages are
 stored in name= and how to process them if necessary (e.g. automatic
 transliteration).

 In the discussion some contributors pointed to the different approach in
 Switzerland.
 In Switzerland there is only one official name and that is the name in the
 local language. So it would be name=Genève, name:de=Genf, name:it=Ginevra


 Again, you don't know what language is stored in name=, but at least
 in this case adding also a name:fr would improve the situation.

 Which brings us back to the point Peteris Krisjanis made:

 name= without the context of a language is somewhat useless from the
 database point of view, apart from quick and dirty rendering of what
 is on the ground.

 A much better approach would be to dispose of it, and force having
 name:lang everywhere. Then one would be able to define e.g. on the
 administrative level (country, district, municipality) what languages
 to use/render on objects inside that relation.

 For example: for the whole of Italy relation you would have lang=it,
 but for the South Tyrol you would have lang=de;it (or whatever order
 is appropriate) which would take precedence. For any exceptions, you
 would add lang= on the object itself which would have highest
 priority...

 M

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

I agree
LM_1

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

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

[LM_1]

JOSM umí stáhnout všechny členy relace (pravděpodobně to dělá nějaký
plugin, který používám, asi relation toolbox) a v okně pro editaci
relace jsou pak všechny položky - tady lze snadno upravovat role.

Dne 25. července 2012 10:35 Petr Stehlik psteh...@sophics.cz napsal(a):
 Ahoj,

 prosím poraďte: ve Zlíně přibyly relace vyjadřující trasy MHD (zřejmě) a
 teď to zlobí při úplně obyčejné editaci - např. když rozdělím silnici
 Březnická (jen kliknu v JOSM na bod a dám Rozdělit cesty) tak validace
 před uploadem na mě vykřikne:

 Nalezena podezřelá data! Varování, člen pro roli prázdné má špatný
 typ - problém při kontrole rolí (2). 2 objekty: 31, 2 objekty: 31.

 Co s takovou relací? Odhaduji, že je špatně někde jinde, a jen ji
 rozzuří, že rozdělím cestu v místě, kudy taky vede. Jak to spravit? Ani
 nevím, jak najít, kde ta chyba skutečně je. Jak se tyto relace vlastně
 editují? Ta linka je tak dlouhá, že celou mapu té oblasti nenatáhnu
 naráz do JOSM...

 Díky,

 Petr

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

___
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 (was: Re: díry v silnicích I. třídy)

[LM_1]

Souhlasím, že na vlastní čáře tvořící cestu by měl být fyzický popis
(šířka, povrch, počet pruhů) - co se mění v průběhu cesty a jíná
označení společná pro více čar by měla být na relaci.
Navrhoval jsem za tím účelem nový typ relace[1], ale s moc velkým
ohlasem se nesetkal

[1]http://wiki.openstreetmap.org/wiki/Relations/Proposed/Group_Relation

LM_1

Dne 19. července 2012 16:43 Petr Holub ho...@ics.muni.cz napsal(a):
   Teoreticky by všechny silnice měly být tvořeny pouze jednou spojitou
   komponentou, zatím tomu tak není.
 
  Pozor, pokud za spojitou komponentu beres neprerusovanou way, tak to
  neni pravda, protoze way musis prerusit napr kvuli pridani casti silnice
  do relace ... Musel bys jeste kontrolovat, zda na sebe sou jednotlivy
  casti napojeny ve svych koncovych bodech a hledat jen takove, ktere ne.

 měl jsem na jazyku stejnou poznámku, ale taky si nejsem jist, jestli kolega
 myslí way

 každopádně tohlento je věc, co mě pěkně točí - někde je souběh nějaké blbosti
 s kusem silnice, takže si way tvořící tu silnici splitnu, ten kousek hodím do
 relace, co potřebuju, ale tím vpodstatě rozbiju tu silnici ... z jedné
 vytvořím tři, na kterých je třikrát stejná kopie tagů ... pak se něco změní,
 třeba oprava překlepu v čísle, a chudák, kdo to opravuje, musí sledovat, na 
 co
 všechno ta way navazuje a opravovat to natřikrát místo jednou?

 Karle, jak jsem psal, myslim, ze na to Jakub sel pres komponenty
 grafu (tj. maximalni souvisle podgrafy) - nebo aspon doufam, protoze
 to je IMHO postup, ktery dava smysl. Pro jistotu, at vime, o cem
 mluvim:
 https://en.wikipedia.org/wiki/Connected_component_%28graph_theory%29

 IMHO ten pristup se segmentovanim a vkladanim do relaci je docela
 prirozeny. Ciste teoreticky bys takhle mohl resit i oznacovani cisel
 silnic - zavedes relaci s cislem te silnice. Svym zpusobem by to mohlo
 byt spravne - resilo by to i situace, kdy se treba 2 cesty stejne urovne
 krizi na jednom kruhovem objezdu: co tam ma na kruhaci ma byt za tagy
 ref? Zretezeni nebo neco jineho? Kdyz se krizi 2 cesty dvou ruznych
 urovni pres kruhac, aby bylo videt, ze ten kruhac patri i k te ceste
 nizsi urovne.

 Petr


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

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

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

[LM_1]

Taky mi to tak dělalo, teď dostávám zprávy jednotlivě a gmail je řadí
do konverzací, funguje to celkem dobře.

Dne 18. července 2012 22:36 Michal Pustějovský
michal.pustejov...@seznam.cz napsal(a):
 Jakub j at kub.cz writes:

 PS: Odebírám list v digest módu a žere mi to diakritiku (viz citace
 níže plná otazníků). Máte někdo stejný problém?


 S digestem mám stejný problém. Řešení jsem zatím nenašel, místo toho si zprávy
 čtu na gmane.org.


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

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

Re: [Talk-cz] MTB mapa

[LM_1]

3) ještě ne, čekám až se trochu uklidní rozbouřené vody kolem změny licence
Lukáš Matějka

Dne 12. července 2012 17:22 Martin Tesar osm...@gmail.com napsal(a):
 Ahojte,

 diky za nazory,

 ad 1,2) nejvetsi zoom bude brzo opraveny, symboly postupne, nektere nove
 jsou ted prilis titerne, spatne citelne. Proto je idealni, ze se ozyvate a
 rikate co konkretne vadi a jak se to ma zlepsit.
 ad 3) Kominy budou. Moc jsem to ted nesledoval, ale uz nekdo udelal ten
 import dat od kominaru?
 ad 4) muze byt, uvidim, co to udela
 ad 5) Udelam to asi offsetovane jako v pripade MTB a KCT tras. Matne si
 vzpominam, ze uz jsem to jednou zkousel, ale z nejakeho duvodu to delalo
 problemy. Jakeho uz samozrejme nevim :)

 Ve vrstvach to bude, ale je to spis v dlouhodobejsim horizontu.

 Martin


 Dne 10. července 2012 22:12 Tomáš Kratina t.krat...@gmail.com napsal(a):

 ja furt verim ze to jednou bude ve vrstvach :) je to stale v planu ?

 2012/7/10 Petr Balíček pbali...@seznam.cz:
  Zdravim Martina Tesaře et al.
  mam opět několik námětů na zlepšení MTB mapy:
 
  1) Nefunguje největší zoom.
  2) Nešlo by tu hnusnou křiklavě červenou barvu nových značek trošku
  „zdecentnit“?
  3) Chybí značka pro tovární komíny.
  4) Vzhledem k určení mapy by asi „highway=path + bicycle=designated“
  mělo vypadat stejně jako „highway=cycleway“. Růžovou bych ale nechal pro
  abstraktní cyklotrasy.
  5) Pod cyklotrasou nejde moc dobře rozlišit tracktype.
 
  ___
  Talk-cz mailing list
  Talk-cz@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-cz

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



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


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

[LM_1]

Zrovna v případě MHD existuje více způsobů a validátor v JOSM a návody
na wiki nejsou úplně v souladu. Takže bych v tomoto případě MHD
ignoroval validátor a postupoval podle wiki - současná preferované
verze je dost pracná, ale má potenciál pokrýt mnoho různých problémů a
očekával bych, že bude stabilní.

Dávání gate na way souvisí s mapováním plotů i cest jako jednoduchých
čar. Až ve chvíli, kdy bude cesta značená jako oblast, bude mít smysl
řešit bránu jako čáru.

Lukáš Matějka

Dne 25. července 2012 12:41 jzvc j...@tpfree.net napsal(a):
 Dne 25.7.2012 12:20, Petr Stehlik napsal(a):
 jzvc píše v St 25. 07. 2012 v 10:59 +0200:
 Co s takovou relací? Odhaduji, že je špatně někde jinde, a jen ji
 rozzuří, že rozdělím cestu v místě, kudy taky vede. Jak to spravit? Ani
 nevím, jak najít, kde ta chyba skutečně je. Jak se tyto relace vlastně
 editují? Ta linka je tak dlouhá, že celou mapu té oblasti nenatáhnu
 naráz do JOSM...
 Neres to, jemu se jen nelibi, ze jednotlivi clenove relace nemaj
 pridelenou zadnou roli - ani nevim jestli pro tenhle ucel jsou nejaky
 rozumny nekde pouzivany.
 je někde RTFM pro mapování MHD? Rozděluju silnici, po které vede desítka
 spojů MHD, ale jen jeden si stěžuje, takže si pořád myslím, že je nějaká
 konkrétní chyba v té lince č.31.

 si stim nelam hlavu, validator hlasi spoustu nesmyslu.
 moc se mi to nelíbí - jakmile jednou začnu ignorovat validátor, můžu v
 mapě časem dělat chyby.

 Trochu mi to připomíná radu neřeš to varování při HTTPS o neplatném
 certifikátu... taky to normálně/obvykle nevadí, ale učí to špatné
 návyky.

 Jestli dokážeš přesně identifikovat, kdy je validátor přehnaně
 úzkostlivý, tak to napišme autorovi JOSM, ať ho trošku zrelaxuje...

 Petr

 Trebas prave kotrola roli v relacich - validator ti bude rvat na kazdy,
 kde jsou prvky bez role. Aby ji mely je sice celkem logickej pozadavek,
 ale pro spoustu ruznejch ucelu nenajdes nic pouzitelnyho. Dtto pokud
 vim, JOSM aktualne neumoznuje dat gate na way, coz nevim proc, kdyz gate
 v podobe bodu sem (v realu) jeste nevidel ... ;D. Rucne to tak samo
 udelat lze.

 Vis, pokud by existoval zpusob, ja to vyresit, nebudu ti psat neres to
 ... nehlede na to, ze uzasna zmena licence stejne rozbila mapu bnaprosto
 dokonale, takze nejaka dalsi chyba sem nebo tam to vubec nevytrhne.



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


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

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

Re: [Talk-cz] gps tracer - zapůjčení

[LM_1]

Podle zaměření tábora by mohla asi tak půlka účastníků mít smartphone,
pak by stačilo mít nachystanou příslušnou aplikaci, případně mapy
okolí. Pro android stačí apk soubor (osvědčil se mi Maverick), ostatní
platformy by asi potřebovaly připojení k netu. Aspoň by pak dětem
aplikace zůstala.
LM

Dne 25. července 2012 15:26 Jakub j...@kub.cz napsal(a):
 Ahoj mapeři - mám takovou prosbu v sobotu odjíždíme na tábor a na poslední
 chvíli se ukázalo, že dělám nějakou takovou divnou aktivitu na nějakém
 openstreetmap :-) takže vznikla myšlenka s tím seznámit děti a vůbec
 zmapovat nějakou část okolí. Přijde mi to super, naráží to na drobný
 technický nedostatek - mám jen jeden gps tracer a to je na skupinu dětí
 málo. Byl by někdo z Prahy (případně opravdu blízkého okolí, nemám moc
 časoprostor jet na druhou stranu republiky) ochoten na 14 dní zapůjčit
 nějaký gps tracer na tábor? Mám na mysli jakýkoli jednoduchý zařízení
 maximálně s waypointama - nic ultrasofistikovaného, stačí to co leží na dně
 vašich skříní. Potřeboval bych 1-3 kousky, aby to mělo pro děcka smysl.
 Předem díky za ochotu a odpověď, klidně i mimo konferenci - detaily
 dořešíme.

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

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

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

[LM_1]

Kromě pochopitelného nezájmu OSMF o jiné mapy bude takový editor
nerealizovatelný, jakmile se mapy začnou lišit (začnou).

LM_1

Dne 25. července 2012 23:00 Butrus Damaskus butrus.but...@gmail.com napsal(a):
 IMHO by mělo FOSM co nejdřív udělat editor, který by umožňoval zároveň
 editovat (přidávat věci) do obou map...

 2012/7/25 Jakub Sykora kub...@kbx.cz:
 V podstate pouze z tohoto duvodu pokracuji v OSM, protoze neverim, ze by se
 v dohledne dobe dala dohromady infrastruktura (at uz strojni nebo lidska),
 ktera by zivotaschopne prepnula na fork tech dat. A tady bohuzel kazdy den,
 kdy je FOSM v necem pozadu za OSM zpusobi, ze cast lidi do toho nepujde.


 Vedena (možná) dobrými úmysly provedla OSMF přelicencování hodně
 špatným způsobem a ukázala, že se nezajímá o názor komunity. To
 považuju za vážné zjištění. Řešením by mohl být FOSM fork, ale nejsem
 si jistý, zda je to životaschopný projekt, proto se skřípěním zubů
 pokračuji v editacích hlavní db a čekám, jak to celé dopadne.


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

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

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

[OSM-talk] Edit review: intermittent waters

[LM_1]

Hi,
I would like to support two ideas that appeared in this thread:
1. Peter Wendorff's about documenting discouraged/old tagging schemes
in wiki as such - with link to correct schemes.
2. Worst Fixers general idea of merging multiple tags describing the
same thing into one (possibly globally). That is if they really mean
the same.
Lukáš Matějka (LM_1)

2012/5/31 Russ Nelson nel...@crynwr.com:
 Worst Fixer writes:
    Persuade people to map just one way, THEN once they're doing that, go
    back and get rid of the old way.
  
   Sane people use type= for relation types.
   They use water= tag to express whether it is lake, pond, river or
   stream. Not how often it flows.

 You seem not to understand. Perhaps German is not your first language?
 Nobody is talking about the sanity or lack of sanity of editors except
 perhaps you. I'm talking about how people *actually* map. I think it's
 great that you're starting up a conversation on how we should
 interpret data not documented in the wiki. I'm NOT sure that we want
 to be *changing* data not documented in the wiki. Not sure at all. In
 fact, I'm pretty sure that we *shouldn't* be changing it. Sure that
 *you* shouldn't be changing it.

 Y'see, once you've made that change, one and only one interpretation
 of this undocumented data is available to everyone -- YOUR
 interpretation. You might be right, you might be wrong, but YOUR voice
 will prevail. Whereas, if we documented this data, and said Don't map
 like this -- map like that, then we accomplish two goals: 1) we let
 data users know what is the standard interpretation of this data, and
 2) we encourage editors to stop editing like this. You know
 ... without calling them insane.

 So yeah, you should stop making these edits, and if you won't stop, I
 support taking action to stop you.

 --
 --my blog is at    http://blog.russnelson.com
 Crynwr supports open source software
 521 Pleasant Valley Rd. | +1 315-600-8815
 Potsdam, NY 13676-3213  |     Sheepdog

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

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

Re: [Talk-cz] dotaz na tlačítko pro zobrazení datovývh prvků

[LM_1]

Vrstvu Data lze zobrazit přes rozbalovací menu schovené v tlačítku
Upravit nahoře (neklikat jen najet a menu se zobrazí)
LM

Dne 13. dubna 2012 9:02 Zdeněk Pražák zpra...@seznam.cz napsal(a):
 Na staré mapě před upgradem bylo k disposici tlačítko data, které umožňovalo
 získat informace o historii zobrazených mapových prvků. Nyní se toto
 tlačítko nezobrazuje.
 Lze nějakým způsobem získat na obrazovce informace o historii zobrazených
 mapových prvků.

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


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

[OSM-talk] Group relation proposal

[LM_1]

I have created a new proposal for group relation (type). It is
intended to reduce tagging duplication and make it easier to map dense
public transport areas by grouping ways that are used by multiple
transport lines (not having to add the same group to multiple route
relations).
The proposal is here:

http://wiki.openstreetmap.org/wiki/Relations/Proposed/Group_Relation

Please discuss or comment, preferably on the wiki discussion page.


Lukáš Matějka (LM_1)

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

Re: [Talk-cz] Import komínů

[LM_1]

Mě by se taky líbilo mít je jako oblasti (i když tagy bych na building
neměnil), ale realizace as zůstane na editorech OSM.
Každopádně jsem očekával trochu větší odezvu (pozitivní či negativní)

LM

Dne 12. března 2012 9:23 Jakub Sykora kub...@kbx.cz napsal(a):
 Me by se celkem libilo importovat jej nejen jako bod, ale jako building o
 patricnem pudorysu. Ovsem nevim, jestli eviduji neco jako je prumer
 kruhovych u zeme a pripadne u hranatych delku hrany - myslim, ze ne...

 K

 Dne 9.3.2012 23:04, LM_1 napsal(a):

 Tak jsem se ptal a s importem není ze strany KODA problém, otázka je
 co (a jak) importovat. Kromě faktu, že je někde komín, z jakého
 materiálu a jak vysoký mají informace o tvaru a přístupnosti.
 Co myslíte?

 Navrhuji:
 man_made=chimney
 height=1999
 material=metal|brick|concrete (způsob výstavby litý/tvárnice/segmenty)
 bych nechal na zvláštní databázi
 source=KODA nebo podobně
 ref:koda=číslo v koda - kvůli identifikaci a pořípadnému pozdějšímu updatu
 minimálně do poznánky tvar, ochozy, žebříky...

 Pro vlastní import by měly jít zrecyklovat skripty na import měst a
 vesnic (vyhledání bodu v okolí a přidání parametrů/vytvoření nového
 bodu...)


 Lukáš Matějka (LM1)

 Dne 18. února 2012 0:21 LM_1flukas.robot+...@gmail.com  napsal(a):

 Nejsem si jist, jestli to pojmosloví co je na stránkách komínáři fakt
 používají, nebo je to specifický druh humoru spolku podivínů, ale data
 o komínech mají v hojném počtu a vypadá to, že celkem přesná, takže
 jsem pro import.
 Poptám se, jak by se k importu stavěli.

 Lukáš Matějka (LM_1)

 Dne 17. února 2012 22:29 Petr Schönmannpschonm...@gmail.com  napsal(a):


 Ahoj všem v konferenci !
 Narazil jsem na docela zajímavá data, která by nebylo špatné mít v mapě
 zanesená. Přeci jen komín je docela dobrým orientačním bodem. Našel by
 se
 někdo kdo by import provedl, zjistil podmínky, licence. Info najdete na.

 http://koda.kominari.cz/

 Pěkný víkend.

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


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


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

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

Re: [Talk-cz] Import komínů

[LM_1]

Však se nic nestalo, hlavně, že se shodneme...
LM

Dne 12. března 2012 18:15 Petr Balíček pbali...@seznam.cz napsal(a):
 Tak v tom případě je na místě abych uznal svou chybu, na wiki sem komín 
 přehlíd (ale mam pocit, že se tam objevil až v nedávný době). Jenom je škoda, 
 že ještě neni v Mapniku.
 PB

  Původní zpráva 
 Od: LM_1 flukas.robot+...@gmail.com
 Předmět: Re: [Talk-cz] Import komínů
 Datum: 12.3.2012 18:06:02
 
 Zdravím,
 man_made=chimney je používaný, zdokumentovaný na wiki, je v
 předvolbách JOSM a zdál se mi nejlepší. Není to ale něco, na čem bych
 dogmaticky trval; pokud se najde lepší alternativa, tak se jí bránit
 nebudu (akorát o žádné nevím).
 LM_1

 Dne 12. března 2012 16:12 Petr Balíček pbali...@seznam.cz napsal(a):
  Zdravim
 
  Přestože já osobně nemam importy moc v oblibě, tak tenhle nápad se mi 
  celkem
 líbí. Problém vidim jenom v použití (nechápu proč) neoficiálního tagu
 „man_made=chimney“.
  Na druhou stranu by hromadnej import zvýšil jeho výskyt, takže by to 
  napomohlo
 protlačení do oficiálních „Map Features“.
  Za mě teda palec nahoru.
 
  PB
 
   Původní zpráva 
  Od: LM_1 flukas.robot+...@gmail.com
  Předmět: Re: [Talk-cz] Import komínů
  Datum: 12.3.2012 11:48:48
  
  Mě by se taky líbilo mít je jako oblasti (i když tagy bych na building
  neměnil), ale realizace as zůstane na editorech OSM.
  Každopádně jsem očekával trochu větší odezvu (pozitivní či negativní)
 
  LM
 
  ___
  Talk-cz mailing list
  Talk-cz@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-cz

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




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

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

Re: [OSM-legal-talk] Feedback requested ... OSM Poland data

[LM_1]

Verfication would be a process of comparing my own data (lets's call
them A) with osm, likely using some automated precess, that would
output a set of locations or areas where the maps differ more than a
given threshold (dataset B).
Legally you now have three datasets A, OSM and a derivative work of
both (B). Dataset B would be used as a to-do list to resurvey or
reimport data from other sources than OSM. OSM data is not copied, but
were used for verification.
This should actually be completely legal now - derivatives works are
allowed, if not published no specific licence character is required.
Actual data for updating is taken from somewhere else.

If the clause is added that data verification requires publication
under free/open licence, it would actually tighten the licence, since
I highly doubt that independently acquired data on places where maps
differ could be treated as derivative work.

LM_1
2012/3/10 Rob Myers r...@robmyers.org:
 On 09/03/12 22:36, LM_1 wrote:
 Why not make this rule general (outside Poland) any data published
 under free and open licence (whatever it is) can be verified by OSM
 data.
 This brings no risk, that anyony big and evil (whatever that is)
 will use it to overrun OSM...
 LM_1

 What is verification?

 If it is altering data to recreate OSM data, we are using verification
 to excuse copying.

 If it is looking at the map, we are using verification to damn reading
 a map.

 So I'm not sure verification is a useful term. Describing the boring
 mechanical actions that are being performed is probably more useful, as
 these are easier to consider against the actions permitted by the licence.

 - Rob.

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

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

Re: [OSM-talk] No attribution on osm.org?

[LM_1]

Isn't the question more How should any other user attribute OSM?
than Is it legally sufficient?? I believe that it should generally
be on the main page (next to map or overlaid) and not somewhere deep
in legal/copyright section that none except for lawyers ever reads.
osm.org should set the example for others in this matter...
LM_1

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

Re: [OSM-talk] Separate lane tagging

[LM_1]

I somehow forgot to react on this one.

2012/3/5 Martin Koppenhoefer dieterdre...@gmail.com:
 Am 5. März 2012 12:08 schrieb LM_1 flukas.robot+...@gmail.com:
 Currently the recommendation about separate mapping of directions
 seems to be the existence of a physical divider (wall, grass...).
  There is no problem if the divider is continuous and only has
 'holes' in it to allow turning or lane changing during construction
 works.


 when there are holes you will obviously have to split the divider
 and keep the holes free.


Sure, this question was not about dividers, but about the streets around.

 If the divider is only a small object like tram platform, it does not
 seem right to divide the way and connect it afterwards.


 why not? IMHO you should so exactly this. There are also similar
 situations like subway entrances and pedestrian crossing islands where
 the carriageway is split.


Not, because it seems like the road is curved, while it is not (or
very little).
  If this is mapped according to the recommendation the street would
 be between two rails (trams cannot change rails), which is not true.
  If each of the one way general traffic roads is mapped separately,
 it would seem that you cannot turn (you are not allowed to, but it is
 physically possible).


 This whole physically possible field merits some further
 considerations and discussions IMHO. First of all: physically possible
 for whom? An old lady with a stick? A battle tank? A generic young
 male acting as pedestrian? Possible with a vehicle with 2 axes 4
 metres long and 1.8 wide or one 18 metres long and 2.3 metres wide?
 Would a cyclist dismantle and lift his bike over a small fence to
 avoid 3 km of detour? Would you risk damaging the tyres of your car
 (could still be physically possible) or do you prefer not to? This
 all depends on a lot of different factors.

In this case physically possible for all the examples you mentioned.
The road has almost same surface quality across the whole width, the
only thing that is stopping you is a white line.
Adhering to the rules creates completely misleading results and
ignoring them by tagging the current legal situation makes physically
connected way look like a street with separated directions...

 For instance some time ago some mappers started to use
 highway=footway, footway=sidewalk to map sidewalks with dedicated
 osm-ways. This will in many cases actually lead to worse routing
 results, as a destination just on the other side of the road will make
 your router suggest to go via the next crossing (however far that
 might be), instead of telling you that you have already arrived.


 cheers,
 Martin
LM_1

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

Re: [OSM-legal-talk] Feedback requested ... OSM Poland data

[LM_1]

Why not make this rule general (outside Poland) any data published
under free and open licence (whatever it is) can be verified by OSM
data.
This brings no risk, that anyony big and evil (whatever that is)
will use it to overrun OSM...
LM_1

2012/3/9 Ian Sergeant inas66+...@gmail.com:
 Indeed.

 My point is we can discuss it here on legal-talk, and get the opinions of a
 handful of people are hung up on the legals and the licence change already.
   Or we can put it to the vote, and I'm confident in the wider community
 that we'd get the support of the 75% required to permit Polish OSM data to
 be used for verification only, and as long as the resulting data is released
 under a free and open licence.

 It is hard for me to imagine an average active mapper who has mapped their
 local streets, and a POI here and there, would rather see Poland wiped from
 OSM rather than give another organisation which is also distributing under a
 free and open licence the use of our data just to verify their own.
 Especially when it is probably permitted under our licence anyway, we'd just
 be confirming that it is okay to avoid doubt.

 Ian.


 On 10 March 2012 07:36, Rob Myers r...@robmyers.org wrote:

 On 09/03/12 10:59, Ian Sergeant wrote:
 
  I can't see who would have a problem with this.

 Hi. ;-)

 - Rob.

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



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


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

Re: [Talk-cz] Import komínů

[LM_1]

Tak jsem se ptal a s importem není ze strany KODA problém, otázka je
co (a jak) importovat. Kromě faktu, že je někde komín, z jakého
materiálu a jak vysoký mají informace o tvaru a přístupnosti.
Co myslíte?

Navrhuji:
man_made=chimney
height=1999
material=metal|brick|concrete (způsob výstavby litý/tvárnice/segmenty)
bych nechal na zvláštní databázi
source=KODA nebo podobně
ref:koda=číslo v koda - kvůli identifikaci a pořípadnému pozdějšímu updatu
minimálně do poznánky tvar, ochozy, žebříky...

Pro vlastní import by měly jít zrecyklovat skripty na import měst a
vesnic (vyhledání bodu v okolí a přidání parametrů/vytvoření nového
bodu...)


Lukáš Matějka (LM1)

Dne 18. února 2012 0:21 LM_1 flukas.robot+...@gmail.com napsal(a):
 Nejsem si jist, jestli to pojmosloví co je na stránkách komínáři fakt
 používají, nebo je to specifický druh humoru spolku podivínů, ale data
 o komínech mají v hojném počtu a vypadá to, že celkem přesná, takže
 jsem pro import.
 Poptám se, jak by se k importu stavěli.

 Lukáš Matějka (LM_1)

 Dne 17. února 2012 22:29 Petr Schönmann pschonm...@gmail.com napsal(a):

 Ahoj všem v konferenci !
 Narazil jsem na docela zajímavá data, která by nebylo špatné mít v mapě
 zanesená. Přeci jen komín je docela dobrým orientačním bodem. Našel by se
 někdo kdo by import provedl, zjistil podmínky, licence. Info najdete na.

 http://koda.kominari.cz/

 Pěkný víkend.

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


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

[OSM-talk] Separate lane tagging

[LM_1]

Currently the recommendation about separate mapping of directions
seems to be the existence of a physical divider (wall, grass...).
  There is no problem if the divider is continuous and only has
'holes' in it to allow turning or lane changing during construction
works.

If the divider is only a small object like tram platform, it does not
seem right to divide the way and connect it afterwards. This is usual
on streets with tram rails in the middle.
  The cross-section of such street would be:

sidewalk | optional grass verge | one direction lane(s) | optional
stop platform | tram rail,usable by buses | (the same in reverse for
other direction). See [1], [2]

  If it is mapped all as one way it is not very accurate (only one
rail, where two are the fact, platforms next to street when they are
in the middle - between car lane and rail.
  If this is mapped according to the recommendation the street would
be between two rails (trams cannot change rails), which is not true.
  If each of the one way general traffic roads is mapped separately,
it would seem that you cannot turn (you are not allowed to, but it is
physically possible). And the buses would need a separate highway
because they use the rail area... That is even more complicated by the
fact, that the rail area can sometimes be used by other vehicles
(general traffic) as well.

Any ideas/thoughts how to map these situations?

[1] http://cs.wikipedia.org/wiki/Soubor:Brno,_Veveří,_Údolní(1).jpg
[2] http://www.mapy.cz/#x=16.597184y=49.198315z=19

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

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

[LM_1]

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)

Dne 27. února 2012 14:32 Petr Morávek [Xificurk]
xific...@gmail.com napsal(a):
 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


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


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

Re: [Talk-cz] dotaz na JOSM - špatné popisování provedených změn

[LM_1]

U mě ne, používám josm-latest verzi
LM

2012/2/22 Zdeněk Pražák zpra...@seznam.cz:

 až nyní jsem si všiml, že při ukládání úprav v JOSM se mi špatně 
 pojmenovávají provedené změny.
 Popis změn je vždy posunut o jednu změnu zpět
 například v Sadě změn: 10751088 se zobrazil popis budovy Přeštěnice, zatímco 
 správně mělo být budovy Radihošť, což se zobrazilo u změny č. 10751202
 Používám JOSM 4875

 Projevuje se toto chování i u někoho jiného?

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

___
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

[LM_1]

start_date v. valid_from
Nejde o to, že jeden je lepší nebo horší, podle mě jsou tak asi
nastejno, takže bych se přiklonil na stranu aktuálního vítěze. Jde o
to, že dva různé klíče popisují tu stejnou věc bez dalšího důvodu. Pro
boundary=protected_area nejsou na taginfo statistiky, ale pro
protection_title je to ve prospěch start_date 2000 : 500
Myslím, že start_date by tam určitě být mělo a valid_from kdyžtak
přidat jenom navíc kvůli kompatibilitě s tím Fr. importem (ale ideálně
jen start_date)

Dočasný tag pro mapnik bych nepoužíval, ale když jsou to jen čtyři
parky tak je to opravdu celkem jedno.

site_zone se používá málo (9×), ale zdá se, že je to jediný
zdokumentovaný a používaný klíč, takže nejlepší volba. Jestli tomu
dobře rozumím tak, by tam měly být vnořené multipolgony označující ty
zóny a všechny by měly být členem nadřazené relace kvůli seskupení.
Najít na mapě to neumím.

Lukáš Matějka (LM_1)

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

Re: [Talk-cz] Import poboček a bankomatů ČS as

[LM_1]

Velmi zběžným pohledem mi připadalo, že data jsou vcelku konzistentní
a překlad dnů by stačil - spolu se změnou čárek na středníky. Většinou
by se to asi dalo zjednodušit vytvořením rozsahu dnů, ale mělo by to
vcelku fungovat i bez toho.
K updatům bych se stavěl jako k původnímu importu. Už by na to byly
připravené skripty a situace by byla v zásadě stejná - někde se doplní
data, někde se přidá fixme, že bankomat je možná jinde nebo tam už
není.

Lukáš Matějka

2012/2/20 Karel Volný ka...@seznam.cz:

 zdar,

 tak naokraj ...

 Dne Po 20. února 2012 15:27:29, Petr Schönmann napsal(a):
 2, v cmt značkách je uvedeno hodně často otevírací doba pobočky, šlo by
 to při importu zohlednit ? Bohužel data nejsou nijak strojově
 předpřipravená jednou jsou tak jednou onak. Bylo by též záhodno
 překonvertovat dny v týdnu na anglické názvy tj. Po  Mo aby se pak údaje
 mohli rendrovat pripadne pouzivat v aplikacich ktere s nimi umi pracovat.

 samotný překlad do angličtiny je dost málo -

 http://wiki.openstreetmap.org/wiki/Key:opening_hours

 - známe?

 a ještě detail, jak se vypořádat s případnými updaty?

 K.


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

___
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

[LM_1]

Ahoj

 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ů:
Jsem pro
  - 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?)
To by mělo záležet na názvu parku, většinou by tam asi to označení zůstalo
  - protect_class
  - ref
  - iucn_level
  - valid_from - pro rok vytvoření
Použil bych spíš start_date, je rozšířenější.
 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.

 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


 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

Lukáš Matějka

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

Re: [Talk-cz] typ lesa was Re: MTB mapa

[LM_1]

+2
Nic není moc detailní.

Lukáš Matějka (LM_1)
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Import komínů

[LM_1]

Nejsem si jist, jestli to pojmosloví co je na stránkách komínáři fakt
používají, nebo je to specifický druh humoru spolku podivínů, ale data
o komínech mají v hojném počtu a vypadá to, že celkem přesná, takže
jsem pro import.
Poptám se, jak by se k importu stavěli.

Lukáš Matějka (LM_1)

Dne 17. února 2012 22:29 Petr Schönmann pschonm...@gmail.com napsal(a):

 Ahoj všem v konferenci !
 Narazil jsem na docela zajímavá data, která by nebylo špatné mít v mapě
 zanesená. Přeci jen komín je docela dobrým orientačním bodem. Našel by se
 někdo kdo by import provedl, zjistil podmínky, licence. Info najdete na.

 http://koda.kominari.cz/

 Pěkný víkend.

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


___
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

[LM_1]

Souhlasím s body 1-6 Petra Morávka a s Lukášem Kabrtem.
Pokud je oblast definována zákonem jako jdoucí potokem/břehem/středem
silnice/podél administrativní hranice tak by měla využívat tyto prvky
jako svou hranici i v OSM.

To znamená ,že v relaci (multipolygonu) bude potok nebo část
multipolygonu waterway=riverbank. Pokud jde po silnici, tak bude
obsahovat silnici nebo jinou hranici.

Naopak pokud jde po břehu/kraji silnice tak by rozhodně neměla být
nijak napojena na vlastní čáru toku nebo silnice.

Důvodem je, že hranice bude následovat osud těchto prvků - při změně
toku potoka nebo trasy silnice se pohne i hranice oblasti. Platí to
samozřejmě i pro administrativní hranice, které jsou z definice
tvořeny potokem.

Úplně jiná situace by byla, kdyby byla hranice definována souřadnicemi
a náhodou šla podél něčeho, potom není spojování na místě.


V závislosti na přesnosti dat by nebylo od věci uvažovat o použití
tvarů pro zpřesnění těch cest/potoků...


@jzvc: Pokud budeš chtít hranici využít tak máš informace o tom, co tu
hranici tvoří, to s tím dost silně souvisí (i když se to nemusí vždy
hodit).


Tagy vztahující se k oblasti by samozřejmě měly být jen na tom
multipolygonu, na čárách jen servisní (source...) a označení hranice
(silnice, plot)

Protože jde o evropská data, budou pravděpodobně k dispozici ve více
zemích, bylo by proto vhodné se podívat jestli už někdo něco
neimportoval a pokud ano tak použít hotové nástroje a zachovat
konzistentní tagování. Pokud ne tak oznámit import i zahraničně, aby
to mohl udělat zahraniční importér stejně.

Lukáš Matějka (LM_1)


2012/2/15 jzvc j...@tpfree.net:
 Dne 15.2.2012 22:43, Lukas Kabrt napsal(a):
 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é).
 Hranice CHKO a asi i dalších chráněných území (aspoň těch
 velkoplošných) jsou definované nejen pomocí administrativních hranic,
 ale i různými přírodními hranicemi - řeka, silnice apod. Průběh
 hranice je určený ve vyhlášce o zřízení daného chráněného území -
 příklad [1]

 IMHO nejčistší řešení by bylo chráněná do OSM přidat jako relace, kde
 členové té relace by byli objekty (silnice, řeky, administrativní
 hranice), tak jak jsou definované v příslušné vyhlášce.
 Tohle by prave bylo dost nestastny, protoze se to pak blbe modifikuje.
 Silnice muze byt trebas z ruznych duvodu posunuta, ale to (predpokladam)
 nezmeni hranici chko. Vubec nemluve o tom, ze je to jen virtualni
 hranice = melo by to mit svoji caru se kterou lze pripadne nezavisle
 hybat. Je to stejny jako administrativni hranice, tam se taky kvuli
 udrzbe zavrhlo pouziti trebas potoku a je to samostatna cara, ac hranice
 vede trebas v ose vodniho toku. Jenze jinde vede po brehu a s chko to
 bude podobny ...

 + samozrejme pokud budu chtit tu hranici nejak vyuzit, trebas pro nejaky
 overlay, tak vazne nechci aby se mi zaroven s tim postahovali trebas
 znacky natagovane k silnici.

 Zkratka nemixoval bych v relacich fyzicke a virtualni objekty mapy.


 [1] old.ochranaprirody.cz/res/data/012/002287.pdf

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


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

___
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

[LM_1]

 Problem je prave trebas to, pokud ty hranice nekdo bude casem chtit
 automaticky ze zdroje aktualizovat = v pripade pouziti silnice, potoka
 ... nerealne.
Nereálné bych si tvrdit neodvážil, komplikované určitě. Ale data v OSM
by měla být především přesná a celistvá, ne sbírka nezávislých
importů. Pro takový případ by snad bylo lepší použít původní data.

 Navic, to tak nelze ani importovat, musel bys to nasledne
 komplet rucne predelat, coz anuluje smysl importu.
Neimportují se jen tvary, ale i další (hezká) data, Importem se
vytvoří multipolygony, u kterých je už snadné změnit část trasy.
Každopádně to je dobrý první stupeň. Dosažení ideálního stavu bude
vyžadovat ještě hodně práce, s tím souhlasím. Možná by nebylo od věci
zkopírovat do nějakého komentáře popis průchodu hranice, aby byl po
ruce při zpřesňování.
Krátce po příchodu k OSM jsem se ptal, jaká přesnost úprav je
požadována. Nejlepší odpověď byla Tak aby mapa byla přesnější než
před editací.

 Nehlede na to, sem
 nejaky to chko zakresloval a klickuje to ruzne podel silnic, okraju
 lesa, hranic administrativnich celku ... a nekde to vede klido
 prostredkem pole ... Kde to vedlo soubezne s admin hranicema, tak tam
 sem je vyuzil, ale i to je dost sporny.

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

Re: [OSM-legal-talk] ODbL implementation plan - extra phase proposal

[LM_1]

Generally there should be less incompatible data every day, however
there still some imports of non-copyrightable (PD, government
licensed) that were uploaded by users who did not agree to CT. Because
of this the incompatibility test would have to be re-run periodically.
(and maybe if some problems with the script get reported). Editors
being free to edit is the main purpose of this. Small scale deleting
of incompatible data before edit makes re-mapping easier and prevents
problems with broken relations and other connections that could be a
burden in the database for years.

What is hurting the community with regard to licence change is the
uncertainty what data will be lost and if really as much as statistics
suggest. If every editor has an easy way to make sure his edits remain
undeleted, and that he can edit without risking that it is futile no
harm will be done.

As pointed out, if the armageddon is postponed, people stop caring
(maybe not once they started), that was the point of API rejecting
non-compliant edits.

If the whole process of licence change takes so long, why should the
last phase (presumably most important one) - fixing what has to be
deleted - take so short.

Lukáš Matějka (LM_1)

2012/1/31 Jonathan Harley j...@spiffymap.net:
 On 30/01/12 23:41, LM_1 wrote:
 ...

 That said there are other ways to ensure the goal of this suggestion -
 seamless transition rather than deletions and angry/leaving
 contributors.

 One that comes to my mind and does not require any drastic changes
 would utilise filtering feature of JOSM (and required Potlatch to
 implement equivalent). Every night/week (depending on how demanding
 task it would be) each incompatible object would be tagged
 odbl=incompatible (server side). Editors would then make these objects
 non-editable/less visible...

 If API is not changed to serve the cleaned version of data, it would
 be good to have at least some editor-side tool to revert selected
 object to the clean state and then repair/edit it as it should be.

 In my original suggestion I said that this period (remapping what has
 to be deleted while still serving data under CC-BY-SA) should take a
 year or two - as long as needed till all the field in
 http://odbl.poole.ch/ show 99% or more. The time pressure is a false
 one, there has not really been any argument why it is important to
 change the licence fast.

 ...

 Non-CT-agreers can't make changes any more, right? So the tagging of objects
 odbl=incompatible would only need to be done once; the number can never go
 up, only down as editors replace those features. The tag would be visible in
 editors without any change (but would make it easy for editors to highlight
 those features and/or warn any user editing them) and it would make it
 crystal clear to all of us which features would be removed for the ODbL
 version when it arrives. That seems like a pretty good idea to me.

 We're coming up towards the 5 year mark on this so nobody can accuse us of
 moving too fast. Personally I'm feeling demotivated knowing that lots of my
 work is likely to be removed (although I've mapped other places from
 scratch, most of my edits around here have been corrections and
 improvements) and I haven't added anything for months. I know more clarity
 about exactly what's going to happen to the map would help me.

 I know we're still hoping that some CT refusers will change their minds, but
 I think we need a definitive decision at some point about exactly what is
 going to be done to which features - and that point needs to be BEFORE the
 license change is implemented - preferably well before. Tagging seems the
 obvious way to communicate that.


 Jonathan.

 --
 Dr Jonathan Harley   :    Managing Director    :   SpiffyMap Ltd

 m...@spiffymap.com      Phone: 0845 313 8457     www.spiffymap.com
 The Venture Centre, Sir William Lyons Road, Coventry CV4 7EZ, UK



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

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

Re: [OSM-legal-talk] The Copyright of Split Ways

[LM_1]

This discussion seems to be based on the assumption that being
original creator of certain object in database constitutes copyright.
That is not entirely true.
If I move each of the nodes of a way, the original creator can hardly
have any copyright in its shape. Even if I move a single node, that
section is not a creation of the original node's creator any more.
The same is true for tags.

Lukas (LM_1)


2012/1/30 Richard Fairhurst rich...@systemed.net:
 andrzej zaborowski wrote:
 (I thought it is i-i+j, at least in JOSM it was up to some point)

 It is. But it's very difficult to extract that with certainty from a
 non-trivial changeset. Add enough splits, and you may find i-i+j+k+l. Then
 add some merges and some deletes, and you possibly have [p+i]+j and [l+p]
 and an odd isolated section of k.

 Probably the only case in which you can actually check whether the user was
 splitting, or creating afresh but using some of the same (agreeing) nodes,
 is if they were using Potlatch 1's live mode. And I don't think that's been
 good practice for a while. ;)

 In any case if a way is an arrangement of node references + some
 tags, then if inside some changeset an arrangement of nodes and/
 or tags is reused, as in your example, then, even if the editor's
 split operation wasn't used to arrive at it, for practical purposes
 the effects is the same.

 Practical purposes, sure, but not IP purposes. If we're saying that there is
 IP in the sweat-of-the-brow required to create those tags or that
 arrangement of nodes, then we need to know whose brow was sweaty.

 cheers
 Richard



 --
 View this message in context: 
 http://gis.19327.n5.nabble.com/OSM-legal-talk-The-Copyright-of-Split-Ways-tp5438685p5441546.html
 Sent from the Legal Talk mailing list archive at Nabble.com.

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

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

Re: [OSM-legal-talk] ODbL implementation plan - extra phase proposal

[LM_1]

Since I am mentioned in the first post, I should probably react too:
It was not a deeply thought through proposal, just a general idea. And
I still believe a good one.
I can imagine that changing the API itself is a lot of work. Much
worse, it serves as a public interface that unknown number of clients
might use. Still I would not rule that out. Who knows when the next
licence change comes (maybe in favour of compatibility with other
licence) or some other event when substantial portion of data becomes
problematic (eg. because some older import is found licence
incompatible).

That said there are other ways to ensure the goal of this suggestion -
seamless transition rather than deletions and angry/leaving
contributors.

One that comes to my mind and does not require any drastic changes
would utilise filtering feature of JOSM (and required Potlatch to
implement equivalent). Every night/week (depending on how demanding
task it would be) each incompatible object would be tagged
odbl=incompatible (server side). Editors would then make these objects
non-editable/less visible...

If API is not changed to serve the cleaned version of data, it would
be good to have at least some editor-side tool to revert selected
object to the clean state and then repair/edit it as it should be.

In my original suggestion I said that this period (remapping what has
to be deleted while still serving data under CC-BY-SA) should take a
year or two - as long as needed till all the field in
http://odbl.poole.ch/ show 99% or more. The time pressure is a false
one, there has not really been any argument why it is important to
change the licence fast.

Lukáš Matějka
(LM_1)

2012/1/28 Mike N nice...@att.net:
 On 1/28/2012 8:30 AM, Frederik Ramm wrote:


 There is nothing fundamentally wrong or impossible about that.

 But it does introduce more work for us (because we would have to
 implement a way for the API to reject changes to tainted objects).


  A notice could originate in the 2 most popular editors, and not require an
 API change.   The user would at least be aware of the problem before
 continuing the edit.


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

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

Re: [OSM-talk] Critical Mass for license change-over

[LM_1]

I would have higher standard for critical mass, definitely over 99 %.
There should be a prolonged (at least one year) period where it is
known what data can remain and what cannot to allow seamless switch.
Having two months to the planned switch and still not knowing the
exact algorithm to determine what stays seems just stupid.

Lukas (LM_1)

2012/1/27 Michael Collinson m...@ayeltd.biz:
 This is a report from the License Working Group and a request for feedback.
 If anyone can do translations or summaries for other language mailing lists,
 I would be very grateful.

 Our moderators have agreed that this is a general topic of concern to the
 whole OSM community. If you are a continuing mapper, please feel free to
 respond and give your opinion. Only strictly legal questions will be
 pointed at legal-talk list.

 As the license change process evolved, concern was expressed that an
 unacceptable amount of data might be lost from the current version of the
 OSM database and consensus was reached that phase 5 [1] - the actual license
 cut-over - should only happen when a critical mass was achieved.

 The question I ask you is, do you agree that we have reached critical mass?

 Here is our report.

 I and the License Working Group think we clearly have reached critical mass
 and that the situation will only improve over the next few weeks. An intense
 effort is being made to reach still undecided mappers. We have already asked
 your help in the UK, Philippines, Canada and USA. We will go global soon. A
 number of decliners have also kindly allowed us to continue using their
 contributions after making sure that their concerns were known. A few more
 may still do so. The OSM Foundation board has asked us to target April 1st
 for the change-over.

 First, the good numbers.

 Several hundred thousand mappers are now actively mapping under the new
 contributor terms. Only 420 older contributors have currently explicitly
 declined. At least 97.1% of nodes [2] and  96.6% of highways [2] in the
 current database were created by continuing mappers. However, some of those
 may have been edited later. From up-to-date figures, [3], it looks as though
 3.2M out of 120M ways are problematic in some way.  That is 2.68%. It is
 declining. So, if we can use just one figure, I suggest we could be at
 97.32% readiness ... feel free to challenge!

 But what about negative factors?

 - There are subjective criteria.  The removal of 100 hospital nodes may be
 far worse than than the removal of several million import points. ... Or the
 loss of a repeatable import may be bad because folks have editted over the
 top. It is difficult to judge whether this has a positive or negative bias
 overall.

 - There are regional and country [2, 4] variations. You might be in an area
 where there are bigger problems than than implied by the figures I have
 given you.  The easiest way to see this is with OSMI License View tool [5] .

 - We still have not been able to get responses from about 35,000 older
 contributors who have mapped at least one node. Sorry, this is an
 approximate figure at the moment. One impact of this is that there are a lot
 of folks who have mapped a small town, stopped mapping and have not
 responded.

 - On a national level, there are still specific issues we are working on in
 Poland and the Czech Republic.  In Australia, Montenegro, Kosovo, Albania,
 Macedonia and, on a regional basis, in Germany there large concentrations of
 data by folks who have specifically declined. In Liberia and Cyprus, there
 are key large contributors who have so far not responded. In Japan, there is
 also one very large contributor who has declined, but we understand this is
 a POI import that will be dropped.

 - http://odbl.de/ [4] gives a more pessimistic view than the numbers I have
 given you. This is probably due to bot edits and changes which are harmless,
 but should be taken into consideration.


 And, lastly, you can see what the new map will look like if we changed
 over today at http://cleanmap.poole.ch/.  This is running on a small
 machine, so please be patient and try again later if lot's of folks are
 hitting it.


 Mike
 License Working Group

 [1]
 http://wiki.openstreetmap.org/wiki/Open_Database_License/Implementation_Plan#PHASE_5_aka_Done_-_License_Cut-over_from_CC-BY-SA_to_ODbL_.28date_to_be_decided.2C_depends_on_the_technical_work.29

 [2] http://odbl.poole.ch/ (based on early December data)

 [3] http://tools.geofabrik.de/osmi/munin.html

 [4] http://odbl.de/

 [5] http://tools.geofabrik.de/osmi/?view=wtfe


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

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

Re: [Talk-cz] Brněnský architenktonický manuál

[LM_1]

Není to všude, ale přibývají. :)

2012/1/27 Petr Holub ho...@ics.muni.cz:
 mapuje architektonicky zajímavé stavby z období 1918-1945. Každá
 stavba má číselné označení C001-C..., často je nastříkané barvou na
 chodníku před budovou. Když okolo takového domu jdu tak ho v mapě

 FYI - v jednom z tech domu bydlim a na chodniku pred barakem nic
 nemame. Ale v te jejich prehledove mape je korektne zaznacen a ocislovan :).

 Petr


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

___
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

[LM_1]

Rád bych reagoval na příspěvek Martina Mareše, do vznikající hádky
bych se nerad vměšoval.
Do hloubky jsem se zabýval případem Welte v. D-Link, kde tři autoři na
Haralda Welte práva ke svým programům (msdos, msdosfs, initrd, mtd)
převedli, právě proto, aby mohl žalovat. U ostatních sporů
předpokládám podobný model (žalobu jen na jednotlivé moduly), i když
jsem je tak podrobně nestudoval.
rozsudek: http://www.jbb.de/urteil_lg_frankfurt_gpl.pdf

Práva lze samozřejmě vymáhat i pro porušení části celku, ale není to
tak účinné. Zrovna u OSM navíc je přispěvatelů řádově víc než u jádra
Linuxu.

Licence je forma kontraktu (licenční smlouva). To, že je často chápána
jako jednostranný akt na tom nic nemění.
V jurisdikcích kde nejsou práva k databázi ani copyright vynucovány
asi těžko nějaká smlouva něco změní, i když představitelné to je (stát
nechrání databáze, ale vynucuje smlouvy).

Doteď byla diskuze o potřebě změny (podle mě existuje) ale ne o jejím
konkrétním provedením (k němu mám výhrady). Naprosto souhlasím, že by
měla být delší doba, kdy nové příspěvky budu přijímány jen od
přispěvatelů s odsouhlasenými CT a zároveň by měla být poměrně dlouhá
doba (rok), kdy bude stanoven jasný mechanismus určení kompatibility
licence a bude možné problematické oblasti napravit (API bude posílat
jen kompatibilní prvky, editované objekty budou muset být celé
kompatibilní), aby v okamžiku zveřejnění mapy pod ODBL byla ztráta
minimální (nulová nebude).

@Petr Morávek: Důkazní břemeno v licenčních sporech je (Evropa,
Severní Amerika jinde si tvrdit netroufnu) na žalobci, ten musí
dokázat, že má práva k tomu co žaluje a že žalovaný je nerespektuje.
Ten se pak může bránit dokázáním, že má právní titul k užívání dat
(uzavřenou licenční smlouvu). Prohlášení, že to má od někoho jiného
bez dalšího důkazu by neuspělo

Lukáš Matějka (LM_1)



2012/1/27 Martin Mares m...@ucw.cz:
 Zdravím!

 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.

 Nikoliv.

 Pokud by nová data byla licencovaná duálně, bude verze pod CC stále použitelná
 a verze pod ODbL sice zpočátku nedokonalá, ale postupem času bude tu verzi pod
 CC dohánět, jak budou stará data přemapovávána.

 Naproti tomu pokud se rozhodnete data licencovaná pouze pod CC smazat,
 dostanete jen verzi pod ODbL, která bude nedokonalá. Možná tím lidi motivujete
 k tomu, aby o to rychleji dotčené části přemapovali, ale pravděpodobnější je,
 že je tím především naštvete.

                                Have a nice fortnight
 --
 Martin `MJ' Mares                          m...@ucw.cz   http://mj.ucw.cz/
 Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
 Never make any mistaeks.

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

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

[Talk-cz] [OSM-talk] Critical Mass for license change-over

[LM_1]

Na globální mailing list (t...@osm.org) přišla zpráva od licenční skupiny (LWG).
Můj osobní názor: Kritické množství by mělo být přes 99 %, měla by být
delší doba, kdy je znám způsob určení, která data budou zachována, ale
ostatní ještě nebudou odstraněna.
Lukáš (LM_1)

tady je shrnutí-

S postupem procesu změny licence bylo dosaženo shody, že (aby nedošlo
k ztrátě nepřiměřeného množství dat) fáze 5 (vlastní přepnutí licence)
by měla proběhnout až po dosažení kritického množství.
Otázka je, jestli si myslíte, že kritického množství bylo dosaženo?
Zpráva LWG:
LWG je přesvědčena, že kritického množství bylo dosaženo, stále
pokračuje snaha o kontaktování nerozhodnutých přispěvatelů, Několik
odmítajících laskavě dovolilo pokračování v užívání jejich příspěvků
po zajištění, že jejich obavy/problémy jsou známé. Výbor OSMF požádal
o směřování změny k 1. 4.
Dobrá čísla:
Pod novou licencí aktivně přispívá několik set tisíc uživatelů,
výslovně odmítlo 420.  97.1% of uzlů [2] a 96.6% of cest bylo
vytvořeno souhlasícími uživateli, některé mohly být později změněny.
Podle aktuálních čísel je 3,2 mil. cest z 120 mil. nějak
problematických - to je 2,68 %. = 97,32% připravenost. Nebojte se
zpochybnit.

A co negativní faktory?
- subjektivní kritéria 100 nemocnic je významější než pár milionů
importovaných uzlů. Ztráta opakovatelného importu může být špatná
kvůli následným editacím.
- existují regionální [2,4] rozdíly, v některých oblastech je situace
horší než vyplývá z uvedených čísel. Použijete OSMI License View tool
[5].
-stále je asi 35000 starších přispěvatelů, kteří neodpověděli. Je mezi
nimi mnoho lidí, kteří zmapovali menší město, přestali a neodpovídají
- na národní úrovni se řeší specifické problémy v České republice a
Polsku. V některých zemích (viz originál) jsou problémy regionální, v
Německu je hodně od uživatelů, kteří vysloveně odmítli. V Libérii a na
Kypru jsou významní přispěvatelé, kteří neodpověděli. V Japonsku je
jeden významný přispěvatel, který odmítl, ale jedná se import POI.
- http://odbl.de/ [4] ukazuje pesimističtější obraz, pravděpodobně
kvůli boty, které jsou neškodné

Konečně nová je na http://cleanmap.poole.ch Běží na nějaké plečce,
takže mějte pochopení pro pomalost a zkuste to za chvíli znovu
Mike

Následuje původní zpráva

This is a report from the License Working Group and a request for
feedback. If anyone can do translations or summaries for other
language mailing lists, I would be very grateful.

Our moderators have agreed that this is a general topic of concern to
the whole OSM community. If you are a continuing mapper, please feel
free to respond and give your opinion. Only strictly legal questions
will be pointed at legal-talk list.

As the license change process evolved, concern was expressed that an
unacceptable amount of data might be lost from the current version of
the OSM database and consensus was reached that phase 5 [1] - the
actual license cut-over - should only happen when a critical mass
was achieved.

The question I ask you is, do you agree that we have reached critical mass?

Here is our report.

I and the License Working Group think we clearly have reached critical
mass and that the situation will only improve over the next few weeks.
An intense effort is being made to reach still undecided mappers. We
have already asked your help in the UK, Philippines, Canada and USA.
We will go global soon. A number of decliners have also kindly allowed
us to continue using their contributions after making sure that their
concerns were known. A few more may still do so. The OSM Foundation
board has asked us to target April 1st for the change-over.

First, the good numbers.

Several hundred thousand mappers are now actively mapping under the
new contributor terms. Only 420 older contributors have currently
explicitly declined. At least 97.1% of nodes [2] and  96.6% of
highways [2] in the current database were created by continuing
mappers. However, some of those may have been edited later. From
up-to-date figures, [3], it looks as though 3.2M out of 120M ways are
problematic in some way.  That is 2.68%. It is declining. So, if we
can use just one figure, I suggest we could be at 97.32% readiness ...
feel free to challenge!

But what about negative factors?

- There are subjective criteria.  The removal of 100 hospital nodes
may be far worse than than the removal of several million import
points. ... Or the loss of a repeatable import may be bad because
folks have editted over the top. It is difficult to judge whether this
has a positive or negative bias overall.

- There are regional and country [2, 4] variations. You might be in an
area where there are bigger problems than than implied by the figures
I have given you.  The easiest way to see this is with OSMI License
View tool [5] .

- We still have not been able to get responses from about 35,000 older
contributors who have mapped at least one

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

[LM_1]

Problém ve vysvětlování je asi v tom, že se dějí dvě věci současně:

1) přijetí Contributer's terms (podmínky užívání): V těch se v zásadě
říká, že dávám OSMF právo užívat data a licencovat je pod nějakou
svobodnou licencí (a možnost tuto licenci měnit na základě většinového
hlasování komunity) a potvrzuji, že k tomu mám příslušná práva.
Tato změna je potřebná proto, aby se odstranila právní nejistota a strnulost.
Hlavní rozdíl je v tom, že určitá práva dostává výlučně OSMF a ta
potom dává licenci k dalšímu užití dat.
Doteď každý jednotlivě dával na svoje příspěvky licenci obecnou -
uživatel mapy tak vstupoval do smluvního vztahu s tisíci přispěvateli,
z nichž každý mu dal licenci na kousek.
Teď vstupuje uživatel mapy do smluvního vztahu pouze s OSMF od které
dostává licenci, a OSMF s každým přispěvatelem od, kterých má povolení
takovou licenci udělit.

Bohužel tato užitečná změna je i důvodem, proč se musí vyžadovat
explicitní souhlas každého jednotlivého přispěvatele.

2) Změna licence z CC-BY-SA na ODBL. Tato změna by mohla (podle mě
měla) proběhnout nezávisle na změně první (až po ní) - formou
většinového hlasování. Důvodem změny je to, že se vztahuje na autorská
díla, jimiž drtivá většina příspěvků v OSM není (berou se tak spíš z
opatrnosti). Proto se přechází na databázovou licenci, které více
odpovídá povaze dat v OSM.

Lukáš (LM_1)

2012/1/26 Martin Mares m...@ucw.cz:
 Dobré odpoledne,

 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.

 po pravdě řečeno, i kdybychom o žádná data nepřišli, je změna licence
 naprosto pochybný krok, protože přidělal mnoha lidem mnoho práce
 a užitek změny licence pro komunitu OSM je zdá se veškerý žádný.

 Kdyby lidi místo změn licence radši vyrazili do terénu mapovat...

 --
 Martin `MJ' Mares                          m...@ucw.cz   http://mj.ucw.cz/
 Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
 This is an object-oriented system. If we change anything, the users object.

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

___
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

[LM_1]

Tak já se do toho vložím ještě jednou:
Celkem důkladným právním testem v Německu prošla GNU GPL (Haralde
Welte se soudil, viz http://gpl-violations.org/). A celkem jednoznačně
uspěl se všemi nároky (= typ veřejně nabízených licencí je platný a
vynutitelný). To platí (typově) o CC i ODBL.

To, jestli licence něco chrání nebo nechrání je bezpředmětná debata
(bohužel rozšířená), protože licence v zásadě nic nechrání (rozšířený
omyl tvrdí opak).
Ochrana se zlepšuje v tom, že zatímco teď by musel v případě porušení
žalovat (=jet k soudu v místě žalovaného, platit soudní výlohy,
minimálně dát někomu plnou moc) každý jednotlivý přispěvatel za každou
jednotlivou cestičku - dokázat, že k ní má autorská práva, že byla
porušena a že tím vznikla škoda.
Příspěvky každého uživatele by se řídily jiným právem, právo kterým by
se řídily by záviselo na kolizních normách práva země žalovaného,
obvykle by to bylo právo země (domicilu) přispěvatele. Teoretický
soudní spor by tak měl 1+ účastníků na straně žalující (zasedání
na sportovním stadionu?), a každý z nich by podle procesních
ustanovení země žalovaného dokazoval, že podle práva jeho země
žalovaný porušil jeho autorská práva. Pokud by nějaký soudce rozhodl
dřív než by spáchal sebevraždu tak by takový sport jistě byl vděčným
tématem mnoha generací právníků.
Nově by toto měla obstarávat OSMF - jedno rozhodné právo (Velké
Británie), jeden silný žalobce.

Data před (zne)užitím chrání zákon. Stejně vlastnictví chrání před
krádeží tak autorská díla chrání před určitými způsoby/druhy užití
(copyright) a podobně pro databáze.
Pokud zákon databázi nechrání, je licence k ničemu.*

Licence (k databázi i k autorskému dílu) může povolit za určitých
podmínek, které by bez licence nebyly možné. Dobrá licence tedy
povoluje právě tolik, kolik chce držitel práv povolit a má takové
podmínky, jaké požaduje. Obecně by každá ze stran měla maximálně
přesně vědět, na čem je.

Licence (nezaměňovat s CT) se mění právě proto, aby bylo jasné (pro
přispěvatele, OSMF, uživatele dat) co smí, co nesmí a za jakých
podmínek a protože obsahuje deklaraci, že přispěvatel neporušuje svými
příspěvky ničí práva.

Řešeným problémem je (obecně) právní jistota, konkrétně možnost
uživatelů s vysokou pravděpodobností určit, jestli je pro ně OSM
použitelná.

Speciálně pro jzvc: data se odstraňují primárně kvůli zavádění CT. Je
to proto, aby byla jednotně licencovatelná od OSMF uživateli a mohla
být brána jako jednotná databáze. Návrhy, ať si uživatelé filtrují
data sami nedává smysl, Taková data nelze dál upravovat - už teď je
problém co s objekty, které upravovalo více lidí, čím dřív se to
oddělí tím líp.

Ještě jednou srovnání s domem: Začnete s pár kamarády stavět dřevěnou
boudu, nic neřešíte. Zjistíte, že místo boudy vám na pozemku (serveru)
vyrostlo obří nákupní centrum. Začnete se zabývat, komu patří a kdo ho
může používat. Zjistíte, že každému patří co přispěl (tady cihla, tam
prkno) a v zásadě není jasné co všechno se tam smí a co ne (CC). Proto
vznikne snaha aby celé centrum patřilo jedné entitě (OSMF) a pomocníci
by mohli většinově rozhodovat o využití (CT), zároveň s tím vznikly
nové podmínky použití (ODBL). Některým se tato změna nelíbí (děkujeme,
odneste si, co jste přispěli, na shledanou) a snahu o odstranění svých
příspěvků chápou jako ničení společného díla. OSMF je v
nezáviděníhodné situaci, kdy je správcem obřího nákupního centra, ale
nemůže s ním celkem nic dělat.


Závěrem: současný stav je dlouhodobě neudržitelný. Raději budu
přispívat do databáze s jasným právním režimem, bez rizika, že moje
editace budou záviset na množství lidí, které neznám.
Lukáš

PS
*Lze si představit inominátní smlouvu typu: kliknutím na tento jediný
odkaz vedoucí ke stažení dat souhlasím s následujícími podmínkami
(uzavření smlouvy), ale to problém s relicencováním neřeší.

Dne 26. ledna 2012 22:22 jzvc j...@tpfree.net napsal(a):
 Dne 26.1.2012 20:39, Petr Morávek [Xificurk] napsal(a):

 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

[Talk-cz] Brněnský architenktonický manuál

[LM_1]

Pro přispěvatele z Brna a okolí:
Nedávno vznikl Brněnský architektonický manuál (bam.brno.cz), který
mapuje architektonicky zajímavé stavby z období 1918-1945. Každá
stavba má číselné označení C001-C..., často je nastříkané barvou na
chodníku před budovou. Když okolo takového domu jdu tak ho v mapě
označím jako ref:bam.brno.cz=C123, případně doplním rok stavby a
architekta a název. Jestli někoho napadlo něco podobného, bylo by
vhodné, aby se čísla budov uchovávala konzistentně.
Lukáš (LM_1)

___
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

[LM_1]

Je to nesmysl, tyto copyleftové licence celkem přesně vystihují rčení:
Co peklo schvátí, to už nenavrátí. Kdo by mi nevěřil tak viz
http://www.creativecommons.cz/zakladni-informace-o-cc/typy-cc-licenci/
úplně dole.
Lukáš (LM_1)

2012/1/26 Martin Mares m...@ucw.cz:
 Zdravím!

 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.

 Kde to v našem AZ je napsáno?

                                Have a nice fortnight
 --
 Martin `MJ' Mares                          m...@ucw.cz   http://mj.ucw.cz/
 Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
 One single semicolon. A perfect drop of perliness. The rest is padding. -- 
 S. Manandhar

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

___
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

[LM_1]

Jestli mě paměť neklame tak Harald Welte měl plné moci k zastupování
od ostatních autorů, (jinak by neměl moc šanci uspět). Navíc žalovali
použití konkrétních programů (a ty bývají v Linuxu malé a
jednoúčelové).
Jistě může každý autor žalovat sám za sebe a svou cestičku a kousek
lesa, ale nemůže žalovat porušení databáze jako celku.
ODBL je lepší v tom, že přesněji upravuje problémy okolo směšování
více databází a následných vykreslených map.
Znovu zopakuji, že připojení libovolné licence neochrání nic, licence
umožňuje použití ostatním. Žádná licence=žádné použití.
Chrání zákony a státní donucení.
Kocour je hezký pokus, ale těžko by uspěl. Závaznost elektronické
kontraktace je celkem široce přijímaná (v nejpřísnějších případech se
požaduje prokazatelné zobrazení podmínek). Navíc dovolávat se
neplatnosti právního dokumentu na základě něhož něco používám je
trochu mimo, ale překvapivě to zkoušeli i právníci Haralda Welte ve
sporu proti D-Link.

Lukáš Matějka (LM_1)

 Třeba právě ten, že CC nefunguje na díla tohoto typu :)
 Není mi úplně jasné, proč. Text CC-BY výslovně zmiňuje, že dílo může
 být i mapa nebo kompilace dat.
Je rozdíl mezi mapou a mapovými daty. Nefunguje je silné slovo, hodilo
by se spíš nevhodná.

2012/1/27 Martin Mares m...@ucw.cz:
 Zdravím!

 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.

 No právě, že nikdo neukázal, že by poskytovala ochranu lepší,
 což činí námitku, že změna licence je zbytečná, oprávněnou.

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

 Není mi úplně jasné, proč. Text CC-BY výslovně zmiňuje, že dílo může
 být i mapa nebo kompilace dat.

                                Have a nice fortnight
 --
 Martin `MJ' Mares                          m...@ucw.cz   http://mj.ucw.cz/
 Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
 Next lecture on time travel will be held on previous Monday.

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

Re: [OSM-talk] How I got here - was Geocaching.com moved to OSM (partly)

[LM_1]

There are much less stable things than graves and tombstones being
mapped. That is not really a problem.
The graves are there (unlike some historical feature), easily visible,
fairly stable. I do not see any reason why they should not be mapped
in OSM database.
They are not likely going to be rendered by any big renderer, but that
does not really matter if someone wants to map them...
Lukas (LM_1)

2012/1/19 Martin Koppenhoefer dieterdre...@gmail.com:
 2012/1/19 Nick Hocking nick.hock...@gmail.com:
 mick Wrote

 I was pointed here by someone on the Devon list at the rootsweb genealogy 


 Hi mick

 When I map a country town I am always on the lookout for any cemetery.
 I find some very obscure ones and always put them on the map.

 What are your feelings about putting individual gravestone info into
 OSM such as the persons name and maybe date and grave location
 (row, number ???).  It would be good for searching and to get the
 same sat nav, that got you to the cemetry, to walk you to the grave
 itself.

 Does this data belong in OSM or should it be a seperate layer
 looked after by Genealogists somewhere else.


 There is some similar data of this kind already in OSM:

 - in 2008 some mappers in Berlin started mapping the graves of famous
 people: http://wiki.openstreetmap.org/wiki/Berlin/OSM_meets_Six_Feet_Under
 (in German)
 - there are some tags (e.g. tomb=war_grave) to map specific types of graves

 but as far as I know there is not yet anybody mapping ordinary
 graves (i.e. of people that are neither famous nor did they die in an
 extraordinary way). One problem I'd see around here is that this kind
 of data is not very stable (usually the dead remain only for 20 years
 in their graves, not for eternity, but this depends on the religion
 and local culture).

 Keeping this data in a separate layer is suboptimal: e.g. you will
 have tombs in OSM and the graves in them in another layer, now if
 someone moves the tombs (to improve the position) they would move the
 dead out of their tombs. Very bad for your karma...

 cheers,
 Martin

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

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

Re: [OSM-legal-talk] Implementing the licence change

[LM_1]

Knowing it does not really start the discussion: I totally agree.
Lukas (LM_1)

2012/1/18 ant antof...@gmail.com:
 First of all I must say that I highly respect the work of everyone who has
 been actively involved in the licence change, including the LWG members, the
 writers of licence change inspection programs and everyone involved in
 discussions.

 I have been watching the process for more than two years and have ever since
 been a supporter of the change.

 However, especially since the switchover date has been announced and the
 phase of remapping has started, I have become more and more skeptical about
 the way things are going on. I want to discuss a couple of concerns I have.

 1. The black box

 As far as I can see the details of the implementation of the licence change,
 i.e. of what is actually going to happen on April 1st, are not known - or at
 least not revealed. Correct me if I am wrong.

 Particularly, the wiki page „What is clean?“[1], which has been said to be
 the binding document, is in its current state not sufficient to serve as a
 reference for any measures regarding the cleaning of data:
 * The considerations in the section „Edge cases“ are only a random selection
 of cases that have been discussed. Neither conditional stetements like „if
 it can be seen not to influence the current version“ nor questions like „Can
 you copyright the state of something not being there?“ (rhetorical?) are
 helpful. The list somewhat lacks a systematic approach.
 * The „deletion paradox“ is, as it has been pointed out on the discussion
 page, no paradox at all (rather it depends on the strategy of cleaning).
 * The section „What taints data?“ repeats the above-mentioned list, but is
 differently (better) structured and different in content. Statements in this
 list, however, contradict, or supersede, previous statements („A tag
 modified by a non-agreeing mapper is tainted“, whereas: correcting a tagging
 typo is not tainted). Furthermore the list contains instructions, which
 should not be the case in a mere specification of what is clean. The clause
 saying that intermediate versions should be created during remapping (a)
 does not belong here and (b) is questionable, as it is based on assumptions
 regarding the implementation of switchover, which has not yet been decided
 upon.
 * There should be rationales explaining for each statement why it is so and
 not different.

 Basically I think that this document needs a rewrite that shall contain
 unambiguous statements preceded by precise definitions. In order to get
 there, however, we must of course have a discussion.

 2. Getting clear about taintedness

 IANAL. But I like to approach problems in a systematical manner. For
 example, I recently asked myself the question, „What is a copyrightable
 object in OSM?“. I think this is a fundamental question to answer if you
 discuss licence topics.
 Is a node copyrightable?
 If yes, what's copyrightable about it?
 What's copyrightable about a way?
 Is the list of references to nodes copyrightable separately from the way's
 tags?
 Are references to nodes atomic? (I.e. Is a single reference copyrightable?
 Or is only the list as a whole?)
 Sorry for the rhetoric, but these questions do bother me. I believe they
 have to be answered prior to discussing which kinds of modifications to what
 object have what effect (- taintedness). And when that has been settled, we
 can talk about measures.

 All in all I think that the approach to the whole thing so far has been too
 pragmatic, just like identifying edge cases and modeling something around
 it. Of course, this might somehow work and the result might even be
 satisfying, but to me it doesn't seem appropriate in a legally significant
 matter like this.

 3. Remapping

 Considering that neither the definitions of what is clean and what is
 tainted nor the technical details of the implementation have yet been
 finalized, it seems unreasonable for me to remap. I don't want to discover
 later that I have done unnecessary work. Besides, current remapping practice
 is completely based on the available inspection tools that implement - more
 or less precisely - a taintedness policy that is still in draft status. For
 this reason I also refuse to use the odbl=clean tag.


 Now I could elaborate a lot more. But the purpose of my post actually is to
 start a discussion, and I am asking you. Me too wants the licence change to
 be a success. So let's go.

 Cheers
 ant

 [1] http://wiki.openstreetmap.org/wiki/Open_Data_License/What_is_clean%3F

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

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

Re: [Talk-cz] MTB mapa

[LM_1]

Celkem formaliovaný způsob hlasování je proposal na wiki s hlasováním.
Když budou vrstvy tak předpokládám, že půjdou snadno zapnout/vypnout a
nebude potřeba řešit překrývání - když budu chtít cyklotrasy, přidám
si vrstvu, když mtb:scale, přidám si tu...
Lukáš (LM_1)


Dne 16. ledna 2012 13:27 Petr Holub ho...@ics.muni.cz napsal(a):
 1)
 ja osobne mtb:scale tagy nedavam na highway=track s tracktype=grade1 ale i s
 tracktype=grade2.

 Na wiki o tracktype=grade2 pisou: Unpaved track; surface of gravel or 
 densely
 packed dirt/sand.

 Z popisu tagu na wiki mi prijde, ze kdyz je neco tracktype=grade2, tak je to
 urcite i mtb:scale=0. Za celou dobu co mapuju i mtb:scale, tak jsem nenarazil
 na vyjimku. Prijde mi tedy, ze highway=track  (tracktype=grade1 ||
 tracktype=grade2) implikuje mtb:scale=0.

 Na mtb:scale=0 by nemely byt volne kameny (kaminky), kdezto na grade2 uz IMHO
 byt mohou, kdyz je ze zajezdeneho sterku. Nicmene - na tomhle bychom se asi
 pomalu meli shodnout a vysledek nacpat do anglicke wiki
 http://wiki.openstreetmap.org/wiki/Mountainbike

 Mame nastroje, jak udelat nejake hlasovani (poll)? Protoze ja si zatim porad
 myslim, ze grade2 uz si to explicitni mtb:scale zaslouzi a chtelo by asi 
 udelat
 demokraticke hlasovani, podle nehoz se pak budeme vsichni konzistentne ridit.

 2)
 V mape kreslit ty fialove cary jen vedle cest (way), na kterych je nastaven 
 tag
 mtb:scale.

 Takhle to bylo puvodne - a zpetna vazba byla, ze to tak je sice dobre pro
 mappery (vidim, co bylo/nebylo explicitne oznacene), ale ne pro bezne 
 uzivatele,
 protoze tim vznika relativne nespojita sit cest se znacenou obtiznosti.
 A normalni uzivatel spis chce videt, kam vsude se dostane po cestach
 obtiznosti mtb:scale=0, kdyz jede na vylet na trekingovem kole.

 U tracktype=grade1 je to asi zbytecne, ta podle plne cary jde poznat
 snadno, co me trochu vadi kdyz je to tracktype=grade1, vedle toho mtb
 fialova a jeste k tomu je to znacena cyklotrasa, ty se totiz
 vykresluji na care a ne vedle ni, takze uz nejde poradne poznat o jaky
 tracktype vlastne jde

 To je dobra poznamka, chtelo by to vyosit. Akorat tam uz zacina byt
 problem s tim, ja by se to delalo, vzhledem k poctu veci, ktere vedle
 cest potrebujeme renderovat a podpore Mapniku pro jejich kresleni -
 zejmena pokud prejdeme na vrstvy (aby se nemusely renderovat ve vsech
 moznych kombinacich).

 Cetl jsem i nazory, ze by se mapa predelala do vrstev. Pro prohlizeni
 na PC by to bylo urcite lepsi, pro mobilni zarizeni ktere maji s
 vrstvama problem by se dala udelat vrstva kde by byly vsechny
 sloucene, ale to by zase hodne narostla kapacita dat a asi i doba
 renderu vsech vrstev. Nevim jestli uz padlo nejake rozhodnuti, cetl
 jsem jen nazory pro a proti.

 Do budoucna celkem urcite ano, ale musime rozmyslet, jak to delat, aby
 tam nevznikala potreba generovat vsechny kombinace toho, co muze
 byt zapnuto a pritom to jeste vypadalo slusne, vizte ten bod vyse
 (priklad: kdyby se cyklotrasy renderovaly vne turistickych tras, tak
 po vypnuti turistickych tras by ty cyklotrasy byly osklive odskocene;
 certik je v detailech...).

 Petr


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

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

Re: [Talk-cz] MTB mapa

[LM_1]

Dne 16. ledna 2012 13:56 Petr Holub ho...@ics.muni.cz napsal(a):
 Celkem formaliovaný způsob hlasování je proposal na wiki s hlasováním.

 Da se to pouzit ale i takhle k semantice kombinace tagu?
Nevidím důvod proč by nedalo.


 Když budou vrstvy tak předpokládám, že půjdou snadno zapnout/vypnout a
 nebude potřeba řešit překrývání - když budu chtít cyklotrasy, přidám
 si vrstvu, když mtb:scale, přidám si tu...

 No jo, ale kdyz si zapnes soucasne cyklotrasy a mtb:scale, tak se
 Ti treba ty znaceni preplacnou pres sebe a uvidis jen tu, ktera bude
 nahore. Pokud je budem davat vedle sebe, tak zalezi na kobinacich,
 ktere dovolime zapnout.

 Jedna moznost je - jednotlive vrstvy bez ohledu na kombinovani (tedy
 urcene k tomu, aby zapnuta byla nejvyse jedna) a pak jednu vrstvu,
 v niz bude vsechno. To nam zjednodusi problem z n^2-n na n+1. Ale
 je otazka, jestli s tim budou uzivatele spokojeni...

Mě osobně by to nevadilo, nacpat všechno do jednoho zobrazení není
vždy ideální, ale někomu by se to asi mohlo nelíbit. Další varianta je
informace o stezkách/povrchu udělat poloprůhledně a dávat normálně
přes sebe.
Renderovat všechny kombinace moc nedává smysl . stejně by musely být
tak aby se všechno vešlo a to by potom šlo rozdělit do vrstev. Třeba
čárkovanou čarou s čárkami jedné vrstvy v mezerách těch ostatních...

Lukáš (LM_1)


 Petr


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

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

Re: [OSM-legal-talk] Way with almost nothing left but created by decliner

[LM_1]

Even if one way has been spotted and remapped, there might be many
similar cases that were not spotted and could not be remapped. If
there is a row of new CT compatible nodes, anything between them
should be considered clean - there is no authorship of the creator of
the original way...
LM_1

2012/1/13 Simon Poole si...@poole.ch:


 Am 13.01.2012 23:42, schrieb Frederik Ramm:

 Hi,

   here's an interesting example from the German forum. A way that was
 created by a decliner but later edited by 10 others; of everything the
 decliner originally created, only the very first node remains, everything
 else has been lost in the editing process.

 OSMI duly paints this way in red - created by decliner, no chance of
 survival.

 Instead of starting yet another thread on the subject on the German forum,
 the OP could have naturally simply remapped the way, which would have
 assured it 100% chance of survival .


 Simon



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

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

Re: [Talk-cz] waterway=náhon?

[LM_1]

Taky mi připadá nesmysl, že se nevykresluje reálná šířka, ten
riverbank se hodí tak na průtoky městem/vesnicí, kde je koryto hodně
upravené. Ve volné přírodě by u většiny řek měla stačit zadaná šířka.
Už jsem i dával na ticket na trac
(http://trac.openstreetmap.org/ticket/3984), ale nevypadá to, že by se
v brzké době šířka vykreslovala...
Lukáš (LM_1)

2012/1/9 Karel Volný ka...@seznam.cz:
 Dne Ne 8. ledna 2012 12:35:30, LM_1 napsal(a):
 Velkou šířku náhonu bych jako problém neviděl, spíš malou šířku řeky.

 pravda, když si to nazoomuju a srovnám s měřítkem, tak mi vychází nějaké
 necelé 4 metry, to je u spousty náhonů celkem reálný, zatímco na řeky je to
 dost málo ... no vpodstatě to odpovídá tomu rozdílu mezi potokem a řekou, jak
 je definovanej, že stream to je dokud to jde přeskočit

 U těch řek se to řeší pomocí waterway=riverbank.

 já vím, ale trošku vopruz obtahovat desítky kilometrů řek jen protože Mapnik
 neumí aplikovat width na čáru, která vede přibližně středem mezi břehama ...

 to se hodí když je to někde nadržený a rozleje se to víc do šířky, a třeba do
 nepravidelnýho tvaru

 navíc je tu trošku problém s logikou v mapě - jedna a ta samá věc je zanesena
 dvěma různejma objektama, jednak tou čárou a jednak plochou ... a v aktuální
 verzi pravidel by riverbank ani neměl patřit do relace řeky (což mi přijde
 dost nelogický, IMHO by naopak ta relace měla zahrnovat vše, průběh řeky lze
 pak zjistit vybráním role main_stream)

 K.


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

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

Re: [Talk-cz] waterway=náhon?

[LM_1]

Změna náhonů na canal je určitě správná.
Velkou šířku náhonu bych jako problém neviděl, spíš malou šířku řeky.
U těch řek se to řeší pomocí waterway=riverbank.
 Zkus si podle cuzk:km nakreslit kousek břehů řeky nebo toho náhonu a
uvidíš jak vypadají šířky reálně. Samozřejmě používání width by tomu
hodně pomohlo (usnadnilo), ale nevypadá, že by to v brzké době chtěl
někdo dělat.
Lukáš (LM_1)

2012/1/8 Karel Volný ka...@seznam.cz:

 Zdar,

 tak jsem včera trošku zeditoval Oslavu, a při té příležitosti jsem akčně
 přepsal náhony z waterway=stream na waterway=canal, neboť

 waterway=stream
      A naturally-formed waterway that is too thin to be classed as a river.
 ...

 náhon určitě není naturally-formed

 waterway=canal
      An artificial open waterway used for transportation, waterpower, or
 irrigation.

 náhon je artificial a je used for waterpower

 A teď koukám, jak je to vyrenderovaný, a je to dost katastrofa, neboť náhony
 jsou stejně tlustý jak řeka samotná (a to jsem navíc neřešil horní tok, kde to
 ještě není river ale jen stream, to už by bylo úplně pěst na oko ...)

 Nějaké návrhy, co s tím?

 Já bych si ideálně představoval rozdělit canal do těch tří podtypů, jak je
 charakterizován, pokud možno v souladu se stávajícím - když kouknu na
 http://wiki.openstreetmap.org/wiki/Tag:waterway=canal
 tak je tam možnost boat=yes
 Takže bych přidal waterpower=yes a irrigation=yes a od toho bych odvozoval
 defaultní renderování - irrigation nejtenší, waterpower jako stream nebo o
 trochu širší, a boat o něco tenší než řeka (samozřejmě při použití v kombinaci
 by slabší byl přebit tlustším).

 Jenže to chce prohnat nějakým oficiálním procesem, a pak donutit renderery,
 aby na to braly ohled - a když se podívám, že mapnik stále kašle na width, což
 by problém řešilo aspoň tam, kde to někdo vyplnil (u těch náhonů mě to fakt
 nenapadlo řešit ...), tak mě jímá pesimismus :-(

 Přehlídnul jsem nějakou možnost, jak se s tím vypořádat, aniž by se kvůli
 vzhledu rozbil význam dat, tj. aniž by se ty náhony musely tagovat jako něco,
 co nejsou (ať už stream nebo ditch)?

 K.


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

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

Re: [Talk-cz] waterway=náhon?

[LM_1]

Ale i v té dávné době někde koryto té řeky bylo, to u náhonů a kanálů neplatí.

Dne 8. ledna 2012 14:03 hanoj eha...@gmail.com napsal(a):
 Pro me je canal neco jako umely plavebni kanal, rekneme Dunaj-Ryn.
 To uplatneni pro nahon je mozne, byt v mych ocich podruzne a
 zanedbatelne. Casto je to v praxi obtizne rozlisitelne i pri hluboke
 mistni znalosti (opravoval jsem ted asi 100 km ruznych vodnich toku).

 Naturally-formed je problemova definice, pokud jen tak z hlavy placnu
 tak Morava, Svratka, Svitava, Jevisovka maji nemalo regulovane koryto,
 casto uplne jinde nez naturally pred 150 lety.


 hanoj

 2012/1/8 Karel Volný ka...@seznam.cz:

 Zdar,

 tak jsem včera trošku zeditoval Oslavu, a při té příležitosti jsem akčně
 přepsal náhony z waterway=stream na waterway=canal, neboť

 waterway=stream
      A naturally-formed waterway that is too thin to be classed as a river.
 ...

 náhon určitě není naturally-formed

 waterway=canal
      An artificial open waterway used for transportation, waterpower, or
 irrigation.

 náhon je artificial a je used for waterpower

 A teď koukám, jak je to vyrenderovaný, a je to dost katastrofa, neboť náhony
 jsou stejně tlustý jak řeka samotná (a to jsem navíc neřešil horní tok, kde 
 to
 ještě není river ale jen stream, to už by bylo úplně pěst na oko ...)

 Nějaké návrhy, co s tím?

 Já bych si ideálně představoval rozdělit canal do těch tří podtypů, jak je
 charakterizován, pokud možno v souladu se stávajícím - když kouknu na
 http://wiki.openstreetmap.org/wiki/Tag:waterway=canal
 tak je tam možnost boat=yes
 Takže bych přidal waterpower=yes a irrigation=yes a od toho bych odvozoval
 defaultní renderování - irrigation nejtenší, waterpower jako stream nebo o
 trochu širší, a boat o něco tenší než řeka (samozřejmě při použití v 
 kombinaci
 by slabší byl přebit tlustším).

 Jenže to chce prohnat nějakým oficiálním procesem, a pak donutit renderery,
 aby na to braly ohled - a když se podívám, že mapnik stále kašle na width, 
 což
 by problém řešilo aspoň tam, kde to někdo vyplnil (u těch náhonů mě to fakt
 nenapadlo řešit ...), tak mě jímá pesimismus :-(

 Přehlídnul jsem nějakou možnost, jak se s tím vypořádat, aniž by se kvůli
 vzhledu rozbil význam dat, tj. aniž by se ty náhony musely tagovat jako něco,
 co nejsou (ať už stream nebo ditch)?

 K.


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

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

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

[OSM-talk] The aim of OpenStreetView

[LM_1]

Hi,
What is the aim of OpenStreetView - Is it a potential Google
StreetView counterpart intended for viewing by general public (And
therefore all photos must be nice, high technical quality, blue sky,
around noon) ORIs it a help tool for OSM mappers (and therefore it is
important what can be used as mapping support and the photos can be
less nice, bad weather, dark - as long as they are informative)?
Thanks for answers
Lukas (LM_1)

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

Re: [Talk-cz] UIR-ZSJ import - last call ;-)

[LM_1]

Pár připomínek mám, ale celkem drobnosti:
neighbourhood může být kdekoliv - i jako část obce (neformální)
locality nemůže být ZSJ, protože tam nikdo nesídlí
na wiki je rozpor v definici hamlet - 300 obyvatel/vlastní
cedule/100-200 na stránce place=hamlet

No a ještě otázečka: Jsou nějak řešeny duplicity? Aby to nedopadlo jak
dibavod, kdy půlka řek je dodnes dvakrát...

LM_1

Dne 5. ledna 2012 0:44 Petr Morávek [Xificurk] xific...@gmail.com napsal(a):
 Zapracoval jsem připomínky a sloučil původní návrh s návrhem hanoje.
 Stránku s popisem importu jsem přesunul na [1] a doplnil odkaz do
 WikiProject Czech Republic/freemap [2].

 Prosím tedy o poslední kolo připomínek...

 Pokud nebudou vážné námitky, rád bych začal s plošným importem datasetů
 OBCE a COBE. A taky na různých místech wiki upravil popisky pro tag place.

 Dobrou noc ;-)
 Petr Morávek aka Xificurk

 [1] http://wiki.openstreetmap.org/wiki/Users:Xificurk/Import_UIR-ZSJ
 [2] http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap

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


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

Re: [Talk-cz] MTB mapa

[LM_1]

 + mozna by nebylo od veci nekde nejak zobrazit, jak starej ten reneder je 
 (datum na dlazdici?) to by se urcite hodilo, vytvaret aktualni overlay 
 pouze se starim dlazdic, ktera by byla defaultne vypnuta. Urcite by se to 
 hodilo i v jinych mapach, ne jen MTB. Nekdo by mohl vytvorit jednoduchy 
 univerzalni skript, ktery by se o to staral a klidne ho budu pouzivat.
Nevím, jak často se zhruba obnovují, ale většinou se na to nebud dívat
individuálně. Takže
http://mtbmap.cz/mtbmap_tiles/15/17892/11210.png/status by mohlo
celkem stačit. (zjistím adresu obrázku jeho otevřením v novém panelu
nebo z vlastností a připojím za ní /status)

Lukáš (LM_1)
Dne 5. ledna 2012 19:05 Martin Tesar osm...@gmail.com napsal(a):
 Zdravim,

 mala pripominka, koukam ze na mape se renederuje napeti u rozvodu, bylo by
 asi lepsejsi ho tam davat v bezne pouzivanych jednotkach - tedy kV, ne ve V,
 zbytecne dlouhy cislo ...


 diky za tip, uz jsem to opravoval driv, ale mel jsem problemy s konverzi
 nekterych hodnot. Ted jsem to udelal jeste hloupeji a snad by to melo
 fungovat lip, pro kV i pripadne MV.


 + mozna by nebylo od veci nekde nejak zobrazit, jak starej ten reneder je
 (datum na dlazdici?)

 to by se urcite hodilo, vytvaret aktualni overlay pouze se starim dlazdic,
 ktera by byla defaultne vypnuta. Urcite by se to hodilo i v jinych mapach,
 ne jen MTB. Nekdo by mohl vytvorit jednoduchy univerzalni skript, ktery by
 se o to staral a klidne ho budu pouzivat.

 Martin




 Dne 23.11.2011 15:18, Martin Tesar napsal(a):

 Ahojte,


 po vypadku zpusobenem problemy s diskovym polem na serveru je MTB Mapa
 opet k dispozici na http://mtbmap.cz/

 Ve chvilce casu jsem zkusil vylepsit vykreslovani turistickych a MTB tras
 tak, aby byly offsetovane porad na stejnou stranu cesty a zbytecne
 nepreskakovaly kvuli orientaci useku cesty. Preskakujou ted pouze na
 krizovatkach s jinymi znacenymi trasami. Musel jsem od zakladu predelat
 nejake skripty, vcetne vyberu tras z databaze, proto prosim o letmou
 kontrolu, zda se v nove renderovane mape vyskytuji vsechny trasy, ktere uz
 jsou v OSM zmapovane.

 Navic mi to umoznilo znacit varovani, ze se vyrazne meni obtiznost tras,
 viz cervene vykricniky treba tady:
 http://mtbmap.cz/?zoom=15lat=49.3041lon=16.57221layers=FB00

 Zvetsil jsem zaber uzemi i na sirsi okoli CR, proto ted nebudou
 aktualizace dat probihat denne, ale mene casto, minimalne jednou za tyden.

 Kdybyste meli nejake dalsi napady co vylepsit, sem s nimi. Pro jistotu i
 takove, co jste mi psali treba uz v lete a zatim se neprojevily.

 Diky za kontrolu a napady,
 Martin


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



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



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


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

Re: [Talk-cz] tracer

[LM_1]

Mě v JOSM funguje ten vestavěný.

adresa dotazu:
wms:http://wms.cuzk.cz/wms.asp?service=WMSVERSION=1.1.1REQUEST=GetMapSRS={proj}LAYERS=parcelni_cisla_i,obrazy_parcel_i,RST_KMD_I,hranice_parcel_i,DEF_BUDOVY,RST_KN_I,dalsi_p_mapy_i,prehledka_kat_prac,prehledka_kat_uz,prehledka_kraju-linieFORMAT=image/pngtransparent=TRUEWIDTH={width}HEIGHT={height}BBOX={bbox}


2011/12/23 Petr Balíček pbali...@seznam.cz:
 Jako merkaartorista můžu poradit jenom tohle:

 http://wms.cuzk.cz/wms.asp?service=WMStransparent=TRUEVERSION=1.1.1SERVICE=WMSLAYERS=KN,RST_KN,RST_KMD,obrazy_parcel,hranice_parcelSRS=EPSG:4326STYLES=FORMAT=image/png

 Normálně mi to funguje.

  Původní zpráva 
 Od: Pavel Pilát pavel.pi...@gmail.com
 Předmět: Re: [Talk-cz] tracer
 Datum: 23.12.2011 22:12:41
 
 Když tak vidím, jak mluvíte o traceru: ten se používá v souvislosti s
 katastrální mapou. Hned jsem se lekl, že už to začalo chodit, tak jsem
 zkusil v JOSM 4667 jak built-in layer Czech CUZK:KM, tak  WMS
 adresy z
 http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap#WMS_.C4.8C.C3.9AZK_-_katastr.C3.A1ln.C3.AD_mapa
 , ale dostávám stále jen červené errory (jako už několik měsíců).

 Nebo existuje nějaký, před wiki skrytý, způsob, jak CUZK:KM v JOSM 
 provozovat?

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




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

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

[Talk-cz] WMS pro záplavová území

[LM_1]

Zdravím,
potřeboval bych zobrazit záplavová území (ne pro mapu, takže problém s
licencí není).
Našel jsem tuto stránku: http://heis.vuv.cz/data/webmap/isapi.dll ale
není tam způsobb, jak vytvořit wms dotaz - něco, co by se dalo použít
do JOSM a zobrazit.
JOSM není podmínkou, jakýkoliv způsob jak zobrazit zároveň záplavová
území a katastrální mapu by byl super...
Umíte někdo poradit?
LM_1

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

Re: [Talk-cz] WMS pro záplavová území

[LM_1]

Dík,
už jsem na to přišel, akorát jsem to už dlouho nedělal a nezmáčknul
jsem získání vrstev a proto to nefungovalo.
Potřeboval jsem zobrazit záplavové území Bobravy v Rosicích, ale na
těch mapách nic není, i když ho tam kraj vyhlásil v roce 2005...
LM

Dne 17. prosince 2011 16:26 hanoj eha...@gmail.com napsal(a):
 vrstvy:
 http://heis.vuv.cz/data/webmap/isapi.dll?service=WMSrequest=GetCapabilities

 firefox:
 http://heis.vuv.cz/data/webmap/isapi.dll?SERVICE=WMSVERSION=1.1.1REQUEST=GetMapSRS=EPSG:4326LAYERS=wms_q100STYLES=FORMAT=image/pngBBOX=16.,49.5000,16.0061,49.5040WIDTH=300HEIGHT=300

 josm:
 http://heis.vuv.cz/data/webmap/isapi.dll?SERVICE=WMSVERSION=1.1.1REQUEST=GetMapSRS=EPSG:4326LAYERS=wms_q100STYLES=FORMAT=image/png;

 ha
 hanoj

 Dne 17. prosince 2011 15:51 LM_1 flukas.robot+...@gmail.com napsal(a):
 Zdravím,
 potřeboval bych zobrazit záplavová území (ne pro mapu, takže problém s
 licencí není).
 Našel jsem tuto stránku: http://heis.vuv.cz/data/webmap/isapi.dll ale
 není tam způsobb, jak vytvořit wms dotaz - něco, co by se dalo použít
 do JOSM a zobrazit.
 JOSM není podmínkou, jakýkoliv způsob jak zobrazit zároveň záplavová
 území a katastrální mapu by byl super...
 Umíte někdo poradit?
 LM_1

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

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