Ahoj, v posledních dnech se u našich changesetů sešly dotazy a pochopitelná nedůvěra. Velká část z ní vznikla tím, že hromadné edity odešly z osobního účtu, který v komunitě skoro nikdo nezná. Rád bych proto vysvětlil, kdo jsme a co děláme, co se stalo a proč, a domluvil se s vámi, co dál. "kdo jsme a co děláme" Píšu za nás tři. Já (<https://www.openstreetmap.org/user/Dvorn%C3%BD/>) a Vojta Fošnár (<https://www.openstreetmap.org/user/Vojt%C4%9Bch%20Fo%C5%A1n%C3%A1r>) se dlouhodobě věnujeme mapování Pardubic a okolí; třetím z nás je funH4xx0r (<https://www.openstreetmap.org/user/funH4xx0r/>), pod jehož účtem proběhly changesety, o kterých se teď diskutuje. Každý automatizovaný edit ale před nahráním prošel rukama nás všech tří. Vytváříme si vlastní nástroje, manuální, poloautomatické i plně automatické: - sync (<https://sync.vfosnar.cz/>, <https://codeberg.org/osmcz/sync>) - stejný účel jako POI importer - fork iD (<https://id.vfosnar.cz>, <https://codeberg.org/osmcz/iD>) - několik experimentálních funkcí, které ulehčují editaci, např. indoor editing nebo poloautomatický import geometrie vodních cest ze ZABAGEDu - osmtools (<https://codeberg.org/vfosnar/osmtools>) - sada knihoven pro středně náročné masové lokální zpracování OSM dat a služby: - zabaged-map (<https://zabaged.vfosnar.cz/>, <https://codeberg.org/osmcz/zabaged-map/>) - prohlížeč dat ZABAGEDu - fullpass (<https://fullpass.vfosnar.cz/>, <https://codeberg.org/osmcz/fullpass>) - Overpass, ale SQL a s plnou historií, užitečný např. pro gamifikační prvky v aplikacích Ani jedna z těchto služeb ale zatím není připravena pro veřejnost; odkazy sdílíme proto, aby měla komunita představu, na čem pracujeme. Kandidátem na první veřejné vydání je sync, ten je ale potřeba nejdřív doladit. Například uživatel zatím není nijak upozorněn na časté chyby v databázi Drobných památek, na to, jak je rozpoznat, ani na to, že se mají nahlašovat, a ne slepě zakreslit do mapy. Protože se nám aktivity kupí a začínají být organizované, rozhodli jsme se je zastřešit neoficiální organizací reperfect.it (<https://wiki.openstreetmap.org/wiki/Organised_Editing/Activities/Reperfect.it>). Budoucí hromadné edity budou prováděny pod účtem této organizace, aby bylo na první pohled jasné, o jaký typ editu jde a kdo za ním stojí. Hosting projektů a služeb se přesune na její VPS, aby nestál a nepadal s jedním člověkem. Společným cílem je vyřešit problémy, na které při mapování sami narážíme: - synchronizovat velké množství dostupných dat, která do OSM nikdo neimportuje: ZABAGED, Drobné památky, AllThePlaces, Overture Maps - odstranit omezení dostupných nástrojů; drobné vylepšení nástroje dokáže mapperovi ušetřit hodiny času: import geometrie ze ZABAGEDu, přichytávání na externí data - uklidit existující data v OSM, protože vágnost jen nabaluje další špatná data: překrývající se ploty, porušování pravidla one feature, one element "co se stalo a proč" V rámci oprav tagování byly informace o POI tagované přímo na budovách extrahovány do samostatných bodů umístěných ve středu dané budovy. Edit po celé ČR odebral tagy amenity z 4 979 budov a v každé z nich vytvořil nový bod s extrahovaným amenity a souvisejícími tagy (např. opening_hours). Pro upřesnění: žádné existující POI body nebyly přesouvány. Edit se týkal výhradně POI zmapovaných na prvku budovy. Edit jsme považovali za "Acceptable usage" podle <https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct> a neprojednali ho předem s komunitou, stejně jako dřívější opravu tagování barrier. Zpětně je zřejmé, že šlo o chybu v naší interpretaci a že edit do této kategorie nespadá. Na konci e-mailu proto pro přehlednost uvádíme všechny automatizované edity, které jsme dosud provedli. Jakýkoliv další automatizovaný zásah do mapy předem ohlásíme na talk-cz, bez ohledu na jeho rozsah, stejně jako tomu bylo u importu ze ZABAGEDu. Teď k odůvodnění editu a k některým argumentům, které zazněly. Pravidlo One feature, one OSM element (<https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element>), tedy "jedna věc má odpovídat jednomu prvku v OSM", existuje proto, že při jeho porušení vznikají v datech nejasnosti. Typickým příkladem je restaurace a hotel na jednom prvku: platí otevírací doba pro restauraci, pro hotel, nebo pro obojí? Editor iD v tomto případě zobrazí pouze typ "Restaurace", protože předpokládá, že jeden prvek popisuje jednu věc. Stejný problém nastává u kombinace budova + POI, například škola (amenity=school) v historické budově (building=civic). Kterému z nich patří tag wikidata? Co v tomto kontextu semanticky znamenají level a height? iD takový prvek zobrazí jako školu a s informací o budově dál nepracuje. Víme, že přidávat amenity=school přímo na budovu je rozšířená a zaběhlá praxe. Často ale neexistuje nic jako "budova školy": na vesnici může být v jedné budově školka i pošta (<https://www.openstreetmap.org/way/188134192>), a samostatný bod s amenity přitom není o moc pracnější než tag na budově. Toto tagování také naráží na budovy importované z RUIANu, kde se školský areál skládá z několika samostatných prvků building. Lidé pak amenity=school z jedné budovy "okoukají" a přidají ho na každou z nich, takže zakreslí třeba osm škol tam, kde je jedna (<https://www.openstreetmap.org/node/13970696416>). Z praktického hlediska jsme navíc tímto editem amenity=school zvýraznili v iD, takže jsou existující chyby v datech mnohem jednodušeji identifikovatelné. Zajímavým případem jsou právě školy: stránka <https://wiki.openstreetmap.org/wiki/Tag:building%3Dschool> pro případ "The school building fills the school ground completely" doporučuje "Map the outline of the area of the building and add the tags amenity=school and building=school", což je podle nás v rozporu jak s principem one feature, one element, tak se samotnou stránkou <https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dschool>. Přijde nám to jako historická nekonzistence wiki, ale rádi si k tomu vyslechneme názor ostatních. Zazněl také argument, že amenity=school nepopisuje samotnou školu, ale její prostory. Pro prostory školy nám ale přijde vhodnější tag landuse=education (<https://wiki.openstreetmap.org/wiki/Tag:landuse%3Deducation>). Dalším argumentem je, že převedením POI z plochy na bod se ztrácí informace o geometrii. To je pravda. Zvažována byla i varianta vytvořit POI jako relaci nad budovou; protože ale za většinou tohoto tagování předpokládáme úmysl "v této budově je fast food", a ne "tato budova JE fast food", byl zvolen bod. Bod má navíc tu výhodu, že zůstává jednoznačný, i když se o budovu dělí více činností, jako v příkladech výše. S tím souvisí vliv na routing. Uznáváme, že se výsledky routování extrakcí mohly změnit, ale plánování trasy na libovolný bod obrysu budovy je stejně nepřesný předpoklad jako routování na bod v jejím středu. Pro spolehlivou navigaci je podle nás nejlepší zmapovat hlavní vchod (entrance=main). "co dál" Naším dalším plánovaným krokem bylo detekovat sobě blízké duplikátní amenity=school a buď je manuálně projít, nebo na ně vytvořit MapRoulette challenge. To samé pak ohledně building!=school v okolí amenity=school. Jakékoliv další edity budeme jasně předem komunikovat na talk-cz, stejně jako to bylo u ZABAGEDu. Pokud se komunita shodne, že náš edit byl chybný, věnujeme čas tomu, abychom ho sami revertovali. Díky všem za reakce, včetně těch kritických, a za trpělivost. Vojta D., Vojta F., funH4xx0r --- Import dat ze ZABAGEDu (<https://wiki.openstreetmap.org/wiki/Cs:POI_ZABAGED_Import>, <https://osmap.vfosnar.cz/talkcz/vlakno/import-vybranych-poi-ze-zabagedu-do-osm>):   <https://www.openstreetmap.org/changeset/185213905> amenity=police   <https://www.openstreetmap.org/changeset/185214485> amenity=fuel   <https://www.openstreetmap.org/changeset/185215755> amenity=fire_station 1/2   <https://www.openstreetmap.org/changeset/185252501> amenity=fire_station 2/2   <https://www.openstreetmap.org/changeset/185257039> amenity=post_office Import dat z databáze Drobné památky (<https://wiki.openstreetmap.org/wiki/Cs:Drobn%C3%A9_pam%C3%A1tky_Import>):   <https://www.openstreetmap.org/changeset/185924049> pravidelná synchronizace tagů wikidata <-> ref:drobne_pamatky   několik changesetů, které zanesly počáteční data dle konvence uvedené na wiki Extrahování chybně mapovaných bariér do samostatných cest:   <https://www.openstreetmap.org/changeset/184692841> 1/3   <https://www.openstreetmap.org/changeset/184692854> 2/3   <https://www.openstreetmap.org/changeset/184692873> 3/3 Deduplikace bariér:   <https://www.openstreetmap.org/changeset/185154333> Oprava tagování amenity na budovách:   <https://www.openstreetmap.org/changeset/184700541> extrakce, ale chybně vypočítaná lokace centroidu + JOSM zahlásil, že se upload nezdařil, což nebyla pravda...   <https://www.openstreetmap.org/changeset/184706070> druhý pokus o nahrání z JOSMu, způsobil duplikaci POI   <https://www.openstreetmap.org/changeset/184706247> revert duplikace z 184706070   <https://www.openstreetmap.org/changeset/184715244> oprava lokace na opravdový centroid