« zpět na výpis měsíce |

[Talk-cz] jmena cest jako relace

Vlákno 7.6. - 15.6.2013, počet zpráv: 20


7.6.2013 04:04:45 (#1)
gravatar

Petr Holub

<hopet at ics.muni.cz>
290 4468
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

7.6.2013 06:08:20 (#2)
gravatar

LM_1

<flukas.robot+osm at gmail.com>
103
Jsem pro všema deseti 2013/6/7 Petr Holub <hopet na ics.muni.cz> zobrazit citaci
> 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 >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20130607/32b88078/attachment.html>

7.6.2013 06:13:44 (#3)
gravatar

hanoj

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

7.6.2013 06:19:48 (#4)
gravatar

Karel Volný

<kavol at seznam.cz>
556
zdar, zobrazit citaci
> plus obdobna vec existuje i pro waterway > http://wiki.openstreetmap.org/wiki/Relation:waterway
což mi připomíná blbej dotaz ... co s tím, když se řeka v nějakém úseku jmenuje nějak, a v dalším úseku jinak? pro každé jméno jednu relaci a řeku definovat jako relaci relací? a mimochodem, co je vlastně autoritativní zdroj co se týče jmen řek? K.

7.6.2013 07:31:20 (#5)
gravatar

Petr Holub

<hopet at ics.muni.cz>
290 4468
zobrazit citaci
> > 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. Bohuzel blbe je, ze je to slozitejsi a ze by to znamenalo koexistenci dvou zpusobu znaceni, pripadne konverzi stavajiciho. Proto to nadhazuji, jaky na to bude ve skupine nazor. Petr

10.6.2013 09:14:52 (#6)
gravatar

hanoj

<ehanoj at gmail.com>
717
zobrazit citaci
>> > uz to tady problesklo pri diskusi u znamek a podobnych veci - co kdybychom >> > do standardu pro CZ zanesli moznost pojmenovavani ulic a cest obecne pomoci >> > relaci? V tomto smeru uz v OSM existuji minimalne dve (! :( ) relace k tomu >> *** ze jsem tak smělý, co to přinese (tedy krom polymorfismu ;) ? > > Ze budes schopen snaze udelat dotaz, ktere vsechny segmenty patri k jedne > ulici. Navic by jedna cesta (way) mohla byt soucasti vice nez jednoho pojmenovani > (uz jsem se s tim nekde potkal - nikoli samozrejme na urovni oficialnich jmen > ulic, ale na urovni zvykoveho oznaceni cest v prirode). A aspon v JOSM by se > snaz kontrolovala spojitost, coz by byl takovy prijemny side effect.
*** Na vice nazvu je tu tag "alt_name". Prvky jende ulice stahnu podle nazvu (kdyz pominu ze definice ulice je nejednoznacna). Kontrola routovacich vazeb by asi sla udelat nejakym algoritmem, priznam se v soucasnem stavu OSM tools nemam prehled. ha hanoj

12.6.2013 12:06:20 (#7)
gravatar

Milan Vancura

<milan at ucw.cz>
25
zobrazit citaci
> 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

12.6.2013 09:36:26 (#8)
gravatar

Marián Kyral

<mkyral at email.cz>
2365 2690
Dne 12.6.2013 00:06, Milan Vancura napsal: zobrazit citaci
>> 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 >
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

12.6.2013 09:45:39 (#9)
gravatar

Václav Řehák

<rehakv01 at gmail.com>
63
zobrazit citaci
> 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. ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20130612/51e05156/attachment.html>

12.6.2013 09:58:21 (#10)
gravatar

hanoj

<ehanoj at gmail.com>
717
zobrazit citaci
> 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. zobrazit citaci
> 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. zobrazit citaci
> 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. zobrazit citaci
> 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. zobrazit citaci
> 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. zobrazit citaci
> 5. získáme 1:1 vazbu na RÚIAN, jeden objekt v něm bude odpovídat jednomu v OSM > > 6. z RÚIANu přibudou další tagy, minimálně reference na něj, a ty teď budeme > moct dát na jedno jasně definované místo a ne na <neznámý-počet-n> jakýchsi > cest automatem obtížně vyhledatelných - viz odstavce 3 a 4.
*** To je iluze, stačí se podívat na strukturu dat RUIAN a způsob práce OSM. I těch málo objektů co má převodník RUIAN OSM 1:1 nevydrží déle než příští editaci. zobrazit citaci
> 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. zobrazit citaci
> 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

12.6.2013 10:12:22 (#11)
gravatar

Marián Kyral

<mkyral at email.cz>
2365 2690
Dne 12.6.2013 09:45, Václav Řehák napsal: zobrazit citaci
>> 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 zobrazit citaci
> 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]
Links: ------ [1] http://lists.openstreetmap.org/listinfo/talk-cz ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20130612/8a9df5a5/attachment.html>

12.6.2013 10:44:30 (#12)
gravatar

Václav Řehák

<rehakv01 at gmail.com>
63
zobrazit citaci
> > 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. ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20130612/917b9eab/attachment.html>

12.6.2013 02:16:25 (#13)
gravatar

Pavel Machek

<pavel at ucw.cz>
1056 1226
Ahoj! zobrazit citaci
> > 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. zobrazit citaci
> > 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. zobrazit citaci
> > 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

12.6.2013 02:19:37 (#14)
gravatar

Pavel Machek

<pavel at ucw.cz>
1056 1226
Ahoj! zobrazit citaci
> 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. zobrazit citaci
> 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

12.6.2013 02:41:59 (#15)
gravatar

hanoj

<ehanoj at gmail.com>
717
zobrazit citaci
>> > 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... zobrazit citaci
>> > 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. zobrazit citaci
>> > 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. zobrazit citaci
> 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

12.6.2013 03:06:46 (#16)
gravatar

Marián Kyral

<mkyral at email.cz>
2365 2690
Dne 12.6.2013 14:19, Pavel Machek napsal: zobrazit citaci
> 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é. zobrazit citaci
>> 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 zobrazit citaci
> name by melo byt na relaci, maxspeed ne. > Pavel

12.6.2013 04:41:36 (#17)
gravatar

Karel Volný

<kavol at seznam.cz>
556
zobrazit citaci
> >> 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.

12.6.2013 07:09:48 (#18)
gravatar

Milan Vancura

<milan at ucw.cz>
25
zobrazit citaci
> 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

13.6.2013 08:56:16 (#19)
gravatar

hanoj

<ehanoj at gmail.com>
717
zobrazit citaci
>> 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

15.6.2013 05:21:37 (#20)
gravatar

LM_1

<flukas.robot+osm at gmail.com>
103
OSM má přes milion "zaměstnanců", takže je pravděpodobně "velká firma", možná dokonce ta největší. Co se užívá jinde má malou vypovídací hodnotu, když uvážíme zvláštní povahu tvorby OSM. S různorodým složením přispěvatelů do OSM roste potřeba jednoduché údržby dat a jejich kontroly. Navíc přechod od hierarchického modelu k jednoduššímu je snadněji realizovatelná, než opačná. LM_1 Dne 13. června 2013 8:56 hanoj <ehanoj na gmail.com> napsal(a): zobrazit citaci
> >> 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 >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20130615/f4c34ede/attachment.html>

« zpět na výpis měsíce