> 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 _______________________________________________ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
