Hungary/Szerszámzat

From OpenStreetMap Wiki
Jump to navigation Jump to search

Bevezetés

Ennek az oldalnak a célja összefogni az OpenStreetMap hozzájáruláshoz és karbantartáshoz hasznos automatizmusokat. A következő matrix csevegőszobában is hozzá lehet szólni, de lehetőleg minden maradandó és visszakeresésre érdemes információmorzsát a wikibe is vezessünk fel:

Eszközök

Utcanév teljesség

POI matcher

OSM GIMMISN

Egy weboldal amin keresztül bárki fókuszálhatja szerkesztés tevékenységet hiányzó házszámok vagy utcák irányába nem terjeszthető referenciák alapján.

OSM GIMMISN reference

Kézi parszerek

OSM 3D Building Tagger

Reláció szakadás ellenőrző

TODO: forward szerep a relációban -> a forward-ok végpontjai egyeznek-e, ha nem, akkor az elágazásoknál kell speciálisan kezelni (utolsó 1 sávos darab), illetve körforgalomnál

Úr Balázs tapasztalata szerint ez sokszor helyesen jelez olyan relációt is amivel volt probléma:

Olyan eszköz volna ideális ami nem webes, hanem valami parancssoros amit cron-nal akár óránként lehetne futtatni -> hiba esetén például emailt küld vagy XMPP üzenetet.

Lehetőleg cache-eljen amikor van értelme: azaz amíg nem változott semmi addig egy bizonyos ideig lemezen letárolhatna egyes lekérések részeredményét.

Lehetőleg ne egyesével kérje le a vonalakat, relációkat és pontokat, hanem kötegenként:

Implementált verzió: https://github.com/attilakundev/osm-rcaf

Bemutatóvideó (FIXME PeerTube): https://www.youtube.com/watch?v=RScDJBB3t9g

Fejlesztő: User:Ottwiz

Parszerek

Eldobható kézi parszerek, segéd scriptek:

Magas szintű nyelvtanokból generált parszerek:

Egyetlen vonalat tartalmazó GPX (mapping parti útvonal) átalakítás OSM mediawiki eseményoldalakon kezelt beágyazott GeoJSON térképpé:

OSN (JOSM által is fájlba letölthető Notes térképjegyzetek) átalakítása GPX-re ami könnyebben nézhető offline terepen:

Letöltött OSM fájlból fixme=* kulccsal rendelkező pontok átalakítása GPX-re:

Berekfürdő POI weboldalak átalakítása egységes CSV-re:

Gárdony POI weboldalak átalakítás egységes CSV-re:

Velencei-tó POI weboldalak átalakítás egységes CSV-re:

NAV adóslista pdf tisztítás és átalakítás egységes CSV-re:

Utcanév parszerek

Komponensek

  • [_] Nyers címszöveg alapú javítás alkalmazó: ez nem nagy kaland, `s/xy/zzy`, bár skálázhatóság szempontjából lehet, hogy érdemes egy scope oszlopot is felvinni amivel opcionálisan import forrásra szűrhető.
  • [x] Egy parszer ami parszolja a string címeket és kulcs-érték párokat ad vissza (hívhatjuk ezt soronként JSON-nak) - a nyelvtan bizonyos rögzített tokeneket már eleve normalizálva parszol fel (mint a level=fszt. => level=Ground, vagy type=t. => type=tér)
  • [_] Programozott mező normalizálók (akár egyazon programban): emelet és épület nagybetűs római számmá átalakító, alátörés kisbetű, lépcsőház nagybetű, helyrajzi szám komponensek nagybetűk, város nagy kezdőbetű.
  • [_] Szótár-helyettesítés alapú utcanév nagybetűsség normalizáló, akár elírás kereső/javító
  • [_] Kulcsokra szűrhető regexp (vagy sima search) alapú szöveges patch tábla alkalmazó: itt már lehetőség van, hogy csak egyes mezőkben javítson (pl. csak utcanév) és csak bizonyos egyéb címkék megléte esetén (pl. City=Gárdony) - ennek a szintaxisát még ki kell találni (CEF?)
  • [_] Egy tool ami alapigazságot táblát állít össze már ellenőrzött és jóváhagyott OSM extraktumból és saját kézi táblákból
  • [_] Egy manuális tool ami elemez minden adatforrást és meglévő adatot, és jelzi a többértelműségeket (út/utca)
  • [_] Egy tool ami alkalmazza a kulcs-érték köztes formára az alapigazság alapú helyettesítést (Xy út -> Xy utca)
  • [x] Egy progi ami a kulcs-értékekből string címeket állít elő kanonikus formában.

Ismert hibák

  • Tegyük fel, hogy létezik egy településen egyszerre ugyanarra a vezetéknévre keresztnév és tanya is, például: Debrecen Balogh tanya, Balogh Tamás utca. Tegyük fel, hogy a címből lehagyják a közterületi típust és rövidítik a keresztnevet vagy tanyát és csupa nagybetűs az egész (vagy felcserélték a kis-nagybetűket). Ekkor a `DEBRECEN, BALOGH T. 1` nem megkülönböztető. Egy olyan településen viszont ahol csak az egyik van a kettő közül, feloldható, de ezt egy külön rétegben kell megtenni.
  • A Nominatim a Mo 1 Rana keresésre megtalálja a Mo i Rana települést is mivel átváltja a név közepén az arab számot rómaira. Javaslom, hogy egyelőre ne kezeljük az utcanevekben szereplő arab/római/betűvel kiírt variánsokat automatizálva. Egy későbbi fejlesztéssel nem lehetetlen ezt is támogatni egy bizonyos mértékig ("kiejtés szerinti egyezés").

Utcanév normalizáláshoz szavak

Előtag:

  • gróf
  • dr.
  • ifj.
  • id.
  • özvegy?

Végződés:

  • (helyesírás szerint - a táblán lehet, hogy más van)
  • 'alsó','felső','középső','belső','külső','széle','mente', 'vezető','úti','utcai','téri','parti','menti','völgyi','hegyi','réti','aknai','terv',
  • 'király','királyné','királynő','vezér','pap','esperes','bíró','apó','fejedelem','cár','pápa','királyfi','ispán','baba','bég','bán','herceg',
  • 'apát','bíboros','püspök','érsek','nádor','hercegprímás','ezredes','tábornok','házaspár','basa','takács','ács','altábornagy','kapitány','doktor','rektor','professzor', 'vezérezredes',
  • 'vértanú','vértanúk','cigány','apostol','tudósok','jakobinusok','nővér','testvérek','deák','nagyfejedelem','barát','vitéz','vitézek','huszár','honvéd','hősök','ifjúság',
  • 'madár', 'banka', 'gém', 'gerle', 'poszáta', 'réce', 'szalonka',
  • 'bikavér', 'fűszeres', 'kincse'

Utcanév normalizálás

  • Képezzünk kisbetűs köznévszótárat a FreeDictből úgy, hogy kivonjuk kisbetűsítve a FreeDict tulajdonneveket
  • Név eleje: amíg az első kisbetűs előtagok között van a szó: kisbetűs a szó és menjünk a következő szóra és ismételjük
  • A következő szó mindig nagybetű (számmal kezdődőt is annak vesszük)
  • Utána szavanként: Ha a köznevek szótárában van, akkor kisbetű, különben nagybetű

OSM RSS Juggler

Emészthetőbb vagy bővebb formában összegzi néhány OSM-specifikus RSS csatorna tartalmát. Óránként fut, és ide tölti fel az átalakított RSS-eket, amit az OSM-hu mindeközben szobában az RSS bot figyel:

Forrás:

OSM-hu mindeközben

Ez egy olyan mátrix szoba, ahol a magyar közösséget érintő frissítések folyamatosan be vannak csatornázva. Forrásainak alapja a Hungary/Kapcsolat cikkben is felsorolt feedek.

OSM RSS Juggler feldolgozás alá vetve:

Nyersen bekötött források:

OSM-Rnd

Grafikus szerkesztő

http://repo.hu/projects/osm-rnd/

- adatok letoltese a szerverrol (at lehet konfiguralni a sandbox szerverre is)

- vektoros megjelenites es szerkesztes (szerkeszteshez erdemes bekapcsolni a thin draw uzemmodot, | a hotkey, de a menuben is megvan valahol)

- sajat stiluslap, meg keves dologgal feltoltve, hogy a dolgok kulonbozo szinben es vastagsaggal jelenjenek meg

- tagek szerkesztese, node/way geometria modositasa, uj node/way rajzolasa

- imagery hatter layerek (Bing es konfiguralhato TMS, amivel pl a FOMI es a normal OSM tileset is mukodik)

- konfiguralhato imagery offset

- modositasok feltoltese (commit)

- undo mindenre

- optimize plugin, ami tud egyenes vonalba rendezni meg ortogonalizalni

- split/merge muvelet (pl utak vagy pontok osszevonasa)

- way reverse

- "szokasos" dolgok, amiket egy -rnd szoftver tud: konfiguralhato menurendszer, 12+ nyelven szkriptelhetoseg, minimalis kulso fuggosegek, modularitas (ami csak lehet pluginbe megy), GUI es tenyleges tevekenyseg elvalasztasa (igy akar GUI nelkul forditva automatizalt feldolgozo toolnak is jo)

A fenti list ossz kotlsege 53 ora fejlesztes volt, es nagyjabol ez volt a 0.0.1-es releaseben. Ami azota kerult bele (egyelore csak svn-bol erheto el):

- egy koteg 2..4 leuteses forrogomb azokra az tagekre, amiket leggyakrabban terkepezek

- felig-meddig mukodo presets GUI (iD-bol szkripttel konvertalt adatbazissal) - azokra, amiket ritkabban terkepezek es/vagy sok mezoje van

- minimalis relation kezeles (most meg nagyon manualis fapad, mert meg csak mostanaban kezdtem el foglalkozni az egesz temakorrel)

- property editor, amiben meg lehet nezni peldaul egy way vagy relation gyerekeit vagy hogy az adott objektum milyen way vagy relation gyereke

- DRC plugin (villamosmernok temrinologia: 'Design Rule Checker'; ellenorzes, most meg csak geometria, commit elott automata fut)

- lehet objektumlistat kerni egy adott pont kornyekere, a listazott objektumokat ki lehet jelolni, a metaadat szerkesztesre valo dialogokat behozni rajuk; igy eleg egyszeru az egymast atfedo 3 vagy tobb vonal kezelese is

- 4 konfiguralhato reference plane; ezt arra hasznalom, hogy ha egy kornyeken sok haz/kerites/ut 1 (vagy nehany) kulonbozo iranyvektorral epult, akkor ezeket a vektorokat gyorsan fel tudjam szedni es gyorsan tudjak valtani ezek kozott; ha van aktiv referenciasik akkor az orthogonalize action ez alapjan dolgozik; van hozza crosshair is, igy mar szemmel is eleve kb jol rajzolom be a merolegeseket


A celom nem az, hogy egy mindenki szamara kenyelmes JOSM-helyettesitot csinaljak. Inkabb az, hogy vegre sajat hasznalatra hatekony es kenyelmes szerkeszto letezzen. Sokkal jobban hasonlit a pcb-rnd nevu nyomtatott aramkoroket tervezo CAD programomra, mint a JOSM-re.

osm-poi-hintmaker

https://codeberg.org/urbalazs/osm-poi-hintmaker

Referenciaadatok alapján azoknak a helyeknek a megjelenítése, ahonnan valószínűleg hiányoznak térképelemek az OpenStreetMap adatbázisából, illetve azoknak az OpenStreetMap-adatoknak a jelzése, amelyek nem találhatóak meg a referenciában.

Végfelhasználóknak

OSM mini

Régi böngészőkön (Opera mini) is futó takarékos kísérleti térkép. Jelenleg csak megjelenítés van benne, de kellene rakni bele keresést (Nominatim), térképjegyzet hozzáadását és otthoni kezdő téglalapot is.

https://bkil.gitlab.io/static-wonders.js/osm/map.html

Bookmarklet

POI userjs

Máltai szeretetszolgálat intézményeiből GeoJSON (JS0):

Google Maps POI beágyazásból GeoJSON (JS0). Mivel minimális az implementáció, kérem a hibákat jelenteni (webcím, veremkiíratás):

NAV elemiszer

Parkolóautomaták felmért azonosítóinak könnyebb ellenőrzésére:

https://bkil.gitlab.io/static-wonders.js/userjs/nav-elemiszer.html

Tervek

A cím javítási folyamat:

  1. preprocesszor: 9999 2483 2483 GárdnyBalatoni utca 2 V2 üzlet -> 2483 Gárdony, Balatoni utca 2 V2 üzlet
  2. szeparáló: 2483 Gárdony, Balatoni utca 2 -> 2483|Gárdony|Balatoni utca|2|V2 üzlet
  3. referencia előállító (osm + alapigazságok)
  4. cím javító: 2483|Gárdony|Balatoni út|2|V2 üzlet

Kifejtve:

Preprocessor

Ami a durva hibáktól megtisztítja a címet, vagy eldobja

  • javítandó: 9999 2483 2483 GárdnyBalatoni út 2 -> 2483 Gárdony, Balatoni út 2
  • itt akkor 99% program szinten gondolkozunk, hogy db jog miatt
  • patch táblában esetleg a string rész összevonásokat/szétválasztásokat lehet megcsinálni
  • GárdnyBalatoni -> Gárdony, Balatoni

eldobandó:

  • 9999
  • mozgóbolt
  • Magyarország teljes területe
  • 1011 Budapest Belterület
  • csomagküldő
  • www.theabags.com

az eldobandó listát egy részét érdemes lenne leválasztani egy fájlba, ekkor nem kell a programba nyúlni minden bővítéshez a lista előnye, hogy a meglévő halmazomat be tudjuk emelni, majd a leprogramozott részket kiszedni belőle

Szeparáló

  • Ezt kamitól át tudjuk venni első körben
  • postal, city, street, number, hrsz, egyéb szemét
  • amit nem tudunk bontani, azt az 1-es lépésben kell javítani, hogy megegye a szeparáló,
  • így sokkal könnyebb minta szeparálót túlbonyolítani, de így is kezelni kell
  • közterület jelleg és házszám nélküli dolgokat: Május 1. 22.
  • házszám, leválasztásnál figyelni: 7-es főút x. km, Fő út 2. pavilon, Budafoki út fsz. 5.,
  • helyrajzi számokat le kell választani: Budaörsi út 1092/6, Diák utca 20. 2956/3 hrsz, Diák utca (2956/3 hrsz) 20.
  • a dupla címeket: Karinthy Frigyes út Egry József utca sarok 1. számú pavilon

Referencia előállítás

  • a) osm-ból, overpass pl. a hibákat (duplikáció, elírások) majd osm-ben kezeljük előtte,
  • b) kiegészítés osm-ben nem szereplő, de valósnak tűnő utcákkal "alapigazságokkal"

Javító

(javító fázisra csak azok címek mennek, amik nem felelnek meg a referenciának)

  • a) (ha a forrás településszintű) ahol irsz. tartományon kívüli -> listára tevés, majd preprocessorba építés vagy eldobás, goto 1
  • b) hibás cityk listára tevése, javítása: én patch táblába tenném az elírások javítását,
  • már csak azért is mert ezt tudom adni és akkor megspóroljuk a dupla munkát
  • c) utcák javítása, ami nem felel meg a referenciának, azon:
  • c1) a referenciából adott irsz-re runtime generált halmazzal egységesítjük

(ennek megvan az előnye, hogy nem fog félremenni szemben az elírások hasonlósággal való javításával)

  • Ady E. -> Ady Endre
  • Ady E -> Ady Endre
  • Ady -> Ady Endre
  • Ady Endre út -> Ady Endre utca

c2) a fenmaradóra egyéb algoritmikus javítások:

  • u. > utca stb.
  • tbd

c3) a fenmaradóra patch táblával (ezek nagy részét tudom generálni a meglévő szótárakból)

  • általános patch tábla: Mórczzs -> Móricz Zsigmond
  • irsz-település szintű patch tábla a többi esetre: Gárdony Balassa Bálint > Balassi Bálint, Szabdság > Szabadság

Fejlesztési igények

Amennyiben segítené az OSM fenntarthatóságát vagy népszerűsítését, érdemes mérlegelni, hogy bizonyos további eszközöket elkészítsünk vagy továbbfejlesszünk. Ha valaki szeretne hobbiból programozni egy kicsit, érdemes innen válogatni és egyeztetni az ötletgazdával. Ha más is szívesen részt venne 1-1 ötlet mentorálásában, bátran írja be magát a mentor sorba!

Mentorálás jelentése a következő (alkuképes!). Amennyiben valaki szeretné implementálni, legyen kihez kérdéssel, vagy akár órahosszas live Jitsi supporttal fordulni. Lehet ez olyan szinten is, hogyha jön valaki aki vagy a programozási részében, vagy az OSM részében kicsit bizonytalan, akkor segít utat mutatni, hogy hol tudná magát a vállalkozó továbbképezni ez irányban (és/vagy segíteni). Vagy ha nem egyértelmű a kiírás, van kitől egyértelműsíteni. Ha készül vagy elkészült, legyen kinek átadni. Esetleg még segíthet is a végén a csiszolásban, de ez mindig egyéni alku kérdése. Ha több ember is szeretne válaszolni ilyesmire, bátran írja be magát másod-mentornak (illendő egyeztetni a meglévő mentorral).

Lásd még:

Térképjegyzetenként állapot nyilvántartása

Cél: szeretnénk fókuszáltabban feldolgozni az osztott teendőket, úgy mint térképjegyzetek, fixme=* vagy más QA visszajelzések. Amit valaki látott, de nem tud vele mit kezdeni, elrejtheti saját magának. Megbízható körök másoknak is (más állapotba helyezi a "Kanban táblán").

Például:

  • needs-verification: anonim bejelentő és nem-triviális kérés esetén, de távolról néha kikutatható
  • needs-survey: távolról nem ellenőrizhető,
  • waiting-for-answer: ha a bejelentőtől visszakérdeztünk egy fontosat

Így azokat el lehetne rejteni a térképünkről amikkel úgysem tudunk mit csinálni távolról, ezáltal szembeötlőbbek lennének azok amik megoldásra vagy megerősítésre várnak.

Inspirációként itt egy régebbi angol jegyzet:

Mentor: User:bkil

Változáscsomag figyelő QA bot

Cél: ha aggályos adat kerül a térképre, az minél hamarabb kerüljön feloldásra, mivel ilyenkor még az közreműködő is emlékezni fog a kontextusra és/vagy a helyszín közelében lesz (nyaralási baki esetén).

A jövőben minute diff alapú replikációval akár 1 percen belül szólhatnánk egy járőrünknek (és/vagy hatalmas bakinál a közreműködést beküldőnek is).

Bármilyen meglévő QA eszköz által feldobott jelzésekre szűrhetnénk, illetve ki is egészíthetnénk.

Példák:

  • felvett valaki egy átfedő egyszerű poligont (vagy POI-t) ami alatt már található egy azonos funkciójú multipoligon
  • szerkesztői hozzáértés hiánya vagy iD okán elrontott relációk

Egy kapcsolódó parszer bot ami a perces változás alapján szól, hogyha valaki elmozdított egy place=* csúcsot, üzemeltetve és bekötve a mindeközben szobában:

Mentor: User:bkil

Elérhetőségek javítása

Végigmehetnénk az összes contact-on (website, contact:website, contact:facebook, stb), és egyrészt ellenőrzi a szintaxist (például valami vagy account ID vagy fully qualified URI), és szól ahol hibádzik. Egy másik eszköz rá is hívna ezekre, és amennyiben nem 2xx, szólna (ilyet pont tud is az egyik QA eszköz ahogy a robots.txt kapcsán előkerült, csak mostanában nem futtatgatják újra a Dunától keletre). Egy megszűnt sörözőnek gyakran megszűnik a honlapja vagy Facebook oldala is (vagy ott kiírják a megszűnt szót), így ez a frissesség fenntartására is alkalmas lehet.

Amennyiben például website esetén hiányzik a séma, végigpróbálhatja a https://, http:// ftp://, gopher://, gemini:// mindegyikével, illetve ezen belül www/ftp/stb aldomain használatával illetve anélkül is, és amelyik sikerült arra át is javíthatja. Illetve berakna az URI végére egy lezáró /-jelet ahol nincs path vagy mappa van, levehetné akár az ismerten felesleges tracking paramétereket (Facebook és társai), akár ellenőrizhetné, hogy azzal és anélkül is ugyanazt az oldalt adja vissza a szerver.

Mentor: User:bkil

Szabad utcakép megjelenítése

Elég hasznos lenne egy JOSM plugin ami egy NextCloud osztott mappában (vagy egyéb hivatkozás alatt) található fényképeket pakol fel a térképre Mapillary mintára.

Kellene hozzá talán egy NextCloud bővítmény. Ahogy látom a mappa áttekintő nézetében ráhív egyenként a /preview végpontra ami 20-30kB-os előnézeti bélyegeket ad vissza (256x256-ban amit utána 32x32-ben jelenít meg!). Ebben simán elférne az, hogy akár a JPEG-ben, HTTP válasz fejlécben vagy még inkább az áttekintő táblázatban visszaadhatná 1-1 fotó koordinátáit.

Továbbá egyszerű volna belepatchelni a skálázó eljárásba az EXIF megőrzését is ami jelentősen gyorsíthatná a betöltést, mivel csak nagyításkor kellene letölteni az eredeti fotót. Egyelőre nincs benne az EXIF amikor csak normál méretben megnyitjuk NextCloud alól (ami 1024 szélesre alakítja, ~700kB), csak ha a download gombra kattintva letöltjük az eredetit (>5MB). 

JPEG image data, JFIF standard 1.01, resolution (DPI), density 96x96, segment length 16, comment: "CREATOR: gd-jpeg v1.0 (using IJG JPEG v62), quality = 90", baseline, precision 8, 1024x1365, frames 3

A fenntartható végső megoldásnak később valami geoindexelt, címkézett föderált (PixelFed, Friendica) vagy P2P (IPFS, Tahoe-LAFS) alternatíva lesz szükséges, de az is egy gyakori használati eset, hogy valaki megkér minket, hogy OSM Fonó alatt dolgozzuk fel a nyaralási fotóit közösen.

Egy kapcsolódó NextCloud bővítmény ami OSM térképen jelenít meg georeferált fotókat akár rekurzívan almappákban:

Mentor: User:bkil

WMS dinamikus réteg megjelenítése

Egyes WMS példányok az érdekes információkat nem fix csempepiramisban szolgálják ki, hanem a dinamikus végpontra kell ráhívni képernyőnként. Ideális és skálázható megoldás volna vagy a JOSM WMS térképréteg kezelőjét ezzel is kiterjeszteni, vagy egy külön JOSM bővítménnyel gyorsítótárazni és láthatóvá tenni ezeket. Lehetne akár közvetlenül a képernyőre rajzolni, bar akkor a gyorsítótárazás nem lesz triviális.

Alternatív körüljárásként virtuális csempepiramist is lehetne generálni az éppen megtekintett szelethez a háttérben. Ekkor átgondolandó, hogy volna-e értelme a dinamikus WMS példány terhelését úgy csökkenteni, hogy ugyanezen számítást egy proxyn végezzük és ott is gyorsítótárazunk. Ez akkor a leghasznosabb ha egy ember gyakran visszanéz ugyanoda vagy sokan nézegetik ugyanazokat a részeket.

Mentor: User:bkil

Hozzászólásban említett fotók mentése szabad utcaképbe

Ha találunk egy fotót említve egy térképhiba hozzászólásban (pl. amit a StreetComplete beír ^https://westnordost.de/p/.*\.jpg$), azt jó volna lementeni tartósan (pl. NextCloud, CryptPad, PixelFed, Lutim, Friendica, stb) amit meg tudunk jeleníteni majd geoindexelt JOSM pluginnal (Mapillary mintájára). Előtte a botnak kérnie kellene egy beleegyező nyilatkozatot a feltöltőtől (nem tudom mi az alapértelmezett licenc StreetComplete-ben).

Mentor: User:bkil

Hibajegy öregedés

Jó lenne rendszeresen átnézetni az összes nyitott térképjegyzeteket (és utána naponta az újakat), megnyitogatni a linkeket, és ha valamelyik nem 2xx, akkor szól nekünk és/vagy hozzászól a hibajegyhez. Ez kiszűrné azt is ha nem sikerült feltölteni a fotót (és másnap még van esély rá, hogy az ott nyaraló ember le tudja újra fotózni), vagy ha el van gépelve egy URL.

A StreetComplete-nek van egy olyan github hibajegye, hogy néha sikertelen a fotó feltöltése de ő ezt nem veszi észre, így 404 lesz a végeredménye. (Valaki más szerint pár hónap után elvesznek fotók, eddig ezt nem tudtam megerősíteni)

Mentor: User:bkil

Saját objektumok járőrözése

Tegyük fel, hogy van egy bizalmi kör. Megegyeznek, hogy (akár heti váltásban) on-call duty-ban lesznek, azaz reagálnak arra, ha valaki a körön kívülről destruktív műveletet végez az ő általuk létrehozott (vagy konkretizált) objektumon.

Példa: felvettem egy tűzcsapot. Egy új szerkesztő véletlenül nyomtalanul és indoklás nélkül letörölte (vagy egy boltot life cycle helyett letörölt). Ezután vagy utána kell nézni a művelet jóságának, vagy egyeztetni kell a közreműködővel és vissza kell vonni a destrukciót (vagy az egész változáscsomagot ha ettől az gyanússá vált). Ez minél hamarabb megtörténik, annál valószínűbb a visszavonás ütközésmentessége, a szerkesztőnél annál több lesz a kontextus, annál kevesebb destrukciót visz végbe és többet tanul a dologból.

Mentor: User:bkil

Adószám szintaktikai ellenőrzés

A ref:vatin:hu kulcsot ellenőrizhetné, 12345678-1-41 típusú e. Az első 8 karaktert CDV ellenőrzés alá vehetné, a második és harmadik számnak is fix az értékkészlete.

Mentor: User:vasony

Megvalósította: User:urbalazs, forráskódtároló, a bemutató előadás diái.

Telefonszám ellenőrzés

A phone és contact:phone át kellene nézni. Ahol nem 06-ot +36-ra javítani, valamint mezőhosszakat és vonalasaknál az értékkészletet validálni. Ha nagyon tutik akarunk lenni vezetékesnél, akkor az nmhh által nyilvántartott érvényes tartományokkal is össze lehet vetni.

Mentor: User:vasony

Nyitvatartás ellenőrzés

Először csak szóljon ha rossz a szintaxisa a parszer szerint, aztán továbbfejlesztve akár javíthatja is ha triviális (mondjuk magyarul H-P 10-18. Van akit a PH off hiánya is zavar.

Mentor: User:vasony

addr QA

Mentor: User:vasony

Értesítés weboldalon történő változásokról

Előfordul, hogy adott szolgáltatótól a múltban kaptunk engedélyt adott weblap vagy dokumentum importálására és/vagy ellenőrző listaként valaki már feldolgozta az összes ott sorolt entitást. Amennyiben az oldal, dokumentum (vagy dátumozott stabil hivatkozással rendelkező aloldal esetén az azt tartalmazó oldal) változik, érdemes volna újra feldolgozni a változásokat. Amennyiben lehetséges, ideális volna a változást kivonatolni emberileg emészthető formában (diff). Az értesítés történhet akár RSS-ben, levélben (levlista), mátrix vagy Friendica bottal.

Mentor: User:bkil

Kommunikációs platformok közti bridge

Már jelenleg is túl fragmentált az eleve szűkös magyar közösség. Jó lenne egy bottal összekötni egymással a saját levlistáinkat, fórumunkat és esetleges további kompatibilis platformokat (Friendica, Matrix, térképjegyzetek?).

Mentor: User:bkil

Egyéni RSS-matrix összekötés

Az OSM mindeközben szobában található RSS-eket már kezdjük kinőni, és a többi fejlesztési igény is jobbá tehető volna amennyiben matrix kliens funkcionalitással rendelkezne értesítések és vezérlés végett.

Eddigi ötletek:

  • Térképjegyzetek szebben formázva (felsorolásban, 1 elem/jegyzet)
  • Lezárt térképjegyzetekhez tartozó üzenetek törlése matrix alól (TODO: vagy csak kipipálni őket, esetleg megszerkeszteni, elhalványítani, kisbetűre alakítani, stb)
  • QA eszközünk miután észreveszi, hogy egy szerkesztő kijavított egy korábban, mostanában beküldött (1 hét, 1 hónap?) hibát, kipiálhatná vagy a fentiek szerint megjelölhetné
  • Az anyabekezdés szerinti hosszútávú tervek szerint matrix `reply` gombbal is lehetne válaszolni a térképjegyzetekre - az integráció ezen része valamivel egyszerűbb lehet, így talán leválasztható.

Mentor: User:bkil, User:Vasony

Hierarchikus matrix bot szobák

A botok és egyéb QA eszközök használhatnának átfedő matrix szobákat (kicsit olyan mintára, ahogyan az üzenetek fediverse alatt címkékkel vannak kategorizálva). Például létezne a matrix szobákon valamiféle taxonómia: 

OSM-hu mindeközben
 #OSM-jegyzetek
 #OSM-levlista
 #OSM-wiki
 #OSM-qa
  #OSM-qa-addr
  #OSM-qa-wlan
...

Minden beküldött üzenet vagy értesítés duplikálódna a hierarchiában elhelyezkedő minden ősben is. Azaz aki szereti a zajt, az a nagyobb szobákhoz csatlakozik és minden, a gyerekben folytatott beszélgetésről is értesül, aki nem, az csak a specifikusabbakhoz.

MVP-ben elég csak egyirányú kommunikációt támogatni (külső rendszer -> bot -> emberek) és a matrix kliens-szerver API-t hívni, de a többi fejlesztési igényhez képest ez jelentősen rosszabbul nézne ki azzal. Úgy fog kinézni mintha minden továbbított üzenet ugyanattól a bottól származik és az eredeti szerző neve szövegesen lesz az üzenet elején megemlítve. GDPR szempontokból implementálni kell azt is, hogyha a szerző javítja vagy törli az eredeti üzenetét, akkor az összes duplikátumon is végre legyen hajtva.

A kétirányú megvalósítás out of scope, bár MVP-ben az adott üzenetre adott `reply` gombos válaszokat és reactjikat még lehetséges továbbítani nem túl nagy erőfeszítéssel.

Az esztétikusabb megjelenítéshez a Matrix S2S föderációs API-t kellene implementálni amivel virtuális felhasználókkal lehetne bábozni, de ez elképzelhető, hogy már nem megoldható ingyenes PaaS PHP webhoszting alatt, csak VPS alatt, és egy igazi matrix szerver egyes elemeit is implementálni kéne. Meg kéne nézni, hogy csinálták a többiek akik hasonló közelítésekkel éltek:

Mentor: User:bkil

Plágiumgyanús tevékenységek kigyűjtése

A teljes OSM history XML magyar kivágatának elemzésere volna szükség, igény szerint, de legalább havonta újrafuttatva. Egy dicsőségfalra ki lehetne gyűjteni, hogy melyik szerkesztő mennyi, külső adatbázisokban is vélhetően tömegesen fellelhető adatot töltött fel, közte utcanevek (utcák?), házszámok, POI-k. Ez a tény még magában nem aggályos.

Ezen belül rangsorolható, hogy a felvitt címkék és változáscsomagok metaadatai, területei lefedettsége és időbeliségének elemzése alapján felvetődhetnek-e életszerűségi kérdéseket, például ha egy friss szerkesztő napi 1000 utcanevet visz fel az ország minden szegletéből véletlenszerű helyszíneken 1 éven keresztül.

A rangsor tetején elvileg már csak nagyon kevés szerkesztő és/vagy változáscsomag lesz, amit egy erre szakosodott, helyi szerkesztőkből álló bizottság kézzel egyenként ki tud elemezni és pipálgatni, miután felkeresték az érintett szerkesztőket és/vagy környéki közreműködők véleményét is 1-1 eset kapcsán.

Sokféle magyarázat fordulhat elő:

  • 1-1 import vagy központi hackathon maradt dokumentálatlanul, ezeket tudjuk a wikin is dokumentálni
  • tanfolyam kapcsán megosztott OSM fiókok
  • feltört fiókok
  • spam és más szándékosan hibás adat
  • nagyvonalú interpoláció meglévő adatok alapján
  • virtuális bejárások szabad talajközeli fotók alapján
  • nem engedélyezett források, plágium
  • false alarm

Mentor: User:bkil

Plágiumgyanús légifelvétel használati szúrópróba

Vizsgálja az alábbi típusú új vagy elmozdított objektumokat:

  • épület
  • kerítés
  • út

Tekintse először a változáscsomag forrásaként megjelölt légifelvételt, majd az összes szabadon elérhetőt.

Ritkítsa a vizsgálandó objektumok készletét típusonként aszerint, hogy reprezentatív körzetenként maradjon egy-egy összefüggő szomszédság.

Állítson elő emberi közreműködésre (kb. CAPTCHA) olyan mikrofeladatokat ahol rákérdez, hogy hihető-e, hogy az érintett szomszédság objektumainak geometriája illeszthető-e valamelyikre valamilyen eltolással.

Mentor: User:bkil

Plágiumgyanús légifelvétel használati felfedező

Vizsgálja az alábbi típusú új vagy elmozdított objektumokat:

  • épület
  • kerítés
  • út

Tekintse először a változáscsomag forrásaként megjelölt légifelvételt, majd az összes szabadon elérhetőt.

Szomszédságonként becsülje meg annak valószínűségét, hogy az érintett objektum geometriája illeszthető-e valamelyikre valamilyen eltolással.

Példák képfeldolgozó algoritmusokra:

Az eltolást próbálja értékelni:

Egy külön ellenőrzésként figyelmeztessen, ha az eltolás pontatlan.

Mentor: User:bkil

OsmAnd közreműködési és térképjegyzet leszúrási figyelmeztetések

Amennyiben az ember offline OsmAnd POI-t szerkeszt vagy térképjegyzetet szúr le, érdemes volna ellenőrizni, hogy nem-e túl régi az adott ország térképe. Ha igen, figyelmeztetni leszúrás vagy feltöltés előtt.

Lehetne erre egy bedrótozott korlát is (pl. 6 hónapnál régebbi adatbázisnál), vagy lehetne akár dinamikus is attól függően, hogy az adott területen mennyi időközönként volt a múltban a szerkesztések várható értéke és a mutatott objektum környéke mikor volt szerkesztve (egyenletességet feltételezve). Lehet a művelet típusa szerint is személyre szabni (például boltok gyakrabban szűnnek meg mint hidak).

Azt is érdemes lehet átnézni, hogy figyelmeztet-e kellőképpen még mielőtt névtelenül töltünk fel térképjegyzetet benne. Ki kell emelni, hogy fiók nélkül nem értesülünk a válaszról és kevésbé bíznak meg bennünk a szerkesztők. Érdemes lenne OSM regisztrációt is felajánlani API-n keresztül, mivel csak egy név, email és (generálható) jelszó kell hozzá.

Kiemelendő az is, hogy ez publikus információ, nem magánjegyzet (könyvjelző) - ideális volna ha könnyű lenne kattintásra átalakítani arra vagy visszavonni ha félrenyomás eredményezi.

Mentor: User:bkil

internet_access QA

Egy eszköz jelezhetné a WLAN tulajdonságok kapcsán fellépő problémákat.

  • internet_access=* használata internet_access:ssid=* nélkül
    • wifi=* használata
    • internet_access:ssid=* használata internet_access=wlan nélkül
    • internet_access=wlan használata internet_access:fee=* nélkül, különösen, ha az SSID-ben szerepel a "free" egy szinonimája, vagy ha olyan elsődleges funkción szerepel ahol köztudottan vagy ingyenes vagy fizetős szokott lenni
      • Ellenpélda: office=* ahová nem feltétlenül netezni járnak az ügyfelek a vendéghálózaton kívül, de a navigációt és a karbantarthatóságot segítheti még akkor is ha személyesen nem is mértük fel a költségét, mert egy wardriving kimeneten vettük észre utólag
  • Ha egy csupasz pontként van felvéve a WLAN elsődleges funkció nélkül
    • Ha egyéni antennaként van leszúrva.
    • Legtöbbször érdemes egy olyan közhasznú funkcióhoz rendelni, ami WLAN jelölés nélkül is megállná a helyét, ezen belül olyan típusra aminél gyakran számíthat rá az ember illetve minél nagyobb kiterjedésűre. Például egyéni man_made=antenna helyett a játszótérre vagy buszállomásra amin elérhető, ennek híján esetleg egy padra, ennek híján esetleg lámpaoszlopra.
  • Ha lemaradt egy POI-ról az elsődleges címke (ezt egy ennél bővebb QA eszközzel is lehetne érzékelni egyéb kulcsok alapján)

Itt egy példa Overpass turbo lekérdezés inspirációként, de a teljes megoldáshoz valószínűleg érdemes lekérni az összeset és utána kézi implementációval leválogatni. 

nwr["internet_access:ssid"][!amenity][!shop][!tourism][!leisure][!office][!craft]

Mentor: User:bkil

Videók listájának frissítése wikiben

A fellelhető PeerTube videók listája itt található: Hungary/videok#PeerTube. Ezt a wiki markupot a következő scraper script elő tudja állítani :peertube2wiki.sh.

A feladat létrehozni egy robot felhasználót, cron-ból meghívni ezt a scriptet legalább naponta, a mediawikire bejelentkezni, ott átírni a bekezdést majd elmenteni.

Opcionális fejlesztésként további scraperek fejleszthetők amik más platformokról is összegyűjtenék a friss magyar OSM videókat.

Előállítható ebből egy RSS is ami mindet tartalmazná.

Mentor: User:bkil

Referencia POI összerendelő

Bemenet:

  • Egy Overpass lekérdezés ami visszaad adott típusú POI-kat az OSM-ből
  • Egy GeoJSON egy adott, nem importálható referenciából
    • Ha nincsenek benne koordináták, azokat először a címekből Nominatim segítségével geokódolhatjuk
  • távolságmetrikára példa: https://pypi.org/project/haversine/

Kimenet:

  • melyek szerepelnek már OSM-en
  • amelyek fent vannak a referenciában, de OSM-en nem
  • amelyek fent vannak OSM-en, de a referenciában nem

Segédtábla:

  • sikeres és sikertelen összerendelések, hogy legközelebbi futásnál ne legyen fals pozitív/negatív
  • ellenőrzöttségi állapot hozzárendelés eltárolása és publikálása
  • OSM objektum típus, ID és verzió, illetve a koordináta (bár redundáns, de frissítésnél vagy törölt POI esetén könnyebbséget hoz)
  • szintetizált referencia ID (akár egyetlen hashbe gyúrva)
    • adatkészlet UUID (pl. fájl hash, esetleg URI és dátum)
    • parszer UUID (git commit)
    • rekord szám (sorszám)

Mentor: urbalazs @ OSM, User:bkil, User:Beringer.Zsolt

Eltolásészlelés

Ha egy adott, eddig jóvá nem hagyott felhasználó olyan változáscsomagot küld be (vagy sok olyan változáscsomagot rövid idő alatt) amiben sokszor előfordul, hogy vonalak és síkidobok kerülnek eltolásra kb. hasonló ofszettel, akkor felmerülhet a gyanú, hogy ofszet nélküli légifelvételt használt az illető.

Amennyiben tapasztalt szerkesztő (hasonló korábbi változáscsomagjainak átnézése alapján), akkor pedig felmerül, hogy kijavította a rossz eltolásokat, így a jövőben ez az észlelés az ő változásait figyelmen kívül hagyhatja.

Mentor: bkil @ OSM

Partimap

Frissítés: nem úgy tűnik, hogy karbantartják az adatbázist, így törölhető.

Erre lehetne egy ütemezett szinkronizálót fejleszteni ami térképjegyzeteket nyit illetve zár be az ő bejelentőiket lekövetve. 

Térképre tesszük a bezárásokat!

A feldolgozott (megoldott vagy figyelmen kívül hagyott) bejegyzések azonosítóit egy txt vagy CSV fájlba kell majd gyűjteni. A HTML fájlban találhatóak a GeoJSON markerek. Van a rekordoknak id mezője, bár én a biztonság kedvéért azért a koordinátából és/vagy a name, leírás és link alapján is szintetizálnék egyet. Itt egy példa: 


 {
   "type": "Feature",
   "geometry": {
     "type": "Point",
     "coordinates": [
       2273997.4885345586,
       5809607.989293486,
       0
     ]
   },
   "properties": {
     "name": "Kiszombor, bankfiók",
     "description": "leírás: Bezár a kiszombori Takarékbank <br>link: https://mcsipos.hu/bezar-a-kiszombori-takarekbank-is-nem-lesz-atm-sem/",
     "styleUrl": "https://www.partimap.eu/admin/project/55/sheet/1#icon-503-3F5BA9",
     "leírás": "Bezár a kiszombori Takarékbank",
     "link": "https://mcsipos.hu/bezar-a-kiszombori-takarekbank-is-nem-lesz-atm-sem/",
     "color": "#3f5ba9",
     "width": 4,
     "dash": "0",
     "visitorFeature": false
   },
   "id": 6262463075
 }

A már meglévő Onosm.org szolgáltatás hasonlóan működik: a felhasználó kitölt a weblapjukon egy űrlapot, mire a robot felvesz rá egy térképjegyzetet: 

onosm.org submitted note from a business:
name: Molnár Rezidencia
phone: 06205578923
website:
twitter:
facebook:
email: bence.molnar0220@gmail.com
hours: Monday-Sunday 0-24
category: Hotels
address: Diószegi út 170, Debrecen, Hungary

Mentor: bkil @ OSM

RTL energiaválság

Frissítés: nem úgy tűnik, hogy karbantartják az adatbázist, így törölhető.

Koncepciót lásd a #Partimap alatt.

Térkép:

CSV adatok (latitude, longitude, title, hogyan):

Mentor: bkil @ OSM

Települések közötti távolságok meghatározása

A mező- és erdőgazdasági földek forgalmáról szóló 2013. évi CXXII. törvény (Földforgalmi törvény) 18. § (1) bekezdés e) pontja említi meg az olyan földművest, akinek az életvitelszerű lakáshasználata helye vagy a mezőgazdasági üzemközpontja legalább 3 éve olyan településen van, amelynek közigazgatási határa az adás-vétel tárgyát képező föld fekvése szerinti település közigazgatási határától közúton vagy közforgalom elől el nem zárt magánúton legfeljebb 20 km távolságra van.

A cél egy olyan eszköz fejlesztése lenne, amely

  • bármely magyarországi település kiválasztása esetén kilistázza azokat a településeket távolságokkal együtt, amelyek megfelelnek a fenti 20 km-es szabálynak
  • megjeleníti térképen a két település közigazgatási határa közötti legrövidebb utat a fenti paraméterek figyelembe vételével
  • képes kezelni pozitív listákat (olyan utak azonosítóit megadva, amelyek mindenképp figyelembe legyenek véve) és negatív listákat (olyan utak azonosítóit megadva, amelyek semmiképp se legyenek figyelembe véve) a távolság számításakor
  • CLI és GUI (webes) felhasználói felülettel is rendelkezik (a térképes megjelenítést csak webes felületen kell megjeleníteni)
  • opcionálisan rendelkezik a mezőgazdasági igazgatási szerv jóváhagyásával és minősítésével

Mentor: urbalazs

Vasúti újratervezés

OSM adatokból lehetne olyan eszközt készíteni ami vasúti járművek útvonaltervezését végzi a valós idejű pozíciókat és késéseket is figyelembe véve. Baleseteknél gyakran konkrétan publikálják (vagy leolvasható a pozíciókból), hogy mely szakaszokon használják melyik vágányokat a vonatok, hol térnek át és vissza, melyik állomásokon vesztegelnek prioritás szerint. Ismert szakaszonként vagy váltóhibáknál a sebességkorlát, járművek gyorsulása, lassulása, felszállási idők. Időnként közzéteszik, hogy mely vonatok maradnak ki vagy mely további állomásokon is állnak meg, mely új végállomások lettek kialakítva. Ezek alapján precízebben újratervezhető az, hogy mikor érkeznek meg a kiindulási- és célállomásunkra.

A vonatkozó vasúti tájékoztatás órákkal el van csúszva, emiatt használhatatlan, a vasúti hálózat proaktív ütemezésére pedig nincs kapacitásuk, emiatt reaktívan határozzák meg kézzel lokális információból, hogy mely állomásokon ki mikor menjen tovább, tehát ennek alapján sem tudnak tervezni a saját meglévő rendszereik. Annak kevés haszna van, ha 5 percenként 5 perccel növelik a kijelzőkön a késés idejét, ha a valóság szerint 45 perc múlva is elég volna kimenni az állomásra és ez már 60 perccel előtte is meghatározható.

Mentor: bkil @ OSM

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Hungary/Szerszámzat&oldid=2718289"