Rethinking Map Features

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Rethinking Map Features

Andrew Hain
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


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Map Features

Joseph Eisenberg
From the talk page:

>I propose to tackle the varying quality of this page in different languages by changing Map
>Features to a single multilingual page that outputs its text in the user’s preferred interface
>language.

>The tag tables can be generated from Taginfo/Taglists. For the best results it should be
>possible to set the description of each tag in each language ahead of writing a long-form
>documentation page.

>The introduction becomes a translatable {{int:…}} string, the message for each language
>transcluding a template of the actual introduction.

>The section headings and table headers also become {{int:…}} messages.

>--Andrew (talk) 11:47, 5 July 2019 (UTC)

>Generating the tables from taginfo taglists is a good idea. But {{int:…}} would require the
>translations to live in the MediaWiki: namespace, which is only editable by administrators.'
>While that's reasonable for widely used templates, elements like the introduction to this
>page are only relevant to a single page. If we rely on taginfo taglists, then there's not as
>much to translate manually as part of the page anyways. – Minh Nguyễn 💬 22:06, 6 July
>2019 (UTC)

I partially agree with Minh's comments. It would be easier to maintain
the page if the descriptions came directly from the description=*
field in the ValueDescription box on each Tag page. This would also
make it clear that a feature can't be added to Map Features without a
wiki page (something that happens surprisingly often).

I've been trying to updated the translated Indonesian Map Features
page. The biggest problem is that you need to check each of the newly
added features on the English page to check if they are actually
approved or de facto tags, rather than a new tag that was added
without discussion. I've already removed a number of tags from the
amenities section that were added without discussion in the past 2
years, but there are several more that should be discussed and status
changed to "De facto"'

My understanding is that tags on the Map Features page should be
status = De facto or status = approved, for consistency.

Perhaps it's possible to include an icon or text column on the Map
Features page that states the status of each tag, Approved, De facto,
In use, Proposed etc.? This would make it easier to find tags that
still need discussion

Joseph

On 7/7/19, Andrew Hain <[hidden email]> 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

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Map Features

Warin
On 07/07/19 10:42, Joseph Eisenberg wrote:

>  From the talk page:
>
>> I propose to tackle the varying quality of this page in different languages by changing Map
>> Features to a single multilingual page that outputs its text in the user’s preferred interface
>> language.
>> The tag tables can be generated from Taginfo/Taglists. For the best results it should be
>> possible to set the description of each tag in each language ahead of writing a long-form
>> documentation page.
>> The introduction becomes a translatable {{int:…}} string, the message for each language
>> transcluding a template of the actual introduction.
>> The section headings and table headers also become {{int:…}} messages.
>> --Andrew (talk) 11:47, 5 July 2019 (UTC)
>> Generating the tables from taginfo taglists is a good idea. But {{int:…}} would require the
>> translations to live in the MediaWiki: namespace, which is only editable by administrators.'
>> While that's reasonable for widely used templates, elements like the introduction to this
>> page are only relevant to a single page. If we rely on taginfo taglists, then there's not as
>> much to translate manually as part of the page anyways. – Minh Nguyễn 💬 22:06, 6 July
>> 2019 (UTC)
> I partially agree with Minh's comments. It would be easier to maintain
> the page if the descriptions came directly from the description=*
> field in the ValueDescription box on each Tag page. This would also
> make it clear that a feature can't be added to Map Features without a
> wiki page (something that happens surprisingly often).
>
> I've been trying to updated the translated Indonesian Map Features
> page. The biggest problem is that you need to check each of the newly
> added features on the English page to check if they are actually
> approved or de facto tags, rather than a new tag that was added
> without discussion. I've already removed a number of tags from the
> amenities section that were added without discussion in the past 2
> years, but there are several more that should be discussed and status
> changed to "De facto"'
>
> My understanding is that tags on the Map Features page should be
> status = De facto or status = approved, for consistency.

Why?

status=approve means it has beeen voted on byt the tagging list and passed.

status=de facto means it was in use before the tagging list made up the approval process, and is generally accepted?

Other status values exist .. why is there a need to ignore or change them?

>
> Perhaps it's possible to include an icon or text column on the Map
> Features page that states the status of each tag, Approved, De facto,
> In use, Proposed etc.? This would make it easier to find tags that
> still need discussion

Arr .. better.
But ... proposed tags I don't think should be propagated for the general OSM population use. These are still under discussion and can change.
Finding tags that 'need discussion' can be done using the status tag ...
https://wiki.openstreetmap.org/wiki/Category:Proposals_by_status

>
> Joseph
>
> On 7/7/19, Andrew Hain <[hidden email]> 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



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Map Features

Joseph Eisenberg
> status=de facto means it was in use before the tagging list made up the
> approval process, and is generally accepted?

The "De facto" is not only used for tags that were created before the
approval process started. A number of more recent tags (post-2008)
have status "de facto" and are listed on Map Features.

I wish there was a wiki page that defined the meaning of each status,
though I believe only the difference between "de facto" and "in use"
is unclear at the moment.

> Other status values exist .. why is there a need to ignore or change them?

My theory is that a tag that's included Map Features should either be
approved or the status changed to "de facto". The wiki can be easily
edited to change a tag from "in use" or "proposed" to "de facto" if
the community agrees that a tag has already become accepted and widely
used, without a complete approval process.

So any tags that are current "in use" but in Map features could be
changed to "de facto" after a brief discussion.

> But ... proposed tags I don't think should be propagated for the general OSM
> population use.

Absolutely. That's why I would like an easy way to see if a proposed
or draft tag has been added to the Map Features page; they should be
removed until discussed.

-Joseph

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Map Features

dieterdreist
In reply to this post by Warin


sent from a phone

> On 7. Jul 2019, at 09:02, Warin <[hidden email]> wrote:
>
> status=de facto means it was in use before the tagging list made up the approval process, and is generally accepted?


defacto means the tag is in significant use and is generally accepted, and no proposal was voted on. It will often have evolved in times when the voting procedure was already established.


Cheers, Martin
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Map Features

marc marc
In reply to this post by Joseph Eisenberg
Le 07.07.19 à 10:31, Joseph Eisenberg a écrit :
> the difference between "de facto" and "in use"
> is unclear at the moment.

approved : a proposal was made and approved during the vote.
no proposal has in the meantime depreciated this tag.

de facto: a not-voted tag but whose important use and absence
of criticism makes it the tag to use for the described usecase.

in use : I see 2 possible meanings:
or it is a generic value for tags that have not been further analyzed
and better classified in a more specific category.
or it is a value to say "not approved, not de facto".
landuse=forest<>natural=wood" could probably be in this situation
since there is not a de facto tag to use to describe a forest but 2.
probably that a better word would be necessary, if not to succeed in
having one "de facto"
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Map Features

dieterdreist


sent from a phone

> On 10. Jul 2019, at 12:06, marc marc <[hidden email]> wrote:
>
> landuse=forest<>natural=wood" could probably be in this situation
> since there is not a de facto tag to use to describe a forest but 2.


actually those are both de-facto (if there wasn’t any voting), and their meaning is not about a forest (says the wiki) but about trees growing there.

Cheers, Martin
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Map Features

Warin
In reply to this post by marc marc
On 10/07/19 20:06, marc marc wrote:
> Le 07.07.19 à 10:31, Joseph Eisenberg a écrit :
>> the difference between "de facto" and "in use"
>> is unclear at the moment.
> approved : a proposal was made and approved during the vote.
> no proposal has in the meantime depreciated this tag.
>
> de facto: a not-voted tag but whose important use and absence
> of criticism makes it the tag to use for the described usecase.

I apply an additional qualification: existed before the approval process.

>
> in use : I see 2 possible meanings:
> or it is a generic value for tags that have not been further analyzed
> and better classified in a more specific category.
> or it is a value to say "not approved, not de facto".

With the above additional qualification to de facto, 'In use' becomes a frequently used tag without any criticism.
The difference between the two is historical, before or after the adoption of the approval process.
It distinguishes between those tags that could not have been through the approval process and those that could but were not.

> landuse=forest<>natural=wood" could probably be in this situation
> since there is not a de facto tag to use to describe a forest but 2.
> probably that a better word would be necessary, if not to succeed in
> having one "de facto"
> _______________________________________________

The key 'landuse' implies that 'landuse=forest' is for those area that have economic befits to humans e.g. timber produce.

The tag natural=wood can be used for "managed woods" as the key 'natural' states that it can be used for things that have human intervention.

There is considerable criticism of the use of both tags, so there should be some concern over the status of these, perhaps a new status "contentious"?



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Map Features

Graeme Fitzpatrick

On Thu, 11 Jul 2019 at 08:20, Warin <[hidden email]> wrote:

With the above additional qualification to de facto, 'In use' becomes a frequently used tag without any criticism.
The difference between the two is historical, before or after the adoption of the approval process.
It distinguishes between those tags that could not have been through the approval process and those that could but were not.

So how do we go with creating a page for a tag that is "in use" but has apparently never been discussed?

Last week, I asked about a Christmas shop, thinking about tagging it as shop=party, but it was pointed out that shop=christmas has actually been used 14 times, but apparently has never been discussed anywhere?

Does that make it "in use" / "de facto"?

Am I OK to just create a page for shop=christmas, so other people know it exists, or should it go through the full RFC / voting procedure to be "approved"?

Thanks

Graeme

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Map Features

Warin
On 11/07/19 09:46, Graeme Fitzpatrick wrote:

On Thu, 11 Jul 2019 at 08:20, Warin <[hidden email]> wrote:

With the above additional qualification to de facto, 'In use' becomes a frequently used tag without any criticism.
The difference between the two is historical, before or after the adoption of the approval process.
It distinguishes between those tags that could not have been through the approval process and those that could but were not.

So how do we go with creating a page for a tag that is "in use" but has apparently never been discussed?

Last week, I asked about a Christmas shop, thinking about tagging it as shop=party, but it was pointed out that shop=christmas has actually been used 14 times, but apparently has never been discussed anywhere?

14? I don't think that is a 'significant' number of uses.

I made a wiki page for netball, which had some ~1,000 uses when I made the page. Now over 6,000 uses... I have not bothered with the status of it .. IIRC left it unstated.
Considering the present state of 'status' I probably won't bother with it.


Does that make it "in use" / "de facto"?

Am I OK to just create a page for shop=christmas, so other people know it exists, or should it go through the full RFC / voting procedure to be "approved"?

Your choice.




_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Map Features

Paul Allen
In reply to this post by Graeme Fitzpatrick
On Thu, 11 Jul 2019 at 00:47, Graeme Fitzpatrick <[hidden email]> wrote:

So how do we go with creating a page for a tag that is "in use" but has apparently never been discussed?

Same way you create any page.  Search for the key, or key=value and if it doesn't already
exist the Wiki offers to let you create it.

Oh, you mean how do you create a page for an in-use, but undocumented, key or value
in a way that won't cause somebody to throw a wobbler and insist you delete the page?
That's probably not possible. :)

Last week, I asked about a Christmas shop, thinking about tagging it as shop=party, but it was pointed out that shop=christmas has actually been used 14 times, but apparently has never been discussed anywhere?

Does that make it "in use" / "de facto"?

Yes.  One of those.  Probably.

Am I OK to just create a page for shop=christmas, so other people know it exists, or should it go through the full RFC / voting procedure to be "approved"?

From  https://wiki.openstreetmap.org/wiki/Key:shop#Others you are allowed to have user-defined
values for shops.  There's a bit of a chicken and egg situation, because it implies you can only
use a user-defined value if it is commonly used (how common?) in taginfo, which it won't be
until somebody uses it, which they can't because it's not in taginfo.

That said, if it is commonly used, or obviously (to most) sensible, then I'd just add it to the shop
page and possibly create a page for the value.  Argument for: some editors interrogate the
OSM wiki and/or OSM wikidata to populate drop-downs, so adding a page for the value ensures
(maybe) it will appear in the drop-down.  Argument against: same as the argument for, except
with things like denomination it ends up being a very large drop-down (except denomination
appears no longer to get the drop-down populated by that mechanism).

--
Paul


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Map Features

dieterdreist


sent from a phone

> On 11. Jul 2019, at 10:53, Paul Allen <[hidden email]> wrote:
>
> Oh, you mean how do you create a page for an in-use, but undocumented, key or value
> in a way that won't cause somebody to throw a wobbler and insist you delete the page?
> That's probably not possible. :)


People are setting up new pages continuously, most of them are not contested as a whole, but likely will be modified and amended in the details by other mappers. If someone insists on deletion there may be serious issues (but not necessarily). You can (and probably should) still set up a formal proposal for a definition at this point.

Cheers Martin


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Map Features

Joseph Eisenberg
In reply to this post by Andrew Hain
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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Map Features

Andrew Hain

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


From: Joseph Eisenberg <[hidden email]>
Sent: 02 August 2019 14:22
To: Tag discussion, strategy and related tools <[hidden email]>
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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Map Features

Yuri Astrakhan-2
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 <[hidden email]> 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
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.


From: Joseph Eisenberg <[hidden email]>
Sent: 02 August 2019 14:22
To: Tag discussion, strategy and related tools <[hidden email]>
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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Map Features

Joseph Eisenberg
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
>> *Sent:* 02 August 2019 14:22
>> *To:* Tag discussion, strategy and related tools <
>> [hidden email]>
>> *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 <[hidden email]> 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
>> [hidden email]
>> https://lists.openstreetmap.org/listinfo/tagging
>> _______________________________________________
>> Tagging mailing list
>> [hidden email]
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Map Features

Yuri Astrakhan-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
>> *Sent:* 02 August 2019 14:22
>> *To:* Tag discussion, strategy and related tools <
>> [hidden email]>
>> *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 <[hidden email]> 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
>> [hidden email]
>> https://lists.openstreetmap.org/listinfo/tagging
>> _______________________________________________
>> Tagging mailing list
>> [hidden email]
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Map Features

Andrew Hain
In reply to this post by Yuri Astrakhan-2
How would you stop the bot from going down and protect against whoever runs it leaving OSM?

--
Andrew

From: Yuri Astrakhan <[hidden email]>
Sent: 03 August 2019 23:06
To: Tag discussion, strategy and related tools <[hidden email]>
Subject: Re: [Tagging] Rethinking Map Features
 
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 <[hidden email]> 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
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.


From: Joseph Eisenberg <[hidden email]>
Sent: 02 August 2019 14:22
To: Tag discussion, strategy and related tools <[hidden email]>
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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Map Features

Joseph Eisenberg
In reply to this post by Yuri Astrakhan-2
You're right, I was a little confused. Almost all the features on Map
Features have a wiki page (and those that don't should get a page or
more likely be removed), so I understand that they have an OSM
wikibase entry, now, and creating the data item isn't an issue.

But I still can't figure out how to add description in another language?

I tried to get the Indonesian translation by:
1) Open the English wiki page (eg from the link on Map Features in this case)
2) Click on the little pencil to edit the OSM wikibase data item
(which I can't see, because I have images disabled, but I just hunt
around...)
3) Click on "edit" next to description
4) Click "all entered languages" - wait, how do I add Indonesian?
?

Maybe I don't see Indonesian because I'm using a satellite internet
connection from Australia and I haven't edited Indonesian before. I
try clicking on "Configure" next to "In more languages"

I don't see Indonesian there either. So perhaps I have to make a new
wikibase entry for my language? Unfortunately I don't see a link to
make a new wikibase item.

Ok, let's try again with Spanish (Español), that's on the list...

I still can't figure it out. How do I add a description in another language?

Fortunately I can just make a stub wiki page by:

1) Open the English language page
2) Click on edit
3) Copy the url, add "id:" in front of the page name
4) Copy and paste the ValueDescription / KeyDescription box content
5) Edit the description to Indonesian

It looks like that will still be fewer clicks and fewer mouse strokes
than editing the OSM wikibase data items, and has the benefit of
creating a visible wiki page rather than just editing an obscure data
item.

Joseph

On 8/4/19, Yuri Astrakhan <[hidden email]> wrote:

> 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
> <[hidden email]>
> 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.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Map Features

Yuri Astrakhan-2
Joseph, before you click "edit description", change your language at the top of the wiki page (make sure you are logged in.  Also, if you change the language a few times to the ones you know, e.g. to Indonesian, to Spanish, and then to English, I think interface will always offer you to enter description in the last few you had picked.

Thanks for adding translations!

On Sun, Aug 4, 2019 at 11:40 AM Joseph Eisenberg <[hidden email]> wrote:
You're right, I was a little confused. Almost all the features on Map
Features have a wiki page (and those that don't should get a page or
more likely be removed), so I understand that they have an OSM
wikibase entry, now, and creating the data item isn't an issue.

But I still can't figure out how to add description in another language?

I tried to get the Indonesian translation by:
1) Open the English wiki page (eg from the link on Map Features in this case)
2) Click on the little pencil to edit the OSM wikibase data item
(which I can't see, because I have images disabled, but I just hunt
around...)
3) Click on "edit" next to description
4) Click "all entered languages" - wait, how do I add Indonesian?
?

Maybe I don't see Indonesian because I'm using a satellite internet
connection from Australia and I haven't edited Indonesian before. I
try clicking on "Configure" next to "In more languages"

I don't see Indonesian there either. So perhaps I have to make a new
wikibase entry for my language? Unfortunately I don't see a link to
make a new wikibase item.

Ok, let's try again with Spanish (Español), that's on the list...

I still can't figure it out. How do I add a description in another language?

Fortunately I can just make a stub wiki page by:

1) Open the English language page
2) Click on edit
3) Copy the url, add "id:" in front of the page name
4) Copy and paste the ValueDescription / KeyDescription box content
5) Edit the description to Indonesian

It looks like that will still be fewer clicks and fewer mouse strokes
than editing the OSM wikibase data items, and has the benefit of
creating a visible wiki page rather than just editing an obscure data
item.

Joseph

On 8/4/19, Yuri Astrakhan <[hidden email]> wrote:
> 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
> <[hidden email]>
> 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.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
12