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