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

2012-02-15 Tema obsahu 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: [Talk-cz] Import chráněných území z EEA

2012-02-15 Tema obsahu jzvc
Dne 15.2.2012 23:52, LM_1 napsal(a):
> 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)
Problem je prave trebas to, pokud ty hranice nekdo bude casem chtit
automaticky ze zdroje aktualizovat = v pripade pouziti silnice, potoka
... nerealne. Navic, to tak nelze ani importovat, musel bys to nasledne
komplet rucne predelat, coz anuluje smysl importu. 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.

>
>
> 2012/2/15 jzvc :
>> 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


___
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

2012-02-15 Tema obsahu 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 :
> 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

2012-02-15 Tema obsahu jzvc
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


Re: [Talk-cz] Import Estudanky

2012-02-15 Tema obsahu jzvc
Dne 14.2.2012 13:46, Karel Volný napsal(a):
> zdar,
>
> tak já nevím, asi jsem vážně natvrdlej, nicméně pořád mi unikaj ty rozdíly, 
> proč by jednou mělo platit něco, a podruhý v obdobným případě něco jinýho
>
> no flame, mohl by se ještě někdo prosím pokusit o vysvětlení?

Protoze definice, viz zakon. Autorske dilo musi jevit znaky tvurci
cinnosti (coz nekteri nechapou, trebas na lupe jeji sefredaktor Zandl),
tudiz ne vsechno co kdo vyrobi je autorskym dilem chranenym zakonem.
Obkreslovani neni tvurci cinnost.
U nas jsou chraneny (extra) databaze, a tu definici databaze, kterou lze
chranit sem +- popsal nize.

>
> Dne Po 13. února 2012 21:18:56, jzvc napsal(a):
>> Panove, dovolim si (laicky informovanou) reakci na vasi plodnou debatu.
>>
>> Ani obkresleni z orthofoto/katastru/... ani GPS souradnice ... samo
>> osobe neni dilo databazove, natoz autorske(zjednodusene), tudiz neni
>> nijak chraneno. Nejde totiz o tzv "tvurci" cinnost ale pouze o
>> mechanickou praci(v principu to muze delat masina a taky to casto dela).
>>
>> Databaze jako takova muze (ale nemusi) byt chranena v pripade, ze
>> obsahuje !unikatni! soubor dat, pripadne jejich vazby (cojavim nekdo
>> prijde na to, ze vic lesu = bohatsi obyvatelstvo a udela databazi na to
>> tema ...). Nelze rozhodne chranit databazi obecne znamych/dostupnych
>> informaci.
>> Takze (jestli sem vyrozumel spravne) pokud import studanek nevadi
>> provozovateli one databaze (= potencialni soubor dat), tak jednotlivych
>> vkladatelu se rozhodne ptat netreba (neb nejde ani u tvurci autorske
>> dilo, ani o databazi).
> - pokud by mělo tohle platit, tak nechápu
>
> a) co poskytuje ochranu OSM, proč řešíme nějaké licence a práva přispěvatelů
>
> b) co poskytuje ochranu ostatním dílům, proč nemůžeme do OSM obkreslovat z 
> čeho nás napadne, nýbrž jen z vybraných zdrojů
>
> anebo jsem právě spadl z Marsu, a předpoklady pro a) ani b) neplatí, 
> obkreslovat můžem, a OSM chráněná není? - pak ale například k čemu se na 
> stránce http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap 
> nějaké licence vůbec řeší?
>
> ad a) - co z přidávání dat do OSM dělá onu "tvůrčí činnost" a nikoli 
> "mechanickou práci, kterou v principu může dělat mašina, a také to často 
> dělá" 
> (ostatně i v OSM spoustu práce udělali skripty a roboti)?
>
> ad b) - informace, že například někde vede cesta, stojí dům, teče potok ... 
> jsou obecně známé/dostupné, a pokud platí, že "nelze rozhodně chránit 
> databázi 
> obecně známých/dostupných informací", proč si je tedy nemohu do OSM vzít 
> odkud 
> se mi zlíbí, resp. naopak, na co se lidi obtěžovali s kontaktováním různých 
> poskytovatelů těchto dat s žádostí o svolení, proč se tu neustále něco 
> takového řeší?
>
> 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

2012-02-15 Tema obsahu Lukas Kabrt
> 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.

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

___
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

2012-02-15 Tema obsahu Petr Morávek [Xificurk]
Jan Kučera wrote:
> CHKO jsou již hotové.

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


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

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

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

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

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

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

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

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

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

Zdraví,
Petr Morávek aka Xificurk

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

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


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

2012-02-15 Tema obsahu Jan Kučera
Zdravím,

chystám se k plošnému importu chráněných území z EEA - tedy NPR, NPP
atd. CHKO jsou již hotové. Dataset pro celou Evropu je dostupný zde:

http://www.eea.europa.eu/data-and-maps/data/nationally-designated-areas-national-cdda-5
jedná se o soubor CDDA_v9_polygons.zip

Jedná se o shapefile, který má hezká metadata. Předpokládám, že máme u
nás pouze minimum těchto území zpamovaných a duplicity budou tedy
spíše vyjímkou a bude možné je časem pořešit.

Snad nikdo nepředloží výrazně závažný důvod bránící importu.

Zdravím,
Kozuch

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


Re: [Talk-cz] MTB mapa

2012-02-15 Tema obsahu Martin Tesar
Ahojte,

2012/2/15 Petr Balíček 

> Jestli to dobře chápu, jedna vrstva teď obsahuje jenom ty mtb:scale, který
> sou tagovaný a druhá i všechny implicitní. To považuju za krok správným
> směrem.


Ne, jedna zatim zustala jak byla, tj. tagovane mtb:scale + grade1 co
navazuje (vim, mel bych pridat i grade2) a druha mtb:scale + vsechny grade1
a grade2. Ta druha uz je ted uz i na mtbmap.cz jako dalsi zakladni vrstva.


> Za sebe bych ještě poprosil o čistě fyzickou vrstvu - bez mtb, cyklotras a
> turistických značení, protože v hustě zmapovaných oblastech (např. okolí
> Brna) už se pro mě mapa stává nepřehlednou.
>

Ok, muzeme ji vytvorit. Mela by byt i bez dalsich tematickych prvku nebo
jen bez zminenych linii? Napr. POI?

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


Re: [Talk-cz] MTB mapa

2012-02-15 Tema obsahu Petr Balíček
Jestli to dobře chápu, jedna vrstva teď obsahuje jenom ty mtb:scale, který sou 
tagovaný a druhá i všechny implicitní. To považuju za krok správným směrem. Za 
sebe bych ještě poprosil o čistě fyzickou vrstvu - bez mtb, cyklotras a 
turistických značení, protože v hustě zmapovaných oblastech (např. okolí Brna) 
už se pro mě mapa stává nepřehlednou.

PB

>  Původní zpráva 
> Od: Petr Holub 
> Předmět: Re: [Talk-cz] MTB mapa
> Datum: 12.2.2012 14:45:41
> 
> > Ale problem je v tom, ze se tak nevykresluji vsechny cesty grade1 v te
> > zmapovane oblasti. Nastava tak situace, ze dve na sebe navazujici grade1/2
> > cesty stejne kvality (v realu i v OSM databazi) se v mape zobrazi jinak.
> Jedna
> > je s fialovou carou a druha je bez ni. Kdyz se na takovou mapu podiva 
> > clovek,
> > ktery necte tenhle mailing list, tak myslim celkem prirozene ocekava, ze se
> ty
> > cesty budou nejak lisit (obtiznosti, vhodnosti pro MTB, ...). Ale oni se
> > nelisi!
> > 
> > Taky to dost divne vypada v pripade, ze je nekde mtb:scale otagovana jedna
> > osamocena cesta (treba nejaka zkratka po grade5). Pak se jako mtb:scale=0
> > vykresli i okolni cest, ktere ale treba nevedou odnikud nikam.
> 
> Martin zkusil vyrenderovat implicitni znaceni mtb:scale=0 na grade1/grade2,
> vysledek v zoomech 9 a 11 je tady:
> http://mtbmap.cz/img/grade12zoom9.png
> http://mtbmap.cz/img/grade12zoom11.png
> 
> Co vy na to?
> 
> 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