jmena cest jako relace

20 zpráv
Zpět na přehled

jmena cest jako relace

20 zpráv HMPLKMVP 8 účastníků 22 min čtení
  1. Petr Holub hopet na ics.muni.cz #m1ed686
    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
  2. LM_1 flukas.robot+osm na gmail.com #m96cbb6
    Jsem pro všema deseti 2013/6/7 Petr Holub <hopet na ics.muni.cz>
  3. hanoj ehanoj na gmail.com #m8cf6e7
    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
  4. Karel Volný kavol na seznam.cz #mbe5d70
    zdar,
    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.
  5. Petr Holub hopet na ics.muni.cz #m0d72a0
    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
  6. hanoj ehanoj na gmail.com #ma0bfd6
    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
  7. Milan Vancura milan na ucw.cz #m13b0d0
    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
  8. Marián Kyral mkyral na email.cz #mb9ae63
    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
  9. Václav Řehák rehakv01 na gmail.com #m164c13
    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.
  10. hanoj ehanoj na gmail.com #ma9800d
    Takže nejdůležitější na začátek: Jsem pro všema dvaceti, samozřejmě za předpokladu, že bude JEDEN způsob, ne dva, ne neznámo kolik. A domlouvaný mezinárodně. Jsem ochotný pomoct, i s angličtinou. 1. jako technik v tom vidím jednoznačný posun v kvalitě dat. Ta ulice je objekt a jako každý jiný objekt má mít svoje tagy uvedené u sebe, tedy právě jednou.
    *** Od počátku dosud v OSM neexistují striktní pravidla, jen konvence. Ten JEDEN způsob by měl splňovat ještě jednu podmínku, jednoduchost. At jsou si data fyzicky uložena jakkoliv, pro uživatele to musí být jednoduché a pochopitelné skrze editor. Kaskády relací např. nad polygony v to zatím nepatří. Podobně jako krom botů nikdo needituje OSM XML z notepadu, ale z grafického editoru.
    Tedy jinými slovy: polymorfismus máme teď, když stejné tagy máme uvedené neznámo-kolikrát-u-nijak-datově-nespojených-objektů. Přesně toho polymorfismu se chceme zbavit.
    *** Polymorfismus je více forem pro jeden jev. Více objektů stejné formy se stejným NAME je spíš z kapitoly normálních forem relačních databází. Ne vždy je nezbytné normální formu v databázi realizovat, protože její režie mohou být nad přínosy.
    Který jiný objekt máme v OSM uvedený tak, že je rozsekaný na spoustu částí bez přímé datové vazby (odhaduje se jen podle jména a polohy ve stejném městě)? Víte o nějakém jiném takovém případu? A pokud ano (já ne), přijde vám to i tam jako správné řešení?!
    *** Třeba ref=* nebo highway=track, jednou je to trackgrade 1 pak 5. Nebo maxspeed nebo kombinace highway=+cycleway=...+oneway *** Nevnímám tu potřebu mít přímou vazbu mezi objekty, stačí mít nepřímou.
    2. relace mají v datovém modelu OSM příjemnou vlastnost, že umožňují (přímý a levný) dotaz na své členy. Přesně co potřebuje renderer. Včetně toho, že u cest umíme mít úseky seřazené, aby navazovaly, atp.
    *** renderer si dělá rozsáhlý postprocessing, proc by si nemohl udelat jednoduchý příkaz v Postgis DISSOLVE.
    Teď konkrétní nápady, ale upozorňuju předem, že jsou to jen prvotní nápady: 3. zbavíme se duplikování tagů a tedy i hrozby překlepů. Ani nepočítám, kolik jsem jich opravil jen ve Vršovicích za cca 3 mapovací dny! 4. to samé platí pro neúplné sady tagů. Např. u některých ulic jsem potkal, že jeden úsek měl tag "name" a jiný jen "name:ru". A nebylo to rozhodně jen jednou. Takovou věc ani automat nepozná, to jsem musel projít ručně i nožně.
    *** Překlepy byly a budou. Dají se snadno najít a opravit, často dávkově. *** Teď budeš kontrolovat, jestli každá relace má správný počet členů... Vždycky budou chyby, které se budou těžko hledat.
    5. získáme 1:1 vazbu na RÚIAN, jeden objekt v něm bude odpovídat jednomu v OSM 6. z RÚIANu přibudou další tagy, minimálně reference na něj, a ty teď budeme moct dát na jedno jasně definované místo a ne na <neznámý-počet-n> jakýchsi cest automatem obtížně vyhledatelných - viz odstavce 3 a 4.
    *** To je iluze, stačí se podívat na strukturu dat RUIAN a způsob práce OSM. I těch málo objektů co má převodník RUIAN OSM 1:1 nevydrží déle než příští editaci.
    7. renderer bude znát objekt jako celek a mnohem lépe bude moct vyhodnotit, kam umístí popisky. Dnes jsou popisky četné podle úseků, na které je ulice rozsekaná v datech, a ne podle potřeby rendereru. A to není chyba rendereru, to je chyba dat! Chceme mít popisek jednolitého objektu a přitom ten objekt nemáme definovaný.
    *** To je věc postprocessingu viz výše.
    Jediné co máme je primitivní heuristika typu "na mosty se dávat popisek s jménem ulice nemusí". A když taková heuristika chybí pro nějakou kombinaci chybí, lidi to "řeší" tím, že vyhodí tag "name" z nějakého objektu, třeba mostu nebo tunelu. Úprava dat podle rendereru, přesně to, co se nemá dělat.
    *** Určitě existuje více způsobů řešení tohoto problému třeba name:bridge, ref:bridge... ha hanoj
  11. Marián Kyral mkyral na email.cz #m442456
    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.
    Links: ------
  12. Václav Řehák rehakv01 na gmail.com #m1d6af3
    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.
  13. Pavel Machek pavel na ucw.cz #m12726d
    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
  14. Pavel Machek pavel na ucw.cz #me67bf0
    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
  15. hanoj ehanoj na gmail.com #m4529ba
    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
  16. Marián Kyral mkyral na email.cz #m847c4c
    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
  17. Karel Volný kavol na seznam.cz #m076df7
    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.
  18. Milan Vancura milan na ucw.cz #ma42f4a
    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
  19. hanoj ehanoj na gmail.com #mda0869
    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
  20. LM_1 flukas.robot+osm na gmail.com #m5ffa20
    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
Napsat odpověď e-mailem… Odpovědět

Otevře váš e-mailový klient. Odpovědi pak sledujte zde na webu.