Re: [Talk-cz] Dalsi preklady wiki a znaceni lesa
POZOR! To že nějakou cestu (například polní či pěšinu vychozenou od chodců) užívají také jezdci na koních, kdy pro ně není přímo vyhrazená ani dle okolností převážně pro ně určená (je řádně užívána i jinými druhy provozu), ještě automaticky neznamená, že se jedná o vyhrazenou stezku pro koně! ...kdepak se to tam vzalo? Bridleway by mela byt stezka pro kone / pesi /kola, ne _vyhrazena_ stezka pro kone. *** To se tam objevilo zvjevně kvůli tobě ;) Protože když si ještě mapovával, všechno kudy jsi projel na koni bylo u tebe bridleway. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Mapa obce
http://wiki.openstreetmap.org/wiki/OSM_on_Paper h. Dne 2. června 2015 20:05 2nd 2...@centrum.cz napsal(a): Ahoj ci dobry den, mimojine pracuji pro osadni vybor v me obci a libila by se nam mapa obce do zasklene vitriny ve formatu A3: poradte prosim jak nejlepe vyexportovat mapu nejlepe v levelu 19 (mapnik), abych to nemusel slepovat v Gimpu :) Dekuji za jakekoliv podnety a pripominky ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] Měření statické přesnosti přijímačů GPS
Ahoj, možná to tu někoho zaujme - cvičně mě zajímalo jak přesné jsou přístroje v mém dosahu, tak jsem to zkusil a mrskl na web: Měření statické přesnosti přijímačů GPS http://gis.templ.net/measure_gps-web2.xhtml ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] ŘOPíky
Nikde, a jak to chcete vyřešit? nechat duplicity? Před importem jsem se ptal, jak se řeší duplicity, nikdo 2 dny neodpověděl. *** Je vhodne nechat na dulezita rozhodnuti jako import klidne 14 dni. To jsme myslim s tebou jednou diskutovali... Je tak neprekonatelne? ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Přebírání dat od měst
nevím zda se to tu již řešilo, ale zeptám se. Pokud dá nějaké město (v tomto případě Plzeň) souhlas s odvozováním ze svých mapových podkladů, jaké formality je k tomu potřeba splnit? Někde to nahlásit či stačí obecné info z jejich strany, že je to možné? Na Wikipedii se převzaté články hlásí do nějakého systému. *** pokud jen odvozování z cizí mapy pak jen zmínit tady: http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap *** pokud by šlo o automatizovaný (strojový) import tak navíc ještě dle návodu zde: http://wiki.openstreetmap.org/wiki/Import/Guidelines *** ze strany majitele dat (gestora) je třeba nějaký dobropis, e-mail, dopis, licence, zákon nebo metadata, kde je váš záměr potvrzen implicitně nebo explicitně jako legální. Pokud by šlo o legalitu z podstaty obecného dokumentu (zákon, licence), pak je vhodné zdůvodnit výklad. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] FW: Chybná evidence budov bez čp/čev, Kelč-Nové Město [664758]
Pane Souček, a že jsem tak smělý a je ten advent, mimo toto téma. ;) Rád bych zopakoval svoji otázku z 12.6.2014, jakou transformaci používá KÚ na RUIAN/KM pro publikaci dat z S-JTSK do WGS-84 a do ETRS89-ETRF2000 a případně mezi ETRS a WGS? zdraví hanoj Dne 16. prosince 2014 18:32 Petr Souček souc...@atlas.cz napsal(a): Dobrý den, předávám pro informaci vyřešený jeden případ. Už se těším až domluvíme nějakou automatizovanou linku :-). Petr Souček From: - Sent: Monday, December 15, 2014 4:53 PM To: Souček, Petr Subject: RE: Chybná evidence budov bez čp/čev Dobrý den, Budova prověřena, def. body v RUIAN odstraněny, oprava provedena v Z-4001/2014-836 (bude zplatněno zítra), OR-411/2014. Děkujeme za upozornění. Pěkný den From: Souček, Petr Sent: Wednesday, December 03, 2014 11:41 AM To: .Valašské Meziříčí-podatelna Subject: Chybná evidence budov bez čp/čev Dobrý den, prosím o prověření evidence budov bez čp/čev, které jsou evidovány na pozemcích 462/1, 462/2 a 462/3 v katastrálním území Kelč-Nové Město [664758]. V ISKN jsou evidovány tři samostatné budovy na třech samostatných parcelách. Z mého pohledu by měla být evidována pouze jedna budova na třech parcelách. Viz ukázka z Nahlížení do KN http://sgi.nahlizenidokn.cuzk.cz/marushka/default.aspx?themeid=3MarUid=7E6595D2%20A5AD9D88%204236F7E7MarUidi=4236F7E7MarMiddlePoint=-506799.365%20-1138173.74MarScale=694 Děkuji za prověření a přeji pěkný den Petr Souček ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Mapování železnic - rozšířené schéma
Ahoj, super práce. Jen se mi to zdá tak komplexní, že pro běžnou praxi prostého uživatele je to neuchopitelné. Ale když základní věci vtělíš do Cz:Map features případně cz /Editing standards tak to snad nějaké ovoce přinese. díky hanoj Dne 12. prosince 2014 15:31 Michal Pustějovský michal.pustejov...@seznam.cz napsal(a): Dobrý den, už nějakou dobu se věnuji překladu tagovacího schématu železniční (resp. kolejové) dopravy z OpenRailwayMap (http://www.openrailwaymap.org/; schéma http://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging). Jedná se o schéma vytvořené německou komunitou k přesnému, systematickému a logickému způsobu popisu tamní železniční sítě. Už nyní je v Německu a Rakousku hojně využíváno. Základem schématu je rozšíření dosavadních tagů a způsobů mapování o další detaily. V několika případech je ale zavrhuje, ovšem vždy z dobrých důvodů, které jsou vysvětleny. Rád bych tímto modelem nahradil současný způsob značení českých železnic, který je zastaralý a nekonzistentní. Součástí textu jsou i poznámky a návrhy týkající se věcí, které bych chtěl projednat s komunitou. S radostí uvítám případné dotazy, připomínky, návrhy nebo kritiku. V části týkající se kolejí se jedná prakticky pouze o rozšíření o další specializované tagy, které např. řeší routing. Hlavní změny nastávají v části popisující nádraží a zastávky, kde se snaží skloubit zažité tagování veřejné hromadné dopravy (railway=station atd.) a nový public_transport. Menší změny jsou i v typech relací popisující trasy jak dopravy, tak i dopravní cesty a infrastruktury. Překlad je zde (dostupný zatím pouze odkazem): https://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/railway_tagging. Nejedná se pouze o překlad, ale spíše adaptaci modelu na české prostředí. Přidávám i návrhy hodnot u klíčů typu operator nebo network. Snažím se v poznámkách také komentovat, co by adaptace pro danou oblast znamenala pro současný stav. Překlad není kompletní, protože původní schéma je opravdu až zbytečně detailní, např. obsahuje značení pro železniční signalizaci, podrobný popis systému elektrifikace apod. Pokud by nikdo nebyl proti, nahradil bych tímto schématem kapitolu o železnici v Editting Standards pro ČR. Současně bych začal pracovat i na příkladech. Nakonec bych uvedl, že neexistuje žádná podobně propracovaná alternativa a že toto schéma se již v zahraničí používá. Těším se na příp. dotazy, Michal ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Róbert Althap_Mendelu_Bakalárka_Import_do_osm
Dobrý deň, v rámci mojej bakalárskej práce na Mendelovej univerzite v Brne sa venujem importu geodát do databáze OSM. Momentálne možnosti, ktoré mi boli predložené je na importovať dáta z registra živnostníkov, konkrétne som zameraný na čerpacie stanice, pobočky a poprípade ceny palív alebo potom ohľadom turistických značiek. *** Ahoj, takové záměry vítáme. Než začneš něco vkládat do OSM, zašli nám ukázky dat a před koncem finální verzi dat k importu, aby komunita mohla ověřit, že je to co bude hromadně přijato je posun vpřed. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Osmose Česká republika
A vzhledem k tomu, že to má stejné podmínky užití, jako prohlížení KM, tak by to mohla být i pravda. No to by byla bomba. *** KM má svůj vlastní zákon a zabývá se jím Katastrální úřad. ZABAGED a orto spravuje Zeměměřičský úřad. Tím ale nechci tvrdit, že se nám současné paradigma zakázaného zdroje nemůže podařit zlomit třeba cestou 106/1999, viz 106/1999. Já ale nejsem sto se tomu věnovat. https://www.youtube.com/watch?v=rf_7MeEVmko ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Osmose Česká republika
Pouze potřebujeme potvrzení, že můžeme použít veřejnou prohlížecí WMS službu jako podklad pro mapování. *** myslím, že v tom má ZÚ jasno a proto potřebujeme ty snímky ;) hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Osmose Česká republika
9. prosince 2014 13:55:47 SEČ, hanoj eha...@gmail.com napsal: Pouze potřebujeme potvrzení, že můžeme použít veřejnou prohlížecí WMS službu jako podklad pro mapování. *** myslím, že v tom má ZÚ jasno a proto potřebujeme ty snímky ;) Hmmm. Jsem koukal, co by to koštovalo: 2 366 255 Kč. To asi dohromady nedáme :-( *** Za data vydane v ramci 106/1999 nelze zpoplatnit. Pripustny je pouze manipulacni poplatek souvisejici s nadmernou administraci (napr. rucni prohledavani v archivu). ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Posunutá mapa?
Nejsem v tomhle uplne kovany a mozna nekdo typu Hanoje bude vedet vice, ale osobne se domnivam, ze hlavni problem souvisi s modelem terenu. *** jsa vyzvan, ne kovan, naznacim sve zapadle znalosti z predmetu Dalkovy pruzkum zeme. a) pokud vas zajimaji metody a postupy zpracovani leteckych/druzicovych dat hledejte na googlu heslo ortorektifikace, praktickych zkusenosti je publikovano dost. Třeba i hodnocení kvality ASTER GDEM na uzemi CR: http://www.gisat.cz/content/cz/dpz/zpracovani-dat/digitalni-vyskove-modely b) add problemy Bing orto Bing stejne jako ostatni globalni vyhledavace/portaly kupuji pro CZ druhotne druzicove snimky, protoze jsou vyrazne levnejsi. Uz jsou vyrobeny po nekoho jineho, casto i jiny ucel nez vyuzivame my. Mohou mit nizsi naroky na vysledek tj. sirku zaberu, pocasi, rocni obdobi. Na mape bingu se tak kombinuji ruzne snimky ruznych kvalit nejen pro ruzne zoomy ale i v ramci zoomu. Ve srovnani s lokalnimy leteckymi ortofotomapami na mapy.cz nebo CUZK je vysledek patrny na prvni pohled. * horsi uspesnost vlicovani (2D napasovani) * nizsi rozliseni (podrobnost) * globalni vyskovy model (3D napasovani) * sirka zaberu (vliv na uklon budov a stineni) * uklon zaberu (kolmy pohled nemusi existovat) ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Preklad terminu o mostech?
Ahoj, v česku pro to analogie moc nejsou: http://wiki.openstreetmap.org/wiki/Proposed_features/Bridge_types#Proposal - bascule *** sklápěcí - transporter *** dopravník - lift_pier - pivot_pier *** zdvihací a otočný pilíř ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Problemy s ulicema a budovama
1. V Pardubicích mám čtyři budovy vedle sebe a na každé z nich dva adresní body ( http://www.openstreetmap.org/way/264919783 ) . Po terénu jsem zjistil že body ze zdroje ref:ruian:addr=* (zleva číslovány 2740) jsou vpořádku a ty ze zdroje source:addr=mvcr:adresa jsou špatně. Můžu ty chybné v tomto případě smáznout? Co s tím kdyby to bylo opačně? *** možno smazat adresní body z mvcr:adresa. Ty jsou polohou často posunuté, protože často vznikly interpolací sudé a liché sady čísel podél linie ulice. 4. V OSMI je jasně vidět ke které již pojmenované ulici směřují které adresní body. Můžu bez místního terénu přiřadit jméno slepé ulici která směřuje z již pojmenované ulici a není v RUIAN když je znatelné že všechny k ní přilehlé budovy mají stejnou ulici? A stejně i u budov dál za vesnicí u hlavní silnice která je pojmenována stejně jako ty budovy ale zase čára dle RUIAN není až k nim? *** určitě pojmenovat. Pokud se nemylim do RUIAN definici geometrie vklada stavebni urad obce, což nemusí vždy vést k úspěchu. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] WMS TMS vrstvy do JOSM
pridáno na wiki: +RUIAN budovy, RUIAN parcely, pLPIS - uhul:ortofoto ha hanoj Dne 15. září 2014 21:30 Petr Schönmann pschonm...@gmail.com napsal(a): Ahoj, chtěl bych se optat zda by někdo nepřidal do výchozích podkladů JOSM České WMS / TMS http://josm.openstreetmap.de/wiki/Maps/Czech%20Republic Udělal bych to sám, ale nejsem si vůbec jistý zda by tam seděli projekce, nevyznám se v tom :) Navrhoval bych dodat tam RUIAN, Pozemky RUIAN, pLPIS + co volného vás napadne. ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] cyklostezky a pěškaři
Používám pro plánování cest GraphHopper na vlastním serveru. Většinou plánuji pěší cesty (config: osmreader.acceptWay=car,foot; ve web url: vehicle=foot). Bohužel uvedené se vyhýbá stezkám pro chodce, které jsou zároveň stezkami pro cyklisty - v OSM však u těchto cest schází tag: foot=designated (respektive foot=yes) a je tam jen highway=cycleway. *** A není to spíš problém interpretace než tagování? Chodec může na každou highway vyjma dálnice a silnice pro motorová vozidla a většina z nich nemá foot=yes/designated... ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] cyklostezky a pěškaři
*** A není to spíš problém interpretace než tagování? Chodec může na každou highway vyjma dálnice a silnice pro motorová vozidla a většina z nich nemá foot=yes/designated... Pokud je cesta značkovaná jen takto: highway=cycleway Může tam chodec? Dle této tabulky: http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions Chápu, že defaultně ne. *** máš pravdu. Možná je jen české specifikum, že cycleway vyhrazené jen pro cyklisty jsou zcela okrajové. hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Relations - sousední obce (kraje, okresy) z API
jak píše xificurk, asi takto: http://overpass-api.de/api/interpreter?data=(rel[name=okres Brno-město][admin_level=7][boundary=administrative];way(r);rel(bw))-.c;(rel.c[admin_level=7][boundary=administrative];way(r);node(w))-.d;.d out meta; výklad syntaxe např. zde: http://geoinformatics.fsv.cvut.cz/data/2014/06-12/03-Barta-Geoinformatics-2014.pdf#page=26 ha hanoj Dne 18. srpna 2014 1:01 Petr Morávek [Xificurk] p...@pada.cz napsal(a): Dne 18.8.2014 00:20, Jiří Sedláček napsal(a): Dobrý den, ahoj, mám poměrně specifický požadavek na API (či případně na jiný zdroj) a nevím, jak se správně zeptat API (či třeba RUIANu). Chtěl bych získat: Obce (či okresy, ...) tak, abych zjistil, která další obec (či okres, ...) s ní sousedí. A to ideálně tak, abych si mohl vybrat obce jen z daného okresu (a to je pro mě největší problém a nijak jsem nedokázal donutit API, aby mi vrátila jen data z daného okresu dle ref nebo id relace). Pokud bych získal data dle BBOXU, tak je to sice hezký, ale nebude to ono - nicméně, i pak mi asi nezbyde nic jiného, než projít jednotlivý relace a jejich ways a dle toho, že ways jsou ve více relacích poznat, že spolu ty dané obce sousedí. Nebo to jde i jinak? Díky za radu či nakopnutí. J. -- S pozdravem, Jirka Sedláček --- jirisedla...@gmail.com mailto:jirisedla...@gmail.com Ahoj, tohle by mělo být řešitelné pomocí Overpass API. Zkonstruování konkrétního dotazu už nechám na tobě, ale postup by měl být zhruba takovýto: 1) Podle jména, id, nebo čehokoliv jiného najít relaci obce (okresu, ...) 2) Najít všechny cesty, které relace odkazuje. 3) Najít všechny relace, ve kterých jsou tyto cesty a vyfiltrovat je pomocí požadovaného admin_level. 4) Příp. stáhnout všechny cesty/uzly, které jsou součástí těchto relací. Zdraví, Petr Morávek aka Xificurk ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] návod Tracer LPIS
Díky,
zdá zdá se, že problém byl v tom, že se lokální Tracer.jar tloukl s
Tracer.jar z repozitáře JOSM. Tak jsem
http://www.kyralovi.cz/tmp/josm/beta/lpis/Tracer.jar přejmenoval na
TraceR.jar.
Tracer nad LPIS mi jede, nad RUIAN ne (pro požadavku na trace hlásí nodata).
Přiřazování tagů landuse apod LPIS se dělá ručně? Nelze to nějak
naparsovat z dotazu krze GetFeatureInfo nebo wfs?
PS: Mariane pěkná práce.
ha
hanoj
Dne 17. srpna 2014 22:32 Petr Schönmann pschonm...@gmail.com napsal(a):
Stáhneš tracer od Mariána http://www.kyralovi.cz/tmp/josm/beta/lpis/Tracer.jar
soubor uložíš do adresáře kde má josm konfiguraci tam do adresare
plugins. Doporucuju tam mit posledni tracer . jestli tam mas nejaky z
minula tak ho smaz ( at tam je jeden tracer.jar )
Linux ~/.josm/plugins
Win7 c:\Users\uzivatel\AppData\Roaming\JOSM\plugins
Spustis JOSM, otevres nastaveni, zaskrtnes tracer plugin ( ten ktery
ma i v lokalni verzi cislo ) + dalsi pluginy geotools a jts (
potrebuje je )
Az se ti nainstaluji otevres znovu preference a mas tam zalozku kde si
zvolis moduly ( zaskrtnes lpis )
Pak uz jen pridat zdroje map WMS a TMS
wms:http://eagri.cz/public/app/wms/plpis.fcgi?FORMAT=image/pngVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLAYERS=LPIS_FB4_KODSTYLES=SRS={proj}WIDTH={width}HEIGHT={height}BBOX={bbox}TRANSPARENT=true
tms:http://tile.poloha.net/budovy/{zoom}/{x}/{y}.png
Dne 17. srpna 2014 21:53 hanoj eha...@gmail.com napsal(a):
Ahoj,
je někde popsán postup, jak zprovoznit Tracer s CUZK, LPIS a RUAIN na
čistém JOSM vč. nastavení odpovídající podkladové vrstvy WMS/TMS a
trace-serveru?
Ze starých mailů jsem něco nevyčetl, ale ne k fungujícímu stavu.
díky
hanoj
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] návod Tracer LPIS
jasne je to -Dfile.encoding=UTF8
hanoj
Dne 18. srpna 2014 9:57 Marián Kyral mky...@email.cz napsal(a):
No ještě na tom pracuji. Teď (opět) řeším napojování ploch. Nějak to ne a ne
fungovat podle mých představ. Teď už to snad bude dobře, jen to potřebuji
odladit a o víkendu jsem, oproti původnímu plánu, nebyl vůbec doma.
Tagy by se měly přiřadit, ale u některých ploch je na windows problém se
znakovou sadou Jako workaround stačí spouštět josm s parametrem
-Dfile.encoding=UTF8
Ad RUIAN - určitě klikáš do budovy, kde jsou ruian data? A máš přepnutý
režim na RUIAN? (přepíná se to pomocí klávesy t).
Když tak pošli detaily - bod na který klikáš a co píše JOSM do konsole.
Jinak plánuji, že až to dostatečně odladím, tak dopíši wiki dokumentaci a
aktualizuji Tracer plugin v JOSM repository, takže pak nebude třeba to
instalovat extra. Ale kdy to bude zatím netuším.
(No a pak by to ještě chtělo LPIS mód do PointInfo pluginu ;-) )
Marián
-- Původní zpráva --
Od: hanoj eha...@gmail.com
Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org
Datum: 18. 8. 2014 9:39:49
Předmět: Re: [Talk-cz] návod Tracer LPIS
Díky,
zdá zdá se, že problém byl v tom, že se lokální Tracer.jar tloukl s
Tracer.jar z repozitáře JOSM. Tak jsem
http://www.kyralovi.cz/tmp/josm/beta/lpis/Tracer.jar přejmenoval na
TraceR.jar.
Tracer nad LPIS mi jede, nad RUIAN ne (pro požadavku na trace hlásí
nodata).
Přiřazování tagů landuse apod LPIS se dělá ručně? Nelze to nějak
naparsovat z dotazu krze GetFeatureInfo nebo wfs?
PS: Mariane pěkná práce.
ha
hanoj
Dne 17. srpna 2014 22:32 Petr Schönmann pschonm...@gmail.com napsal(a):
Stáhneš tracer od Mariána
http://www.kyralovi.cz/tmp/josm/beta/lpis/Tracer.jar
soubor uložíš do adresáře kde má josm konfiguraci tam do adresare
plugins. Doporucuju tam mit posledni tracer . jestli tam mas nejaky z
minula tak ho smaz ( at tam je jeden tracer.jar )
Linux ~/.josm/plugins
Win7 c:\Users\uzivatel\AppData\Roaming\JOSM\plugins
Spustis JOSM, otevres nastaveni, zaskrtnes tracer plugin ( ten ktery
ma i v lokalni verzi cislo ) + dalsi pluginy geotools a jts (
potrebuje je )
Az se ti nainstaluji otevres znovu preference a mas tam zalozku kde si
zvolis moduly ( zaskrtnes lpis )
Pak uz jen pridat zdroje map WMS a TMS
wms:http://eagri.cz/public/app/wms/plpis.fcgi?FORMAT=image/pngVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLAYERS=LPIS_FB4_KODSTYLES=SRS={proj}WIDTH={width}HEIGHT={height}BBOX={bbox}TRANSPARENT=true
tms:http://tile.poloha.net/budovy/{zoom}/{x}/{y}.png
Dne 17. srpna 2014 21:53 hanoj eha...@gmail.com napsal(a):
Ahoj,
je někde popsán postup, jak zprovoznit Tracer s CUZK, LPIS a RUAIN na
čistém JOSM vč. nastavení odpovídající podkladové vrstvy WMS/TMS a
trace-serveru?
Ze starých mailů jsem něco nevyčetl, ale ne k fungujícímu stavu.
díky
hanoj
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Změna ve vykreslování tramvají na silnici (?)
Dne 17. srpna 2014 21:35 Jan Martinec j...@martinec.name napsal(a): Dne 08/17/2014 v 07:31 PM Michal Pustějovský napsal(a): Ano, oddělování tramvají od silnic v Ostravě (komplet) a v Brně (napůl dokončeno) je moje práce. Uvažoval jsem o tom už delší dobu, ale nový způsob renderování mapniku mě k tomu tak říkajíc dokopal. Podle toho co vím, tak na cestách s kombinací highway+railway mapnik nově vykresluje highway NAD railway. Jinak se nic nezměnilo. Dle wiki jsou povolené oba způsoby tagování, ale doporučuje se ten se zvláštními cestami pro highway i railway. To dává smysl tam, kde jde o oddělené cesty (nebo alespoň oddělené pruhy); ale oddělovat tramvaj od zbytku silnice např. v Křižovnické v Praze smrdí mapováním pro konkrétní renderer. *** myslím, že v tomto vlákně nejde o 2(3) paralelní way, ale o 2 way na identických nodech. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] návod Tracer LPIS
Ahoj, je někde popsán postup, jak zprovoznit Tracer s CUZK, LPIS a RUAIN na čistém JOSM vč. nastavení odpovídající podkladové vrstvy WMS/TMS a trace-serveru? Ze starých mailů jsem něco nevyčetl, ale ne k fungujícímu stavu. díky hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import of farmland from LPIS
On Tue 2014-07-22 15:40:32, hanoj wrote: The data are freely available to anyone by law as they were created by government agency using tax payers' money. There are no copyrights on the data. The basic registers are created according to the Lawe No. 111/2009 Sb.. The possibility of extraction and use of data for OSM is based on § 62 of Law 111/2009 Sb. Sorry, we are not aware of any English translations of Czech laws. *** Ehm, a na to jsi přišel jak? Ty data poskytuje Ministerstvo Zemedelstvi, AFAICT, takze jak by to melo byt jinak? *** Zacal bych tim, ze si ten odkazovany zakon prectes. Ve skutecnosti je to uplne jinak: http://www.zakonyprolidi.cz/cs/1997-252#p3ab-2 http://www.zakonyprolidi.cz/cs/2000-121#p3-1-a hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import of farmland from LPIS
The data are freely available to anyone by law as they were created by government agency using tax payers' money. There are no copyrights on the data. The basic registers are created according to the Lawe No. 111/2009 Sb.. The possibility of extraction and use of data for OSM is based on § 62 of Law 111/2009 Sb. Sorry, we are not aware of any English translations of Czech laws. *** Ehm, a na to jsi přišel jak? ha hanoj 2014-07-22 15:28 GMT+02:00 Pavel Machek pa...@ucw.cz: Hi! I'd like to start import of LPIS farmland database, as we have very good coverage of houses, forests and water, but farmland is very good at places and completely missing at different places. Import page is at https://wiki.openstreetmap.org/wiki/LPIS , import script is attached to this email. Best regards, 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 https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Co s adresami na POI
Jestliže je tedy odpor (jako že je) vůči mazání adres na POI, nebudu si POI všímat vůbec. Kdybych si jich všímal a pracoval s nimi, mohlo by docházet k jejich posunu a to u obchodů asi není dobré. *** Odpor tu byl, ale nebylo navrženo jiné řešení než nic nedělat, což mne mrzí. Takže budu-li proti tomuto odporu, diskuze se vzájemně vyruší ;) ? Také je zřejmé, že jindy znamená nikdy. A teď k věci. Z 53 000 POI (node.shop+node.amenity) má adresu 5%, takže použití této vazby je v hypotéze její potřebnosti prakticky k ničemu. Kdežto funkční, referenční a jednotný a aktualizovatelný systém adres můžeme mít letos. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Úvaha o poloze adresního bodu (co PŘESNĚ je definiční bod?)
Osobně bych byl spíš za schopnost nástrojů zachovat adresu na poi, protože... Ty obchody ve skutečnosti žádnou adresu nemají. Adresa je - jak psal hanoj - místo v terénu vztažené ke *stavebnímu objektu*. ...toto je sice formálně zcela správně, ale v realitě tam venku obchod lokalizuje právě adresa - nikdo si nepíše souřadnice :-D *** myslíš adresu sídla podnikání, místa podnikání nebo sídla pobočky? *** jak charakterizuje POI jeho adresa v nákupním centrum, obchodním domě? Vazba tam tedy je, a v současných frontendech k osm se bohužel předpokládá explicitní: iD má políčka pro adresu jako součást toho co se dá/má pro poi nastavit. Nevím tedy jak moc je reálné spravit všechny ostatní lidi? *** předělávat lidi samozřejmě není nutné, stačí když robot ví co s tím ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Úvaha o poloze adresního bodu (co PŘESNĚ je definiční bod?)
(co PŘESNĚ je definiční bod?) *** příspěvek k debatě. Definice Adresního Místa dle zákona: Adresním místem je takové místo v terénu, kterému lze ve vztahu ke stavebnímu objektu přiřadit adresu http://geoinformatics.fsv.cvut.cz/data/2014/06-12/05-Formanek-Geoinformatics-2014.pdf#page=18 http://www.zakonyprolidi.cz/cs/2009-111#p29-d ha hanoj Dne 29. června 2014 12:58 Petr Vejsada o...@propsychology.cz napsal(a): Ahoj, právě mě přestává bavit přesouvat tisíce adresních bodů, které jsou posunuty o 3 domy vedle. Uvažuji o něčem, co by mělo mělo zbytek importu výrazně urychlit. Jak určíme, kde má v OSM být adresní bod? Návrh: 1.) vezmeme ho z OSM - je do 0.5m od hranic stavebního objektu? Ano, OK, bereme z OSM, není co řešit. - nejsou hranice SO, leží adresa v OSM do 3m od definičního bodu SO? OK, není co řešit - není def. bod SO? Leží v OSM bod do 3m od souřadnic AM v RUIAN? OK, není co řešit. Pokud jsme neuspěli, pokračujeme 2.) Souřadnice AM z RUIAN - jsou souřadnice AM v RUIAN do 0.5m od hranic SO? OK, bereme souřadnice AM z RUIAN - nejsou hranice SO, leží AM v RUIAN do 3m od definičního bodu SO? OK, bereme souřadnice AM z RUIAN Pokud jsme neuspěli, pokračujeme 3.) ST_Centroid hranic SO - nachází se definiční bod SO uvnitř hranic SO či do 1m od hranic? (*viz poznámka dole) OK, bereme ST_Centroid SO. Pokud jsme neuspěli, pokračujeme 4.) Definiční bod SO Pokud jsme neuspěli, bereme souřadnice z OSM. Pokud bod nemáme v OSM, máme smůlu ;-). V RUIAN jsou AM, která nemají žádné souřadnice. * poznámka: jak jsem psal, definiční bod SO může ležet jednotky či desítky km od hranic stavebního objektu. Takových chyb je v RUIAN několik stovek včetně oné rekordní 221km. Velmi podezřelých je pak asi 1500 (třeba definiční bod SO je 100 metrů od hranic). Potřebuji ovšem vědět, co je to definiční bod, tedy hlavně mě zajímá, zda definiční bod správně musí ležet na povrchu polygonu hranic. Mějme budovu ve tvaru U, pak ovšem ST_Centroid nebude ležet na povrchu polygonu. http://postgis.refractions.net/docs/ST_Centroid.html - obrázek vlevo dole. V tomto případě ST_Contains(hranice_SO,adresni_bod) vráti false. Takže asi tolerovat nějakou vzdálenost definičního bodu SO od jeho hranic? Jakou? Výsledkem tohoto postupu by mělo být, že jediná varování, která by měl řešit člověk, by byla AM blízko u sebe. Importoval bych už jen po celých polygonech, tedy obcích (včetně obcí Plzeň, Jihlava a podobných velkých měst; už jich moc nezbývá. Asi i Brno.) Proč po jasných polygonech? Protože vše, co má nějaký addr: a po tomto procesu zůstane uvnitř tohoto přesného polygonu, to bych zlikvidoval. Když se dívám na ortofoto míst, která zbudou (to jsou ty hlášky V OSM je nějaký bod s adresou podezřele blízko), pak v naprosté většině je to zbořeniště či dům, který i z leteckého snímku vypadá, že se brzy rozpadne sám. V menšině jsou to domy, svítící novotou a tak asi ještě nemají nové číslo. Tímto postupem bychom se také vyhnuli reimportu - tedy kompletnímu smazání všech adres a jejich novému vytvoření. Ten systém reimportu funguje, ale ještě jsem ho naostro nepoužil. Nakonec by zbyly oblasti, kde je velmi vysoký počet duchů uvnitř budovy, tuším, že například Mníšek pod Brdy. V těchto případech by se asi vyplatilo počkat, až budou duchové odstraněni, protože importem bychom si OSM spíš zaplevelili. Tento postup by se týkal i následných, tedy už probíhajících, aktualizací už importovaných území. Pokud je item_timestamp AM v RUIAN novější než timestamp, kdy jsme místo importovali, tak se zaktualizuje. Tak co kdo na to? -- Petr, p...@propsychology.cz p ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Aktualizace již importovaných adres
Co rada starších ;-) na variantu smazat/nahrát? *** já jsem pro, minimálně u importů hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Wikipedia a WTOSM
koukám právě na přednášku http://sotm-eu.org/en/slots/69 o spolupráci mezi Wikipedií a OSM. Zaujala mě zmínka o http://wtosm.openstreetmap.it/ což je skript, který prohledává italskou wikipedii a vyhledává všechny stránky, které mají geografické koordináty, ale nejsou linkované na Wikipedii (možná i naopak?) a umožňuje otevřít JOSM na takovém bodě. Bohužel ta stránka vypadá dost italsky … nevíte někdo o podobném projektu který by byl český nebo anglický? *** mimochodem SK projektují wiki na mapu: http://wikipedia.freemap.sk/#p=48.84583|19.15|10|A,m=AW ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] RÚIAN - budova rozdělena na několik částí
Například tyto budovy: http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/49788027 http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/42852951 Ale v bezprostředním okolí jsou ještě další tři budovy se stejným problémem. Chtěl jsem se zeptat, zda to je chyba, nebo je to z nějakého důvodu správně. Pokud je to chyba, tušíte, proč toto vzniká a jaká je šance, že se to časem opraví - sjednotí do jedné budovy? neresilo se to tu pred nejakym casem. Nakonec se ukazalo, ze to byla tusim hranice oblasti, ktera se digitalizovala do katastru, takze kazda pulka budovy se zpracovala zvlast... *** Urcite nejde o hranici k.u., nebo nejake historicke zmeny (je to uprostred k.u. Lubne). Ta umela hranice skrze objekt kopiruje hranici parcel a odkazuje az na hranici parcel historickych cisarskych otisku (684 a 761) [1]. ha hanoj [1] http://archivnimapy.cuzk.cz/com/1639-1/1639-1-001_index.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Nový S-JTSK grid, kdo pomůže?
obávám se že ČÚZK nemůže - ani jeden z těchto systémů nemá pod svou správou a schvalování algoritmů se týká pouze ETRS (možná bude někdo jiný vědět víc). Ale přítel Google mi hned jako první odkaz dal http://transformace.webst.fd.cvut.cz/Iframe/WGS_ETRS_iframe.htm ... *** ze je 7/14 prvkova je asi pochopitelne, ale tech klicu jsem na googlu nasel pro ruzne epochy a realizace desitky, např [1]. Takze by mi velmi pomohlo ukazat prstem, kterou verzi pouziva CUZK. nebo alespon popsat to slovne např.: ETRS89-ETRF2000 R8 epocha 2000.0 a WGS84-G1150 epocha 2000.0: [1] http://www.defensie.nl/binaries/defence/documents/circulars/2013/08/23/transformation-parameters-between-itrs-wgs84-and-etrs89/trafoparsitrs_v2013en.xls ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pLPIS a WFS - jak na to?
Odpovím si sám ;-) *** to mě těší, že si tu wiki o JTSK nakonec někdo přečte http://eagri.cz/public/app/wms/plpis_wfs.fcgi?VERSION=1.1.0SERVICE=WFSREQUEST=GetFeatureTYPENAME=LPIS_FB4BBOX=-904539,-1227290,-731680,-935232SRSNAME=EPSG:102067 Trochu jsem si s tím hrál. Našel jsem nějaký příklad, jak pomocí geotools převádět mezi projekcemi. Nějak to funguje, ale nevím, jestli dobře. *** netrap se s geografickými spouřadnicemi. Vytahej data WFS alis GML v krásně planárním systému S-JTSK a konečný výsledek pak převeď do WGS84 krze GDAL/ogr2ogr. Ještě by nás mělo před importem zajímat, co zdroj obsahuje a co ne, jaká je jeho cca přesnost, jaká je licence těchto dat, a udělat o tom zápis sem: http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Nový S-JTSK grid, kdo pomůže?
Nejprve převeďme tvé výsledky na počítačovější formu. Jestli počítám správně, tak tvé výsledky pro transformaci bez gridu jsou: ... 2.520413388 to je trochu moc, ne? 2.5 metru? *** myslím, že jsi opsal špatně jednu číslici jedné souřadnice A teď moje výsledky: 0.747197172 metru *** souhlas http://pastebin.com/eZ7Km2Mx Dejme tomu, že je posun při transformaci s gridem správným směrem a že je tedy výsledek přesnější než bez gridu. Když si dáme v JOSM přes sebe průhlednou KM a k tomu moje vrstvy budov, proč se tedy lépe kryjí růžové budovy (t.j. bez gridu) než budovy modré (t.j. s gridem) ???Růžové se lépe kryjí i s tím, co je v OSM. Znamená to, že máme vše v OSM špatně? A hlavně - co s tím dál? *** Nejprve je treba vedet co je spravne a proc. Proto jsem vznesl oficiální dotaz na CUZK ohledne transformaci. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Nový S-JTSK grid, kdo pomůže?
ano, mapové služby (jak na geoportal.cuzk.cz, tak na services.cuzk.cz - WMS i WFS nebo GML) obsahují oficiálně schválené algoritmy pro transformaci *** tak zda se, ze jadro pudla pri prevodu gridem[1] je v tom, ze tento grid dela transf EPSG:5514 - EPSG:4258 (a pribuzne), kdezto my v OSM pouzivame EPSG:4326 (a pribuzne) a chybi nam popsat vztah EPSG:4258 a EPSG:4326 tj. ETRS89 a WGS84. Muze CUZK tento transf postup ETRS89 - WGS84 (predpokladam ze je to 7 prvkovy klic) pro aktualni verzi ETRF2000 publikovat? priklad viz: http://pastebin.com/rDgjErEt ha hanoj [1] http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres a vzdálenost AM od SO
kod| distance --+-- 51833077 | 221482.323142855 *** jedna se o tyto dva nize? Ja tam totiz problem nevidim... http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/51833077 http://vdp.cuzk.cz/vdp/ruian/adresnimista/41487770 ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import adres a vzdálenost AM od SO
Uz to vidim (UZSZ neni UKSH), mas recht. Ta geometrie so 51833077 je ukradena tomuto domu so 51474468: http://pastebin.com/G0RXydht http://vdp.cuzk.cz/vdp/ruian/stavebniobjekty/51474468 hezky ;) ha hanoj Dne 24. května 2014 22:25 Petr Vejsada o...@propsychology.cz napsal(a): Ahoj, UZSZ - vybral sis základní datovou sadu. Ta polygony neobsahuje, je třeba použít sadu UKSH. Bez ohledu na to, zda DKM v Klatovech je či není, tak soubor 20140430_OB_555771_UKSH.xml.gz tam ten polygon prostě má a leží v Poličce. http://pastebin.com/6SeTEnUb Dne So 24. května 2014 21:56:59, hanoj napsal(a): ano, to je ono. Adresní místo v tomto případě má geometrii a ta je shodná s definičním bodem. Až na tu maličkost, že hranice, tedy vlastní polygon budovy, se nenachází v Klatovech, ale 221km odsud, v Poličce. *** IMHO so 51833077 polygon budovy nema: http://pastebin.com/AvUQxjvf http://vdp.cuzk.cz/vymenny_format/soucasna/20140430_OB_555771_UZSZ.xml.gz k.ú. Klatovy, kam Kal č.p.25 spadá nemá ještě DKM, tudíž ani polygony v RUIAN. http://vdp.cuzk.cz/vdp/ruian/katastralniuzemi/665797 ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Nový S-JTSK grid, kdo pomůže?
stejný výsledek (až na poslední platnou číslici v délce - mě to dává na konci 5016 místo 5017) dostanu z té konfigurace, kterou jsme testovali. *** ano to je v pořádku, to jsme daleko za číslicí přesnosti transformace, max. 10 místo. Udělal jsem to znovu - http://ruian.poloha.net , vrstva je http://tile.poloha.net/budovy-grid/. Je to úplně stejně špatně jako při prvním pokusu. Jakoby byl ten posun otočený. *** Já ti nerozumím, mluv čísly souřadnic a příkazovou řádkou, SQL dotazy, ne obrázky dvou map s různou transformační chybou Vezmeme si bod Jablunkov Navsi [1], kde má být chyba s globalnim klicem az 0,7m [2]: 000937190090 ETRS-89: B=49 34 25.6508 L=18 47 38.2211 H(el.)=561.77 S-JTSK: Y=436231.78 X=1133608.56H(Bpv)=519.20 nyni transformujme globalnim klicem[3]: echo -436231.78 -1133608.56 | cs2cs +init=esri:102067 +towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 +to +init=epsg:4326 18d47'38.2E49d34'25.631N 41.921 nyni transformujme gridem[4]: echo -436231.78 -1133608.56 | cs2cs +proj=krovak +ellps=bessel +nadgrids=jezek_czech08.llb +to +proj=longlat +datum=WGS84 18d47'38.222E49d34'25.65N 0.000 To znamena o 2 setiny lepsi vysledek s gridem pro oboje souradnice, tj. cca 40 a 50 cm pro lat/lon posun na SV. A to zda se koresponduje s i s tvym vysledkem na mape tj. posun na SV. Nerozumím větě z odkazovaného webu: Problém se znaménky a případným přehozením os je věc samotného zobrazení (+proj=krovak) a tedy stále zůstává. Pro souřadnice vztažené k osám ve směru 'sever východ' (záporné hodnoty) lze přidat parametr +czech a používat Proj.4 ve verzi větší než 4.5.0. *** celkem není třeba rozumnět, to se použije jen když lezou zcela nesmysné výsledky v řádech 10^6 metru Proj mám 4.8, co že to udělá ten parametr +czech ? Přidat +czech do definice a mělo by se to posunout žádoucím směrem? Tápu :-( *** ne, nic nepřidávat, taky mám proj 4.8 ha hanoj [1] http://dataz.cuzk.cz/gu.php?1=372=193=0094=astamp=3eZrAviURcutu2rKsp9slPcCYmOfccCL [2] http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Chyba_p%C5%99i_transformaci_z_WGS84_do_S-JTSK [3] http://freegis.fsv.cvut.cz/gwiki/S-JTSK#S-JTSK_.E2.86.92_WGS84 [4] http://freegis.fsv.cvut.cz/gwiki/S-JTSK_/_Grid#Pr.C3.A1ce_s_gridem ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Nový S-JTSK grid, kdo pomůže?
díky. To je ten stejný grid, jako měl schovaný Xificurk, binárku. Ten jsme
přeci zkoušeli a dopadlo to špatně. Jevilo se to jakoby ten grid korigoval
obráceně, na opačnou stranu, ale ani tak to nesedělo. Bez něj to vypadá
přesněji vůči KM. Viz archiv konference.
*** Co jste věcně zkoušeli a jak to odpadlo jsem v archivu nevyčetl,
nebo nepochopil, PostGIS není moje parketa, ale:
bash:
wget http://gis.templ.net/grid_jezek2008/jezek_czech08.llb
sudo cp jezek_czech08.llb /usr/share/proj
postgres:
INSERT INTO spatial_ref_sys(srid, auth_name, auth_srid, srtext, proj4text)
VALUES (999, 'jezek', 999, 'NULL', '+proj=krovak +ellps=bessel
+nadgrids=jezek_czech08.llb');
#Dotaz probehl úspešne: bylo ovlivnený 1 rádek
SELECT ST_AsText(ST_Transform(ST_GeomFromText('POINT(-718583.33
-949224.46)',999),4326)) As wgs_geom;
#POINT(14.5808761364013 50.9523314825017)
což dává očekáváný výsledek
ha
hanoj
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Nový S-JTSK grid, kdo pomůže?
Ahoj, na základě teorie i výpočtů konstatuji, že dříve dostupný grid Ježek2008 (jehož kopie je opět na odkazu níže dostupná) je do doby novějšího oficiálního řešení možno používat pro běžné potřeby OSM za účelem zvýšení přesnosti transformace S-JTSK - WGS84. více viz tento odstavec: http://jdem.cz/ba4eu7 ha hanoj Honza Jezek mi psal, ze ma studenta, ktery pracuje na novem gridu, doufam, ze se dozvime vic na Geoinformatics ... ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pLPIS a WFS - jak na to?
Tak jsem měl teď přes oběd trochu času a koukal jsem na WFS. Základní URL: Prvních 200 položek: No a s tím mám jen dva (dost podstatné ;-) ) problémy *** a což zkusit project ID? http://eagri.cz/public/app/wms/plpis_wfs.fcgi?VERSION=1.1.0SERVICE=WFSREQUEST=GetFeatureSRSNAME=EPSG:102067TYPENAME=LPIS_FB4featureID=LPIS_FB4.8780373 nebo BBOX? http://eagri.cz/public/app/wms/plpis_wfs.fcgi?VERSION=1.1.0SERVICE=WFSREQUEST=GetFeatureTYPENAME=LPIS_FB4BBOX=-904539,-1227290,-731680,-935232SRSNAME=EPSG:102067 ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Nový S-JTSK grid, kdo pomůže?
Mám celou databázi polohového bodového pole TB, ZhB a CZEPOS v ETRS89(ETRF2000) S-JTSK, nechtěl by mi někdo, kdo se víc orientuje v GDAL (Jáchym Čepický?) pomoci vytvoři nový nadgrid ntv2? *** ten grid je už spočtený, jen je třeba ho převést do správného formátu pro GDAL. http://www.cuzk.cz/Zememerictvi/Geodeticke-zaklady-na-uzemi-CR/GNSS/Nova-realizace-systemu-ETRS89-v-CR.aspx ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Dotaz k významu bicycle:yes
Dne 18. dubna 2014 21:22 Pavel Cvrček jasnap...@jasnapaka.com napsal(a): V takovém případě mi to ale nedává moc smysl. To bych mohl tento tag vyznačit ke každé lesní cestě, polňačce či klidně asfaltce. Jak by pak vypadala mapa na OpenCycleMap? *** ja ten tag bicycle=yes z track i path zpravidla mažu protože zde nemá smysl a často je vložen díky presetům. Je to podobné jako maxspeed=90 a highway=primary, prostě CZ default. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] [Adresy] Informace o stavu vyjednavani
rádi bychom vás senámili s postupem debaty ohledně importu adres z RÚIAN. *** dobrá práce ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Společná stezka pro chodce a cyklisty
jak se taguje Společná stezka pro chodce a cyklisty - auta tam až na dopravní obsluhu nesmí je to cycleway nebo poraďte sím něco lepšího. *** takto: highway=cycleway foot=designated bicycle=designated segregated=yes/no ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] cestni sit uhul
já jsem trochu mimo obor, může mi někdo (, Jelene, ) říct, v jaké datové sadě UHUL jsou lesní cesty? Že je UHUL v nějaké formě má a že by je mohl uvolnit pro OSM, o tom se mluvilo už dlouho, ale zatím nic. Chtěl bych zjistit, co by obnášelo si o ně zažádat (podle 106ky? autorského zákona - resp. jako o 'úřední dílo'? nějaký tip?) *** mozna odvozni cesty maji slouzit jako lakmusovy papirek, ale zrovna ty jsou tak nepresne, ze jeji informacni hodnota je vyuzitelna v OSM je asi tak: v tomhle lese je/neni odvozni cesta. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Geoportál Praha - to mi hlava nebere
Data jsou poskytována zdarma, platí se pouze manipulační poplatek za jejich výdej. Jeden by si řekl, že je to pochopitelné, že DVD něco stojí a práce s tím je, ale už je méně pochopitelné, že data musím následně zabezpečit proti zneužití - ??? co to sakra má být? - a nesmím je poskytovat dál. Takže dokonce ani nesmím pomoci naší obci s distribucí dat a pomoci jí tak snížit náklady na výdej dat? !?! To je výsměch a zakrývání skutečnosti, že data fakticky prodávají, i když to prezentují jako zdarma. *** OSM poskytuje volne data, ale podminky licence ODbL. Praha poskytuje volne data ale za licencnich podminek, pro ktere je (v ceskem statnim prostredi) nutno uzavrit dvojstrannou dohodu, proto to fyzicke DVD. Ano bylo by krasne, kdyby ta geodata byla k dipozici nejen free ale i open. Zákon 106/1999 Sb o tom vubec nic nerika. AZ definuje uredni dilo jako resjtrik nebo listinu, o geodatech neni reci. Rad se budu mylit. ho hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Bing - nové obrázky
Dík za info, nadnárodní internetové firmy často kupují snímky družicové, již po někoho účelově nasnímané nebo archivní dříve systematicky snímané a tedy výrazně levnější. Vzhledem ke copyrightu by mohlo jít snímky družic DigitalGlobe z roku 2012 nebo o nějaký měsíc dříve dříve (příprava surových snímků také nějakou chvíli trvá). http://en.wikipedia.org/wiki/DigitalGlobe ha hanoj Dne 5. března 2014 1:09 xkomc...@centrum.cz napsal(a): jenom pro informaci: Bing přidal minimálně dva nové obrázky - první z nich je z Vysočiny, kde přibyla oblast mezi městy Chrast - Hlinsko - Žďár nad Sázavou - Jarovměřice nad Rokytnou (stále však na východě zůstává tenký proužek bez satelitního snímku) - jde o foto zimní krajiny, přepokládám tedy něco čerstvého; ten druhý je z oblasti mezi městy Ústí nad Orlicí - Česká Třebová - Svitavy - Olešnice. Tady je pokrytí nyní již kompletní. V tomto případě se jedná o snímek letní krajiny, uvolněn byl však z neznámého důvodu až někdy nyní... ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Ortofotomapa a její lokální kopie
před nějakým časem se řešilo, že nefunguje ortofotomapa. Dneska jsem ji náhodou zkusil a už je zase on-line. Problém však stále zůstává s její rychlostí: načítání trvá dost dlouho a používat ji je dost problematické. Chtěl jsem se tedy zeptat, zda-li existuje nějaký jednoduchý návod (či skript) na to, jak rozběhnout lokální kopii. Hodila by se při tvorbě oblatí, kde Bing stále nemá pokrytí... *** nevím, prošel jsem odkazy a zadnou orto nevidim http://www.uhul.cz/mapy-a-data/webove-sluzby ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Ukázkový .osm Re: Adresy z RUIAN - 2. rekapitulace
- source:position - nevím, k čemu je. Možnosti ignorovat, mazat, i nově přidaných AM přidat, ? source:position se nemaže, v případě přidávání nových bodů se přidává. *** spíše source:loc než source:position http://taginfo.openstreetmap.org/keys/source:position#combinations http://taginfo.openstreetmap.org/keys/source:loc#combinations hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Skolni projekty pro OSM
[1] http://www.fit.vutbr.cz/study/DP/BP.php?id=13454 [2] http://www.fit.vutbr.cz/study/DP/BP.php?id=15220 [3] http://www.fit.vutbr.cz/study/DP/BP.php?id=14089 *** zajimava temata, ale pokud se dobre divam, nemaji ty prace zadne on-line publikace nez text... ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] stav UHUL ortofoto
On Mon 2014-02-10 13:51:07, hanoj wrote: mate predstavu, co se stalo s UHUL:ortofoto a jestli ji budeme mit jeste dotupnou? Pokud pouziji URL prednastavene v JOSM, tedy Mam lokalni kopii UHUL:ortofoto; chvili byla i na openaerialmap. Takze kdyby byl zajem, slo by to nekde zprovoznit. Licence to tusim dovoluje. *** Zadnou licenci k UHUL:ortofoto nedisponujeme, UHUL to poskytoval na dobre slovo. I proto to bylo v rozporu s podminkami nekdejsiho openaerialmap.org http://wiki.openstreetmap.org/wiki/En:WikiProject_Czech_Republic/freemap se tvari ze UHUL ortofoto je oficialni dilo a tutiz na to zadnou licenci nepotrebujem... *** tak si přečti i druhý odstavec Overview. K této ortofotomapě žádné svolení nemáme a ani nemůžeme dostat, protože UHUL není majitelem dat. Souhlas byl dán jen na odvozování geodat. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] stav UHUL ortofoto
A neni nahodou orthofoto cuzk presne totez? Tedy tzv uredni dilo? http://geoportal.cuzk.cz/Default.aspx?mode=TextMetaside=wms.verejnemetadataID=CZ-CUZK-WMS-ORTOFOTO-PmetadataXSL=metadata.sluzbamenu=3118 Podmínky užití - zpoplatnění službyŽádné podmínky neplatí. = primo na webu povoleno zcela bezpodminecne pouzivani. *** čti dál ;) Omezení přístupu - licenční podmínky a jiná omezení Jinak AZ (dovolim si myslet, ze jde o verejnou listinu a rejstrik, pripadne uredni dokumentaci slouzici jako podklad + verejny zajem by tu jiste byl taky): 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 *** Já v citaci bohužel nevidím, že když si státní správa koupí mapu se všemi právy, je z této mapy obratem úřední dílo. Ale jednou bych se rád dožil stavu jak to mají v USA (co se zaplatí 1x z daní, už je pro všechny přístupné). a dále viz: Podobným případem je neoprávněné užití leteckých snímků (nebo jiné fotografie), ze kterých je vytvořena mapa. http://www.prf.upol.cz/fileadmin/user_upload/PrF-dokumenty/Rigo/Rigorozni_prace-VondrakovaA.pdf#page=67 ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] stav UHUL ortofoto
mate predstavu, co se stalo s UHUL:ortofoto a jestli ji budeme mit jeste dotupnou? Pokud pouziji URL prednastavene v JOSM, tedy Mam lokalni kopii UHUL:ortofoto; chvili byla i na openaerialmap. Takze kdyby byl zajem, slo by to nekde zprovoznit. Licence to tusim dovoluje. *** Zadnou licenci k UHUL:ortofoto nedisponujeme, UHUL to poskytoval na dobre slovo. I proto to bylo v rozporu s podminkami nekdejsiho openaerialmap.org ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer plugin - ruian update
Jinak co se diskutovany presnosti tejce, vidim tam posun vuci KM o cca 10 cm ... coz neni nic tragickyho, ale zajimavy to teda je. *** uz se prosim nedivme, ale chapejme: http://grass.fsv.cvut.cz/gwiki/Chyba_p%C5%99i_transformaci_z_WGS84_do_S-JTSK ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer plugin - ruian update
Ale zatím se mi podařilo proklikat jen k textu diplomky. A bohužel během té chvilky, co jsem tomu věnoval, tak jsem úplně nevykoukal, kde vzít data a co s nima krok po kroku udělat, aby nakonci vypadl grid pro celou republiku. Data budou v příloha - CD/ROM *** odpověď viz citace e-mailu níže: muzeme (OSM-cz) v tom nejak pomoci? Slo by publikovat to CD k dimplomce, nebo to v cem jsi pokrocil a zasek? Ondra Chlup (diplomant) na tom dela, pocitam, ze do tydne dame info jak to vypada. JJ. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer plugin - ruian update
Pro zajímavost bych rád věděl, co je příčinou, že to tak úplně nesedí na obrázek z katastrální mapy. Rozdíly jsou, tam kde jsem to zkoušel, asi jen v centimetrech, ale proč to není úplně přesně? Je to chyba digitalizace KM do RUIAN, nebo je to droboučká chybička při přepočtu do jiné kartografické projekce? (Posun, co máš v Nastavení tomu nepomůže, protože ten objekt je prostě jinak velkej.) To já bych taky rád věděl, protože ty fialovo-růžové dlaždice mám na svědomí. Je dost možné, že je to chyba v transformaci, protože jsem ještě neviděl dvě stejné definice srid 5514. Co člověk, to jiná definice ;-). Také i v této konferenci se dočítám, že přesná transformace není možná. *** velmi přesné globální transformace možné jsou, např. pomocí gridu, garantem pro potřeby státu je ČUZK. http://geoportal.cuzk.cz/%28S%28sjzdxw551s14nceonx1floj0%29%29/Default.aspx?head_tab=sekce-01-gpmode=TextMetatext=wctsmenu=19 http://www.cuzk.cz/Zememerictvi/Geodeticke-zaklady-na-uzemi-CR/GNSS/Nova-realizace-systemu-ETRS89-v-CR.aspx http://www.cuzk.cz/Zememerictvi/Geodeticke-zaklady-na-uzemi-CR/GNSS/Seznam-schvalenych-programu.aspx Jediný problém je v tom, že dosavadní aplikace jsou proprietární a pro FOSS není dotažené řešení do konce: http://www.kma.zcu.cz/main.php?KMAfile=./STRUCTURE/05_ebooks/04_Zaverecne_prace/zav_prace.phpDRC=./STRUCTURE/05_ebooks/04_Zaverecne_prace/DRL=CZDROF=0osCislo=52920 cituji Honzy Ježka: - Diplomka otestovala postup a výsledek byl, že metoda lze aplikovat s dostatečnou přesností, ale odovzení a finální výpočet gridu byl - vytvořen jen pro malé území. S odvozením pro celou CR jsme měli nějaké technické problémy s R, ktere se nepodarilo vcas vyresit a ted - nemam paky jak to dotahnout, ale zkouším to. Na podzim taky probehla komunikace s CUZK o odvozeni 'oficialni' verze gridu, ale v - poslední době to usnulo. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] RUIAN info
Co myslíte? *** moc tomu nerozumim, ale WMS CUZK KM má standadní GetFeatureInfo např. http://openlayers.org/dev/examples/getfeatureinfo-control.html hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Ruian jako zdroj dat
Někde u prostřed Čech to docela sedí s cuzk:km, ale třeba v Beskydech se již objevuje ochylka několika (reálných) dcm v porovnání s cuzk:km. Totéž lze pozorovat při porovnání maps.fordfrog.com a cuzk:km. Lze to nějak jednoduše odstranit? Asi by se musela změnit transformace, momentálně budovy posouvám v JOSM podle cuzk:km. http://grass.fsv.cvut.cz/gwiki/S-JTSK http://grass.fsv.cvut.cz/gwiki/Chyba_p%C5%99i_transformaci_z_WGS84_do_S-JTSK http://grass.fsv.cvut.cz/gwiki/S-JTSK-Grid ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Znaceni zakazovych znacek a dodatkove tabulky
Ahoj 1) Most s maximalni tonazi a tabulka Jedine vozidlo x tun [1]: - maxweight=28 a maxaxleload=10.8 jsou jasne, ma pak smysl jeste resit tu dodatkovou tabulku pro jedine vozidlo? Dat to alespon do note nebo comment? ja pouzivam: *** maxweight:total=80 *** ref:bridge=399-002 2) Zakaz vjezdu vsech motorovych vozidel krome povoleni [2]: - Znacit motor_vehicle=private. *** OK Doplnit pak nekam, ze to povoleni plati pro OU Loukovany (opet note, comment, ...)? *** to je asi zbytecne podrobne, nic rozumneho se z toho vyvodit neda 3) Dopravni obsluze vjezd povolen [3]: - Podle wiki se bezne znaci (?): - agricultural=no, hgv=no, access=delivery - Vyuziti :conditional [4] je sice ukecanejsi, ale prijde mi presnejsi, tedy: agricultural:conditional=yes @ delivery, agricultural=no, hgv:conditional=yes @ delivery, hgv=no Pokud je to spravne, doplnil bych to na [5]. *** asi bych se primlouval na domluve na nejakou specifickou hodnotu pro CR, porotoze, z vyse uvedene kombinace tagu se obtizne zrekonstruuje mimo D.O. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Adresy a is_in, RUIAN
Ona ta problematika je dost složitá, v Praze existuje mnoho různých dělení. Viz http://cs.wikipedia.org/wiki/%C4%8C%C3%A1sti_Prahy V centru je to ještě celkem přehledné, ale takové Satalice jsou buď díky za info, autor článku má můj obdiv. Tak do toho nejdu. *** k pochopení situace síše pomůže toto: http://www.czso.cz/csu/rso.nsf/i/soustava_prvku resp http://www.czso.cz/csu/rso.nsf/5873954e2ae286eec12570f8003e7738/a1809b67f5f4560ec1256e6100495bff/Obsah/138.2F62?OpenElementFieldElemFormat=gif hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Ruian jako zdroj dat
Asi by bylo vhodné ho importovat, třeba jako tag building:ruian:use nebo building:ruian:type a nechat tam jen to číslo, jak je, protože překládat ho do více anglických slov asi nebude moc hezké. Zároveň bych navrhoval ten objekt označit již současně používanou hodnotou do tagu building. *** tento dualismus se mi líbí Tady se říká http://wiki.openstreetmap.org/wiki/CS:Map_Features že je to název obce za PSČ, což by byly Dívčice. Co tedy chceme mít v tomhle tagu? Neměla by se opravit wiki? *** Opravit. Spíš mě to připadá, že si někdo neuvědomil při tom výkladovém zjednodušování, že pošta nemusí být shodná s názvem casti obce v adresním míste. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Ruian jako zdroj dat
Účet mi nebyl zablokován kvůli neprůhlednému názvu. *** to je zřejmé, někdo tvrdil opak? Mám opačný problém. Data jsou příliš přesná a dochází ke kolizi s nepřesnými daty v OSM. *** to je logické a ten samý problém bude někdo řešit jednou po tobě na tvém importu Při výběru názvu účtu jsem se řídil poslední větou http://wiki.openstreetmap.org/wiki/Import/Guidelines#Use_a_dedicated_user_account *** smysl zvlášních účtů na importy bylo oddělení osobní licence od importní licence a importních licencí navzájem. viz problém User.Pavel. *** informaci o garage v RUIAN imho neni. imho je :-) *** supr, takze to zohlednis v importu? ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Ruian jako zdroj dat
*** licence existuje a vyplývá ze zákona, více je na wiki jenom jsem se ztotožnil s příspěvkem, zde na talk.cz https://lists.openstreetmap.org/pipermail/talk-cz/2012-June/007406.html Stát nemusí zkoumat, vymýšlet licence, vydá zákon, ale třeba je to opravdu jinak. *** třeba ano: neexistence licence = platí obecná ustanovení Autorského zákona licence vyplývá ze zákona xy = veřejný rejstřík = můžeme importovat OSM Ano opravdu existují i kombinace čev/čo *** to je hezké ;) addr:postcode addr:street (pokud existuje) *** OK addr:country (nevím jak moc je nutné) addr:city = obec *** tohle je součástí info v boundary addr:place = část obce *** ano část obce dnes v OSM chybí, neumím rozhodnout zda je lepší :is_in nebo :place source:addr *** nestačilo by prostě source? adresní bod bude vždy jen adresní bod. ref:ruian ref:ruian budeme mít i na budovách. Budovy mají v ruian vlastní kód. Co se stane, když někdo k tagům budovy přidá i tagy adresní? Bude mít budova ref:ruian 2x? *** Stavebni objekt = way+building, Adresni misto = node+addr *** adresni body z 99% jsou nody a RUAIN jako body vzdy zustanou, takze bych znovu nepripoustel strkani techo tagu do way building. (tohle zarucene do diskuze nekoho zapoji ;) ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Ruian jako zdroj dat
rad bych se Mirka zastal, protoze mam dojem, ze to jaky zvolil nazev uctu, je spise podruzna zalezitost a mam pocit, ze kritika, ktera se na nej ted snasi je trochu zbytecna a spis odrazujici od dalsi prace. *** Zvolil si nepruhledny nazev importniho uctu, byl zablokovan, nikde nic nepopsal co skutecne dela, takze je legitimni, kdyz to alespon zpetne udela. Kritika neni urazka, ale nastroj jak delat veci lepe. Koneckoncu, kdyz ja rucne obmalovavam katastralni mapu, tak delam neco velmi podobneho a taky to delam pod svym nickem a nic zvlastniho se z meho nicku nevycte. *** Taky te nikdo nebanuje a obkreslujes po jednotlivych objektech ne? Pocitam, ze to hlavni je, ze na vytvorene objekty dava tagy source a ref, ktere rikaji odkud data pochazi a jak vznikla. A to snad staci ne? *** Staci to pokud nedelas import. Vytvoření metadat o importu je na několik hodin, ale vytvořit je může jen on, protože je má v hlavě. Pokud ovsem Hanoj narazi jen na to, ze pouziva source:addr=ruian nebo source=ruian a radsi by byl, aby pouzil source=cuzk:ruian tak to je asi rozumny pozadavek a myslim, ze minimalis to bude schopen snadno opravit, pokud mu bude odblokovan ucet. ;-) *** ja nechci na nic narazet, proste rad bych videl nekde popsane proc to dela jinak nez dosud nebo prave tak *** pokud se bavime jen o adresnich bodech (a ja dosud nevim zda jsou jedinym predmetem importu), pak je na prvni pohled vhodnejsi mit source tag=cuzk:ruian a nabytecnost is_in, ktery se uz drive vypoustel Naopak si myslim, ze vzhledem k popsane slozitosti importu dat z RUIAN je velmi vhodne, ze pro svou konkretni metodu a vysledek prace si zvolil ucet, ktery primo odkazuje na jeho osobu, ale da se odlisit od kresleni, ktere dela jako minimalis rucne. *** proc ne, ale vzhledem k politice importu bude pro jeden ucet fungovat prave jeden zdroj. Na druhou stranu by asi bylo hodne dobre, kdyby napsal onu stranku na ceske wiki, kam by pro zacatek uplne stacilo copypastnout sve predchozi maily o tomhle projektu. Aby ta informace nekde byla jasne a prehledne i pro dalsi, pokud by chteli na jeho praci navazat, resp. o tom projektu diskutovat na jednom prehlednem miste. *** CP doufam ne, budu veřit že lakoničnost a výstižnost převáží nad esejemi. Dal by me zajimalo, jestli si nemyslite, ze by bylo vhodne, pokud teda bude mit Mirek naladu pokracovat, doplnovat k budovam i ty doplnujici informace, jako je treba ucel objektu. Nabizi se bud rovnou pouzit (a trochu rozsirit) tak building, treba building=garage, nebo mene konfliktni novy tag, treba building:ruian=neco. *** informaci o garage v RUIAN imho neni. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Ruian jako zdroj dat
Pár slov na wiki dám, dejte mi čas týden, na utřídění myšlenek a zavzpomínání, co všechno jsem ještě neuvedl. Nevím zda tam přidat nějaké *** těším se Například jsem nezmínil to, že aktualizuji pouze AM jako body. Ne že by nešli aktualizace adres na budovách, ale místy opravdu nejdou. Nejdou na SO s více vchody a tedy více AM, kde je na SO pouze jedno AM a ostatní scházejí . Potíž je nad takový SO s jedním AM umístit nové body. Dochází k překryvu čísel a jejich nečitelnosti. Jednoduché řešení nemám. Nezmínil jsem ještě zdvojení AM na rohových SO. V Ruian jsou body pro vedlejší i hlavní ulici na sobě, což se JOSM nelíbí. I přes jeho odpor to tak nechávám v případech, kdy jsou obě čísla identická a liší se pouze ulice. U AM s číslem orientačním je pak posouvám ručné k hraně SO. Navíc ani nevím, zda u těchto SO jsou opravdu využitelné (existují?) oba vchody. Ale co jsem namátkou kontroloval tak jsou i v adresy.xml. Jak to udělat automaticky nevím. *** supr, ještě popsat pro ty co neznají strukturu RUIAN ze AM jsou adresni místa a SO stavebni objekty. Hanoj by konečně mohl být ve své kritice konstruktivnější a napsat svoji představu o názvech importních účtů pro případ více uživatelů + jeden hlavní pro automat. *** nikde jsem nepsal, že ho máš změnit, psal jsem že jeho nazev nevystihuje obsah. Pokud bys chtěl mít nový, tak by bylo vhodné aby obsahoval slova ruain, import a treba minimalis, jestli bude slouzit jen tobe. Nějaký čas vyčkám, zda se někdo ujme vývoje nějakého polo/automatu. *** na godota asi čekat netřeba. Na metadata o dosavadním importu před pokračováním určitě vyčkej. Interně si můžeme říct, že moje činnost byla opravdu více import, než odvozování ... Tedy pokud porovnám objem dat. Že ruční práce je zdlouhavější na věci nic nemění. Navenek bych to ovšem opravdu prezentoval jako odvozování. Nebo jsem se domníval, že jde o odvozování. *** Každý import obsahoval dost ruční práce z různých příčin a na různé úrovni a vždy zůstal importem. Bez importu bys neměl co upravovat. Do zdrojů pro odvozování patří ortofotomapy, nebo schémata silniční nebo elektrické sítě ŘSD ČEPS. Importovat nejdou ale obsahují dost informací na odvození atributů či a obkreslení. Jedná se o projekt s příspěvkem EU. Data jsou k dispozici volně bez licence. *** licence existuje a vyplývá ze zákona, více je na wiki ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Ruian jako zdroj dat
nejsem robot, ani si (prozatím?) automatickou aktualizaci nedokážu představit. Proto ten název účtu... *** (ne)automatizace importu nijak nesouvisí s podstatou účtu Nikde jsem se nedočetl, že by název účtu měl být odvozený od zdroje importovaných dat. *** docela pomůže těm ostatním v mraneništi že se ferdovi říká ferda a ne malej mravenec Ano, uznávám. Jsem špatný čtenář a ctitel pravidel... *** Nerozumím, proč to stále opakuješ, raději si zkus něco přečíst. Nepřipadá mi že bych svoji činností poškodil ostatní editory a uživatele. Naopak jsem jejich chyby odstranil a skryl do historie OSM. *** hodnota dat není jen v jejich (pochybné) existenci v OSM, ale také to, že je o nich hodnověrný popis jak vznikly, proč to tak bylo, jak se s daty nakládalo, proč tak bylo nebo nebylo uděláno, co chybí, jaké jsou možnosti pro ty ostatní k pokračování a dále přesnost, úplnost, pokrytí, atributová homogenita se staršími daty, řešení konfliktů, následných změn, aktualizace... Nebo narážíš na to, že jsem se o řešení nepodělil s ostatními? Pokud někomu napíšu, co všechno musí zvládnout sám, spolehlivě ho odradím (bohužel). *** Tak to je asi nedorozumění. Cílem není psát prosebné maily, ale popsat to co delas na wiki. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Ruian jako zdroj dat
2) Minimalis_import *** dokázal bych si představit výstižnější název pro účet importující výhradně RUIAN 3-4) vycházel jsem z předchozích diskuzí zde a částečně ze zvyklostí vyčtených v OSM datech. *** tak někde na wiki popiš proč jsi vybral toto schéma, proč se nedržíš stávajícího a jaká data a proč vlastně importuješ, co děláš s těmi co už jsou v osm... http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap#.C4.8C.C3.9AZK_-_RUAIN http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap#Dokon.C4.8Den.C3.A9_importy Pochopil jsem, že hledat řešení akceptovatelné všemi je zbytečná ztráta času. *** Tak to je asi nedorozumění. Cílem není získat jednotný souhlas ve formě aklamace, ale 1) nadhodit téma, 2) vytvořit koncept dat a metadata, 3) vyslechnout připomínky a zvážit je 4) nakonec něco realizovat. V tvém případě jsem dosud viděl jen 1) a 4) Takže možná tak trochu partyzánština. *** to je pro ostatní editory i uživatele dat škoda, ne? ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Ruian jako zdroj dat
Ahoj, možná by neškodilo dodat: 1) co jsi dělal 2) pod jakým účtem 3) kde je k tomu popis postupu a metadata k výsledku 4) kdy jsi to výše uvedené předhodil talk-cz k připomínkám díky hanoj Dne 26. listopadu 2013 22:04 Mirek Dlask dlas...@gmail.com napsal(a): Ahoj komunito Jak už jsem psal nedávno, byl jsem na svoji záškodnickou činnost ( import dat Ruian z uživatelského účtu) upozorněn P Normanem. Po založení dedikovaného účtu a pár importech jsem byl bloknut s následujícím vysvětlením. would you please, before continuing any of your imports, e-mail d...@osmfoundation.org and explain how you have conformed to our import guidelines (see http://wiki.openstreetmap.org/wiki/Import)? I couldn't find any discussion about your proposed import on the imports@ list and the source of your data is unclear. Frederik Ramm OSMF Data Working Group Vzhledem k mojí neochotě se někam registrovat a ještě menšímu diplomatickému umění něco vysvětlovat bych tuto ne/milou povinnost přenechal někomu jinému. Třeba už je někdo registrován a jeho angličtina je lepší než ta moje. Ani nevím co a jak vysvětlovat e-mailem. Hlásí se někdo dobrovolně? M.D. ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Opravdu nen? ??dn? shoda o adresn?ch bodech?
To, že v (normalizované) databázi je všechno jednou a mezi jednotlivými informacemi jsou vazby nikdo nezpochybňuje. Vazbám v databázi ale spíš odpovídá relace v OSM - přímý odkaz pomocí klíče - než poloha přes sebe. *** poloha je jednoznačná identifikace stejně jako klič. Aby klíč nebyl duplicitní, nebo aby např. adresní bod byl uvnitř budovy na to jsou jiné nástroje (integritní omezení a topologie) Tomu příkladu s overpass API nerozumím - ukazuje cykloobchody v Brně, ale předchozí diskuse spíš směřovala k vypsání adres cykloobchodů v Brně (přiřadit obchod k budově a pak najít odpovídající adresu - podle budov, ne podle nejbližšího bodu). *** jak psal kubajz, je to příklad prostorového dotazu. Podle logiky relačních databází by všechny cykloprodejny měly být v relaci Brna, nebo mít nějaký tag is_in. Ale je to nadbytečné, ony totiž v Brně už jsou tagem lat/lon. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Opravdu nen? ??dn? shoda o adresn?ch bodech?
Myslete trochu na ty chudaky co se snazi osm data pouzivat. Ano, je mozne spocitat ktera budova obsahuje dany adresni body... ale neni to uplne primocary program, a muze tam nastat spousta zajimavosti.. jako treba neuzavrena budova. A kdyz chci zjistit adresu restaurace (POI), hledat kvuli tomu obrys budovy a prohledavat, ktery adresni body lezi v obrysu... mi prijde zvrhle. Ano, s dostatecnou motivaci bych to mohl napsat, ale.. kdyz tech implementaci bude vic (bude), budou se v okrajovych pripadech chovat jinak (spatne!). Ty vazby by v datech mely byt. Muze je vyrabet/kontrolovat nejaky automat, ale nutit kazdyho uzivatele mapy aby si to naprogramoval neni hezke. *** Trochu mi to pripomina, kdyz se lidem pracujicim v Excelu vysvetluje princip databaze: Treba ze v databazi nebude mit kazda faktura adresu, ale jen klic odkazujici do tabulky subjektu s adresou a oni chudaci musi pouzit JOIN aby dve tabulky sloucili v jednu. Stejne tak v geodatabazi je prvni co se uci SPATIAL JOIN, a je to standard i v GIS desktopech. A co OSM uzivatel a prostorove vztahy? Proste to funguje... http://overpass-api.de/api/convert?data=node%28area:3600438171%29;node._[%22shop%22=%22bicycle%22];out%20meta;target=openlayerszoom=12lat=49.2lon=16.6 ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Opravdu není žádná shoda o adresních bodech?
Ahoj, prosím, neuraž se, ale tvoje odpověď mi teda vůbec nepomohla. *** urcite ne;) Moje původní otázka byla, jestli je nějaká shoda na tom, jak se mají adresy kreslit do OSM. Archiv talk-cz jsem prolejzal a skutečně je tam toho napsáno hodně, ale že bych našel informaci, jaký je preferovaný způsob, to teda ne. Přijde mi škoda, že, pokud teda shoda vůbec je, to někdo nenapsal na wiki, aby v tom bylo jasno. *** absolutní shoda tu nebyla nikdy na ničem, podle toho to taky to občas vypadá. Existuji spíše převažující zvyky. Na editační války je tu málo lidí. *** tvořit wiki je chválihodné. Primárně nechci nic zlepšovat, ale prostě bych jen chtěl data do mapy přidávat, tak aby to bylo co nejúčelnější. A odpověď na otázku jestli mám adresu dávat radši jako: -a samostatný bod na místo určené v KM nebo RÚIAN -b bod v cestě obrysu domu, pokud možno na vchod -c přímo do obrysu domu jsem prostě nikde nenašel. *** dle mého názoru a také když stáhnu v drtivé většině OSM data, spustím addr plugin v JOSM a nebo poloimport z UIR-ADR taky tak je to var a): samostatný bod na místo _odvozené_ z KM nebo RÚIAN, bod který neobsahuje nic jiného. Dost pochybuju, že mi odpověď přímo poskytne tebou doporučované studium GIS a možností překryvných analýz. *** mě to kdysi dost pomohlo v přemýšlení v GIS... proč není nutná pevná vazba s jinými prvky a co se ztrácí vložením do obrysu. Zkoumal jsem, co je vlastně v RÚIAN a došel jsem k závěru, možná zcela mylnému, že nakonec v KM i v RÚIAN jsou adresy jen jako body, byť možná RÚIAN obsahuje i vektory budov. *** správně Vůbec nechápu, co máš na mysli touhle větou Systém adresních bodů (jakož i budov) už mimo OSM někdo vymyslel, udržuje ho a z 99% bude vždy naším jediným zdrojem RUIAN/KM. Dnešní využití těchto dat v OSM je jemu podobné a tento systém je pro nás dost dobrý Chápu, že tím asi myslíš, že budeme vždy vycházet z těchto dvou zdrojů, ale myslíš tím, že teda máme používat pro adresy body v místech, kde jsou v RÚIAN a v KM? *** chci tím říct, že adresní body mají být formou pouze body a mají obsahovat jen adresní tagy (nikoliv POI). Umístěné mají být nad reprezentativní budovou (problém vazby budova adresa M:N). ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] číslo evidenční v addr:housenumber
Z toho mi jasně vyplývá, že tady http://wiki.openstreetmap.org/wiki/CS:WikiProject_Czech_Republic/Address_sys tem uvedené doporučení je pro kočku, protože se doporučuje něco, co se nepoužívá. *** bych netvrdil, spíše import proběh jinak/dříve než doporučení na wiki. ale počítám, že si přes OverPass API natáhnu kusy ČR do JOSM, opravim to a uploadnu zpátky. třeba takhle: http://www.overpass-api.de/api/xapi?node[bbox=16.25,49,16.7,49.25][shop=bicycle][@meta] další příklady zde: http://wiki.openstreetmap.org/wiki/User:Hanoj/overpass ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Aplikace TerrainGIS pro Android
Problém je trochu v tom, že já jako autor nedokážu jistě říct, jestli navržené ovládání je pro uživatele pohodlné nebo ne... *** Určitě zajímavé, ale žel to nemám kde vyzkoušet. Možná by k tomu měli více co říct lidé tady: freege...@fsv.cvut.cz ahoj hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] footway vs. path vs. bridleway
Je otázka zda chápat, footway chodníky přesně tak jak, jak na ně pohlíží zákon, jestli automaticky znamená chodník= zákaz cyklistům. Pokud budu mít zpevněný chodník napříč lokou, může být využitý i cyklisty. Zas naopak, je proč otagovávat zákazem pro cyklisty jen nutně to, kde je značka zákaz cyklistům a né všechny takové komunikace, které jsou pro cyklisty i nevhodné a ohrožovali by jízdou chodce, případně další účastníky provozu. *** na legalitu je tag access=* *** na vhodnost pro horská kola je mtb:* http://wiki.openstreetmap.org/wiki/Cs:Key:mtb:scale např. chodník může obecně jen chodec, je-li to někde jinak pak se přidá access tag (např. Pardubice mají některé chodníky i pro cyklisty). Nic to nemluví o tom jak ten chodník je vhodnej/pohodlnej pro kolo. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] footway vs. path vs. bridleway
shodou okolností jsem nedávno trochu studoval právní problematiku pohybu cyklistů a koní v lese (ne na loukách, ne někde jinde). Zákon říká, že cyklisté a jezdci na koních se v lese mohou pohybovat jen po značených cestách. Zákon bohužel neříká, co je značená cesta, ale většinou se to vykládá tak, že to je cesta vyznačená alespoň v katastru jako cesta. *** já to čtu trochu jinak - nikoliv značená cesta ale cesta (chápu jako odvozní, přístupová, zásobovací) nebo vyznačená trasa (chápu jako KČT, cyklotrasy, naučné stezky vedoucí často pěšinami napříč cestami), což myslím že je už docela zřetelné. § 53 (1) Přestupku se dopustí ten, kdo v rámci obecného užívání lesa v lese ... g) bez povolení poruší zákaz vjezdu a stání motorovým vozidlem, ... j) jezdí mimo cesty a vyznačené trasy na kole, na koni, na lyžích a na saních, ... http://www.zakonyprolidi.cz/cs/1995-289#p53-1-j ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] footway vs. path vs. bridleway
Problemem je http://wiki.openstreetmap.org/wiki/Cs:Map_Features . Nevim kdo ji prekladal, ale moc dobrou praci neudelal: *** tato stranka wiki nebyla nikdy prekladana ale lokalizovana. Zacalo se s tim pred 7 lety a je veskrze konzistentni. ...ze se v CR objevuji vyjimecne, neni pravda, treba lesy okolo Klanovic a Rican jsou toho plne. V Klanovicich je typicky velka cesta po ktery chodej lidi a jezdej kola, a vedle toho nesutrata, ale rozbahnena, stezka pro kone. V Pocernicich a Ctenicich jsou dokonce znacany malymi plastovymi tabulkami. *** Klanovice neznam, zato tam kde jsem byl na vyletech a doma kde se mnou sousedi asi 20 koni nic takoveho neni. Bohuzel, automaticka editace z takto oznacenych cest (highway=bridleway) udelala highway=path... cimz se ztratila informace. Pokusim se informaci vratit zpatky, a byl bych rad kdyby se dalsi automaticke niceni mapy neopakovalo. *** ztrata informace je vzdycky skoda, nicmene tvemu popisu nerozumim, takze bych si prvne overil u nekoho kdo to tam zna, zda se na tom schematu shodnete a bude v souladu s wiki. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] opětovný dotaz na další wms služby ÚHÚLu
Konkrétně by mě zajímala wms vrstva výškopis: geodetické body s nadmořskou výškou, vrstevnice, ... . Na stránce http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap je napsáno Pan Císař z ÚHÚL nás ovšem ujistil, že přes WMS poskytují buď data, která jsou úředním dílem a lze je užít nebo data, ke kterým má ÚHÚL takovou licenci, která nám umožňuje legálně užívat a odvozovat z nich další. POZOR! UHUL ma na svem webu dve mapove sluzby, jednu pod WMS, kterou je mozne legalne uzivat, druhou, ktera je prevzata od CUZK a tu mozne pouzivat neni, viz nize. *** Je třeba chápat, že ten dopis p. Císaře je 6 let starý a vztahoval se na tehdejší stav WMS vrstev. To na co se díváme dnes nemusí mít s tehdejším stavem nic společného (např. tehdá byly v provozu navíc i WFS služby). Co se výškopisu apod týče, tak tato data v ČR poskytuje a udržuje pouze několik málo institucí (tipuji CUZK, Geodis, Dobruška). A já tipuji, že na 90% to má UHUL od CUZK, licenční podmínky ČUZK jsou na webu. Nicméně za optání člověk nic nedá. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] opětovný dotaz na další wms služby ÚHÚLu
k tomu mám jen připomínku na okraj. Kreslím si teď okolo Týna nad Vltavou a připadé mi, že lesy, které, předpokládám, jsou naimportované z diskutovaného zdroje (ozančené uhul:wms) mají při porovnání s katastrem a ortofotomapu celkem mizernou přesnost. Často se to liší o desítky metrů. Nevím, jestli ta data jsou takhle nepřesná už ze zdoje, nebo došlo k nějakému zkreslení/zaokrouhlení při importu nebo přepočtu souřadnic. *** ta data jsou generalizované parcely katastrální mapy z pozemků PUPFL (generalizace nebyla nejšťastněji provedena, ale to není hlavní problém). Člověka zpravidla nezajímá PUPFL ale to kde stromy/les opravdu je. *** Polohová přesnost je jen jedním z indikátorů kvality, docela významný je ale také úplnost mapování (např. na území státu). V každém případě pokud by měly ty odvozní cesty mít stejný problém, tak bych se tím snad ani neřídil. *** pokud by existovalo přesvědčení, že jsou odvozní cesty plnocenným zdrojem, už dávno bysme je importovali. Řekněme, že je to pomocný zdroj. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] opětovný dotaz na další wms služby ÚHÚLu
ÚHUL nam tehdy poskytl vše na co měl licenci nebo bylo jeho tj. čb ortofoto, odvozní cesty, lesní pozemky ha hanoj Dne 20. srpna 2013 19:47 Pavel Kwiecien pavel.kwiec...@seznam.cznapsal(a): Ahoj, již M. Kyral se ve svém dotazu ptal na další wms služby ÚHÚLu: http://lists.openstreetmap.org/pipermail/talk-cz/2013-January/008137.html jako je například výškopis atd. Na dotaz však nebylo zodpovězeno. Chtěl bych se proto na toto téma znovu zeptat, zda je možné tento zdroj použít. Děkuji za odpověď a zdraví Pavel Kwiecien ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Rada - neznámý objekt v OSM
--- ADMIN --- Jako admin tohoto talk-cz@ už nechci číst níže uvedené vulgární pindy, napadání druhých či třetích. Běžte se projít k vodě, vyvětrejte místnost a dopisy zásadně pište druhý den po té, co se vám v hlavě zatmí. (Jakož i podobně budiž v tématu KČT) děkuji konec hlášení hanoj --- ADMIN --- Krása, že? Tak buď ať to udělají pořádně, nebo ať s tím jdou do prdele. To nejsou schopní se podívat někdy na render, aby viděli, jaká prasečina z toho v mapě je? To asi často koukají na mapu nebo do editoru. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] cesta jako dvě jednosměrky?
prosím připomeňte mi, proč v OSM někdo kreslí normální čtyřproudou cestu (konkrétně např. R49 mezi Zlínem a Otrokovicemi) jako dvě protiběžné jednosměrky. Připadá mi to jako zlozvyk přebraný z Google Maps, který si tím pomáhá při routování, takže to dělá skoro všude (ty jednosměrky). V OSM to ale přece dělat nemusíme, máme na všechno příznaky - na počet pruhů, na jejich směry, na přikázané/zakázané odbočení... *** U tzv. směrově dělených silnic (typicky dálnice, rychlostní silnice) je každá osa pro jeden směr; za směrové oddělení se nepovažuje ostrůvek přechodu, vjezdová brána obce, ani křižovatka s ostrůvky. http://kuc.cz/43if8r A když už jsme u toho, proč se dálnice bez prostředního dělícího čehokoliv taky kreslí jako dvě protiběžné jednosměrky? To je nějaký úzus? Nebo když je na asfaltu dvojitá plná čára, tak už se to bere jako dvě cesty v OSM? *** Komunikace bez dělícího ostrůvku (a bez svodidla) nemůže být dálnice. *** Dvojitá plná čára není dělící ostrůvek = jedna cesta. Chápal bych to jako úzus. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] sidewalk
koukal jsem, ze i v diskusi v minulosti tady v talk-cz@ jsme se shodli, ze sidewalk=both/left/right/none by se mel pouzivat tam, kde chodnik navazuje na silnici. Nicmene koukam, ze to nikde nemame zdokumentovane *** mě ten tag přijde máloobsahový. Po všech silnicích může chodec (vyjma motorových). V obytné zástavbě je ze zákona dáno, že chodník být musí a také v drtivé většině je. Pro pěší navigaci je jeho konkrétní forma left/right nedostačující... Ale chápu, že při použití highway=footway je problém přejít silnici jinde než na přechodu. Možná by to šlo vyřešit nějak algoritmicky, něco jako je-li přechod dál než 50m (361/2000 Sb) pak jsou-li dva chodníky blíže než šířka vozovky tj cca. 6 až 12m +2m umožni přejít. Tj. obalová zóna (buffer tj. polygon) okolo chodníků 14m mínus obalová zóna 50m okolo přechodů, mínus domy (jako polygony) a bariéry (jako polygony). Tam kde mezi obalovými zónami chodníků zůstal vztah vzájemného překryvu, tam existuje vztah pro přejití. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] maps.fordrog.com RUAIN
--+---+---++ 5514 | epsg | 5514 || +proj=krovak +lat_0=49.5 +lon_0=24.83 +alpha=30.2881397528 +k=0. +x_0=0 +y_0=0 +ellps=bessel +units=m +towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 no_defs (1 row) *** na prvni pohled mi tam chybi +pm=greenwich a + u no_defs, ale jesti je to problem nevim. upne zneni: +proj=krovak +lat_0=49.5 +lon_0=24.83 +alpha=30.2881397222 +k=0. +x_0=0 +y_0=0 +ellps=bessel +pm=greenwich +units=m +no_defs +towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] maps.fordrog.com RUAIN
Pak už mi tedy zůstal ještě problém, že EPSG 5514 nezná QGIS, ale to předpokládám u tebe nevadí. *** EPSG:5514 je totožný s ESRI:102067 je možno ho tam ručně přidat [1]. Oba by QGIS 2.0 měl znát již od instalace. [1] http://grass.fsv.cvut.cz/gwiki/S-JTSK#Volba_projekce_S-JTSK_v_QGIS ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] [okfn-cz] ŘSD stále odmítá vydat mapy
Jen krátký komentář, v letu jsem dopis přečetl a tuto problematiku jsem nějakou dobu řešil. 1) Informační zákon 106/1999 Sb dává povinnost poskytovat informace nikoliv data. 2) Ani INSPIRE nic takového neřeší. Než se soudit, zkusil bych ještě prubnout o data JDVM. http://www.jdvm.cz/ Pán na RSD je zjevně placen proto, aby odmítal a jde mu to. Nic z toho mne samozřejmě netěší. ha hanoj Dne 2. července 2013 8:21 Jachym Cepicky jachym.cepi...@gmail.com napsal(a): (Přeposílám do OSM-CZ mailing listu) Tak jsem si to přečetl a docela mě to zdůvodnění pobavilo. Pár věcí, které mě napadají (asi napadají každého): * ŘSD pomocí WMS neposkytyje žádná data, jak píše pan řídící, ale obrázek dat a mělo by se jim to vtlouct do hlavy * Pokud si někdo myslí, že pomocí webové mapové aplikace lze zjistit souřadnice čehokoliv, je vedle jak ta jedle, protože to *vždy* bude jenom nepřesný odhad * těch 210 000 odhaduju cenu licence k nějakému softu, která je potřeba na to, aby se něco převedlo z CAD do GIS formátu? Myslím, že je-li to v CADu a dali-li by to v CADu, nikdo by nemohl nic říct. * pokud existuje WMS, musí pod tím existovat datový soubor nebo databáze, nad kterým to jede - tečka. Cena za skopírování souboru je 210 000? Cena za jedno SQL je 210 000? Tuhle práci chci dělat! Proč ten dopis nezveřejnit v plném znění na webu? ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] [okfn-cz] ŘSD stále odmítá vydat mapy
No, je to trochu slovíčkaření - data jsou přece informace (dost mě to slovíčkaření na jednom semestru informatiky na ČZU nebavilo), *** myslím si, že na tomto rozlišení je postaven onen zákon. Tedy, že informace je jakákoliv skutečnost, fakt, papír, úřední rozhodnutí, ale data jsou utříděný rejstřík, tabulka, databáze. Zákon dává nárok na fakturu, výsledky hospodaření, ale ne na účetnictví. Pokud by se podařilo zlomit tento výklad, pak bychom mohli žádat o geodata lec koho (pokud by to nebylo už dříve předmětem jeho obchodní činosti, prodeje). Pokud tedy ŘSD nabízí informace v podobě WMS, pak je nabízí dost nepřesné a zkreslené. *** Pokud požádáte město o jízdní řády MHD, odkáže vás na web. Skutečnost, že to prakticky není strojově zpracovatelné není žel argument. To je praxe, ale není o tom precedent ve smyslu Nejvyššího správního soudu. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] maps.fordrog.com RUAIN
Ahoj, moje oblíbené mapy nejedou http://maps.fordfrog.com/ předpokádám, že je to tím, že od datové sady vydané ke dni 2013-05-31 jsou data v souřadném systému EPSG:5514 namísto dříve užívané EPSG:2065, a tudíž není nutné pro potřeby GIS transformovat geodata do EPSG:102067, protože EPSG:5514 a ESRI:102067 jsou totožné kdyby byl čas na jejich nahození tak díky. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] osm, metro, github
Pardon - ty ST_* funkce jsou právě z rozšíření PostGIS *** to jsou prave ty hezke funkce, umoznujici pracovat s geodaty aniz by muselo byt nutne vse zapsano ve strukture dat (napr relacich). Na puvodni verzi vzal Jachym vstupy do metra, sloucil je do skupiny podle jmen, a pak z nich udelal jedno teziste. Volna vazba pres jmeno je pro mnoho aplikaci plne dostacujici. ST_Centroid( -- there are more metro entrances, just one point needed ST_Union(point.way) -- join all entrances with same name into one multi-point feature ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] jmena cest jako relace
Takže nejdůležitější na začátek: Jsem pro všema dvaceti, samozřejmě za předpokladu, že bude JEDEN způsob, ne dva, ne neznámo kolik. A domlouvaný mezinárodně. Jsem ochotný pomoct, i s angličtinou. 1. jako technik v tom vidím jednoznačný posun v kvalitě dat. Ta ulice je objekt a jako každý jiný objekt má mít svoje tagy uvedené u sebe, tedy právě jednou. *** Od počátku dosud v OSM neexistují striktní pravidla, jen konvence. Ten JEDEN způsob by měl splňovat ještě jednu podmínku, jednoduchost. At jsou si data fyzicky uložena jakkoliv, pro uživatele to musí být jednoduché a pochopitelné skrze editor. Kaskády relací např. nad polygony v to zatím nepatří. Podobně jako krom botů nikdo needituje OSM XML z notepadu, ale z grafického editoru. Tedy jinými slovy: polymorfismus máme teď, když stejné tagy máme uvedené neznámo-kolikrát-u-nijak-datově-nespojených-objektů. Přesně toho polymorfismu se chceme zbavit. *** Polymorfismus je více forem pro jeden jev. Více objektů stejné formy se stejným NAME je spíš z kapitoly normálních forem relačních databází. Ne vždy je nezbytné normální formu v databázi realizovat, protože její režie mohou být nad přínosy. Který jiný objekt máme v OSM uvedený tak, že je rozsekaný na spoustu částí bez přímé datové vazby (odhaduje se jen podle jména a polohy ve stejném městě)? Víte o nějakém jiném takovém případu? A pokud ano (já ne), přijde vám to i tam jako správné řešení?! *** Třeba ref=* nebo highway=track, jednou je to trackgrade 1 pak 5. Nebo maxspeed nebo kombinace highway=+cycleway=...+oneway *** Nevnímám tu potřebu mít přímou vazbu mezi objekty, stačí mít nepřímou. 2. relace mají v datovém modelu OSM příjemnou vlastnost, že umožňují (přímý a levný) dotaz na své členy. Přesně co potřebuje renderer. Včetně toho, že u cest umíme mít úseky seřazené, aby navazovaly, atp. *** renderer si dělá rozsáhlý postprocessing, proc by si nemohl udelat jednoduchý příkaz v Postgis DISSOLVE. Teď konkrétní nápady, ale upozorňuju předem, že jsou to jen prvotní nápady: 3. zbavíme se duplikování tagů a tedy i hrozby překlepů. Ani nepočítám, kolik jsem jich opravil jen ve Vršovicích za cca 3 mapovací dny! 4. to samé platí pro neúplné sady tagů. Např. u některých ulic jsem potkal, že jeden úsek měl tag name a jiný jen name:ru. A nebylo to rozhodně jen jednou. Takovou věc ani automat nepozná, to jsem musel projít ručně i nožně. *** Překlepy byly a budou. Dají se snadno najít a opravit, často dávkově. *** Teď budeš kontrolovat, jestli každá relace má správný počet členů... Vždycky budou chyby, které se budou těžko hledat. 5. získáme 1:1 vazbu na RÚIAN, jeden objekt v něm bude odpovídat jednomu v OSM 6. z RÚIANu přibudou další tagy, minimálně reference na něj, a ty teď budeme moct dát na jedno jasně definované místo a ne na neznámý-počet-n jakýchsi cest automatem obtížně vyhledatelných - viz odstavce 3 a 4. *** To je iluze, stačí se podívat na strukturu dat RUIAN a způsob práce OSM. I těch málo objektů co má převodník RUIAN OSM 1:1 nevydrží déle než příští editaci. 7. renderer bude znát objekt jako celek a mnohem lépe bude moct vyhodnotit, kam umístí popisky. Dnes jsou popisky četné podle úseků, na které je ulice rozsekaná v datech, a ne podle potřeby rendereru. A to není chyba rendereru, to je chyba dat! Chceme mít popisek jednolitého objektu a přitom ten objekt nemáme definovaný. *** To je věc postprocessingu viz výše. Jediné co máme je primitivní heuristika typu na mosty se dávat popisek s jménem ulice nemusí. A když taková heuristika chybí pro nějakou kombinaci chybí, lidi to řeší tím, že vyhodí tag name z nějakého objektu, třeba mostu nebo tunelu. Úprava dat podle rendereru, přesně to, co se nemá dělat. *** Určitě existuje více způsobů řešení tohoto problému třeba name:bridge, ref:bridge... ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] MTB mapa (cyklo)stezky
http://mtbmap.cz/#zoom=18lat=50.03901lon=15.201424 , viz http://goo.gl/maps/U9xWj , v OSM je pak zde: http://www.openstreetmap.org/browse/way/152321764 . Měl bych proto dva dotazy: - Je stezka v OSM správně označkovaná a lze podle ní upravit všechny ostatní? *** myslím, že ne. Je li tam značka: * C7 + E13 (cyklistům vjezd povolen, používá se v Pardubicích) = highway=footway bicyle=yes * C8 = highway=cycleway * C9 = highway=cycleway foot=designated segregated=no * C10 = highway=cycleway foot=designated segregated=yes * je-li tam jen vychozená pěšina pak jen highway=path * je-li tam jen vyježděná cesta auty, polní nebo lesní cesta pak jen highway=track (pripadne surface, trackgrade apod.) http://wiki.openstreetmap.org/wiki/Cs:Map_Features#Ostatn.C3.AD_druhy_cest ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] jmena cest jako relace
uz to tady problesklo pri diskusi u znamek a podobnych veci - co kdybychom do standardu pro CZ zanesli moznost pojmenovavani ulic a cest obecne pomoci relaci? V tomto smeru uz v OSM existuji minimalne dve (! :( ) relace k tomu *** ze jsem tak smělý, co to přinese (tedy krom polymorfismu ;) ? Ze budes schopen snaze udelat dotaz, ktere vsechny segmenty patri k jedne ulici. Navic by jedna cesta (way) mohla byt soucasti vice nez jednoho pojmenovani (uz jsem se s tim nekde potkal - nikoli samozrejme na urovni oficialnich jmen ulic, ale na urovni zvykoveho oznaceni cest v prirode). A aspon v JOSM by se snaz kontrolovala spojitost, coz by byl takovy prijemny side effect. *** Na vice nazvu je tu tag alt_name. Prvky jende ulice stahnu podle nazvu (kdyz pominu ze definice ulice je nejednoznacna). Kontrola routovacich vazeb by asi sla udelat nejakym algoritmem, priznam se v soucasnem stavu OSM tools nemam prehled. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] jmena cest jako relace
uz to tady problesklo pri diskusi u znamek a podobnych veci - co kdybychom do standardu pro CZ zanesli moznost pojmenovavani ulic a cest obecne pomoci relaci? V tomto smeru uz v OSM existuji minimalne dve (! :( ) relace k tomu *** ze jsem tak smělý, co to přinese (tedy krom polymorfismu ;) ? ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Turistické známky
Dne 29. května 2013 23:17 Marián Kyral mky...@email.cz napsal(a): Sice teď nějak nestíhám, ale dovolil bych si to shrnout: Turistická známka bude zadávána jako relace (type=checkpoint). Uvnitř bude minimálně jeden člen definující turistickou atrakci (role=attraction), ke které se daná známka vztahuje. Další členové jsou nepovinní a označují prodejní místa (role=sales_point). Během importu se vytvoří relace popisující turistickou známku a dočasný bod, který bude následně ručně spárovat se skutečným objektem. Pokud konkrétní bod neexistuje, změní se dočasný bod na trvalý. Bude označen jako tourism=attraction. Pokud se známka neprodává nikde jinde než v místě, nebude prvek s rolí sales_point přiřazen. Předpokládá se, že známka se prodává na atrakci. (ekvivalent: checkpoint:sales_point=yes) (Případně neměl by být prvek přidán dvakrát, pokaždé s jinou rolí?. JOSM má sice námitky, ale nechá se přesvědčit a takovou relaci vytvoří.) *** Zásadně se mi nelíbí, že 1) import má 2000 relací a v každé je jeden bod 2) každý bod má fixme Je třeba opustit iluzi, že se to postupně opraví a doplní. Netvařme se, že jsme schopni mít lepší data než sám původce turistických známek (TZ). To prostě nefunguje, dodnes je v OSM spousta roky nedotažených importů a import TZ prezentuje ani ne polotovar. Import TZ má mít 2000 bodů bez relací a má být natolik konzistentní, aby byl bez fixme. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Turistické známky
Bohužel bez ručního spárování to nejde. Jméno TZ málokdy přesně souhlasí se jménem daného objektu. Nevím, jak bych to tedy automaticky dohledával. Navíc, jak bylo zmíněno v diskuzi, některé známky ani konkrétní bod nemají. Jak to ve skriptu zjistit? *** Neříkám, že to jde automaticky. Jestli všechn 2000 TZ jsi _ty_ schopen projít a do 1/4 roku opravit do finální podoby, nemám s tím problém. Navíc nápad s relacemi se mi líbí. Vyřeší se tím problém s kolizemi (name, website, ref, tourism...). A možnost mít v relaci i konkrétní místa prodeje je podle mně výhoda. To že TZ neposkytují přesné souřadnice by nás přece nemělo zastavit. *** Nevím jestli je to výhoda, já bych to třeba oželel. Nekopírujeme do OSM svět 1:1 ale modelujeme ho, zjednodušujeme, aby s ním šlo pracovat. Máme třeba v OSM linky a zastávky, ale už ne jízdní řády. Ale možná jsem s názorem osamocen... Pokud to naimportuji jako samostatné body a následně budu chtít přidat i místo kde se známka prodává? Musím pak tu relaci vytvořit manuálně? Nebo mám smůlu a relaci vytvořit nesmím, tedy tato informace nebude dostupná? *** Nemusíš nic... já jsem psal, že se mi některé věci nelíbí ;) U předchozích importů jsem nebyl a nevím jak probíhaly. Když jsem se ptal na zkušenosti s importy a jak to správně udělat, nikdo zkušený se neozval. *** zatím postupuješ jako u všech předchozích uděláš krok vpřed a dáš vědět, takže OK. Nikdo ti není schopen poradit předem tak, aniž by ten import za tebe připravil nebo si to s tebou nenastudoval od A-Z. Chci vylepšit OSM a myslím, že TZ je jedna z věcí, která hodně vylepší turistické mapy. Když jsem zjišťoval, jak takový import probíhá, nabyl jsem dojmu, že to bude fuška. No nemýlil jsem se. Abych řekl pravdu, vůbec se nedivím, že ty komíny nakonec nikdo nenaimportoval, i když zdroj a souhlas s užitím máme. *** určitě si tvé práce cením. Je dobře, že to je náročné, protože pak není potřeba revertovat. To se zatím dělalo hromadně snad jen dvakrát. Poněkud neslavně dopadly s dočištěním waterway. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Společné hranice ploch
rozfrncat vsechny cesty na pidisegmenty ... (a pak se v takovy krizovatce renderuje nazev ulice 10x ...) *** No v editoru to az tak asi nevadi a pri renderovani lze pouzit bezny postprocessing pro konkrétní tag. V GIS se tomu říká rozpuštění, dissolve, viz obrázek: http://kuc.cz/ds40o2 Dissolve je opačný princip k neomezené hierarchizaci tagů. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Společné hranice ploch
a---b---c---d---e | Pole | Les | | f---g | | h---i (s temi vsemi pismenky a indexy to vypada slozite, ale v JOSM je to jen par kliku, zkuste si to). *** Ono o té jednoduchosti multipolygonu už mluví to, že pro 2 plochy vytvoříš 5 objektů s různými tagy ;) Což, vytvořit to ještě možná jde, ale vysvětli to někomu nebo po někom zedituj, zkontroluj, oprav to... Popravdě mi Plugin Relation Toolbox mnoho štestí nepřinesl. Jsem rád, že zatím to nikoho nenapadlo dělat hromadně s buildings... Kde vidím multipolygony oprávněné a použitelně: * Vnitřní ostrovy polygonů jako multipolygony s inner/outer, OK. * Trasy (zpravidla myšlené) jako multipolygony s route, OK. * Seskupování autonomních objektů jako multipolygony s collection, OK. * Administrativní hranice jako multipolygony s inner/outer, OK (to vzniklo jednou a navždy importem a edituje to jen pár guru). ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Turistické známky
Přiznávám, překvapuje mě, že v tak základní věci (co se týče typu dat) není shoda ani po tolika letech projektu. Pořád jsem čekal, co napíší zkušenější, ale teď mám pocit, že už se téma začíná rozmělňovat do detailů, a tak se ozývám, než se úplně rozdrobí do ztracena (stejně jako např. téma tagování českých škol nedávno, toho je velká škoda). *** Záleží co si představuješ za shodu, asi ne jednotné hlasování jako KSSS ;) Přesto adresní body fungují jako nody od počátku OSM (s menší přetržkou díky jednomu pluginu), třídění škol funguje beze změn od počátku OSM. hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Společné hranice ploch (was: Re: Par dotazu, na veci nenalezene na Wiki)
kdyz jsem si precetl tuhle odpoved, tak me napadl dotaz. Kdyz je v OSM uz naimportovany les a ja lehce upravim jeho tvar, tak bych mel radsi smazat ten tag, ze je to import z UHUL? *** měl bys popsat všechny zdroje, které se na výsledném podobě lesa podíleli ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Společné hranice ploch
Přiznám se, že jsem to nikdy nezkoušel, ale není ten problém s exportem ploch v tom, že je tolik způsobů jejich reprezentace? -1 uzavřená cesta s typickým tagam pro oblast -2 uzavřená plocha s typickým liniovým tagem a area=yes -3 multipolygon - ...? *** ano, exportovat variantu -1 případně -2 není problém. Multipolygon už není jen o změně zápisu přes nějaké API ale o celkové přeformulování formy objektu. Je zajímavé, že běžně užívané datové modely v GIS naše úsporné problémy neřeší, prostě každá plocha má nejen svou hranu na hranici, ale také své lomové body. Tomu nerozumím, ocenil bych vysvětlení. *** viz srovnání níže hranice dvou polygonů v GIS (ESRI Shapefile): a-b-c-d g-h-i-j hranice dvou polygonů v OSM bez relací: a-b-c-d a-b-c-d hranice dvou polygonů v OSM s relací: a-b-c-d + rel1 +rel2 ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Společné hranice ploch
...každá plocha má nejen svou hranu na hranici, ale také své lomové body. Má tento výrok ještě jiný význam, než že hranice mezi dvěma objekty není vždy rovná čára, ale někdy i lomená? Jestli ne, je všechno jasné. *** Nerozumím otázce ;) *** Dva sousedíci polygony mají společnou společnou hranici (tj. dotýkají se v úsečkách). Pak v datovém modelu: * v GIS má každý polygon své originální lomové body (respektivé své hrany) * v OSM má každý polygon svou hranu po společných bodech * v OSM s relací má každý polygon společnou hranu i body ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
