Re: [Talk-cz] Dotaz na zrušeni changesetu

2013-04-05 Tema obsahu Martin Kokeš
Plugin Reverter nepomáhá?
http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Reverter

MK
  _  

From: Zdeněk Pražák [mailto:zpra...@seznam.cz]
To: talk-cz@openstreetmap.org
Sent: Fri, 05 Apr 2013 18:48:57 +0200
Subject: [Talk-cz] Dotaz na zrušeni changesetu

Dnes jsem doplňoval turistické značky v okolí Kutné hory a omylem jsem v 
changesetu 15622280 smazal červenou značku.
Chtěl jsem se zeptat jak mohu tento changeset zrušit a vrátit se k původnímu 
stavu

Pražák
=  ___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz


Re: [Talk-cz] Data RUIAN - uliční čáry

2013-02-18 Tema obsahu Martin Kokeš
Možná to bude mírnou změnou formátu od 1.1.?, Viz.:


http://www.cuzk.cz/GenerujSoubor.ashx?NAZEV=10-NOVINKY_VFR_RUIAN_1_1

MK
  _  

From: Miroslav Šulc [mailto:fordf...@fordfrog.com]
To: OpenStreetMap Czech Republic [mailto:talk-cz@openstreetmap.org]
Sent: Mon, 18 Feb 2013 09:06:02 +0100
Subject: Re: [Talk-cz] Data RUIAN - uliční čáry

na http://maps.fordfrog.com mám naimportovaná denní 
data až do  17.2.2013, ale na mapě stále vidím jen fragmenty ulic. neměl 
jsem  zatím čas hledat, kde je problém, jestli v xml nebo v importu nebo v  
renderování.
  
  ff
  
  
Dne 7.2.2013 12:34, JV napsal(a):
Zdravím všechny,
v aktuálním stavovém exportu dat RUIAN (k 31.1.2013) by již měly
být opraveny uliční čáry - tedy už tam lezou kompletní.

J. Veselý




___  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] Průjezdy a další dotazy

2013-01-10 Tema obsahu Martin Kokeš
Kabátici zrovna najdeš mezi trigonometrickými body 
http://bodovapole.cuzk.cz/_mapTop.aspx, stačí je z S-JTSK transformovat na 
souřadnice WGS84 pomocí cs2cs.

Návod zde:
http://grass.fsv.cvut.cz/gwiki/S-JTSK-Grid

GDAL pro Windows zde:
http://vbkto.dyndns.org/sdk/Download.aspx?file=release-1600-gdal-1-9-2-mapserver-6-2-0\gdal-19-1600-core.msi
http://vbkto.dyndns.org/sdk/Download.aspx?file=release-1600-x64-gdal-1-9-2-mapserver-6-2-0\gdal-19-1600-x64-core.msi

MK

- Original Message -
From: Marián Kyral
[mailto:mky...@email.cz]
To: OpenStreetMap Czech Republic
[mailto:talk-cz@openstreetmap.org]
Sent: Thu, 10 Jan 2013 09:23:07
+0100
Subject: Re: [Talk-cz] Průjezdy a další dotazy


 

-- Původní zpráva --
Od: hanoj
 eha...@gmail.com
Datum: 10. 1. 2013
Předmět: Re: [Talk-cz] Průjezdy a
 další dotazy

 Jo. V tom mám trochu zmatek. Nevím, kam přesně to
 patří. Do addr tedy ne.
 Takže buď budova, nebo areál. BTW, buď jsem
 slepý, nebo tam ta oprava není
 ;-)
*** asi jsem to neodeslal, uz je to
 OK.
*** bud node POI, budova nebo areal, podle typu objektu nebo zastavby
a
 charakteru mista. Tag pekarstvi v dome bude na node POI, tag uradu
bude asi
 na building, a na skolu/skolku se hodi na areal. Ale nikdy do
addr.

OK,
 díky




 Tak jsem ta parkoviště projel a opravil. Už by to mělo být
 lepší.
*** supr

PS: Frydlanstka x Bezrucova neni mini
 roundabout




No to už tam bylo. Sice se mi to nezdálo, ale zatím jsem
 to tak nechal. 
Mrknu na to. Problém je v tom, že tam je podobných chyb
 více a hodně toho 
chybí a nevím, kam dříve. Navíc jsem zjistil, že
 má rodná vesnice 
(Chlebovice) je jen název a čísla domů.
 Katastrální mapa je tam úplně 
prázdná. Takže momentálně chci
 dodělat sídliště, pak se vrhnu na Chlebovice 
a pak budu pokračovat s
 úpravami FM a okolí. Snad mi elán vydrží.




Ještě bych měl
 dotaz:

Nad Chlebovicemi je vrchol Kabátice. Z Wiki a jiných zdrojů
 dokáži zjistit 
nadmořskou výšku, ale se souřadnicemi to je horší.
 Nevede tam turistická 
značka, je to v lese, takže i kdybych ten vrchol
 fyzicky našel (což nebude 
jen tak), tak přesnost GPS bude špatná. Je
 nějaká možnost, jak zjistit 
přesnější souřadnice? Je mi jasné, že
 kdyby to bylo někde veřejně dostupné, 
tak by se to už dávno
 naimportovalo.





Marián


 


hanoj

___
Talk-cz
 mailing
 list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
(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] Průjezdy a další dotazy

2013-01-10 Tema obsahu Martin Kokeš
Ten GDAL pro Windows nějak nefunguje, asi je Maďar offline, tak alternativa:
http://fwtools.maptools.org/

MK

- Original Message -
From: Marián Kyral
[mailto:mky...@email.cz]
To: OpenStreetMap Czech Republic
[mailto:talk-cz@openstreetmap.org]
Sent: Thu, 10 Jan 2013 09:23:07
+0100
Subject: Re: [Talk-cz] Průjezdy a další dotazy


 

-- Původní zpráva --
Od: hanoj
 eha...@gmail.com
Datum: 10. 1. 2013
Předmět: Re: [Talk-cz] Průjezdy a
 další dotazy

 Jo. V tom mám trochu zmatek. Nevím, kam přesně to
 patří. Do addr tedy ne.
 Takže buď budova, nebo areál. BTW, buď jsem
 slepý, nebo tam ta oprava není
 ;-)
*** asi jsem to neodeslal, uz je to
 OK.
*** bud node POI, budova nebo areal, podle typu objektu nebo zastavby
a
 charakteru mista. Tag pekarstvi v dome bude na node POI, tag uradu
bude asi
 na building, a na skolu/skolku se hodi na areal. Ale nikdy do
addr.

OK,
 díky




 Tak jsem ta parkoviště projel a opravil. Už by to mělo být
 lepší.
*** supr

PS: Frydlanstka x Bezrucova neni mini
 roundabout




No to už tam bylo. Sice se mi to nezdálo, ale zatím jsem
 to tak nechal. 
Mrknu na to. Problém je v tom, že tam je podobných chyb
 více a hodně toho 
chybí a nevím, kam dříve. Navíc jsem zjistil, že
 má rodná vesnice 
(Chlebovice) je jen název a čísla domů.
 Katastrální mapa je tam úplně 
prázdná. Takže momentálně chci
 dodělat sídliště, pak se vrhnu na Chlebovice 
a pak budu pokračovat s
 úpravami FM a okolí. Snad mi elán vydrží.




Ještě bych měl
 dotaz:

Nad Chlebovicemi je vrchol Kabátice. Z Wiki a jiných zdrojů
 dokáži zjistit 
nadmořskou výšku, ale se souřadnicemi to je horší.
 Nevede tam turistická 
značka, je to v lese, takže i kdybych ten vrchol
 fyzicky našel (což nebude 
jen tak), tak přesnost GPS bude špatná. Je
 nějaká možnost, jak zjistit 
přesnější souřadnice? Je mi jasné, že
 kdyby to bylo někde veřejně dostupné, 
tak by se to už dávno
 naimportovalo.





Marián


 


hanoj

___
Talk-cz
 mailing
 list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
(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] Průjezdy a další dotazy

2013-01-10 Tema obsahu Martin Kokeš
No, jak já mám tušit, nejsa jasnovidec, že používáš linux. ;-) V tom případě 
stačí proj4 a gdal z gentoo, není třeba fwtools.

Ten formulář je naprd, je to je Javascript.

pj_transform(): failed to load datum shift file  tak to tam asi nebudeš mít 
nahraný ten soubor s gridem.

MK

- Original Message -
From: Marián Kyral
[mailto:mky...@email.cz]
To: OpenStreetMap Czech Republic
[mailto:talk-cz@openstreetmap.org]
Sent: Thu, 10 Jan 2013 10:48:30
+0100
Subject: Re: [Talk-cz] Průjezdy a další dotazy


 

-- Původní zpráva --
Od: Marián Kyral
 mky...@email.cz
Datum: 10. 1. 2013
Předmět: Re: [Talk-cz] Průjezdy a
 další dotazy




-- Původní zpráva --
Od: Martin
 Kokeš sh...@typo3-hosting.com
Datum: 10. 1. 2013
Předmět: Re: [Talk-cz]
 Průjezdy a další dotazy

Ten GDAL pro Windows nějak nefunguje, asi je
 Maďar offline, tak
 
alternativa:
http://fwtools.maptools.org/(http://fwtools.maptools.org/)

MK




Díky,
 win verze není třeba. Mně stačí linux. Už to kompiluji na svém
 Gentoo.
Našel jsem i nějaké webové formuláře, ale fungoval mi jen
 jeden:
 http://www.
alena.ilcik.cz/gps/souradnice/JTSKtoWGS.htm
(http://www.alena.ilcik.cz/gps/souradnice/JTSKtoWGS.htm)




Ale
 trochu mě mate, že se tam zadává i nadmořská výška ta se
 přepočítá na 
688m. Přitom všude v mapách je 601m. Taky nevím jak
 moc je to přesné a 
jestli se tomu dá věřit. Uvidím co na to
 gdal.







Hmm, tak zatím končím na tomhle: 

pj_transform(): failed
 to load datum shift file








Marián


=

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


Re: [Talk-cz] presnejsi trackovani pro OSM

2012-10-15 Tema obsahu Martin Kokeš
Mno já myslel, že gyroskop je právě gyroskopem od toho, aby zmatený nebyl. ;-) 
A že akcelerometr nefunguje jen v jedné ose.
Nicméně,když taková zařízení fungují ve všem možném od RC vrtulníků, přes 
foťáky, Wii, Segway, auta až po kosmické sondy, kola i koně, nebo jiné 
přerostlé psy by to určitě zvládlo...

MK

- Original Message -
From: Pavel Machek [mailto:pa...@ucw.cz]
To:
OpenStreetMap Czech Republic [mailto:talk-cz@openstreetmap.org]
Sent: Mon,
15 Oct 2012 14:35:00 +0200
Subject: Re: [Talk-cz] presnejsi trackovani pro
OSM


 Ahoj!

 Já jsem v autě dosáhl slušných výsledků s Qstarz BT-Q1000X
 na 5 Hz v kombinaci s funkcí Kalman Filter v
 http://www.efficasoft.com/gpsutilities/windowsmobile_professional.html.
 Největší gró tam asi dělá ten Kalman filtr. Možná že by šlo
 použít pro postprocessing toto:
 https://github.com/lacker/ikalman
 

 Nicméně pro ostré zatáčky v lese by pomohl jedině GPS v kombinaci s
 gyroskopem/akcelerometrem.


To by asi fungovalo v aute, ale na kole se
 obavam bude
gyroskop/akcelerometr dost zmateny...

(Hmm. a co teprv na
 konskym hrbetu...)
Pavel
-- 
(english)
 http://www.livejournal.com/~pavelmachek
(cesky, pictures)
 http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

___
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] presnejsi trackovani pro OSM

2012-10-14 Tema obsahu Martin Kokeš
Určitě, ukaž, zajímá mě to. Já si tenkrát dělal porovnání současného záznamu 
Mediateku na 5 Hz s Kalmanem a Sirfu na 1 Hz vestavěného v HP RX5910 a ten 
Mediatek vypadal definitivně lépe.

MK

- Original Message -
From: Petr Holub
[mailto:ho...@ics.muni.cz]
To: 'OpenStreetMap Czech Republic'
[mailto:talk-cz@openstreetmap.org]
Sent: Sun, 14 Oct 2012 08:16:40
+0200
Subject: Re: [Talk-cz] presnejsi trackovani pro OSM


   Já jsem v autě dosáhl slušných výsledků s Qstarz BT-Q1000X na 5
 Hz v kombinaci s funkcí Kalman
  Filter
   v
 http://www.efficasoft.com/gpsutilities/windowsmobile_professional.html.
 Největší gró tam asi dělá
   ten Kalman filtr. Možná že by šlo použít pro postprocessing toto:
   https://github.com/lacker/ikalman
  
  Diky za tip - o Kalmanovic filtrovani jsem sice vedel, nicmene jsem si
  myslel, ze mi to moc nepomuze - u toho Holuxe mam problem v tom, ze on
  ma jakoby tendenci ustrelovat jakoby systematickou nikoli nahodnou chybou
  (tj. ne ze by ty body byly rozhazene kolem nejakeho spravneho prumeru,
  ale jsou ujete o nejak metry tam ci onam). Bohuzel nemam Windows Mobile,
  s nimiz bych to mohl primo pouzivat, nicmene jsem narazil na
  NMEA Processor, ktery by to mel taky zvladat:
  http://www.gpspassion.com/forumsen/topic.asp?TOPIC_ID=106662whichpage=21
  https://sites.google.com/site/victorpomortseff/nmea-processor
  ale jeste ho budu muset trochu prozkoumat, co to vlastne umi.
 
 Takze - uchodit jsem to uchodil a Kalman filtrovani dela presne to,
 co bych od neho cekal - odfiltruje tu nahodnou chybu (v uvozovkach
 to pisu proto, ze to, co jsem vyse oznacil jako systematickou chybu
 je ve skutecnosti taky nahodna, ale jina nez to kratkodobe driftovani.
 Pokud chcete, muzu nekam vystavit priklad, jak to dopadlo.
 
 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] presnejsi trackovani pro OSM

2012-10-13 Tema obsahu Martin Kokeš
Já jsem v autě dosáhl slušných výsledků s Qstarz BT-Q1000X na 5 Hz v kombinaci 
s funkcí Kalman Filter v 
http://www.efficasoft.com/gpsutilities/windowsmobile_professional.html. 
Největší gró tam asi dělá ten Kalman filtr. Možná že by šlo použít pro 
postprocessing toto:
https://github.com/lacker/ikalman

Nicméně pro ostré zatáčky v lese by pomohl jedině GPS v kombinaci s 
gyroskopem/akcelerometrem.

MK

- Original Message -
From: Petr Holub
[mailto:ho...@ics.muni.cz]
To: 'OpenStreetMap Czech Republic'
[mailto:talk-cz@openstreetmap.org]
Sent: Sat, 13 Oct 2012 19:58:05
+0200
Subject: [Talk-cz] presnejsi trackovani pro OSM


 Ahoj vespolek,
 
 trochu jsem hledal, jeslti by se nejakymi rozumne dostupnymi prostredky
 nedala zlepsit presnost tracklogu, zejmena ziskanych na kole, ale klidne
 i pesky a autem. Zlobi mne to hlavne pri rychlejsi jizde na kole spojene
 s rycheljsimi zmenami smeru (kdy Garmin 60CSx nestiha zatacet) a v lese,
 kde
 je presnost vubec na pytel (60CSx ani Holux M-1000C). Zacal jsem uvazovat
 o nejakem modulu, ktery by sbiral raw GPS data na dostatecne frekvenci, na
 nichz by se dal udelat postprocesing - ale ne v cenove kategorii 30.000CZK
 a vic (tedy profi GPS zarizeni). Narazil jsem dve firmicky, ktere neco
 takoveho delaji (a do jiste miry spolu i spolupracuji): Optimalsystem.de
 a OneTalent-GNSS. Navrhy desek dela Michele Bavaro pro obe firmy a primarne
 pracuje pro ten OneTalent-GNSS - nize najdete jak moje dotazy na neho, tak
 i jeho odpovedi. Prestoze vyjadruje skepsi kolem dosazeni presnosti 1m
 v lese (pricem 1m povazuji pro potreby OSM naprosto dostacujici), nicmene
 porad by to mohlo by podstatne zlepseni proti tomu, co mam ted. Uvazuji
 o jednom z nasledujicich modulu:
 http://www.onetalent-gnss.com/ideas/wireless/denga10logbt
 http://www.onetalent-gnss.com/ideas/wireless/rappen10logbt
 Jinak data pro postprocesing by napr. pro okoli Brna mely byt zdarma
 dostupne ze site stanic EUREF:
 http://www.epncb.oma.be/_networkdata/stationlist.php
 pro Brno napr. tady:
 http://www.epncb.oma.be/_networkdata/siteinfo4onestation.php?station=TUBO_11503M001
 
 
 Moje dotazy do fora:
 - Hrali jste si nekdo s necim podobnym?
 - Meli byste chut a cas se nekdo do toho taky pustit?
 
 Diky,
 Petr
 
 
 
 From: Michele Bavaro [mailto:mbav...@onetalent-gnss.com] 
 Sent: Sunday, October 07, 2012 10:19 PM
 To: Petr Holub
 Subject: Re: a module for accurate mapping for OSM
 
 Hello Petr,
 
 Thanks for getting in touch!
 
 It will be very difficult to guarantee 1m accuracy (standalone real-time or
 differential post-processed) under dense
 foliage.
 Trees are well known to disrupt carrier phase information which is essential
 to achieve such accuracies.
 There is something about it on the German forum Kowoma:
 http://www.kowoma.de/gpsforum/viewtopic.php?f=1t=3248p=14992#p14992
 
 Denga10 and Rappen10 are not suitable. But their _LogBt or _LogWi version
 instead might work: they have a battery which
 will last a longer than 6hr, logging, and Bluetooth - or pretty much any
 other wireless communication system. Of course
 both have raw measurements but their carrier phase will be impaired under
 foliage as I wrote above.
 I am finalising the firmware in these days (today I had logging with fatfs
 and USB MSC running simultaneously finally)
 but -as it is quite experimental- I cannot really claim that is a set and
 forget kind of solution.
 Firmware is open though and if you have programming skills you may modify it
 to your needs.
 I am also working on enclosures... I have the bare boxes but I need to
 hand-tool them.
 If you are happy to do it by yourself I can make a discount:
 http://www.onetalent-gnss.com/announcements/contributorsgetafreereceiver
 
 Unfortunately in any case I cannot make you a lower price than
 250EUR+VAT+shipping as I hand assemble the boards and I
 don't sell many of them so I cannot reduce the price by producing volumes. 
 
 I would love to help you but I understand that compared to a 100EUR logger
 it's a lot of money to invest.
 By the way, all new Mediatek receivers have 10Hz and very high
 sensitivity... the new MTK also has Glonass.
 ST Microelectronics has the STA8088FG which performs very well and it's very
 low cost.
 Not to mention of course the usual CSR GSD4E and Skytraq Venus..
 Have you looked at Fastrax, Locosys, and GlobalTop?
 
 I am very happy to help an enthusiastic mapper, please let me know if I can
 do something else for you.
 
 Best regards,
 Michele
 
 
 
 
 
 On 7 October 2012 18:52, Petr Holub ho...@ics.muni.cz wrote:
 Hello,
 
 I'm looking for a GNSS module that could improve precision of my
 mapping efforts for Openstreetmap - mainly mountainbike trails and
 hiking paths in the Czech Republic (http://www.mtbmap.cz/). Up to
 now, I'm using Sirf3-based Garmin 60CSx mounted on the MTB handlebar,
 and MTK3329-based Holux M-1000C logger switched to 10Hz, mounted to
 my MTB helmet. While Garmin 60CSx produces reasonably precise
 results while 

Re: [Talk-cz] presnejsi trackovani pro OSM

2012-10-13 Tema obsahu Martin Kokeš
Prý to je hodně špatné:
http://stackoverflow.com/questions/7829097/android-accelerometer-accuracy-inertial-navigation

Třeba by se dalo něco sestavit na platformě Arduino, ale to by musel nějaký 
znalec...
http://arduino.cc/forum/index.php?topic=58048.0
http://arduino.cc/forum/index.php/topic,104951.0.html

MK

- Original Message -
From: hanoj [mailto:eha...@gmail.com]
To:
OpenStreetMap Czech Republic [mailto:talk-cz@openstreetmap.org]
Sent: Sat,
13 Oct 2012 21:24:37 +0200
Subject: Re: [Talk-cz] presnejsi trackovani pro
OSM


  Nicméně pro ostré zatáčky v lese by pomohl jedině GPS v kombinaci
 s
 gyroskopem/akcelerometrem.
*** to mne taky uz napadlo proc se to v praxi
 nepouziva, vzdyt 3D
akcelerometr a elekro-kompas ma uz kazdy
 Android

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] dotaz na funkčnost http://maps.fordfrog.com/

2012-10-05 Tema obsahu Martin Kokeš
Tak to by si měli ve Velemíně nebo na nadřízeném stavebním úřadu asi opravit ne?

Viz.
http://www.cuzk.cz/Dokument.aspx?PRARESKOD=998MENUID=10769AKCE=DOC:10-RUIAN_METODIKA_2

- Original Message -
From: jzvc [mailto:j...@tpfree.net]
To:
talk-cz@openstreetmap.org
Sent: Thu, 04 Oct 2012 23:43:56 +0200
Subject: Re:
[Talk-cz] dotaz na funkčnost http://maps.fordfrog.com/

 Cus, tuhle
 http://maps.fordfrog.com/?zoom=18lat=50.53776lon=13.97885layers=B00FFF se
 cisla popisny renederujou celkem dost mimo budovy - a samo uplne jinde
 nez sou na km.

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


[Talk-cz] Fw: Re: Administrativni hranice z RUIAN

2012-08-31 Tema obsahu Martin Kokeš
Každý dobrý úmysl nebo skutek musí být po zásluze potrestán. :-)

Ne vážně, je třeba zvážit priority. Pro mě je tedy podstatnější prioritou mít v 
mapě přesné hranice KÚ, ne to, co musím furt opravovat nepříliš chytrou WMS 
metodou, když někam náhodou zabloudím. Stejně jsem chtěl vzít KN z INSPIRE 
tématu (tam je jen DKM nebo KMD) a opravit to sám. A jestli má někdo na hranici 
KÚ něco navázané, to mi je srdečně jedno, neměl to vázat, nebo tu hranici měl 
opravit, aby aspoň seděla s KN. A pokud se chce na ty případy Petr tady navíc 
podívat ručně, nechápu smysl toho přílišného zaměření se na detail - řečeno 
diplomaticky.

MK

- Original Message -
From: Petr Morávek [Xificurk]
[mailto:p...@pada.cz]
To: OpenStreetMap Czech Republic
[mailto:talk-cz@openstreetmap.org]
Sent: Thu, 30 Aug 2012 23:37:52
+0200
Subject: Re: [Talk-cz] Administrativni hranice z RUIAN


 jzvc wrote:
 Vidim problem v tom, ze takhle vyrobis cosi jako totalne
 oddelenou
 vrstvu, sniz kdokoli cokoli spoji, tak ty mu to smaznes.

Ale
 vždyť už jsem několikrát psal, že jako nejlepší řešení vidím,
 že se
podle logu na těch pár spojených starých objektů podívám
 ručně, a pokud
to bude vhodné, tak je spojím zpět.
Můžeš napsat
 konkrétně, co se ti na tomhle postupu nezamlouvá? Tohle
podle mě fakt
 jinak než ručně (člověkem) rozhodnout nejde, pokud máš
opačný
 názor, popiš prosím rozhodovací algoritmus (stačí slovně), který
by
 tento problém spolehlivěe automaticky řešil.

Zdraví,
Petr Morávek aka
 Xificurk

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

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


Re: [Talk-cz] Administrativni hranice z RUIAN

2012-08-31 Tema obsahu Martin Kokeš
wget http://git.zcu.cz/grid/czech.lla
nad2bin  czech.lla /usr/share/proj/czech

2065 mi pak funguje jako '+proj=krovak +lat_0=49.5 +lon_0=42.5 
+alpha=30.2881397222 +k=0. +x_0=-0 +y_0=-0 +ellps=bessel 
+nadgrids=czech +pm=ferro +to_meter=-1 +no_defs' resp. zkráceně, definice toWGS 
se nahradí za definici nadgrids

MK

- Original Message -
From: Petr Morávek [Xificurk]
[mailto:p...@pada.cz]
To: OpenStreetMap Czech Republic
[mailto:talk-cz@openstreetmap.org]
Sent: Fri, 31 Aug 2012 14:06:26
+0200
Subject: Re: [Talk-cz] Administrativni hranice z RUIAN


 Martin Kokeš wrote:
 Jsem stejného názoru. Pracuju s daty z RÚIAN a
 WSDP ISKN v CouchDB, kde mám uložené přesně transformované souřadnice
 přes nadgrids=czech a pro výstup v GeoJSON je lehce generalizuju. Když tu
 ty data jsou, tak proč je nemít přesná.
 
 MK

V souvislosti se
 zjednodušováním geometrie, mi až teď došlo, že zatím
jsem používal
 sedmiprvkovou transformaci s klíčem +towgs, která nemá
úplně
 nejlepší přesnost.
Můžete mě prosím někdo nasměrovat na vhodný
 soubor s českým gridem?

Zdraví,
Petr Morávek aka
 Xificurk

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

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


Re: [Talk-cz] Administrativni hranice z RUIAN

2012-08-30 Tema obsahu Martin Kokeš
Doufám, že to pak po jednoduchém simplify nevypadá jako na třetím obrázku... :-)
http://trac.osgeo.org/postgis/wiki/UsersWikiSimplifyPreserveTopology

MK
- Original Message -
From: Petr Morávek [Xificurk]
[mailto:p...@pada.cz]
To: OpenStreetMap Czech Republic
[mailto:talk-cz@openstreetmap.org]
Sent: Thu, 30 Aug 2012 12:12:14
+0200
Subject: Re: [Talk-cz] Administrativni hranice z RUIAN


 Mike wrote:
 Jenže ono to tak často je, že dům stojí na dvou
 katastrálních územích.

Jenže o tomhle případu jsem já vůbec
 nepsal. ;-)

Zopakuji, co jsem napsal už dříve:
JESTLIŽE vede hranice
 přesně se zdí domu, tak by zjednodušení mohlo
způsobit, že najednou
 bude roh domu na jedné straně a zbytek na druhé
straně hranice.
A
 přidám:
JESTLIŽE vede hranice skrz dům, tak by zjednodušení mohlo
 způsobit, že
najednou bude celý dům jen na jedné straně hranice.

To
 samé platí o tvé připomínce k plotu z druhého mailu:
JESTLIŽE plot
 vede po hranici, tak je spojení obou objektů naprosto v
pořádku a dává
 dodatečnou informaci.
JESTLIŽE vede plot vedle hranice, tak je spojení
 samozřejmě špatně.

Opravdu si myslím, že když už ta přesná data
 máme, tak bysme je neměli
zbytečně znehodnocovat.


Ad zjednodušení
 geometrií:
Dělal jsem ještě nějaké testy na datech RUIANu a zdá se,
 že pokud
provedu zjednodušení (Douglas-Peucker) s přesností na 1cm
 (což je taky
zhruba přesnost s jakou jsou data v OSM uložena), tak počet
 nodů jde
dolu o zhruba 17%. To je myslím celkem slušná redukce bez
 výrazné ztráty
informace.
Jen pro úplnost: přesnost 0.1m dává redukci
 22%, 1m potom 39%.

Zdraví,
Petr
 Morávek

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

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


Re: [Talk-cz] Vrcholy kopců

2012-08-30 Tema obsahu Martin Kokeš
Nevidím důvod proč by nemohla, je to úřední dílo, které má svou vyhlášku 
31/1995 Sb. Bohužel hromadné na 50 bodů výstupy nejsou bezúplatné.

MK

 Nicmene by bylo dobre, kdyby nekdo se znalosti formalnich procesu
 v GISech dal vedet, zda se ta bodova pole smi pouzivat jako zdroj
 dat ci nikoli.
 
 Diky,
 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

2012-08-28 Tema obsahu Martin Kokeš
Jsem stejného názoru. Pracuju s daty z RÚIAN a WSDP ISKN v CouchDB, kde mám 
uložené přesně transformované souřadnice přes nadgrids=czech a pro výstup v 
GeoJSON je lehce generalizuju. Když tu ty data jsou, tak proč je nemít přesná.

MK

- Original Message -
From: Petr Morávek [Xificurk]
[mailto:p...@pada.cz]
To: OpenStreetMap Czech Republic
[mailto:talk-cz@openstreetmap.org]
Sent: Tue, 28 Aug 2012 09:06:49
+0200
Subject: Re: [Talk-cz] Administrativni hranice z RUIAN


 hanoj wrote:
 Geometrii bych určitě nezjednodušoval, to je celkem

 zbytečná nepřesnost.
 *** uplne bych se tomu nebranil, presna hranice ma
 smysl pokud pracuji
 s katastralni mapou (aby 1 parcela nebyla ve 2 k.u.).
 Chyba 1 metr je
 v nasich potrebach dostacujici.

Já si zas říkám, že
 ty nody se dají případně zrecyklovat i na další věci
(vzhledem k
 tomu, že vedou po hranicích parcel). Jestliže vede hranice
přesně se
 zdí domu, tak by zjednodušení mohlo způsobit, že najednou bude
roh domu
 na jedné straně zbytek na druhé straně hranice.
V podstatě jediný
 důvod pro zjednodušení je redukce většího množství
nodů... což mi
 nepřijde jako příliš silný argument.

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

Občas
 bohužel mají... už jsem na to v minulosti při opravách
 narazil.

Zdraví,
Petr Morávek aka
 Xificurk

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

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


Re: [Talk-cz] import budov

2012-08-02 Tema obsahu Martin Kokeš
Předpokládám, že tehdy při importu UIR-ADR nikdo chybu při převodu JTSKWGS84 
neřešil. :-)

http://grass.fsv.cvut.cz/wiki/images/c/c6/Dopnul_wgs84_jtsk_xyerr.png

MK

- Original Message -
From: Jan Breuer
[mailto:jan.bre...@jaybee.cz]
To: OpenStreetMap Czech Republic
[mailto:talk-cz@openstreetmap.org]
Sent: Thu, 02 Aug 2012 17:52:08
+0200
Subject: Re: [Talk-cz] import budov


 V celem Liberci to bylo take uplne stejne posunute nahoodne o nekolik domu,
 ale pritom korektne otagovane. Mnoho desitek adres jsem tehdy opravoval
 rucne, kdyz jsem na to narazil.
 
 JB
 
 Dne 2.8.2012 16:35 LM_1 flukas.robot+...@gmail.com napsal/a:
 
 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 :)
 
  ...
 

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


Re: [Talk-cz] import budov

2012-08-02 Tema obsahu Martin Kokeš
Bohužel v metrech. :-) Např. Pardubice cca 20 metrů SV-JZ.

MK
- Original Message -
From: Petr Morávek [Xificurk]
[mailto:xific...@gmail.com]
To: OpenStreetMap Czech Republic
[mailto:talk-cz@openstreetmap.org]
Sent: Thu, 02 Aug 2012 18:49:28
+0200
Subject: Re: [Talk-cz] import budov


 Martin Kokeš wrote:
  Předpokládám, že tehdy při importu UIR-ADR nikdo chybu při převodu
 JTSKWGS84 neřešil. :-)
  
  http://grass.fsv.cvut.cz/wiki/images/c/c6/Dopnul_wgs84_jtsk_xyerr.png
  
  MK
 
 Ahoj,
 
 to jsou odchykly v centimetrech, ne? To je/bylo pro import adresních
 bodů celkem irrelevantní.
 U importu budov už by možná mělo smysl přemýšlet nad přesnější
 transformací s nadgrids=czech. Na některých místech by ten necelý metr
 už mohl být znát, ale i tak by to asi nebyla žádná velká tragédie.
 
 Petr
 

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


Re: [Talk-cz] import budov

2012-08-02 Tema obsahu Martin Kokeš
S tou sedmiprvkovou transformací je to samozřejmě přesnější. Jde o to, jestli 
byla při importu UIR-ADR použita... :-)

MK

- Original Message -
From: Petr Morávek [Xificurk]
[mailto:xific...@gmail.com]
To: OpenStreetMap Czech Republic
[mailto:talk-cz@openstreetmap.org]
Sent: Thu, 02 Aug 2012 22:29:45
+0200
Subject: Re: [Talk-cz] import budov


 Martin Kokeš wrote:
  Bohužel v metrech. :-) Např. Pardubice cca 20 metrů SV-JZ.
  
  MK
 
 Určitě? V porovnání s čím?
 Sice mám v tomhle směru fakt limitované znalosti, ale když jsem stáhnul
 grid [1] a zkusil transformovat pár bodů z Ostravska, tak se výsledek
 oproti definici [2] lišil cca o 0.5m (plus opačná znaménka).
 
 Petr
 
 [1] http://grass.fsv.cvut.cz/wiki/index.php/S-JTSK-Grid
 [2] http://spatialreference.org/ref/sr-org/czech-s-jtsk-epsg2065/proj4/
 
 

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


Re: [Talk-cz] import budov

2012-08-01 Tema obsahu Martin Kokeš
Mimo UIR-ADR importu (hodně slabé) je IMHO většina adres je dělána pomocí 
czechaddress pluginu 
http://wiki.openstreetmap.org/wiki/CS:JOSM/Plugins/CzechAddress a následně 
ručně umístěných podle adresních bodů v KN.

MK

- Original Message -
From: LM_1
[mailto:flukas.robot+...@gmail.com]
To: OpenStreetMap Czech Republic
[mailto:talk-cz@openstreetmap.org]
Sent: Wed, 01 Aug 2012 14:48:17
+0200
Subject: Re: [Talk-cz] import budov


 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

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


Re: [Talk-cz] import budov

2012-07-29 Tema obsahu Martin Kokeš
Já jsem pro hromadný import, případně následně pro vytvoření robota na údržbu. 
Minimálně u adresních bodů. 

MK 

- Original Message -
From: hanoj [mailto:eha...@gmail.com]
To:
OpenStreetMap Czech Republic [mailto:talk-cz@openstreetmap.org]
Sent: Sat,
28 Jul 2012 22:35:08 +0200
Subject: Re: [Talk-cz] import budov


 Ja bych nadhodil nekolik otazek treba pro adresni body:

* Kolik je
 adresnich bodu? 2.500.000
* Kolik mapperu se bude ucastnit takove prace?
 Prvni desitky.
* Jak dlouho to bude trvat? ...

* Jaka cast dat by mela byt
 mappery pridavana tam kde nikdy nebyla? Vetsina.
* Jak budou uzivatele
 hodnotit (ne)kvalitu dat jiz v OSM? Na zaklade
dat CUZK a u par stovek bodu
 ze znalosti z terenu kde bydli.Tezko
 ale
suplovat:
http://www.cuzk.cz/GenerujSoubor.ashx?NAZEV=10-POROVNANIADRES

Opravdu
 je individualni prace na vetsine uzemi republiky cesta, jak
data RUIAN
 dostat do OSM?


h.anoj


Dne 27. července 2012 17:17 Miroslav Šulc
 fordf...@fordfrog.com napsal(a):
 v souvislosti s tím co píšeš mě
 napadlo udělat to komplet jako josm
 plugin. tj. serverová část by
 zůstala tak jak jsem psal, ale všechno
 ostatní by se dělalo přímo z
 josm pluginu. ten by si stáhl data přes api
 ode mě ze serveru z
 aktuální databáze rúian, provedl by porovnání s
 datovou vrstvou z
 osm a vyhodil by nějaké info o rozdílech v osm a v
 rúian s tím, že
 mapper by si vybíral varianty a potvrzoval je, případně
 by sáhnul
 přímo do osm vrstvy a udělal úpravy tam. při uploadu změn do
 osm by
 se pak zapsalo i info ke mně na server o provedení importu. do
 pluginu
 by se pak dala přidávat funkcionalita dle potřeby.

 ff

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

 možnosti.

 Pokud nic vhodné stávajícího není, tak bych to viděl
 spíše na
 interaktivní aplikaci, která zobrazí ty rozdíly ve vhodné
 podobě, u
 každé umožní se rozhodnout, zda ponechat stará data,
 nová data,
 automaticky zmergovat nebo ručně upravit. Ruční úpravu
 by ta aplikace
 přímo nepodporovala, protože by to bylo příliš
 náročné (vlastně by
 bylo třeba vytvořit obdobu editoru jako JOSM),
 ale poznačilo by to
 nutnost ruční editace do dat nějakými tagy, aby
 výsledek, který z
 aplikace vypadne, bylo možné otevřít např. v
 JOSM a ručně provést
 potřebné úpravy.

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

 tagů (ty by možná bylo třeba také kontrolovat v aplikaci) atd.

 U
 budov to bude samozřejmě výrazně složitější.

 Obecně čistě
 ručního importu se celkem obávám. Dat je vetší než malé
 množství.

 Honza


 Dne 27. července 2012 13:41 Miroslav Šulc
 fordf...@fordfrog.com napsal(a):
 Dne 27.7.2012 13:20, Jan Bilak
 napsal(a):
 Ahoj,

 teď z toho nechápu, zda si aplikaci
 představuješ jen jako evidenční
 nebo zda aplikace má provádět
 vlastní import (resp. s ním výrazně
 pomáhat).
 aplikace pouze
 připraví data z rúian, samotný import provede mapper.
 tj. aplikace
 pro import připraví data, ale nebude import provádět, ten
 se bude
 dělat ručně. i kdybychom (pokud vůbec, to vyplyne z ručních

 importů) v budoucnu uvažovali o nějaké automatizaci, tak v prvním
 kroku
 se to stejně musí udělat ručně, abychom věděli, nakolik je
 rúian
 spolehlivý zdroj, jaké problémy lze očekávat apod. pro
 kontinuální práci
 s daty z rúian je pak potřeba ta evidenční
 část.

 Tedy za zásadní považuji porovnání současných OSM
 dat s daty RUIAN a
 následné provedení změn (posuny stávajících
 bodů, opravy tagů,
 zachování stávajících tagů, doplnění
 chybějících tagů, ...).
 Samozřejmě s tím, že proces bude pod
 manuální kontrolou člověka, který
 bude import provádět (tedy
 nikoli plně automatický, ale
 poloautomatický). O těchto funkcích
 se v popisu nezmiňuješ.
 vycházel jsem hlavně z importu budov tam,
 kde je nemáme, to je asi ta
 nejjednodušší varianta. co se týče
 importu budov do míst, kde už nějaké
 jsou, nebo importu adresních
 bodů, tak se přiznám, že 

Re: [Talk-cz] (skoro) funkční rúian wms vrstvy

2012-07-20 Tema obsahu Martin Kokeš
102067,PROJCS[S-JTSK_Krovak_East_North,GEOGCS[GCS_S_JTSK,DATUM[Jednotne_Trigonometricke_Site_Katastralni,SPHEROID[Bessel_1841,6377397.155,299.1528128]],PRIMEM[Greenwich,0],UNIT[Degree,0.017453292519943295]],PROJECTION[Krovak],PARAMETER[False_Easting,0],PARAMETER[False_Northing,0],PARAMETER[Pseudo_Standard_Parallel_1,78.5],PARAMETER[Scale_Factor,0.],PARAMETER[Azimuth,30.2881397528],PARAMETER[Longitude_Of_Center,24.83],PARAMETER[Latitude_Of_Center,49.5],PARAMETER[X_Scale,-1],PARAMETER[Y_Scale,1],PARAMETER[XY_Plane_Rotation,90],UNIT[Meter,1],EXTENSION[PROJ4,+proj=krovak
 +lat_0=49.5 +lon_0=24.83 +alpha=30.2881397222 +k=0. +x_0=0 
+y_0=0 +ellps=bessel +nadgrids=czech +pm=greenwich +units=m 
+no_defs],AUTHORITY[EPSG,102067]]

Možná lépe v případě použití PROJ4 a S-JTSK nadgridu? Aby někdo nepanikařil, že 
to má ve 4326 posunuté... ;-)

- Original Message -
From: Miroslav Šulc
[mailto:fordf...@fordfrog.com]
To: 
Cc: OpenStreetMap Czech Republic
[mailto:talk-cz@openstreetmap.org]
Sent: Fri, 20 Jul 2012 10:56:29
+0200
Subject: Re: [Talk-cz] (skoro) funkční rúian wms vrstvy


 nastavil jsem tam teda jen ty čtyři srs. pokud by tam někdo chtěl
 ještě
 ještě nějaký přidat, tak dejte vědět.
 
 ff
 
 Dne 20.7.2012 10:01, Jachym Cepicky napsal(a):
  V naší WMS prohlížečce se projevila (typická) chybka při
 konfiguraci
  Geoserveru. Geoserver ve výchozím nastavení publikuje *všechny*
  podporované souř. systémy, i ty které nemají na daném území smysl.
 
  Prosil bych, v nastavení WMS dát do pole Limited SRS list hodnoty
 
  4326, 2065, 5514, 102067 (případně další).
 
  Bude potřeba do souboru data_dir/user_projection/epsg.properties doplnit
  následující řádky (tedy, dělám to poprvé, snad to bude ok):
 
 
 5514=PROJCS[S-JTSK_Krovak_East_North,GEOGCS[GCS_S_JTSK,DATUM[Jednotne_Trigonometricke_Site_Katastralni,SPHEROID[Bessel_1841,6377397.155,299.1528128],TOWGS84[498.17,136.89,510.08,6.007,4.343,3.831,3.38]],PRIMEM[Greenwich,0],UNIT[Degree,0.017453292519943295]],PROJECTION[Krovak],PARAMETER[False_Easting,0],PARAMETER[False_Northing,0],PARAMETER[Pseudo_Standard_Parallel_1,78.5],PARAMETER[Scale_Factor,0.],PARAMETER[Azimuth,30.2881397528],PARAMETER[Longitude_Of_Center,24.83],PARAMETER[Latitude_Of_Center,49.5],PARAMETER[X_Scale,-1],PARAMETER[Y_Scale,1],PARAMETER[XY_Plane_Rotation,90],UNIT[Meter,1],AUTHORITY[EPSG,5514]]
 
 102067=PROJCS[S-JTSK_Krovak_East_North,GEOGCS[GCS_S_JTSK,DATUM[Jednotne_Trigonometricke_Site_Katastralni,SPHEROID[Bessel_1841,6377397.155,299.1528128],TOWGS84[498.17,136.89,510.08,6.007,4.343,3.831,3.38]],PRIMEM[Greenwich,0],UNIT[Degree,0.017453292519943295]],PROJECTION[Krovak],PARAMETER[False_Easting,0],PARAMETER[False_Northing,0],PARAMETER[Pseudo_Standard_Parallel_1,78.5],PARAMETER[Scale_Factor,0.],PARAMETER[Azimuth,30.2881397528],PARAMETER[Longitude_Of_Center,24.83],PARAMETER[Latitude_Of_Center,49.5],PARAMETER[X_Scale,-1],PARAMETER[Y_Scale,1],PARAMETER[XY_Plane_Rotation,90],UNIT[Meter,1],AUTHORITY[EPSG,102067]]
 
 
  Dík
 
  Jáchym
 
  Dne 19.7.2012 16:22, Miroslav Šulc napsal(a):
  ahoj,
 
  na adrese http://wms.fordfrog.com/wms? jsou k dispozici vrstvy z rúian
  dat. data se ještě importují do databáze, takže tam nejsou zatím
  kompletní, ale někde už jsou vidět (např. bělá pod bezdězem).
 
  jsou tam celkem 4 vrstvy plus jedna složená: adresní body, ulice,
  stavební objekty, zastavěné parcely a vše (složená). pokud byste
 tam
  chtěli ještě nějaké vrsvty přidat, tak dejte vědět.
 
  grafická kvalita toho výstupu zatím není nic moc. pokud by mi někdo
 byl
  schopný poradit, jak to zobrazení vylepšit, tak bych to uvítal.
 běží to
  na geoserveru 2.1.4.
 
  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] Data RUIAN - výměnný formát

2012-06-30 Tema obsahu Martin Kokeš
Čistě matematická transformace dosahuje značné nepřesnosti v závislosti na 
lokalitě až 70 metrů.
http://grass.fsv.cvut.cz/gwiki/Chyba_při_transformaci_z_WGS84_do_S-JTSK

Převod GML se dělá pomocí ogr2ogr, případně lze GDAL knihovnu začlenit do 
Céčkového programu nebo do Python skriptu bez problémů pomocí API: 
http://gdal.org/gdal_tutorial.html

MK

- Original Message -
From: Pavel Machek [mailto:pa...@ucw.cz]
To:
OpenStreetMap Czech Republic [mailto:talk-cz@openstreetmap.org]
Sent: Sat,
30 Jun 2012 12:45:23 +0200
Subject: Re: [Talk-cz] Data RUIAN - výměnný
formát


 On Sat 2012-06-23 04:45:21, Jan Bilak wrote:
 Díky. Nevíte o nějakých
 knihovnách (.NET, Java, JavaScript, C, C++,
 ...) pro transformaci pomocí
 toho S-JTSK gridu? Nebo, pokud nejsou
 přímo knihovny, ve kterých
 opensource programech s vhodnou licencí by
 tato transformace šla
 najít?

Ja tu mam:

gdalwarp -s_srs +proj=krovak +a=6377397.155
 +rf=299.1528128 +no_defs
+towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56
 -t_srs
+proj=latlong +a=6378137 +rf=298.257223563
 +no_defs
+towgs84=0.000,0.000,0.000
 /data/gis/READ-ONLY/cechy.tif
/tmp/delme.tiff

a pak pascalovej zdrojak:

{

Copyright 2005 Zdenek Hrdina, distribute under GPLv2
}

procedure
 jtsk_wgs( X,Y,Hel:double; var B,L,H:double);
{Vypocet zemepisnych souradnic
 v systemu WGS-84 z rovinnych souradnic
S-JTSK a elipsoidicke
 vysky}

procedure transformace_BLH(var B,L,H: double);
{Transformace
 zemepisnych souradnic z JTSK do WGS}
 var
 lat,lon,alt,x1,y1,z1,x2,y2,z2:double;


... Poslu nebo by mel jit
 vygooglit.
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky,
 pictures)
 http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

___
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] Formát zápisu adresních bodů (was Data RUIAN - výměnný formát)

2012-06-26 Tema obsahu Martin Kokeš
Některé atributy jsou důležité pro službu Nominatim

http://wiki.openstreetmap.org/wiki/Nominatim/Development_overview

MK

- Original Message -
From: Libor Pechacek
[mailto:lpecha...@gmx.com]
To: OpenStreetMap Czech Republic
[mailto:talk-cz@openstreetmap.org]
Sent: Tue, 26 Jun 2012 19:21:52
+0200
Subject: Re: [Talk-cz]  Formát zápisu adresních bodů (was Data
RUIAN - výměnný formát)


 Ahoj Honzo,

Zabral jsem se do detailů a nějak zapomněl uzavřít
 návrhem.

Jsem pro požití tagů addr:housenumber,
 addr:streetnumber,
addr:conscriptionnumber, addr:street a is_in.  Is_in
 proto, že často obsahuje
informaci o městských částech, kterou z mapy
 nelze odvodit.  Pokud někdo najde
nějakou hypoalergenní[1] variantu k
 is_in, jsem pro.

Dál navrhuji seskupit adresy jedné ulice do relace,
 která ponese addr:street a
is_in, aby se předešlo duplikaci.  Adresní
 body by v tom případě měly jen
addr:housenumber, addr:streetnumber a
 addr:conscriptionnumber.  Otázkou je, jak
by taková relace měla
 vypadat[2].

Addr:postcode, addr:city a addr:country bych klidně zahodil,
 pokud neposlouží
jako náhrada is_in.

Libor

[1]
 http://wiki.openstreetmap.org/wiki/Key:is_in#Controversy
[2] v úvahu
 zřejmě připadá
   
 http://wiki.openstreetmap.org/wiki/Relations/Proposed/Collected_Ways,
   
 http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street nebo
   
 http://wiki.openstreetmap.org/wiki/Relation:associatedStreet

On Tue
 26-06-12 16:12:11, Jan Bilak wrote:
 Ahoj,
 
 díky za rozbor, ale myslel
 jsem to tak, jaký zápis chceme v OSM
 ideálně mít. Tedy v jakém
 formátu připravovat import z RUIAN, jaké
 tagy tam dát pro nové
 adresní body, jaké tagy doplnit ke stávajícím,
 jaké existující
 tagy případně smazat nebo změnit (ostatní předpokládám
 zachovat).
 Tedy aby to všude jednotné (+ u některých bodů nějaké
 specifické
 tagy). Jak se má složit obsah tagu is_in (pokud tam má
 být), protože
 to je složenina různých údajů.
 
 Honza
 
 
 Dne 26. června 2012
 13:58 Libor Pechacek lpecha...@gmx.com napsal(a):
  Ahoj,
 
  Z
 mojí zkušenosti se formát adresního bodu liší podle použitého
 nástroje.  Jsou
  tři (polo)automatické způsoby importu, a nakonec
 pak ruční zadání.
 
  On Tue 26-06-12 04:14:04, Jan Bilak wrote:

  jak vypadá ideální zápis adresního bodu v OSM XML? Koukal jsem se
 do
  snapshotu OSM dat ČR a zápisy nemají jednotný formát. Např.:

 
        node id=296674495 lat=48.9631350 lon=14.5119948
 version=2
  changeset=1965423 user=Radomír Černoch uid=51295

  timestamp=2009-07-28T14:56:31Z
                tag
 k=addr:conscriptionnumber v=2030 /
                tag
 k=addr:housenumber v=2030/1 /
                tag
 k=addr:postcode v=37006 /
                tag
 k=addr:street v=U pramene /
                tag
 k=addr:streetnumber v=1 /
                tag
 k=source:addr v=uir_adr /
                tag
 k=uir_adr:ADRESA_KOD v=23398671 /
        /node
 
  Tohle
 je podle mě výsledek UIR-ADR importu.
 
 http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap#Adresn.C3.AD_body_-_MPSV.28UIR-ADR.29

 
        node id=1496603658 lat=48.8736400 lon=14.6758775
 version=1
  changeset=9784174 user=Petr1868 uid=72020
 
 timestamp=2011-11-09T19:54:47Z
                tag
 k=addr:conscriptionnumber v=13 /
                tag
 k=addr:country v=CZ /
                tag
 k=addr:housenumber v=13 /
                tag k=is_in
 v=Třebeč, Borovany, Jihočeský kraj, CZ /
               
 tag k=source:addr v=mvcr:adresa /
                tag
 k=source:loc v=cuzk:km /
        /node
 
  Tento záznam
 vytváří nástroje napsané Lukášem Kábrtem.
 
 http://wiki.openstreetmap.org/wiki/Import_Adres_%C4%8CR
  Pokud jsou v
 obci ulice, je přítomen i tag addr:street.
 
        node
 id=33705330 lat=49.7021197 lon=17.0731786 version=12
 
 changeset=5435557 user=NE2 uid=207745
 
 timestamp=2010-08-08T17:43:41Z
                tag
 k=addr:city v=Litovel /
                tag
 k=addr:conscriptionnumber v=678 /
                tag
 k=addr:country v=CZ /
                tag
 k=addr:housenumber v=678/1 /
                tag
 k=addr:postcode v=78401 /
                tag
 k=addr:street v=Mlýnská /
                tag
 k=addr:streetnumber v=1 /
                tag k=is_in
 v=Litovel, Olomoucký kraj, CZ /
                tag k=name
 v=Penzion U starého mlýna /
                tag
 k=source:addr v=mvcr:adresa /
                tag
 k=tourism v=hotel /
                tag k=url
 v=http://ustarehomlyna.cz; /
        /node
 
  Tohle je podle
 mě CzechAddress plugin pro JOSM napsaný Radomírem Černochem.
 
 http://wiki.openstreetmap.org/wiki/CS:JOSM/Plugins/CzechAddress
  Name a
 URL tagy byly zřejmě přidány ručně.
 
        node
 id=283050015 lat=50.1039117 lon=14.5115490 version=2
 
 changeset=1984279 user=Radomír Černoch uid=51295
 
 timestamp=2009-07-30T12:44:24Z
                tag
 k=addr:housenumber v=?/66 /
                tag
 k=addr:streetnumber v=66 /
                tag
 k=created_by v=Potlatch 0.10b /
        /node
 
  Tenhle
 byl asi 

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

2012-06-22 Tema obsahu Martin Kokeš
Já jsem si udělal pár jednoduchých XSL a přechroustal to pomocí XMLStarletu 
dvěma kroky (první odstraní ty namespacy a druhý je pak transformace do daného 
typu vrstvy) do docela importovatelného GML, které jde poslat do QGISu nebo 
transformovat přes ogr2ogr.

Jde třeba hranice ku, hranice obce (nic moc), hranice parcel, hranice budov, 
budovy jako body, adresni místa jako body... s většinou atributů.

Chce se toho někdo ujmout a vylepšit to na nějaký udělátor pro import? Asi by 
šlo i udělat XSL přímo do OSM formátu, ale Merkaartor zvládne GML levou zadní.

MK

- Original Message -
From: hanoj [mailto:eha...@gmail.com]
To:
OpenStreetMap Czech Republic [mailto:talk-cz@openstreetmap.org]
Sent: Fri,
22 Jun 2012 13:48:11 +0200
Subject: Re: [Talk-cz]  Data RUIAN - výměnný
formát


 Ahoj,

 Po spuštění Veřejného dálkového přístupu k RUIAN budou
 data dostupná přes tuto aplikaci.
Vyborna zprava! Par otazek...

* Proc se
 uziva EPSG:2065, kdyz na data se bezne uziva ESRI:102067?
* Je nejaky
 osvedceny prohlizec, ktery umi data zobrazit krome
Snowflake s
 registraci?


In specie OSM
-
Chapu to tak ze pro OSM
 jsou pro plne automaticky import pouzitelne
vrstvy na uzemi ktera uz ma DKM
 (v dubnu 2012 55% CR):
*AdresniMisto (addr=*)
*Stavebni objekt
 (building=*)
*Ulice (name=*)


Na uzemi bez DKM je jen Adresni
 Misto.


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] Data RUIAN - výměnný formát

2012-06-22 Tema obsahu Martin Kokeš
Ano, jde o RÚIAN, veřejný registr bez licence, dle 111/2009 Sb.. Generovaná 
data jsou už teď ke stažení. Rozhraní VDP ještě není, bude až od 1.7., nevím 
jak to bude se SOAPem, možná podobně, jako funguje u WSDP ke KN. Více info by 
asi dal p. Veselý.

Využitelné jsou samozřejmě uliční čáry, polygony budov, adresní body, takže je 
čas udělat tracerům pápá (to platí pro zastavěné území).

V souvislosti s WFS službou nad tématem INSPIRE parcely je možné získávat 
parcely i mimo zastavěné území, buď jako předgenerované soubory, nebo přímo 
přes WFS dotaz (možná by se ulevilo ZP a jeho tabletu při obkreslování 
zemědělské půdy ;-)...).

Jelikož se všude používá nativně Křovák, je nutná zpřesněná transformace pomocí 
S-JTSK gridu.

MK

- Original Message -
From: Jan Bilak
[mailto:jan.bilak@gmail.com]
To: OpenStreetMap Czech Republic
[mailto:talk-cz@openstreetmap.org]
Sent: Fri, 22 Jun 2012 20:53:02
+0200
Subject: Re: [Talk-cz] Data RUIAN - výměnný formát


 Ahoj,
 
 předem se omlouvám, pokud budu psát nesmysly - moc o tom nevím.
 
 Chápu to správně tak, že data budou licenčně použitelné pro OSM,
 budou
 obsahovat např. adresní body, obrysy budov, ulice apod., vše zdarma ve
 formě veřejné dostupné aplikace na bázi XML/SOAP? A nyní data ještě
 dostupná nejsou, ale budou od příštího měsíce. Data nejsou
 kompletní,
 ale zahrnutí jen ty části ČR, které mají digitalizovaný katastr
 nemovitostí (cca půlka, ale výhledově bude růst). Data budou
 průběžně
 aktualizována a budou dostupná ve dvou formátech:
 a) aktuální stav
 b) změnové soubory
 
 Pokud je to tak je, tak by bylo vhodné celý proces importu maximálně
 zautomatizovat tak, aby se dala provádět pravidelně aktualizace dat
 (třeba 1x denně nebo týdně ... to je už detail). Kromě vlastního
 převedení dat bude třeba řešit kolize s daty, které pochází z
 jiných
 zdrojů (např. ručně kreslené). Rád bych se na takové automatizaci
 podílel, protože v tom vidím značný přínos.
 
 S pozdravem
 Honza

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


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

2012-06-22 Tema obsahu Martin Kokeš
Nějaké příklady...

Striptýz XSL (vyhází namespacy, spoléháme 100% na ČÚZK ;-)... ):
xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xsl:template match=*
xsl:element name={local-name()} 
xsl:apply-templates select=@*|node()/
/xsl:element
/xsl:template
xsl:template match=@*
xsl:attribute name={local-name()}
xsl:value-of select=. /
/xsl:attribute
/xsl:template
/xsl:stylesheet

Primitivní výcuc budov XSL:
?xml version=1.0 encoding=UTF-8 ?
xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xsl:template match=/
ogr:FeatureCollection 
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; 
xsi:schemaLocation=http://ogr.maptools.org/; 
xmlns:ogr=http://ogr.maptools.org/; xmlns:gml=http://www.opengis.net/gml;
xsl:for-each 
select=VymennyFormat/Data/StavebniObjekty/StavebniObjekt
xsl:if test=Geometrie/OriginalniHranice
gml:featureMember
ogr:stavebniobjekty fid={Kod}
ogr:geometryProperty
  xsl:copy-of 
select=Geometrie/OriginalniHranice/
/ogr:geometryProperty
ogr:Kod
xsl:value-of 
select=Kod/
/ogr:Kod
ogr:CislaDomovni
xsl:value-of 
select=CislaDomovni/
/ogr:CislaDomovni
ogr:TypStavebnihoObjektuKod
xsl:value-of 
select=TypStavebnihoObjektuKod/
/ogr:TypStavebnihoObjektuKod
ogr:CastObce
xsl:value-of 
select=CastObce/Kod/
/ogr:CastObce
/ogr:stavebniobjekty
/gml:featureMember
/xsl:if
/xsl:for-each
/ogr:FeatureCollection
/xsl:template
/xsl:stylesheet

Atd...

MK

- Original Message -
From: Martin Kokeš
[mailto:sh...@typo3-hosting.com]
To: OpenStreetMap Czech Republic
[mailto:talk-cz@openstreetmap.org]
Sent: Fri, 22 Jun 2012 18:37:33
+0200
Subject: Re: [Talk-cz]  Data RUIAN - výměnný formát


 Já jsem si udělal pár jednoduchých XSL a přechroustal to pomocí
 XMLStarletu dvěma kroky (první odstraní ty namespacy a druhý je pak
 transformace do daného typu vrstvy) do docela importovatelného GML, které
 jde poslat do QGISu nebo transformovat přes ogr2ogr.

Jde třeba hranice
 ku, hranice obce (nic moc), hranice parcel, hranice budov, budovy jako body,
 adresni místa jako body... s většinou atributů.

Chce se toho někdo
 ujmout a vylepšit to na nějaký udělátor pro import? Asi by šlo i
 udělat XSL přímo do OSM formátu, ale Merkaartor zvládne GML levou
 zadní.

MK

- Original Message -
From: hanoj
 [mailto:eha...@gmail.com]
To:
OpenStreetMap Czech Republic
 [mailto:talk-cz@openstreetmap.org]
Sent: Fri,
22 Jun 2012 13:48:11
 +0200
Subject: Re: [Talk-cz]  Data RUIAN - výměnný
formát


 Ahoj,

 Po
 spuštění Veřejného dálkového přístupu k RUIAN budou
 data
 dostupná přes tuto aplikaci.
Vyborna zprava! Par otazek...

* Proc se

 uziva EPSG:2065, kdyz na data se bezne uziva ESRI:102067?
* Je nejaky

 osvedceny prohlizec, ktery umi data zobrazit krome
Snowflake s

 registraci?


In specie OSM
-
Chapu to tak ze pro OSM

 jsou pro plne automaticky import pouzitelne
vrstvy na uzemi ktera uz ma
 DKM
 (v dubnu 2012 55% CR):
*AdresniMisto (addr=*)
*Stavebni objekt

 (building=*)
*Ulice (name=*)


Na uzemi bez DKM je jen Adresni

 Misto.


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

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


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

2012-06-22 Tema obsahu Martin Kokeš
Ahoj,

viz http://grass.fsv.cvut.cz/gwiki/S-JTSK-Grid, cokoliv co používá GDAL/PROJ4.

MK

- Original Message -
From: Jan Bilak
[mailto:jan.bilak@gmail.com]
To: OpenStreetMap Czech Republic
[mailto:talk-cz@openstreetmap.org]
Sent: Sat, 23 Jun 2012 04:45:21
+0200
Subject: Re: [Talk-cz] Data RUIAN - výměnný formát


 Díky. Nevíte o nějakých knihovnách (.NET, Java, JavaScript, C, C++,
 ...) pro transformaci pomocí toho S-JTSK gridu? Nebo, pokud nejsou
 přímo knihovny, ve kterých opensource programech s vhodnou licencí by
 tato transformace šla najít?
 
 Honza
 
 
 Dne 22. června 2012 22:12 Martin Kokeš sh...@typo3-hosting.com
 napsal(a):
  Jelikož se všude používá nativně Křovák, je nutná zpřesněná
 transformace pomocí S-JTSK gridu.
 
  MK
 
 ___
 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-13 Tema obsahu Martin Kokeš
Otázka je, zda vůbec GPS point o poloze nějaké studánky podléhá autorskému 
zákonu. Vždyť je to jen popis reality, místa pro nějakou autorskou činnost 
příliš nezbývá. Možná by stálo za to, kontaktovat 
http://cs.wikipedia.org/wiki/Ivo_Telec s dotazem na správný výklad.

MK

- Original Message -
From: hanoj [mailto:eha...@gmail.com]
To:
OpenStreetMap Czech Republic [mailto:talk-cz@openstreetmap.org]
Sent: Mon,
13 Feb 2012 10:03:31 +0100
Subject: Re: [Talk-cz] Import Estudanky


 import uzivatele jf01 [1]
* je nekompatibilni s licenci CC BY SA tak ODbL.
*
 je provedena v rozporu se standardy (zvlastni changeset)
* nakonec by stejne
 chtel docistit a upravit tagovani

souhlasim s vymazem uvedenych
 changesetu

[1] http://www.openstreetmap.org/user/jf01/edits

hanoj

Dne 12.
 února 2012 15:36 Jan Breuer jan.bre...@jaybee.cz napsal(a):
 Ahoj


 chtěl bych se zeptat na proběhlý import studánek. Všechny, které
 jsem
 dřív zakreslil jsou nyní duplicitní, vzdáleny od sebe kolem
 50-ti
 metrů. Mám nechat moji zaměřenou pomocí gps (ale většinou
 beze jména),
 nově importovanou (podle mě blbě zaměřenou) nebo
 můžu smazat svoji a
 tu importovanou posunout na její místo?



 myslím, že celý import estudanky.cz neměl vůbec proběhnout. Nelze ani
 nikde
 dohledat explicitní souhlas všech přispěvatelů do estudanky,
 že lze jejich
 dílo použít v OSM. Licence, pod kterou jsou estudanky CC
 BY-NC-ND [1] nelze
 zařadit do žádného odvozeného díla, natož pak do
 díla, které umožňuje
 komerční využití  CC BY-SA [2], jako je
 třeba OSM. Osobně bych tedy
 doporučoval zmíněný import (changeset
 10532251, 10532393, 10532577,
 10532755, 10532807, 10532878, 10532913,
 10532944, 10532979, 10532995,
 10533019, 10533040, 10533061) studánek
 odstranit a nechat pouze ručně zadané
 studánky.
 Na wiki stránkách
 [3] jsou estudanky v sekci nepoužitelných zdrojů z dobrého

 důvodu.

 Honza

___
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-13 Tema obsahu Martin Kokeš
Však já také píšu o jednotlivých GPS pointech a právech jednotlivých 
přispěvatelů, ne o databázi jako celku.

MK

- Original Message -
From: hanoj [mailto:eha...@gmail.com]
To:
OpenStreetMap Czech Republic [mailto:talk-cz@openstreetmap.org]
Sent: Mon,
13 Feb 2012 11:20:15 +0100
Subject: Re: [Talk-cz] Import Estudanky


 2012/2/13 Martin Kokeš sh...@typo3-hosting.com:
 Otázka je, zda vůbec
 GPS point o poloze nějaké studánky podléhá autorskému zákonu. Vždyť
 je to jen popis reality, místa pro nějakou autorskou činnost příliš
 nezbývá. Možná by stálo za to, kontaktovat
 http://cs.wikipedia.org/wiki/Ivo_Telec s dotazem na správný
 výklad.

Elektronická databáze je chráněna stejně jako jiná
 díla

http://cs.wikisource.org/wiki/Wikizdroje:Autorsk%C3%A9_pr%C3%A1vo#Elektronick.C3.A1_datab.C3.A1ze

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] Import Estudanky

2012-02-13 Tema obsahu Martin Kokeš
Kdepak, to není jedno a to samé. Pokud práce při tvorbě mapy (třeba OSM) 
vykazuje znaky autorské činnosti (např. obkreslování ortofota, které samo o 
sobě autorským dílem zpravidla není, vytváření topologií, analýz a odvozených 
dat a jejich zpětná aplikace), pak je výsledek samozřejmě autorské dílo.

Já se myslím oprávněně ptám, zda lze považovat napochodování s GPS ke studánce, 
zaznamenání její polohy jediný bodem a následný záznam do databáze E-Studánky 
pod nějakým obecně zažitým názvem za úkon hodný ochrany autorským právem.

Samotná databáze pak samozřejmě ochrany požívá a je je na majiteli (v tomto 
případě zřejmě provozovatel onoho webu), jak s ní naloží.

MK

- Original Message -
From: Karel Volný
[mailto:ka...@seznam.cz]
To: OpenStreetMap Czech Republic
[mailto:talk-cz@openstreetmap.org]
Sent: Mon, 13 Feb 2012 12:21:12
+0100
Subject: Re: [Talk-cz] Import Estudanky


 Dne Po 13. února 2012 11:11:58, Martin Kokeš napsal(a):
  Otázka je, zda vůbec GPS point o poloze nějaké studánky podléhá
 autorskému
  zákonu. Vždyť je to jen popis reality, místa pro nějakou autorskou
 činnost
  příliš nezbývá.
 
 ehm, tato úvaha má drobnou chybu v tom, že se dá induktivně zobecnit na
 celou 
 mapu - vždyť je to jen popis reality ...
 
 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 Estudanky

2012-02-13 Tema obsahu Martin Kokeš
Zdá se, že je problém pochopit rozdíl na záznamem jediného bodu (jak pomocí 
GPS, tak odvozením z ortofotomapy) a složitější prací s geodaty (co já vím, 
kreslení polyline, čištění polygonů atp.). Autorský zákon si na složitost 
získání (musím s GPS do terénu / musím kliknout do ortofotomapy) nehraje, tam 
jde o to, že nějaká činnost musí vykazovat charakter tvorby unikátního díla.

Když někdo přijde s GPS/klikne na mapu a vytvoří záznam ke studánce, nedává mu 
to hned patent na to, že nemůže přijít někdo jiný a udělat to samé se stejným 
nebo velmi podobným výsledkem.

Ad ctění licence, argumenty klackem nebo slzami neberu.

V tomto konkrétním případě jsou autorská práva k databázi čistě v gesci 
majitele (E-studánky) a ten musí rozhodnout, jak s databází lze či nelze 
naložit. Přispěvatelé do této databáze si v tomto případě těžko mohou nárokovat 
autorská práva k souřadnicím a názvům, neboť jejich činnost související s 
pořízení této dvojice údajů nelze považovat za autorskou. Jiné by bylo, pokud 
by někdo chtěl použít jejich fotografie nebo nějaké eseje, které k dané 
studánce zaznamenali.

MK

- Original Message -
From: Jan Breuer
[mailto:jan.bre...@jaybee.cz]
To: OpenStreetMap Czech Republic
[mailto:talk-cz@openstreetmap.org]
Sent: Mon, 13 Feb 2012 14:45:18
+0100
Subject: Re: [Talk-cz] Import Estudanky

Vypadá to jako jedno a to samé.
V
 prvním případě napochoduji kurzorem nad ortofoto mapu, kliknu a
 vytvořím
bod, který si uložím do počítače a nebo ho dám někomu k
 užívání.
V druhém případě napochoduji na místo ve skutečném
 světě, který
předpokládám je také public domain. Uložím si bod a
 přenesu ho do počítače
a nebo ho dám někomu k užívání.


Rozdíl
 mezi prvním a druhým je jen v tom, že to druhé je
 podstatně
složitější (musím se zvednout ze židle).
Zároveň z [1] je
 zřejmé, že ne všechny body byly pořízeny pomocí GPS a
spadají tedy
 do prvního případu.


Myslím, že by se v tomto projektu měla licence
 ctít a ne polemizovat nad
tím, jestli se dá nějak obejít, protože
 někdo další provedl import, který
provádět neměl.


[1] Otázka: Jak
 zjistit souřadnice GPS když nevlastním
 přístroj?
http://www.estudanky.cz/caste-dotazy

Honza

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


Re: [Talk-cz] Import Estudanky

2012-02-13 Tema obsahu Martin Kokeš
- Original Message -
From: Karel Volný
[mailto:ka...@seznam.cz]
To: OpenStreetMap Czech Republic
[mailto:talk-cz@openstreetmap.org]
Sent: Mon, 13 Feb 2012 15:39:10
+0100
Subject: Re: [Talk-cz] Import Estudanky


 Dne Po 13. února 2012 15:13:38, Martin Kokeš napsal(a):
  Zdá se, že je problém pochopit rozdíl na záznamem jediného bodu (jak
 pomocí
  GPS, tak odvozením z ortofotomapy) a složitější prací s geodaty (co
 já vím,
  kreslení polyline, čištění polygonů atp.).
 
 tak ho nám, hloupým, laskavě vysvětli

Vysvětlení je již uvedeno v závorkách.

  Autorský zákon si na složitost získání (musím s GPS do terénu /
 musím
  kliknout do ortofotomapy) nehraje,
 
 pak tedy nechápu, proč jsi v minulém mailu stavěl právě na tomto
 rozdílu, 
 cituju:
 
 vykazuje znaky autorské činnosti (např. *obkreslování ortofota* ...),
 pak je 
 výsledek samozřejmě autorské dílo.
 
 vs
 
 zda lze považovat *napochodování s GPS ke studánce*, ... za úkon
 hodný 
 ochrany autorským právem.

Obkreslování ortofota míněno vytváření poněkud složitějších prvků, než je 
jediný bod, čištění GPS záznamů (ať už ručně, nebo nějakými algoritmy, jako 
Kalman, Douglas-Pecker atp.), slučování do polyline, vytváření (multi)polygonů, 
relací atp.

  Když někdo přijde s GPS/klikne na mapu a vytvoří záznam ke
 studánce, nedává
  mu to hned patent na to, že nemůže přijít někdo jiný a udělat to
 samé se
  stejným nebo velmi podobným výsledkem.
 
 ovšem my se tu nebavíme o nějakých patentech, že by druhý nemohl
 udělat totéž 
 co první, nýbrž o tom, zda druhý naopak může *neudělat* to samé co
 první a 
 jenom vzít výledek toho, co udělal první, namísto aby používal
 výsledek práce 
 vlastní

To je přece nesmysl, každý nějak používá výsledky duševní práce nějakých lidí 
před ním. Záleží přece na tom, jak moc ta původní práce vykazuje charakter 
autorské činnosti, podle toho si zaslouží nebo nezaslouží ochranu.

Proč myslíš, že např. katastr nemovitostí není chráněn AZ? Protože při jeho 
tvorbě je třeba reflektovat realitu co nejpřesněji a to tak, že na nějakou 
autorskou činnost prostě není místo. Jak to geodet zaměřil a vypracoval, co já 
vím v AutoCADu Map, tak se to zanese do KN a je hotovo. Nikdo nenárokuje žádná 
autorská práva, protože pokud každý v tom daném řetězci udělal, co bylo jeho 
úkolem, lze za 100 let přijít a vytvořit to samé dílo, odlišné jen o nějaký 
kontinentální drift a nějaké ty nepřesnosti dané použitou technikou.

  Ad ctění licence, argumenty klackem nebo slzami neberu.
 
 hm, a ty tu nějaké takové vidíš, nebo co tě vede k takovýmto
 prohlášením?

Však to snad píšu, vztahuje se k souvětí o ctění licence.

  V tomto konkrétním případě jsou autorská práva k databázi čistě
 v gesci
  majitele (E-studánky) a ten musí rozhodnout, jak s databází lze či
 nelze
  naložit. Přispěvatelé do této databáze si v tomto případě těžko
 mohou
  nárokovat autorská práva k souřadnicím a názvům, neboť jejich
 činnost
  související s pořízení této dvojice údajů nelze považovat za
 autorskou.
  Jiné by bylo, pokud by někdo chtěl použít jejich fotografie nebo
 nějaké
  eseje, které k dané studánce zaznamenali.
 
 a měl bys nějaké konkrétní argumenty, proč by tomu tak mělo být?
 
 - nejlépe kdybys to vysvětlil na příkladu, proč nemohu napsat:
 
 V tomto konkrétním případě jsou autorská práva k databázi čistě v
 gesci 
 majitele (OpenStreetMap) a ten musí rozhodnout, jak s databází lze či
 nelze 
 naložit. Přispěvatelé do této databáze si v tomto případě těžko
 mohou 
 nárokovat autorská práva k souřadnicím a názvům, neboť jejich
 činnost 
 související s pořízení této dvojice údajů nelze považovat za
 autorskou. Jiné 
 by bylo, pokud by někdo chtěl použít jejich fotografie nebo nějaké
 eseje, 
 které k dané studánce zaznamenali.

Vysvětleno z mé strany už mnohokrát, protože tvorba OSM nemá zpravidla 
charakter jediného kliknutí. Výjimkou jsou ojedinělé editace POI přes 
Potlatch nebo např. Cloudmade POI collector, tam už lze mluvit o činnosti, 
která má s autorským dílem pramálo společného.

 ... anebo to napsat mohu?
 - tak o čem tu pořád flejmujem a proč někdo pořád řeší nějakého
 Pavla Machka 
 apod.?

Netuším, mě třeba žádný Machek nezajímá.

MK

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


[Talk-cz] Fw: Re: Import Estudanky

2012-02-13 Tema obsahu Martin Kokeš
- Original Message -
From: Karel Volný
[mailto:ka...@seznam.cz]
To: OpenStreetMap Czech Republic
[mailto:talk-cz@openstreetmap.org]
Sent: Mon, 13 Feb 2012 18:36:44
+0100
Subject: Re: [Talk-cz] Import Estudanky


 vskutku? - já tam žádné vysvětlení nevidím ...

S tím nic nenadělám.

 eh, promiň, ale opravdu ti nerozumím - co má zpracování GPS záznamu
 algoritmem 
 na redukci počtu bodů společného s obkreslováním z ortofotomapy?

Autorskou činnost.

 - pokud by KN neměl být nijak chráněn protože je třeba reflektovat
 realitu a 
 protože ČÚZK jen udělal, co bylo jeho úkolem, pak by asi bylo
 namístě 
 například ptát se, pročpak nám pan ředitel takto lhal, když tvrdil,
 že k 
 (nějakému specifickému) užití KN je třeba souhlas

Pana ředitele neznám, do hlavy mu nevidím. Doufejme, že nejpozději na konci 
roku už to s ohledem na INSPIRE a její požadavek na veřejná data parcel a 
službu WFS nebudeme muset řešit.

 ale já přece taky kliknu jen jednou, když v OSM tvořím bod ...
 a pak ještě jednou, a ještě jednou, a ještě jednou ... a ty studánky,
 to také 
 není jedna studánka, ale ještě jedna, a ještě jedna ... takže kde
 máme ten 
 rozdíl?

Pokud každé svoje kliknutí považuješ za autorské dílo, pro mě za mě si třeba 
považuj. V tomto je náš názor na to, co je autorské dílo a co už nikoliv zřejmě 
totálně nekompatibilní. Z tohoto důvodu jsem někde vzadu obecně doporučoval 
konzultaci s některým s autorů AZ nebo jinou právní autoritou (kterou by třeba 
uznalo víc lidí, než nějakého Martina Kokeše).

 mějme nějakou stavbu, pozveme si JEDNOHO zedníka, který položí X
 cihel, a 
 dostane zaplaceno X Kč
 
 a teď mějme další stavbu, ale tam si pozveme X zedníků, kteří
 položí dohromady 
 X cihel, každý z nich JEDNU
 
 a ty tvrdíš, že v druhém případě nemá každý z nich nárok nechat
 si zaplatit 1 
 Kč, protože mezi položením 1*X cihel a položením X*1 cihly má být
 nějaký 
 záhadný rozdíl ještě v něčem jiném, než jen v organizaci práce, a
 že si tudíž 
 v druhém případě můžeš tu stavbu nárokovat zadarmo?

To je typický diskuzní hastroš, který s principy ochrany autorského díla 
nesouvisí. Bez komentáře.

 no tak to potom asi můžem ukončit ...

LOL, nezájem o Machka coby kámen, na který padla kosa diskuze. Ukončit, to bude 
úplně ideální řešení, neboť před sebou tlačím káru plnou jiné práce, která mi 
platí účty. Ve stručnosti tvrdím, že způsob licencování databáze studánek je 
plně v moci jejího provozovatele a tím své přispívání do tohoto vlákna končím.

MK

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


Re: [Talk-cz] import bodů či tras v kmz/kml

2011-12-30 Tema obsahu Martin Kokeš
Apríla teprve bude a asi to objevování nemělo dostatečnou intenzitu. 
http://lmgtfy.com/?q=p%C5%99evod+kml+na+gpx hned několik prvních odkazů 
dovede člověka ke gpsbabelu.


MK

From: petrun...@gmail.com
Sent: Friday, December 30, 2011 5:57 PM
To: Talk-cz@openstreetmap.org
Subject: [Talk-cz] import bodů či tras v kmz/kml

Zdar,
jsem tu zatím nový a chtěl bych se optat jak nejlépe dostat do OSM bodíky 
případně trasy, které jsem si loni vytvořil při přípravě cesty do Polonin. 
Zaznamenával jsem si to do GoogleEarth a odtud to dostanu v kml nebo kmz. 
Zatím jsem ale neobjevil funkční converter zdarma do gpx formátu, který asi 
jediný lze naimportit do OSM


Vilém

e-mail: petrun...@gmail.com
tel: +420 605 445 664
skype: cpt.smetak


___
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] Export dat z geoportálů

2011-12-29 Tema obsahu Martin Kokeš

http://www.cuzk.cz/Dokument.aspx?PRARESKOD=998MENUID=0AKCE=DOC:10-VYSTUPY_DAT_ISKN_DLE_INSPIRE

a článek na 
http://www.geobusiness.cz/2011/09/inspire-na-cuzk-%E2%80%93-cesta-od-testovani-k-realizaci/


MK

-Původní zpráva- 
From: hanoj

Sent: Thursday, December 29, 2011 9:47 AM
To: OpenStreetMap Czech Republic
Subject: Re: [Talk-cz] **SPAM** Re: Export dat z geoportálů

Dne 29. prosince 2011 1:04 Martin Kokeš sh...@typo3-hosting.com napsal(a):

Zatím ne, ale s implementací INSPIRE asi nastanou velké změny.


*** kde se v INSPIRE píše, že bude geoportál poskytovat data ve WFS?


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] **SPAM** Re: Export dat z geoportálů

2011-12-28 Tema obsahu Martin Kokeš
Zatím ne, ale s implementací INSPIRE asi nastanou velké změny.

Martin Kokeš

- Original Message -
From: Jan Kučera
[mailto:kozuc...@gmail.com]
To: Talk-cz@openstreetmap.org
Sent: Wed, 28 Dec
2011 16:23:35 +0100
Subject: [Talk-cz] Export dat z geoportálů


 Ahojte,
 
 nevíte někdo, zda je možné v nějakém rozumném formát (gpx)
 exportovat data
 z geoportálů veřejné správy ČR? Myslím třeba
 http://geoportal.gov.cz.
 
 Díky,
 Kozuch
 

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


Re: [Talk-cz] Značení mýta v České republice

2011-08-05 Tema obsahu Martin Kokeš
 2011/8/5 Swejzi swe...@centrum.cz:
  Ok.
  toll=hgv
  Tak kdo s tím tedy souhlasí? :-)
 
 1) prestan vytvaret nova vlakna na to same tema
 2) souhlas se da vyjadrit i tak, ze to nechas nekolik dni v konf
 ulezet, OSM mam pet let a pet dni urcite pocka
 3) kdyz neco navrhnujes, melo by to mit oporu na wiki, a to at uz
 dohledanou nebo nove vytvorenou
 4) myto plati i autobusy

1-4 Souhlas. Navíc, než dělat u každého kousku trasy nový atribut toll, možná 
by stálo za to zauvažovat nad relací. ;-)

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

MK

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


Re: [Talk-cz] křižovatka dvou a více cest zakreslených jako dvě ways

2011-06-09 Tema obsahu Martin Kokeš
Tím se IMHO poruší síťová topologie ne? Když dělám mapy pro Waze, musím na 
takovém místě prostě nastavit zákazy odbočení.

MK

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


Re: [Talk-cz] dibavod: vodn? toky uvnit? vodn?ch ploch

2011-02-27 Tema obsahu Martin Kokeš
Tady ale přece vůbec nejde o nějaké routování, ale o princip zachování 
primitivní stromové síťové topologie (když už jsou ty data k dispozici). To 
když bude chtít někdo změřit délku Vltavy, tak bude muset počítat nějaké 
těžnice z tvaru Lipna anebo by to měl vzít rovnou vzdušnou čarou od hráze k 
přítoku?


To se pak můžeme vykašlat na nějaké silnice vedoucí skrz každý rynek nebo 
skrz každou náves. Uděláme ze Staromáku krásnou plochu a vymažeme spojení 
Dlouhá-Pařížská, jen aby to bylo v Mapniku krásný. Ať si z toho řidiči 
udělají třeba Carmageddon. To samé platí v bleděmodrém o parkovištích a 
parking lanes.


MK
-Původní zpráva- 
From: Mike

Sent: Saturday, February 26, 2011 10:49 PM
To: OpenStreetMap Czech Republic
Subject: Re: [Talk-cz] dibavod: vodn? toky uvnit? vodn?ch ploch

On někdo někdy routoval po potocích a rybníkách? Tam přece nikdo
nejezdí. Jezdí se maximálně po řece a odtud není kam uhnout. Používá
někdo navigaci v kanoi, když sjíždí Vltavu? Nebo snad loďař na Labi?

Možná bysme do mapy mohli začít zakreslovat i nějaké aeroway, aby
plachťák věděl, kudy má lítat :)

Pánové, řeště nějaký důležitější problémy...


On 02/24/2011 02:33 PM, Stanislav Brabec wrote:

Michal Grézl píše v Čt 24. 02. 2011 v 13:50 +0100:

Routing skrze plochu zadny program, co znam, nedela. Pokud to nejaky
delat zacne, tak pravdepodobne zvoli nejkratsi spojnici, tedy bude
kopirovat presne tu caru ktera uz tam ted je.


To bohužel není pravda:

- Ta čára z dibavod je naprosto nahodilá. Většinou není ani rovná, ani
  nevede reálným korytem na dně vodní plochy.

- I kdyby software routing vodních ploch uměl, data dibavod jsou v tomto
  nespojitá - rybník není napojen na vodní tok. V horším případě dokonce
  přítok v datech končí několik metrů před rybníkem, takže ani
  topologická analýza nepomůže.



___
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] dibavod: vodn? toky uvnit? vodn?ch ploch

2011-02-24 Tema obsahu Martin Kokeš
Ad topologie vodních toků - to je zcela správná úvaha. Stejně tak jako nedávná 
diskuze o budovách a popisných číslech - pokud bude bod s popisným číslem mimo 
budovu, nikdy nepůjde udělat topologie na budovy.

Je třeba zvážit, jestli k OSM přistupovat jako ke GISu nebo si jen tak 
malovat kartogramy.

MK 

- Original Message -
From: Jiri Parkan
[mailto:jpar...@gmail.com]
To: OpenStreetMap Czech Republic
[mailto:talk-cz@openstreetmap.org]
Sent: Thu, 24 Feb 2011 10:44:55
+0100
Subject: Re: [Talk-cz] dibavod: vodn? toky uvnit? vodn?ch ploch


 Ahoj,
 Já bych naopak řekl, že vodní toky, které jsou z hlediska topologie
 vlastně strom, by v datech měly zůstat spojitě. Že je v cestě potoku
 nějaký rybník na tom nic nemění. Stejně jako riverbank nebo přehrady
 u
 řek. Když si budu chtít stáhnout Vltavu, tak tak nějak logicky
 předpokládám, že dostanu spojitou čáru a ne několik úseku s dírami.
 Aby
 to na mapě nevypadalo tak podivně je třeba řešit na úrovni rendereru a
 ane v datech.

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


Re: [Talk-cz] dibavod: vodn? toky uvnit? vodn?ch ploch

2011-02-24 Tema obsahu Martin Kokeš
I obyčejná mapa může mít topologii. Platí to samé i pro ulice/silnice? Nač pak 
u nich děláme relace, když to má být jen obyčejná mapa?

MK

- Original Message -
From: Mike [mailto:m...@mikecrash.com]
To:
OpenStreetMap Czech Republic [mailto:talk-cz@openstreetmap.org]
Sent: Thu,
24 Feb 2011 11:09:49 +0100
Subject: Re: [Talk-cz] dibavod: vodn? toky uvnit?
vodn?ch ploch


 Aly my přece jen malujeme obyčejnou mapu. OSM nikdy nebude sloužit
 jako
relevantní zdroj dat. V systému, kde si každý může nakreslit co
 chce to
prostě nejde. OSM bude vždy využita jen pro mapu a navigaci,
 nikdy ji
nebude používat někdo, kdo potřebuje spolehlivá, zaručená a
 ověřená data.

Navíc když si někdo stáhne jen data vVltavy, tak to
 má stejně bez břehu
a je to jen nic neříkající čára. A pokud v ní
 bude díra, tak aspoň ví,
že tam je něčím přerušená. Jak by to
 jinak poznal? Navíc není problém
kouknout na konečný node a zjistit,
 kam je připojen (přehrada, rybník).

Mike


On 24.2.2011 10:54, Martin
 Kokeš wrote:
 Ad topologie vodních toků - to je zcela správná úvaha.
 Stejně tak jako nedávná diskuze o budovách a popisných číslech -
 pokud bude bod s popisným číslem mimo budovu, nikdy nepůjde udělat
 topologie na budovy.
 
 Je třeba zvážit, jestli k OSM přistupovat jako
 ke GISu nebo si jen tak malovat kartogramy.
 
 MK 
 
 - Original
 Message -
 From: Jiri Parkan
 [mailto:jpar...@gmail.com]
 To:
 OpenStreetMap Czech Republic
 [mailto:talk-cz@openstreetmap.org]
 Sent:
 Thu, 24 Feb 2011 10:44:55
 +0100
 Subject: Re: [Talk-cz] dibavod: vodn?
 toky uvnit? vodn?ch ploch
 
 
 Ahoj,
 Já bych naopak řekl, že
 vodní toky, které jsou z hlediska topologie
 vlastně strom, by v datech
 měly zůstat spojitě. Že je v cestě potoku
 nějaký rybník na tom
 nic nemění. Stejně jako riverbank nebo přehrady
 u
 řek. Když si
 budu chtít stáhnout Vltavu, tak tak nějak logicky
 předpokládám, že
 dostanu spojitou čáru a ne několik úseku s dírami.
 Aby
 to na
 mapě nevypadalo tak podivně je třeba řešit na úrovni rendereru a

 ane v datech.
 
 ___
 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] dibavod: vodn? toky uvnit? vodn?ch ploch

2011-02-24 Tema obsahu Martin Kokeš
Programy pro routování a vůbec síťovou analýzu používají síťové topologie. 
Navrhovaný způsob mazání jde proti vytvoření síťové topologie z vrstvy vodních 
toků. Nač mazat nějaká relevantní data, když už jsou tu k dispozici? Dopadne to 
tak, že se budou za dva roky pracně dokreslovat, nebo dopočítávat, jako se 
dokresluje zeleň, která byla kdysi před importem zjednodušena, protože někoho 
napadne udělat routovatelnou mapu pro vodáky nebo pro vodní cesty jako takové. 
Případně někdo bude chtít změřit délku vodních toků.

MK
- Original Message -
From: Petr Morávek [Xificurk]
[mailto:xific...@gmail.com]
To: OpenStreetMap Czech Republic
[mailto:talk-cz@openstreetmap.org]
Sent: Thu, 24 Feb 2011 13:09:40
+0100
Subject: Re: [Talk-cz] dibavod: vodn? toky uvnit? vodn?ch ploch


 MP napsal(a):
  , že často optimální cesta vede někde uvnitř plochy, mimo
 zakreslené
  linie toku, které mi někdy přijdou dost divné, nejspíš by
 neodpovídaly
  realitě pokud by se rybník opravdu vypustil. V některých případech
 pak
  naopak mohou odpovídat realitě a pak místo 5 km trasy z jednoho konce
  přehrady přímo ke hrázi takový routing navrhne 20 km cestu po
  meandrech kudyma tekla původní řeka.
  
  Takže i když je lepší tam ty toky nechat, tak se na ně při routingu
  spolehnout nelze a v podstatě je někdy je lepší ignorovat. Otázkou
 pak
  je, jestli se tyhle úseky budou nějak tagovat, nebo se to nechá zcela
 na
  software aby si tyhle věci našel a ty úseky si interně smazal,
 případně
  z vodní plochy vygeneroval nějaké optimální trasy sám.
 
 Ad nepřesnost - to nevidím jako příliš velký problém. Člověku,
 který
 používá jen kreslenou mapu je to úplně jedno, a pro ostatní je mnohem
 důležitější údaj, že ten vodní tok někde tady vede, než to
 jestli je
 to skutečně na metr přesně.
 
 Ad routování - moc nerozumím té argumentaci, ale taky nemám v tomto
 směru moc praktických zkušenosti, tak mě kdyžtak někdo zkuste opravit.
 Vycházel jsem z toho, že jistě existují programy, které umí routovat
 jen
 po propojených cestách, proto je velmi důležité, aby vedly vodní toky
 i
 skrze zatopená území, protože v opačném případě algoritmus nenajde
 spojitou cestu z bodu A do B. A pokud už program dokáže poznat, že
 nějaká oblast je celá routovatelná plocha, tak mu je přeci úplně
 jedno,
 jestli skrze ni jsou nebo nejsou nakresleny nějaké další cesty.
 
 
 Zpátky k původnímu problému - evidentně se tu vyrojila spousta
 drobných
 důvodů, proč by bylo vhodné kreslit toky i skrze přehrady, rybníky,
 atd.
 A jistě se jich dá pěkná řádka vymyslet.
 
 Z druhé strany - pominu-li to, že na jedné (z mnoha) map renderovaných z
 OSM dat vypadá zrovna teď škaredě, jaké jsou důvody proti tomuto
 zavedenému postupu, tj. pro komplet výmaz, nebo vynalézání nového
 tagu?
 
 Petr
 
 

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


Re: [Talk-cz] dibavod: vodn? toky uvnit? vodn?ch ploch

2011-02-24 Tema obsahu Martin Kokeš
Mnoho proč? taky zodpoví různé učebnice kartografie a nebo třeba i ten 
primitivní help k Autocad Map:

http://bit.ly/ide41f

- Original Message -
From: Petr Morávek [Xificurk]
[mailto:xific...@gmail.com]
To: OpenStreetMap Czech Republic
[mailto:talk-cz@openstreetmap.org]
Sent: Thu, 24 Feb 2011 13:09:40
+0100
Subject: Re: [Talk-cz] dibavod: vodn? toky uvnit? vodn?ch ploch


 MP napsal(a):
  , že často optimální cesta vede někde uvnitř plochy, mimo
 zakreslené
  linie toku, které mi někdy přijdou dost divné, nejspíš by
 neodpovídaly
  realitě pokud by se rybník opravdu vypustil. V některých případech
 pak
  naopak mohou odpovídat realitě a pak místo 5 km trasy z jednoho konce
  přehrady přímo ke hrázi takový routing navrhne 20 km cestu po
  meandrech kudyma tekla původní řeka.
  
  Takže i když je lepší tam ty toky nechat, tak se na ně při routingu
  spolehnout nelze a v podstatě je někdy je lepší ignorovat. Otázkou
 pak
  je, jestli se tyhle úseky budou nějak tagovat, nebo se to nechá zcela
 na
  software aby si tyhle věci našel a ty úseky si interně smazal,
 případně
  z vodní plochy vygeneroval nějaké optimální trasy sám.
 
 Ad nepřesnost - to nevidím jako příliš velký problém. Člověku,
 který
 používá jen kreslenou mapu je to úplně jedno, a pro ostatní je mnohem
 důležitější údaj, že ten vodní tok někde tady vede, než to
 jestli je
 to skutečně na metr přesně.
 
 Ad routování - moc nerozumím té argumentaci, ale taky nemám v tomto
 směru moc praktických zkušenosti, tak mě kdyžtak někdo zkuste opravit.
 Vycházel jsem z toho, že jistě existují programy, které umí routovat
 jen
 po propojených cestách, proto je velmi důležité, aby vedly vodní toky
 i
 skrze zatopená území, protože v opačném případě algoritmus nenajde
 spojitou cestu z bodu A do B. A pokud už program dokáže poznat, že
 nějaká oblast je celá routovatelná plocha, tak mu je přeci úplně
 jedno,
 jestli skrze ni jsou nebo nejsou nakresleny nějaké další cesty.
 
 
 Zpátky k původnímu problému - evidentně se tu vyrojila spousta
 drobných
 důvodů, proč by bylo vhodné kreslit toky i skrze přehrady, rybníky,
 atd.
 A jistě se jich dá pěkná řádka vymyslet.
 
 Z druhé strany - pominu-li to, že na jedné (z mnoha) map renderovaných z
 OSM dat vypadá zrovna teď škaredě, jaké jsou důvody proti tomuto
 zavedenému postupu, tj. pro komplet výmaz, nebo vynalézání nového
 tagu?
 
 Petr
 
 

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


Re: [Talk-cz] Tagovani pro routing

2011-02-08 Tema obsahu Martin Kokeš

Dne 8.2.2011 15:20, Pavel Machek napsal(a):

Ahoj!


Teď se zkusím podívat po něčem pro Androida na offline routing.

Vysledky prosim do konference :-).

Ja vim ze existuje navit (GPL), ale je to port z PC; kdyz jsem ho
testoval ja, byl lehce nenazrany...

Já mám Navdroyd, ten je celkem v pohodě.

MK


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


Re: [Talk-cz] licence na CHKO mapy

2011-01-25 Tema obsahu Martin Kokeš

Dne 25.1.2011 15:31, Frettie napsal(a):

Přesně tak, v zákoně jsou snad názvy, zbytek těžko říct, zda je PD.
Mapy ale na 99% ne.

http://www.isvs.cz/legislativa/patri-uredni-databaze-vsem.html

Zákon nespojuje úřední dílo s otázkou autorství (tedy kdo ho vytvořil), 
ale s otázkou, zda existuje či neexistuje veřejný zájem na vyloučení z 
ochrany autorského zákona. Subjekt, který databázi vytvořil, by měl vždy 
od povinného orgánu dostat při zadání zakázky či při uzavírání 
autorského ujednání informace o tom, k čemu bude dílo využíváno a z 
jakých zdrojů vychází potřeba vytvoření této databáze.


Přístup k takovým informacím neobsluhuje žádný jiný zákon (jako např. u 
katastru nemovitostí) a veřejný zájem je v tomto případě myslím 
nezpochybnitelný.


MK


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


Re: [Talk-cz] zemský pokryv - využití CORINE dat

2010-11-05 Tema obsahu Martin Kokeš

Dne 5.11.2010 12:57, MP napsal(a):
On Fri, 05 Nov 2010 11:13:45 +0100 (CET), Zdeněk Pražák 
zpra...@seznam.cz wrote:

Díval jsem se, že například v Rumunsku probíhá import dat o zemském
pokryvu (lesy, pole atd) s využitím dat European Enviroment agency
(EEA) - project CORINE.
Nebylo by možné obdobná data z projektu CORINE  využít i pro import
zemědělské půdy v ČR.


Pokud už někde importují, tak s licencí asi problém nebude. Otázkou je 
ale kvalita dat.
Jak moc přesná ty data jsou a jak jsou stará? Zemědělská půda je 
trochu vidět z ortofota (uhul, yahoo), s poměrně slušnou přesností je 
vidět i v katastrální mapě z CUZK. Jak kvalitní ve srovnáním z tímhle 
jsou data z CORINE?


MArtin

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
MinZe u nás provozuje tento podrobný evidenční systém využití zemědělské 
půdy (kvůli dotacím EU): http://www.sitewell.cz/czlpis/. Data v něm jsou 
velmi přesná a jsou i fyzicky kontrolována úředníky.


MK


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


Re: [Talk-cz] Pražský okruh

2010-09-27 Tema obsahu Martin Kokeš
http://www.openstreetmap.org/browse/way/41057918/history :-) No tam je teda 
živo.

- Original Message -
From: Jakub Sykora
[mailto:kub...@kbx.cz]
To: OpenStreetMap Czech Republic
[mailto:talk...@openstreetmap.org]
Sent: Mon, 27 Sep 2010 07:19:47
+0200
Subject: Re: [Talk-cz] Pražský okruh


 No a proto jsem prave nepochopil uplne toho clovicka, co po me cely 
okruh
 pretagoval, kdyz se mel otevirat v pondeli a ja ho pretagoval v 
patek bez
 pripojnych cest... No a v pondeli si to dal nekdo cele znovu :)

K

Dne
 26.9.2010 22:40, Pavel Machek napsal(a):
 Ahoj!


 pokud jde o
 důležitou silnici, tak je výhoda robota v tom, že to
 otevře přesně
 v daný datum (nebo dokonce čas) a to klidně o víkendu
 nebo v
 pracovní době, kdy na to nikdo nemá čas (nebo naopak zamezí
 tomu,
 aby se jednotliví uživatelé přetahovali).
  
 No, a k cemu je
 dobry ze to bude presne v dany cas? Lidi to stejne
 pouzivaj offline,
 renderery maj spozdeni, etc.

 Mit tam nejaky tagy aby i offline navigace
 vedela aha, do 1. zari
 nic, od 1. zari je tu silnice by bylo docela
 pekny, ale myslim ze
 dost komplikovany...
   Pavel
   
 


___
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] tema bakalarky

2010-09-23 Tema obsahu Martin Kokeš

 Dne 22.9.2010 12:13, Stanislav Brabec napsal(a):

Martin Kokeš píše v Út 21. 09. 2010 v 22:50 +0200:

A já bych se připojil s dalším návrhem, který by šel eventuelně i v tom
pythonu udělat - implementace Kalmanova filtru pro vyhlazování surových
NMEA tracklogů. :-) Případně aproximace několika podobných tracklogů do
jednoho.

To jde ještě vylepšit pokusem identifikovat chybu.

Nízké HDOP, VDOP a počet satelitů můžete pochopitelně eliminovat v 
GPSBabelu např., ale free software, který by aproximoval více tras do 
jedné případně vyhlazoval pěší tracklogy Kalman filtrem, ten ještě není 
(mimo placené verze Efficasoft GPS Utlilities). Stává se, že prostě 
jdete moc pomalu a satelity létají moc rychle, proto vznikají tak 
kostrbaté logy, ačkoliv máte dobrý příjem.


MK


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


Re: [Talk-cz] tagování sídel

2010-06-06 Tema obsahu Martin Kokeš
Dne 5.6.2010 21:41, Petr Morávek [Xificurk] napsal(a):
 Petr Morávek [Xificurk] napsal(a):

 Pokud to někoho zajímá, tak doporučuju metodiku ze stránek ČSÚ:
 http://www.czso.cz/csu/rso.nsf/i/metodicka_dokumentace_registru_doc/$File/metodika%202009_v1.zip
  
 Mimochodem v tomto dokumentu jsou i dvě zajímavé kapitolky ohledně
 užívání dat.


 1.4. Ochrana individuálních dat
 Registr sčítacích obvodů a budov neobsahuje skutečnosti, na něž se vztahuje 
 ochrana individuálních dat dle zákona č. 89/1995 Sb., o státní statistické 
 službě.

 1.5. Externí využívání
 Registr sčítacích obvodů a budov ze zákona č. 89/1995 Sb., o státní 
 statistické službě, v platném znění, je dle novelizace zákona zveřejněné ve 
 Sbírce zákonů 2004, částka 25 ze dne 25. února 2004 veřejným seznamem. Dle 
 novelizace zákona č. 230/2006 Sb., jsou údaje o počtu bytů v jednotlivých 
 budovách veřejné a údaje o jednotlivých bytech jsou neveřejné.
 O vývoji registru je informováno prostřednictvím veřejné internetové služby 
 na stránce http://www.czso.cz/csu/rso.nsf/i/registr_scitacich_obvodu
  
 Já si to vykládám tak, že je možné ty data bez problémů importovat do
 OSM. Příp. se můžeme s odkazem na tento text ujistit přímým dotazem na
 ČSÚ, z kontaktů mi přijde jako nejvhodnější:


 Distribuce výstupů z registru
 Lenka Šilhanová, vedoucí oddělení pro poskytování elektronických výstupů
 tel: 274 053 115
 e-mail: lenka.silhan...@czso.cz
  
 Co vy na to? Mám tam napsat, nebo se najde vhodnější člověk (třeba
 někdo, kdo něco _ví_ o předešlé komunikaci :))?

 Zdraví,
 Petr

Zmíněný registr je samozřejmě z hlediska AZ veřejně přístupným 
rejstříkem (§3), možno použít bez neveřejných údajů zcela bez problémů, 
na to není potřeba ani svolení, ani složitý právní výklad.

MK


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


Re: [Talk-cz] Nové WMS KN

2010-05-27 Tema obsahu Martin Kokeš
http://cs.wikipedia.org/wiki/Web_Map_Service :-)

http://wms.cuzk.cz/wms-new.asp?REQUEST=GetCapabilities

- Original Message -
From: Pavel Pilát
[mailto:pavel.pi...@gmail.com]
To: OpenStreetMap Czech Republic
[mailto:talk...@openstreetmap.org]
Sent: Thu, 27 May 2010 13:35:52
+0200
Subject: Re: [Talk-cz] Nové WMS KN


 Zatím se na dané adrese ve Firefoxu zobrazuje pouze:

Tento XML soubor
 nemá připojeny žádné informace o vzhledu prvků. Strom
XML dokumentu je
 zobrazen níže.

−
ServiceExceptionReport
 version=1.1.1
ServiceExceptionMissing REQUEST parameter or its
 value./ServiceException
/ServiceExceptionReport


a v IE8:

The XML page
 cannot be displayed
Cannot view XML input using style sheet. Please correct
 the error and
then click the Refresh button, or try again
 later.

System
 error: -2146697211. Error processing
 resource
'http://10.252.102.206/wmsdtd/1.1.1/WMS_exception_1_1_1.dtd'.



Ale
 vyzkouším po čase zas

Pavel



2010/5/27 JV j@seznam.cz:

 Dobrý den,
 - na zobrazování s jinými EPSG kódy se pracuje
 - bitovou
 hloubku u PNG zkoumáme
 - vypnul jsem antialiasing
 - vykreslování
 textů pomocí obrysů jsem opravoval v úterý odpoledne, teď by to
 nemělo nastávat

 J.Veselý

  Původní zpráva
 
 Od: hanoj eha...@gmail.com
 Předmět: Re: [Talk-cz]
 Nové WMS KN
 Datum: 26.5.2010 11:48:16

 
  v současné době začínáme
 provozní testování nového způsobu poskytování WMS
 služeb nad
 katastrálními mapami. Pokud budete mít zájem se na to podívat,
 adresa
 je http://wms.cuzk.cz/wms-new.asp.
 
  Pokud budete mít
 nějaké připomínky nebo náměty, pište, prosím, na adresu

 cuzk.wms(na)cuzk.cz. Do 9.6. budu asi mimo mail, takže případné
 odpovědi pošlu
 později. Případně to můžeme probrat od zítřka v
 Brně na GIVS :-)

 *** vsiml jsem si dvou ne zrovna prijemnych
 veci:

 1) zmena barevneho prostoru PNG obrazku z 4bitu na 32bitu

  a) vyrazne zacvici s vytizenim procesoru pri renderovani v JOSM az na

 hranici unosnosti
  b) naroste velikost i prazdneho stahovaneho obrazku
 po kompresi z 0,5
 kB na 5kB, . [1][2]

 IMHO je antialiasing luxus na
 zcela neucelnem miste. Vice vrstev a
 rychlejsi aktualizace je urcite
 prinos, ale zlate 4bitove barvy -
 vzdyt je to technicka mapa.


 2)
 v EPSG 4326 jsou texty oproti starsi verzi vyrazne vertikalne
 protazene.


 zdravi Hanoj


 [1]

 http://wms.cuzk.cz/wms-new.asp?service=WMSVERSION=1.1.1REQUEST=GetMapSRS=EPSG:4326LAYERS=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=TRUEBBOX=16.,49.5000,16.0061,49.5040WIDTH=300HEIGHT=300


 [2]

 http://wms.cuzk.cz/wms.asp?service=WMSVERSION=1.1.1REQUEST=GetMapSRS=EPSG:4326LAYERS=kn-i,prehledky,def_budovyFORMAT=image/pngtransparent=TRUEBBOX=16.,49.5000,16.0061,49.5040WIDTH=300HEIGHT=300


 ___
 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] podivna silnice

2010-05-27 Tema obsahu Martin Kokeš
Řekl bych že to bude mít něco do činění s plachtěním. LKZS je letiště Kralupy. 
Někdo si dělá z OSM leteckou mapu.

MK

  _  
From: Petr Holub [mailto:ho...@ics.muni.cz]
To: talk-cz@openstreetmap.org
Sent: Thu, 27 May 2010 23:33:37 +0200
Subject: [Talk-cz] podivna silnice

Dobreho dne vespolek,

netusite nekdo, co ma byt tohle?
http://www.openstreetmap.org/browse/way/60274125

Diky,
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] podivna silnice

2010-05-27 Tema obsahu Martin Kokeš
BTW pán se docela činí http://www.openstreetmap.org/user/jzve/edits :-D samá 
hájvej...

MK

  _  
From: Petr Holub [mailto:ho...@ics.muni.cz]
To: talk-cz@openstreetmap.org
Sent: Thu, 27 May 2010 23:33:37 +0200
Subject: [Talk-cz] podivna silnice

Dobreho dne vespolek,

netusite nekdo, co ma byt tohle?
http://www.openstreetmap.org/browse/way/60274125

Diky,
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] mapnik v obci

2010-04-30 Tema obsahu Martin Kokeš
Dne 30.4.2010 9:33, hanoj napsal(a):
 2010/4/30 Mikem...@mikecrash.com:

 Protože garden/zahrada v OSM je veřejná zahrada za účelem pěstování
 rostlin k okrasným, vědeckým apod. účelům. Zahrada u domu je většinou
 jen plocha, která je kolem baráku, protože tam být musí, je tam jen
 tráva, jeden strom a deset kytek jen proto, aby tam nerostlo křoví.

 Není to blbé, když v reálu je kolem obce plno zeleně - křoví, okrasných
 stromů, květin, ovocných stromů, trávníků, ale ta se neznačí, protože to
 ani moc nejde, ale obec, kde jsou jen zahrady, ve kterých není skoro
 nic, je samá garden a obec je celá zalená jak oáza na poušti? Je to
 příšerný. Když tam pak člověk dojede a kouká na mapu, tak to vypadá, že
 je někde úplně jinde.

 Navíc garden je veřejná - kdokoliv tam může volně/za vstupné jít. To je
 smysl tagu. K čemu je vůbec taková informace, že je kolem baráku
 zahrada? Pokud je tam plot, tak tam má být plot.  A pokud je tam plot,
 je jasné, že se tam nesmí a že je kolem domu zahrada. Nedělejme z OSM
 omalovánky pro děti s naprosto zbytečnými informacemi.
  
 *** Tak jak tady Majk rozvedl jsem to myslel. Vypada to jako oaza ne
 jako mesto(urbanizovane uzemi).

 hanoj

Naprosto souhlasím, je třeba uvědomit si, kde má projekt OSM kořeny - ve 
Velké Británii. Tam je drtivá většina půdy v soukromých rukou, 
rozparcelována na malinkaté kusy pozemků, obzvlášť pak v městech. Proto 
tam existují zahrady (garden), které mají stejnou funkci jako městské 
parky (můžete tam dojít, sednout si na lavičku, na perfektně sestřižený 
trávník, udělat piknik, spát, číst, odpočívat), nicméně vstup do nich 
může být i za úplatu. U nás mají takovou funkci třeba méně časté 
botanické zahrady, nebo zahrady školní, zahrady při nějakém zahradnictví 
atp.

MK


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


Re: [Talk-cz] mapnik v obci

2010-04-30 Tema obsahu Martin Kokeš

Dne 30.4.2010 15:37, Michal Grézl napsal(a):

2010/4/30 Mikem...@mikecrash.com:
   

Protože garden/zahrada v OSM je veřejná zahrada za účelem pěstování
rostlin k okrasným, vědeckým apod. účelům.
 

To je nesmysl, v anglii je garden to same co u nas. cerpam z wikipedie.
Prectete si vsichni ten clanek, zahrada je tam to same co u nas.
   
Já myslím, že v http://wiki.openstreetmap.org/wiki/Tag:leisure%3Dgarden 
je to dostatečné:


Place where flowers and other plants are grown in a decorative and 
structured manner or for scientific purposes.  An area where plants and 
trees are displayed, private or public gardens (free / at cost / or for 
a donation).


Přesně to odpovídá anglické zahradě. Jsa z Pardubic, mohu prohlásit, že 
o takové zahradě tam nevím. Jsou tam parky, několik zahradnictví a 
zahrádkářské kolonie. Jelikož ale teď bydlím v Praze, vím, že tady je v 
Průhonicích opravdu dendrologická zahrada, která není parkem a která 
odpovídá leisure=garden.


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


Re: [Talk-cz] mapnik v obci

2010-04-30 Tema obsahu Martin Kokeš
 ja tam vidim zahrady, s bazenama:)
 posekanej travnik je jedna z vrcholnejch forem zahradniceni,
 lidi kultivaci travniku stravi veskerej volnej cas.
 
 Jediny co bych uznal jako nezahradu je neupravena prirodni louka, tedy
 kdyz by se o to nekolik let nikdo nestaral (koprivy, lucni kviti a
 tak), vsechno ostatni je zahrada, kde je rozdil mezi parkem a zahradou
 sem moc nezjistil (pravdepodobne je park podmnozina zahrady), z
 vyznamu slova by zahrada mela byt ohranicena.
 
 The etymology of the word refers to enclosure: it is from Middle
 English gardin, from Anglo-French gardin, jardin, of Germanic origin;
 akin to Old High German gart, an enclosure.
 
 Tudiz vse uzavrene, ne nutne fyzicky plotem, kde neco roste a co je
 upravovane clovekem je proste zahrada a hotovo.
 
 Moje konecny slovo: Nejenom ze neni nic spatneho na tom tagovat
 zahrady jako leisure=garden, naopak je to ta nejlepsi mozna varianta.

Hmm, no ono není špatné se mkrnout, jak to třeba mapují jinde, kde jsou už 
mnohem dál...

Já teda nevidím ultrazelený Aschaffenburg nebo Oxford. :-)

http://osm.org/go/eutDzOJP-
http://osm.org/go/0D2BDIQ4-

MK

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


Re: [Talk-cz] křižovatka v Otrokovicích - je to správně?

2010-04-01 Tema obsahu Martin Kokeš
OK, tak to přemalujem a budeme doufat v toto nebo podobné features/relations 
http://wiki.openstreetmap.org/wiki/User:%C3%96mmes/Wayparts, nemám s tím 
problém.

MK

- Original Message -
From: hanoj [mailto:eha...@gmail.com]
To:
OpenStreetMap Czech Republic [mailto:talk...@openstreetmap.org]
Sent: Thu,
01 Apr 2010 04:07:24 +0200
Subject: Re: [Talk-cz]  křižovatka v
Otrokovicích - je to správně?


 Dne 1. dubna 2010 0:37 Martin Kokeš sh...@typo3-hosting.com napsal(a):
  No v tom případě, pokud byste to chtěl brát doslova z wiki, tak
 průtah Hranicemi a spousta dalších podobných jedniček v městech by se
 musel taky překreslit (protože pruhy s navzájem opačným provozem v nich
 nejsou ničím fyzickým odděleny, maximálně dvojitou plnou).
 http://osm.org/go/0ls...@5l-
 
 *** Tu I/47 jsem historicky kreslil myslim taky ja. Silnice I/47 ve
 vetsine useku delena JE, v hranicich nejspis neni ale chova se takto.
 Vznikala v dobe kdy vznikaly pravidla i prvni OSM useri.
 Takze je to spise anachronizmus, nez dobry priklad.
 
 Dneska jsem prekresloval I/37 a ulici Vocelovu v Hradci Kralovem ze
 dvou linii do jedne .
 
 
  A pokaždé, kdy by došlo k fyzickému oddělení pruhů, by se to
 muselo opět překreslovat.
 
 *** tak vyhrocene to snad neni.
 
 
 zdravi
 
 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] křižovatka v Otrokovicích - je to správně?

2010-03-31 Tema obsahu Martin Kokeš
No v tom případě, pokud byste to chtěl brát doslova z wiki, tak průtah 
Hranicemi a spousta dalších podobných jedniček v městech by se musel taky 
překreslit (protože pruhy s navzájem opačným provozem v nich nejsou ničím 
fyzickým odděleny, maximálně dvojitou plnou). http://osm.org/go/0ls...@5l-

A pokaždé, kdy by došlo k fyzickému oddělení pruhů, by se to muselo opět 
překreslovat.

Myslím si že je to zbytečné, dokud nebudou existovat v OSM nástroje, kterými 
bude možné podobnou topologii vytvářet jednoduchou linií (s příslušnými 
atributy) a nad ní bez problémů routovat. Možná by ani neškodilo podívat se, 
jak to řeší konkurence. http://tinyurl.com/yjoapea

U turn přes dvojitou plnou, to si asi děláte legraci, že? ;-) Možná je dobře, 
že já tam jezdím vždycky se 14denní přestávkou...

MK

- Original Message -
From: Pavel Pilát
[mailto:pavel.pi...@gmail.com]
To: OpenStreetMap Czech Republic
[mailto:talk...@openstreetmap.org]
Sent: Wed, 31 Mar 2010 22:50:48
+0200
Subject: Re: [Talk-cz]  křižovatka v Otrokovicích - je to
správně?


Chci zjistit, jak se na toto komunita
 dívá. Například od toho Zlína
jsou na tom půlkilometru před
 křižovatkou tři pruhy - dva směrem ke
křižovatce, jeden od ní.
 Zakreslil jste to jako Divided Highway - a
toto Editing Conventions řeší
 tady
http://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions#Divided_highways

Specielně
 vypichuju:

A divided highway (also separated highway) is any highway
 where
traffic flows are _physically_ separated by a barrier (e.g.,
 grass,
concrete, steel), which prevents movements between said flows
 ...
Divided highways should be drawn as separate ways. The ways
 will
typically be oneway ...

No, to nám příliš nesedí na reálnou
 situaci, že :). Jezdím tudy každý
den, ale ty fyzické bariéry zatím
 chybí. ;) U-turn tam udělat můžu,
když mě nic nesestřelí.

Takže
 fakticky by tam měla být jedna highway s lanes=3, je to tak?
Křižovatka
 by asi taky měla vypadat jako jednoduché protnutí dvou
highways. Dva
 oblouky (Napajedla - Zlín a Zlín - Otrokovice) bych řekl
akceptovatelné
 jsou, jsou fyzicky oddělené ostrůvkem.


Takže jak? Měli bychom
 dodržovat při mapování pravidla? Odkud pokud?
Ring volný...
 ;)

Pontiac_CZ


2010/3/31 Mike m...@mikecrash.com:
 Všiml jsem si
 ještě toho Lidlu - je tam nakresleno parkoviště a k němu
 vedou 2
 service roads, které ale nejsou propojené, končí u parkoviště.
 Ty
 bych propojil tak, aby to bylo průjezdné, protože jinak z toho
 navigace
 bude zmatená. Parkoviště jako takové totiž není silnice, ale
 jen
 jakýsi plácek, kde není definované, kudy se jezdí.

 Mike

 Pavel
 Pilát wrote:
 Zdravím,

 zajímal by mě Váš názor na
 křižovatku

 http://www.openstreetmap.org/?lat=49.19882lon=17.53777zoom=17layers=B000FTF


 Pro srovnání, tady je fotomapa:

 http://maps.google.com/maps?f=qsource=s_qhl=engeocode=q=otrokovicesll=37.0625,-95.677068sspn=47.838189,79.013672ie=UTF8hq=hnear=Otrokovice,+Czech+Republicll=49.199261,17.537436spn=0.002426,0.006866t=kz=18


 Křižovatka obsahuje tři ostrůvky. Jde mi hlavně o to rozdělení na

 oneways, které zasahuje i dost daleko přestože směry nejsou fyzicky

 oddělené (lze tam odbočit doleva).

 Je to správně zakreslená
 křižovatka?

 S pozdravem
 Pontiac_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

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


Re: [Talk-cz] křižovatka v Otrokovicích - je to správně?

2010-03-30 Tema obsahu Martin Kokeš
Kvítkovickou křižovatku jsem zakreslil tak, aby byla bez problémů routovatelná 
v navigacích a ty vás nehonily ostře doprava, kde ani fyzicky odbočit nemůžete.

Odbočovací pruh směr Staré Město-Zlín začíná jak sám vidíte z ortofota ještě 
před vyústěním účelové komunikace. Odbočovací pruh směr Malenovice-Otrokovice 
začíná rovněž na začátku zastávky MHD. Směr od Barumu a z Centra výrazné 
odbočovací pruhy oddělené ostrůvky nemají. Myslím, že by všechny routy by tam 
měly mít parametry lanes.

To samé platí i o zdvojení dalšího 2+1 pruhu z Malenovic.

V čem vidíte konkrétně problém? Že to Mapnik maluje moc tlusté?

MK

- Original Message -
From: Pavel Pilát
[mailto:pavel.pi...@gmail.com]
To: OpenStreetMap Czech Republic
[mailto:talk...@openstreetmap.org]
Sent: Tue, 30 Mar 2010 22:12:19
+0200
Subject: [Talk-cz] křižovatka v Otrokovicích - je to správně?


 Zdravím,

zajímal by mě Váš názor na
 křižovatku
http://www.openstreetmap.org/?lat=49.19882lon=17.53777zoom=17layers=B000FTF

Pro
 srovnání, tady je
 fotomapa:
http://maps.google.com/maps?f=qsource=s_qhl=engeocode=q=otrokovicesll=37.0625,-95.677068sspn=47.838189,79.013672ie=UTF8hq=hnear=Otrokovice,+Czech+Republicll=49.199261,17.537436spn=0.002426,0.006866t=kz=18

Křižovatka
 obsahuje tři ostrůvky. Jde mi hlavně o to rozdělení na
oneways, které
 zasahuje i dost daleko přestože směry nejsou fyzicky
oddělené (lze tam
 odbočit doleva).

Je to správně zakreslená křižovatka?

S
 pozdravem
Pontiac_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] lesní cesty: highway=service nebo highway=track?

2010-03-02 Tema obsahu Martin Kokeš
highway=service je IMHO účelová komunikace 
http://cs.wikipedia.org/wiki/%C3%9A%C4%8Delov%C3%A1_komunikace

Lesní cesty taguji jako track a tracktype.

MK
- Original Message -
From: CZ_Tibo [mailto:cz-t...@seznam.cz]
To:
talk-cz@openstreetmap.org
Sent: Tue, 02 Mar 2010 19:28:03 +0100
Subject:
[Talk-cz] lesní cesty: highway=service nebo highway=track?


 Zdravím,
 
 dostal jsem se s jedním kolegou do sporu ohledně tagování lesních a
 polních asfaltek. Pro me jsou to highway=track+tracktype=grade1, zatímco
 on prosazuje highway=service:
  takova asfaltka, ac v lese, vice odpovida popisu service road
 (http://wiki.openstreetmap.org/wiki/Tag:highway%3Dservice) nez
 tracktype=grade1 (http://wiki.openstreetmap.org/wiki/Key:tracktype).
 
 moje protiargumenty:
  http://wiki.openstreetmap.org/wiki/Tag:highway%3Dservice
  z toho chapu, ze highway=service je odbocka k necemu - benzinka,
 druzstvo, tovarna, parkoviste atd.
  http://wiki.openstreetmap.org/wiki/Tag:highway%3Dtrack
  a tady se doslova mluvi o tom, ze highway=track jsou polni a lesni cesty,
 tedy nevedou k necemu, ale proste do lesa. tracktype pak jenom
 rozlisuje, jestli je zpevnena, castecne zpevnena nebo nezpevnena.
 
 jeho odpověď:
  me prijde, ze je to minimalne sporne.
  Myslim, ze lesni asfaltky jsou u nas vetsinou budovany pro pristup
 techniky pro tezbu dreva. Prave proto mi oznaceni service (sluzebni cesta)
 sedi vic nez track (polni cesta). A dalsim duvodem, proc preferuju service
 pred tracktype=1 je, ze takto by byl mezi tracktype=1 a tracktype=2 veliky
 rozdil, protoze mezi kvalitni polni cestou a asfsaltkou je znacny rozdil.
 
 Jeste jeden můj pohled:
 highway=service vznikly jako nove cesty na miste, kde driv zadna cesta
 nebyla. Naopak lesni/polni asfaltky vznikly vyasfaltovanim puvodne
 nezpevnenych cest, u kterych o highway=track neni pochyb.
 
 Když jsem začal mapovat, taky jsem lesní a polní asfaltky značil jako
 highway=service, než mi jednu walley opravil. Od té doby důsledně
 používám highway=track a kvalitu rozlišuju tagem tracktype:
 Pokud grade1 pouziju pro asfalt, grade2 pro sotolinu nebo panelovku, grade3
 pro hlinu prosypanou sterkem, grade 4 pro hlinu, kde toho sterku moc neni a
 grade 5 pro sotva zretelne koleje v poli, tak mam stupnici lesnich a polnich
 cest vyresenou docela plynule - tedy IMHO.
 
 Takže, jak to teda má správně být? Ať v tom máme systém...
 + šlo by to nějak zdůraznit ve wiki?
 
 Tibo
 
 ___
 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] Hranice obcí

2010-01-18 Tema obsahu Martin Kokeš
Dne 18.1.2010 12:28, Radek Bartoň napsal(a):
 Dne neděle 17 Leden 2010 18:43:44 hanoj napsal(a):

 *** bud musis specifikovat jakou hranici z vyse popsanych mas na
 mysli, nebo poslat href. To v tve otazce neni...
  
 Jedná se mi o takové šedé podbarvení Olomouce, které je vidět jestě na tomhle
 zoomu
 http://www.openstreetmap.org/?lat=49.622lon=17.186zoom=10layers=B000FTF ale
 dále už ne. Zvláštní je, že žádná taková linie nebo relace v datech (v
 Potlachu nebo Merkaartoru) není.

To je hranice zastavěného územi, ne katastrálního území, osobně to dělám 
tak, že objedu parcely kolem posledních domů do polí.

MK


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


Re: [Talk-cz] Hranice obcí

2010-01-18 Tema obsahu Martin Kokeš
Dne 18.1.2010 12:28, Radek Bartoň napsal(a):
 Dne neděle 17 Leden 2010 18:43:44 hanoj napsal(a):

 *** bud musis specifikovat jakou hranici z vyse popsanych mas na
 mysli, nebo poslat href. To v tve otazce neni...

 Jedná se mi o takové šedé podbarvení Olomouce, které je vidět jestě na tomhle
 zoomu

Osobně si myslím, že jak se to objevuje a mizí podle zoomu, že to bude 
nějaká chyba v rendereru nebo někde v datech protože u jiných měst to 
zůstává.

MK


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


Re: [Talk-cz] OpenStreetMap komerční služba

2010-01-07 Tema obsahu Martin Kokeš

Dne 7.1.2010 13:58, MP napsal(a):

Nápad to špatný není, ale dárcovské sms jsou na prd (je třeba mít
živnosťák, pokud se nepletu) a taky jsou z nich minimální částky pro
 

Na jakekoliv podnikani je potreba mit zivnostak, at uz clovek prijima
penize pres sms nebo jinak.

Taky mne neco takoveho napadlo, moje idea byla, ze by pro technicky
nedostatecne zdatne podnikatele (k tomu aby se tam zanesli sami) byl
formular, kde by si clovek vybral co tam chce nacpat (hospodu, obchod,
supermarket, ...), dopsal tam pak do kolonek dalsi udaje (oteviraci
hodiny, atd ), pak by se nasel v mape a umistil tam bod a ono by
to pak vyrobilo node s patricnymi tagy a ten to pak po schvaleni
adminem systemu uploadlo. Neco ve stylu kdyz se firma zapisuje treba
do seznamu. K realizaci jsem se zatim ale nedostal (a vzhledem k
mnozstvi jine prace asi ani jen tak nedostanu). S nejakym zpoplatnenim
jsem nepocital, i kdyz mozna by nemuselo byt spatne tam dat moznost
dobrovolneho financniho prispevku na domapovani okoli nebo tak neco.

Vyhoda meho systemu je, ze admin jen omrkne jestli tam neni zadany
nejaky nesmysl a schvali. Prace tak max. na 5 vterin/firmu.

Martin

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
   
Můžu nabídnout vlastní hosting i zaštítit projekt vlastním ŽL (+DPH 
registrací), mám i jeden z více volných spořících účtů u mBank, který 
nepoužívám a ze kterého mohu pravidelně poskytovat výpisy. Platba přes 
Pipay.cz, kde mám myslím i registraci. Bohužel nemám příliš času na 
samotnou realizaci takového projektu, ale dám klidně komukoliv volné 
pískoviště na hraní. S utrženými provizemi nechť si (po jejich zdanění) 
dělá česká komunita, co je libo, věnuji je na cokoliv, co uznáte za vhodné.


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


Re: [Talk-cz] OpenStreetMap komerční služba

2010-01-07 Tema obsahu Martin Kokeš
Dne 7.1.2010 14:49, Martin Kokeš napsal(a):
 Dne 7.1.2010 13:58, MP napsal(a):
 Nápad to špatný není, ale dárcovské sms jsou na prd (je třeba mít
 živnosťák, pokud se nepletu) a taky jsou z nich minimální částky pro
  
 Na jakekoliv podnikani je potreba mit zivnostak, at uz clovek prijima
 penize pres sms nebo jinak.

 Taky mne neco takoveho napadlo, moje idea byla, ze by pro technicky
 nedostatecne zdatne podnikatele (k tomu aby se tam zanesli sami) byl
 formular, kde by si clovek vybral co tam chce nacpat (hospodu, obchod,
 supermarket, ...), dopsal tam pak do kolonek dalsi udaje (oteviraci
 hodiny, atd ), pak by se nasel v mape a umistil tam bod a ono by
 to pak vyrobilo node s patricnymi tagy a ten to pak po schvaleni
 adminem systemu uploadlo. Neco ve stylu kdyz se firma zapisuje treba
 do seznamu. K realizaci jsem se zatim ale nedostal (a vzhledem k
 mnozstvi jine prace asi ani jen tak nedostanu). S nejakym zpoplatnenim
 jsem nepocital, i kdyz mozna by nemuselo byt spatne tam dat moznost
 dobrovolneho financniho prispevku na domapovani okoli nebo tak neco.

 Vyhoda meho systemu je, ze admin jen omrkne jestli tam neni zadany
 nejaky nesmysl a schvali. Prace tak max. na 5 vterin/firmu.

 Martin

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

 Můžu nabídnout vlastní hosting i zaštítit projekt vlastním ŽL (+DPH 
 registrací), mám i jeden z více volných spořících účtů u mBank, který 
 nepoužívám a ze kterého mohu pravidelně poskytovat výpisy. Platba přes 
 Pipay.cz, kde mám myslím i registraci. Bohužel nemám příliš času na 
 samotnou realizaci takového projektu, ale dám klidně komukoliv volné 
 pískoviště na hraní. S utrženými provizemi nechť si (po jejich 
 zdanění) dělá česká komunita, co je libo, věnuji je na cokoliv, co 
 uznáte za vhodné.

 Martin Kokeš
Jinak ještě co se týče Pipay.cz resp. Mobilníplatby.cz, provize se liší 
podle toho, od kterého operátora SMS přijde. Dávám příklad:
SMS za 30 Kč = na účet O2 13,07; TMobile 13,07; Vodafone 9,37

MK


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


Re: [Talk-cz] OpenStreetMap využit v komerčn ích SmartMaps

2009-12-23 Tema obsahu Martin Kokeš
První komerční firmou využívající OSM data je IMHO Nav'n'Go, která vydala 
OSM-based mapy Běloruska, Moldávie tuším ještě, Makedonie a Albánie ve formátu 
pro navigační SW IGO 8 už před nějakou dobou.

Martin Kokeš

- Original Message -
From: Aleš Janda
[mailto:openstreet...@kyblsoft.cz]
To: OpenStreetMap Czech Republic
[mailto:talk...@openstreetmap.org]
Sent: Wed, 23 Dec 2009 12:10:34
+0100
Subject: [Talk-cz] OpenStreetMap využit v komerčních SmartMaps


 Dnes jsem se dozvěděl o (první?) komerční firmě, která pro svůj
 byznys přímo 
používá OpenStreetMap - a sice mapová aplikace SmartMaps
 pro mobilní zařízení. 
Sice tuto možnost zpoplatnili přirážkou a
 navíc je to jen mimo ČR a SR (proč?), 
ale i tak myslím, že je to pro
 OSM velký úspěch - jsem rád, že ho vzali za své a 
nevidí v tom
 konkurenci, které by mohli chtít škodit.

Více
 na
http://www.palmserver.cz/modules.php?name=Newsfile=articlesid=4756
http://www.pressonline.cz/a/tz.php?akce=zpravad=2510
a
 přímo nabídka
http://www.smartmaps.cz/produkty/smartmaps-osm/

Aleš
 Janda

___
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] Vrtulnikova mapa pro GPS Garmin

2009-10-15 Tema obsahu Martin Kokeš
Dne 15.10.2009 16:50, Ivo Lukacovic napsal(a):
 Vysledek je tak upokojujici, ze jsem se rozhodl takovou mapu udelat i 
 pro oblast Alp, kde je moznost kolize s lanovkami, draty a terenem 
 zdaleka nejvyssi. Bohuzel jsem narazl na mnoho prekazek.

 1) Nedari se mi sehnat nejakou volne siritelnou variantu vrstevnic.

Možná pomůžou tyto odkazy:
http://wiki.openstreetmap.org/wiki/GroundTruth
http://wiki.openstreetmap.org/wiki/SRTM

MK


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


Re: [Talk-cz] Dotazy začátečníka #1

2009-09-09 Tema obsahu Martin Kokeš
Dne 9.9.2009 12:54, Petr Stehlik napsal(a):
 Asi bych si to pro sebe shrnul tak, že pokud je na cuzk:km vidět
 oddělení/rozdělení vozovek, tak bych to měl vidět i v OSM.

To je rozumné, jednu chvíli jsem měl tendence rozdělovat před kruhovými 
objezdy silnici do jednosměrných pruhů, ale nakonec jsem to předělal s 
napojením přímo rovně.
Třeba takto http://osm.org/go/0...@fede--
Příklad účelové komunikace, odbočující už před kruháčem: 
http://osm.org/go/0J8K8AV5L-- (podobně bych řešil i zmíněné objízdné 
pruhy, které spojují ramena kruhových křížovatek)

Nicméně větší ostrovy zeleně a pruhy mezi nimi bych zakreslil:
http://osm.org/go/0J5f99jA5--

Ale jak vyřešit asfaltový rynek velikosti 100x100x100 m, to je pro mně 
záhada, zatím je to takto, pokud někdo nevymyslí lepší rendering (zadat 
šířku pruhů):
http://osm.org/go/0J8Knn3zt--

MK


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


Re: [Talk-cz] Adresy, epilog

2009-08-06 Tema obsahu Martin Kokeš
Dne 6.8.2009 12:46, Kubajz napsal(a):
 A ted jedna takova kousava:

 mam dum, ktery ma vchod ze severu. Cesticka vede kolem nej pres pozemek
 a vchod na pozemek je z jihu. Kam umistit adresni bod? (Jo a ja to nestavel)

 a) do budovy
 b) na hranu budovy, tam kde je fyzicky vchod
 c) na hranu pozemku

 Babo rad :/

 K

S ohledem na budoucí navigační funkce asi tam, kam se lze nejblíže 
dostat v rámci veřejného prostranství nebo po (i třeba soukromé) účelové 
komunikaci. Prostě k první zábraně. S tímto jsem se potýkal třeba před 
týdnem - byl jsem v Anglii a jezdil jsem autem po různých hradech, 
zámcích, některé byly docela odlehlé a cesty k nim nezmapované (v okolí 
vedlo spoustu klasických silniček o šíři 2,5 m - na každé straně zeď s 
živým plotem, co 200 m možnost vyhnutí). POI byl někde uprostřed toho a 
kolikrát jsem tam dojel třeba z druhé strany, kde se o nějakém 
parkovišti mluvit rozhodně nedalo.

MK


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


[Talk-cz] **SPAM** Re: Zaverecne hlasovani o adresach

2009-06-28 Tema obsahu Martin Kokeš
Hlas pro 1)

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


Re: [Talk-cz] Adresy, finale diskuse

2009-06-05 Tema obsahu Martin Kokeš
Dne 5.6.2009 9:07, Petr Nejedlý napsal(a):
 Zdar,

 Moje namitky proti konscriptionnummer:
 1. Nikdy zadny globalni search engine nebude zohlednovat tuhle opicarnu.
 2. Nikdy zadny globalni rendered nebude renderovat tuhle opicarnu.
 3. (plyne z 1 a 2) AndNav2 me nikdy nedovede na takovou adresu.

1. Ale ano, bude a zohledňuje. Zkuste si vyzkoušet v libovolných 
webmapách v libovolném městě zadat adresu s číslem popisným a číslem 
orientačním. Najde vám obojí.
2. Pokud nikdo nenavrhne a nepožádá o začlenění příslušného stylu, o co 
se, jak vidno, už vynasnažil Radek Černoch, tak ne.
3. Pokud bude vývojář AndNav2 líný začlenit do svého SW funkci, kterou 
disponuje libovolný TomTom Navcore, IGO, Garmin, tak nedovede. V opačném 
případě ano.

Tato opičárna u nás je od C.K. R-U, stěžujte si u svých samospráv, proč 
za ta léta, kdy jsou u vesel a nejsou řízení centrálně, ještě nezavedli 
čísla orientační (housenumbers), jak je současným standardem:

http://en.wikipedia.org/wiki/House_numbering

MK




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


Re: [Talk-cz] Adresy, finale diskuse

2009-06-05 Tema obsahu Martin Kokeš
Dne 5.6.2009 13:23, Radomír Černoch napsal(a):
 Tohle téma jsem otevřel 2x na talk@ a v talk-cz@ se teď řeší potřetí.
 Každou chvíli se objeví někdo, kdo minulou diskuzi (ve stejném mailing
 listu) neviděl a navrhne něco, co už se dávno zavrhno.

 Konskriptionsnummer vyšel vyšel jako závěr 2. kola diskuzí na talk@ i
 talk...@. Přitom je to jediný návrh, proti kterému je nejvážnější
 výtka náchylnost na překlepy. Máte-li někdo jiný nápad, jak tagovat
 čísla popisná, navrhněte ho, oběhněte kolečko na talk@ i talk-cz@ a
 sdělte mi výsledek. Přeji pěkné dny ztrávené psaním desítek mailů. Já
 už na to nemám nervy a začíná mi to být jedno.

Každý dobrý skutek musí být po zásluze potrestán. Každá iniciativa 
dospět k nějakému čistému databázovému řešení samozřejmě také. ;-)

Jinak mě napadá mě důvod, proč nepsat do housenumber čísla ve formátu 
452/34 resp. 452;34. Pokud k tomu nebude nějaký nástroj, nedůsledný 
člověk se lehce splete a napíše 34/452. Dotazovat se do databáze na 
takto promixovaná č.p. a č.o. (třeba za účelem kontroly proti číselníkům 
státní správy) musí být opravdu vzrušující...

MK
a), b) i c)


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


Re: [Talk-cz] Adresy, finale diskuse

2009-06-04 Tema obsahu Martin Kokeš
Dne 4.6.2009 16:33, Tomáš Tichý napsal(a):
 Moje řeč. Navíc když se dělal import, tak se taky na diskuzi v listu
 nebrat ohled a udělalo provizorní řešení s nesmyslným
 alternatenumber a spoustou None, které nám teď dělají bordel v
 renderování.
 Každá změna k lepšímu je dobrá.

 K addr:konskriptionsnummer:
   - když to někomu je nesrozumitelné, tak si to vygoogluje, překlad
 hned třetí odkaz
   - alternatenumber bylo nesrozumitelné nejen čechům, ale i komukoli dalšímu
 Takže ze špatného řešení se nám stane přijatelné řešení - já jsem jedině pro.

 Mimochodem každé debatě o tom jak něco otagovat se používá jako
 argument přinejhorším se to pak dá hromadně změnit.
 Tak ukažme, jestli je to platný argument :-)

 =TT=

Souhlasím se změnou. Ad konskriptionsnummer, jako pozůstatek německého 
vlivu je to vhodné a myslím i světově jednoznačné pojmenování.

MK


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


Re: [Talk-cz] Adresy, finale diskuse

2009-06-04 Tema obsahu Martin Kokeš
Dne 4.6.2009 20:51, Pavel Machek napsal(a):
 a) spatna srozumitelnost pro anglicky mluvici lidi (nutnost googlovat)

 (hodne cechu mluvi anglicky)

Zajímalo by mě, proč ti anglicky mluvící lidé taky neprotestují proti 
amenity:biergarten, amenity:bureau_de_change...
 b) vetsi sance na preklepy.

Pokud někdo nepoužije czechaddress, nebo předdefinované tagy, tak je to 
myslím stejně překlepoidní, jako historic:archaeological_site, 
highway:emergency_access_point
 Jako vyhodu chapu ze je to jednoznacny v ramci sveta. Podle me
 nevyhody prevazujou.

Myslím, že tyhle diskuze jsou takové hnípaní se v detailech a přehlížení 
primárního cíle. Ten je, jasně stanovit atribut místně specifický a 
historicky vázaný jen na země, které v 18.-19. století používaly jako 
úřední jazyk němčinu. Pro všechny výrazy v cizích jazycích holt 
angličtina nemá alternativy a tak jako čeština i ona používá cizí slova. 
Dneska se taky nikdo nediví názvu filmu I Robot, přestože robot jak 
víte není nativní anglický výraz...

MK


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


Re: [Talk-cz] Adresy, finale diskuse

2009-06-04 Tema obsahu Martin Kokeš
Dne 4.6.2009 22:00, Karel Volný napsal(a):
 uff, cože?

 takže plán je nacpat do addr:housenumber, které se běžně renderuje, číslo
 orientační, a do addr:konskriptionnummer (*), které se nerenderuje, o jehož
 existenci skoro nikdo neví, a kdo ví, tak neví, co to je za sprosté slovo,
 číslo popisné?

Ad rendering, viz dotaz a návrh na 
http://lists.openstreetmap.org/pipermail/talk/2009-May/036901.html

MK


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


Re: [Talk-cz] OSM: změna licence

2009-03-05 Tema obsahu Martin Kokeš
Dne 5.3.2009 11:17, Tomas Kolda napsal(a):
 Z toho co jsem vypozoroval se mi nova libi a problem s tim nemam. Chapu
 take, ze zmenit licenci by se melo udelat vcas. Coz uz neni asi pripad
 OSM, ale bude to jedine horsi. Soucasna neni na miru teto aplikace, tak
 proc ji nezmenit. Pro me osobne licence musi splnovat toto:

 * Moznost pouzit data jakymkoliv zpusobem (i komercne) jen s tim
 omezenim, ze se musi uvest zdroj
 * Nenutit nikoho kdo pomoci dat neco vytvoril, aby zpristupnoval cokoliv
 z jeho prace zdarma nebo zdrojove kody apod.

 Zbytek pro me neni dulezity.

Mám na to podobný názor. Zkrátka se na podobné věci mělo myslet už v 
začátcích, nicméně podobné projekty jsou výsledkem více či méně 
nekontrolovatelného vývoje.

Vadí mi jen nějaké případné mazání dat těch, kteří s novou licencí 
nesouhlasí nebo souhlasit nebudou/nemohou. Už padlo víc návrhů a nějaké 
přechodné období by určitě neškodilo. Osobně také nevidím ohledně 
hromadných importů problém, zase tolik jich v ČR nemáme.

Mimochodem, když se člověk podívá na text CC 3.0:
http://creativecommons.org/licenses/by-sa/3.0/legalcode
tak je to opět kus hnusný právničiny jako ODBl, jen možná v bledě 
zeleném místo v bledě modrém.

MK


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


Re: [Talk-cz] OSM: změna licence

2009-03-04 Tema obsahu Martin Kokeš
Dne 4.3.2009 11:13, MP napsal(a):
 Chtelo by to k tehle licenci i nejake max. jednostrankove shrnuti co
 teda s daty lze/nelze delat pro nepravniky. Doufejme ze vznikne 

http://wiki.openstreetmap.org/wiki/Open_Data_License/Use_Cases , pravda, 
je sice na jedné stránce, ale počet příkladů použití trochu nabobtnal

Osobně se na celou věc tvářím neutrálně.

MK


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


Re: [Talk-cz] dotaz na poslední verzi JOSM

2009-02-26 Tema obsahu Martin Kokeš
Zdeněk Pražák napsal(a):
 Mohl by jsi ve zkratce popsat na co jsi přišel, anglickému textu jsem moc 
 neporozumněl.
 Zdeněk Pražák
   
Online překladač nepomohl?
http://translate.google.com/translate?prev=hphl=csu=http%3A%2F%2Fjosm.openstreetmap.de%2Fticket%2F2240sl=entl=cs

MK


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


Re: [Talk-cz] Dopravní podnik Prahy

2009-02-24 Tema obsahu Martin Kokeš
Petr Dlouhý napsal(a):
 Dobrý den,

 komunikoval jsem s DPP ohledně možnosti využívaní dat z jejich schémat a 
 podobně. Nevím ale, jak k výsledku komunikace přistupovat. Znamená to co mi 
 odepsali výslovný souhlas? Nebo se taková data dají z jízdních řádů čerpat i 
 bez svolení dané instituce?
   
Mám obavu, že jízdní řád není žádné autorským zákonem chráněné umělecké,
ani uměleckému dílu podobné, dílo. :-)

MK




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


Re: [Talk-cz] Dopravní podnik Prahy

2009-02-24 Tema obsahu Martin Kokeš
Petr Dlouhý napsal(a):
 On Tue, 24 Feb 2009 16:05:58 +0100, Martin Kokeš sh...@typo3-hosting.com  
 wrote:

 To bych neřekl, že dílo musí být umělecké, aby ho chránil autorský zákon.  
 Je snad počítačový program, nebo mapa umělecké dílo? Nemyslím si, že bych  
 mohl vzít jízdní řád jako celek a dělat si s ním co chci (například ho  
 prodávat v rámci svého programu). Jízdní řád je databáze, na kterou se  
 vztahují autorské zákony stejně jako na další díla.
 Jiná věc je, jestli by nešlo o čerpání ze zdroje podobné tomu, jako když  
 se píše odborná publikace (nebo něco podobného).
 Bohužel se v daných zákonech nevyznám tak do hloubky, abych byl schopen  
 říct, co je a co není možné.
   
U jízdního řádu chybí především tvůrčí prvek (tím spíš, když z něho 
chceš použít jen pořadí zastávek...). Ad zbytek... nevím proč tolik 
zbytečných otázek, co je a co není Dílo jasně říká paragraf 2 AZ.
*
http://cs.wikisource.org/wiki/Autorsk%C3%BD_z%C3%A1kon_(121/2000)

MK
*


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


Re: [Talk-cz] Dopravní podnik Prahy

2009-02-24 Tema obsahu Martin Kokeš
hanoj napsal(a):
  Verze jízdního řádu IDOS pro nevidomé a slabozraké.
 Provozuje a inzertně zastupuje MAFRA, a.s. Aplikaci vyvíjí a
 technologie dodává CHAPS, spol. s r.o.
 Garance dat
 verze 1.72.05/1.31/2.08
 Publikování a další šíření informací bez souhlasu autorů je zakázáno.
Seznam zastávek nikdy nemůže být jedinečným výsledkem tvůrčí činnosti 
autora. Je to faktická informace, kterou lze kdykoliv přesně vygenerovat 
mnoha dostupnými způsoby znovu a znovu v nejedinečné formě (má-li tato 
forma reprezentovat skutečný stav věci).

A co se týče citovaného textu, není tam napsáno, kdo je autorem (autor 
může být pouze fyzická osoba, nikoliv CHAPS, spol. s r.o., MAFRA a.s.) a 
zřetelně se jedná o souborné dílo, které navíc vzniká zřejmě při 
sestavování grafikonu a generuje ho nějaký specializovaný software. 
Navíc jízdní řády lze bez problémů přímo zkopírovat včetně dat pomocí 
§ 33, natož pak §36 a §37 odst. 2. písm. a).

Jediná kopie jízdního řádu, která by skrz AZ neprošla je např. úplná 
bajt-po-bajtu totální kopie jízdního řádu včetně obslužného programu.

MK


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


Re: [Talk-cz] licence heis.vuv.cz vs. dibavod

2009-02-17 Tema obsahu Martin Kokeš
hanoj napsal(a):
 5) Ne tak na tady:
 http://www.otevrete.cz/forum/viewtopic.php?p=3447#3447
   
No já tam vidím teda něco úplně jiného.

Kužílek: Takovým bývá rejstřík, který je zřízen na základě zákona a též 
je zákonem stanoveno, že je každému volně přístupný.

Ve Vodním zákoně je (pro mě zcela jasně) napsáno, že (kráceno a 
nahrazeny odkazy) zjišťování a hodnocení stavu povrchových a podzemních 
vod slouží k poskytování informací veřejnosti a Ministerstvo 
zemědělství a Ministerstvo životního prostředí postupují při správě 
informačních systémů podle odstavců 3 a 4 podle zákona o informačních 
systémech veřejné správy.

Pro jistotu jsem tam vznesl dotaz, nicméně je to myslím jednoznačné sdělení.

MK


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


Re: [Talk-cz] natural=water vs landuse=reservoir

2009-02-15 Tema obsahu Martin Kokeš
Karel Volný napsal(a):
 'hoj,

 chtěl jsem doplnit jména rybníků v okolí trasy, co se teď snažím nasypat do 
 mapy, a zjistil jsem, že tyto rybníky jsou označeny jako natural=water

 podle wiki (http://wiki.openstreetmap.org/wiki/Tag:natural=water) by se ale 
 takto měla označovat jezera a jezírka; pro lidmi vytvořené nádrže (= rybníky) 
 by se asi mělo používat landuse=reservoir 
 (http://wiki.openstreetmap.org/wiki/Tag:landuse=reservoir)

 jenže když jsem to zkusil změnit, tak se mi ta plocha přestala vykreslovat, 
 ačkoliv podle wiki by to oboje měl být modrej flek

 tož kde je chybka, pochopil jsem to špatně, anebo máme většinu republiky blbě 
 otagovanou a zároveň Merkaartoru chybí příslušné vykreslovací pravidlo?

 K.
   
Já teda nevím, ale mně Merkaartor 0.13pre1 vykresluje správně jak 
reservoir tak water (style MapnikPlus). Osobně dělám natural water v 
JOSMu s tím, že se ve svém okrese k tomu následně vrátím. IMHO 
analýzou OSM lze podle názvů rybníků docela dobře otagovat správně každý 
rybník/jezero (předpokládám, že rybníky u nás převažují), a to hromadně 
v rámci některého z velkých úklidů. Myslím, že zbytečné soustředění se 
na detaily ohledně tagů je často kontraproduktivní a mně osobně to třeba 
odhání od důležitější práce (správného zákreslení). Hlavní je, že se to 
správně vyrenderuje a cizelování se člověk může vždycky vrátit.

MK


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


Re: [Talk-cz] dotaz na tagování skalních útvar ů

2009-02-13 Tema obsahu Martin Kokeš
Zdeněk Pražák napsal(a):
 Nikdo neví ?
   
cliff je IMHO libovolný skalní útvar a takto se podle příkladu renderuje 
v mapniku. http://www.openstreetmap.org/?lat=53.35538lon=-1.63862zoom=15

Možná by to chtělo příště věnovat více pozornosti celému textu na 
http://wiki.openstreetmap.org/wiki/Tag:natural%3Dcliff

MK


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


Re: [Talk-cz] dotaz na tagování skalních útvar ů

2009-02-13 Tema obsahu Martin Kokeš
Michal Grézl napsal(a):
 2009/2/13 Martin Kokeš sh...@typo3-hosting.com:
 utes jako utes at je na pobrezi nebo ne, ale o samostatnem sutru,
 treba i velikosti skaly tam nic neni. Neco ve stylu
 http://navigovat.mobilmania.cz/Files/Obrazky/2008_Q2/TopoSrovnani/49.png,
 viz ty sede dobky v okoli vrcholu, zrejme to maji byt nejake prerostle
 sutry.
   
http://wiki.openstreetmap.org/wiki/Tag:natural%3Dcliff
Vlevo boxík element:
Can be attached on nodes
Can be attached on ways
Can be attached on areas

Jiná otázka je, jestli se to bude nějak renderovat.

MK


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


Re: [Talk-cz] dotaz na tagování skalních útvar ů - oprava

2009-02-13 Tema obsahu Martin Kokeš
Michal Grézl napsal(a):
 2009/2/13 Martin Kokeš sh...@typo3-hosting.com:
 utes jako utes at je na pobrezi nebo ne, ale o samostatnem sutru,
 treba i velikosti skaly tam nic neni. Neco ve stylu
 http://navigovat.mobilmania.cz/Files/Obrazky/2008_Q2/TopoSrovnani/49.png,
 viz ty sede dobky v okoli vrcholu, zrejme to maji byt nejake prerostle
 sutry.
   
http://wiki.openstreetmap.org/wiki/Tag:natural%3Dcliff
Vlevo boxík element:
Can be attached on nodes
Can be attached on ways
Can be attached on areas

Jiná otázka je, jestli se to bude nějak renderovat.

MK

Oprava: vpravo nikoliv vlevo


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


Re: [Talk-cz] Tip na citlivou GPS

2009-02-12 Tema obsahu Martin Kokeš
hanoj napsal(a):
 a k cemu je tam tech 66 kanalu?

 zdravi

 hanoj
   
LOL. Já nepsal, že jsem konstruktér toho čipu. Místo na 
talk-cz@openstreetmap.org jsi měl psát na serv...@mediatek.com. Možná, 
že předností toho čipu není čím víc kanálů, tím víc Adidas (i když za 
pár let se to může třeba hodit, až nám budou možná lítat nad hlavama 
GIOVy), ale citlivost a spotřeba energie.

Zdraví

Shr3k


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


Re: [Talk-cz] křížky a kapličky

2009-02-12 Tema obsahu Martin Kokeš
hanoj napsal(a):
 je tu někdo zkušenější v otázkách náboženství i architektury, kdo může
 potvrdit/vyvrátit, jak to chápu, a vnést do toho trošku lepší systém?
 (já jsem pokus o lepší návrh zabalil už na tom, že nejsem schopen zjistit, 
 jak
 se anglicky řekne smírčí kříž ... leda tak inspirovat se německým Steinkreutz
 = Stone cross)
 
 *** dost mozna je problem v historii, my patrime pod region
 nemecko/rakousko, v anglii je plno jinych krizu a stel jiz 2000 let.

 hanoj
   
Steinkreuz (Sühnestein, Mordwange) = smírčí kříž. Anglicky by se dalo 
stone cross nebo conciliation cross. Řekl bych, že smírčí kříže v UK 
nejsou proto, že tam platila od 13. století Magna carta a s ní i právo 
na řádný soud. Soudnictví tam tedy bylo značně rozvinuté, na rozdíl od 
kontinentální Evropy. U nás se mimosoudní vyrovnání vraždy coby součást 
smírčího práva zrušilo teprve po 30leté válce, takže kříže postavené 
poté už slouží jen jako památka na místo neštěstí.

Jinak pokud bychom netrvali nutně na podobě kříže, jde použít výraz 
stéla, čili stele. http://en.wikipedia.org/wiki/Stele , což myslím 
pochopí i Angličani. Případně jako high cross čili vztyčený kříž, což je 
ostatně i kategorie http://en.wikipedia.org/wiki/Category:High_crosses .

MK


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


[Talk-cz] Tip na citlivou GPS

2009-02-11 Tema obsahu Martin Kokeš
Vážení, pokud někdo hledá citlivou GPS na logování do lesa, resp. na 
logování vůbec, můžu doporučit nové GPS s 66kanálovým čipsetem Mediatek 
Qstarz BT-1000X (cca 6 MB logger) a nebo BT-Q818X bez loggeru. Umí i 5 
Hz mód a jejich citlivost a přesnost je opravdu skvělá. Po porovnání 
jsem dal na http://leteckaposta.cz/590367438 srovnání včerejší cesty s 
HP iPAQ rx5730. Logoval jsem jak výstup z interní GPS se SiRF III (NMEA 
výstup z iGO8), tak připojenou Qstarz BT-1000X (Efficasoft GPS 
Utilities). Pokud si to natáhnete do JOSMu a připojíte si 0,5 m ortofoto 
z Cenia, myslím, že budete mile překvapeni. Jen těch bodů je na vymazání 
poněkud víc. :-)

Takže kdo chce logovat v lese, optimum je Qstarz na rameno, nebo na 
čepici a smartphone s Efficasoft GPS Utilities v kapse.

MK


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


Re: [Talk-cz] dotaz na verzi JOSM 1344

2009-01-29 Tema obsahu Martin Kokeš
Zdeněk Pražák napsal(a):
 Co má uvedený plugin umět, kde se dá stáhnout a kam se musí instalovat.
 Pražák
   
Já teda nevím, ale mně ty pluginy stahuje a instaluje přímo JOSM. F12  
Záložka s elektrickou zásuvkou a kabelem. ;-) Co takový plugin umí je 
popsáno tamtéž.

MK


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


Re: [Talk-cz] Katastralni mapy CUZK

2009-01-09 Tema obsahu Martin Kokeš
Pavel Kovář napsal(a):
 Já jenom že to není polňačka ale asfaltka a ta už se neměnila pěkně dlouho.

 JInak k Územním plánům asi moc jednoduchý přístup nebude jak sem se tak díval
Ono to je možná tak, že se díváte (a divíte) nad starým, skenovaným 
katastrem. Pokud se podíváte na plně digitalizovaný (vektorový) katastr, 
z valné většiny sedí. Digitalizace katastru je postupná (akutálně cca 40 
%), víc třeba na webu konference Internet ve státní správě:  
http://www.isss.cz/archiv/2008/download/prezentace/stencel_cuzk.pdf

MK


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


Re: [Talk-cz] dotaz na vykreslení mapy v OSMrenderer u

2008-12-30 Tema obsahu Martin Kokeš
Zřejmě to někomu spadnuly ti...@home na nedostatek paměti nebo míst na disku.

Martin Kokeš
  _  
From: Zdeněk Pražák [mailto:zpra...@seznam.cz]
To: talk-cz@openstreetmap.org
Sent: Tue, 30 Dec 2008 11:42:34 +0100
Subject: [Talk-cz] dotaz na vykreslení mapy v OSMrendereru

Mám dotaz proč je špatně vykreslena v OSMrendereru oblast mezi letištěm Hradec 
Králové a obcemi Skalice a Hubiles. Okolní území je jinak vykresleno v pořádku
Vykreslení v mapniku uvedeného území je v pořádku

___
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] je DIBAVOD verejny informacni rejstrik?

2008-11-19 Tema obsahu Martin Kokeš
Jiri Klement napsal(a):
 Ja jsem tu diskuzi pochopil tak, ze na pouziti DIBAVODu neni pravni
 narok. Ale povodi labe neoficialne souhlasilo (akorat by se muselo
 vyresit to, ze na mape ma by napsano Vytvoreno pomoci dat povodi
 Labe). Je mozne, ze by souhlasila i ostatni povodi.
   
Poslal jsem na otevrete.cz doplňující dotaz:

http://www.otevrete.cz/forum/viewtopic.php?p=3457#3457

MK



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


Re: [Talk-cz] je DIBAVOD verejny informacni rejstrik?

2008-11-19 Tema obsahu Martin Kokeš
Jiri Klement napsal(a):
 Ja jsem tu diskuzi pochopil tak, ze na pouziti DIBAVODu neni pravni
 narok. Ale povodi labe neoficialne souhlasilo (akorat by se muselo
 vyresit to, ze na mape ma by napsano Vytvoreno pomoci dat povodi
 Labe). Je mozne, ze by souhlasila i ostatni povodi.
   
Poslal jsem na otevrete.cz doplňující dotaz:

http://www.otevrete.cz/forum/viewtopic.php?p=3457#3457

MK



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


[Talk-cz] Použití ÚIR-ZSJ

2008-11-19 Tema obsahu Martin Kokeš
Abychom to nějak nezdazili, padl tu dotaz na zmíněné číselníky:

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

Vzhledem k tomu, co je uvedeno na:

http://www.czso.cz/csu/redakce.nsf/i/zasady_cenove_strategie_v_csu_
---
*2.1. Poskytnutí statistických informací zdarma*
ČSÚ postupně zveřejňuje na svých internetových stránkách maximum
informací získaných statistickým zjišťováním. Jsou k dispozici pro
každého, kdo je potřebuje a umí je použít. Jde např. o Rychlé informace,
publikace v elektronické formě, veřejnou databázi a další odvětvové
dotazovací aplikace. Navíc v rámci běžného režimu informačních služeb
ČSÚ poskytuje (zdarma) technickou i metodickou podporu každému, kdo o ni
požádá.

Veškeré údaje na internetových stránkách ČSÚ si může kdokoliv převzít
pro své účely bezplatně, pouze s podmínkou, že uvede jako zdroj ČSÚ. Je
doporučováno uvádět i datum, kdy údaje byly převzaty.
---
Bych se s tím nijak nepáral, uvedl u toho source a data využil (případně
si schoval screenshot uvedené stránky). Co na to říká konfera?

MK



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


Re: [Talk-cz] Použití ÚIR-ZSJ

2008-11-19 Tema obsahu Martin Kokeš
Ondrej Novy napsal(a):
 Ahoj,

 On Wed, Nov 19, 2008 at 02:14:23PM +0100, Martin Kokeš wrote:
   
 Abychom to nějak nezdazili, padl tu dotaz na zmíněné číselníky:

 http://www.czso.cz/csu/rso.nsf/i/prohlizec_uir_zsj
 ...
 ---
 Bych se s tím nijak nepáral, uvedl u toho source a data využil (případně
 si schoval screenshot uvedené stránky). Co na to říká konfera?
 

 souhlasim, akorat co z toho chceme pouzit? :)
   
Cit. Ze by to byl tygl. ;)

No já nevím, řeč byla o těchto číselnících a dalších věcech z 
http://www.czso.cz/csu/rso.nsf/i/ke_stazeni_rso v souvislosti s čísly 
popisnými.

MK


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


Re: [Talk-cz] Možnost využití dat Povodí Labe

2008-10-27 Tema obsahu Martin Kokeš
Tomas Kolda napsal(a):
 - Kontrolu licence :). Ja vim, ze s tim porad otravuju, ale asi je to 
 nejvice dulezite...
Požádal jsem o vyjádření p. Kužílka, odborníka na právo a svobodný 
přístup k informacím:
http://www.otevrete.cz/forum/viewtopic.php?p=3447#3447

MK
http://www.otevrete.cz/forum/viewforum.php?f=3


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


Re: [Talk-cz] Možnost využití dat Povodí Labe

2008-10-23 Tema obsahu Martin Kokeš
Petr Dlouhý napsal(a):
 Mě teda ta přesnost nepřipadá nijak přehnaně vysoká, ne pokud si děláme  
 ambice, že to jednou může sloužit i jako turistická mapa. Později bychom  
 toho mohli litovat, protože například podle detailů ve tvaru těch řek by  
 šlo odhadnout polohu různých objektů při podrobném mapování (cesta vede  
 podel řeky a odpojí se u třetího meandru).
 Nemám úplně představu, kolik to bude zabírat celkem, ale pokud se to vejde  
 do 50MB (po komprimaci), tak bych o tom osobně nepřemýšlel. Byl bych spíš  
 pro to, aby se udělala generalizovaná verze czehie určená pro export do  
 různých zařízení (například do navigace se možná řeky nemusí exportovat  
 vůbec).
   
Mám na to stejný názor. Pokud to má být mapa univerzální (s tím, že z ní 
bude možno exportovat různě podrobné mapy pro různé účely), bylo by 
podle tohoto návrhu optimální zachovat data tak jak jsou a případně je 
zpřesňovat už jen ručně podle GPS, či případně v budoucnu pomocí 
přesnějšího ortofota. Stačí se podívat, co všechno člověk najde v 
Garminu a mapě TOPO 2 Czech PRO. Pokud bude OSM stejně tak dobrá ne-li 
lepší (díky znalostem lokálních přispěvatelů), bude to jen dobře.

MK


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


Re: [Talk-cz] Možnost využití dat Povodí La be

2008-10-22 Tema obsahu Martin Kokeš
Petr Nejedly napsal(a):
 No ja jsem se mezitim mrknul i na A01 (osy vsech toku) a to bylo bratru 5M
 bodu a vsechno siroko daleko (cela republika) modre.
 A kdyz jsem se koukal zblizka na horni tok moravy (od pramene po obec Horni
 Morava, cili asi 8km), bylo tam spousta potucku ;-)
Předpokládám, že potůček je A naturally-formed waterway that is too 
thin to be classed as a river. A person may be able to just jump over 
it.Tak takový atribut OSM zná, stejně jako An artificial waterway for 
carrying storm water or industrial discharge. . ;o)
Jako je jasné, že Saúdská Arábie se, co se týče vodstva asi bude mapovat 
lépe, ale na druhou stranu, co mají říkat třeba Nizozemci nebo Finové, 
že... :-)

MK


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


Re: [Talk-cz] Možnost využití dat Povodí La be

2008-10-22 Tema obsahu Martin Kokeš
hanoj napsal(a):
 Dne 21. říjen 2008 19:12 Martin Kokeš [EMAIL PROTECTED] napsal(a):
   
 Martin Kokeš napsal(a):
 
 Další otázkou je zda nezkusit využít přímo DIBAVOD celý.
 http://www.vuv.cz/oddeleni-gis/17/o-projektu-dibavod.html

   
 Podíval jsem se na příslušné zákony, zejména 254/2001 Sb. a  391/2004
 Sb. kvůli nimž by DIBAVOD stvořen. Vzhledem k tomu, že DIBAVOD podléhá
 zákonu 365/2000 Sb. o informačních systémech veřejné správy a na výstupy
 z něj má právo každý bezplatně (pokud nepožaduje ověření) a to v
 libovolném rozsahu (úplné či po částech)
 
 *** kde se píše v 365/2000 Sb o poskytování bezplatného obsahu, na
 prvni pohled jsem to nenašel?
   
Tak to chce příště i druhý pohled, ne jen ten první.

§2
t) veřejným informačním systémem informační systém vedený správci 
uvedenými v § 3 odst. 2 nebo jiný informační systém poskytující služby 
veřejnosti, který má vazby na informační systémy veřejné správy;

§ 3
(2) Správci informačních systémů veřejné správy jsou ministerstva, jiné 
správní úřady a územní samosprávné celky (dále jen „orgány veřejné správy“).

§ 5
Orgány veřejné správy
(2) Orgány veřejné správy jsou v rámci informačních systémů veřejné 
správy povinny
f) postupovat při uveřejňování informací způsobem umožňujícím dálkový 
přístup tak, aby byly informace související s výkonem veřejné správy 
uveřejňovány ve formě, která umožňuje, aby se s těmito informacemi v 
nezbytném rozsahu mohly seznámit i osoby se zdravotním postižením. Formu 
uveřejnění informací stanoví prováděcí právní předpis;

§ 9
(1) Z informačních systémů veřejné správy nebo jejich částí, které jsou 
veřejnými evidencemi, rejstříky nebo seznamy, vydávají orgány veřejné 
správy, které jsou správci nebo provozovateli těchto systémů (dále jen 
„správci“), na požádání úplný nebo částečný výpis ze zápisu vedeného v 
elektronické podobě v tomto informačním systému.
(2) Výpis podle odstavce 1 (dále jen „výpis“) v listinné podobě je 
veřejnou listinou.
 , a je to veřejně přístupný
 rejstřík (§ 3 121/2000 Sb.), nevztahuje se na něj ochrana podle
 autorského zákona.
 
 *** o rejstřík IMHO nejde, jde o geodatabázi, která je odvozená z ZVH
 mapy. Jako rejstřík bych považoval nejspíš evidenci knih v knihovně.
   
Tak to snad jen opravdu IYHO.

§ 3 Výjimky z ochrany podle práva autorského ve veřejném zájmu
Ochrana podle práva autorského se nevztahuje na
a) úřední dílo, jímž je právní předpis, rozhodnutí, opatření obecné 
povahy, veřejná listina, veřejně přístupný rejstřík a sbírka jeho 
listin, jakož i úřední návrh úředního díla a jiná přípravná úřední 
dokumentace, včetně úředního překladu takového díla, sněmovní a senátní 
publikace, pamětní knihy obecní (obecní kroniky), státní symbol a symbol 
jednotky územní samosprávy a jiná taková díla, u nichž je veřejný zájem 
na vyloučení z ochrany,

Takže si to shrneme, u každého informačního systému veřejné zprávy (krom 
systémů citovaných v § 3 365/2000 Sb.) je jejich správce (orgán veřejné 
správy) povinen postupovat při uveřejňování informací způsobem 
umožňujícím dálkový přístup tak, aby byly informace související s 
výkonem veřejné správy uveřejňovány ve formě, která umožňuje, aby se s 
těmito informacemi v nezbytném rozsahu mohly seznámit i osoby se 
zdravotním postižením.

I kdyby zmíněná databáze nebyla veřejně přístupným rejstříkem (což 
evidentně je, jak podle 365/2000 Sb. §2 písm. t , tak i podle 254/2001 
Sb. §22 odst. 3), stále je její úplný výtisk veřejnou listinou. Správce 
je povinen na požádání vydat úplný nebo částečný výpis ze zápisu 
vedeného v elektronické podobě v tomto informačním systému, který pak má 
status veřejné listiny a na tu se nevztahuje ochrana podle práva autorského.

MK


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


[Talk-cz] Možnost využití dat Povodí Labe

2008-10-21 Tema obsahu Martin Kokeš
Nedalo mi to a zeptal jsem se Povodí Labe na možnost využití jejich dat 
(osy vodních toků) ve formátu SHP, která poskytují na svých stránkách ke 
stažení a dostalo se mi kladné odpovědi od p. Staňka, správce jejich GIS 
i s doporučením. Ujmul by se prosím někdo importu?

Martin Kokeš
(shr3k)
---
Dobrý den,

filosofie našeho podniku je založena na principu, že data by měl 
poskytovat ten, který dané mapové objekty spravuje
a to pokud možno zdarma.

To je i odpovědí na Váš dotaz.
Na našich stránkách poskytujeme osy vodních toků, cizí i ty, které 
spravujeme (cca 300 os vodohospodářsky významných toků z cca 20.000 
všech os toků a meliorací na území našech Podniku = cca 1/5 ČR). Ty co 
spravujeme i aktualizujeme, a ty ostatní budou postupně aktualizovat 
jejich správci (Lesy ČR, Státní meliorační správa, Vojenské újezdy, ...)
Centrálně tak existuje 5 databází na 5 podnicích Povodí, které dohromady 
pokrývají toky celé ČR.

Co se týká IDéček, bylo na úrovni MZe odsouhlaseno, že bude používán 
jednoznačný číselný bezvýznamový identifikátor vodního IDVT, který již 
dnes naše databáze obsahují.
V případném využití doporučujeme tento IDVT udržovat a přes něj provádět 
jakékoli aktualizace nebo vazby. Tento IDVT přebírá postupně i ČÚZK do 
ZaBaGeD.

Offline data poskytujeme (cca 1x ročně) na našich stránkách: 
http://www.pla.cz/planet/ram.aspx?id=21 v SHP formátu
a do budoucna uvažujeme o zřízení WMS či WFS online přístupů do naší 
centrální databáze.

Zároveň naše data a data, která jsme oprávněni využít i pro internetové 
presentace jsou veřejně dostupná
přes GIS aplikaci http://www.pla.cz/gis/ , kde je vyžadován ActiveX 
prvek MapGuide od firmy AutoDESK.

Závěrem si dovolím konstaovat, že každý podnik Povodí řeší presentaci a 
poskytování svých dat individuálně.
Přesto jsou vybraná data (převážně legislativně určená), která se 
zveřejňují jednotně a ty jsou pak přístupná přes porál Ministerstva 
zemědělství (MZe) a Životního prostředí (MŽP)
http://www.voda.gov.cz/portal/cz/

S pozdravem



Pavel Staněk, správce GIS
__
Povodí Labe, státní podnik
Víta Nejedlého 951
500 03 Hradec Králové
tel. : +420 495 088 633
e-mail : [EMAIL PROTECTED]
http://www.pla.cz/
---
Dobrý den,

chtěl jsem se zeptat, zda by bylo možné použít některá mapová díla
státního podniku Povodí Labe pro účely projektu OpenStreetMap. Zejména
pak osy vodních toků, vodní nádrže, ale i případně i další vhodné
objekty ve správě Povodí Labe (jezy atd.). Nekomerční projekt
OpenStreetMap má za cíl vytvoření svobodných a licencemi nezatížených
map, volně použitelných v otevřeném formátu pro všechny uživatele. V
současné době to vypadá tak, že přispěvatelé buď mapují území na základě
záznamů svých GPS zařízení, nebo odvozují mapy ze zdrojů, které toto
umožňují (převážně ortofotomapy ÚHUL, případně katastru nemovitostí ČÚZK).

Více informací k uvedenému projektu naleznete zde:

http://www.openstreetmap.org/ případně http://www.informationfreeway.org/
a
http://wiki.openstreetmap.org/index.php/Cz:Main_Page
http://wiki.openstreetmap.org/index.php/WikiProject_Czechia

Myslím, že česká komunita, mapující naši republiku v projektu
OpenStreetMap, by uvítala jakákoliv, případně i mírně generalizovaná
(znepřesněná) data, případně jakoukoliv formu licence k jejich použití
nebo vytvoření odvozeného mapového díla. Věříme, že tato a ostatní data
z projektu by byla v budoucnu dobře použitelná i pro Vaše zaměstnance
(podklady pro plány, prezentace, plánování či navigaci atp.), neboť je
lze exportovat přímo z centrálního úložiště v mnoha dostupných formátech
(mj. pro Garmin GPS atp.).

Děkuji za jakoukoliv odpověď, s pozdravem

Martin Kokeš
Dašická 1253
53003 Pardubice
tel. 777 136 677




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


Re: [Talk-cz] Možnost využití dat Povodí La be

2008-10-21 Tema obsahu Martin Kokeš
Petr Nejedly napsal(a):
 Tomas Kolda napsal(a):
   
 Klidne se toho ujmu, jaky source tomu chcete priradit?
 

 Že by source=pla:dibavod?
 Nicméně: V případě tisku si zpracovatel vyhrazuje uvedení copyrightu na 
 vytištěném
 listu takto: (c) Zpracováno s použitím dat Povodí Labe, státní podnik

 Toto je podmínka, kterou těžko v OSM splníme. To by chtělo vyjasnit.

 Zdroj: http://www.pla.cz/planet/ram.aspx?id=21
   
Další otázkou je zda nezkusit využít přímo DIBAVOD celý.
http://www.vuv.cz/oddeleni-gis/17/o-projektu-dibavod.html

MK



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


  1   2   >