Wikipédia:Zenei műhely/Kottamunkacsoport/Dalok hely szerinti térképes keresője

Dalok hely szerinti térképes keresője

Szia! Tudsz az infoboxok alapján olyan listát generálni a kottás lapokból, mely a gyűjtés helye szerint listázza őket?

Itt a lista, melyet kézzel elég hosszadalmas feltölteni, talán géppen rá lehetne segíteni: Szerkesztő:Cvbncv/Kottaportál_(terv)/Népdalgyűjtési_helyszínek. Ezt szeretném bővíteni.

Természetesen a térképeket kézzel kell a településpöttyökkel ellátni, bottal csak az adott településhez tartozó dalok listáját kellene kikeresni. Így:

===Település1===
* [[Dal1]]
* [[Dal2]]

===Település2===
* [[Dal1]]
* [[Dal2]]

...

Szóval szerinted megoldható? Kb mennyi munka? Ha legenerálnád nekem, és betennéd valahová, mondjuk egy allapomra (mondjuk ide), az nagy segítség lenne, onnan akár kézzel is átmásolgatnám.

Cvbncv Vince^{(érveljünk)} 2016. október 28., 15:32 (CEST)[válasz]

SQL-szerű lekérdező!

Támadt egy másik ötletem! Arra gondoltam, hogy a lekérdező szkriptjeiddel össze lehetne állítani olyan adattáblaszerű fájlokat, melyekből aztán le lehet kérdezni listákat. Kicsit úgy, ahogy azt például SQL-ben tenné az ember.

Példaképpen írtam egy tesztet a próbalapomon.

Így nézne ki egy adatfájl, ilyet kellene generálni automatikusan:

Szerkesztő:Cvbncv/próbalap/dbtest/dbfile

Így nézne ki a lekérdezés:

Szerkesztő:Cvbncv/próbalap/dbtest

Az oszlopegyezés szerinti keresést ez a fájl valósítja meg:

Szerkesztő:Cvbncv/próbalap/dbtest/dbwherecol

A lekérdezést ilyen szintaxissal kell majd meghívni:

{{/<adatfájl neve>
|függvény=dbwherecol
|feltétel = <mire illeszkedjenek a kiválasztandó sorok keresőoszlopai>
|ebben_keress = <mi legyen a keresőoszlop a kiválasztásnál>
|ezt_listázd = <mely oszlopot adja vissza értékként az illeszkedő sorokból>
}}

Azaz arról szólna a dolog, hogy lekérdezzük az adott településen gyűjtott népdalokat, ami SQL terminológiával valahogy úgy hangzana, ha lenne ilyen itt a wikin, hogy SELECT dalnév WHERE település="Horgos". Sajnos a wikiben csak névtelen adatoszlopokkal lehet ezt könnyen megcsinálni, azaz a lekérdezés most effektíve úgy működik, hogy SELECT (0.oszlop) WHERE (1. oszlop)="Horgos".

Persze ez még csak teszt, például jelenleg max négysoros adattábla lehetséges, haha. Továbbá nem tudom, hogy mi a limitáció a wikipédia sablonoknál a névtelen paraméterek maximális számára, az is limitálja jelenleg a maximális adattábla-méretet.

Ha szerinted az adattáblafájl legenerálható ilyen formában, akkor utána megírnám rendesen a lekérdező sablont, és rögtön ki is próbálhatnánk a Kottaportálban.

Cvbncv Vince^{(érveljünk)} 2016. október 28., 18:08 (CEST)[válasz]

Szerintem érdemes Luát használni – itt akár nevesített oszlopok is lehetségesek, bár az jóval hosszabbá teszi a kódot –, a településnevek helyett pedig a Wikidata-azonosítójukat (ha ez a bottal megoldható): egyrészt így több azonos nevű település nem zavar be, másrészt további információk (pl. koordináták) is lekérdezhetők, amik automatikusan frissülnek, és nem jön létre redundancia egy település több rekordja által. – Tacsipacsi ^vita 2016. október 28., 18:43 (CEST)[válasz]

Ha jól értem, az összes Dal infobox tartalmát kellene összegyűjteni egy fájlba (esetleg programmal kezelhetőbb formában). A robotnak ezt az egy fáljt kellene frissítenie, amit talán még az adminok sem látnak , mert eldugjuk a portál névtérben. A kotta portál pedig sablonokat tartalmaz, melyek ebből a fájlból dolgoznak. Így egy-egy sablonnal kiválthatók lennének az eddigi dallistás lapok is, és más lekérdezéseket is lehetne írni sablonban. Tetszik az ötlet. (Lehet, hogy ezt írtad a múltkor is, csak nem értettem meg?)

Így senkinek nem fájna, hogy a sablon kimenete nem szerkeszthető, és nem lenne vita arról sem, hogy milyen névtér, hiszen a szócikk névtér hivatkozhatik sablonra, arra meg talán a Szent Útmutató sem tér ki, hogy a sablon hová nyúl. A felhasználó számára meg ugyanaz lenne az eredmény, csak kicsit processzor-igényesebb formában. Cserébe megszűnne a sokak szemét bántó Egyéb fejezet a listalapon. És ebből a fájlból meg lehetne csinálni a kottakeresőt is.

Amit Te írtál, az az egyetlennek szánt lua-sablon paraméterfájlja, ami a lekérdezéseket csinálná. Nem biztos, hogy ilyen univerzális sablont kell írni, mert nagyon bonyolult lesz, de az ellenkezője sem biztos. Végig kellene gondolni a kimenetek lehetséges formáit. Jóval egyszerűbb lenne nem fájlban, hanem lua-paraméterekben átadni őket. A lua-hívás úgyis wikitext sablon: az lenne a paraméterfájl. Ez technikai részletkérdés: az ötlet jó.

@Tacsipacsi: Természetes, hogy minden (vagy a?) sablon luában készül. A település szinte mindenütt egyértelmű a Dal infoboxban, bár néhány kivétel azért van, mert nem tudtam, hogy két azonos nevű településből melyik az igazi. Ha viszont a település adatait Wikidatából akarjuk lekérdezni, akkor a robotnak kell lekérdeznie minden település lapját, és kibányászni belőle a wd-azonosítót, hogy a szövegfáljba belekerüljön. Ez nem gyors, de megoldható (ugyanazzal a parszerrel, ami a Dal infoboxot bányássza ki. Remélem, minden település ugyanazt az infoboxot használja, és bennük van a wd.).

Egy apró probléma azért maradt, de ez robottal sincs megoldva. Egy dal egyszerre lehet pl. komolyzenei dal és egyházi népének, és az infoboxban csak egy műfaj van. A másik/többi a kategóriából derül ki.

Akkor fehér füst? Akár kezdhetem is írni a robotot? Vagy az adminok még beleszólhatnak? Gyimhu ^vita 2016. október 28., 20:18 (CEST)[válasz]

@Cvbncv: Persze hogy tudok település szerinti lekérdezést csinálni. Viszont ha az SQL-lekérdezőben leírtból lesz valami, akkor luából is meg lehet csinálni a lekérdező sablonnal, és az jobb megoldás, mert nincs hozzám kötve. Gyimhu ^vita 2016. október 28., 20:51 (CEST)[válasz]

A települések szócikkeiben már nem kell feldolgozni az infoboxot (ami egészen biztosan nem ugyanaz mindenhol, mivel a mai országok alapján vannak a települések infoboxai, így Pozsony szlovákot, Nagyvárad románt stb. kap), ha már megvan a cikkcím, akkor API-val meg lehet találni az azonosítót: action=wbgetentities&sites=huwiki&props=info&titles=cikkcím. (Ha szeretnéd minimalizálni a HTTP-kérések számát, akkor action=wbgetentities&sites=huwiki&props=info|sitelinks&sitefilter=huwiki&titles=cikk1|cikk2 formában lehet – az előző linkre adott válasz nem adja meg a cikk címét.) Egyébként meg arra gondoltam, hogy magát a listát is lehetne modulallapon tárolni, majd mw.loadData() függvénnyel beolvasni – így pl. nem kell az adatbázisnak minden paramétert átadnia a feldolgozást végző lapnak, hiszen az utóbbit hívjuk közvetlenül más lapokról, emellett bonyolultabb lekérdezéseket is lehet végezni. És nekem nem alap, hogy minden sablon Luában készül, én még ma is készítek wikikódos sablonokat. – Tacsipacsi ^vita 2016. október 28., 21:45 (CEST)[válasz]

@Tacsipacsi, Gyimhu: Számomra nem egyértelmű, hogy egy sablon csak Luás lehet. Főleg, hogy ahhoz nem értek, csak wikikódhoz. A fenti példáim is mind wikikódosak.

Itt tisztáznék egy dolgot (főleg a magam kedvéért, de segíthet megérteni, hogy valóban egyről beszélünk-e). A javasolt lekérdezések során az információ alapvetően háromféle megírandó kódon folyik át, négy lépésben:

A wikipédia szócikkeiből származik minden adat, amit valaki valahová kézzel beírt.
Ezt lehet parszolni, adattáblába rendezni.
Utána az adattáblából lehet lekérdezni.
Majd mindezt közreadni egy Portálban.

A kezdet tehát wiki-kódban írt szócikkek és némi információ, amit az API-n lehet lekérni. A következő lépés az adattábla kialakítása. Ezt szerintem nem lehet megírni wikikódban. Az adattábla lehet Luás, vagy wikikód. Utána jön az adattáblából való lekérdezés, melyet meg lehet valósítani wikikóddal, erre láthattatok egy példát az első írásomban. Az megint egyértelmű, hogy a 4. lépésben a portálnévtérben ismét wikikódot kell kapni.

Lehet Luá-sítani akár a wikiből való adatbázisosítást, akár az adatok tárolását, akár az abból való lekérdezést. De a felvetésem a következő: ha a lekérdezést és a tárolást meghagynánk wikikódosnak, akkor a mezei szerkesztő, mint én is, könnyebben csinálhatnánk lekérdezést. Nem függnénk olyan nagyon azoktól a szerkesztőktől, akik értenek a Luá-hoz. (Bár jobb lenne egyszerűen csak beletanulnom a Luá-ba, nem igaz...?)

Szóval a fentieket is figyelembe véve szerintetek a folyamatnak mely részeiben érdemes elrugaszkodni a wikikódtól és Luában megcsinálni? Nem biztos, hogy mindet, mert bár a wikikód körülményes, de nagyon rugalmas, és magasabb szintű (úgy értem, hogy közelebb van a felhasználói réteghez, mint egy Lua-kód). Cvbncv Vince^{(érveljünk)} 2016. október 28., 22:36 (CEST)[válasz]

@Tacsipacsi, Cvbncv: Bocs, hogy elhallgattam. Nem kezdtem kódolni. Hosszú és rögös pályafutásom alatt megtanultam, hogy amíg nincs egyetértés, nem szabad.

Nem kellene ezt a megbeszélést áttenni a kottaportálra?

Cvbncv: annyi kiegészítéssel, hogy a 2. pontot robot csinálja. 300-nál több szócikket nem lehet röptében elolvasni és parszolni. Ráadásul tudtommal lekérdezni sem lehet röptében a listát: nincs olyan API, ami egy kategória szócikkeit lekérdezi. Vagy csak én nem találtam. Tacsipacsi jobban ismeri az API-t: majd ő megmondja.

Úgy képzelem, hogy a robot egy listát állítana elő, melynek minden sora egy-egy szócikk. A sorban a Dal infobox mező lennének (mondjuk) |-lal elválasztva, előre dokumentált sorrendben. Lenne egy lua modul, ami ezt a robot-listát beolvasná egy asszociatív lua-tömbbe. Minden kottás sablon köteles lenne ezt használni. Ezzel függetlenítjuk magunkat a robotlista formátumától, viszont a luához kötjük magunkat.

Az asszociatív tömb név mezője célszerűen a Dal infobox sablon paraméterneve. Célszerűen ékezetesen, bár így egy kicsit kényelmetlenebb a lua-programozás.

Ha csak annyi a cél, hogy szűrjünk a dallista bizonyos mezőire, és valamelyik szerint rendezzünk, ezt egy lua-modul meg tudja csinálni. Egyszerűen megkapja paraméterben a mezőneveket és a rendezendő mezőét. A modul kimenete úgyis rendezhető táblázat lesz: nem hiszem, hogy érdemes több kulcsban gondolkodni, bár ez sem lehetetlen, még utólag sem.

A mezőket kiíró lua-modult wikitext sablonból kell hívni, valahogy így: {{#invoke:lua-modulnév|lua-függvény|1=magyar népdal|2=gyűjtő|3=hely|4=év|rendez=hely}}

Amúgy a lua leírása szerint a nyelv negyed óra alatt megtanulható. Én a jelek szerint gyenge programozó vagyok, úgyhogy négy órámba telt a dok. végigolvasása és az első program megírása, amiben ciklus és if is volt.

Ez még mindig csak javaslat. Ha jól végiggondoljuk a célt, töredékére csökken a kódolás és tesztelés ideje. Gyimhu ^vita 2016. október 29., 10:24 (CEST)[válasz]

@Tacsipacsi, Cvbncv: Ilyen lenne a robot által előállított fájl:

szó | Bartók | Budapest | ...
szócikk2 | Kodály, Kecskemét | ...

Így képzelem az adatszerkezetet:

gyujto   = 1
hely     = 2
ret = {}

ret["szó"] =            { "Bartók", "Budapest" }
ret['szócikk2'] =       { "Kodály", "Kecskemét" }
print("A \"szó\" szócikk adatai:", ret["szó"][gyujto],ret["szó"][hely])
-- A betöltő modul hívása után így lehet végigmenni a szócikkeken:
print("Az összes kikeresett szócikk:")
for i,t in pairs(ret)
do      print(i,ret[i][gyujto],ret[i][hely])
end

Jó így? Írjam a robotot? Gyimhu ^vita 2016. október 29., 21:38 (CEST)[válasz]

Szerintem érdemesebb lenne először a modult megírni, mellé egy mintafájllal. A bot kimenete adott (arra kell figyelni, hogy ha az adatokban | van, akkor azt kódoltan, pl. {{!}} formában kell írni, hogy ne csússzanak el az oszlopok), a modulnál a bemenet feldolgozása nem egyértelmű, én mondjuk valahogy így tudnám elképzelni:

local oszlopok = {
	['gyűjtő'] = 1,
	['hely'] = 2,
	...
}

local adat = beolvas() -- itt olvassa be az allapról az adatokat egy asszociatív tömbbe

local function szures(rekord, felt, ki)
	for n, v in pairs(felt) do
		if rekord[n] ~= v then
			return nil
		end
	end
	local kimenet
	for i, v in ipairs(ki) do
		kimenet[i] = rekord[mw.text.trim(v)] -- a kimenet lehessen „gyűjtő, hely” is, ne csak „gyűjtő,hely”
	end
	return kimenet
end

function p.main(frame)
	local args = getArgs(frame) -- [[Modul:Arguments]].getArgs
	local felt = {}
	for n, _ in pairs(oszlopok) do
		if args[n] then
			felt[n] = args[n]
		end
	end
	local oszlopok_ki = mw.text.split(args.kimenet, ',', true)
	local kimenet = {}
	for n, v in pairs(adat) do
		local szurt = szures(v, felt, oszlopok_ki)
		if szurt then
			kimenet[n] = szurt
		end
	end
	return formaz(kimenet) -- táblázatforma stb.
end

Ez a következőképpen hívható meg:

{{#invoke:<modulnév>|main
|gyűjtő = Kodály
|hely = Q1017610 <!-- Horgos -->
|kimenet = gyűjtő, hely
}}

(a feltételoszlopok esetén a paraméternév az oszlopnév, a paraméterérték pedig a feltétel; a (cím mellett) kért oszlopok a kimenet paraméterbe írandók vesszővel elválasztott listaként). Egyébként én API alatt a HTTP API-t értem, amit bottal lehet elérni – az természetesen le tudja kérdezni egy kategória szócikkeit, ellentétben a Scribunto által kínált eszközökkel, amik valóban nem. – Tacsipacsi ^vita 2016. október 30., 14:04 (CET)[válasz]

Robot első változat

A kimenete itt van: Modul:Kották metaadatai. Ódzkodom a kód adatként kezelésétől (vagyis hogy program programkódot állítson elő), most mégis belementem. Azt hiszem, nincs benne biztonsági lyuk. Már akkor, ha minden úgy működik, ahogy neki kell...

Egy egyszerű lekérdezés eredménye. Gyimhu ^vita 2016. október 31., 14:32 (CET)[válasz]

Szia! Ha jól értem, akkor ez lenne kimentve, időnként robottal frissítve, és ebből a kimentettből lehetne modullal lekérdezni. Az asszociatív tömböd kulcsa most a szócikk címe, melynek mivel eleve egyedinek kell lennie, jó választás elsődleges kulcsnak. De talán adatmezőként is érdemes lenne feltüntetni. Csak egy ötlet - Te értesz a Luához, döntsd el, hogy kell-e.

Például Hogyan működne mondjuk az, hogy település szerint kérdezek le? Gondolom valami ilyesmi szintaxissal:

{{#invoke:<modulnév>|<lekérdező függvény>
|hely = Q1017610 <!-- Horgos -->
|kimenet = cím
}}

Helyesen gondolom? Javíts ki kérlek.

Továbbá az jutott eszembe, hogy a kigyűjtés pillanatában a legegyszerűbb a listát formázni (azaz könnyebb, mint utólag), így esetleg a lekérdezéskor meg lehetne adni, milyen formátumban kérem a listát. Legyenek-e bellinkek a címeken, legyen-e pontokba szedve, legyen-e vesszővel tagolva stb. Mondjuk akár egy elválasztó karakter megadhatósága elég lenne, mert akkor is tudnék kistát csinálni úgy, hogy "\n * "-ra választom az elválasztót. Mit gondolsz?

Cvbncv Vince^{(érveljünk)} 2016. november 2., 10:34 (CET)[válasz]

@Cvbncv, Tacsipacsi: Amint látjátok, beletettem a paraméterek közé a település Wikidata-kódját. Nem kézzel.

Cvbncv: a robot az asszociatív tömböt frissíti majd. Ez egy lua adatmodul: nincs benne programkód. Az adatok eléréséhez kell egy kódot tartalmazó lua modul. Egy egyszerű példa: Modul:Kották metaadatainak tesztje, aminek a kimenete itt van feljebb, és automatikusan frissül az adatmodul frissítésével.

A tömb adatait csak a szócikk címét tudva lehet elérni. Pont ez az asszociatív tömb lényege. Ha nem tudod a szócikk címét, végig tudsz menni a tömb elemein egyenként. Ezt fogom csinálni, amikor pl. az egyházi népénekeket listázó programot írom. Egy ciklussal végigmegyek a tömb elemein, és a belső asszociatív tömbből – immár ciklus nélkül – hozzáférek a Műfaj mezőhöz.

A tömb kulcsa ugyanolyan adat, mint a többi: felesleges még egyszer tárolni. Amúgy az utolsó 25 aktív évemben én terveztem az adatszerkezetet, amire az alkalmazásokat írtuk, úgyhogy nem akkora csoda, hogy jó az index.

Minden lekérdezéshez külön lua-programot kell írni, hacsak nem tudod paraméterben megadni, amit szeretnél. Lua-hívásnak meg tudsz adni paramétereket sablonból. Elvileg a kimenethez is hozzáférsz sablonból, de a formázás sokkal egyszerűbb luában.

A cél tehát a lekérdezések tipizálása lenne, hogy ugyanazt a lua-modult különbözőképpen paraméterezve a lekérdezések többségét meg lehessen oldani. Pl. lehet egy lua-függvényt írni, ami paraméterként megkapja a települést, és visszaadja a koordinátáit (miután kiolvasta a robot által feltöltött asszociatív tömbből az azonosítót, és annak alapján lekérdezte Wikidatából). Egyébként ha csak a koordináta kell, semmibe nem kerül kicserélni az azonosítót a koordinátára a robot kimenetében. Így gyorsabb lenne a lekérdezés.

Én most a kottás lapok műfajok szerinti listáit akarom először megírni a navbox számára. Remélem, HuFi abba már nem köt bele, és végre nyugvópontra jut az ügy. Utána a dallamkereső jön. Még nem tudom, hogy a robothoz nyúljak-e hozzá, vagy luában számoljam ki pl. a soronkénti ambitusból a teljes műét.

Persze még a robot sincs kész: ha lefuttatom a kb. 300 kottára, biztos lesz olyan adat, amit nem bír ki. De ezt már tesztelésnek hívják. Gyimhu ^vita 2016. november 2., 22:22 (CET)[válasz]

A robot működik az összes kottára. A tesztlistát áttettem másik lapra, mert jó hosszú, viszont a lekérdezés meglepően gyors.

Két hiba volt vele: az egyik az aposztróf a szócikk címében (ettől a lua megőrült), a másik az új sor az infobox érték részében. Ettől meg az én scriptem őrült meg.

Akkor most nagy levegő, és a komolyzenei lapok listája luában. majd a dal navboxban. És reménykedünk, hogy ebbe végre HuFi nem szól bele. Gyimhu ^vita 2016. november 3., 18:41 (CET)[válasz]

@Cvbncv, Tacsipacsi: Lassanként frissítem a Modul:Kották metaadatai lapot. Nem válaszoltatok: nem lenne jobb a település koordinátáját kiszedni Wikidatából, és csak azt tenni bele Helydata helyett? Kell onnan más is? A Wikidata hívása drága művelet, lehet, hogy nem fog lemenni 200-szor egy szócikkben. A frissítés előtt megcsinálnám. Ugyancsak beleteszem a lap utolsó módosításának dátumát.

A Modul:Dallisták szerzővel ismét frissült. Oszloplistát lehet megadni neki a hívó sablonban. Aztán hasonló módon jön a szűrés és a rendezés.

Cvbncv-től korábban azt kérdeztem, van-e ötlete, hogyan illessze a táblázatot a kottaportálba. (Célszerű a táblázatos forma a rendezés miatt, de elvileg nem muszáj.) Gyimhu ^vita 2016. november 6., 20:39 (CET)[válasz]

Szia Gyimhu! Ne haragudj, mostanában nem mindig érek rá sajnos, ezért válaszolok lassan. Tetszenek a fejlemények, amennyire fel tudtam fogni.

A kérdésedre: ha a térképes népdalkeresővel kapcsolatban kérdezed, akkor kétféle lekérdezés kell hozzá:

a térkép számára egyrészt kell egy olyan lekérdezés, ami a népdalcikkek infoboxaiban megemlített településekről csak az alábbi három adatot tartalmazza: településnév, lat, lng. Ebből lehet elkészíteni a térképre rakott pöttyöket.
Másrészt egy másik lekérdezés tudja kitölteni a települések szerint szakaszokba gyűjtött, pontokba szedett dallistát. A formátumtól, amit kézzel itt csináltam (nézd meg kérlek a forráskódját), ettől persze el lehet térni. Például Te szerintem egy táblázatos megjelenítést preferálsz, ha jól gondolom. Végig kell gondolni, hogy hogy lenne a legjobb. Én hajlom az egyszerűségre, hogy pontokban legyenek csak felsorolva, és a többi dal-adat meg szerepeljen más ilyen keresőkben, de itt csak a cím.

Szóval létezik olyan, hogy lekérdezem az összes különböző települést a népdalokról, majd egy másik lekérdezésben kigyűjtöm azok lat-lng koordinátáit? Mit gondolsz, működhet? Cvbncv Vince^{(érveljünk)} 2016. november 6., 20:57 (CET)[válasz]

Szia! Először is bevallottad , hogy nemcsak a település koordinátájára van szükséged, hanem az országra is. Ha az nem Magyarország, akkor Kárpát-medence.

A kérdésedre a válasz: igen, de nem.

A sablon makróként működik: a wiki motorja kicseréli a sablonhívást a sablon által visszaadott szöveggel. Gondolom, ez nem drámai újdonság.

Lehet olyan lekérdezést írni, ami visszaadja a települések listáját. De milyen formában szeretnéd? Mondjuk a sablon visszadja a gyűjtési települések listáját, az egyszerűség kedvéért: Alsok Horgos formában. Ezt még átalakíthatod a hívó sablonban, de ehhez ciklust kell írni, és az nagyon nem egyszerű. Hogy lesz ebből ilyen?

===Alsok (Csurgó)===
* [[A juhásznak jól van dolga]]
===Horgos===
* [[A horgosi csárda]]
* [[A szegedi halastó]]

(Amúgy Horgos Szerbiában van, de ez most mindegy.) Ráadásul a népdalokhoz kell egy belső ciklus is a népdalok kiírására. Vagy más algoritmussal, de akkor meg rendezni kell.

Szóval: a fenti listát célszerű luában megírni úgy, ahogy használni akarod. Ha két helyen akarod használni más formában, akkor kétféleképpen kell megírni a formázást (hogy egy függvényben forma paraméterrel, vagy kettőben, ez részletkérdés, mindkettőt lehet). Luában minden kimenetet meg lehet csinálni, amihez van adat (és Lua API az eléréséhez ).

A lua hívás is sablon: természetesen tehetsz két sablonhívást egy lapra.

Egy technikai kérdés, amire nem tudok választ kicsiholni Belőled. Azt hiszem, hívom a Szent Inkvizíciót. A robot által feltöltött adatokban a település Wikidata-kódja van. Ehhez a (lua vagy sem) sablonnak el kell mennie a Wikidatába, és lekérdezni az országot és a koordinátát. Ez viszont „drága” művelet, túl sokat nem enged a wikimotor, nehogy túlterhelje a szervert. Ezért hajtogatom mániákusan, hogy a Wikidata-kódból a robot kérdezze le a koordinátát és az országot, mert neki van ideje. Most olyan 3–4 perc alatt fut le nálam, akkor majd lesz 10 perc. Teljesen mindegy. Gyimhu ^vita 2016. november 7., 10:41 (CET)[válasz]

Mielőtt rám hívod az inkvizíciót, gyorsan válaszolok, nehogy puha párnákkal szurkáljanak. (Lásd: "Nobody expects the Spanish Inquisition!" by Monty Python :) ) Kérdésedre: Úgy gondolom, hogy szerintem is jó lenne inkább a koordinátákat, országot is lekérdezni, hogy portál-oldalletöltésekben ne legyen wikidata-hívás. Más ötlet: a kottákkal kapcsolatos települések adatait egy a dalokéhoz hasonló "adatbázisba" luával ki lehet gyűjteni, ahonnan már ismét nem költséges a hívás futásidőben. Bár hozzátenném, hogy még mindig nem teljesen értem a luás részeket (és sajnos időhiányomban nem is nagyon tudom beleásni magam sajnos.). Szóval a megvalósításban jobban kell támaszkodnom a Te ötleteidre, mind gondolnád... Cvbncv Vince^{(érveljünk)} 2016. november 7., 11:50 (CET)[válasz]

Én erőltettem a Wikidatát, mert az kisebb redundanciát okoz a tárolásban (név, koordináták, ország hármasok sokszor szerepelnek, ezek helyett lenne jó az egyetlen Wikidata-azonosító). Eddig abban a hitben éltem valamiért, hogy ez nem költséges, de most eszembe jutott, hogy mégis: egyedi Wikidata-elemből – ha jól látom a HTML-forrásban a wgPageParseReport változót – legfeljebb 400 engedélyezett. Nem tudom, mennyivel várható a jelenlegi 116 egyedi település túllépése, de egyelőre kezelhetőnek tűnik. Ha várhatóan ennél jóval több lesz, akkor esetleg érdemes egy külön táblát készíteni a településekről (kulcsai lehetnek a WD-azonosítók). Egyébként a térképet érdemes lehet a Kartographer kiterjesztéssel csinálni – a Lua tud egy tömbből JSON-t készíteni (mw.text.jsonEncode()), ami ennek a bemeneti formátuma. – Tacsipacsi ^vita 2016. november 7., 18:48 (CET)[válasz]

@Tacsipacsi: Én nem néztem utána, de józan paraszti ésszel kitalálható. Költségesek azok a műveletek, amelyek miatt ki kell nézni a lapról fájlrendszerbe, adatbázisba vagy pláne másik szerverre. A redundanciát gyorsan elfelejthetjük: a Wikipédiának van 400 000 szócikke. Ehhez képest 200–300 szócikk 30–40 bájtja nem tétel. (És ha már a biteknél tartunk: az adatbázisok 4–8k vagy még nagyobb blokkokban tárolják az adatokat. Kicsi az esélye, hogy pont a 30–40 bájt miatt kell újabb blokk.)

A redundancia azért „káros”, mert ha a WD-n változik az adat, mi egy darabig még a rossz adatottal dolgozunk. Ennek igen kicsi az esélye: elég nagy földcsuszamlás kell hozzá, hogy egy település koordinátákban mérhetően arrébb menjen

, és az sem valószínű, hogy egy adat annyira rossz, hogy a mi rossz felbontású térképünkön látszik a különbség.

A WD-azonosítót teljesen ki akarom hagyni a robot adatai közül. Bármi módon használjuk, az drága. Elsődleges kulcsként ott a településnév (pontosabban: az egyértelműsítés utáni link).

@Cvbncv: A népdaloknál öt régiót szokás megkülönböztetni: északi (Felvidék), Alföld, Dunántól, Erdély és Moldva. Sajnos ezekre nincs adat a Dal infoboxban. Lehet, hogy erre mégis jól jön a külön településtábla? 100 körüli településhez be tudjuk írni a régiót. Gyimhu ^vita 2016. november 7., 20:36 (CET)[válasz]

Természetesen ha „a” tömbben tároljuk a települések nevét, koordinátáját stb., akkor nincs szükség Wikidata-azonosítóra, arra az esetre javasoltam, ha külön táblába kerülnek a települések adatai (immár a régióval). – Tacsipacsi ^vita 2016. november 7., 21:10 (CET)[válasz]

@Cvbncv: Szia, Vince! Akkor megint Nálad a labda. Akarsz öt térképet (esetleg később), vagy maradjunk a kettőnél? Ezen múlik a folytatás.

@Tacsipacsi: Nekem most már nem is olyan természetes. Ha egyértelműsítik valamelyik települést, gond lesz. Persze ezt lehet kézzel kezelni. Gyimhu ^vita 2016. november 7., 21:52 (CET)[válasz]

Tartalom a kottaportál nyitó lapjára

@Cvbncv, Tacsipacsi: Ez a riport is lehetne a nyitó lapon mások mellett:

Műfaj	Szám
magyar egyházi népének	93
magyar népdal	262
magyar népies dal	39
egyéb magyar népies dal	23
egyházi népének	2
magyar hangszeres népzene	1
mozgalmi dal	15
német eredetű dal	2
népdal	32
komolyzenei dal	29
könnyűzenei dal	3
külföldi népies dal	1
magyar komolyzenei dal	16
Összesen	518

~~(Van benne két adathiba, amit a szócikkben már javítottam, csak nem futtattam újra a riportot.)~~ Innen végig lehet menni az összes kottán.

A jobb oldali számokon link lenn a dallistára. Ezek már megvannak: Szerkesztő:Gyimhu/Lejátszható kották, csak külön lapra kéne őket tenni, és a népdalokat átnézni, hátha van még adathiba. Ugyanezekre a lapokra szerenék linkelni a navboxból is. Akkor most várunk egy hónapot a Wikitanácsra, hogy lehet-e egyáltalán?

Más. A településtáblát mégiscsak megcsinálom, hogy ne kelljen most dönteni az öt népdalrégióról. Gyimhu ^vita 2016. november 14., 20:30 (CET)[válasz]

@Cvbncv, Tacsipacsi: A településlista kész: Modul:Népdalgyűjtési helyszínek. Úgy képzelem, hogy mostantól kézzel javítjuk. A Modul:Kották metaadatai-ból a következő frissítéskor kiveszem a Wikidata-kódot.

Országstatisztika:

HU 52
RO 26
SK 25
nincs megadva 24
UA 3
RS 1

A 24 település nem volt benne Wikidatában.

A teszteléskor észrevettem, hogy Szeged koordinátái nem egyeznek a magyar lapon és a Wikidatában. Nem nagy a különbség: olyan 200 méter, de az okát nem értem. A szócikkbe nincs beleírva a koordináta: fogalmam sincs, hogy a Magyar település infobox honnan veszi. Ha netán kerekítési hiba, akkor meg nem volna szabad másodperceket és századfokokat is kiírni. Gyimhu ^vita 2016. november 16., 21:04 (CET)[válasz]