Re: [Tagging] Rethinking Map Features

[Marc Gemis]

I probably should have used "desirable" instead of "required" (*), but
even then this is not "desirable" for countries where postal code
boundaries are mapped as relations.

(*) please look at the video and see which text is pasted in the
Wikibase definition for addr:street.

On Tue, Aug 6, 2019 at 3:51 PM Tod Fitch  wrote:
>
>
>
> > On Aug 6, 2019, at 12:56 AM, Martin Koppenhoefer  
> > wrote:
> >
> > sent from a phone
> >
> >> On 6. Aug 2019, at 05:33, Tod Fitch  wrote:
> >>
> >> When I walk down a street collecting house numbers I have no indication of 
> >> the ZIP code of each building. If you require ZIP codes then I am forced 
> >> into an import situation rather than a field survey
> >
> >
> > you might survey this by asking locals about their address, or by looking 
> > at addresses that businesses publish about themselves.
> >
> > Cheers Martin
>
> When I map businesses I do look to see what they publish about themselves and 
> the ZIP code as well as hours of operation can be easily determined. But if 
> you are asking me to knock on doors in residential areas or ask total 
> strangers who look like they might be locals what their ZIP code is as I 
> collect non-business addresses you are asking too much.
>
> In the suburban sprawl of my country I am guessing there are far more 
> residential addresses than business addresses. So putting postal code 
> requirement on my collecting house numbers means that either we will never 
> have a critical mass of house numbers or we will be doing it all with 
> imports. By critical mass, I mean a sufficient density of numbers so people 
> use OSM as their first choice for looking up an address to navigate to. At 
> least where I live, ZIP codes are not needed or normally used for when giving 
> an address for a navigation destination. ZIP codes are used really for just 
> one thing: Delivering mail.
>
> I can see a suggestion in the wiki that acquiring a postal/ZIP code for an 
> address is desirable to provide completeness. But making it a requirement? No.
>
> Cheers Tod.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rethinking Map Features

[Martin Koppenhoefer]

sent from a phone

> On 6. Aug 2019, at 15:49, Tod Fitch  wrote:
> 
> But if you are asking me to knock on doors in residential areas or ask total 
> strangers who look like they might be locals what their ZIP code is as I 
> collect non-business addresses you are asking too much.


I didn’t say you must do it, I wrote it was a possible way to survey ZIP code 
data on the ground, it is not impossible to do it. ;-)

Cheers Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rethinking Map Features

[marc marc]

Le 06.08.19 à 15:49, Tod Fitch a écrit :
> ZIP code for an address is desirable to provide completeness. But making it a 
> requirement? No.

I agree. where is the zip code an requirement ?

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rethinking Map Features

[Tod Fitch]

> On Aug 6, 2019, at 12:56 AM, Martin Koppenhoefer  
> wrote:
> 
> sent from a phone
> 
>> On 6. Aug 2019, at 05:33, Tod Fitch  wrote:
>> 
>> When I walk down a street collecting house numbers I have no indication of 
>> the ZIP code of each building. If you require ZIP codes then I am forced 
>> into an import situation rather than a field survey
> 
> 
> you might survey this by asking locals about their address, or by looking at 
> addresses that businesses publish about themselves.
> 
> Cheers Martin

When I map businesses I do look to see what they publish about themselves and 
the ZIP code as well as hours of operation can be easily determined. But if you 
are asking me to knock on doors in residential areas or ask total strangers who 
look like they might be locals what their ZIP code is as I collect non-business 
addresses you are asking too much.

In the suburban sprawl of my country I am guessing there are far more 
residential addresses than business addresses. So putting postal code 
requirement on my collecting house numbers means that either we will never have 
a critical mass of house numbers or we will be doing it all with imports. By 
critical mass, I mean a sufficient density of numbers so people use OSM as 
their first choice for looking up an address to navigate to. At least where I 
live, ZIP codes are not needed or normally used for when giving an address for 
a navigation destination. ZIP codes are used really for just one thing: 
Delivering mail.

I can see a suggestion in the wiki that acquiring a postal/ZIP code for an 
address is desirable to provide completeness. But making it a requirement? No.

Cheers Tod.


signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rethinking Map Features

[Tod Fitch]

Requiring postal codes on addresses makes no sense even in countries that use 
ZIP codes. When I walk down a street collecting house numbers I have no 
indication of the ZIP code of each building. If you require ZIP codes then I am 
forced into an import situation rather than a field survey.

Cheers!
Tod


On August 6, 2019 3:10:44 AM UTC, Marc Gemis  wrote:
>and what if I do not agree with the English text. I saw the example
>for addr:street in your movie.
>The description now says you have to add addr:postal_code. This is not
>true for countries whare postal code boundaries are mapped. I do agree
>that this is needed in countries that use ZIP codes though. How do we
>solve such issues (before they get translated in too many languagues)
>?
>
>regards
>
>m.
>
>On Mon, Aug 5, 2019 at 4:00 PM Joseph Eisenberg
> wrote:
>>
>> Thanks, I've got it now.
>>
>> The problem with the wikibase data item "labels": if you go to add
>the
>> description in another language for a recently created wiki page, the
>> top left of the page has a very large, gray text heading like "No
>> Label Defined" (but in Indonesian, or Spanish, etc), which suggests
>> that something is missing.
>>
>> I suspect this happens because the English "label" field may not have
>> been created in the data item?
>>
>> Also, when adding the description, the next field to the left is the
>> blank label field, with grayed-out text "No Label Found". It's quite
>> tempting to fill this in. Do we really want wiki users to feel they
>> should add translations for the "key" and "value" of each tag?
>>
>> On 8/5/19, Yuri Astrakhan  wrote:
>> > Joseph, you don't need to use preferences - just click the language
>> > switcher at the very top of the page, and you only need to switch
>to
>> > Indonesian and back once -- the interface will always offer both
>choices to
>> > fill out.  Please see the video, and let me know if what you see is
>> > different. You might be using mobile version of the site?
>> >
>> > Filling it out labels in every language is a bit silly - there are
>> > thousands of languages, why would we want to store identical
>information in
>> > every one of them, when the system automatically does fallback to
>English?
>> > I could create some sort of a javascript gadget that hides the
>label column
>> > when the item type is a key/value/relation/relation role
>(multilingual
>> > labels are still useful for other item types), but some people have
>already
>> > added some alternative language-specific labels, essentially
>localizing
>> > keys - not sure if we should just hide those.  BTW, if anyone wants
>to hack
>> > on it (I'm looking at you Minh :)), it would be awesome!  Or at
>least we
>> > should maybe give a warning when user tries to add a label
>identical to
>> > English?
>> >
>> > Every wiki page, including the data items have a "history" tab at
>the top
>> > that will show every edit done to that page.
>> >
>> > On Sun, Aug 4, 2019 at 12:17 PM Joseph Eisenberg
>> > 
>> > wrote:
>> >
>> >> Thanks, yes, changing the language under “preferences” for the
>wiki
>> >> works,
>> >> though it’s a little annoying.
>> >>
>> >> You should set the label field for all languages to the key=value
>or
>> >> remove this field and display the key=value at the top of the page
>> >> anyway.
>> >> It’s quite distracting Now.
>> >>
>> >> Is there a way to see the wikibase data item history? One big
>concern I
>> >> have is that it won’t be easy to see when something is changed.
>Can you
>> >> get
>> >> notified if someone changes a description?
>> >>
>> >> Joseph
>> >>
>> >> On Mon, Aug 5, 2019 at 1:05 AM Yuri Astrakhan
>
>> >> wrote:
>> >>
>> >>> P.S. I made a short video on how to add descriptions and
>translations
>> >>>
>> >>> https://www.youtube.com/watch?v=rI1NDD4MtC4
>> >>>
>> >>> On Sun, Aug 4, 2019 at 11:56 AM Yuri Astrakhan
>
>> >>> wrote:
>> >>>
>>  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 <
>>  joseph.eisenb...@gmail.com> 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
>> 

Re: [Tagging] Rethinking Map Features

[Marc Gemis]

and what if I do not agree with the English text. I saw the example
for addr:street in your movie.
The description now says you have to add addr:postal_code. This is not
true for countries whare postal code boundaries are mapped. I do agree
that this is needed in countries that use ZIP codes though. How do we
solve such issues (before they get translated in too many languagues)
?

regards

m.

On Mon, Aug 5, 2019 at 4:00 PM Joseph Eisenberg
 wrote:
>
> Thanks, I've got it now.
>
> The problem with the wikibase data item "labels": if you go to add the
> description in another language for a recently created wiki page, the
> top left of the page has a very large, gray text heading like "No
> Label Defined" (but in Indonesian, or Spanish, etc), which suggests
> that something is missing.
>
> I suspect this happens because the English "label" field may not have
> been created in the data item?
>
> Also, when adding the description, the next field to the left is the
> blank label field, with grayed-out text "No Label Found". It's quite
> tempting to fill this in. Do we really want wiki users to feel they
> should add translations for the "key" and "value" of each tag?
>
> On 8/5/19, Yuri Astrakhan  wrote:
> > Joseph, you don't need to use preferences - just click the language
> > switcher at the very top of the page, and you only need to switch to
> > Indonesian and back once -- the interface will always offer both choices to
> > fill out.  Please see the video, and let me know if what you see is
> > different. You might be using mobile version of the site?
> >
> > Filling it out labels in every language is a bit silly - there are
> > thousands of languages, why would we want to store identical information in
> > every one of them, when the system automatically does fallback to English?
> > I could create some sort of a javascript gadget that hides the label column
> > when the item type is a key/value/relation/relation role (multilingual
> > labels are still useful for other item types), but some people have already
> > added some alternative language-specific labels, essentially localizing
> > keys - not sure if we should just hide those.  BTW, if anyone wants to hack
> > on it (I'm looking at you Minh :)), it would be awesome!  Or at least we
> > should maybe give a warning when user tries to add a label identical to
> > English?
> >
> > Every wiki page, including the data items have a "history" tab at the top
> > that will show every edit done to that page.
> >
> > On Sun, Aug 4, 2019 at 12:17 PM Joseph Eisenberg
> > 
> > wrote:
> >
> >> Thanks, yes, changing the language under “preferences” for the wiki
> >> works,
> >> though it’s a little annoying.
> >>
> >> You should set the label field for all languages to the key=value or
> >> remove this field and display the key=value at the top of the page
> >> anyway.
> >> It’s quite distracting Now.
> >>
> >> Is there a way to see the wikibase data item history? One big concern I
> >> have is that it won’t be easy to see when something is changed. Can you
> >> get
> >> notified if someone changes a description?
> >>
> >> Joseph
> >>
> >> On Mon, Aug 5, 2019 at 1:05 AM Yuri Astrakhan 
> >> wrote:
> >>
> >>> P.S. I made a short video on how to add descriptions and translations
> >>>
> >>> https://www.youtube.com/watch?v=rI1NDD4MtC4
> >>>
> >>> On Sun, Aug 4, 2019 at 11:56 AM Yuri Astrakhan 
> >>> wrote:
> >>>
>  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 <
>  joseph.eisenb...@gmail.com> 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 

Re: [Tagging] Rethinking Map Features

[Joseph Eisenberg]

Thanks, I've got it now.

The problem with the wikibase data item "labels": if you go to add the
description in another language for a recently created wiki page, the
top left of the page has a very large, gray text heading like "No
Label Defined" (but in Indonesian, or Spanish, etc), which suggests
that something is missing.

I suspect this happens because the English "label" field may not have
been created in the data item?

Also, when adding the description, the next field to the left is the
blank label field, with grayed-out text "No Label Found". It's quite
tempting to fill this in. Do we really want wiki users to feel they
should add translations for the "key" and "value" of each tag?

On 8/5/19, Yuri Astrakhan  wrote:
> Joseph, you don't need to use preferences - just click the language
> switcher at the very top of the page, and you only need to switch to
> Indonesian and back once -- the interface will always offer both choices to
> fill out.  Please see the video, and let me know if what you see is
> different. You might be using mobile version of the site?
>
> Filling it out labels in every language is a bit silly - there are
> thousands of languages, why would we want to store identical information in
> every one of them, when the system automatically does fallback to English?
> I could create some sort of a javascript gadget that hides the label column
> when the item type is a key/value/relation/relation role (multilingual
> labels are still useful for other item types), but some people have already
> added some alternative language-specific labels, essentially localizing
> keys - not sure if we should just hide those.  BTW, if anyone wants to hack
> on it (I'm looking at you Minh :)), it would be awesome!  Or at least we
> should maybe give a warning when user tries to add a label identical to
> English?
>
> Every wiki page, including the data items have a "history" tab at the top
> that will show every edit done to that page.
>
> On Sun, Aug 4, 2019 at 12:17 PM Joseph Eisenberg
> 
> wrote:
>
>> Thanks, yes, changing the language under “preferences” for the wiki
>> works,
>> though it’s a little annoying.
>>
>> You should set the label field for all languages to the key=value or
>> remove this field and display the key=value at the top of the page
>> anyway.
>> It’s quite distracting Now.
>>
>> Is there a way to see the wikibase data item history? One big concern I
>> have is that it won’t be easy to see when something is changed. Can you
>> get
>> notified if someone changes a description?
>>
>> Joseph
>>
>> On Mon, Aug 5, 2019 at 1:05 AM Yuri Astrakhan 
>> wrote:
>>
>>> P.S. I made a short video on how to add descriptions and translations
>>>
>>> https://www.youtube.com/watch?v=rI1NDD4MtC4
>>>
>>> On Sun, Aug 4, 2019 at 11:56 AM Yuri Astrakhan 
>>> wrote:
>>>
 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 <
 joseph.eisenb...@gmail.com> 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 / 

Re: [Tagging] Rethinking Map Features

[Yuri Astrakhan]

Joseph, you don't need to use preferences - just click the language
switcher at the very top of the page, and you only need to switch to
Indonesian and back once -- the interface will always offer both choices to
fill out.  Please see the video, and let me know if what you see is
different. You might be using mobile version of the site?

Filling it out labels in every language is a bit silly - there are
thousands of languages, why would we want to store identical information in
every one of them, when the system automatically does fallback to English?
I could create some sort of a javascript gadget that hides the label column
when the item type is a key/value/relation/relation role (multilingual
labels are still useful for other item types), but some people have already
added some alternative language-specific labels, essentially localizing
keys - not sure if we should just hide those.  BTW, if anyone wants to hack
on it (I'm looking at you Minh :)), it would be awesome!  Or at least we
should maybe give a warning when user tries to add a label identical to
English?

Every wiki page, including the data items have a "history" tab at the top
that will show every edit done to that page.

On Sun, Aug 4, 2019 at 12:17 PM Joseph Eisenberg 
wrote:

> Thanks, yes, changing the language under “preferences” for the wiki works,
> though it’s a little annoying.
>
> You should set the label field for all languages to the key=value or
> remove this field and display the key=value at the top of the page anyway.
> It’s quite distracting Now.
>
> Is there a way to see the wikibase data item history? One big concern I
> have is that it won’t be easy to see when something is changed. Can you get
> notified if someone changes a description?
>
> Joseph
>
> On Mon, Aug 5, 2019 at 1:05 AM Yuri Astrakhan 
> wrote:
>
>> P.S. I made a short video on how to add descriptions and translations
>>
>> https://www.youtube.com/watch?v=rI1NDD4MtC4
>>
>> On Sun, Aug 4, 2019 at 11:56 AM Yuri Astrakhan 
>> wrote:
>>
>>> 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 <
>>> joseph.eisenb...@gmail.com> 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  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 

Re: [Tagging] Rethinking Map Features

[Joseph Eisenberg]

Thanks, yes, changing the language under “preferences” for the wiki works,
though it’s a little annoying.

You should set the label field for all languages to the key=value or remove
this field and display the key=value at the top of the page anyway. It’s
quite distracting Now.

Is there a way to see the wikibase data item history? One big concern I
have is that it won’t be easy to see when something is changed. Can you get
notified if someone changes a description?

Joseph

On Mon, Aug 5, 2019 at 1:05 AM Yuri Astrakhan 
wrote:

> P.S. I made a short video on how to add descriptions and translations
>
> https://www.youtube.com/watch?v=rI1NDD4MtC4
>
> On Sun, Aug 4, 2019 at 11:56 AM Yuri Astrakhan 
> wrote:
>
>> 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 <
>> joseph.eisenb...@gmail.com> 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  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
>>> > 
>>> > 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 

Re: [Tagging] Rethinking Map Features

[Yuri Astrakhan]

P.S. I made a short video on how to add descriptions and translations

https://www.youtube.com/watch?v=rI1NDD4MtC4

On Sun, Aug 4, 2019 at 11:56 AM Yuri Astrakhan 
wrote:

> 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 <
> joseph.eisenb...@gmail.com> 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  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
>> > 
>> > 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
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rethinking Map Features

[Yuri Astrakhan]

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 
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  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
> > 
> > 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
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rethinking Map Features

[Joseph Eisenberg]

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  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
> 
> 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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rethinking Map Features

[Andrew Hain]

How would you stop the bot from going down and protect against whoever runs it 
leaving OSM?

--
Andrew

From: Yuri Astrakhan 
Sent: 03 August 2019 23:06
To: Tag discussion, strategy and related tools 
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 
mailto: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<http://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<http://wiki.openstreetmap.org>


From: Joseph Eisenberg 
mailto:joseph.eisenb...@gmail.com>>
Sent: 02 August 2019 14:22
To: Tag discussion, strategy and related tools 
mailto: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 
mailto: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 dee

Re: [Tagging] Rethinking Map Features

[Yuri Astrakhan]

; >> 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 
> >> *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  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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] 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  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 
> 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 
>> *Sent:* 02 August 2019 14:22
>> *To:* Tag discussion, strategy and related tools <
>> tagging@openstreetmap.org>
>> *Subject:* Re: [Tagging] Rethink

Re: [Tagging] Rethinking Map Features

[Yuri Astrakhan]

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 
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 
> *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  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_Fe

Re: [Tagging] 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
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 
Sent: 02 August 2019 14:22
To: Tag discussion, strategy and related tools 
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  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

Re: [Tagging] Rethinking Map Features

[Joseph Eisenberg]

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

Re: [Tagging] Rethinking Map Features

[Martin Koppenhoefer]

sent from a phone

> On 11. Jul 2019, at 10:53, Paul Allen  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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rethinking Map Features

[Paul Allen]

On Thu, 11 Jul 2019 at 00:47, Graeme Fitzpatrick 
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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rethinking Map Features

[Warin]

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


On Thu, 11 Jul 2019 at 08:20, Warin <61sundow...@gmail.com 
> 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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rethinking Map Features

[Graeme Fitzpatrick]

On Thu, 11 Jul 2019 at 08:20, Warin <61sundow...@gmail.com> 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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rethinking Map Features

[Warin]

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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rethinking Map Features

[Martin Koppenhoefer]

sent from a phone

> On 10. Jul 2019, at 12:06, marc marc  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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rethinking Map Features

[marc marc]

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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rethinking Map Features

[Martin Koppenhoefer]

sent from a phone

> On 7. Jul 2019, at 09:02, Warin <61sundow...@gmail.com> 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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] 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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] 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  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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] 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  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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging