Re: [Talk-cz] Podivná mapa KN (ovály)
Že by dodavatel v rámci vývoje do výstupu nafrkal debugovací informace a pak tu verzi omylem hodil na produkční prostředí? :) V hrubších zoomech tyhle patvary nejsou (ale tam zase pak už jsou obrysy budov celkem dost hrubé) Martin 2013/5/29 Jiří Veselý j@seznam.cz Dobrý den, děkuji všem za zaslané informace. Chyba je vázaná na EPSG:4326, v jiných souřadnicových systémech se neprojevuje (alespoň co se nám podařilo vyzkoušet). Je to již nahlášené dodavateli, čekáme na opravu. J. Veselý Dne 29.5.2013 7:09, JV napsal(a): Zdravím všechny, pokud narazíte na podivnosti v katastrální mapě (nesmyslné ovály), tak mi, prosím, na mojí adresu pošlete Vaši konfiguraci WMS pro services.cuzk.cza ideálně i odchycený WMS požadavek. Potvrzuji podobné chování např. na Androidu v iKatastr, ale stejná oblast se přes webový ikatastr.czzobrazuje správně. Takže bude asi trochu oříšek přijít na příčinu a budu vděčný za jakékoliv podklady. Děkuji a přeji příjemný den Jiří Veselý ___ Talk-cz mailing listTalk-cz@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Nemehlo
Mozna by stalo za to udelat nastroj co by hlidal podobne novacky, vymyslela by se nejaka metrika - napr. ze v oblasti jejich editace pribylo hromadad chyb v keepright, erroru/warningu v JOSM validatoru, ze jejich editace hned nekdo editovat znovu (t.j.nejspis byly blbe a nekdo to opravoval) - a u lidi s vysokym score by se pak nekde vedl seznam jejich editaci ktere je treba zkontrolovat a pripadne bud manualne opravit, castecne revertnout, proste podle toho co tam nasekali. S tim, ze casem by pak slo patricne uzivatele pote co jim nekdo nejak vysvetli co delaji blbe ze seznamu nevedoucich novacku zase odstranit (pote co zacnou mapovat veci spravne) Martin 2013/4/7 jzvc j...@tpfree.net Dne 7.4.2013 2:04, Michal Tauchman napsal(a): V tomhle případě nezbývá nic jiného než se obrnit trpělivostí a vysvětlit problém. Případně jej odkázat na help, jabber chat, ci komunitu na G+ kde se má možnost zeptat a bude mu porazeno. Nicméně nápověda na wiki je dost obsáhlá v en, v CZ nevím jak na tom jsme. V Cz jsou mezery, ale řekl bych, že nejdůležitější prvky tam jsou, nepřeloženy bývají jen podrobnější a méně využívané tagy. Vetsinou je to o tom, ze ti lide ani o wiki nevedi ... a proste si zapnou web editor a kresli si - casto aniz by si uvedomovali, ze se jejich zmeny obratem projevi. Casto staci jim napsat. Ale je fakt, ze si moc nedovedu predstavit, jak se k tomu postavit, kdyby to nekdo delal naschval - a to je jen otazka casu. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer plugin úprava
Trace server ma zdrojak na Assemble: https://www.assembla.com/code/osm-tracer/subversion/nodes Pripadne primo SVN url: https://subversion.assembla.com/svn/osm-tracer/ pokud posles patch, muzu na nej mrknout a pripadne ho tam pridat :) Plugin tracer do JOSM ma zdrojaky tam kde maj zdrojaky i vetsina ostatnich pluginu do JOSM: http://svn.openstreetmap.org/applications/editors/josm/plugins/ Tam mam mozna prava na zapis taky (musel bych overit), nicmene tusim ze jeho autorem je Petr Dlouhy, ktery mam ten dojem tenhle mailing list cte taky ... Martin 2012/9/14 Martin Kokeš sh...@typo3-hosting.com: Ahoj, mohl bych požádat autory Traceru o jeho zdroják, případně o maličkou úpravu - možnost specifikovat URL traceserveru včetně jeho portu v rámci JOSM předvoleb (např. jako plugins.tracer.url=http://muj.server.cz:8080/). Chtěl bych udělat novou online službu, která bude pluginu vracet přímo transformované body parcel DKM/KMD od ČÚZK. Přijde mi lepší použít Tracer než např. ext_tools. MK ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] tracer
Pachatele vetsiny nenavazanych budov jsem pred asi rokem kontaktoval a
pomohl mu nastavit si tracer aby tuhle chybu uz nedelal. Ty stare
budovy ktere byly natrasovany blbe (a neni jich zrovna malo :) ovsem
zustaly.
Takze pokud to nekomu nespojuje budovy, tak at rekne, poslu svoje
konfiguraky pro tlustostenny a tenkostenny katastr a navod k
pouziti.
Nejjednodussim resenim je ty budovy smazat a natrasovat znovu (ovsem
pozor na to jestli na ty budovy nekdo nepridal mezitim dalsi tagy,
jako napr. name, height, building:levels, apod... ktere je pak treba
na nove budovy prekopirovat)
Pokud maj tagy, tak lze napr. celou oblast presunout pryc, znovu
natrasovat, dokopirovat tagy pres copy paste a pak to presunute
smazat.
Martin
BTW: nenavazany budovy jsou napr v Litomericich, cast sem svazal, ale
vetsina neni, a narazim na to docela casto. Pokud nemaj budovy dalsi
tagovani, je casto pak jednodussi celou oblast smaznout a pouzit tracer
znova.
Dne 2011 12 23 18:21 Petr Balíček pbali...@seznam.cz napsal(a):
Pravda, asi bych měl bejt konkrétnější. Přesně jak píšeš - obkreslujou se
čísla budov, šipky a takovýhle věci.
Mnohde sou timhle způsobem zakreslený i louky a jiný pozemky, tam
nepovažju obkreslování z katastru za vhodný řešení, protože v realitě se to
často hodně liší. Hlavně ale ty polygony na sebe nenavazujou a překrejvají
se.
Jako příklad uvedu Jemnici (nebo Jemnice?) na Vysočině, kde sem ještě
nezasahoval, po pachateli se mi teď nechce pátrat.
Původní zpráva
Od: Petr Dlouhý petr.dlo...@email.cz
Předmět: Re: [Talk-cz] tracer
Datum: 23.12.2011 17:22:35
Ahoj,
prosím napiš o jaké prasárny jde, ať to každý ví: Po trasování by se
měli
odstranit body, které vzniknou na číslech budov, značkách S pro
spojení částí
budovy a jiných nečistotách. Pokud je budova pravoúhlá, tak je dobré
použít
ortogonizátor (klávesová zkratka Q v JOSM). Taky je dobré spojit všechny
body na
sebe nalepených budov, pokud to tracer z nějakého důvodu neudělá.
Původní zpráva
Od: Petr Balíček pbali...@seznam.cz
Předmět: [Talk-cz] tracer
Datum: 23.12.2011 12:25:40
Zdravim,
lidi, když používáte k obkreslování budov tracer, kontrolujte a
opravujte to,
co
z něho leze!
V poslední době sem se dal do opravování chyb podle inspektora a ty
prasárny,
co
tam sou, to je neskutečný. Možná by to chtělo víc upřednostňovat
kvalitu před
kvantitou.
Hezký svátky,
PB
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
Petr Dlouhý
petr.dlo...@email.cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Dotaz novacka - sousedici plochy kolem pozemnich komunikaci (prilinani ploch k pozemnim komunikacim)
Navic reneder se sirkou silnic nepracuje (overeno). Jak ktery. Mapnik mozna ne, ale ruzne rederery to resi ruzne. Mapnik pri zoomovani od jiste miry silnici v podtstate nezvetsuje, ale nektere renderery ano ane ktere podporuji i sirku silnice (tag width ...) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Dotaz novacka - sousedici plochy kolem pozemnich komunikaci (prilinani ploch k pozemnim komunikacim)
Obecne by se ve vetsine pripadu liniove (cesty) a plosne objekty (pole, loky, atd...) spojovat nemely (i kdyz jsou vyjimky, napr. pokud hranice nejakeho CHKO je dana definovana stredem slnice) Pokud se napr. pole spoji se silnici, ma to nasledujici nevyhody: * Plocha ma jinou plochu (vetsi) nez ve skutecnosti * klasicke 2d rederery to zvladaji, ale 3d renderery s tim mohou mit mozna problem (pri trose smuly muze napr. pole koncit v pulce silnice) * V editoru se s tim hur manipuluje - kliknu na silnici a nekdy se vybere silnice,nekdy pole (pokud oboji splyva) * V mistech kdy se plocha odpojuje od silnice muzou vznikat ruzne nepresnoti * Pokud se později namapuje něco mezi hranicí plochy a silnice (lavička, lampa, strom, ...) tak je pak nutno bud plochy spravit aby se uz nedotykaly, nebo vznikne nelogicnost (lavicka co je kus za krajem pole je v datech uvnitr) Takze bych doporucoval plochy dotahovat jen tam, kde skutecne jsou. Ne az doprostred silnice. Martin On Tue, 12 Jul 2011 22:03:21 +0200, Pavel Bokr (OSM) wrote: Zdravim, Mel bych dotaz ohledne prilinani ploch tesne sousedicich s pozemnimi komunikacemi k cestam reprezentujicim prislusne komunikace. Jde mi o to jestli je nejake pravidlo nebo doporuceni zda-li prilinat sousedici plochy az na cestu v ose komunikace reprezentujici komunikaci nebo ty plochy presne ukoncit na skutecnem rozhrani mezi okrajem komunikace a prislusnou casti krajiny. Treba jestli zastavbu ukoncit treba dle DKM na okaji komunikace se kterou tesne sousedi nebo az na ceste reprezentujici osu komunikace. Nebo napriklad z jedne strany les a z druhe zahrada pokud opet oboji tesne sousedi s komunikaci tak jestli je ukoncit presne na okrajich komunikace (treba opet dle DKM) nebo jestli to napojit na sdilenou cestu v ose komunikace. Kdyz o tom sam tak premyslim tak si myslim ze by bylo lepsi to dotahovat az na tu sdilenou cestu v ose komunikace - vychazim z toho ze pokud je komunikace o nejake sirce (ta je do urciteho zoomu logicky zanedbatelna) reprezentovana linii tak plochy ktere s ni tesne sousedi by se meli aby byla zachovana topologie na tu linii, ktera v sobe predstavuje celou sirku komunikace, taky napojovat (stejne jako je nutne napojovat treba pesiny az do stredu silnice). Renderer si s tim poradi protoze vetsinu komunikaci vykresluje v rozumne siri a taky tam kde je to potreba vykresli potrebnou plochu uz od kraje komunikace podle toho jak ji prave vykresluje. Na druhou stranu trochu pochybnosti mam tam kde je polni/lesni cesta ktera je vykreslovana jen uzkou linii a kolem ni treba oplocena zahrada a les nebo rybnik a les tak jestli tam to pak pri plnem priblizeni nebude vypadat trochu divne. Tady by se mozna vizuelne po renderovani podle soucasnych pravidel rendereu hodilo mozna naopak neprilnout ty oplocene zahrady (skoncit u plotu) a rybnik (skoncit hrane komunikace a rybnika) az k ose komunikace - viz napr: http://a.tile.openstreetmap.org/17/70643/44480.png http://www.openstreetmap.org/?lat=49.94977lon=14.02897zoom=17layers=M Nicmene v globalu se mi zamlouva spise prilinani sousedicich ploch az na cestu v ose komunikace. Jak ale je to spravne? Je na to nejake doporucen? Cetl jsem si neco (ale urcite ne vsechno) z obsahle dokumentace a odpoved jsem nenasel. Koukal jsem do mapy a videl jsem ze se ruzne pouziva oboji takze to mi taky moc nepomohlo. Predem dekuji za odpoved, pokud je to nekde popisovano pak bohate staci link (a v takovem pripade se omlouvam ze obtezuji). Zpresnoval jsem Zahorany (obec Kraluv Dvur) a tam pokud to sousedi tak jsem prilinal az do osy komunikace: http://www.openstreetmap.org/?lat=49.953423lon=14.025149zoom=18layers=M Diky Pavel Bokr ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Oauth strasi?
To že vznikne CC-BY-SA fork je skoro jisté, teď už jen doufat, že ten fork bude jen jeden, nebo že pokud jich bude víc, tak ty ostatní rychle vychcípou a zbyde jen jeden (plus někteří lidi chtěli i PD fork, takže je možné, že vznikne ještě jeden fork, kde ale bude asi jen minimum dat) Pokud v ČR zmizí 20 až 25 procent dat (což je aktuální odhad dle té stránky), tak bych tipoval, že lidi nejspíš utečou k cc-by-sa forku, v jiných zemích to může dopadnout jinak (pokud bude dopad mazání minimální, můžou tam lidi zůstat). Úplný rozpad asi nebude, ale tipuju, že se přispěvatelé rozdělí na tři skupiny, jedna co zůstane na ODBl a pokusí se napravit chaos vzniklý smazáním čtvrtiny dat (tipuju to na většinu lesů a vodstva plus asi celkem dost silnic a dalších věcí - může to být méně než čtvrtina pokud se některé podaří přesvědčit aby odbl akceptovali, ale i více, pokud se ukáže že některé importy jsou s novou licencí nekompatibilní a pak by musela data pryč ať už dotyčný souhlasil s odbl nebo ne) a ta se nejspíš časem bude spíše zmenšovat (asi je těžké dávat dohromady mapu, kde po celé republice různé náhodné kousky chybí). Druhá se přesune na cc-by-sa fork, kde budou data všechny (ale je to fork, ne každý o něm ví atd ...). Třetí odejde a přestane mapovat. Tipuju, že žádná z prvních dvou nebude větší než polovina současných uživatelů. Martin On Tue, 21 Jun 2011 14:21:21 +0200, Jakub Sykora wrote: Ja pockam, jak se to vyvine. Kazdopadne pokud to zpusobi rozpad tohoto projektu, bude me to hodne mrzet - adl jsem do toho dost sveho casu a energie, ktera by vysla dost nazmar. A vkladat znovu energii do neceho co bude zase zacinat od piky, to opravdu ne... K Dne 21.6.2011 14:05, Michal Grézl napsal(a): 2011/6/21 Jakub Sykorakub...@kbx.cz: Abych pravdu rekl, tak jsem tohle moc nesledoval i kdyz jsem vedel, ze to dopadne jako pru.er, ale faze 4 me trochu desi a jeste vic po ni faze 5. Pokud bude clovek pro kompletni dataset muset mergovat finalccby.osm a novou odbl databazi, tak to bude pekne na vite co... Tech dat, ktere z DB vypadnou, nebude malo - vizte [1] K [1] http://odbl.de/czech_republic.html Pokud ty data opravdu smazou, coz udelaji, a nikdo je neda zpet, tak se bude muset zustat u forku, nebot zadne mergeovani pravdepodobne nebude mozne. Nehlede na to ze budeme mozna muset vymazat veskera importovana data, u kterych puvodni vlastnik nebude souhlasit s novou licenci. Pro zacatek http://fosm.org/ ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Oauth strasi?
S novou licencí jsem souhlasil. Souhlasil jsem s tím, aby mé příspěvky byly public domain. Ale hrubě nesouhlasím s tím, aby se mé příspěvky mazaly z jakéhokoliv vnitřně politického důvodu. Tak to jsme na tom stejně. Pokud to provedou, projektu OpenStreetMap předpovídám budoucnost XFree86. Ten projekt také dodnes existuje a vydává své verze, ale téměř všichni uživatelé utekli po vnucené změně licence k forku - k Xorg. Rozdíl je v tom, že kód mezi projektem a forkem projektu lze poměrně dobře přenášet, jsou na to nástroje typu diff, patch a postupy na řešení konfliktů, pokud se patch nedá jednoduše aplikovat. Pro mapová data v OSM na tak dobré úrovni nástroje nejsou (hlavně na to řešení konfliktů), takže to je o dost složitější. Importy by mohly projít jak do forku, tak do OSM (napíše se skript a jen se pustí dvakrát), ale tím to asi tak hasne, většina lidí se asi rozhodne pro fork nebo hlavní projekt a to druhé bude ignorovat. Fork ale (minimálně ze začátku) asi na tom bude hůře co se serverové kapacity týče, takže je možné že místo jedné fungující opensource mapy tu budou dvě nepoužitelné (jedna kde je náhodně vyrvána čtvrtina dat a druhá kde servery budou pomalé a přetížené) Nejlepší by bylo, kdyby si to Odbl rozmysleli :) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] footway=sidewalk
On Tue, 07 Jun 2011 12:54:40 +0200, Jakub Sykora wrote: Zde je trochu problem s tim left a right. Staci aby nekdo otocil silnici a nestesti je na svete... Problem, ze nekdo otoci silnici a nevidi souvislosti ale muze mit dalekosahlejsi nasledky, napr. tim znehodnoti i oneway=yes (jednosmerka povede opacne), relace s roli forward a backward u relaci typu route (autobusove a tramvajove linky, mezinarodni silnice (E ##), atd ...) pak budou taky blbe. Mozna to ma nasledky i na jine veci co mne zrovna nenapadly... I kdyz napr. JOSM nektere tyhle pripady umi detekovat a pripadne i automaticky opravit. Martin Nicmene separatne take mapuji pouze chodniky, ktere jsou od komunikace vyznamne oddelene - siroky pas travy (vic nez metr nebo dva), bariera... Dne 7.6.2011 12:41, Zdeněk Pražák napsal(a): Postup uvedený v odkaze 3 bych používal v případě, že chodníky jsou od ulice odděleny například zeleným pásem nebo zábradlím. U chodníků neoddělených od silnice používám tag sidewalk s hodnotami left, right, both. Takto jsem tagoval ulice v Nechanicích Pražák Původní zpráva Od: hanojeha...@gmail.com Předmět: [Talk-cz] footway=sidewalk Datum: 07.6.2011 11:39:22 Ahoj, na wiki [1] se pred mesicem objevil navrh/postup jak mapovat chodniky, ktere vedou soubezne podel silnic. Rozdilny pohled na vec je patrny uz v diskuzi[2]. U nas se takove chodniky objevili v Brne-Lisni [3]. Povazujete takove chodniky za prinosne a v mape udrzovatelne? Neni lepe predpokladat, ze v obci ulice = silnice + chodnik + pripadna zelen, nebo to osetrit tagem u highway=*? zdravi hanoj [1] http://wiki.openstreetmap.org/wiki/Tag:footway%3Dsidewalk [2] http://wiki.openstreetmap.org/wiki/Talk:Tag:footway%3Dsidewalk [3] http://osm.org/go/0Jv37bp9l-- ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Pro zaj?mavost: Mapa k Bedn?
On Tue, 17 May 2011 18:35:41 +, Pavel Machek wrote: Ahoj! Možná by někoho mohlo zaujmout, že na tradiční pražské šifrovací hře Bedna [1] byla letos účastníkům distribuována specializovaná mapa vytvořená na základě OpenStreetMap v měřítku 1 : 12 000 (vytištěná na formát cca 100×70 cm) s IMHO pěkným stylem (patrně Mapnik, ale Bednu jsem (do)sel (ho-wa-da) (:-), a jo, tohle me hodne potesilo. Protoze ta mapa je papirova, pouzitelna, a profesionalne udelana. Diky CC-BY-SA mam pravo ji nafotit a hodit na web, k cemuz se doufam co nejdriv dostanu. To sice jo, ale pokud je zdrojem pro nafocení mapa co prošla šifrovačkou (obzvláště když na ní skoro celou noc pršelo), tedy poněkud rozmoklá, zmuchlaná a potrhaná, tak to nebude kvalitou nic moc. Spíš by to chtělo přemluvit orgy aby tu mapu dali na web jako třeba PDF (nebo prostě v tom formátu ve kterém to posílali na tisk), případně prozradli co za software na to použili (takže by si pak lidi mohli to samé vygenerovat s novějšími daty, případně pro jinou oblast) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Linky MHD
Sítě MHD jsou většinou dost stálé, probíhají většinou drobné úpravy jednou za rok - už jenom kvůli lidem, kteří jsou na to zvyklí. Tak rozsáhlé změny, jaké popisuje Honza jsou docela neobvyklé. V Praze se moc MHD nemění, když nepočítám teda dočasné překopávky sítě kvůli výstavbě tunelu Blanka (což celkem zamávalo s hodně linkama v okolí, ale pak se zase vrátily zpět), DPP vydá čas od času nějaký seznam s kterými linkami kam hýblo a obvykle tam jsou jen drobné změny pár autobusdových linek, tramvaje dost zřídka (obvykle jen když se zprovozní někde nový kus tratě) Takže může být užitečné to zmapovat, udržovat to pak aktuální není moc práce. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] omezení tagu na 255 znaků
jde to omezení obejít nějak lépe, existuje třeba nějaká dohoda o tom, jak řešit tagy na pokračování? Spíš vymyslet jiné schéma kdy nebudou veledlouhé tagy. Např. že by se destinations zadávaly jako členy relace, takže by existoval člen typu destination a ten by byl pak třeba daný hrad, rozcestník, město, atd Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] dibavod: vodn? toky uvnit? vodn?ch ploch
No jo, ale lidi co to mazali nedavali ty vznikle kousky do relace, ze? Asi ne, ale nekde existuje nastroj, co zjistuje jestli vodni toky v OSM tvori souvisly graf. Pokud by se pustil na CR, tak by se tyhle useky vcelku snadno nasly ... Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] dibavod: vodní toky uvnit? vodních ploch
On Fri, 11 Mar 2011 10:51:08 +0100, Petr Morávek [Xificurk] wrote: Karel Volný napsal(a): Dne Čt 10. března 2011 Aleš Janda napsal(a): Netřeba nic počítat. Mapnik používá „malířův algoritmus“ - nakreslí všechno, přičemž pozdější objekty (ty co jsou výše) přepíšou všechny objekty níže. Ale mapnik není ani zdaleka jediný renderer. Ne všechny renderery používají malířův algoritmus a i u podobných rendererů může být problém např. pokud něco kreslí průsvitně (pak to pod něčím bude vidět). Takže to řeší problém u jednoho rendereru, a co ty ostatní? hm, takže pokud tomu rozumím správně, tak s layer logikou by les nebo vpodstatě jakýkoliv objekt musel mít -2, aby se přes něj vykreslil průběh ponorné řeky (pokud mě v mapě zajímá), která bude mít -1, protože je pod normálním povrchem layer funguje hlavně proto, aby se daly v mapě separovat objekty v rámci stejného nebo podobného typu (např. silnice / železnice, když se kříží mimoúrovňově), které jsou nad sebou nebo pod sebou a říct tak co se má zobrazit nad čím, ale pokud se nějaký typ objektů (např. polotransparentní hranice okresu) zobrazuje vždy nad jiným (např. silnice) tak s tím layer nic nenadělá. Martin Ne! V jakém pořadí se vykreslují jednotlivé objekty je záležitostí rendereru (resp. dodaného stylu) a nemá to (skoro) nic společného s tagem layer. Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] dibavod: vodní toky uvnit? vodních ploch
Spíš by bylo dobré, kdyby se s tím nějaký schopný geoprogramátor popral, průsečíky spočítal jednou (přidal heuristiku, která by jej vytvořila, pokud přítok končí méně než dejme tomu 10 m od vodní plochy) a podvodní části nechal přetagovat automaticky, a to vše nahrál do OSM. Dělat to ručně by byla obrovská práce. Nejdřív bychom se asi měli dohodnout na tom, jaký má být cílový stav a pak teprve přemýšlet jak se do něj dostat. Předpokládám, že se všíchni asi shodneme, že části pod vodou (v rybníce, přehradě), pokud by měly zůstat, tak je musí být možné odlišit od částí tekoucích nad vodou, a to pokud možno bez toho, aby se počítaly průsečíky Jakmile se na tom dohodneme, tak se může jednak začít přetagovávat, jednak to zapsat na wiki a jednak šťouchat do rendererů aby to renderovali podle nového schématu. Takže návrhy: 1. smazat části pod vodou. + vyřeší se problémy s rendererem - tok je nespojitý - nelze zjistit strom toku, délku řeky - ztratí se data která se někomu hodí 2. přetagovat části pod vodou, stylem waterway=underwater_route (nebo něco podobného, jakmile vybereme variantu, tak se už pak nějak dohodneme na vhodném názvu tagu), případně s přidaným tagem underwater_route=river|stream + renderer to přestane zobrazovat + tok je spojitý strom - je třeba naučit nástroje novému tagu 3. přetagovat části pod vodou, waterway nechat a přidat tag underwater_route=yes - nutno naučit renderery aby to nezobrazovali, nebo zobrazovali jinak + tok je spojitý strom Osobně jsem pro variantu 3. K 2 a 3 je pak otázka, jestli chceme (a jestli vůbec v praxi můžeme) nějak rozlišovat případy, kdy ten podvodní tok má správný tvar (odpovídající realitě, pokud by byla nádrž vypuštěna) a kdy ne (tedy je to jen odhad, protože jezero se za posledních pár století nevypouštělo) Dále stojí otázka, zda by měly části uvnitř rybníka obsahovat tag name. Pokud ano, asi by se neměl vykreslovat. Např. mosty na silnicích, což jsou krátké úseky kde je silnice obdobně přerušena tag name obsahují. Tedy bych asi name zachoval, rederery se naučí, že by ho asi spíš zobrazovzat neměly. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] dibavod A04 = ditch
On Tue, 1 Mar 2011 20:02:54 +0100, Jan Masopust wrote: Ahoj, mám pro vás jednu špatnou zprávu. Přetagování jsem navrhoval už hned po importu, ale bez odezvy. Poté, co jsme se více méně domluvili na mazání, jsem už část ČR promazal. Takže nevím ... Ono je to možná skoro lepší - znovu nakreslit těch 1% něčeho (a tentokrát přesně), kde ty data aspoň trochu odpovídala realitě dá asi v součtu méně práce, než procházet těch 99 procent, kde ty čáry jsou buď nesmysl, nebo přibližná duplikate okolních potoků. BTW v mapě je pořád celkem dost duplicitních vodních toků (vždycky jeden z dibavodu a jeden původní), i když celkem ubývají. Napadlo mne, jestli někdo nevíte o nějakém nástroji, co by je dokázal najít (dalo by se možná využít toho, že se cesty často navzájem mnohokrát kříží - vyfiltrovat jen vodní toky je jednoduché, ale pak najít ty křížení je už těžší.) Teoreticky by bylo jednoduché to naprogramovat (cesty by se rozsekaly na segmenty, nacpalo se to do nějaké struktury typu R-strom a pak by se to procházelo a hledalo se křížení), ale lepší by bylo, pokud by šel použít nějak už hotový kód. Existuje nějaký takový nástroj, případně nástroj, kde by bylo potřeba jen minimum úprav aby se dal k tomuhle použít? Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] dibavod: vodn? toky uvnit? vodn?ch ploch
On Mon, 28 Feb 2011 14:35:10 +0100, Marek Prokop wrote: 2011/2/28 Jan Dudík jan.du...@gmail.com: Víme o nějaké zemi, kde proběhl import vodních toků? Dobrá poznámka. Asi neproběhl. Jenže upřímně, právě kvůli tomu importu mám o zakreslování toků uvnitř vodních ploch stále pochybnosti. Většina z vás argumentuje tím, že tam ten tok někde je. To je jistě pravda. Jenže zároveň se musím ptát, kde je. U větších nádrží (slapy, orlík) může být často možné původní tok (a tedy asi i pozici kde by to teklo, kdyby se nádrž vypustila) zjistit např. z historických map. U rybníků, které se vypustí (ať už kvůli výlovu nebo opravě hráze) to jde zjistit v realitě. U rybníků, které se dlouho nevypouštěli je možné, že to nikdo neví a to co je v dibavodu je nejspíš výmysl, který tam někdo frknul právě proto, aby mu to nerozbilo strom toků. Průtok rybníkem by měl z hlediska logiky (stromová struktura toku, atd ... viz argumenty v diskuzi) zůstat, možná by bylo užitečné ho nějak otagovat (aby nástroje jako např. renderer lépe poznali, že tenhle tok je skrytý pod hladinou) Ale otázkou je - co u toků, kde je zjevné, že takhle to v realitě asi opravdu neteče - tam kde ten co dával dohromady dibavod nejspíš věštil z křištálové koule, případně to nakreslil prostě jak mu zrovna ujela ruka (protože ani on nevěděl kudyma pod hladinou teče). Nechat tam data, o nichž víme že jsou nesprávná? Nějak je označit jako nepřesná? Předělat je podle nějakého odhadu (a tak nahradit nepřesná data jen nejspíš o něco málo přesnějšími daty)? Optimální je zjistit jak to tam teče doopravdy a zanést to do mapy, ale to asi v naprosté většině nepůjde. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Označení rychlostních silnic
On Sat, 26 Feb 2011 07:59:07 +0100, Jakub Sykora wrote: Ciste z toho duvodu, ze ceska legislativa odlisuje dalnici a silnici pro motorova vozidla. Myslim, ze to sice poskozuje CR ve smyslu investic a uz se i nekolikrat resilo, ze by se rozdil mezi dalnici a rychlostni silnici uplne zrusil. Nicmene ten rozdil tu porad bude existovat - soubezne s dalnici musi vest silnice prvni tridy jako alternativa pro vozidla, ktera z tech. duvodu na dalnici jet nemohou. U rychlostni silnice tato podminka neni splnena a dost casto to byva jediny rozdil mezi dalnici a rychlostni silnici. Kdyz jsem se ptal v autoskole, tak mi bylo receno, ze jediny rozdil je v tom, ze na dalnici nesmi byt urovnove krizeni (tedy klasicka krizovatka treba se semaforem), tam smi byt pouze mimourovnove (nadjezd, podjezd ...). Kdezto na silnici pro motorova vozidla to byt muze (i kdyz vetsinou spis nebyva). V praxi byva rozdil i v parametrech jako polomer oblouku atd... Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] dibavod: vodn? toky uvnit? vodn?ch ploch
Ja z ni treba pocitam mapu pokryti pro vysilace - je to pro me nejdostupnejsi databaze budov a vyskoych staveb, ktera zatim je. Sice jsou ty budovy treba spatne vysoke, ale porad to dava lepsi vysledky nez vypocet bez nich. Vysky se daji doplnit (pokud je vyska jen odhadnuta, protoze na budove je tag building:levels), pripadne opravit ... i kdyz ne vzdy je k dispozici presna hodnota. Ta mapa pokryti - to jako software ktery napr. pro zadany wifi vysilac spocte odkud je na nej videt? Je ten software nekde verejne dostupny? Pokud uvazuje i vyskova data, napr. ze SRTM, mohl by to byt celkem zajimavy projekt Co se tyka vodnich toku - citim to taky spojite, ale protoze data z vodnich toku nepouzivam, je mi to celkem jedno. Az tedy na fakt, ze kazdy vi, ze Vltava prameni na Sumave a vleva se u Melnika do Labe a to uz po staleti. Ze by byly po ceste nejake pasaze, kde ta reka netece nebo netekla jsme se v zemepise ani dejepise neucili. To ze na te rece vybudovali kaskadu vodnich del je asi vec uplne jina - tok te reky je porad stejny. Akoratze v dost velkem poctu rybniku uz byly ty spojeni preruseny. Co s tim ted? Jenom rict lidem co to prerusovali, ze by s tim meli prestat, pokusit se to navic nejak obnovit zpet (akoratze i tak je pak sance ze se najde iniciativni jedinec co zacne ty vnitrni toky odstranovat), nebo udelat jine reseni (napr. tagovat ty useky uvnitr rybniku tak, aby je renderer nevykresloval, napr. je pretagovat na waterway=waterflow (a na proposed features se to pak dodefinuje jako tok vody v ramci vetsiho vodniho telesa (prehrada, rybnik) co se nema v beznych mapach renderovat), cimz to jednak vypadne z rendereru (protoze tenhle tag nezna), jednak to ma logiku (zachova se informace o tom co kam tece a zustane tak strom vodniho toku co se da nejak automaticky prochazet)) Na druhou stranu, nastroj co sleduje strom vodniho toku by nemel mit problem s tim, ze bude tok sledovat po brehu rybnika, takze by se dalo rict, ze ty vnitrni toky vlastne nepotrebuje. ad posledni veta - ono vsechno jde, otazkou je jak je to slozite. Nebylo by opravdu lepsi vyresit nastaveni renderingu tak, aby tok ve vodnim dile nezobrazoval? Navrhuji ty vnitrni useky zacit pretagovavat napr. na waterway=waterflow (pripadne pak dodat waterflow=stream|river|... pokud se ma zachovat i toto) Pokud se pak pozdeji dohodne jine znaceni, pujde to pres xapi snadno vsechno vytahat, v JOSM behem par vterin hromadne pretagovat a hned zas uploadnout. Alternativne to pujde skoro stejne tak dobre najednou smazat, pokud se tak dohodne :) Aly my přece jen malujeme obyčejnou mapu. OSM nikdy nebude sloužit jako relevantní zdroj dat. V systému, kde si každý může nakreslit co chce to prostě nejde. OSM bude vždy využita jen pro mapu a navigaci, nikdy ji nebude používat někdo, kdo potřebuje spolehlivá, zaručená a ověřená data. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] dibavod: vodn? toky uvnit? vodn?ch ploch
On Thu, 24 Feb 2011 12:05:52 +0100, Petr Morávek [Xificurk] wrote: MP napsal(a): Navrhuji ty vnitrni useky zacit pretagovavat napr. na waterway=waterflow (pripadne pak dodat waterflow=stream|river|... pokud se ma zachovat i toto) Pokud se pak pozdeji dohodne jine znaceni, pujde to pres xapi snadno vsechno vytahat, v JOSM behem par vterin hromadne pretagovat a hned zas uploadnout. Alternativne to pujde skoro stejne tak dobre najednou smazat, pokud se tak dohodne :) Nevidím v tom přínos, jen zbytečnou práci navíc. V prvé řadě, by se měl opravit způsob renderování mapy na hlavní stránce OSM (bug report už existuje) - což je vlastně důvod proč na tohle vůbec došla řeč. Já se domnívám, že po odstranění plochy rybníku/přehrady z mapy, by tam mělo zůstat to samé, co uvidím v reálu, pokud ten rybník vypustím. A ještě jsem neviděl, že by na jedné straně ten potok/řeka zmizely a u stavidla byl nový pramen. Navíc spojité (a propojené) vodní cesty jsou dobré, jak už bylo zmíněno, pro spoustu jiných věcí - počínaje odpovědí na otázku kde tenhle tok pramení?, přes obyčejné spočtení délky vodního toku, až po ryze praktický routing po vodních tocích (stejně jako se to dělá v ulicích města). Tam je ale trochu problém (obdobně jako třeba u routingu pro chodce na náměstích) , že často optimální cesta vede někde uvnitř plochy, mimo zakreslené linie toku, které mi někdy přijdou dost divné, nejspíš by neodpovídaly realitě pokud by se rybník opravdu vypustil. V některých případech pak naopak mohou odpovídat realitě a pak místo 5 km trasy z jednoho konce přehrady přímo ke hrázi takový routing navrhne 20 km cestu po meandrech kudyma tekla původní řeka. Takže i když je lepší tam ty toky nechat, tak se na ně při routingu spolehnout nelze a v podstatě je někdy je lepší ignorovat. Otázkou pak je, jestli se tyhle úseky budou nějak tagovat, nebo se to nechá zcela na software aby si tyhle věci našel a ty úseky si interně smazal, případně z vodní plochy vygeneroval nějaké optimální trasy sám. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] import adres pardubice
Na druhou stranu -- kdyz bude POI oddeleny od adresniho bodu, bude tezke odpovedet na dotaz jakou adresu ma tahle restaurace?. A jak pak řešit kdy na jedné adrese je více POI (například dům s pasáží, kde jsou třeba 3 obchody)? Při spojení POI a adresního bodu by pak buď adresa musela být zduplikovaná na všech 3 POI (což není moc dobré), nebo by byla na jednom z nich a zbylé 2 mají smůlu (což taky není dobré) Asi nejlepší by bylo to vyřešit nějak relací (buď nový typ relace, nebo nějak rozšířit associatedStreet) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Izometrická 3D mapa z OSM
Někde mezi featured images na OSM wiki se objevil screenshot z nového programu - glosm. V podstatě je to OpenGL aplikace, zobrazující 3D mapu lokálně (vcelku rychlé, zvládá to v realtime zobrazovat celou Prahu, ale je to dost nové, takže je to ještě trochu nedodělané) Co mně ale zaujalo je podpora pro 3D budovy - program navíc k tagu height porporuje i tag min_height (tedy výška spodní části budovy nad zemí) a zná tag building:part (tedy část budovy, co se nerenderuje na mapě, typicky část co přesahuje přes půdorys) Napadlo mně, že by se mohla podpora pro tohle dodat i do kýblsoftí 3D mapy, např. jsem takhle předělal Žižkovský vysílač a vypadá to o dost lépe než jak to bylo předtím, viz screenshot http://git.wz.cz/glosm-viewer-zizkovsky-vysilac.png Přidat podporu pro building:part a min_height by mohlo být celkem jednoduché a pak by dost objektů mohlo v 3D mapě vypadat o dost lépe (např. ten Žižkovský vysílač se tvarem už dost blíží realitě) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Fwd: [OpenStreetMap] duplicate nodes
On Sun, 14 Nov 2010 21:12:18 +0100, Petr Morávek [Xificurk] xific...@gmail.com wrote: Jo, určitě... mě jen zajímalo jestli to někdo nemá zautomatizované. Na duplicitní cesty jsem si něco napsal, tak to použiuju na bažiny. Ale hledání duplicitních nodů takhle v místech dělení cest moc snadné není. Mám skript co do něj nacpu dump a vyjede mi mapa, kde jsou vidět duplicitní nody (resp pokud je tam N duplicitních bodů, tak se jich na výstup posledních N-1 zkopíruje). Tohle pak lze otevřít v JOSM a podle toho si vybírat kde se na to podívat, ale přímo z toho výsledku to opravovat nelze (většina nodů je zároveň součástí nějakých cest). Teď je to asi 45000 nodů jako vedlejší důsledek všech duplicit v dibavodu. Výsledek je na http://git.wz.cz/dup_nodes_cz.osm.bz2 pokud by někoho zajímalo, kde ty duplicity jsou. Stručně řečeno jsou skoro všude. honny napsal(a): Ve volných chvílích (v místech, kde zrovna něco mapuju) promazávám zdvojený objekty - mám v tom teda pokračovat? Nic automatickýho nemám. :) Já jen jestli v tom nedělám zmatek třeba. Teď jsem si napsat obdobný skript i na vyhledávání duplicitních cest (celkem to našlo asi 14 000 případů duplicitních cest v ČR), ale spousta jich tam už není. Vypadá to, že velké množství duplikací je (bylo) v pruhu mezi 17. a 18. stupněm. Když jsem zjišťoval jestli je chyba ve skriptu, nebo jestli to někdo opravuje, tak jsem narazil na tohle: http://www.openstreetmap.org/browse/changeset/6362586 Vypadá to, že ty duplicity v ČR už někdo řeší (aspoň pro potoky), tak bych ho nechal ho to dořešit. Jinak duplicitních bažin je asi 5000, při hromadném odstraňování by to chtělo být opatrný, aby se nakonec neodstranily obě kopie (někdo smaže první z těch duplicit, někdo tu druhou a nebude tam ani jedna). Validator v JOSM při odstraňování duplicitních cest postupuje deterministicky (z duplicitních cest nechá tu z nejnižším ID, tedy tu co tam byla první, a zbylé smaže), ten kdo řeší potoky, tak na to jde co jsem koukal asi stejně (zdá se, že používá JOSM). Takže pokud by to někdo dělal, doporučuju, aby použil buď taky JOSM, nebo aspoň stejný algoritmus (z duplikátů tu s nejnižším ID nechat, smazat ty zbylé) Já bych v tom promazávání během regulérního opravování pokračoval, aspoň je pak vidět kde ještě nikdo nic neopravoval (tam kde jsou zdvojené věci) a kde už jo (tam kde nic duplicitního není). Navíc v JOSM je smazání duplicitních v aktuálně staženém výřezu záležitost asi na 3 kliknutí ve validatoru. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] zemský pokryv - využití CORINE dat
On Fri, 05 Nov 2010 11:13:45 +0100 (CET), Zdeněk Pražák zpra...@seznam.cz wrote: Díval jsem se, že například v Rumunsku probíhá import dat o zemském pokryvu (lesy, pole atd) s využitím dat European Enviroment agency (EEA) - project CORINE. Nebylo by možné obdobná data z projektu CORINE využít i pro import zemědělské půdy v ČR. Pokud už někde importují, tak s licencí asi problém nebude. Otázkou je ale kvalita dat. Jak moc přesná ty data jsou a jak jsou stará? Zemědělská půda je trochu vidět z ortofota (uhul, yahoo), s poměrně slušnou přesností je vidět i v katastrální mapě z CUZK. Jak kvalitní ve srovnáním z tímhle jsou data z CORINE? MArtin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] dibavod import
On Tue, 2 Nov 2010 23:11:18 +0100, Pavel Machek pa...@ucw.cz wrote: ...dokoncen. Presneji, jediny o cem vim ze chybi je jedna bazina. Ted by to chtelo nejak vyresit duplicity, a zjistit jestli by nejak neslo importovat C03_KoupalisteVeVolnePrirode . Hmm, a pripadne jestli jsou k necemu MILAN_A16_Brehove_linie . A mozna zjistit jestli je na neco A02... a02 je waterway=ditch? Asi tak v jednom z 20 az 50 pripadu ta linie dava podle jinych zdroju (uhul ortofoto, cuzk) aspon trochu smysl (ze by tam mozna mohlo byt neco cim by mozna mohla tect voda). Jinak je to bude vicemene nesmyslna cara (nebo neco co neni videt v realite, jako treba nejsou na zemi videt vrstevnice nebo rozhrani povodi, pripadne kanalizace - ale nedovedu si predstavit co by to mohlo byt) bez zjevneho vyznamu, pripadne cara, ktera kopiruje existujici potoky (a to vetsinou dost nepresne, takze je imho nemozne, aby po tom nejakym zpusobem nejak tekla voda, at uz to ma vyznam jakykoliv) Umeli by duplicity nejak elegantne vyresit na serveru? Rekl bych, ze by to slo spis obtizne. Jednodussi byde vzit dump, duplicitni ways z nej vyfiltrovat a pak nahrat lokalne do JOSM, duplicity promazat, upload ... a je to :) Pokud by byly problemy (ze by na ty duplicitni ways navazovalo neco jineho, pripadne ty ways byly soucasti relaci), tak by se muselo delat rucne (stahnout kus dat, opravit, upload), ale ten .osm s duplicitnimi cestami by mohl byt dobre voditko kde tyhle veci hledat. Ja bych to moc nehrotil, jak budou lidi dibavod opravovat, tak behem toho prubezne vyresi i ty duplicity ... Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] duplicity v dibavod-baziny
On Sun, 31 Oct 2010 19:52:34 +0100, Petr Morávek [Xificurk] xific...@gmail.com wrote: Právě jsem zjistil, že některé bažiny se naimportovaly vícekrát, viz např. http://www.openstreetmap.org/browse/way/82858253 http://www.openstreetmap.org/browse/way/82791642 Teď co s tím? Je to jen nějaká lokální anomálie, nebo je problém většího rozsahu? Asi by to chtělo poopravovat nějak strojově. Je to problém většího rozsahu (co tak koukám na různá místa tak bych tipl celá ČR). Validator v JOSM to umí najít a jedním tlačítkem všechny duplicitní bažiny ve stažených datech eliminovat (z X kopií nechá jen jednu a to tu s nejnižším ID), což osobně dělám všude kudyma při editaci projdu, Nevím o tom, jestli existujě nějaký plně automatický nástroj. Pokud by existoval nějaký co na to jde z dumpu, tak by bylo riziko, že více lidí použije na ty samá data jiný nástroj, kdy každý z nich má jinou logiku kterou z těch duplicitních cest nechat a tak by jeden smazal první z nich jako duplikát, jeden tu druhou a nebyla by tam pak nakonec ani jedna. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] import dibavod
Hmm.. ve skutecnosti staci stahnout dump z doby pred importem, vyfiltrovat na waterway=, a to budou prave konflikty. To bude fungovat nejaky cas = ale z bude vetsi cast CR opravena (i kdyz to bude nejaky cas trvat), tak to bude chtit neco, co projde cely dump a najde krizici se cesty. V soucasnem stavu vzhledem k tomu, ze i pred importem bylo v mape relativne dost vodnich cest, tak staci najet na nahodne misto v CR, nahrat do editoru ctverec tak 5x5 km a urcite tam minimalne par konfliktu bude :) Mozna bych casem mohl napsat neco co projde dump a vyplivne vsechny cesty co se nejak nekde s necim krizi nebo na tohle uz existuje nejaky nastroj? Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer 7.1
Pár připomínek: 1) V archivu chybí pluginy SmallHoleRemover a LargeHoleRemover. Ty se na některé oblasti katastru mohou hodit. 2) Nebylo by dobré ty změny commitnout i do SVN? SVN repozitář je na assemble, Jan Bilak může udělit práva na zápis. (případně to tam můžu hodit i já ... jsou nějaké změny i ve zdrojáku, nebo se měnil jen config?) 3) obsahuje to i změny ve zdrojáku z SVN? Jako např. možnost specifikovat adresář pro cache? Martin On 2010-09-19, hanoj eha...@gmail.com wrote: Ahoj, na nize uvedene adrese najdete tracer s novym konfigurakem, ktery a) odstranuje z WMS dotazu nadbytecne vrstvy (prehledky) b) redukuje potrebne vrstvy z DKM (cisla parcel, grafika) c) obsahuje korektni adresu wms i po 30/9/2010 http://wiki.openstreetmap.org/wiki/Cz:JOSM/Plugins/Tracer ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Nějaká free data k importu
Možná bych to označil nějakým extra tagem (něco jako fixme=opravdu residential?), aby bylo jasné, že to je asi residential a poznalo se to od území,. co jsou takhle otagované ručně. Martin On 2010-09-15, Jakub Sykora kub...@kbx.cz wrote: Proti landuse residential nic nemam. etsinou to bude jakztakz odpovidat... K Dne 15.9.2010 19:09, Pavel Zbytovský napsal(a): Myslím, že to nebudou ta data co jsem posílal nahoře. Když se podíváte na changeset, tak tam je 83 nodů: http://www.openstreetmap.org/browse/changeset/5690485 Napíšu Medulove, aby to případně revertnul a osvětlil původ dat. Možná za týden se do toho importu pustím, jste tedy pro, aby ta zastavěná území byla landuse=residential? Nebo jsme vymysleli něco vhodnějšího? Zdravím, zby-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Koordinace mapování turistický ch tras KČT
Nevím jaká je obvyklá prodleva mezi projitím a zakreslením. Já zakresluji ihned po návratu z výletu. Možnost duplicitní práce z důvodu nestihl jsem zakreslit mi přijde malá. Pokud výlet je vícedenní pobyt, tak prodleva může být větší. Klidně i týden. Jinak to, že by mě někdo předběhl a zanesl data z mého průzkumu dříve než já se mi stalo jen jednou - holt když jde X lidí na Bednu a jdou velmi podobnou trasou, šance že tam bude více než jeden člověk co se pak bude vrtat v mapě podél trasy už je celkem velká. Ale i tak jsem tam do dat dal pár věcí, které tam ani tak nebyly, holt každý mapuje jinak a všímá si jiných detailů (případně jde k další šifře jinudy :) Ale pokud nejde o organizovanou akci, kde se nahrne na stejnou nebo podobnou trasu pár set lidí, tak je asi riziko dvojitého mapování prakticky nulové. Myslím, že kreslení tras KČT je limitováno především rychlostí mapování. :) U mě to je kolem 3 km/hod včetně kreslení v JOSMu. BTW kolik je kilometrů tras v ČR? ;-) Podle cz wiki to bylo v roce 2002 asi 38 500 km pěších tras v ČR. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] OSM tracer fix
On 2010-09-07, Jan Bilak jan.bilak@gmail.com wrote: Ahoj, díky za úpravy. Na SVNko OSM to samozřejmě klidně dejte - bude to nejlepší. Jen pak prosím sem do maillistu napište na to odkaz, kde se to dá najít. No tak momentálně zdrojáky neobsahují žádnou licenci, takže pro publikování někde v SVNku OSM by chtělo minimálně vymyslet pod jakou licencí to tam dát (GPL2? GPL3? BSD? Jiná? ) no a potom by se to už asi mohlo nechat aby se to nějak vyvíjelo - zatím jsem pro to napsal jeden patch, kde je možné specifikovat adresář pro cache, aby to neplnilo adresář s binárkou cachovanými daty, takže ten bych tam pak mohl přidat :) Mohl bych to tam pak hodit (musel bych k tomu dopsat min. nějakékrátké readme a info o autorivi, licenci, k čemu ten program je a tak ...)... asi bych to tam dal do http://svn.openstreetmap.org/applications/utils/ a tam bych vytvořil adresář tracer-server Martin Honza 2010/9/7 hanoj eha...@gmail.com: binarka http://openstreetmap.cz/tracer/tracer7patched.tar.gz *** supr funguje to, na CZ:wiki pluginu jsem pridal odkaz. diky hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] OSM tracer fix
On 2010-09-08, Jan Bilak jan.bilak@gmail.com wrote: Hmmm, tak pokud je jediný problém to, že k tomu nemohu napsat, že je to svobodný software, tak to nevidím jako problém. Šlo mne o podporu U svobodných licencí je jen omezení co člověk může dělat se zdrojáky a progamem ohledně distribuce, ne už ohledně používání programu. Stímhle omezením už to technicky nepatří mezi svobodný software (což ale pro účely použití v OSM vůbec nevadí :). projektu OSM a ne o to, aby program např. používala nějaká firma pro přípravu map, které pak bude prodávat. Vzhledem k tomu, že výstup z traceru pořád potřebuje celkem dost ruční práce, tak mi takovéhle použití přijde nepravděpodobné. K něčemu takovému by to museli jednak dost vylepšit, jednak tam přidat další části, jako třeba něco co určí kde začít trasovat. A pak by měli jen budovy - myslím si, že ty snadněji získají odjinud. Tak s tímhle to asi nepůjde dát do SVN openstreetmap, nevím jestli tam jdou cpát věci co nejsou svobodný software. Vidím to asi tak na 2 alternativy - 1) zdrojáky, binárky a případná vylepšení budou kolovat mailinglistem jako dosud. 2) hodí se to někam jinam - má někdo nějaký server kde by mohl být svn nebo jiný (git?) repozitář? Vzhledem k tomu, že nejde o svobodný sotware, tak github, sourceforge a podobné využít nepůjdou. Martin Honza Dne 8. září 2010 23:09 Aleš Janda openstreet...@kyblsoft.cz napsal(a): Ahoj, tak přesně takovouhle licenci jsem chtěl taky pro svůj program, jenže pak se stává nesvobodným, viz http://www.abclinuxu.cz/poradna/programovani/show/297980 Nakonec jsem to vyřešil GPLv3. Aleš Janda Dne 8.9.2010 22:54, Jan Bilak napsal/a: Ahoj, v licencích se moc neorientuji. Představoval bych si to tak, že program lze bez omezení použít pro přípravu dat do projektu OpenStreetMap. Program lze bez omezení šířit a měnit s tím, že bude zachována a přiložena tato licence. Program ale nelze použít pro přípravu dat, které by byly komerčně využity, aniž by před tímto využitím byly uploadovány do projektu OpenStreetMap pod licencí, kterou OSM vyžaduje. Aneb když připravíš data pro OSM, tak neaplikuj žádná omezení a klidně data použij i komerčně. Pokud program použiješ, ale o výsledná data se nepodělíš vprojektu OSM, tak data nesmíš komerčně použít (tím se vyřeší to, že třeba data z nějakého důvodu zahodíš nebo předáš někomu jinému pro dopracování, než se uploadnou do OSM). Pokud v tom vidíte nějaký problém, řekněte. Třeba je to blbost. Honza Dne 8. září 2010 22:33 MPsingular...@gmail.com napsal(a): On 2010-09-07, Jan Bilakjan.bilak@gmail.com wrote: Ahoj, díky za úpravy. Na SVNko OSM to samozřejmě klidně dejte - bude to nejlepší. Jen pak prosím sem do maillistu napište na to odkaz, kde se to dá najít. No tak momentálně zdrojáky neobsahují žádnou licenci, takže pro publikování někde v SVNku OSM by chtělo minimálně vymyslet pod jakou licencí to tam dát (GPL2? GPL3? BSD? Jiná? ) no a potom by se to už asi mohlo nechat aby se to nějak vyvíjelo - zatím jsem pro to napsal jeden patch, kde je možné specifikovat adresář pro cache, aby to neplnilo adresář s binárkou cachovanými daty, takže ten bych tam pak mohl přidat :) Mohl bych to tam pak hodit (musel bych k tomu dopsat min. nějakékrátké readme a info o autorivi, licenci, k čemu ten program je a tak ...)... asi bych to tam dal do http://svn.openstreetmap.org/applications/utils/ a tam bych vytvořil adresář tracer-server Martin Honza 2010/9/7 hanojeha...@gmail.com: binarka http://openstreetmap.cz/tracer/tracer7patched.tar.gz *** supr funguje to, na CZ:wiki pluginu jsem pridal odkaz. diky hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Souvislé či nesouvislé trasy K ČT
Pokud vim tak merge relaci JOSM neumi. Osobne v takovych pripadech pouzivam postup ze zachovam prvek s nizsim ID, pokud je to rozumne mozne. Neumí, ale lze otevřít najednou editaci dvou relací a pak na pár kliknutí přes selection (v první relaci označit všechny prvky a kliknout na tlačítko, co je dá do selection v JOSM, v druhé pak se zmáčkne přidání prvků ze selection) přeházet všechny prvky z jedné relace do druhé (a tu pak smazat). Je tam, i tlačítko na automatické setřídění relace, které se pokusí setřídit relaci tak, aby prvky za sebou na sebe navazovaly (ne vždy to jde, např. pokud jsou v trase i odbočky) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] tagování sídel
Další příklad - podle wiki by měl town být 10-100 tis. obyvatel. Našel jsem spoustu obcí, které někdo označil jako town jen proto, že má k tomu místu vztah (možná tam bydlí), přestože obec měla sotva 1000 obyvatel a Rabštejn nad Střelou má asi 20 stálých obyvatel (+pár chalupářů), přesto má status města (ve středověku tam byl hrad a trochu větší osídlení, dnes tam moc lidí není, ale status města zůstal). Takových pidiměst (pod 1000 obyvatel) je víc, byť ne tak malých. Tam by zase asi nechtělo cpát do nich town, byť mají status města, protože jsou pak tyto pidiměsta vidět už od příliš velkého zoomu. ani nemá status města. Ani většina měst, co máme označených jako town, toto nesplňuje. Jak rozhodnout tu hranici? Proto se to dělá podle toho, zda má u nás obec status města, pak je to town, jinak je to prostě village (včetně tzv. městysů). Toto přesně definuje značení a každý ví, jak to má udělat. Oproti stavu, kdy definujeme nějakou velikost - rozlohu/počet obyvatel apod. Možná by oficiální status (obec, město, městys, městská část, část obce) + počet obyvatel k nějakému dni šel docpat do dalšího tagu a pak podle něj případně přetagovávat (město + obyvatelé1000 - village), pokud vymyslíme pravidla podle kterých by to šlo dělat. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] tagování sídel
Ok, špatný příklad, ale je dost jiných pidiměst, viz. http://cs.wikipedia.org/wiki/Seznam_měst_v_Česku_podle_počtu_obyvatel Nejmenší má 71 obyvatel, ale malých měst pod 2000 je asi stovka, což je šestina seznamu. Tagovat slepě město - town nemusí být vždy to nejlepší Martin On 04/06/2010, Mike m...@mikecrash.com wrote: A když se podívám do oficiálního UIR, tak je opravdu Rabštejn nad Střelou jen část obce Manětín, takže jestli to někdo označil jako town, tak je to přesně to, o čem jsem mluvil. On 4.6.2010 14:16, Jiri Parkan wrote: 2010/6/4 MP singular...@gmail.com: Rabštejn nad Střelou má asi 20 stálých obyvatel (+pár chalupářů), přesto má status města (ve středověku tam byl hrad a trochu větší osídlení, dnes tam moc lidí není, ale status města zůstal). Takových pidiměst (pod 1000 obyvatel) je víc, byť ne tak malých. Tam by zase asi nechtělo cpát do nich town, byť mají status města, protože jsou pak tyto pidiměsta vidět už od příliš velkého zoomu. Když se kouknu na wikipedii, dočtu se tam že Rabštejn nad Střelou je bývalé město v severní části okresu Plzeň-sever, dnes část města Manětín. takže to town asi nebude, i když se jako nejmenší město republiky rádi prezentují. Parkis ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] podivna silnice
On 28/05/2010, Jakub Sýkora kub...@kbx.cz wrote: Mozna by take bylo dobre to napsat PMkem primo tomu uzivateli... Ja nemam nic proti leteckym zonam v mape, ale musi to mit hlavu a patu :) Pripadne dotycneho navest rovnou na http://wiki.openstreetmap.org/wiki/Proposed_features at tam navrhne nejaky zpusob znaceni tech zon, aby ty jeho letecke zony mely hlavu i patu i pro ostatni lidi. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] mapnik v obci
Ten samý člověk se v Pardubicích (asi i jinde, ale já kreslím hlavně v Pardubicích) rozhodl obkreslovat z KM také čáry které značí hranice parcel a tagovat je jako plot. Nemusím asi vysvětlovat, že neplatí že hranice pozemku = plot. Ne, ale to jestli tam je nebo není plot někdy jde odhadnout třeba z UHULu. To jestli to tak Zdeněk Pražák ale dělá, nebo to odhaduje jinak ale netuším. Soukromé zahrady by asi měly být odlišené od těch veřejných (nebo třeba výzkumných), měl by tedy asi být nějaký speciální tag, případně specializace nějakého tagu. Možná specializace tagu landuse=residential, jako jsem navrhl tady: http://wiki.openstreetmap.org/wiki/Proposed_features/residential_details Tak na to mrkněte. Pokud by se všechny podobné zahrádky u domů přetagovaly jako landuse=residential + residential=garden, tak by se pak dalo šťouchat do lidí od mapniku aby takovéhle plochy renderovaly aspoň trochu nazelenalou barvou :) Pokud bysme se aspoň tady na wiki na tagu shodli, tak bych to mohl začít přetagovávat. Jinak jsem si udělal výcuc z dumpu a teď je v ČR 14401 zahrad otagovaných leisure=garden (většina jsou ways, něco z toho jsou multipolygony) Z nich jen 19 má tag name: a tedy jméno a tedy to asi budou skutečné zahrady. Zbytek bych tipoval zahrádky u domků (co jsem koukal, obvykle je to shluk pár desítek nebo stovek zahrad pro vesnici nebo město a takových shluků je v mapě pár desítek až stovek) Možná by s tím chtělo něco dělat, dokud je těch zahrad jen 14 tisíc. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] opentrackmap - hrady a další
Nebo chybějící fonty? Pak možná inkscape hrábne po jiných fontech a výsledkem je černý čtverec. Martin On 16/04/2010, Kubajz kub...@kbx.cz wrote: Nevim, kde je problem, ja uz leta pouzivam Inkscape bez problemu na ruznych platformach a v ruznych verzich. Ted minimalne zobrazim vse na ubuntu tak, jak psal Michal. Nemuze byt spis problem v nejake podpurne knihovne (cairo nebo neco takoveho)? K Karel Volný napsal(a): do horoucích pekel, může mi někdo poradit funkční editor SVG? :-/ značku zříceniny jsem zbastlil v oodraw, vypadalo to dobře, tak jsem tak začal kreslit další ... jenže po uploadu vidím, že se to rozsypalo tak jsem zkusil informační tabuli naučné stezky překreslit v Inkscape ... to dopadlo tak, že místo číslice je tam černý flek ... a nejde o nekompatibilitu wiki, ale ten blbej Inkscape si to nepřečte ani sám po sobě, ani po uložení v inkscape svg! tak jsem zkusil karbon (2.1) ... ten sice generuje hezké, čisté, krátké xml bez milionu blbostí, ale neuložil mi tam tu číslici vůbec ... sodipodi už je tak staré, že ho ani nemám v distribuci sakra, to si mám nastudovat normu a napsat si to ručně ve vimu nebo co? K. Dne St 14. dubna 2010 Karel Volný napsal(a): Dne Po 12. dubna 2010 Radek Bartoň napsal(a): Za dva dny odjíždím na 2-3 týdny pryč, ale pak budu mit na OTM trochu času. Pokud se dohodnete na způsobu tagování, můžu pak vytvořit příslušné styly a ikony. V ideálním případě, mi někdo, prosím, sepište wiki stránku, kde by bylo přehledně definováno, co a jak se má vykreslovat (případně stačí jen linky na další relevantní wiki stránky). začal jsem se snažit zde: http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/OTM_značkový_ klíč momentálně je to jen hrubý opis legendy z map KČT, nekamenujte mě, začal jsem to tvořit ve čtvrt na jednu :-) K. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] landuse ve velkém - lesy, pole, louk y
On 13/04/2010, Mike m...@mikecrash.com wrote: To si právě nemyslím, to že má někdo na zahradě jeden strom a záhonek 1*2m z toho celého ještě nedělá zahradu pro dekorativní nebo vědecké účely. Tam patří třeba biologická zahrada apod. Hlavne tim jsou mineny predevsim VEREJNE zahrady - tam kde je mozne do te zahrady vstoupit a prohlizet si ty kyticky (at uz zadarmo nebo se vstupnym) - tedy napr. botanicka zahrada, ruzne zamecke zahrady, atd, pripadne neverejne, ale pro vedecke ucely nebo mozna i nejak vyznamne . Tohle vetsina zahradek u domu nesplnuje (i kdyz lze do nich nahlizet pres plot, nejsou ani verejne, ani pro vedecke ucely a obvykle ani nijak vyznamne). A pokud jde o trávu, tak tráva roste všude, to bysme museli označovat každou louku Louky se oznacuji landuse=meadow (vetsi louky napriklad kolem lesu), pokud je to jen nejaky maly travnicek uprostred mesta nebo vesnice, tak landuse=village_green , stejně tak pole apod. Ty se oznacuji landuse=farmland Je mi jasné, že kde kdo dává garden na zahradu u domu a tězko to zastavím, takže se přít nebudu. Vůbec to ale nezapadá do mapy a už vůbec to nezapadá do účelu. Když už, tak tam patří residential. Když pak obec Mozna vymyslet nejaky pod-tag, ze by se zahrady u domu znacily landuse=residential, residential=garden. Pripadne residential=grass pro bloky domu, mezi krerymi je spise volne pruchodna trava, typicky sidliste. Dal jsem na http://wiki.openstreetmap.org/wiki/Proposed_features/residential_details navrh na lepsi tagovani tohohle, takze by se tenhle problem mohl pripadne diskutovat tam i s ostatnimi lidmi. je kvůli zahradám celá zelená, kdežto kolem obce není nic, přestože tam té zeleně je mnohem víc, tak to vypadá opravdu dost divně. nehledě na to, že žádná jiná mapa to tak nemá. Hlavne kdyz pak nekdo hleda skutecnou zahradu, tak najde akorat spoustu podobnych soukromych zahradek... Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] landuse ve velkém - lesy, pole, louk y
1. landuse=residential - někdo ho používá pro označení bloku obytných budov, ale většinou se v mapě setkávám s tím, že je takto jedním tagem označené celé zastavěné území obce, kde bych spíš použil tag place=city. Taky si myslim, ze by se melo pouzit place=city, obzvlaste kdyz takovehle landuse=residential jde casto i pres neco co by melo byt otagovano jinym landuse (industrial, farmyard, ) 2. landuse=industrial - označovat jednotlivé firmy a areály, nebo celou oblast, např. průmyslovou zónu, bez ohledu na rozdělení pozemků? Někde jsem viděl, že každý areál měl své jméno podle firmy, která ho vlastní, což by bylo ideální, ovšem ne vždy je to z cuzk:km zřejmé, spousta areálů stojí na pozemcích JZD, které mají desítky vlastníků. Myslim, ze oboji je mozne, jednotlive firmy a arealy lze oznacovat pokud vim co komu patri, ale pokud se s tim nechci parat, nebo ty vlastniky neznam a nevim kde presne se to deli, tak je mozne to tam hodit jako jeden velky bezejmenny areal a je to taky spravne. 3.landuse=commercial a landuse=retail - zatím jsem vždy obtáhl blok domů, ohraničený nejbližšími ulicemi, a neřešil, jestli je uvnitř bloku nějaký plot nebo zeď, ovšem nejsem si jistý správností. To je podle mne spravne, extra ploty nebo zdi uvnitr lze dodatecne dokreslit pomoci barrier=fence nebo barrier=wall 4. pořadí vykreslování: pokud landuse=residential označuje celou zastavěnou oblast, bude landuse=park vykresleno nad nebo pod ní? Dále např. landuse=forest Zavisi na rendereru. Da se tomu pomoct tim, ze na landuse=residential se hodi layer=-1 a timpadem se to bude vykreslovat pod parkem (layer=0 je default) A treba Gpsmid to vykresluje v defaultnim stylu blbe i kdyz se to spravne otaguje tagy layer, protoze tam ma nastaveno ignorovat layer a soupnout to do vlastniho layeru se v mapniku vykresluje nad landuse=military. Přitom myslím, že takovéto oblasti (vojenský prostor, národní park atd.) by měly spíš překrývat vše ostatní (s nějakou poloprůhledností, i když např. u Garmin navigace se při průhledné bitmapě citelně zpomalí vykreslování). Nekde se to zpomali, GpsMid treba polopruhlednost neumi vubec. To je ale spis zalezitost jednotlivych rendereru, treba pro Mapnik bych stiznosti podobneho typu smeroval na http://trac.openstreetmap.org/ 5. landuse=allotments - v mém chápání je to zahrádkářská kolonie. Jak tedy značit zahrady ve vesnici? Zatím používám leisure=garden, což ale spíš chápu jako okrasnou a odpočinkovou zahradu, než jako místo se záhonky a ovocnými stromy. Taky si myslim ze je to zahradkarska kolonie. IMHO na bezne zahrady tag neni, ja nekdy pouzivam landuse=redisential (obytna zastavba) coz taky neni uplne presne mozna zkusit na to navrhnout nejaky tag na wiki a zkusit ho tam protlacit mezi pouzivane. 6. Co se týká společných hranic, zatím jsem se jich bál a kreslil jednu oblast těsně podél druhé, viz zahrady a domy na Velehradě: http://www.openstreetmap.org/?lat=49.105719lon=17.398478zoom=18layers=B000FTF (ovšem za správné řešení to nepovažuju a budu se snažit to dělat jinak). Pokud se ty plochy v realite skutecne dotykaji (t.j. neni mezi nimi cesta, potok nebo neco dalsiho co zabira nejak misto a tak opodstatnuje pripadnou mezeru) tak by se mely dotykat i v datech. Sice je pak trochu obtiznejsi editace pokud chci ty oblasti pozdeji z nejakeho duvodu oddelit, ale treba v JOSM lze oznacit oblast a pak spolecnych bodu, dat Unglue ways a ono to ty body oddeli a oznaci, takze s nimi pak lze hybnout nekam jinam. Takze to neni zas o tolik tezsi. Treba u lesu a poli davam spolecne hranice pokud se dotykaji, pokud je tam nejaky pas krovi, potom, mez, nebo neco sirsiho co jednotlive pole oddeluje, tak pak pole z obou stran vedu jen k te hranici (s tim ze ta volna plocha se muze vyplnit necim jinym, nekdy tam pasuje natural=scrub (pokud je to zarostle nejakym krovim), nekdy nevim a nedam tam nic :) Ještě se dotknu importovaných lesů, které jsou tak rozsáhlé, že překračují limit 2000 bodů pro polygon. OpenKýblMap ale neumí vykreslit lesy, které mají vnější hranici tvořenou více než jedním polygonem, stejný problém má i mkgmap a ani Merkaartor 0.14 neumí takovéto lesy zobrazit korektně. Na renderu pak chybí velké GpsMid to taky neumi, ale treba JOSM a Mapnik to umi dobre. oblasti lesa v Beskydech a Krkonoších, Hostýnky a Chřiby jsem opravil podle pravidla, že silnice 1., 2. a 3. třídy nepatří do zalesněného území, takže jsem lesy rozstříhal podle silnic. Beskydy a Krkonoše jsou ovšem rozsáhlejší a míň civilizované, tam podobné rozstříhání bude složitější. Je to správný postup? Postup je to spravny, ale nekdy pracny. Taky se to obcas snazim nejak rozstrihnout kdyz na to narazim a kdyz to rozumne jde. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Bug v Traceru
On 07/04/2010, Jan Bilak jan.bilak@gmail.com wrote: Ahoj, můžeš zkusit: http://jabi.aspone.cz/osm/TraceServerBeta6.zip (mělo by stačit vyměnit jen exe soubor) Je k tomu nekde i balik se zdrojaky? Kdyz jsem nahradil vsechny soubory (zapomnel jsem nahradit SmallHoleRemover.dll v podadresari) tak to sice uz funguje, ale plugin LargeHoleRemover prestal fungovat. Nejspis se zmenilo neco v API a bohuzel nevim co zmenit ve zdrojacich LargeHoleRemoveru aby to zase fungovalo. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Izometrická 3D mapa z OSM
Trošičku jsem přemýšlel, jak by to šlo udělat… pokud je hřiště obdélník (nebo aspoň „skoroobdélník“), je to docela snadné. Pokud ale ne, tak je to dost problém… tam by se buď ta textura prostě nedala, nebo by se muselo dělat asi nalezení maximálního obdélníku, který se do toho polygonu vejde, nebo tak něco. Podle pravidel fotbalu má hřiště nějakou danou velikost - http://en.wikipedia.org/wiki/Association_football_pitch, takže pokud je to příliš velké, tak je možné, že někdo otagoval pomocí sport=soccer i okolní tribuny, zázemí a tak (a pokud moc malé, tak jde nejspíš o trénínkové hřiště pro dorost nebo tak něco :) Druhá možnost je, že pokud jsou dvě (nebo více) hřišť vedle sebe (občas fotbal, ale celkem často např. tenis, kdy je v jednom areálu X hřišť navzájem oddělenými pouze ploty a je to otagoivané celé jako jeden obdélník), tak ten kdo to mapuje prostě nakreslí nějaký obdélník (případně jiný polygon) kolem celého areálu a už se neví kolik hřišť je uvnitř (a pak to nejde tak jednoduše texturovat ...) A také je škoda, že při importu z UHUL se nezachovala informace o druhu lesa. Možná by to šlo nějak doplnit - brát existující polygony z UHULu jeden po druhém, zjišťovat typ lesa (coniferous/deciduous, případně mixed - a u těch mixed pak případně zvážit, jestli by se ten les nedal rozetnout na listnaté a jehličnaté části), na polygon se plácne patřičný tag a jede se dál :) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Izometrická 3D mapa z OSM
udělal jsem novinku v mapě: vykreslování stromů v lesích a parcích (ale ne v městské zeleni). Momentálně vygenerováno v Kralupech, postupně se tím bude dogenerovávat celá ČR. Vypadá to zajímavě, ale zdá se mi, že ty stromy jsou poměrně dost tmavé, skoro až černé. A když jsem si prohlížel ty lesy, tak mně napadla další věc, co by se tam mohla vykreslovat - vzletové a přístávací dráhy na letišti, včetně okolních pojížděcích drah a stojánek (na rendering by to nemuselo být složitější než silnice, svým způsobem to je jen trochu tlustší silnice, i když vykreslovat to i s kompletním značením by bylo pěkné :). Ruzyňské letiště teď vypadá na té 3D mapě takové dosti prázdné ... Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import KÚ
Ke všem obcím bych pak přidal nějaký nový tag, kde by byl status obce, u nás jsou město-městys-vesnice... (je někde nějaký seznam?) Vcelku kompletní data jsou (status a počet obyvatel k nějakému datu) na české wikipedii, takže z toho by to mohlo jít vysosat wiki je navíc cc-by-sa, takže licenčně to nebude problém :) Pocty obyvatel jsou treba i tady v XML souboru: http://aplikace.mvcr.cz/adresa/xml.html (nevim jak je to s licenci, ale tusim ze je to uredni dilo a uz se to snad i nekde v nejakem importu pouzilo ...) Tam ale zase neni status obce (mesto/mestys/) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Mapa hustoty zástavby
Mozna by slo to prekryt/zkombinovat s mapou ukazujici hustotu poctu nodu v OSM a tak zjistit mista, kde sice je zastavba, ale moc dat v tech mistech neni - a tedy by to tam pak chtelo v tech mistech domapovat. Martin On 05/03/2010, Lukas Kabrt lu...@kabrt.cz wrote: Na základě dat, která vznikla pro účely importu adres jsem vytvořil jednoduchou mapku, která znázorňuje hustotu zástavby v ČR. Mapka je ke zhlédnutí na [1]. Žádný hubší význam nemá, ale na podívání je hezká :-) [1] http://sites.google.com/a/kabrt.cz/osm/hustota-zastavby/map.png?attredirects=0 -- Lukas ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Boundary
On 02/03/2010, alik dolezal alik.dole...@gmail.com wrote: Mám jen bobky z toho, co to udělá při uploadu cest, pokud bude nějaký node chybět. Ahoj, mám takovej nepříjemnej pocit, že vám dám možnost zjistit co se stane. Nejsem si jist, jestli jsem při likvidaci duplicitních rybníků (teď už ale v datech žádné duplicitní rybníky nejsou) taky občas nesmazal nějaký ten node (jakmile jsem si tohle vlákno přečetl, tak už jsem si na to dával pozor ). Možná by to šlo vyřešit tak, že se stáhne dump z geofabrik, tam se vyparsují všechny existující IDčka nodů a porovnají se s IDčky co jsou v datech k importu. Ty data kde nějaký node chybí by se daly do extra souboru (zbytek by bse mohl hned uploadnout) a mohly se pak vyřešit zvlášť - třeba nějak přeznačit chybějící IDčka na nová ID a doplnit je tam, což by snad mohlo jít automaticky. Případně to nechat uploadovat jednotlivě po jednotlivých cestách. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer - nastavení
On 27/02/2010, Jan Bilak jan.bilak@gmail.com wrote: Ahoj, přidal jsem podporu nějakého nastavení TraceServeru: http://jabi.aspone.cz/osm/TraceServerBeta5.zip Tak jsem to zkusil a nefunguje to, hází to jakousi exception kvůli nenalezenému filtru: filter name=SmallHoleRemover / Pokud tuhle řádku v defaultním konfiguráku nezakomentuju, hází mi to tuhle chybu: $ mono Osm.Kn.Trace.Server.exe EXPERIMENTALNI VERZE (2) Plugin dir is /m/e/p/josm/tracer/plugins. Plugin SmallHoleRemover.dll loaded. Unhandled Exception: System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary. at System.Collections.Generic.Dictionary`2[System.String,System.Type].get_Item (System.String key) [0x0] at Osm.Kn.Trace.Server.Wms.BitmapFilterManager.AddFilter (System.String name, IDictionary`2 parameters) [0x0] at Osm.Kn.Trace.Server.Config.LoadBitmapFilters () [0x0] at Osm.Kn.Trace.Server.Server.Start () [0x0] at Osm.Kn.Trace.Server.Program.Main (System.String[] args) [0x0] Bez téhle řádky to sice jde spustit, ale pak to hází tuhle chybu: - trace/simple/50.10415000432744;14.36878225455269 http://wms.cuzk.cz/wms.asp?service=WMSVERSION=1.1.1REQUEST=GetMapSRS=EPSG:4326FORMAT=image/pn gLAYERS=knBBOX=14.3660,50.1040,14.3680,50.1067WIDTH=1600HEIGHT=2160 System.NullReferenceException: Object reference not set to an instance of an object at Osm.Kn.Trace.Server.Config.get_Treshold () [0x0] at Osm.Kn.Trace.Server.Wms.TileDownloader.Download (Osm.Kn.Trace.Server.Wms.Tile tile) [0x0 ] at Osm.Kn.Trace.Server.Wms.TileDownloader.Get (Osm.Kn.Trace.Server.Wms.Tile tile) [0x0] at Osm.Kn.Trace.Server.Server.CreateBitmap (Osm.Kn.Trace.Server.Wms.Tile[,] tiles, Int32 resolution) [0x0] at Osm.Kn.Trace.Server.Server.TraceCommand (PointGeo point, IExporter exporter) [0x0] at Osm.Kn.Trace.Server.Server.webServer_GetContent (System.Object sender, Osm.Kn.Trace.Server.WebServer.GetDataEventArgs e) [0x0] ... takže ta nová verze vlastně nefunguje Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import DIBAVOD
Aha, ja nekdy predevcirem nektere casti uz v JOSM opravoval (s validatorem to jde rychle a vcelku automaticky...), takze nektere rybniky tam jsou uz jen jednou. Tak doufejme, ze se toho pri tom revertu nesmaze vic nez se ma (aby aspon jedna kopie zustala) - validator to aspon dela deterministicky (z vice kopii jedne cesty ponecha tu s nejnizsim ID, tedy tu nejstarsi ...). Jinak dalsi problem je v datech nahranych uzivatelem Medulove. Skript, kterym kontroluju cas od casu dumpy na mozne chyby mi na dumpu z dnesniho rana nahlasil asi 10700 duplicitnich nodu od nej (rozprostrenych po cele CR) a co jsem tak koukal, tak je to taky dibavod (byt kazdy rybnik je tam jen dvakrat). pavel ma 13700 duplicitnich nodu (nez jsem vcera nektere casti opravoval, tak jich bylo asi 32000) Takze duplicity od Medulove by taky asi chtely vyresit... Martin On 22/02/2010, Pavel Machek pa...@ucw.cz wrote: Hi! It seems that I created duplicate data when importing DIBAVOD; I assumed that if connection died before closing transaction, no data would be uploaded, and it seems it is not so :-(. Edits in question are: #3938287 February 21, 2010 20:50 dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938219February 21, 2010 21:37 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938181February 21, 2010 21:30 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) #3938082February 21, 2010 21:23 import dibavod, cast 41 11.985,48.587,17.993,50.959 (big) ...they should be duplicates (if not, the biggest one should be left). Now, there are big fat warnings about revert scripts and I'd prefer not to mess up the database even more. What is the best way to proceed? Sorry for the mess, Pavel Pokud jsem se díval na několik rybníků, tak všechny byly nahrány 4x. Například Trubární rybník - cesta č. 50937312 je nahrán ještě jako cesta č. 50932852, 50935613 a 50934642 Praák Původní zpráva Od: Pavel Machek pa...@ucw.cz Předmět: Re: [Talk-cz] Import DIBAVOD Datum: 22.2.2010 08:03:14 Ahoj! Namátkou jsem zjistil, že Pavel nahrál omylem část č. 41 celkem čtyřikrát. Padlo spojeni ve fazi uploading, ale pred uzavrenim transakce. Takze jsem letmo skontroloval ze tam data nejsou (a nebyla?!) a zkusil to znovu. Opravdu je duplicita v datech? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import DIBAVOD
A jak se ma pri tomto postupovat? Ja myslel, ze pro kazdy bod co JOSM uploadne si priradi nove id. Takze kdyz spadne spojeni melo by stacit dat save a tim uz by mel byt XML updatovan o to co se uploadlo. Nebo se mylim? Pokud se pouziuva diff upload tak se nova ID priradi az na konci a JOSM se o nich dozvi az pote, co si server vsechno prebere a ty ID vrati zpatky takze pokud spojeni vyhnije pote co bylo vse odeslano na server, ale predtim, nez JOSM dostane zpet nova IDcka, tak server to tam vse sice uspesne nacpe, ale po vyhnilem spojeni uz nevrati nova ID a JOSM se pak tvari, ze to cele selhalo. A kdyz to clovek zkusi znovu tak tam uz cpe druhou kopii Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Izometrická 3D mapa z OSM
Nesouhlas přinejmenším u školy. Objekt s amenity=school (apod.) _není_ budova školy, ale areál školy. Budova školy _musí_ mít i building=yes. Viz též http://wiki.openstreetmap.org/wiki/Tag:amenity=school Potiz je, ze pokud ma budova zaroven tag skola (a vetsina skol nema areal, pouze budovu) tak se renederuje (na standardni adrese s mapnikem) jako obyc anonymni barak. To neplati jen o skolach, ale napriklad i o fabrikach atd. Pak je ale potreba spravit Mapnik a ne vynechavat tagy u budov. Na spouste skol treba v Praze je pouzito amenity=school na areal (hodne zakladnich skol ma minimalne nejaky dvorek s hristem nebo tak neco) a pak na vlastni budovy uvnitr bud jenom building=yes, pripadne zopakovane amenity=school Mapnik by mel mit svuj bugtracker nekde, takze by mohlo stacit si v nem na tohle postezovat a casem to nekdo (snad) spravi. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Izometrická 3D mapa z OSM
3) máte nějaké nápady na vylepšení? Mohly by se zohlednovat tagy height a building:levels a podle nich pak upravovat vysku domu v mape V oblasti kolem 50.090, 14.477 je takhle otagovanych asi 100 domu, ale pokud by lidi vedeli, ze se ty tagy nekde projevi, tak by treba tagovali vic budov timhle (nebo by tagovaly aspon ty velky, kde pak bude zadani spravne vysky v tehkle mape nejvic videt). Z zizkovskeho vysilace by pak byla vez a ne maly trojuhelnikovy baracek :) Pěkný by byly i kopce a údolí, ale to už by bylo asi dost problematický a nevím, jestli jsou takový data k dispozici. Jsou, daj se pouzit volne dostupna public-domain SRTM data z NASA, presnost pro cely svet je cca 90 metru jsou i presnejsi data ASTER GDEM (tusim 30 metru presnost), ziskane spolupraci NASA a METI, ale ty jsou sice volne (no, je treba se prokousat jakousi registraci) dostupna a stazitelna (bohuzel ne jednoduse jako treba pres wget -r ale maji tam jejich uchylny system s rezervacemi download slotu), ale uz je tam nejake omezeni na redistribuci. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer na rozpoznání budov z katast r. map
On 13/02/2010, Petr Dlouhý petr.dlo...@email.cz wrote: Ahoj, v Praze, například, už začínají docházet nezmapovaná KÚ, která jsou kreslená tlustými čarami. Zbylá území jsou kreslená čárami tenkými a na těch se Tracer moc nechytá, takže to dá výrazně víc práce. Jiná města jsou třeba skoro celá kreslena tlustými čarami - např. Hradec Králové, takže by šlo do vyřešení problému trasovat tam. Co jsem koukal i jinde, tak i menší města (odhadem tak od 3 obyvatel výše, ale je ti různé...) jsou často trasována tlustými čarami. Nešlo by upravit Tracer server pro tenké čáry? Hlavní problémy jsou dva - slučky a díry v čarách. Slučky asi budou tvrdší oříšek, a asi jsou zatím důležitější věci na práci (například import adresních bodů). Díry by ale možná šly vyřešit jednodušeji. Nešlo by udělat, aby šlo nastavit, jak moc velkou dírou ten flood-fill proleze? V tlustých čarách je naopak problém s tím, že u některých garáží to občas neproleze kolem nápisu vedle kterého je úzká díra. Zkusit na to pustit dilataci? http://en.wikipedia.org/wiki/Dilation_(morphology) Sice to nepomůže s garážemi, ale mohlo by to vyřešit tenké polygony s dírami. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer na rozpoznání budov z katast r. map
používáš starou verzi Traceru. V té, co je dostupná přes pluginy JOSM (verze 19892, beta 3 serveru) je vše vyřešené kromě změny stávajících budov. Ortogonalizace bloku budov se dělá přes shift + trasování. Je někde k tomu dokumentace nebo nápověda jak tyhle rozšířené funkce aktivovat? Napadlo mně ještě jedno vylepšení - V ConnectWays.java jsou natvrdo zadrátované konstanty: final static double MIN_DISTANCE = 0.05; //Minimal distance, when nodes are merged final static double MIN_DISTANCE_TW = 0.05; //Minimal distance, when node is connected to other way final static double MIN_DISTANCE_SQ = 0.05; //Minimal distance, when other node is connected this way final static double MAX_ANGLE = 30; //Minimal angle, when other node is connected this way Co jsem to zkoušel, tak se mi zdá, že k ostatním budovám se to připojuje příliš agresivně, takže by se hodila možnost si tyhle konstanty v nastavení změnit. Možná bych i snížil defaultní hodnoty z 0.05 na 0.03 nebo 0.04 A pak by neškodilo, pokud by šlo definovat jiné URL traceru než natvrdo zadrátované http://localhost:5050/; (rád bych si pustil tracer na vzdáleném stroji s lepším CPU i připojkou do netu) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer na rozpoznání budov z katast r. map
zkoušel jsem odstranit dialog a udělat z trasování normální vlákno. Problém nastane když se trasuje a zároveň se přidávají nody (nebo jiná podobná akce), tak to vyhodí výjimku, protože UndoRedoHandler není připraven na vícenásobný přístup. Potíž je v tom, že nevím jak přístupy do UndoRedo synchronizovat bez toho, abych modifikoval JOSM. Má někdo nápad, jak to vyřešit? Asi modifikovat JOSM. Je tam víc věcí které by mohly běžet na pozadí zatímco člověk dále edituje. Kromě traceru třeba i stahovaní GPX tras ze serveru, stahování nových OSM dat pokud se stahují do nové vrstvy, s trochou štěstí i věci jako download parent ways/relations, takže pokud by se tam přidal nějaký zámek na editaci a nějaké info okénko říkající co běží na pozadí za věci, tak by to bylo asi nejlepší :) Rozhodně by to zjednodušilo práci s tracerem, člověk by to naklikal a pak by si jen chvíli počkat až se mu všechny domy vytvoří místo kratšího či delšího čekání po každém kliku :) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer na rozpoznání budov z katast r. map
Taky se mi zda, ze tracer ma problemy s nekterymi vetsimi budovami, treba od tehle vytrasuje jen roh: trace/simple/50.08182736797727;14.513559241177791 a nektere nevytrasuje vubec Neni tam nejaky limit na maximalni velikost budovy? Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer na rozpoznání budov z katast r. map
Tak jsem si doinstaloval mono a zkusil to. Vcelku to funguje, v nekterych oblastech je uspesnost skoro stoprocentni, v jinych to trochu pokulhava. Par postrehu: - Obcas to misto domu vezme cely pozemek, jako treba tady (c.p. 515): trace/simple/50.05549775797148;14.575302979868146 - Kdyz kliknu o kus nize na dalsi dum (c.p. 505), udela to ten samy pozemek, i presto, ze ten pozemek je uplne mimo oblast kam jsem kliknul: trace/simple/50.055289871529034;14.575388459664714 Beta 2 i 3 se v tomhle chova stejne. To je asi oblast, kde to tomu moc nejde (cary jsou v tehle casti katastru celkem dost tenke) Obcas to hodi nejakou exception a nevrati to nic (beta 3): - trace/simple/50.055007144521866;14.576206993474267 System.IndexOutOfRangeException: Array index is out of range. at Osm.Kn.Trace.Server.Tracer.Tracer.SortBorderPoints (System.Drawing.Point[] points) [0x0] at Osm.Kn.Trace.Server.Tracer.Tracer.Trace (Point innerPoint) [0x0] at Osm.Kn.Trace.Server.Server.TraceCommand (PointGeo point, IExporter exporter) [0x0] at Osm.Kn.Trace.Server.Server.webServer_GetContent (System.Object sender, Osm.Kn.Trace.Server.WebServer.GetDataEventArgs e) [0x0] Toihle to hazi hodne na tech castech katastru s tencima carama. - Nezvlada to fialove budovy - na nekterych castech katastru jsou nektere budovy fialovou barvou (nevim presne co to znamena, ale co jsem tak v realu pozoroval, tak jde o nove postavene budovy, obvykle max. rok dva stare. Ale proc jsou fialove to netusim) - Cache si to uklada do adresare s exe, mozna by neskodilo mit moznost nastavit kam to bude tu cache cpat. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer na rozpoznání budov z katast r. map
Ted jsem ale objevil asi trochu vaznejsi chybu - kdyz se mi vytrasuje neco co nechci, tak zmacknu ctrl+Z (undo) a novy objekt zmizi. Ale pokud ten novy objekt prizpusobil nejak budovy v okoli (aby navazovaly) tak tohle uz undo nevrati. Coz pak nejak vede celkem rychle k nekonzistenci dat a padu na exception (undo asi nevraci zpet ostatni modifikovane cesty a ty pak odkazuji na bod mimo data (ten co byl vytvoren a pak pomoci undo zas smazan)). Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer na rozpoznání budov z katast r. map
ten tracker se snažil to čáru posouvat na střed čáry (tedy nejprve obtáhnul vnitřní hranu, pak zkoušel detekovat tlouštky čar a čáru posouvat). Ale moc mu to nešlo. Mám rozpracovanou úpravu, která to myslím trochu zlepší. Chybu to občas udělá, ale je to myslím lepší. Možná by tam šlo mít možnost si nastavit tlouštku čáry natvrdo - server by to trasoval pořád uvnitř, ale pak by to rozšířil ven o nějakou konstantní vzdálenost, kterou by si člověk před trasováním nastavil (třeba by tam byl příkaz v pluginu nastavit tlouštku čáry, pak by člověk namaloval krátkou čáru přes celou tlouštku čáry na katastrální mapě a použila by se polovina téhle vzdálenosti) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Tracer na rozpoznání budov z katast r. map
On 05/02/2010, hanoj eha...@gmail.com wrote: V JOSM ale chybí nástroj na jednoduché vytváření děravých polygonů, takže kdyby ho někdo vytvořil, tak by se mohla ušetřit práce. *** ten plugin multipolygon na to neni pouzitelny? Multipoly by na to mel jit pouzit, pokud se cesty neprotinaji a jsou uzavrene, tak vytvori korektni multipolygon a nastavi vzdy spravne v relaci inner a outer. Co zatim neumi je advanced multipolygons, kdy nektera z vnejsich nebo vnitrnich cest je tvorena nekolika neuzavrenymi cestami, jez spolu tvori uzavrenou cestu (takovy workaround kolem limitu 2000 nodu na cestu). Tam pak jsou vysledky ponekud slabsi ... ale mam to v TODO pro to podporu dodelat. Ale pokud je tam neco co brani pouziti v tomhle pripade, muzu to tam treba taky dodelat. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] OpenStreetMap komerční služba
Nápad to špatný není, ale dárcovské sms jsou na prd (je třeba mít živnosťák, pokud se nepletu) a taky jsou z nich minimální částky pro Na jakekoliv podnikani je potreba mit zivnostak, at uz clovek prijima penize pres sms nebo jinak. Taky mne neco takoveho napadlo, moje idea byla, ze by pro technicky nedostatecne zdatne podnikatele (k tomu aby se tam zanesli sami) byl formular, kde by si clovek vybral co tam chce nacpat (hospodu, obchod, supermarket, ...), dopsal tam pak do kolonek dalsi udaje (oteviraci hodiny, atd ), pak by se nasel v mape a umistil tam bod a ono by to pak vyrobilo node s patricnymi tagy a ten to pak po schvaleni adminem systemu uploadlo. Neco ve stylu kdyz se firma zapisuje treba do seznamu. K realizaci jsem se zatim ale nedostal (a vzhledem k mnozstvi jine prace asi ani jen tak nedostanu). S nejakym zpoplatnenim jsem nepocital, i kdyz mozna by nemuselo byt spatne tam dat moznost dobrovolneho financniho prispevku na domapovani okoli nebo tak neco. Vyhoda meho systemu je, ze admin jen omrkne jestli tam neni zadany nejaky nesmysl a schvali. Prace tak max. na 5 vterin/firmu. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] OpenStreetMap komerční služba
Taky mne neco takoveho napadlo, moje idea byla, ze by pro technicky nedostatecne zdatne podnikatele (k tomu aby se tam zanesli sami) byl formular, kde by si clovek vybral co tam chce nacpat (hospodu, obchod, Taky dobrý nápad. Jak by se ale řešilo zadávání polohy? Adresou nebo GPS souřadnicemi. Obávám se, že se najde spousta lidí, co by nebyli schopni GPS souřadnice správně zadat. Obdobně jako se např. v účtu na OSM zadává poloha bydliště, přes slippy map ... chvíli člověk scrolluje mapou a pak někam klikne a tím definuje bod s tím, že by u té mapy mohlo fungovat i vyhledávání, takže když zadají ulici ve které je jejich podnik (nebo i GPS souřadnice), tak se jim ta ulice zobrazí a oni pak už tam jen najdou kde přesně jsou oni a píchnou se tam. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] vazby?
A nestacilo by, aby protokol umel stahnout vsechny polygony, ktere maji s danym uzemim neprazdny prunik? Stacilo, ale on to AFAIK neumi. A neni lepsi to ten protokol naucit, misto abychom zavadeli ruzne berlicky v podobe tagovani vsech objektu atributem is_in? To neni tak jednoduchy. Protokol by musel umer pro kazdou cestu poznat jestli je to uzavreny polygon, nebo jestli je to jen cesta. Coz je slozitejsi nez se zda, system by musel pomerne podrobne zkoumat tagy aby zjistil co to je (to ze je cesta uzavrena jeste neznamena ze je to polygon - viz. treba zeleznicni okruh u velimi) a pak do hry prichazeji multipolygony, poskladane z nekolika cest (u ceskych lesu, kde vnejsi cesta je delsi nez 2000 bodu je i ta vnejsi cast poskladana z X cest) a tenhle vypocet do znacne miry komplikujici. Vysledkem by asi byl nejaky kompromis mezi tim, ze server to bude odhadovat a nacpe do vysledku i spoustu false positives co vypadaji jako polygon ale polygon nejsou (clovek si krome maleho okoli ulice kde chce mit navigace stahne tez hranice mesta, statu a kontitnentu a pak jeste X cest co jsou nekde pobliz, ale uz mimo oblast a algoritmus je blbe odhadl jakozto polygon) a tim, ze server bude v tomhle presny, ale stravi nad tim nechutne mnozstvi CPU casu. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Nastavení wms pluginu
Pro UHUL ortofoto http://geoportal2.uhul.cz/cgi-bin/oprl.asp?SERVICE=WMSVERSION=1.1.1REQUEST=GetMapSRS=EPSG:4326LAYERS=ortofoto_cbSTYLES=defaultFORMAT=image/jpeg pro katastr http://wms.cuzk.cz/wms.asp?service=WMSVERSION=1.1.1REQUEST=GetMapSRS=EPSG:4326LAYERS=kn-i,prehledky,def_budovyFORMAT=image/pngTRANSPARENT=TRUE Co mám v těchto adresách opravit abych mohl opět dále pracovat Zkusil bych pridat na konec adresy znak , tedy napr. pro UHUL by to bylo: http://geoportal2.uhul.cz/cgi-bin/oprl.asp?SERVICE=WMSVERSION=1.1.1REQUEST=GetMapSRS=EPSG:4326LAYERS=ortofoto_cbSTYLES=defaultFORMAT=image/jpeg; predchozi verze to tam cpaly samy, ale zase se mohl objevit problem pokud nekde bylo WMS, ktery vlastni parametry nemelo, takze misto by tam mel byt jako oddelovac otaznik. Pridani na konec URL by to melo spravit. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Fungují UHUL ortofoto mapy?
on poslední dobou nejak blbne. Chodí jen občas, a když už chodí, tak je posunutý (to se dá spravit). Pokud ti chodí katastrální mapa, tak to pravděpodobně není chyba na tvé straně. Jinak by měla chodit adresa z preferencí pluginu. Je posunuty, ale trochu nepravidelne - kdyz UHUL posunu aby sedel a pak se presunu o par kilometru vedle, tak uz zase o kus nesedi, takze posun to spravi jen lokalne, v malem okoli. Pri posunu treba z Prahy do Brna to musim zase posouvat. Takze se da akorat pouzivat na domapovani drobnosti tam, kde uz neco zmapovano je. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Duplicitni uzly
JOSM má ohledně té rychlosti nějaký nepříjemný bug, už je hlášen tady: Uz je spraven, poslal jsem jim par patchu: http://josm.openstreetmap.de/ticket/3347 přes sebe mockrát a navíc domy bez č.p. takto smáznout nejde - a těch domů a oblastí vůbec šílené množství, nevím jestli se do toho má cenu vůbec pouštět. Navíc duplicitní cesty vidět nejsou. Uz jsou detekovatelne ve validatoru: http://josm.openstreetmap.de/ticket/3367 Lze tim smaznout jakekoliv duplicitni cesty (stejne souradnice uzlu, stejne tagy) zcela automaticky. Obcas neco ruco pomazu, ale je to prace na ... promaz sem tam Uz jsem to promazal :) Dodatek 2: !!! OPRAVIT rozhodne NEPOUZIVAT !!! To se hodi az ve finalni fazi (pote co byly opraveny vsechny duplicitni ways, pak po znovukontrole z toho vyplyvajici izolovane body). Bohuzel na duplicitni relace zatim nastroj neni, ale tech bylo tak malo, ze to slo rucne. zduplikovany) a kolem 100 uzlu trva JOSM cca 30 - 45 minut (jak kdy). Po aplikovani noveho patche JOSM zvlada 800 bodu za 5 sekund. Takze 1500 musi byt na cely den (predpokladam ze to JOSM neprezije a S novym validatorem by to mohlo byt tak na 10-15 sekund. vytuhne, coz se mi take nekolikrat stalo). Jinak krom ces se v okoli Kralup duplikovaly i relace a ty taky nelze likvidovat automatizovane. To by slo do budoucna zlepsit ... IMO je chyba to, ze pri likvidaci se slucuje. Pokud jsou body/cesty/relace totozne, mela by se ponechat nejstarsi (s nemensim ID) U duplikace cest se to tak dela. U duplikace nodu uz castecne taky: Patch na http://josm.openstreetmap.de/attachment/ticket/3384/mergenodes.patch to resi, pokud maji duplikovane body stejne tagy, tak se jeden smaze (nevim jestli vzdy nejstarsi, tak moc jsem se v kodu nehrabal) Automaticka deduplikace relaci zatim ve validatoru pokud vim neexistuje. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Dotazy začátečníka #1
Ta situace na http://osm.org/go/0J0lmEIoY je opravdu legracni. Supluje to nemoznost jednoho mostniho telesa pro vice trati tim, ze je pod tim tunel. Kdyby tam chybelo mostni teleso, dalo by se s tim souhlasit (dira v zemi vylozena betonem a nahore na travniku polozene koleje. Ale pokud je to most s mostovkou, tak by spravne mely lezet ty koleje na moste. Prozatim ale spolecna mostovka nejde. Nicmene az budu mit chvilku, tak to predelam, cimz autora asi dost nastvu :) Mozna by stalo zkusit ji navrhnout na http://wiki.openstreetmap.org/wiki/Proposed_features a nejak se dohodnout jak by se to melo tagovat. A pak teprve to pripadne predelat v datech :) Ono to skoro i je tunel. Dalsi podobny jsou treba v Libni, na Prumyslove v Hostivari a jinde, kde zeleznicni most pres silnici ma tolik koleji, ze to pod tim vypada uz jako tunel (dlouha, osvetlena dira ...) Tunely sice byvaji razene nebo jinak vrtane, ale nekdy jsou stavene tak, ze se vyhrabe velka jama, postavi se steny, pres to se hodi nejaka betonova deska a pak se to zahrabe zase nejakou vrstvou hliny (treba i jen metr). IMHO tyhle hodne siroke mosty bych zatim tagoval jako tunel (dokavad se nevymysli jak rozumne tagovat spolecne mostovky), normalni viadukty bych tagoval jako most. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Dotazy začátečníka #1
2) Když tvořím nějakou amenity jako area, tak nemá ikonku (škola, parkoviště, restaurace), mám to řešit přidáním ještě ikonky navrch (hackování rendereru mapnik) nebo počkat až bude renderer časem zobrazovat ikonky nad areama automaticky? Ne. Nepridavat ikonky, to by pak vedlo k tomu, ze az renderer zacne zobrazovat ikonky nad areama (mam pocit ze u nekterych area to uz dela) tak by tam byly ikonky hned dve, 3) Kdy používat tunel a kdy most? Podle popisu na wiki to je jasné - tunel je vyvrtaný; most položený přes něco pouze pro konkrétní cestu. Ale v posledních pár větách dodávají, že při různém úhlu cest je lepší použít tunel, protože se lépe renderuje. Přeci by se mělo taggovat podle reality a ne podle mapnik-rendereru, ne? Většina viaduktů na Praze 6 jsou tagované jako tunely silnic vespod, přitom to jsou podle mě jasné mosty, jaký je váš názor? U nekterych viaduktu, napr. v Libni, ktere jsou delsi (maji vice koleji) jde technicky o most (na to aby tam mohlo byt neco vrtaneho je tam mezi stropem dole a zemi nahore moc mala vrstva), ale vypada to jako tunel: http://osm.org/go/0J0yAQaEy-- Pokud je uvnitr zespoda uz osvetleni (pokud je nahore vice koleji a dole pod viaduktem je tak vlastne vicemene tunel, i kdyz ne vrtany), tak bych tagoval uz jako tunel, jinak jako most. 6) Jak je to se zastávkami tramvaje, když jsou v obou směrech mapovat obě? s příznakem směru? Ano, pokud nejsou primo naproti sobe, tak mapovat kazdou zvlast 7) Changeset comments v češtině nebo aj? Nekteri pisou v CJ, nekteri v AJ ... IMHO je to pro editovani v ramci CR jedno :) 8) lze nějak v JOSMu schovat dočasně objekt (ty hranice katastrů mě nezajímají ani na mapě) :-/ Bohuzel, pokud vim, tak to JOSM neumi.JOSM sice umi prepinat mezi jednotlivymi styly mappaintu a tak je mozne nechtene veci zobrazit nejakou nenapadnou barvou, nicmene porad na ne pujde klikat a manipulovat s nima. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Jak mapujete zelené plochy ve měste ch?
On 28/08/2009, Pavel Zbytovský m...@zby.cz wrote: Ahoj, ještě bych se tedy zeptal i spolu s Frettiem, jaký tag pro městkou zeleň používat - jde o rozsáhle pruhy trávy často vedle silnic... leisure=common ? Osobne pouzivam landuse=village_green (pokud je to proste jen travnata plocha) nebo leisure=park (pokud to vypada spis jako park a jsou tam kere, stromy apod.) Jinak hranice kreslim tam, kde skutecne jsou, neprotahuju je umele az do osy silnice. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Duplicitni uzly
Otazkou je jestli by nestalo na to udelat nejaky poloautomaticky skript do JOSM, pripadne rozsirit validator - ten umi spojovat dobre duplicitni identicke uzly, neumi ale spojovat duplicitni identicke cesty (v Kralupech je skoro kazda cesta 4x nebo 8x) Pak by slo i v budoucnu opravit podobny prehmat na par kliknuti v JOSM (jediny problem je v tom, ze jak je tam moc domu, tak je JOSM v te oblasti silene pomaly, zkusil jsem dat opravit validatorem asi 1500 duplicitnich bodu a JOSM ted uz asi pul hodiny nereaguje - asi tam bude nejaky algoritmus se slozitosti O(n^2) nebo horsi, takze by se to muselo jeste urychlit aby to bylo pouzitelne na prehmaty takovehleho rozsahu) Martin Problém se tedy, předpokládám, týká Kralup nad Vltavou, Odoleny Vody a všech primitiv (včetně relací), které sem zasahují. Zkusím vše opravit. *** ja jsem sem tam nasel duplikaci nekterych adresnich bodu v Brne, po poslednich hromadnych upravach. zdravi hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Brno v OSM? 60%
Když už je o tom řeč, můžu se zeptat, co můžu použít na ruční pojmenování ulic? Komerční plán města nesmím a obejit všechny ulice se mi zrovna nechce. Bud norc.cz - snimky z ulice, neco jako google streetview kde mame povoleni je pouzivat - tam kde jsou k dispozici, coz je Praha, Brno, Plzen, Olomouc a Ostrava. Staci najit v te ulici ceduli a opsat jmeno, daji se tam hledat i hospody, jednosmerky a jine veci ... :) Casto lze nazev najit na katastralni mape z CUZK, i kdyz pozor, na par mistech jsou jeste stare komunisticke nazvy (Fucikova, apod..) Neco je i v UIR-ADR, to pak bude naimportovane primo v JOSM a staci opsat nazev z okolnich adresnich bodu. Na http://aplikace.mvcr.cz/adresa/xml.html je pak sice kompletni adresar ulic v CR (vcetne seznamu popisnych a orientacnich cisel), ale je to jen seznam bez souradnic. Existuje plugin czechaddress do JOSM, kde je pak mozne tohle zkombinovat s katastralni mapou (kde jsou napsana cisla popisna) a tak ty ulice pojmenovavat. Sam jsem to nezkousel, ale snad by to melo fungovat dobre :) Asi bych zkusil ten plugin, to by mohlo byt nejjednodussi. O dalsich pouzitelnych zdrojich nevim. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Brno v OSM? 60%
[1] http://web.mvcr.cz/adresa/b/brno/index.html [2] OSM way orezane na hranice mesta Brna. Nad popisnou slozkou udelan SQL dotaz: SELECT COUNT(highway) WHERE 1 GROUP BY name. Zaokrouheno na cele desitky. Je k tomu nejaky skript, ze bych to zkusil i pro Prahu a jina mesta a pripadne by se to cas od casu mohlo nejak poustet poloautomaticky? Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Mapovani Krkonos
Sám zatím zneužívám 'highway=service' pro tři různé kategorie cest: jednak nádherné dlouhé rovné asfaltky v polích či lesích, pro které se mi 'track' prostě příčilo dát (ale změním to, už kvůli navigacím, jak jsem se tu teď dočetl); druhak různé cesty vedoucí z obytných center někam pryč na samoty k pár domům, kde mi residential vůbec nesedělo (a potřeboval jsem nějak vizuálně sdělit, že tam nemá nikdo jezdit sporťákem a když u tam vjede, tak ať dává pozor, bude to užší než Pokud je to ulice se jmenem (ale bez asfaltu), tak asi dat highway=residential, ale pridat surface=unpaved, pripadne pridat tag width=... pokud je uzka Pokud je to asfaltka, kde neni zakazany vjezd (a neni to silnice treti nebo lepsi tridy) a vede mezi nejakymi dvemi rozumnymi body a dve osobniu auta se tam muzou alespon jakztakz vyhnout, aniz by jedno z nich skoncilo v prikopu, tak asi highway=unclassified, pro mensi highway=track + surface=paved normální cesta); a treťjak různé krátké odbočky z cesty k pár domům - bývají obvykle sakra úzké a kvalitou někde těsně nad polňačkou... Pro highway=service (je-li tam asfalt), nebo highway=track (pokud je to uz spis ta polnacka) tento třetí typ bych rád, kdyby navigace věděly, že ta cesta sice existuje, ale doporučily by ji až jako poslední možnost :-) I vizuálně by bylo super, kdyby ta cesta prostě vypadala úzká. Nemyslím si, že lanes=0.7 to řeší. lanes=... ne, ale width=... ano (mozna to zatim nepodporuji vsechny renderery, ale to casem prijde :) Mimochodem, jak se řekne tu je závora, třeba taková ta zamčená v lese, aby tam lidi nejezdili auty, ale má uprostřed díru pro cyklisty a peší? barrier=gate + access=foot a wheelchair a bicycle? barrier=lift_gate + foot=yes + bicycle=yes + wheelchair=yes (i kdyz nektere takovehle zavory jsou delane tak debilne, ze by tam vozickar bez cizi pomoci asi neprojel, takze posledni u takovych pripadne vynechat ) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Co je tohle za turistickou značku?
On 22/07/2009, Tomáš Tichý t.ti...@post.cz wrote: No tak s bílou barvou značky jsem se zatím nesetkal. Pakliže může být bílá i jiná než trasa cyklostezka, která se netaguje pomocí kct_barva, tak by se mělo nějak dořešit, jak bílé značky tagovat. Např. v projektu [4] s tím nepočítám (cyklostezky tam zatím nejsou). Pár bílých cykloznaček jsem už viděl, zato neexistují z pochopitelných důvodů žluté. Jestli jsou i bílé lyžoznačky nevím. Mozna bych zkusil najit mapu, ve ktere je tahle cyklostezka vyznecena. Mam takove tuseni ze se tyhle bile znacky v mape znaci zlutou barvou (takze je to vlastne zluta cyklostezka) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] ulice a chodníky
Ono by mozna nebylo od veci kreslit (alespon nekde) ulice podobne jako reky = vcetne sirky. Na ulici je mozne vrznout tag width (sirka ulice, v metrech), pripadne lanes (kolik ma pruhu). Co se chodniku tyce, tak je navrhovany tag sidewalk: http://wiki.openstreetmap.org/wiki/Proposed_features/Sidewalk Takze tagovat asi podle tohohle navrhu, i kdyz podle diskuze to vypada ze se bude jeste menit. V nejhorsim se to automaticky pretaguje :) Kreslit ulici jakozto plochu (obdobne jako lze reky kreslit pres waterway=riverbank) pokud vim zatim neni podporovano, ale muzete to zkusit nekdo navrhnout na http://wiki.openstreetmap.org/wiki/Proposed_features :) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Nejvice nezmapovana mista
Problem je v tom, ze snad ve vsech mestech se jmena ulic pisou na tabule velkymi pismeny. Nevim jestli by bylo dobre se toho zas az tak drzet a psat treba name=NA VYTONI. Martin On 30/06/2009, Michal Grézl michal.gr...@openstreetmap.cz wrote: v mape by melo byt to, co je napsano na tabuli na zdi baraku. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Nejvice nezmapovana mista
On 29/06/2009, Jan Dudík jan.du...@gmail.com wrote: Ono by pro začátek třeb adost pomohlo, kdyby někdo zkusil udělat mapu čr: - čtverce např. 1x1 km - barevně vyplněné podle počtu uzlů v tom kterém čtverci Jak jsem tu kdysi prezentoval svuj nastroj pro zjistovani kdy se naposled do daneho kusu hrablo, tak jsem ho i vylepsil, aby udelal mapu hustoty nodu. Jenze problem je v tom, ze pokud je v danem ctverci treba nezajimave pole, tak i kdyz bude ten ctverec perfektne zmapovany tak tam bude porad vyssi hustota nez ve meste, ktere je zmapovane z 5%, cili skoro vubec. Pro zajimavost historicky vyvoj (brezen az cerven) hustoty zmapovani CR v OSM. http://git.wz.cz/cz-density-2009-03-15.png http://git.wz.cz/cz-density-2009-04-16.png http://git.wz.cz/cz-density-2009-05-30.png http://git.wz.cz/cz-density-2009-06-19.png Skript, ktery toto vyplodil (skript dostane na vstupu osm dump a vyplodi historii a hustotu nodu): http://git.wz.cz/osm-age.pl A ted otazka: jak se pozna, ktera mista jsou ridka proto ze tam nic neni as ktera proto, ze to tam nikdo jeste nezmapoval? Pokud bychom meli nejaky etalon (podobna mapa hustoty vygenerovana z jineho zdroje), tak by to slo porovnat, ale samo o sobe to asi tak moc nepomuze (jsou videt opravdu velke diry = vojenske ujezdy, ale to je asi tak vse) - bílé čtverce neobsahují nic (uprostřed lesa nebo polí či nezmapované oblasti) - některé obsahují jen pár uzlů (skrz vede silnice, kraj lesa) - některé obsahují hodně = zmapovaná oblast případně zkusit takovou mapku po měsících, jako to bylo onehdá se silnicemi Pokud nekomu ta mapka pripada uzitecna, muzu tam kazdy mesic hodit novou verzi :) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] Export vseho, co editoval uzivatel X
Da se nejak (automaticky) vyexportovat vse, co kdy editoval jeden konkretni uzivatel? Na jedne z ways (id=33620428) jsem narazil na tag source:name=www.mapy.cz, coz znaci, ze asi dotycny nepochopil odkud se muzou (treba katastralni mapy a uir-adr) a odkud se nemuzou (treba ty mapy.cz) veci prebirat. Vypada to, ze za to muze user slimejs - ma ale asi skoro 200 changesetu, coz je na rucni kontrolovani mozna trochu moc. Je nejaky nastroj, co by ty changesety nejak vysbiral a inteligentne prosel/spojil, pripadne pak neco, cim by nektere casti sly revertovat? Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Zaverecne hlasovani o adresach
Volim 1: čo ... addr:streetnumber čp ... addr:conscriptionnumber če ... addr:provisionalnumber Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] Nejvice nezmapovana mista
Vcelku casto se stava, ze nekdo nekde chce pouzit openstreetmap, ale pak zjisti ze jeho oblibene mesto tam je zmapovane stylem dva hlavni tahy skrz a pak nic takze z toho sejde. Priklad s Pelhrimovem, ktery jsem tu zminoval pred par dny nekdo zkazil tim, ze ho mezitim trochu domapoval, ale porad je dost mest (napr. mesto Tepla), ktere nejsou v podstate vubec zmapovane, i kdyz takovychhle pripadu postupne ubyva. To, ze nektera mista jsou zmapovana dobre, ale nektera naopak dosti spatne je asi momentalni nejvetsi slabinou openstreetmap. Napadlo mne udelat nejaky skript, ktery by nachazel tyhle slaba mista openstreetmap - jeho vystup by pak sel nejak vyuzit (bud tam zamerit pozornost a misto nejak domapovat pres cuzk/uhul, pripadne tam zamerit cinnosti jako napriklad nedavny napad schovavat geocache na nezmapovana mista, atd...) Problem je ale jak to zjistit. Na http://aplikace.mvcr.cz/adresa/xml.html je seznam ulic, kde by ke kazde obci slo zjistit kolik k ni patri jakych ulic a pak to porovnat se stavem v OSM, ale jednak nebude uplne jednoduche tenhle seznam namatchovat na ulice v OSM (i kdyz nejak to vyresit pujde, asi pro kazdou ulici v OSM se vybere seznam moznych mest kde by mohla byt (ktere obsahuji ulici tohoto jmena) a pak se to priradi do nejblizsiho z nich - snad jediny problem by mohl byt s malymi mesty hned vedle velkych - cili asi okoli Prahy a Brna), jednak se tim porovnaji jen pojmenovane ulice, ale uz ne jine (treba take dulezite) featury (ulice ktere v osm jeste nemaji jmeno, reky, jezera, prehrady, zeleznice, ) Napada nekoho nejaky vhodny datovy zdroj, ktery by sel takhle pouzivat k (automatickemu) porovnavani kvality OSM? Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Spolupráce na OSM
Ono se muze stat to, ze to nekdo domapuje tak, ze vratit node se spravnym cislem na spravne misto muze byt obtizne. Obzvlaste pokud je umyslem poslat tam nekoho aby to zmapoval, tak je sance ze to tam nekdo driv nebo pozdeji prekope celkem znacna. Takze bud souradnice nejak odvozovat z historie nebo nejakeho changesetu, nebo definovat souradnice cache natolik robustne, aby to prezilo i editace (zalozit to na nodech, se kteryma asi nikdo nebude hybat) Martin On 26/06/2009, Frettie fret...@gmail.com wrote: Hm, to je zas názor. Proč jim pomáhat, když jim to jde ztížit, že? Chápu, že pro danou keš to není problém, ale s tímhle přístupem moc nováčků nenalákáme. A že by se hodili, jistě jsou místa, kde není aktivní nikdo z editorů, ne? 2009/6/26 Petr Nejedlý p...@nejedli.cz: Frettie napsal(a): Ano, nicméně to neřeší to, když to někdo změní, tak bude mít ten člověk problém s nalezením toho správného prvku s tím správným autorem. Aspon se nauci OSM history API 2009/6/26 Pavel Kovář f...@vsetin.org: U každého prvku v mapě je vidět autor ne ?Stačí aby si hledající uvěřil že autorem je skutečně ten autor kdo to má být. S pozdravem Pavel Kovář ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz -- S pozdravem, Jirka Sedláček --- jirisedla...@gmail.com ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Spolupráce na OSM
Je otázka, do jaké míry by to KČT svým členům toleroval.. Z posledního e-mailu [1] my vyšlo, že vedení je proti podobným aktivitám (aktivitám směřujícím k potlačení jejich monopolu) dost nabroušeno. Ačkoliv co jiného by měl být KCT, než organizace shromažďující veřejná data poskytující je veřejnosti? Mají za to snad lidé, co obnovují turistické stezky nějaké peníze nebo jsou to 'jenom' dobrovolníci, jako my? A co říkají na to, že vedení tvrdě prodává jejich práci? Hodně otázek, část z nich bych možná označil za zavádějící a demagogické, ale nic o tom nevím. Jakou vlastne ma pravni subjektivitu KCT? Obcanske sdruzeni? Vychází mi z toho, že pokud se něco někde nezmění, bude s KCT těžká domluva. Jelikoz prodejem dat, kteri pak jini cpou do svych map jako turisticke znacky (pripadne prodejem vlastnich map) si nejspis vedeni KCT vydelava nejake netrivialni penize (a pokud znacky neprekresluji dobrovolnici, tak jejich obnovovani asi nebude zas tak lacine a nejakou cast penez to zas zhltne) tak se mozna boji, ze pokud by se do OSM dostaly turisticke znacky, ze by jim odbyt map a mapovych dat ponekud klesl. Pokud ty znacky obnovuji dopbrovolnici ve svem volnem case, tak by jim tezko mohl KCT zakazovat aby pri obnovovani trasy zaroven nedelali track,log a ten pak poskytli i s patricnym popisem (vocad pocad cervena s modrou, potom zelena) do OSM. Pokud na to maj ale placenou silu, tak ty by to mozna zakazovat mohli. Vedeni se sice muze rozhodnout nespolupracovat (data vam nikdy nedame, smula ), protoze se jim OSM nehodi do kramu, ale zase klacky nam pod nohy (legalne) hazet nemuzou... Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Czech Republic (mala ale nase)
* Mozna to dost zaplaca mapu. Proto by se mohlo pockat na API 0.7, kde by se mohla objevit moznost vrstev (napr. administrativni hranice, topografie), nebo vylouskat z toho jen dilci casti (obce, kraje). Tohle je spis zalezitost editoru (editr dostane vsechny data, ale ty co mne nezajimaji tak si je schovam) - cili tlacit na autory JOSM, Merkaartoru, Potlatche a dalsich aby to tam docpali. Proste by se definovalo par vrstev (reky, budovy, katastralni uzemi) + specialni vrstva zbytek, clovek by si pak vybral co chce videt a editovat Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] adresni body a POI
Ja je osobne rozdeluju. V cisle popisnem je casto vic nez jen obchod (napr. i nejake byty), takze doprostred baraku cislo popisne, a ke kraji (podle toho kde je do nej vchod) pak obchod, pripadne obchody, pokud jich je v baraku vice. U benzinek, ktere obsahuji i restauraci a shop bych osobne tag fuel vrznul zhruba tam, kde jsou stojany, shop a restaurant pak do budovy (tam by mozna uz slo je spojit, ale osobne bych to taky rozdelil, podle toho v ktere casti budovy je restaurace a v ktere je obchod) Pokud je to v jedne mistnosti obchod s vice typama zbozi, tak to uz asi delit nejde, takze pak strednikem (shop=groceries; newsagent; ...) povazujete za vhodne slucovat adresni body a POI? Matne si pamatuji ze o tom sla kdysi rec. Me se to zda charakterem geoprvku reprezentujici POI a adresni body i stavem rendereru za nestaste. Nejen renderery, ale i jine nastroje. Pro vetsinu amenity =townhall; restaurant je neco jineho nez amenity =restaurant; townhall a nepoznaji v tom ani townhall ani restaurant. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Začátečnické dotazy
Silniční síť by zmapovaná měla být celá (silnice I.-III. třídy), samozřejmě oprava nedostatků je výtána. Chybí hlavně ulice v některých městech a vesnicích. Na automatické doplnění názvů ulic z adresních bodů existoval skript, ale nevím, jak to s ním v současné době je. Ten doplňoval názvy ulic podle blízkých adresních bodů. Jednak už asi doběhl (aspoň v Praze, tam už žádné další ulice, které by šly doiplnit už nejsou), jednak není dokonalý (asi tak 5% ulic (můj odhad, nepodložený přesným měřením, pouze tím, že jsem po něm musel někde dost opravovat) označil chybně) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Začátečnické dotazy
Na mape jsem vypozoroval, ze pokud vede cesta napr. po kraji lesa, tak nekde je to nakresleno jako dve linie, nekde jako jedna, kdy les a cesta sdili hranicni body. Podobna situace je u dvou sousedicich ploch napr. (zastavena oblast, les). Logicka se mi zda druha varinta a navic pri jejim pouziti bych rekl, ze vyrenederovana mapa vypada lip. Je to spravne? Jak to resit pokud sousedi dve linie (cesta, potok; cesta, elektricke vedeni), kreslit je oddelene? V tomto směru neexistuje shoda. Obě varianty mají své plusy a mínusy. Já osobně sdílené hranice nepoužívám. Logičtější může být varianta druhá, ale poměrně špatně se edituje. Ještě existuje třetí varianta, a to nechat na té hranici poze jednu way, a té přiřadit tagy obou objektů, případně objekty reprezentovat relací. Idea sice dobra, ale je to nekorektni varianta - neni to dle specifikace, navic snad kazdy ze soucasnych softwaru to nepochopi tak, jak autor zamyslel. IMHO kreslit oddelene pokud jsou v terenu ty veci kus od sebe (mezi potokem a prostredkem cesty obvykle byva nejaka mezera, vedeni stejne tak nevede prostredkem cesty...), pokud se vyslovene dotykaji (napr. les ktery sdili hranici s rybnikem, aneb stromy az k vode), tak bych to udelal bez mezery. Ale jini lide na to maji jiny nazor. S tim souvisi dalsi otazka. Mnoho cest, ktere vedou lesem ho na mape deli na dve casti. je spravny postup ten les spojit do jednoho? Nevadi, ze takhle vnikaji hodne velke polygony? Vetsi polygony spis nespojovat (mozna i nektere opravdu velke polygony (vice nez 1000 bodu) tahle i rozdelovat). Navic je tam limit 2000 nodes na cestu, takze pokud by po spojeni mel vysledny polygon vice tak smula, nepujde nahrat (coz sice lze resit pomoci multipolygonu, ale renderery a jiny software asi nebudou mit moc radost pokud dostanou na vstup obri polygon o 1 bodech) Pokud jsou polygony male (vysledek by mel mene nez 500 bodu), tak asi spojit Snazil bych se drzet s polygony obecne tak pod 500-1000 bodu (v ramci moznosti), s vetsimi se pak hure pracuje. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Začátečnické dotazy
- Doplňování chybějících názvů ulic. Někde chybí sem tam název některé ulice, někde chybí názvy všech ulic. Názvy ulic lze doplnit editací, pokud jsou tyto autorovy známy. Lze případně použít i ruční vkládání názvů na základě jiných zdrojů (mapové servery apod.)? Má to smysl, momentálně asi není v dohlednu nějaká šance na automatický import ulic, byť jsou ve vývinu nástroje, které by to mohly o něco usnadnit (Czechaddress...) ale asi ne zautomatizovat. - Prolezení nezmapované vesnice a vytvoření mapy jejích ulic s pomocí GPS. Má smysl, obzvláště má smysl přidávat různé POI (points of interest), jako třeba obchody, úřady, hospody, lékárny, nemocnice, policejní stanice, telefonní budky, pošty, atd tyhle věci žádným automatickým importem asi nebude možné získat. A to je i to, co v komerčních mapách buď není, nebo je to nekompletní nebo zoufale zastaralé (dost hospod třeba na mapy.cz už neexistuje, jmenuje se jinak, nebo jsou někdy i o 100 metrů jinde) - Co GPS mapování lesních cest, značených stezek všeho druhu, potoků, atd.? Má to smysl nebo je reálná šance na doplnění některých těchto dat hromadným importem v dohledné budoucnosti? Je tu jistá šance na doplnění odvozních lesních cest z UHULu (což je část lesních cest, ale ne všechny) ale nevím, v jakém je to momentálně stavu. Co se potoků týče, tak byl pokus o dohodnutí importu z tuším heis.vuv.cz, ale myslím že se to nakonec selhalo kvůli autorským právům (nechtěli to pustit), takže potoky bych asi spíš v importu nečekal. - Příležitostné ověřování, zpřesňování a doplňování všech stávajících prvků. Tohle je vždy vítáno. Jednak data z automatických importů mají někdy omezenou přesnost, jednak se občas stane, že nějaký nováček s něčím omylem hýbne nebo něco zmrví a pokud se na to přijde, tak to chce napravit. Martin Koordinují se tyto věci nějak nebo aktivita není zase tak velká, aby to bylo nutné? Moc se to nekoordinuje, i když jsou zde pokusy o jistou organizaci, jako např. mapping party Mělník. Ale lidí co mapujou zas tolik není, takže je nepravděpodobné, že by si lidi příliš lezli do zelí (s vyjímkou větších měst, kde někdy je aktivních více lidí najednou v nějaké oblasti, ale zatím jsem se jen jednou setkal s tím, že by dva lidi editovali jednu oblast najednou - já s Mormegilem jsme kreslili cesty na olšanských hřbitovech. Já práci uložil, ale jemu padl před uložením JOSM a když se k tomu chtěl vrátit tak už tam ty cesty byly (ode mně), z čehož byl celkem překvapen) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] komplikovanějších budovy v KN
Jaký je správný postup pro kreslení budov z KN, které jsou v KN rozděleny čarou oddělující části s jinou výškou? ? nakreslit dvě přiléhající budovy: + lze to udělat pouze za pomoci KN + tak to na mapě většinou nacházím - logicky to není dobře, protože uvnitř je to jedna budova To je asi jediny spravny postup pokud se planuje doplneni tagu typu building:height a building:levels. Stejne jako silnice se musi nelogicky drobit na mensi segmenty protoze na ruznych castech muze byt most, tunel, nebo napr. omezeni rychlosti (pak se daji v aplikaci co ty data vyuziva pripadne slepovat podle odpovidajiciho name/ref), stejne tak se musi budova drobit na mensi casti co maji jine vlastnosti. Jinak ne vzdy je to v KN takhle rozdelene. Obcas je tam ruzne vysoka budova jako jeden polygon. ? ignorovat to, a celé to nakreslit jako jednu budovu + logičtější - z KN nemusím poznat, ke které budově objekt patří Taky reseni kdyz se s tim nechci prilis matlat, rozdelit to pozdeji jde vzdycky :) ? nakreslit to jako dvě budovy nad sebou s různým layer + nejlogičtější - z KN nemusím poznat, ke které budově objekt patří - komplikovanější na zakreslení Tohle bude delat bordel, ruzne programy pak muzou dospet k nazoru ze na danem fleku jsou 2 budovy a nemusi byt jasny jak to interpretovat (napr. je jedna dvoupatrova a NAD ni je sedmipatrova? Nebo ta sedmipatrova prebiji dvoupatrovou, ktera tam neni?). Vzhledem k tomu, ze casto na jedne budove (obchodak) byva stavena druha (garaze) a ze pripady kdy je postavena budova, pak je vzduch a pak dalsi budova jsou sice ridke ale vyskytuji se (ruzne obchodni galerie a nekde jsem videl i obrazek, kde bylo ve spodni vrstve postavena budova asi s parkovistem, nad tim vrstva ke vedla silnice a nad tim stadion. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Adresy, finale diskuse
Mozna by sel udelat tag ve stylu: addr:alternate=rice:1234;konscription:2345;some_other_numbering_scheme:3456 Takhle kdyz se prida nejake nove cislovaci schema (da se cekat ze schemata budou pribyvat, jak se bude OSM v case zpresnovat a lidi zacnou mapovat adresy v zemich kde ted treba teprve resi aby tam meli aspon silnice), tak renderer sice nevi jake presne schema, ale muze aspon zkusit zobrazit to za dvojteckou, pripadne v tom hledat. Pokud vi o jaka cisla jde, muze zobrazovat nejak inteligentneji. addr:konskriptionsnummer tiohle neumoznuje (renderer nebude riskovat zobrazovat nezname tagy a ledat v neznamych tazich muze byt nekdy pro koncoveho uzivatele kontraproduktivni (ruzne nesmysly v note, fixme, ...)) BTW proc se nepouzil aspon preklad do anglictiny? Treba addr:conscription_number Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] hranice obce
Tím myslíš, že nejde spárovat příslušné cedule, aby šel poznat vnitřek od vnějšku, resp. se může kvůli chybě stát, že jsou tabule zcela nespárované? To je pravda; asi by to chtělo je svázat do nějaké relace To se muze stat i v realite - sice ne moc casto, ale na nekterych prijezdovkach obcas cedule chybi (na hlavni trase je, ale kdyz jeste pred ceduli uhnu do postranni ulicky, dostanu se do vesnice aniz bych projel kolem vubec nejake cedule oznacujici zacatek obce) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] hranice obce
bohuzel asi nikdy nebudou ) well styled. Predstava, ze v OSM namodelujeme krasne omezeni rychlosti je supr - sam bych za to byl rad - ale nevidim to realne - bude to vzdy pouze priblizne. Priblizne staci. Routing potrebuje vedet max. rychlost aby si spocital jestli je lepsi jet primo, nebo to objet po delsi ceste, kde se ale da jet 90. Presne se to stejne asi nespocita, to by musel routing znat frekvence semaforu, aktualni ucpanost silnice, rychlosti auta v zavislosti na polomeru zatazek (coz zavisi na nalade a zkusenostech ridice, pocasi, povrchu silnice a typu auta), poctu chodcu kteri budou lezt na prechod a tak nutit ridice zpomalit nebo zastavit, poctu policajtu co budou stavet auta a chtit videt papiry, atd, atd ... Na to by mohl nejaky polygon snad stacit, resp. by se do navigace dopsalo landuse=residential v CR - maxspeed=50 (na dalnicich 80) pokud neni dano jinak. Plus mozna asi extra pravidlo aby se to chytlo na obrys prahy a jinych velkych mest, ktere nejsou uzavrene cele v jednom landuse. V nekterych mistech (napr. v Praze v Pisnici) taky treba je znacka zona 40 ktera plati vicemene na celou ctvrt. Takove zony by taky mozna bylo pak lepsi delat nejakym polygonem otazka - Obec je: po chvili marneho premysleni jsem opravdu nevedel a podival se na nabizene moznosti - uzemi ohranicene znackami zacatek a konec obce - to je jak technicka podpora od microsoftu - je to pravda, ale ridit se podle toho neda. Pravidlo je, ze z obce a do obce vede vzdy alespon jedna silnice, kde toto znaceni neni. Otazka je, jestli kdyby clovek vjel do obce nekde kde ta znacka neni, jestli by mu proslo kdyby nedodrzoval padesatku a jel tam treba 90. Pak by melo smysl mapovat ty cedule a brat to nejak bodove, ale nechtel bych pak videt ten routovaci algoritmus :) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] hranice obce
Způsob pomocí polygonu je sice relativně uživatelsky snadno pochopitelný a tak, ale přijde mi jako datově dost nečistý. Čisté by IMHO bylo nějak tagovat ty silnice, ať už rovnou na všech pomocí maxspeed, nebo relací. Seskupování objektů (nodů, wayí) tím, že leží geometricky uvnitř nějakého polygonu, to IMHO leží mimo architekturu datového modelu OSM. Relace: jednak je tu limit 2000 elementu v relaci, jednak je prace s relacemi v JOSM ponekud krkolomna a hlavne pokud nekdo dokresli dalsi silnice, s nejvyssi pravdepodobnosti je zapomene do te relace pridat, takze vysledek bude asi dost nekonzistantni. Tagovani vsech wayi v polygonu - velka duplikace dat a problem s konzistenci jako u relace - nekdo nakresli dalsi silnice a zapomene je oznacit. Nekonzistentni data drive ci pozdeji. Soupnuti polygonu s maxspeed - datove sice neciste, ale routovaci program si pak muze pri predzpracovani ty waye rozsekat podel polygonu (coz neni algoritmicky trivialni, ale da se to udelat v rozumnem case), uvnits si je oznacit a polygon zahodit a lidsky je to editovatelne celkem prehledne. Ja bych volil ten polygon v nejhorsim by se k tomu dopsal nejaky preprocesor co by ty polygony aplikoval a vystupem by bylo zase OSM, jen trochu stravitelnejsi pro pripadne routovaci a jine aplikace. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] hranice obce
No tak motorway a trunk budou mít 130 vždycky, a jinak to upravují cedule, tedy explicitně uvedené maxspeed. Vzdycky ne: motorová vozidla do 3500 kg (3,5 t) a autobusy smějí jet na dálnici a silnici pro motorová vozidla mimo obec nejvýše rychlostí 130 km/hod., na dálnici a silnici pro motorová vozidla v obci nejvýše rychlostí 80 km/hod. Takze v obci je to jen 80. Obvykle to tam byva teda explicitne zdurazneno znackou a na nekterych mistech je povoleno i 100... Navic treba kamiony maji max. 80 na vsech silnicich (v obci pochopitelne jen 50). A jak validátor zjistí, že se daná silnice nachází v obci? Tim, ze se nachazi v prislusnem polygonu? Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] N?pad na jednodu??? kreslen? budov
On 05/05/2009, Pavel Machek pa...@ucw.cz wrote: Ahoj! nedávno jsem také začal doplňovat do mapy tvar budov. Nápad jsem měl podobný, ale poměrně prozatím jsem ho zavrhl. Program by jednak musel poznat, že řadové domy mají společnou stěnu a obrysy obou sousedících domů k sobě přirazit. Kromě toto mapě v katastrální mapě každý druhý dům přes sebe čáru, která ho rozděluje na 2 samostatné oblasti. Program by musel poznat, že obě oblasti ve skutečnosti tvoří jeden dům... Mozna udelat ne automat, ale nejaky poloautomat co praci usnadni. Napr. neco co najde a zvyrazni vsechny rohy v CUZK, ty se pak daji spojovat podel car ... clovek by pak jen volil ktere useky car pridat do domu, takze jednodussi domy co nejsou rozdelene by byly na dve kliknuti (kliknout na tu caru a pak vytvorit dum), slozitejsi na vice (vybralo by se nekolik linii co tvori dum a z nich se to pak vytvorilo) Sice by to nebylo automaticky, ale pokud tim clovek stravi ctvrtinu casu, tak to je take dobre :) podobne tema muzu vypsat u nas na FSV, CVUT, obor Geoinformatika [1]. Resp. rad bych vypsal vice temat souvisejicich s OSM --- mate nejake dalsi konkretni tipy? No, me porad jeste chybi slusna (a rychla!) prohlizecka mapy. Neco jako PJsofti infomapa (ktera je ale komercni a jen pro windows), ale nad osm daty? To mne chybi taky. Na mobilu mam GPSmid, ktery funguje (na to ze to bezi na mobilu) slusne, ale na desktop jsem nic rozumnyho nenasel. Nedavno jsem se po necem takovym ptal na english talku, doporucili mi navit (pekny routovani a zobrazovani, ale neumi hledat a pri vetsim odzoomovani to ma bugy v zobrazeni), travelling salesman (ten jsem nejak nepochopil jak funguje), gosmore (zobrazeni by potrebovalo dost zlepsit, nektery veci to zobrazuje dost divne a nektery vubec, hledani taky neni optimalni, hledam treba palackeho a vyjede mi chrchel ulic u kterych neni napsany v jakym jsou meste ovladani lehce krkolomne, rychlost ujde), kosmos (v monu pry nejede, takze jsem ani nezkousel). Nejlepsi je asi ten gosmore, ale do idealu ma dost daleko. Zbytek bych oznacil za spise nepouzitelne. Svyho casu jsem premyslel o tom ze bych neco takoveho napsal sam, ale vzhledem k slozitosti ukolu a jinym vecem co mam na praci bych to asi nezvladl v rozumnem case dokoncit. Mozna ze casem but nejak vylepsim navit nebo gosmore, pripadne z tech dvou vykucham nejaky kod a zkusim nad tim podstavit neco vlastniho. Kdyby se nekdo chopil formatu ( http://wiki.openstreetmap.org/wiki/GSoC_Project_Ideas_2009#Advanced_file-format_for_OSM_data ) tak by tim dost veci vyresil, ale nikdo se mtoho neujal Je tu jeste josm-ng, kde prohlizeni je celkem rychly, ale loadovani dumpu pro celou republiku trva vecnost a sezere to dost pameti. Jinak... na mff 'vedu' projekt ktery pridava do qgisu podporu osm. Za mesic -- mesic a pul budem potrebovat nejake testery... Hmm ... pujde to pak pouzit i jako prohlizecka OSM? Ze bych se zucastnil testovani? :) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] dotaz na wms služby uhul
Ted jsem to zkusil a zda se, ze uz UHUL funguje ... uz to asi spravili :) Martin On 15/04/2009, Zdeněk Pražák zpra...@seznam.cz wrote: obdržel jsem od správce sítě UHUL odpověď na dotaz k fungování wms ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] ditaz na fungov?n? UHUL mapy v JOSM
Řekl bych, že problém je na straně ÚHULu. Mě to taky nefunguje, a neprováděl jsem žádnou aktulizaci. Funguje ÚHUL někomu? Mne nefunguje cca od patku minuleho tydne. Uvidime, snad ten server dostahuji brzy :) Jinak openaerialmap by mela fungovat a mela mit cache uhulu v rozumnem rozliseni. Mozna v rozumnem rozliseni, ale uz ne v mistech kde to potrebuju. Zatim je tu aspon Yahoo, ktere je sice barevne a novejsi, ale s rozlisenim oproti uhulu ponekud pokulhava. Kdyby nahodou ne, mam svoji vlastni kopii :-). Vlastni kopie? Kolik GB to ma? Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] adresni body do OSM
Podle mne by meli mit servery dostatecne dobre dimenzovane (da se cekat ze to bude vyuzivat siroka verejnost), takze kdyby se ty data ziskavaly rozumne pomalu (1 request za 5 sekund?) tak to na zatezi serveru nepoznaj. Mozna si toho ani nevsimnou :) Sice se ty data budou stahovat dele (tyden? mesic?), ale to asi neni problem, UHUL taky trval dost douho nez se nakonec importoval :). Horsi je to s pripadnymi autorskymi pravy - tady neznam odpoved, nevim pod jakymi podminkami je to poskytovane. Pokud by se vyresil problem s pravy, tak technicky se uz nejaka cesta vzdycky najde :) Martin 2009/3/23 JV j@seznam.cz: Zdravím všechny, já mohu mluvit jen k technickým důvodům - rozhodně by to narazilo na ochrany proti DoS a podobným aktivitám. J.V. Původní zpráva Od: hanoj eha...@gmail.com Předmět: Re: [Talk-cz] adresni body do OSM Datum: 23.3.2009 11:17:26 Ten připojený dotaz vyhledá nejbližší definiční bod a zobrazí k němu příslušné informace - využitelnost posuďte sami, nicméně systematické stahování celé ČR tímto způsobem nedoporučuji. *** nedoporucujes to z technickych duvodu (DoS), nebo z duvodu autorskych prav k databazi? diky hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] adresni body do OSM
2009/3/23 JV j@seznam.cz: Tak ještě jinak - definiční body je položka, která se prodává. Takže rozhodně nelze čekat, že nějakou oficiální cestou bude možné je získat zdarma. Samozřejmě to je můj soukromý názor, doporučuji oficiální dotaz. No, uz jsem se pred nejakou dobou ptal. Na webu CSU zminovali databazi budov, ktera neni ke stazeni, ale lze ji zdarka ziskat kdyz tam clovek zajde osobne. Zeptal jsem se na detaily a tohle prislo jako odpoved: k dispozici zdarma Vám můžeme poskytnout BUDINFO bez souřadnic. Budovy se souřadnicemi lze zakoupit dle ceníku ČSÚ: http://www.czso.cz/csu/redakce.nsf/i/f_registr_scitacich_obvodu_(rso) Struktura atributů: http://www.czso.cz/csu/rso.nsf/i/budovy_s_cislem Podmínky pro komerční využití produktů ČSÚ: http://www.czso.cz/csu/redakce.nsf/i/m_podminky_pro_komercni_vyuziti_produktu_csu_pri_pouziti_smluvnich_cen -- Primo na CUZK jsem se neptal. Ale zase kdyz mame souhlas s pouzitim WMS cuzk, kde ty souradnice jsou (jen by se muselo provest OCR), tak by to mozna slo zkombinovat. U asi 10% budov mame souradnice z UIR-ADR. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Talk-cz Digest, Vol 24, Issue 21
Zkusil jsem si stahnout osmarender a pak spustit: ./osmarender data.osm Jenze po 22 hodinach spotrebovaneho CPU casu stale vysledek nikde - osmarender asi neni urcen na tak velke vyseky, obvykle se s nim renderuji jen male dlazdice (nejspis tam bude pouzit nejaky algoritmus se slozitosti O(n^2) nebo jeste horsi). Koukal jsem na ty data.osm - tam je ale vsechno, ne jen highways (protina to centrum prahy a je tam asi tak 10800 budov), takze mozna to osmarender nerozdychal, vyrobit SVG mapu zhruba 1/4 prahy je na nej asi moc :). Kdyby v tom vyseku byly opravdu jenom cesty (to by mela zajistit URL http://www.informationfreeway.org/api/0.5/way[highway=*][bbox=14.41,49.55,14.52,50.30] ), tak by to mozna jeste slo v rozumnem case osmarenderem vyrenderovat (zkusim to pustit, treba z toho neco vyleze v rozumnem case), jinak bych asi zkusil jiny nastroj (ma nekdo nejaky tip?). Martin 2009/3/18 Rolf K r...@seznam.cz: Opravdu dekuju, ze se tim zabyvas... No pri tom renderovani jsem postupoval podle navodu tady: http://wiki.openstreetmap.org/wiki/Osmarender/Howto Zkousel jsem to dvema zpusoby: 1) Pomoci Xalan, prikaz. radka xalan.jar org.apache.xalan.xslt.Process -in osm-map-features-z17.xml -out map.svg 2) Pomoci MSXLS, prikaz. radka msxsl osm-map-features-z17.xml -pi -o map2.svg Oba tyto zpusoby vygenerovaly svg soubor a nehlasily zadnou chybu, ale ani v jednom z nich nic nebylo... ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Export cest z OSM
Sice se mi povedlo vygenerovat si data.osm s vrstvou cest z pozadovane oblasti (http://rolf.sweb.cz/osm/data.osm), ale kdyz jsem to pak prekonvertil do .svg formatu (http://rolf.sweb.cz/osm/map.svg) a chtel si to prohlednout, tak mi Firefox hlasi To XML vypada na vyplod osmarenderu - ale jaksi neni korektne ukoncene a opravdu moc dat neobsahuje. Zda se, ze to generovani SVG selhalo (cim presne to bylo generovane a s jakymi parametry? Pripadne hlasilo to neco za chyby?) a spadlo predtim, nez se do SVG stihlo zapsat neco vic nez jen hlavicka se styly. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Export cest z OSM
Napriklad XAPI: Navod je na http://wiki.openstreetmap.org/wiki/Osmxapi Pro vyexpotovani cest by to bylo neco ve stylu: http://www.informationfreeway.org/api/0.5/node[highway=*][bbox=14,50,15,51] (je treba upravit bbox ...) Tim dostanu jenom cesty pro nejakou oblast, je potreba to pak jeste necim prekonvertovat do formatu co prijima dane zarizeni ... hmm, v jakem formatu to zarizeni je schopne brat ty data? Martin 2009/3/17 GC Rolf r...@atlas.cz: Zdravim vsechny a preju hezky vecer. Uz nejakou dobu se pokousim mapovat mista, kde se pohybuju a take uz delsi dobu nemuzu prijit na - pro mnohe z vas mozna malickost - jak vyexportovat JENOM CESTY do nejakeho vektoroveho formatu z urcene oblasti. Abych vysvetlil ucel - v navigaci mam klasickou rastrovou topomapu a rad bych si pres ni dal prave tuhle pruhlednou vrstvu cest z OSM. Jen nemuzu prijit jak a jestli to vubec jde. Vektorova podoba je nutna kvuli srovnani meritek. Za vsechny tipy predem dekuju. Rolf ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
