iD news - 2.12.0 released 🎉

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

iD news - 2.12.0 released 🎉

Bryan Housel-2
Last week, after several months of work, we released iD v2.12.0 for editing OpenStreetMap.
I hope you like it!  Here are some of the highlights from the release:

✌️  2-finger pan and zoom gestures
Mac users can now use 2 finger trackpad gestures to pan and zoom the map.
Try swiping with 2 fingers to pan, or pinching out/in to zoom and unzoom. You'll be less likely to accidentally drag nodes!

🔻  Directional way markers
iD now draws triangular markers on the "down" side of ways where the direction matters. Thanks, Huon Wilson for this feature!
Ways with a direction include cliffs, coastlines, retaining walls, kerbs, guard rails, embankments.

↔️  Resizable sidebar
You can now resize the sidebar, or hide it completely. Shout out to Quincy Morgan for his work on this!
Try dragging the sidebar to resize it, or click the hide button in the top toolbar. The top bar buttons can also shrink on narrower screens.

🍔  Brand Name Suggestions
We've released a huge upgrade to the brand name suggestions in iD. Thank you to everyone who volunteered to match brand names to their proper OpenStreetMap tags.  Follow the brand name suggestion project here:  https://github.com/osmlab/name-suggestion-index
Try adding some branded businesses to the map - `brand`, `brand:wikidata`, and other tags will be set for you.

📎  More Wikidata integration 
iD now displays linked data if a feature has a wikidata tag, and will protect fields like name and brand from direct editing.
Make sure prominent features have a Wikidata tag, for added protection against accidental changes.

🔆  More features for working with relations
Hovering over a relation or member in the sidebar will highlight it on the map. You can also download incomplete sections, and zoom to inspect relation children. Thanks, Quincy Morgan!
Check out the "All Relations" and "All Members" sections of the sidebar to try out the new relation editing tools.

👩‍💻  Hacktoberfest happened! 
We merged 40 pull requests during the month of October. Thank you to all of our new contributors!


As always, the update includes many other usability improvements and new presets - check out the changelog for all the details.
(It’s pretty epic, thanks to the dozens of people who worked on this release!)

Changelog: 
v2.12.0 changelog:  https://github.com/openstreetmap/iD/blob/master/CHANGELOG.md#2120

Twitter:
v2.12.0 announcement:  https://twitter.com/bhousel/status/1070068684297768960  


Follow and star the iD project on GitHub to show your support:  https://github.com/openstreetmap/iD
And follow me on Twitter https://twitter.com/bhousel for the latest iD news. 

Thank you!
❤️ Bryan, and the rest of the 🆔 team.

P.S.
We are getting together in NYC to hack on iD during the week of Dec 17-21 at the Facebook office.  Space is limited, so please private message me if you want to attend!  We also have started a bi-weekly sync for the core development team.  If you want to work on iD, we’d love your help!


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

Re: iD news - 2.12.0 released 🎉

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 [hidden email]  ##  N49°00'09" E008°23'33"

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

Re: iD news - 2.12.0 released 🎉

Andrew Harvey-3
On Mon, 10 Dec 2018 at 19:02, Frederik Ramm <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: iD news - 2.12.0 released 🎉

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
[hidden email]
https://lists.openstreetmap.org/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: iD news - 2.12.0 released 🎉

dieterdreist
In reply to this post by Andrew Harvey-3
Am Mo., 10. Dez. 2018 um 13:51 Uhr schrieb Andrew Harvey <[hidden email]>:
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
[hidden email]
https://lists.openstreetmap.org/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: iD news - 2.12.0 released 🎉

Bryan Housel-2
In reply to this post by Frederik Ramm
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:

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 <[hidden email]> 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  ##  [hidden email]  ##  N49°00'09" E008°23'33"

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


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

Re: iD news - 2.12.0 released 🎉

Yves-2
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
[hidden email]
https://lists.openstreetmap.org/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: iD news - 2.12.0 released 🎉

SimonPoole
In reply to this post by Andrew Harvey-3
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 <[hidden email]> 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
> [hidden email]
> https://lists.openstreetmap.org/listinfo/dev

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

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: iD news - 2.12.0 released 🎉

Frederik Ramm
Hi,

On 12/10/18 17:42, Simon Poole wrote:
> I suspect Frederik was more concerned about the consequence that it
> makes place names essentially uneditable.

I was hoping to get an explanation from Bryan what the idea behind this
was, especially if there's any API level connection to Wikidata either
implemented or planned. My gut reaction is "we certainly don't want to
defer to Wikidata for names" but perhaps I've got this wrong and that's
not what this whole thing is about. I wanted to ask for details before
judging it or expressing concern.

Bye
Frederik

--
Frederik Ramm  ##  eMail [hidden email]  ##  N49°00'09" E008°23'33"


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

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: iD news - 2.12.0 released 🎉

Sarah Hoffmann
In reply to this post by Bryan Housel-2
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
[hidden email]
https://lists.openstreetmap.org/listinfo/dev