[Tagging] Rethinking Map Features

Yuri Astrakhan yuriastrakhan at gmail.com
Sun Aug 4 07:08:33 UTC 2019


Joseph, could you clarify what you mean by "Map Features entry" ?  If you
only refer to keys/tags/relations/relation roles, than those things are
automatically created -- an editor only needs to translate them.

I do agree that if we want to store more diverse data items, we need
specialized UI, at least for the initial item creation. Luckily, there is a
large Wikidata community that has already done many such custom UIs. For
example, Wikidata now stores language data (all lexems), and there is a
community-created tool to add such words --
https://tools.wmflabs.org/lexeme-forms/  (I'm not sure if this tool checks
for duplicates, please check first if you want to add new data). There are
many other tools we can model after.  Best thing -- those tools don't have
to be part of the wiki, but can reside anywhere else, and could be in pure
client-side JavaScript.

On Sun, Aug 4, 2019 at 2:05 AM Joseph Eisenberg <joseph.eisenberg at gmail.com>
wrote:

> So far, I've found it very difficult to create and edit new wikibase
> entries. I don't think it will be easier for Indonesian mappers to
> create a wikibase entry for every Map Features entry, rather than
> creating a stub page with a description.
>
> The advantage of translating wiki pages for each features is that then
> there is a human-readable page which can be updated and expanded over
> time, and also it's clear where the list of feature descriptions are
> coming from.
>
> If you want everyone to create wikibase entries instead, there needs
> to be a much easier, friendlier interface, available in all languages,
> and I think such a major change should be discussed and be implemented
> only if there is consensus that this would be a clear improvement for
> most language communities.
>
> On 8/4/19, Yuri Astrakhan <yuriastrakhan at gmail.com> wrote:
> > 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 <andrewhainosm at 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.eisenberg at gmail.com>
> >> *Sent:* 02 August 2019 14:22
> >> *To:* Tag discussion, strategy and related tools <
> >> tagging at 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 <andrewhainosm at 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 at openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/tagging
> >> _______________________________________________
> >> Tagging mailing list
> >> Tagging at openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/tagging
> >>
> >
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20190804/b633df12/attachment-0001.html>


More information about the Tagging mailing list