> Ahoj, > > 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 > urcene: > http://wiki.openstreetmap.org/wiki/Relation:associatedStreet > http://wiki.openstreetmap.org/wiki/Relation:street > plus obdobna vec existuje i pro waterway > http://wiki.openstreetmap.org/wiki/Relation:waterway > > Petr > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> 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

> plus obdobna vec existuje i pro waterway > http://wiki.openstreetmap.org/wiki/Relation:waterway

> > uz to tady problesklo pri diskusi u znamek a podobnych veci - co kdybychom > > do standardu pro CZ zanesli moznost pojmenovavani ulic a cest obecne pomoci > > relaci? V tomto smeru uz v OSM existuji minimalne dve (! :( ) relace k tomu > *** ze jsem tak smělý, co to přinese (tedy krom polymorfismu ;) ?

>> > uz to tady problesklo pri diskusi u znamek a podobnych veci - co kdybychom >> > do standardu pro CZ zanesli moznost pojmenovavani ulic a cest obecne pomoci >> > relaci? V tomto smeru uz v OSM existuji minimalne dve (! :( ) relace k tomu >> *** ze jsem tak smělý, co to přinese (tedy krom polymorfismu ;) ? > > Ze budes schopen snaze udelat dotaz, ktere vsechny segmenty patri k jedne > ulici. Navic by jedna cesta (way) mohla byt soucasti vice nez jednoho pojmenovani > (uz jsem se s tim nekde potkal - nikoli samozrejme na urovni oficialnich jmen > ulic, ale na urovni zvykoveho oznaceni cest v prirode). A aspon v JOSM by se > snaz kontrolovala spojitost, coz by byl takovy prijemny side effect.

> 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

>> 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 <neznámý-počet-n> > 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 >

> 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. >

> 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.

> 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 <neznámý-počet-n> 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.

>> 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 na openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-cz [1]

> > 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. >

> > 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

> > 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.

> > 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...

> 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ů.

>> > 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.

> 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

> >> 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š.

> 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ý.

>> 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 .

> >> 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >