Ahoj, předně děkuji za vaši práci a za snahu ji vysvětlit. Bylo by to asi o chlup jednodušší a příjemnější kdyby o tom komunita věděla předem :)
> 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. Na wiki je doslova napsáno: Useful edits that would be tedious to do manually, only after approval by the community and appropriate discussion. To neznamená, že nespadá do acceptable use, ale že jste ho měli projednat předem i tak. S edity v zásadě souhlasím. Co se týče extrakce bodů, asi s tím budu nakonec taky souhlasit, i když při zakreslování obchodu, pro který byla postavena budova s účelem být ten obchod a je v ní jediný, přijde mi v pohodě, aby byl tag shop= přímo na budově. Na druhou stranu ale musím argumentovat tím, že například mapování obchodů v nákupních centrech pomocí ploch je naprosto ďábelská praktika, protože obchody se často mění a to nejen provozovatel, ale i velikost a tvar prodejny. Opravovat něco takhle nakresleného je stokrát horší, než když je tam pouze bod. Takže jasný výstup z toho nemám. S přáním klidné mysli a zdraví Ondřej Lopatka ondrejlopatka.cz <http://ondrejlopatka.cz/> > On Jul 20, 2026, at 8:59 AM, Marián Kyral <[email protected]> wrote: > > Ahoj, > já nejsem proti, mít více POI na jedné budově přináší často více problémů než > užitku. Kromě těch popsaných nevýhod se nejednoznačností je třeba mnohem > jednodušší přesunout jen bod, když se provozovna přestěhuje. > > Trochu mi ale vadí, když se pak všechny body nacpou doprostřed budovy. Já se > snažím body dávat buď na skutečné umístění v rámci budovy (pokud ho znám) > nebo poblíž ke vchodu (pokud ho znám ;-) ) > > Ad (ne)podpora více typů POI na budově v iD - nevím, jestli je na tom nějaké > issue, ale ignorovat další tagy mi nepřijde moc OK. Ideálně kdyby alespoň > nějak upozornili, že tam je těch tagů více. > > Ad One feature, one OSM element - to funguje dobře ve vztahu plocha / bod. > Ovšem, pokud mám strom na kterém je rozcestník, body záchrany a třeba i > křížek mám najednou 4x POI na tom samém místě. A to taky není ideální. Jak to > ideálně vyřešit ale pořád nevím. > > Marián > > ---------- Původní e‑mail ---------- > Od: Vojtěch Dvořák <[email protected]> > Komu: [email protected] > Datum: 18. 7. 2026 21:28:41 > Předmět: [talk-cz] Kvůli uživateli funH4xx0r končím s poloautomatickými a > plně automatickými importy > > 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 > > > _______________________________________________ > talk-cz mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-cz > https://openstreetmap.cz/talkcz > _______________________________________________ > talk-cz mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-cz > https://openstreetmap.cz/talkcz
_______________________________________________ talk-cz mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-cz https://openstreetmap.cz/talkcz
