Re: [Talk-cz] jmena cest jako relace
Dne 12.6.2013 00:06, Milan Vancura napsal: uz to tady problesklo pri diskusi u znamek a podobnych veci - co kdybychom do standardu pro CZ zanesli moznost pojmenovavani ulic a cest obecne pomoci relaci? V tomto smeru uz v OSM existuji minimalne dve (! :( ) relace k tomu Ahoj, Takže nejdůležitější na začátek: Jsem pro všema dvaceti, samozřejmě za předpokladu, že bude JEDEN způsob, ne dva, ne neznámo kolik. A domlouvaný mezinárodně. Jsem ochotný pomoct, i s angličtinou. A co si od toho slibuju, nejdříve obecně: 1. jako technik v tom vidím jednoznačný posun v kvalitě dat. Ta ulice je objekt a jako každý jiný objekt má mít svoje tagy uvedené u sebe, tedy právě jednou. Tedy jinými slovy: polymorfismus máme teď, když stejné tagy máme uvedené neznámo-kolikrát-u-nijak-datově-nespojených-objektů. Přesně toho polymorfismu se chceme zbavit. Který jiný objekt máme v OSM uvedený tak, že je rozsekaný na spoustu částí bez přímé datové vazby (odhaduje se jen podle jména a polohy ve stejném městě)? Víte o nějakém jiném takovém případu? A pokud ano (já ne), přijde vám to i tam jako správné řešení?! 2. relace mají v datovém modelu OSM příjemnou vlastnost, že umožňují (přímý a levný) dotaz na své členy. Přesně co potřebuje renderer. Včetně toho, že u cest umíme mít úseky seřazené, aby navazovaly, atp. Teď konkrétní nápady, ale upozorňuju předem, že jsou to jen prvotní nápady: 3. zbavíme se duplikování tagů a tedy i hrozby překlepů. Ani nepočítám, kolik jsem jich opravil jen ve Vršovicích za cca 3 mapovací dny! 4. to samé platí pro neúplné sady tagů. Např. u některých ulic jsem potkal, že jeden úsek měl tag "name" a jiný jen "name:ru". A nebylo to rozhodně jen jednou. Takovou věc ani automat nepozná, to jsem musel projít ručně i nožně. 5. získáme 1:1 vazbu na RÚIAN, jeden objekt v něm bude odpovídat jednomu v OSM 6. z RÚIANu přibudou další tagy, minimálně reference na něj, a ty teď budeme moct dát na jedno jasně definované místo a ne na jakýchsi cest automatem obtížně vyhledatelných - viz odstavce 3 a 4. 7. renderer bude znát objekt jako celek a mnohem lépe bude moct vyhodnotit, kam umístí popisky. Dnes jsou popisky četné podle úseků, na které je ulice rozsekaná v datech, a ne podle potřeby rendereru. A to není chyba rendereru, to je chyba dat! Chceme mít popisek jednolitého objektu a přitom ten objekt nemáme definovaný. Jediné co máme je primitivní heuristika typu "na mosty se dávat popisek s jménem ulice nemusí". A když taková heuristika chybí pro nějakou kombinaci chybí, lidi to "řeší" tím, že vyhodí tag "name" z nějakého objektu, třeba mostu nebo tunelu. Úprava dat podle rendereru, přesně to, co se nemá dělat. Toť zatím vše, klidně přidávejte nebo diskutujte. Milan Nejsem proti. Navíc, nějaký návrh už ve wiki je, stačí jej jen dopracovat a začít používat: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street Ideální by bylo toto nějak zakomponovat do editorů, aby byla práce s těmito relacemi co nejjednodušší. Ideálně tak, aby se o vše pokud možno staral editor bez nutnosti do toho manuálně zasahovat. Napadá mě třeba rozdělení ulice s mnoha segmenty na dvě. (dejme tomu, že se politici zblázní a ulici fakt rozdělí na dvě nezávislé půlky ;-) ) Pokud bude původní ulice jako relace, není rozdělení na jedno kliknutí. Chtělo by to něco jako "Split relation", případně další nástroje (které mě teď nenapadají). Nevím, možná už něco takového existuje. A když už jsme u toho, stejně by se mohlo udělat i omezení rychlosti, pokud je v části ulice rychlost omezená a v OSM to je více segmentů. Taky by se tím omezily duplicity tagů. Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] jmena cest jako relace
> Napadá mě třeba rozdělení ulice s mnoha segmenty na dvě. (dejme tomu, že > se politici zblázní a ulici fakt rozdělí na dvě nezávislé půlky ;-) ) Pokud > bude původní ulice jako relace, není rozdělení na jedno kliknutí. Chtělo by > to něco jako "Split relation", případně další nástroje (které mě teď > nenapadají). Nevím, možná už něco takového existuje. > To není až tak neobvyklá situace, jak by sis mohl myslet. Znám oblast, kde probíhá výstavba rodinných domů v několika etapách. Krajní ulice má tvar širokého U a jedno jméno. V další etapě se k jejím koncům připojí další, takže vznikne H, kde prostřední (vodorovný) úsek si zachová jméno a ty na něj kolmé dostanou nové. Jinak si myslím, že takto globální změnu nemá smysl řešit tady, ale vhodným místem je list tagging. V. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] jmena cest jako relace
> Takže nejdůležitější na začátek: Jsem pro všema dvaceti, samozřejmě za > předpokladu, že bude JEDEN způsob, ne dva, ne neznámo kolik. A domlouvaný > mezinárodně. Jsem ochotný pomoct, i s angličtinou. > > 1. jako technik v tom vidím jednoznačný posun v kvalitě dat. Ta ulice je > objekt a jako každý jiný objekt má mít svoje tagy uvedené u sebe, tedy právě > jednou. *** Od počátku dosud v OSM neexistují striktní pravidla, jen konvence. Ten JEDEN způsob by měl splňovat ještě jednu podmínku, jednoduchost. At jsou si data fyzicky uložena jakkoliv, pro uživatele to musí být jednoduché a pochopitelné skrze editor. Kaskády relací např. nad polygony v to zatím nepatří. Podobně jako krom botů nikdo needituje OSM XML z notepadu, ale z grafického editoru. > Tedy jinými slovy: polymorfismus máme teď, když stejné tagy máme > uvedené neznámo-kolikrát-u-nijak-datově-nespojených-objektů. Přesně toho > polymorfismu se chceme zbavit. *** Polymorfismus je více forem pro jeden jev. Více objektů stejné formy se stejným NAME je spíš z kapitoly normálních forem relačních databází. Ne vždy je nezbytné normální formu v databázi realizovat, protože její režie mohou být nad přínosy. > Který jiný objekt máme v OSM uvedený tak, že je rozsekaný na spoustu částí bez > přímé datové vazby (odhaduje se jen podle jména a polohy ve stejném městě)? > Víte o nějakém jiném takovém případu? A pokud ano (já ne), přijde vám to i tam > jako správné řešení?! *** Třeba ref=* nebo highway=track, jednou je to trackgrade 1 pak 5. Nebo maxspeed nebo kombinace highway=+cycleway=...+oneway *** Nevnímám tu potřebu mít přímou vazbu mezi objekty, stačí mít nepřímou. > 2. relace mají v datovém modelu OSM příjemnou vlastnost, že umožňují (přímý a > levný) dotaz na své členy. Přesně co potřebuje renderer. Včetně toho, že u > cest > umíme mít úseky seřazené, aby navazovaly, atp. *** renderer si dělá rozsáhlý postprocessing, proc by si nemohl udelat jednoduchý příkaz v Postgis DISSOLVE. > Teď konkrétní nápady, ale upozorňuju předem, že jsou to jen prvotní nápady: > > 3. zbavíme se duplikování tagů a tedy i hrozby překlepů. Ani nepočítám, kolik > jsem jich opravil jen ve Vršovicích za cca 3 mapovací dny! > > 4. to samé platí pro neúplné sady tagů. Např. u některých ulic jsem potkal, že > jeden úsek měl tag "name" a jiný jen "name:ru". A nebylo to rozhodně jen > jednou. Takovou věc ani automat nepozná, to jsem musel projít ručně i nožně. *** Překlepy byly a budou. Dají se snadno najít a opravit, často dávkově. *** Teď budeš kontrolovat, jestli každá relace má správný počet členů... Vždycky budou chyby, které se budou těžko hledat. > 5. získáme 1:1 vazbu na RÚIAN, jeden objekt v něm bude odpovídat jednomu v OSM > > 6. z RÚIANu přibudou další tagy, minimálně reference na něj, a ty teď budeme > moct dát na jedno jasně definované místo a ne na jakýchsi > cest automatem obtížně vyhledatelných - viz odstavce 3 a 4. *** To je iluze, stačí se podívat na strukturu dat RUIAN a způsob práce OSM. I těch málo objektů co má převodník RUIAN OSM 1:1 nevydrží déle než příští editaci. > 7. renderer bude znát objekt jako celek a mnohem lépe bude moct vyhodnotit, > kam > umístí popisky. Dnes jsou popisky četné podle úseků, na které je ulice > rozsekaná v datech, a ne podle potřeby rendereru. A to není chyba rendereru, > to > je chyba dat! Chceme mít popisek jednolitého objektu a přitom ten objekt > nemáme > definovaný. *** To je věc postprocessingu viz výše. > Jediné co máme je primitivní heuristika typu "na mosty se dávat popisek s > jménem ulice nemusí". A když taková heuristika chybí pro nějakou kombinaci > chybí, lidi to "řeší" tím, že vyhodí tag "name" z nějakého objektu, třeba > mostu > nebo tunelu. Úprava dat podle rendereru, přesně to, co se nemá dělat. *** Určitě existuje více způsobů řešení tohoto problému třeba name:bridge, ref:bridge... ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] jmena cest jako relace
Dne 12.6.2013 09:45, Václav Řehák napsal: >> Napadá mě třeba rozdělení ulice s mnoha segmenty na dvě. (dejme tomu, že se >> politici zblázní a ulici fakt rozdělí na dvě nezávislé půlky ;-) ) Pokud >> bude původní ulice jako relace, není rozdělení na jedno kliknutí. Chtělo by >> to něco jako "Split relation", případně další nástroje (které mě teď >> nenapadají). Nevím, možná už něco takového existuje. > > To není až tak neobvyklá situace, jak by sis mohl myslet. Znám oblast, kde > probíhá výstavba rodinných domů v několika etapách. Krajní ulice má tvar > širokého U a jedno jméno. V další etapě se k jejím koncům připojí další, > takže vznikne H, kde prostřední (vodorovný) úsek si zachová jméno a ty na něj > kolmé dostanou nové. Aha. To vymyslel nějaký debil ne? Když si představím, že se nastěhuji, udělám si kolečko po úřadech kvůli změny adresy a za rok si to zase zopakuji, protože se mezitím dostavěla další ulice a tu moji mi přejmenovali. Asi bych nebyl rád. Marián > Jinak si myslím, že takto globální změnu nemá smysl řešit tady, ale vhodným > místem je list tagging. > > V. > > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-cz [1] Links: -- [1] http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] jmena cest jako relace
> > To není až tak neobvyklá situace, jak by sis mohl myslet. Znám oblast, kde > probíhá výstavba rodinných domů v několika etapách. Krajní ulice má tvar > širokého U a jedno jméno. V další etapě se k jejím koncům připojí další, > takže vznikne H, kde prostřední (vodorovný) úsek si zachová jméno a ty na > něj kolmé dostanou nové. > > > > Aha. To vymyslel nějaký debil ne? Když si představím, že se nastěhuji, > udělám si kolečko po úřadech kvůli změny adresy a za rok si to zase > zopakuji, protože se mezitím dostavěla další ulice a tu moji mi > přejmenovali. Asi bych nebyl rád. > Už jsme trochu OT, ale v tomto konkrétním místě to vychází tak, že k těm přejmenovávaným úsekům nepatří žádné adresy. Možná i proto si to dovolí takhle přejmenovávat. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] jmena cest jako relace
Ahoj! > > Takže nejdůležitější na začátek: Jsem pro všema dvaceti, samozřejmě za > > předpokladu, že bude JEDEN způsob, ne dva, ne neznámo kolik. A domlouvaný > > mezinárodně. Jsem ochotný pomoct, i s angličtinou. > > > > 1. jako technik v tom vidím jednoznačný posun v kvalitě dat. Ta ulice je > > objekt a jako každý jiný objekt má mít svoje tagy uvedené u sebe, tedy právě > > jednou. > *** Od počátku dosud v OSM neexistují striktní pravidla, jen konvence. > Ten JEDEN způsob by měl splňovat ještě jednu podmínku, jednoduchost. > At jsou si data fyzicky uložena jakkoliv, pro uživatele to musí být > jednoduché a pochopitelné skrze editor. Kaskády relací např. nad No, relace se jmenem jednoducha je. > > 2. relace mají v datovém modelu OSM příjemnou vlastnost, že umožňují (přímý > > a > > levný) dotaz na své členy. Přesně co potřebuje renderer. Včetně toho, že u > > cest > > umíme mít úseky seřazené, aby navazovaly, atp. > *** renderer si dělá rozsáhlý postprocessing, proc by si nemohl udelat > jednoduchý příkaz v Postgis DISSOLVE. Jasne ze muze. Ale aby to delal kazdy je trochu hloupe. > > Jediné co máme je primitivní heuristika typu "na mosty se dávat popisek s > > jménem ulice nemusí". A když taková heuristika chybí pro nějakou kombinaci > > chybí, lidi to "řeší" tím, že vyhodí tag "name" z nějakého objektu, třeba > > mostu > > nebo tunelu. Úprava dat podle rendereru, přesně to, co se nemá dělat. > *** Určitě existuje více způsobů řešení tohoto problému třeba > name:bridge, ref:bridge... name:bridge je jeste horsi hack nez problem ktery resi. Samozrejme by renderer mohl vse pospojovat pomoci jmena, a pak se tvarit ze je to pospojovane. Jenze jmeno neni uplne idealni cim by se mela data spojovat. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] jmena cest jako relace
Ahoj! > Nejsem proti. Navíc, nějaký návrh už ve wiki je, stačí jej jen > dopracovat a začít používat: > http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street > > Ideální by bylo toto nějak zakomponovat do editorů, aby byla práce s > těmito relacemi co nejjednodušší. Ideálně tak, aby se o vše pokud > možno staral editor bez nutnosti do toho manuálně zasahovat. > > Napadá mě třeba rozdělení ulice s mnoha segmenty na dvě. (dejme > tomu, že se politici zblázní a ulici fakt rozdělí na dvě nezávislé > půlky ;-) ) Pokud bude původní ulice jako relace, není rozdělení na > jedno kliknutí. Chtělo by to něco jako "Split relation", případně > další nástroje (které mě teď nenapadají). Nevím, možná už něco > takového existuje. Aktualne, kdyz nekdo rozdeli ulici na dve, tak na to take neni nastroj... takze nove nastroje nevidim tak kriticky. > A když už jsme u toho, stejně by se mohlo udělat i omezení > rychlosti, pokud je v části ulice rychlost omezená a v OSM to je > více segmentů. Taky by se tím omezily duplicity tagů. Duplicity tagu by to asi omezilo, ale tohle uz neni spravne. maxspeed je vlastnost daneho kusu silnice (stejne jako treba surface). name je vlastnost cele ulice. name by melo byt na relaci, maxspeed ne. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] jmena cest jako relace
>> > Takže nejdůležitější na začátek: Jsem pro všema dvaceti, samozřejmě za >> > předpokladu, že bude JEDEN způsob, ne dva, ne neznámo kolik. A domlouvaný >> > mezinárodně. Jsem ochotný pomoct, i s angličtinou. >> > >> > 1. jako technik v tom vidím jednoznačný posun v kvalitě dat. Ta ulice je >> > objekt a jako každý jiný objekt má mít svoje tagy uvedené u sebe, tedy >> > právě >> > jednou. >> *** Od počátku dosud v OSM neexistují striktní pravidla, jen konvence. >> Ten JEDEN způsob by měl splňovat ještě jednu podmínku, jednoduchost. >> At jsou si data fyzicky uložena jakkoliv, pro uživatele to musí být >> jednoduché a pochopitelné skrze editor. Kaskády relací např. nad > > No, relace se jmenem jednoducha je. *** Jednoduchy je to do te doby, nez to nekoho napadne udelat to same s ref, dál tam povede tam route PSV, foot, bicycle a zákazy odbočení. Do toho se prida polygon namesti, ten bude mit ostrov jako multipolygon, collection... >> > 2. relace mají v datovém modelu OSM příjemnou vlastnost, že umožňují >> > (přímý a >> > levný) dotaz na své členy. Přesně co potřebuje renderer. Včetně toho, že u >> > cest >> > umíme mít úseky seřazené, aby navazovaly, atp. >> *** renderer si dělá rozsáhlý postprocessing, proc by si nemohl udelat >> jednoduchý příkaz v Postgis DISSOLVE. > > Jasne ze muze. Ale aby to delal kazdy je trochu hloupe. *** Kazdy ne, jen renderer. >> > Jediné co máme je primitivní heuristika typu "na mosty se dávat popisek s >> > jménem ulice nemusí". A když taková heuristika chybí pro nějakou kombinaci >> > chybí, lidi to "řeší" tím, že vyhodí tag "name" z nějakého objektu, třeba >> > mostu >> > nebo tunelu. Úprava dat podle rendereru, přesně to, co se nemá dělat. >> *** Určitě existuje více způsobů řešení tohoto problému třeba >> name:bridge, ref:bridge... > > name:bridge je jeste horsi hack nez problem ktery resi. *** V cem? Je to jasne, jednoznacne a prehledne. Nemusim vyvyslet podle typu prvku jaky ref/name by tak mohl byt. > Samozrejme by renderer mohl vse pospojovat pomoci jmena, a pak se > tvarit ze je to pospojovane. Jenze jmeno neni uplne idealni cim by se > mela data spojovat. *** zalezi k cemu to spojovani potrebuju. Jestli k vytvareni popisku tak je to dostatecne dobre. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] jmena cest jako relace
Dne 12.6.2013 14:19, Pavel Machek napsal: Ahoj! Nejsem proti. Navíc, nějaký návrh už ve wiki je, stačí jej jen dopracovat a začít používat: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street Ideální by bylo toto nějak zakomponovat do editorů, aby byla práce s těmito relacemi co nejjednodušší. Ideálně tak, aby se o vše pokud možno staral editor bez nutnosti do toho manuálně zasahovat. Napadá mě třeba rozdělení ulice s mnoha segmenty na dvě. (dejme tomu, že se politici zblázní a ulici fakt rozdělí na dvě nezávislé půlky ;-) ) Pokud bude původní ulice jako relace, není rozdělení na jedno kliknutí. Chtělo by to něco jako "Split relation", případně další nástroje (které mě teď nenapadají). Nevím, možná už něco takového existuje. Aktualne, kdyz nekdo rozdeli ulici na dve, tak na to take neni nastroj... takze nove nastroje nevidim tak kriticky. Ok to byl jen příklad. Ale nemůžeš popřít, že rozdělení ulice tvořené relací je o trochu složitější a není tak přímočaré. A když už jsme u toho, stejně by se mohlo udělat i omezení rychlosti, pokud je v části ulice rychlost omezená a v OSM to je více segmentů. Taky by se tím omezily duplicity tagů. Duplicity tagu by to asi omezilo, ale tohle uz neni spravne. maxspeed je vlastnost daneho kusu silnice (stejne jako treba surface). name je vlastnost cele ulice. A co když je ten kus silnice rozdělen na více menších kousků třeba proto, že po kousku vede turistická značka, nebo tam je třeba nějaký podjezd, kde je potřeba maxheight. Jde o to, jak velký ten kousek definuješ. Marián name by melo byt na relaci, maxspeed ne. Pavel ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] jmena cest jako relace
> >> A když už jsme u toho, stejně by se mohlo udělat i omezení > >> rychlosti, pokud je v části ulice rychlost omezená a v OSM to je > >> více segmentů. Taky by se tím omezily duplicity tagů. > > > > Duplicity tagu by to asi omezilo, ale tohle uz neni spravne. maxspeed > > je vlastnost daneho kusu silnice (stejne jako treba surface). name je > > vlastnost cele ulice. > > A co když je ten kus silnice rozdělen na více menších kousků třeba > proto, že po kousku vede turistická značka, nebo tam je třeba nějaký > podjezd, kde je potřeba maxheight. Jde o to, jak velký ten kousek > definuješ. no, takže opět narážíme na omezení datového modelu, ne? nějak začínám mít pocit, že přiřazování vlastností cestám je prostě cesta do pekel ... /unconstructive_rant K. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] jmena cest jako relace
> 7. renderer bude znát objekt jako celek a mnohem lépe bude moct vyhodnotit, > kam > umístí popisky. Dnes jsou popisky četné podle úseků, na které je ulice > rozsekaná v datech, a ne podle potřeby rendereru. A to není chyba rendereru, > to > je chyba dat! Chceme mít popisek jednolitého objektu a přitom ten objekt > nemáme > definovaný. A dodávám: nejde jen o popisky. Jde prostě o to, že neznáme ulici jako objekt. To se nám může vymstít ve více věcech, např. že v netriviálních případech ji nenajdeme. Resp. najdeme, ale mockrát. Zkuste si vyhledat ulici Ke skalkám, Praha. Poctivě odklikejte "najdi další" a pak si zkoušejte, co vám který ten odklik z najitých ukáže. No a pak si to zkuste na mapy.cz . Rozdíl, který vidite a citite. Milan ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] MTB mapa (cyklo)stezky
Dne 12. června 2013 8:52 hanoj napsal(a): > > Značky C9 a C10 nejsou o nic víc cyklostezky než cesty pro pěší ani > naopak. > > Kombinace highway=path, bicycle=designated, foot=designated nebo > > bicycle+foot=official je správně. Viz > *** Správně je to co se dohodneme. Že "path je typicky lesní pěšina" > je letitá konvence. O takové konvenci nevím. S první větou souhlasím, přičemž my neznamená nás dva nebo českou komunitu, ale globální OSM. > Že stezkám C9 a C10 dáváme tag cycleway není žádná > nadřazenost vůči chodcům, ale jasná kategorizace. Když o něčem řeknu, že je to cycleway a chodce tam jen přilípnu v podobě access tagu (který jak sám píšeš většina ještě nepobrala) tak to preference cyklistů je. Stejně tak by to mohlo být footway + bicycle=designated. > Že se význam tagu na > anglické wiki se změnil není žádný rozkaz pro změnu v CZ. Nemyslím si, že můžou/měly by existovat národní specifika pro něco tak běžného jako je společná stezka pro cyklisty a chodce. Některé věci jinde nejsou (čísla popisná/orientační) - tam mají lokální specifika smysl. Dosavadní > systém funguje a má větší systém podrobnosti v rozlišení skutečnosti v > terénu a legality přístupnosti. > V čem je ta větší podrobnost a rozlišení? Navíc, většina maperů dosud nepobrala rozdíl mezi legalitou, vhodností > a stereotypy pro access tagy (access=*, foot=, vehicle=,...) > Potom je potřeba vysvětlovat použití access tagů. > > ha > hanoj > > ___ > Talk-cz mailing list > Talk-cz@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > LM_1 ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] MTB mapa vyhledava trasy
Ahoj, nevadí, já jsem jen tak doufal, že když už umíte počítat výškový profil trasy, tak třeba už máte pro každou cestu její profil spočítaný a uložený. Mám ještě připomínku k těm parametrům vyhledávání. Teď je to strašně komplikované. Pokud jsem dobře počítal, tak je tam kolem 50 různých nastavení, což musí spolehlivě odradit každého. Navíc není vůbec zřejmé, jak se ta nastavení parametrů projevují v ohodnocení grafu cest. Jde třeba nějak nastavit, aby highway=path s mtb:scale=0 byla víc vhodná než highway=path s mtb:scale=1? Nejak se mi to nepodařilo. Pro vyhledávání trasy pro horské kolo by mi přišlo ideální, kdyby uživatel měl jen jedno nastavení a to "obtížnost". Tím by říkal, o kolik obtížnější může trasa být v porovnání s nejméně obtížnou trasou, která vůbec nebere v potaz vhodnost cest. Ohodnocení cest by se pak počítalo takto: Pro každou cestu a směr by se braly v úvahu dvě veličiny, "namáhavost" a "působivost", a ty by se pak spolu s nastavenou obtížností použily k vypočítání celkové váhy cesty. Namáhavost by říkala, kolik sil stojí projet cestu v daném směru. Například asfaltová cesta, která vede po rovině, patří k nejméně namáhavým, zato pěšina s mtb:scale:uphill=5 ve směru do kopce nebo schody ve směru do kopce, kde se musí tlačit, patří k těm nejvíce namáhavým. Podobně cesta do kopce je více namáhavá, než stejná cesta po rovině a ta je více namáhavá než stejná cesta s kopce. Působivost by pak popisovala něco jako radost z projetí cesty. Radost může být buď ze samotné jízdy, nebo z okolí. Například radost z jízdy po silnici první třídy je většinou velmi malá, zato radost z jízdy po pěšině s mtb:scale=0 je většinou velmi velká. Podobně cesta která vede v rovině v poli s kukuřicí má asi méně působivé okolí než cesta, která vede v národním parku, národní přírodní rezervaci, CHKO, rezervaci UNESCO a tak podobně (tohle dostat z OSM dat by asi byl problém). Z namáhavosti a působivosti by se pak počítala výsledná váha cesty. To jak se tyto dvě veličiny zkombinují by pak záleželo na nastavení obtížnosti. Na nejlehčí obtížnost by algoritmus vybíral co možná nejméně namáhavé cesty s minimem objížděk (malá váha na působivosti). Čím těžší obtížnost, tím raději by algoritmus vybíral namáhavější, ale působivější cesty. Počítat by se to dalo asi takto: = *( - *). Algoritmus pro hledání by pak hledal trasu s nejmenší vahou. Různých hodnot pro obtížnost by asi měl být nějaký malý počet (tak 5). Obdobným způsobem by se asi dala udělat i pěší navigace. Dává to smysl? Vím že tu neřeším žádné detaily, ale snad je z toho mého popisu zřetelny princip fungování. Co vy na to? Honza Kouba Dne Út 11. června 2013 09:25:31, Martin Tesar napsal(a): Ahoj, ze dne na den to není možné, ale dodělat by to časem určitě šlo. Výškový profil trochu (nekdy i trochu dost) přehání, musím se na to podívat. Diky za podněty, Martin Dne 10. června 2013 19:19 Jan Kouba napsal(a): Ahoj, nešlo by do toho ohodnocení cest nějak zahrnout taky nastoupané metry? Takhle mě to pořád žene někde po kopcích, přesto že se dá jet po pěkné cestě (mtb:scale=0, highway=track, tracktype=grade4) i mnohem víc po rovině. A taky mi přijde, že ten výškový profil ukazuje více nastoupaných metrů, než je to ve skutečnosti. Honza Kouba Dne Po 10. června 2013 12:12:29, Martin Tesar napsal(a): Ahoj, není to nic tajného. Nahraji data do PostGISu pomocí aplikace osm2po a "trochu" je upravím. Přímo v databázi pak vyhledává knihovna pgRouting, která má jako parametr SQL dotaz, v němž specifikuju výběr cest a jejich ohodnocení podle veškerých parametrů a omezení. Díky tomuto dynamickému ohodnocování každé cesty (hrany) je to celkem pomalé, oproti ostatním vyhledávačům. Martin Dne 10. června 2013 10:28 Václav Řehák napsal(a): Ahoj, zajímavý počin, hlavně možností parametrizace. Mohl bys prozradit něco víc o technickém řešení, pokud to není tajné :) Použil jsi nějaký hotový engine nebo udělal kompletně svůj? V. Dne 7. června 2013 18:14 Martin Tesar napsal(a): Ahojte, spustil jsem první verzi vyhledávače tras na mtbmap.cz, který je určený pro cyklisty a turisty. Zatím je pokryto území ČR. Dá se různě parametrizovat, jak má výsledná trasa vypadat. Kvůli tomu je to docela pomalé, ale výsledek snad stojí za to. Vyzkoušejte, sdílejte a těším se na ohlasy. Martin -- Martin Tesar http://mtbmap.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 -- Martin Tesar http://mtbmap.cz/ ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz -- Martin Tesar http://mtbmap.cz/ ___
Re: [Talk-cz] MTB mapa vyhledava trasy
a) Jaké vlastnosti mají namáhavost a působivost? Tedy mám dva úseky cesty s namáhavostí n_1 a n_2 a působivostí p_1 a p_2, jaká bude namáhavost n a působivost p složené cesty z těchto dvou úseků? Součet, maximum, vážený průměr s váhou délky úseku, ...? b) Nějaké pojmenované profily mi dávají smysl, protože řekněme jízda na horském kole a na silničním (pokud pominu, že jde o MTB mapu) je z principu jiná a nelze dost dobře vyjádřit zmíněným vzorečkem. c) Mě dává smysl mít možnost nastavit i další parametry (jako nějaké "advanced settings"). Např. za žádných okolností nechci jezdit po silnici vyšší třídy. Nebo naopak třeba chci jezdit pouze po kvalitních cestách (asfalt apod.) a rozhodně nechci jezdit po nějaké lesní cestičce. Nebo maximálně preferuji rovinatý terén a kvalita povrchu je pro mě druhořadá. Jen bude vhodné nastavení předělat tak, aby bylo lépe pochopitelné pro běžné uživatele. Naopak pro pokročilé uživatele podrobněji vysvětlit, jaký to má vlastně dopad na algoritmus hledající cestu. Honza Dne 13. června 2013 2:24 Jan Kouba napsal(a): > ** > > Ahoj, > > > > nevadí, já jsem jen tak doufal, že když už umíte počítat výškový profil > trasy, tak třeba už máte pro každou cestu její profil spočítaný a uložený. > > > > > > > > Mám ještě připomínku k těm parametrům vyhledávání. Teď je to strašně > komplikované. Pokud jsem dobře počítal, tak je tam kolem 50 různých > nastavení, což musí spolehlivě odradit každého. > > > > Navíc není vůbec zřejmé, jak se ta nastavení parametrů projevují v > ohodnocení grafu cest. Jde třeba nějak nastavit, aby highway=path s > mtb:scale=0 byla víc vhodná než highway=path s mtb:scale=1? Nejak se mi to > nepodařilo. > > > > Pro vyhledávání trasy pro horské kolo by mi přišlo ideální, kdyby uživatel > měl jen jedno nastavení a to "obtížnost". Tím by říkal, o kolik obtížnější > může trasa být v porovnání s nejméně obtížnou trasou, která vůbec nebere v > potaz vhodnost cest. > > > > Ohodnocení cest by se pak počítalo takto: Pro každou cestu a směr by se > braly v úvahu dvě veličiny, "namáhavost" a "působivost", a ty by se pak > spolu s nastavenou obtížností použily k vypočítání celkové váhy cesty. > > > > Namáhavost by říkala, kolik sil stojí projet cestu v daném směru. > Například asfaltová cesta, která vede po rovině, patří k nejméně namáhavým, > zato pěšina s mtb:scale:uphill=5 ve směru do kopce nebo schody ve směru do > kopce, kde se musí tlačit, patří k těm nejvíce namáhavým. Podobně cesta do > kopce je více namáhavá, než stejná cesta po rovině a ta je více namáhavá > než stejná cesta s kopce. > > > > Působivost by pak popisovala něco jako radost z projetí cesty. Radost může > být buď ze samotné jízdy, nebo z okolí. Například radost z jízdy po silnici > první třídy je většinou velmi malá, zato radost z jízdy po pěšině s > mtb:scale=0 je většinou velmi velká. Podobně cesta která vede v rovině v > poli s kukuřicí má asi méně působivé okolí než cesta, která vede v národním > parku, národní přírodní rezervaci, CHKO, rezervaci UNESCO a tak podobně > (tohle dostat z OSM dat by asi byl problém). > > > > Z namáhavosti a působivosti by se pak počítala výsledná váha cesty. To jak > se tyto dvě veličiny zkombinují by pak záleželo na nastavení obtížnosti. Na > nejlehčí obtížnost by algoritmus vybíral co možná nejméně namáhavé cesty s > minimem objížděk (malá váha na působivosti). Čím těžší obtížnost, tím > raději by algoritmus vybíral namáhavější, ale působivější cesty. Počítat by > se to dalo asi takto: > > = *( - *). > > Algoritmus pro hledání by pak hledal trasu s nejmenší vahou. > > > > Různých hodnot pro obtížnost by asi měl být nějaký malý počet (tak 5). > Obdobným způsobem by se asi dala udělat i pěší navigace. > > > > Dává to smysl? Vím že tu neřeším žádné detaily, ale snad je z toho mého > popisu zřetelny princip fungování. Co vy na to? > > > > > > Honza Kouba > > > > > > > > > > Dne Út 11. června 2013 09:25:31, Martin Tesar napsal(a): > > Ahoj, > > ze dne na den to není možné, ale dodělat by to časem určitě šlo. > > Výškový profil trochu (nekdy i trochu dost) přehání, musím se na to > podívat. > > Diky za podněty, > > Martin > > > > Dne 10. června 2013 19:19 Jan Kouba napsal(a): > > Ahoj, > > > > nešlo by do toho ohodnocení cest nějak zahrnout taky nastoupané metry? > Takhle mě to pořád žene někde po kopcích, přesto že se dá jet po pěkné > cestě (mtb:scale=0, highway=track, tracktype=grade4) i mnohem víc po > rovině. > > > > A taky mi přijde, že ten výškový profil ukazuje více nastoupaných metrů, > než je to ve skutečnosti. > > > > Honza Kouba > > > > > > Dne Po 10. června 2013 12:12:29, Martin Tesar napsal(a): > > Ahoj, > > není to nic tajného. Nahraji data do PostGISu pomocí aplikace osm2po a > "trochu" je upravím. Přímo v databázi pak vyhledává knihovna pgRouting, > která má jako parametr SQL dotaz, v němž specifikuju výběr cest a jejich > ohodnocení podle veškerých parametrů a omezení. Díky tomuto dynamickému > ohodnocování každé cesty (hrany) je to celkem pomalé,
Re: [Talk-cz] MTB mapa (cyklo)stezky
Dne St 12. června 2013 22:19:29, LM_1 napsal(a): > Dne 12. června 2013 8:52 hanoj napsal(a): > > *** Správně je to co se dohodneme. Že "path je typicky lesní pěšina" > > je letitá konvence. > > O takové konvenci nevím. to je smutné ... http://wiki.openstreetmap.org/wiki/Tag:highway=path => http://wiki.openstreetmap.org/wiki/File:GuideFootPathCycleYes.jpg ;-) K. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] MTB mapa (cyklo)stezky
Ahoj, > 2013/6/12 LM_1 : > Dne 12. června 2013 8:52 hanoj napsal(a): > >> *** Správně je to co se dohodneme. Že "path je typicky lesní pěšina" >> je letitá konvence. > > O takové konvenci nevím. S první větou souhlasím, přičemž my neznamená nás > dva nebo českou komunitu, ale globální OSM. Pokud se pouzijes dodatecny tagy jako povrch, sirka, obtiznost, tak by melo byt jedno jestli highway=path nebo highway=cycleway (na vetsine map to stejne nebude, ale netagujeme pro renderery...). Pokud ne, tak path je typicky pesinka - uzka, bez asfaltu. Cycleway je asfaltka, alespon metr siroka nebo alespon sotolina. >> >> Že stezkám C9 a C10 dáváme tag cycleway není žádná >> nadřazenost vůči chodcům, ale jasná kategorizace. > > Když o něčem řeknu, že je to cycleway a chodce tam jen přilípnu v podobě > access tagu (který jak sám píšeš většina ještě nepobrala) tak to preference > cyklistů je. Stejně tak by to mohlo být footway + bicycle=designated. Ja highway=cycleway beru jako prakticky zpusob, jak oznacit jeden typ komunikace. Nejenom kdo tam muze, ale take typicke vlastnosti. Stejnym zpusobem by se dalo pouzit highway=footway + bicycle=designated, ale vzhledem k tomu, ze chodniky jsou uplne vsude, tak mi prijde v poradku cyklostezky zduraznit. >> ha >> hanoj > LM_1 -- Jirka ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] MTB mapa (cyklo)stezky
>> Dosavadní >> systém funguje a má větší systém podrobnosti v rozlišení skutečnosti v >> terénu a legality přístupnosti. > > V čem je ta větší podrobnost a rozlišení? *** Protože jasně popisuje nějaký druh infrastruktury s nějakými typickými vlastnostmi. Stejně jako z praktických důvodů nepoužíváme následující: highway=path, surface=asphalt, width=22, motorcarspeed:more60=yes ALE highway=motorway highway=path, surface=asphalt, width=8.5 , vehicle=yes ALE highway=primary kategorie je tedy jasná a upřesnění může následovat dodatkem. hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] jmena cest jako relace
>> 7. renderer bude znát objekt jako celek a mnohem lépe bude moct vyhodnotit, >> kam >> umístí popisky. Dnes jsou popisky četné podle úseků, na které je ulice >> rozsekaná v datech, a ne podle potřeby rendereru. A to není chyba rendereru, >> to >> je chyba dat! Chceme mít popisek jednolitého objektu a přitom ten objekt >> nemáme >> definovaný. > > A dodávám: nejde jen o popisky. Jde prostě o to, že neznáme ulici jako objekt. > To se nám může vymstít ve více věcech, např. že v netriviálních případech ji > nenajdeme. Resp. najdeme, ale mockrát. Zkuste si vyhledat ulici Ke skalkám, > Praha. Poctivě odklikejte "najdi další" a pak si zkoušejte, co vám který ten > odklik z najitých ukáže. No a pak si to zkuste na mapy.cz . *** Neznam, jak to dela byvale PlanStudio pro mapy.cz. Zato jsem videl nekolik datovych baliku pro tvoření map tohoto typu (ono jich na trhu moc neni ZABAGED, SM10, balik ArcCR, data Tmapy) a zadny nemel takove problemy reseny primo v datovem modelu. Vyhledavani seznam.cz je presna ukazka ucelovych uprav puvodnich dat pro potreby jedne aplikace. Prostě jeden analytický příkaz nahradí složitou práci s modelem a zejména přípravou dat (ci jejich nakupem). Slozite datove geomodely si muze dovolit jen velka firma ve specifickych pripadech, napr. RUIAN, Katastr nemovitostí. Jinde se užívá konvenční, nehierarchický systém. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
