Re: [OSM-dev] iD news - 2.12.0 released 

2018-12-10 Thread Sarah Hoffmann
On Mon, Dec 10, 2018 at 09:54:23AM -0500, Bryan Housel wrote:
> Sure, I can describe the logic in more detail.  
> 
> When I talk about “fields”, I mean the fields near the top of iD’s sidebar.  
> Users can still edit all the raw tags in the tag editor that appears below 
> the fields.  
> 
> The purpose of this feature is not really to prevent someone who knows what 
> they are doing from changing a tag value, but more to hint to users 
> (especially newbies) “hey maybe you should not change that”.  
> 
> The protection should discourage people from changing the Name field just for 
> fun, but also make sure that if a business re-brands (e.g. a Shell station 
> changes to an Exxon station) someone changes all the tags and not just the 
> Name that gets rendered.

That's all well meaning but somehow I doubt that a read-only field
will achieve these goals. I see one of two things happen: a
casual mapper who just wants to fix something suddenly finds
that they cannot change stuff and just leave. And the people,
who change names just for fun will randomly poke at the user
interface until their change goes through.

I tried the latter a bit. Lets assume somebody realises that
this McDonalds is actually a Burger King:
https://www.openstreetmap.org/way/586629904

Trying to change that in the new iD, here is the things that
happened during a few minutes me poking the interface in an
attempt to achieve that goal:

* Change only Operator because it is the only editable field that contains
  the offending 'McDonalds' name.

* Change all 'McDonalds' in the raw list of tags. Leaving the wikidata
  field as is because there is no way to know that there is any
correspondence.

* Actually bother to read the tool tip that appears on the locked name,
don't understand a word it says (what is that wikidata it is speaking
of?). The only thing that parses is: 'delete it'.
Click on the closest 'dust bin' you can find(the one for the name
field). Et voila, the name field is writeable again. Conclude that
this is the proper way to change a name.

* Do the not so obvious and click on that 'Fast Food' button on top.
  List appears with preset of which none are 'Fast Food'. There is
no way to know from just looking at the interface that you have
to type 'Burger King' into the search box to achieve your goal.
Even if succeed in finding out, operator and wikipedia
remain with 'McDonalds'. Good luck noticing that.

All of these are relatively likely to happen to somebody unfamiliar
with iD and all end you in an inconsistent state despite the locked
name. The problem here is that there is nothing obvious about the
'protected' fields. As such they are no hint to the user
on how to map but they are  just a barrier to circumvent. You could
of course add more 'protections' to prevent the circumventions
but that just ends in an arms race the editor writer can't win.
All you end up with is an editor that is no longer usable as
a general purpose editor.

To add to that: data consumers (including me) like
to complain a lot about the quality of OSM data but that is
actually greatly exaggerated. As developers, we tend to mostly
see the bad data points because the 99% of good data just
gets processed quietly without drawing any attention. That
tends to skew our perception. The number of errors this
'protection change' prevents is simply not relevant in the
grand scheme of things. And people who want to do real damage
will certainly not be deterred by a tiny read-only barrier.

Sarah

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


Re: [OSM-dev] iD news - 2.12.0 released 

2018-12-10 Thread Simon Poole
I suspect Frederik was more concerned about the consequence that it
makes place names essentially uneditable.

Simon

Am 10.12.2018 um 13:48 schrieb Andrew Harvey:
> On Mon, 10 Dec 2018 at 19:02, Frederik Ramm  wrote:
>> On 10.12.2018 03:14, Bryan Housel wrote:
>>> iD now displays linked data if a feature has a wikidata tag, and will
>>> protect fields like name and brand from direct editing.
>> Can you elaborate on the logic behind this a bit more?
>>
>> On first reading it sounds like if I set a wikidata tag on something, iD
>> will load name and brand from wikidata and not allow editing of those
>> fields but that certainly can't be right. Which fields exactly are
>> protected, what does protection mean, and by what is this protection
>> triggered?
> If you search for a preset with a brand, eg. McDonalds and select that
> it will populate:
>
> amenity=fast_food
> cuisine=burger
> name=McDonald's
> brand=McDonalds
> brand:wikidata=Q38076
> brand:wikipedia=en:McDonald's
>
> Then the name field is locked from editing in your session so you
> can't change it, unless you go down to the advanced "All tags" section
> where you can edit any of these locked free form tags.
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev



signature.asc
Description: OpenPGP digital signature
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev


Re: [OSM-dev] iD news - 2.12.0 released 

2018-12-10 Thread Yves
Not that I like this kind of limitations imposed in the presset fields, but it 
is mainly targeted to avoid newbies mistakes so that's great of some kind. 
This always look to me to over simplify our data model, and will be improved 
over time, I guess. 
Yves 
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev


Re: [OSM-dev] iD news - 2.12.0 released 

2018-12-10 Thread Bryan Housel
Sure, I can describe the logic in more detail.  

When I talk about “fields”, I mean the fields near the top of iD’s sidebar.  
Users can still edit all the raw tags in the tag editor that appears below the 
fields.  

The purpose of this feature is not really to prevent someone who knows what 
they are doing from changing a tag value, but more to hint to users (especially 
newbies) “hey maybe you should not change that”.  

The protection should discourage people from changing the Name field just for 
fun, but also make sure that if a business re-brands (e.g. a Shell station 
changes to an Exxon station) someone changes all the tags and not just the Name 
that gets rendered.

The fields that can be protected are the “Name” and “Brand” fields.

Name
If the `name` tag has a value, and there is a `wikidata` or `brand:wikidata` 
tag with a value, and the “Brand” field is not being shown, the “Name” field 
will be readonly and have a tooltip that says:  "The “Name" field is locked 
because there is a Wikidata tag. You can delete it or edit the tags in the "All 
tags" section."

Brand
If the `brand` tag has a value and there is a `brand:wikidata` tag with a 
value, the “Brand” field will be readonly and have a tooltip that says:  "The 
“Brand" field is locked because there is a Wikidata tag. You can delete it or 
edit the tags in the "All tags" section.”


In practice it means that features with a `wikidata` tag (the closest thing we 
have in OSM to a stable identifier) will have the “Name" field readonly.  This 
includes things like places, landmarks, artworks, schools, etc.  

It also means that most features with a `brand:wikidata` tag will have the 
“Name" field readonly - this includes recognized brands like “McDonald’s”, 
“Starbucks” etc.  The exception to this is when iD displays both a “Name" and a 
“Brand" field, the “Name" field is unlocked and the “Brand" field is locked.  
This is done on gas stations, car/motorcycle dealerships, hotels/motels - 
anything where it is common for the Name and Brand to be different  
(`name=Route 22 Honda`, `brand=Honda`).


More details can be found on this ticket:
https://github.com/openstreetmap/iD/issues/5515 


I also encourage everyone to try editing with iD and see how it works in 
practice.

Thanks,
Bryan



> On Dec 10, 2018, at 2:59 AM, Frederik Ramm  wrote:
> 
> Hi,
> 
> On 10.12.2018 03:14, Bryan Housel wrote:
>> iD now displays linked data if a feature has a wikidata tag, and will
>> protect fields like name and brand from direct editing.
> 
> Can you elaborate on the logic behind this a bit more?
> 
> On first reading it sounds like if I set a wikidata tag on something, iD
> will load name and brand from wikidata and not allow editing of those
> fields but that certainly can't be right. Which fields exactly are
> protected, what does protection mean, and by what is this protection
> triggered?
> 
> Bye
> Frederik
> 
> -- 
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
> 
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev

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


Re: [OSM-dev] iD news - 2.12.0 released 

2018-12-10 Thread Martin Koppenhoefer
Am Mo., 10. Dez. 2018 um 13:51 Uhr schrieb Andrew Harvey <
andrew.harv...@gmail.com>:

> If you search for a preset with a brand, eg. McDonalds and select that
> it will populate:
>
> amenity=fast_food
> cuisine=burger
> name=McDonald's
> brand=McDonalds
> brand:wikidata=Q38076
> brand:wikipedia=en:McDonald's
>
> Then the name field is locked from editing in your session so you
> can't change it, unless you go down to the advanced "All tags" section
> where you can edit any of these locked free form tags.




I would find it strange if a brand:wikidata tag locked the "name" tag,
brand is mainly used for "grouping" of multiple instances (it somehow
defines a category/common property), while name is an individual tag for
instances.
Looking up your McD example with overpass turbo, I found 572 objects with
brand=McDonald's and a name different to "McDonald's", out of 841 total
objects according to taginfo.

I like the idea though to connect brand and brand:wikidata, and require an
extra click (or going to "all tags") when your edit makes them inconsistent.

Cheers,
Martin
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev


Re: [OSM-dev] iD news - 2.12.0 released 

2018-12-10 Thread Dave F



On 10/12/2018 12:48, Andrew Harvey wrote:

If you search for a preset with a brand, eg. McDonalds and select that
it will populate:

amenity=fast_food
cuisine=burger
name=McDonald's
brand=McDonalds
brand:wikidata=Q38076
brand:wikipedia=en:McDonald's

Then the name field is locked from editing in your session so you
can't change it, unless you go down to the advanced "All tags" section
where you can edit any of these locked free form tags.


Tail wagging the dog.

DaveF

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


Re: [OSM-dev] iD news - 2.12.0 released 

2018-12-10 Thread Andrew Harvey
On Mon, 10 Dec 2018 at 19:02, Frederik Ramm  wrote:
> On 10.12.2018 03:14, Bryan Housel wrote:
> > iD now displays linked data if a feature has a wikidata tag, and will
> > protect fields like name and brand from direct editing.
>
> Can you elaborate on the logic behind this a bit more?
>
> On first reading it sounds like if I set a wikidata tag on something, iD
> will load name and brand from wikidata and not allow editing of those
> fields but that certainly can't be right. Which fields exactly are
> protected, what does protection mean, and by what is this protection
> triggered?

If you search for a preset with a brand, eg. McDonalds and select that
it will populate:

amenity=fast_food
cuisine=burger
name=McDonald's
brand=McDonalds
brand:wikidata=Q38076
brand:wikipedia=en:McDonald's

Then the name field is locked from editing in your session so you
can't change it, unless you go down to the advanced "All tags" section
where you can edit any of these locked free form tags.

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


Re: [OSM-dev] iD news - 2.12.0 released 

2018-12-10 Thread Frederik Ramm
Hi,

On 10.12.2018 03:14, Bryan Housel wrote:
> iD now displays linked data if a feature has a wikidata tag, and will
> protect fields like name and brand from direct editing.

Can you elaborate on the logic behind this a bit more?

On first reading it sounds like if I set a wikidata tag on something, iD
will load name and brand from wikidata and not allow editing of those
fields but that certainly can't be right. Which fields exactly are
protected, what does protection mean, and by what is this protection
triggered?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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