Diskusia s redaktorom:DB111

Modul:Súradnice

Hi. Ad [1]: please, do provide meaningful edit summaries explaining the purpose of an edit, even if it's just a maintenance action. Regards --Teslaton (diskusia) 12:40, 21. október 2019 (UTC)

Hi Teslaton, you're are completely right, I saved by accident :-( I will provide the summary soon, sorry! It's about enabling GeoData for Slovakian Wikipedia. Thank you, --DB111 (diskusia) 13:03, 21. október 2019 (UTC)

One side-effect of that edit is, that all dependant pages are now being categorized into cat. Kategória:Stránky s nesprávnými značkami zeměpisných souřadnic (eq. of en:Category:Pages with malformed coordinate tags), even though both coords itself and template/module calls are valid. When I open module revision before today's changes [2] and render some affected page using that one, it renders without that tracking cat. Shoud I revert your edit, or was it just a step forward to something more and you will finish that? --Teslaton (diskusia) 14:33, 21. október 2019 (UTC)

Thank you for that advice, so I reverted for now. --DB111 (diskusia) 14:58, 21. október 2019 (UTC)

I don't know how to trace/debug Lua modules efficiently in this MW integration implementation (maybe there are tools, maybe just dumping into resulting markup), but there may be problem with that last t parameter, you are passing to frame:callParserFunction(). In case that RE test

local r,s,t=string.match (coordinateSpec["param"],'(.*)_(E?W?)_(.*)')

does not match anything, the subsequent

globalFrame:callParserFunction('#coordinates', {coordinateSpec["dec-lat"], coordinateSpec["dec-long"], 'primary', t})

will throw an error, leading to that categorization. Without that last param (i.e. just {{#coordinates:N|N|primary}} form), the call seems to work. --Teslaton (diskusia) 16:01, 21. október 2019 (UTC)

Problem may be, that our coord module implementation is quite aging and unmaintained - it's enwiki clone from 2013 and that geodata part was added in 2014 [3] and not updated much since then. --Teslaton (diskusia) 16:09, 21. október 2019 (UTC)

No, t seems not to be an (only) problem. Categorization takes place even in case of this minimal module contents:

coordinates = {};

function coordinates.coord(frame)
    frame:callParserFunction('#coordinates', {'49', '19', 'primary'})
    return 'test'
end

return coordinates

Is 'primary' a valid value for 3rd param? --Teslaton (diskusia) 16:19, 21. október 2019 (UTC)

Thank you for your kind research, the parameter is valid, two further ideas:

#frame:callParserFunction('#coordinates', {'primary', 49', '19'}) – primary at first position?

#frame:callParserFunction('#coordinates', {'primary, 49, 19}) – please try numbers not as string --DB111 (diskusia) 16:30, 21. október 2019 (UTC)

Whether numbers are passed as int/float/string does not seem to make any difference. The position of 'primary' value either. The call frame:callParserFunction('#coordinates', {49, 19}) (i.e. without the 'primary' value) seems to work without an error. So does a direct {{#coordinates:49|19|primary}} call inside the page markup (which should be a markup equivalent of that indirect call throwing an error). --Teslaton (diskusia) 16:45, 21. október 2019 (UTC)

Maybe you can see an useful output of the callParserFunction, e.g. "print(frame:callParserFunction('#coordinates', {'49', '19', 'primary'}))". --DB111 (diskusia) 16:37, 21. október 2019 (UTC)

You mean in the debuging console below the module editor? Yes, there is print() global defined and I can dump using mw.log() from the module source. But I really don't know, how to pass a correct context (a frame like when evaluated during page rendering). Without that, the frame:callParserFunction() call will obviously fail... --Teslaton (diskusia) 16:55, 21. október 2019 (UTC)

Well, it seems to be testable from the console via call like this:

p.coord(mw.getCurrentFrame())

But when called, the call:

frame:callParserFunction('#coordinates', {'49', '19', 'primary'})

(from the minimal module snippet above) does not dump any error (as it does in case of too large number for some coordinate, for example), it just adds that tracking category, when evaluated inside call from a page. Maybe it really is a bug somewhere (like [4] was) and we should report it. --Teslaton (diskusia) 18:01, 21. október 2019 (UTC)

I think I got the problem: "na stránce není možné mít více než jeden hlavní štítek". The code is evaluated twice in the page, that is the reason why "primary" fails.... --DB111 (diskusia) 18:06, 21. október 2019 (UTC)

You mean two calls from the {{Geobox}} tpl.? Yes, that may be a problem. Even though, just one of that call should have display=title set (which should correctly lead to 'primary' being passed to #coordinates, no?). --Teslaton (diskusia) 18:16, 21. október 2019 (UTC)

Ok, I finally found the „Protokoly Lua“ expandable section in page profiling data on the bottom... :) That is the place, where mw.log() dumps together with error messages go during a page rendering. --Teslaton (diskusia) 18:22, 21. október 2019 (UTC)

Yes, you have two identical coordinate outputs e.g. for towns: One above the infobox and one inside ("primary" does in this terms by the way mean "the main coordinate", not any support for multiple call the "#coordinates", what ist the failure here(If you have further, different, secondary coordinates in the page, you should call "#coordinates" for them without "primary"). So the coordinate module code gets double-called in the page at the moment. 1. Don't have the coordinates painted twice in the page? 2. Find a better place that's always called once per page for the "#coordinates" call? 3. Some kind of check if already called? 4. ... ??? --DB111 (diskusia) 18:27, 21. október 2019 (UTC)

Sound's good: Only with "display=title" make the call.... --DB111 (diskusia) 18:30, 21. október 2019 (UTC)

So good to know that the code snippet works per se, so maybe you/we'll find a good place to call (the change of 2014 was ineffective, no call took place). Would really be nice to have for nearby-Features, most Wikipedias have it enabled: https://tools.wmflabs.org/wikimap/?lat=48.15&lon=17.15&commons=false&lang=sk --DB111 (diskusia) 18:34, 21. október 2019 (UTC)

Yes, I was just working on that conditional output [5], hope it will work without further side-effects. --Teslaton (diskusia) 18:40, 21. október 2019 (UTC)

Great! :-) --DB111 (diskusia) 18:49, 21. október 2019 (UTC)

But this way, no {{#coordinates}} is called on non-title coord tpl. calls (so these secondary coordinates will not get populated into geo index). Maybe non-primary {{#coordinates}} call should be emitted instead (for display=inline only calls). --Teslaton (diskusia) 18:46, 21. október 2019 (UTC)

Of course, but not the same coordinate value once as primary and once as non-primary (I thought of the infoxbox with two equal values). True inline coordinates should be written with "primary" omitted, exactly.--DB111 (diskusia) 18:49, 21. október 2019 (UTC)

Uniqueness of coordinates (primary vs. non-primary) is impossible to check from the module point of view, it can just register that inline call as non-primary (will the duplicities cause a problem from the index/tools point of view?) To get uniqueness, IB templates modifications will be required (a flag, indicating not to emit any #coordinates call, at least). --Teslaton (diskusia) 18:59, 21. október 2019 (UTC)

As long as you call "primary" only once per page (for the "title" coordinate), all is fine I think. Rest is not up to you, people will insert crazy coordinates in articles, so don't care. A "name" attribut is useful for non-primary coordinates, to distinguish them [6] (if you pass this attribut anyway for the GeoHack parameters, it will be used automically). Thank you very much for your today's support! --DB111 (diskusia) 19:12, 21. október 2019 (UTC)

We thank for your effort on skwiki! Seems that Special:Nearby finally shows some hits... --Teslaton (diskusia) 19:21, 21. október 2019 (UTC)

I'm not a LUA expert either. I was totally shocked when I found out that every little or big Wikipedia has to do all the template / module work itself with hardly enough article authors. So I helped hsb./dsb.wikipedia.org (our two little Sorbian language Wikipedias in Germany) to enable GeoData. By the way: All the parameters were totally correctly written to the Database during the change (Lat/Lon/Primary/Type/Region/...). So it's not impossible that others even don't check #Errors und would get the same error else. I will have a further look on it, you're help is also really appreciated and useful! And sorry for this surprise, I thought it would run smoother. --DB111 (diskusia) 17:17, 21. október 2019 (UTC)

Interesting that nearby spatial queries are viable and quite fast even via SQL [7] on small wiki like skwiki – despite the seq scan required on geo_tags table, as there is no spatial or any other index on gt_lat/gt_lon columns; GeoData is configured to use Elastic on WMF instances, obviously. Certainly not suitable for massive loads (like those, GeoData API should be able to withstand), but for ocasional manual Quarry execution it seems fine... --Teslaton (diskusia) 14:31, 23. október 2019 (UTC)

Impressive! German Wikipedia has 1546873 rows in table, Commons even 13176464. Yeah, the [GeoSearch API] uses obviously [Elastic], so the spatial query performance of this API is good. But it's some kind of crutch: You write the data (somewhere in the GUI part of location/coordinates template/module) per parser function to a SQL database, this fills Elastic again, ... So maybe time to move to Wikidata or so :-) --DB111 (diskusia) 15:37, 23. október 2019 (UTC)