The biggest issue with using Lua/Server side scripting with large lists is that every single data item used on a wiki page requires a separate SQL query (or even multiple ones), due to how mediawiki + wikibase is implemented. On the other hand, relying on TagInfo has some shortcomings - TagInfo does not (yet) understand data items, relying on its own wiki page parser, it is very fixed in a way it can present information, and every wiki page view also uses makes 1 or more external call to taginfo (higher chance of something going down).
There is a popular middle ground that can solve it for us -- very flexible, highly performant, uses a common data source (data items), and relies on a single system. Essentially it is a bot-updated wiki markup: * an editor adds a special template at the top of a wiki page, where they specify a SPARQL query for the data they want - i.e. "find all label+description+image of data items, whose type is a 'tag' and whose key is 'denomination'". A bot would run that query on occasion (e.g. once a day), and append query results to that same page after the template. Thus, the result becomes a regular wiki markup, without any significant server costs. See https://www.wikidata.org/wiki/Template:Wikidata_list The PROs: * The bot can run at any moment, by anyone, to update the data * In the worst case of a bot completely dying, wiki markup could be edited by hand until the bot is fixed * very flexible - a complex query could get any data needed for the output, and the output is templated to show in any kind of a list/table format. CONs: * every list update is essentially a wiki page edit, slowly increasing history. This is not that big of a deal because size wise the growth is small and has very little performance impact, plus it makes it possible to track changes with time. On Sat, Aug 3, 2019 at 5:25 PM Andrew Hain <andrewhain...@hotmail.co.uk> wrote: > Now the wiki has data items and scripting in Lua I have been wondering > whether they are a useful alternative to Taginfo-driven lists. > > Advantages of server scripts: > > 1. Descriptions can be generated from data items, tharefore they can > be in a language where there is no long form documentation for the key. > This resolves the issues that have limited use of taglists in languages > other than English because descriptions can be rolled out quickly and some > can be copied from the old map features templates. > 2. Tables at the top of pages are visible immediately, > 3. A successful connection to tagindo.openstreetmap.org is unnecessary. > > Advantages of taglists driven by Taginfo: > > 1. The technology aleady exists and can be rolled out. > 2. Separate scripts avoid overloading the server (Map Features in > Polish, Ukrainian and Japanese hits wiki limits). > 3. The web scripts are free-standing and can be hosted on another > website outside the wiki, > > (crossposted from > https://wiki.openstreetmap.org/wiki/Talk:Taginfo/Taglists#Server_scripts_as_alternative_taglists > ) > > -- > Andrew > Talk:Taginfo/Taglists - OpenStreetMap Wiki > <https://wiki.openstreetmap.org/wiki/Talk:Taginfo/Taglists#Server_scripts_as_alternative_taglists> > Languages. This is a very cool feature! One question: Could the template > get the langugage automatically? I know this is done on some templates > (e.g. Template:Tag).-- Jojo4u 17:20, 20 August 2015 (UTC) . I am not a > template wizard. > wiki.openstreetmap.org > > ------------------------------ > *From:* Joseph Eisenberg <joseph.eisenb...@gmail.com> > *Sent:* 02 August 2019 14:22 > *To:* Tag discussion, strategy and related tools < > tagging@openstreetmap.org> > *Subject:* Re: [Tagging] Rethinking Map Features > > Andrew, > > I now think it is a good idea to switch to taglists for all of the Map > Feature page templates. It will make it much easier to keep the pages > consistent and to a reasonable length if all of the descriptions are > pulled from the wiki pages directly (just as is done for descriptions > used by Taginfo). > > This just means that any deprecated or discouraged tags which are > currently "strikethrough" on Map Features will need something in the > description that mentions that they are discouraged. This is a good > idea anyway, so that the documentation is consistent. > > Joseph > > On 7/7/19, Andrew Hain <andrewhain...@hotmail.co.uk> wrote: > > I have been working on a scheme to improve the cross-language quality of > Map > > Features. > > [ > https://wiki.openstreetmap.org/wiki/Talk:Map_Features#Reimagining_Map_Features > ] > > > > Of course the page may deserve a bigger or deeper rethink. > > > > -- > > Andrew > > Talk:Map Features - OpenStreetMap > > Wiki< > https://wiki.openstreetmap.org/wiki/Talk:Map_Features#Reimagining_Map_Features > > > > amenity=school rendering colour. amenity=school is displayed in the page > as > > a light-purple area for ways, whereas mapnik renders them as a pale > yellow > > colour > > wiki.openstreetmap.org > > > > > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
