[OSM-talk] id Editor auto-converts split polygons into MP relation

[Simon Poole]

Am 29.10.2020 um 00:17 schrieb Dave F:
> iD editor attracts a hell of a lot of "WTFs", doesn't it? I mean, even 
> its most ardent fan must occasionally raise a Roger Moore eyebrow.
>
> bhuousel has taken the presumptive decision that the contributor's 
> desired end result will always be a MP relation. This is wrong, plain 
> & simple (& quite arrogant). iD editor should provide tools to allow 
> contributors to make their own decisions as easily as possible & not 
> take them on their behalf.
>
I'm not sure why you believe Bryan has or had anything to do with that 
specific design decision, but he didn't, that happened a substantial 
time before he had any formal involvement.

> As has been noted other, editors don't make this assumption.

Other editors don't try to synthesize an area type.

>
> The correct solution to split polygons with tags on the ways is to 
> rejoin those ways, not create a MP.
>
As I pointed out, the question is -when- to rejoin those ways.
>  A MP with only one* outer is invalid.
>
Nope.
> * splitting it still means there's only one.
>
> Relations were created to allow mapping of entities, not possible with 
> just ways. They aren't meant to be the default for all objects.
>
See above.

Simon


> DaveF
>
> On 27/10/2020 08:11, Simon Poole wrote:
>> Its done that essentially since day one. As Bryce points out doing so 
>> keeps the object a valid "area" (and iD makes a valiant effort to 
>> stop you from breaking that).
>>
>> It is also one of my favourite examples in talks why trying to keep 
>> things simple for the user is very difficult and some times 
>> counterproductive.
>>
>> Lots of people have had the wtf moment when they come along a 
>> multi-polgon consisting of just one ring built from two ways. The 
>> problem is that once the user has split the polygon, there is no 
>> obvious point in time were you can be sure that the user is finished 
>> with it and you could simplify, particularly when you are trying to 
>> get the user to save often and early. So the simplification for the 
>> iD user comes at the expense of wtf's of everybody else.
>>
>> Simon
>>
>> Am 27.10.2020 um 02:05 schrieb Dave F via talk:
>>> Hi
>>>
>>> I don't use iD editor much, but I've just discovered it 
>>> auto-converts closed polygons which are split (Shortcut Key = X) 
>>> into MP relations.
>>>
>>> I'm struggling to comprehend a logical reason for this. Is there 
>>> one? If there's been a previous discussion which I've missed please 
>>> post a link.
>>>
>>> There's a couple of threads on iD's github issues, bhousel closed 
>>> them with "wontfix - I Saw A Thing I Didn't Like (but is valid in OSM).
>>>
>>> It may be valid, but is it desirable or helpful? I split closed 
>>> ways, in P2, for various reasons without wanting them to be 
>>> converted. How many newbies would even know what a MP relation is?
>>>
>>> Having them as as split tagged ways is just as "valid". More so, 
>>> considering splitting long ways is desirable.
>>>
>>> DaveF
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> talk mailing list
>>> talk at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk
>>
>> _______________________________________________
>> talk mailing list
>> talk at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20201029/df687402/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x4721711092E282EA.asc
Type: application/pgp-keys
Size: 4922 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20201029/df687402/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20201029/df687402/attachment-0001.sig>