[talk-au] turn restrictions discussion
Dian Ågesson
me at diacritic.xyz
Sun May 1 03:17:08 UTC 2022
Hi Anthony,
I'm not particularly interested in previous disagreements, so I'm not
going to wade into this other "bus stop" issue.
It is clear that there is a disconnect between what you understand these
edits are doing to routing algorithms, and what the other editors are
explaining is happening. In particular, the method you are using to
model intersections (using separate ways for turns where no physical
separation) is causing extra complexity and errors. The wiki is a good
place to start for more detail, as is
https://labs.mapbox.com/mapping/mapping-for-navigation/modeling-intersections-for-map-navigation/
I am happy to spend time going into this in more detail, but mailing
lists tend to be a bad forum for really detailed conversation and these
resources are a good start.
Dian
On 2022-05-01 02:50, Anthony Panozzo wrote:
> What that luke person was talking about was a bus stop node upgrade
> which took place a few months ago, the kids on discord argued that
> there might be a 1 in million "edge case" which will ruin the map, so
> my mass edit was reverted and they have to be edited individually, now
> the same people came out of nowhere because they see me posting here
> and argue that this guy is free to go about clicking buttons based on
> the validator and there will never ever be an edge case scenario. With
> these kids it's personal they don't make any sense and that's why that
> kids decided to come in here and bring up bus stops lmao.
>
> From: talk-au-request at openstreetmap.org
> Sent: Saturday, 30 April 2022 10:55 PM
> To: talk-au at openstreetmap.org
> Subject: Talk-au Digest, Vol 178, Issue 57
>
> Send Talk-au mailing list submissions to
> talk-au at openstreetmap.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.openstreetmap.org/listinfo/talk-au
> or, via email, send a message with subject or body 'help' to
> talk-au-request at openstreetmap.org
>
> You can reach the person managing the list at
> talk-au-owner at openstreetmap.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Talk-au digest..."
>
> Today's Topics:
>
> 1. Re: Talk-au Digest, Vol 178, Issue 55
> (Andy Townsend (ajt1047 at gmail.com))
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 30 Apr 2022 14:21:34 +0100
> From: "Andy Townsend (ajt1047 at gmail.com)" <ajt1047 at gmail.com>
> Cc: talk-au at openstreetmap.org
> Subject: Re: [talk-au] Talk-au Digest, Vol 178, Issue 55
> Message-ID:
> <CAPptsBSETC17tVGc9RY3j+Z77Z7rXgUW+C0WP85hAEcBiyC38g at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I suspect that no-one is taking the piss - depending on the mail client
> "reply all" will very often go to the sender cc the list.
>
> Perhaps a bit more discussion about what problems have been created
> might
> have helped (and "source=knowledge") isn't a great description of why
> something was changed, but to an outsider it does look like a couple of
> rounds of polite questions were mossing before the "wtf is going on" on
> https://www.openstreetmap.org/changeset/120344373#map=19/-34.76638/138.58995
> .
>
> Where there are turn restrictions missing something vital like "from"
> or
> "to" sometimes it's obvious what needs to be re-added, and sometimes
> actually deleting it is just fine because other tags (such as oneway)
> are
> doing the same job.
>
> Where you think a turn restriction has been deleted in error, perhaps
> it
> would help to comment why that was in error?
>
> On Sat, 30 Apr 2022, 13:18 Anthony Panozzo, <panozz at outlook.com> wrote:
>
>> Im not it?s 100% true, youre the one taking the piss by jumping in
>> this
>> conversation and just speaking on behalf of the other person involved
>> when
>> the matter was already discussed and sorted. Please do not email me
>> directly
>>
>>
>>
>>
>>
>>
>>
>> *From: *talk-au-request at openstreetmap.org
>> *Sent: *Saturday, 30 April 2022 9:41 PM
>> *To: *talk-au at openstreetmap.org
>> *Subject: *Talk-au Digest, Vol 178, Issue 55
>>
>>
>>
>> Send Talk-au mailing list submissions to
>> talk-au at openstreetmap.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://lists.openstreetmap.org/listinfo/talk-au
>> or, via email, send a message with subject or body 'help' to
>> talk-au-request at openstreetmap.org
>>
>> You can reach the person managing the list at
>> talk-au-owner at openstreetmap.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Talk-au digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: Talk-au Digest, Vol 178, Issue 48 (Luke Stewart)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Sat, 30 Apr 2022 22:07:00 +1000
>> From: Luke Stewart <suburbansilvervlogs at gmail.com>
>> To: Anthony Panozzo <panozz at outlook.com>
>> Cc: OSM Australian Talk List <talk-au at openstreetmap.org>
>> Subject: Re: [talk-au] Talk-au Digest, Vol 178, Issue 48
>> Message-ID:
>> <CABO5kcyjkTJtd=t5XtT1N72L+B1wS_-Z=
>> 3+dC4UvT_K62zZEMQ at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Can someone else please confirm that this guy is just taking the piss?
>>
>> Cheers,
>> Luke
>>
>> On Sat, 30 Apr 2022 at 21:58, Anthony Panozzo <panozz at outlook.com>
>> wrote:
>>
>>> I didn?t realise you emailed me directly I am going to have to block
>>> you
>>> from doing so in the future, it?s against OSM au-talk policy
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From: *Luke Stewart <suburbansilvervlogs at gmail.com>
>>> *Sent: *Saturday, 30 April 2022 9:21 PM
>>> *To: *Anthony Panozzo <panozz at outlook.com>; OSM Australian Talk List
>>> <talk-au at openstreetmap.org>
>>> *Subject: *Re: [talk-au] Talk-au Digest, Vol 178, Issue 48
>>>
>>>
>>>
>>> "TheSwavu has already said he deleted it because the validator told
>>> him
>>> to" - What's most likely is that the validator located a relation
>>> that
>> was
>>> incorrect, and he determined that he should delete it. Alternatively,
>>> it
>>> could have been added back. Regardless, the relation was
>>> non-functional
>> and
>>> that is obvious given the single member
>>>
>>> "have you figured out how to route bus stops with out the platform
>>> tag
>>> yet" - Stops should have a platform tag, either on the node or the
>>> area
>>> that is the platform, but mass adding them still remains incorrect as
>>> has
>>> been discussed ad nauseam
>>>
>>> "a bunch of people who all have the same opinion and wont listen to a
>> word
>>> im saying" - This is not always the case, however if everybody else
>>> has a
>>> contrary opinion that may be an indication that you don't understand
>>> what
>>> we are saying or why you are incorrect
>>>
>>>
>>>
>>> So if you want to add the no-u-turn relation on the freeway off-ramp,
>> then
>>> go for it, but it was non-functional to begin with. And a side-note,
>>> I am
>>> yet to see a validator that says "delete it, it's wrong". It most
>>> likely
>>> would say that there is an incorrect number of members, which then
>> provides
>>> a mapper with two options on how to proceed and fix it.
>>>
>>>
>>>
>>> Please provide an example of where the routing is still incorrect, in
>>> a
>>> way that TheSwavu has 'broken' by using a validator. It is possible
>>> that
>>> deleting the relation, rather than re-adding the two missing members,
>>> was
>>> the wrong decision. However, it is also the case that you yourself
>>> broke
>>> the relation (again, perhaps inadvertently), within 24 hours of first
>>> adding it.
>>>
>>>
>>>
>>> P.S., make sure to use 'reply all', so that the message gets
>>> cross-posted
>>> to talk-au.
>>>
>>>
>>> Cheers,
>>>
>>> Luke
>>>
>>> On Sat, 30 Apr 2022 at 21:03, Anthony Panozzo <panozz at outlook.com>
>> wrote:
>>>
>>> Luke,
>>>
>>>
>>>
>>> TheSwavu has already said he deleted it because the validator told
>>> him
>>> to, it wasn?t based on local knowledge or intersection rules. And
>>> have
>> you
>>> figured out how to route bus stops with out the platform tag yet? Do
>>> you
>>> now understand the whole bus stop thing was about routing in the
>>> first
>>> place? OMG it?s like Im speaking to a bunch of people who all have
>>> the
>> same
>>> opinion and wont listen to a word im saying.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From: *Luke Stewart <suburbansilvervlogs at gmail.com>
>>> *Sent: *Saturday, 30 April 2022 7:59 PM
>>> *To: *Graeme Fitzpatrick <graemefitz1 at gmail.com>
>>> *Cc: *Anthony Panozzo <panozz at outlook.com>; talk-au at openstreetmap.org
>>> *Subject: *Re: [talk-au] Talk-au Digest, Vol 178, Issue 48
>>>
>>>
>>>
>>> This is taken directly from the OpenStreetMap website. If you can not
>>> see
>>> the problem with it, and why TheSwavu deleted it, then I suggest you
>>> familiarise yourself with the documentation:
>>> https://wiki.openstreetmap.org/wiki/Relation:restriction#Examples
>>>
>>> Version #2
>>> fixed intersection routing
>>>
>>> Edited about 2 months ago by slice0 ? Changeset #118293106
>>>
>>> Tags
>>> restriction no_u_turn
>>> type restriction
>>>
>>>
>>> *Members 1 member Node 6357628400 as via*
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sat, 30 Apr 2022 at 20:25, Luke Stewart <
>> suburbansilvervlogs at gmail.com>
>>> wrote:
>>>
>>> I genuinely can't tell if you are being straightforward with the
>>> community, or attempting to rouse trouble because it is amusing to
>>> you. I
>>> guarantee I am not the only one who has this opinion. Several other
>>> mappers, including TheSwavu himself, have already provided in-depth
>>> explanations of their (correct) reasoning on this talking list.
>>>
>>>
>>>
>>> iD has a habit of breaking relations. One of the u-turn relations
>>> that
>> you
>>> commented on was broken *by you* within a day of you adding it (aka,
>>> it
>>> lost two of its members), making it unusable for routing.
>>> Fundamentally
>> the
>>> validators are looking at the OSM data verbatim, without the lens of
>>> presets or a GUI, and it is quite simple: if a turn restriction does
>>> not
>>> have at least 3 members (from, via, to), then it is definitionally
>> invalid,
>>> unusable for routers, and requires correction as TheSwavu did in this
>> case.
>>>
>>>
>>>
>>> OpenStreetMap, whilst it does favour local knowledge, also values
>>> remote
>>> edits, particularly when it is (generally) simple to solve, like in
>>> the
>>> case of these edits.
>>>
>>>
>>>
>>> There was a long, drawn out community discussion across multiple
>> platforms
>>> with the mass edit of Australian bus stops. To me, this feels like a
>>> very
>>> similar situation. It seems like you don't quite understand the
>>> purpose
>> of
>>> OpenStreetMap, or how validators, tools, and other programs interact
>>> with
>>> it. OpenStreetMap is designed to work across a myriad of platforms
>>> and
>>> devices, not a single router or renderer.
>>>
>>>
>>>
>>> Whilst on this point, concerns have been raised about your mapping of
>>> intersections, by adding diagonal ways (see this as an example, which
>>> apparently has 69 turn restriction relations:
>>> https://www.openstreetmap.org/#map=19/-34.77083/138.63419). Perhaps
>>> the
>>> community can also agree that this is clearly incorrect
>>>
>>> I suggest that you attempt to interact with fellow mappers in an
>>> appropriate and constructive manner, particularly given this is not
>>> the
>>> first situation like this. We are all working on a community project
>>> with
>>> good intentions, and this sort of interaction isn't helpful to
>>> anyone.
>>>
>>>
>>>
>>> Cheers,
>>> Luke
>>>
>>>
>>>
>>> On Sat, 30 Apr 2022 at 16:02, Graeme Fitzpatrick
>>> <graemefitz1 at gmail.com>
>>> wrote:
>>>
>>> Anthony
>>>
>>>
>>>
>>> Could I suggest that you check keepright for your area:
>>>
>> https://www.keepright.at/report_map.php?zoom=14&lat=-33.87613&lon=151.17154
>> [1]
>>> (Defaults to Sydney) & look at the "Restrictions" & "Geometry
>>> Glitches"
>>> reports.
>>>
>>>
>>>
>>> These will show spots that the system considers are in error, & will
>>> also
>>> allow you to advise that the error is a false positive, if you
>>> consider
>>> that what is shown is OK.
>>>
>>>
>>>
>>> Thanks
>>>
>>>
>>>
>>> Graeme
>>>
>>>
>>>
>>>
>>>
>>> On Sat, 30 Apr 2022 at 15:42, Anthony Panozzo <panozz at outlook.com>
>> wrote:
>>>
>>> Diaz, i?m sorry I can?t sympathise with these excuses ?it?s not me it
>>> the
>>> validator? the bottom line is that this user is breaking perfectly
>>> fine
>>> routing all for the sake of some crappy validator gives him a pat on
>>> the
>>> back because it says so, that is irresponsible and foolish editing
>>> and
>>> deserves no credit for simply saying the validator told me so, it?s
>>> basically bot editing using that excuse, I will be watching all edits
>> this
>>> guy makes from now on and will be reporting every single edit he
>>> makes
>> that
>>> breaks routing to the DWG and by the report button itself on the user
>> page,
>>> then he can explain himself there
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:* talk-au-request at openstreetmap.org <
>>> talk-au-request at openstreetmap.org>
>>> *Sent:* Saturday, April 30, 2022 2:35:26 PM
>>> *To:* talk-au at openstreetmap.org <talk-au at openstreetmap.org>
>>> *Subject:* Talk-au Digest, Vol 178, Issue 48
>>>
>>>
>>>
>>> Send Talk-au mailing list submissions to
>>> talk-au at openstreetmap.org
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> https://lists.openstreetmap.org/listinfo/talk-au
>>> or, via email, send a message with subject or body 'help' to
>>> talk-au-request at openstreetmap.org
>>>
>>> You can reach the person managing the list at
>>> talk-au-owner at openstreetmap.org
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of Talk-au digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>> 1. Re: Talk-au Digest, Vol 178, Issue 46 (Dian ?gesson)
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Sat, 30 Apr 2022 15:04:05 +1000
>>> From: Dian ?gesson <me at diacritic.xyz>
>>> To: OSM Australian Talk List <talk-au at openstreetmap.org>
>>> Subject: Re: [talk-au] Talk-au Digest, Vol 178, Issue 46
>>> Message-ID: <06b0964db149a5343954af20fe2e33dd at diacritic.xyz>
>>> Content-Type: text/plain; charset="us-ascii"; Format="flowed"
>>>
>>>
>>>
>>> Hi Anthony,
>>>
>>> I can sympathise with your sense of frustration. It does feel
>>> irritating
>>> when you feel as though your work is being undermined or broken. I
>>> know
>>> I've spent a lot of time making changes for better routing, only to
>>> find
>>> the same errors get reintroduced.
>>>
>>> I think your frustration is misdirected at Andrew here, though. If
>>> validation tools are detecting issues with some data, someone will
>>> eventually notice and try to fix it; whether it be Andrew or some
>>> other
>>> editor. In a collaborative, decentralised community it isn't possible
>>> to
>>> stop other editors from making changes in an area.
>>>
>>> In this specific case, these errors are a result of problems using
>>> the
>>> iD editor which create "orphaned" relations that would not be used in
>>> routing anyway. Andrew has indicated that he isn't trying to undo the
>>> changes that have been added, rather to resolve the validation
>>> errors.
>>>
>>> I've created a few of these errors myself inadvertently, and it
>>> wasn't
>>> until I started to use JOSM that I realised how much easier and more
>>> powerful that tool can be. If you are spending hours trying to get
>>> these
>>> restrictions perfect, I'd strongly recommend giving that a try.
>>>
>>> Both Andrew and yourself are trying to improve the quality of the
>>> map,
>>> and no one benefits when frustrations boil over in this way. It's
>>> better
>>> to try and work together constructively so we can all spend more time
>>> doing the fun stuff. :)
>>>
>>> Dian
>>>
>>> On 2022-04-30 14:20, Anthony Panozzo wrote:
>>>
>>> Let me put it this way, it very easy for you to come along with your
>>> validator toll and get on your high horse and point out how trash
>>> some
>>> routing edits are... but you have no clue at all how much effort it
>>> take
>>> to get some intersections functioning as intended as per the rule of
>>> the
>>> intersection, the one you pointed out was pretty simple and was
>>> functioning 100% correctly before you touched it now it allows
>>> u-turns,
>>> you're pointing out the tiny issue that your validator points out but
>>> what you don't realize is that the validator doe not see the big
>>> picture
>>> either, its pretty much just pointing out conflicting restrictions
>>> which
>>> are even sometimes left in intentionally, this is not the first time
>>> ive
>>> ran into your edits but I have had enough of it, it takes a lot more
>>> knowledge and effort to get them working as intended per the rules
>>> than
>>> for you to come along with your little tool, if you personally don't
>>> know the intended routing and can't see any errors using the routing
>>> engine itself LEAVE IT ALONE, OSM is only meant to be edited by
>>> people
>>> with local knowledge of the areas, I put a lot of time into what I do
>>> including random routing on my gps to see what it will throw at me, I
>>> do
>>> not need to be worry about you and your tool coming along to destroy
>>> it.
>>> I am not proff reading this so sorry if there are spelling errors!
>>>
>>> From: talk-au-request at openstreetmap.org
>>> Sent: Saturday, 30 April 2022 1:33 PM
>>> To: talk-au at openstreetmap.org
>>> Subject: Talk-au Digest, Vol 178, Issue 46
>>>
>>> Send Talk-au mailing list submissions to
>>> talk-au at openstreetmap.org
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> https://lists.openstreetmap.org/listinfo/talk-au
>>> or, via email, send a message with subject or body 'help' to
>>> talk-au-request at openstreetmap.org
>>>
>>> You can reach the person managing the list at
>>> talk-au-owner at openstreetmap.org
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of Talk-au digest..."
>>>
>>> Today's Topics:
>>>
>>> 1. iD and turn restrictions (Was:Re: Talk-au Digest, Vol 178,
>>> Issue 44) (Andrew Davidson)
>>> 2. Re: iD and turn restrictions (Was:Re: Talk-au Digest, Vol
>>> 178, Issue 44) (Andrew Davidson)
>>> 3. Re: iD and turn restrictions (Was:Re: Talk-au Digest, Vol
>>> 178, Issue 44) (Phil Wyatt)
>>> 4. FW: Talk-au Digest, Vol 178, Issue 44 (Phil Wyatt)
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Sat, 30 Apr 2022 11:53:53 +1000
>>> From: Andrew Davidson <theswavu at gmail.com>
>>> To: talk-au at openstreetmap.org
>>> Subject: [talk-au] iD and turn restrictions (Was:Re: Talk-au Digest,
>>> Vol 178, Issue 44)
>>> Message-ID: <9d7c85e4-257e-f7b0-bd48-bf425c9c30ff at gmail.com>
>>> Content-Type: text/plain; charset=UTF-8; format=flowed
>>>
>>> On 30/4/22 00:45, Anthony Panozzo wrote:
>>>
>>> > This account is either a bot account or someone that thinks they know
>>> > more than they actually do, every single time anybody does a routing
>>> > correction this account comes along and ?fixes? it based on ?knowledge?
>>>
>>> Some terminology before we start. To be valid a turn restriction
>>> relation needs to have:
>>>
>>> 1. A way with the role "from"
>>> 2. A way with the role "to"
>>> 3. One or more "via" s that can be either a node or one or more ways
>>> 4. The members must connect in a way that you can travel
>>>
>>> When I say "broken" I mean that one of the rules is broken and when I
>>> say "knowledge" I mean I know what a valid turn restriction should
>>> be.
>>>
>>> > from the notes, let me just say I looked over some of the edit this
>>> > account does and it breaks the routing for the most part, Changeset:
>>> > 120344373 | OpenStreetMap
>>>
>>> This changeset deleted this turn restriction:
>>>
>>> https://osm.mapki.com/history/relation/13905961
>>>
>>> which you added in changeset 118257827 and then broke in 118293106
>>> (it
>>> only had a node via member). When I reviewed this one I decided to
>>> delete it because it would only duplicate this turn restriction:
>>>
>>> https://osm.mapki.com/history/relation/14044389
>>>
>>> which you added in changeset 119769921, if I fixed it.
>>>
>>> > <https://www.openstreetmap.org/changeset/120344373> and Changeset:
>>> > 120198383 | OpenStreetMap
>>>
>>> This intersection had 15 broken turn restriction relation in it:
>>>
>>> https://osm.mapki.com/history/relation/13477255
>>> https://osm.mapki.com/history/relation/13477256
>>> https://osm.mapki.com/history/relation/13477257
>>> https://osm.mapki.com/history/relation/13477258
>>> https://osm.mapki.com/history/relation/13477260
>>> https://osm.mapki.com/history/relation/13477261
>>> https://osm.mapki.com/history/relation/13477263
>>> https://osm.mapki.com/history/relation/13477268
>>> https://osm.mapki.com/history/relation/13477269
>>> https://osm.mapki.com/history/relation/13557714
>>> https://osm.mapki.com/history/relation/13761157
>>> https://osm.mapki.com/history/relation/13761161
>>> https://osm.mapki.com/history/relation/13761169
>>> https://osm.mapki.com/history/relation/13761170
>>> https://osm.mapki.com/history/relation/13991446
>>>
>>> You broke 14 and added one new broken relation (13991446). While I
>>> was
>>> deleting these I noticed that the intersection had some sort of
>>> cross-your-heart thing going on with added ways for turn lanes, so I
>>> simplified it to a standard traffic light box intersection:
>>>
>>> https://www.openstreetmap.org/#map=19/-34.76387/138.59277
>>>
>>> You can turn right from each arm which means we don't have to have
>>> any
>>> no-right turns. There are 4 no-left turns because each approach has a
>>> slip lane. Since it's SA and at traffic lights then there are four no
>>> u-turns to cover that. This is exactly the same routing information
>>> that
>>> was there before, but now in a simpler easier to maintain format.
>>>
>>> > <
>>>
>> https://www.openstreetmap.org/changeset/120198383#map=17/-34.76452/138.59301
>> [2]
>>> >
>>> > are two examples of this account breaking routing, ive been wasting my
>>> > time spending hours and hours fixing routing just for this shitty bot
>>> > to
>>> > come along and fuck it all up over and over again, I would like to ask
>>> > DWG to take a real close look at this account and see if it can be
>>> > banned from any further edits under the bot edit policy or straight out
>>> > vandalism!
>>>
>>> I am not a bot. Just a mapper with overpass, the JOSM validator, the
>>> to-do plugin, and many hours of puzzling over the question of what a
>>> broken turn restriction relation was supposed to be doing.
>>>
>>> A couple of years ago I spent quite a bit of time fixing all the turn
>>> restrictions around AU, but I have to keep coming back every couple
>>> of
>>> months, as 100-200 newly broken ones get created every month. Mostly
>>> because iD will quietly break existing turn restrictions or let you
>>> create invalid ones and then upload them to OSM. I used to put
>>> changeset
>>> comments on the ones that had broken them until a user asked me how
>>> they
>>> could stop doing it and I discovered that there isn't a way to do
>>> that
>>> in iD.
>>>
>>> My fixes should not be changing any routing outcomes as they are
>>> almost
>>> all deleting turn restrictions that iD didn't clean up after a mapper
>>> reconfigured an intersection. None of the examples you have pointed
>>> to
>>> have changed the routing outcomes as I check to make sure I
>>> understand
>>> what someone was trying to map before I fix it.
>>>
>>> ------------------------------
>>>
>>> Message: 2
>>> Date: Sat, 30 Apr 2022 12:25:31 +1000
>>> From: Andrew Davidson <theswavu at gmail.com>
>>> To: OpenStreetMap <talk-au at openstreetmap.org>
>>> Subject: Re: [talk-au] iD and turn restrictions (Was:Re: Talk-au
>>> Digest, Vol 178, Issue 44)
>>> Message-ID:
>>>
>>> <CACXR7K1Ujx2WQZF5nsGxrD+6CRp-Upx7MPaSjsvLOGg5de9xEA at mail.gmail.com>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> On Sat, 30 Apr 2022, 11:53 Andrew Davidson, <theswavu at gmail.com>
>>> wrote:
>>>
>>> >
>>> > https://osm.mapki.com/history/relation/14044389
>>> >
>>> >
>>> > Cut and paste error there. The existing no u-turn restriction is:
>>> https://osm.mapki.com/history/relation/13909088
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL:
>>> <
>>>
>> http://lists.openstreetmap.org/pipermail/talk-au/attachments/20220430/418ba850/attachment-0001.htm
>> [3]
>>> >
>>>
>>> ------------------------------
>>>
>>> Message: 3
>>> Date: Sat, 30 Apr 2022 13:53:14 +1000
>>> From: "Phil Wyatt" <phil at wyatt-family.com>
>>> To: "'Andrew Davidson'" <theswavu at gmail.com>,
>>> <talk-au at openstreetmap.org>
>>> Subject: Re: [talk-au] iD and turn restrictions (Was:Re: Talk-au
>>> Digest, Vol 178, Issue 44)
>>> Message-ID: <000d01d85c45$d472c5e0$7d5851a0$@wyatt-family.com>
>>> Content-Type: text/plain; charset="UTF-8"
>>>
>>> Many thanks for the detailed explanation
>>>
>>> -----Original Message-----
>>> From: Andrew Davidson <theswavu at gmail.com>
>>> Sent: Saturday, 30 April 2022 11:54 AM
>>> To: talk-au at openstreetmap.org
>>> Subject: [talk-au] iD and turn restrictions (Was:Re: Talk-au Digest,
>>> Vol
>>> 178, Issue 44)
>>>
>>> On 30/4/22 00:45, Anthony Panozzo wrote:
>>>
>>> > This account is either a bot account or someone that thinks they know
>>> > more than they actually do, every single time anybody does a routing
>>> > correction this account comes along and ?fixes? it based on ?knowledge?
>>>
>>> Some terminology before we start. To be valid a turn restriction
>>> relation needs to have:
>>>
>>> 1. A way with the role "from"
>>> 2. A way with the role "to"
>>> 3. One or more "via" s that can be either a node or one or more ways
>>> 4.
>>> The members must connect in a way that you can travel
>>>
>>> When I say "broken" I mean that one of the rules is broken and when I
>>> say "knowledge" I mean I know what a valid turn restriction should
>>> be.
>>>
>>> > from the notes, let me just say I looked over some of the edit this
>>> > account does and it breaks the routing for the most part, Changeset:
>>> > 120344373 | OpenStreetMap
>>>
>>> This changeset deleted this turn restriction:
>>>
>>> https://osm.mapki.com/history/relation/13905961
>>>
>>> which you added in changeset 118257827 and then broke in 118293106
>>> (it
>>> only had a node via member). When I reviewed this one I decided to
>>> delete it because it would only duplicate this turn restriction:
>>>
>>> https://osm.mapki.com/history/relation/14044389
>>>
>>> which you added in changeset 119769921, if I fixed it.
>>>
>>> > <https://www.openstreetmap.org/changeset/120344373> and Changeset:
>>> > 120198383 | OpenStreetMap
>>>
>>> This intersection had 15 broken turn restriction relation in it:
>>>
>>> https://osm.mapki.com/history/relation/13477255
>>> https://osm.mapki.com/history/relation/13477256
>>> https://osm.mapki.com/history/relation/13477257
>>> https://osm.mapki.com/history/relation/13477258
>>> https://osm.mapki.com/history/relation/13477260
>>> https://osm.mapki.com/history/relation/13477261
>>> https://osm.mapki.com/history/relation/13477263
>>> https://osm.mapki.com/history/relation/13477268
>>> https://osm.mapki.com/history/relation/13477269
>>> https://osm.mapki.com/history/relation/13557714
>>> https://osm.mapki.com/history/relation/13761157
>>> https://osm.mapki.com/history/relation/13761161
>>> https://osm.mapki.com/history/relation/13761169
>>> https://osm.mapki.com/history/relation/13761170
>>> https://osm.mapki.com/history/relation/13991446
>>>
>>> You broke 14 and added one new broken relation (13991446). While I
>>> was
>>> deleting these I noticed that the intersection had some sort of
>>> cross-your-heart thing going on with added ways for turn lanes, so I
>>> simplified it to a standard traffic light box intersection:
>>>
>>> https://www.openstreetmap.org/#map=19/-34.76387/138.59277
>>>
>>> You can turn right from each arm which means we don't have to have
>>> any
>>> no-right turns. There are 4 no-left turns because each approach has a
>>> slip lane. Since it's SA and at traffic lights then there are four no
>>> u-turns to cover that. This is exactly the same routing information
>>> that
>>> was there before, but now in a simpler easier to maintain format.
>>>
>>> > <https://www.openstreetmap.org/changeset/120198383#map=17/-34.76452/13
>>> > 8.59301> are two examples of this account breaking routing, ive been
>>> > wasting my time spending hours and hours fixing routing just for this
>>> > shitty bot to come along and fuck it all up over and over again, I
>>> > would like to ask DWG to take a real close look at this account and
>>> > see if it can be banned from any further edits under the bot edit
>>> > policy or straight out vandalism!
>>>
>>> I am not a bot. Just a mapper with overpass, the JOSM validator, the
>>> to-do plugin, and many hours of puzzling over the question of what a
>>> broken turn restriction relation was supposed to be doing.
>>>
>>> A couple of years ago I spent quite a bit of time fixing all the turn
>>> restrictions around AU, but I have to keep coming back every couple
>>> of
>>> months, as 100-200 newly broken ones get created every month. Mostly
>>> because iD will quietly break existing turn restrictions or let you
>>> create invalid ones and then upload them to OSM. I used to put
>>> changeset
>>> comments on the ones that had broken them until a user asked me how
>>> they
>>> could stop doing it and I discovered that there isn't a way to do
>>> that
>>> in iD.
>>>
>>> My fixes should not be changing any routing outcomes as they are
>>> almost
>>> all deleting turn restrictions that iD didn't clean up after a mapper
>>> reconfigured an intersection. None of the examples you have pointed
>>> to
>>> have changed the routing outcomes as I check to make sure I
>>> understand
>>> what someone was trying to map before I fix it.
>>>
>>> _______________________________________________
>>> Talk-au mailing list
>>> Talk-au at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-au
>>>
>>> ------------------------------
>>>
>>> Message: 4
>>> Date: Sat, 30 Apr 2022 14:00:38 +1000
>>> From: "Phil Wyatt" <phil at wyatt-family.com>
>>> To: "OSM-Au" <talk-au at openstreetmap.org>
>>> Subject: [talk-au] FW: Talk-au Digest, Vol 178, Issue 44
>>> Message-ID: <001301d85c46$dc381a40$94a84ec0$@wyatt-family.com>
>>> Content-Type: text/plain; charset="us-ascii"
>>>
>>> From: Phil Wyatt <phil at wyatt-family.com>
>>> Sent: Saturday, 30 April 2022 2:00 PM
>>> To: 'Anthony Panozzo' <panozz at outlook.com>
>>> Subject: RE: [talk-au] Talk-au Digest, Vol 178, Issue 44
>>>
>>> Hi Anthony,
>>>
>>> There are multiple tools out there for finding 'errors' in OSM data
>>> and
>>> many
>>> people use them to keep the OSM data up to date. You might also like
>>> to
>>> share the OSM software that you are using on your vehicle GPS as it
>>> may
>>> turn
>>> out that it doesn't handle relations or routing of some situations.
>>>
>>> Cheers - Phil
>>>
>>> From: Anthony Panozzo <panozz at outlook.com <mailto:panozz at outlook.com
>>> <panozz at outlook.com>> >
>>> Sent: Saturday, 30 April 2022 10:35 AM
>>> To: Phil Wyatt <phil at wyatt-family.com <mailto:phil at wyatt-family.com
>>> <phil at wyatt-family.com>> >
>>> Subject: RE: [talk-au] Talk-au Digest, Vol 178, Issue 44
>>>
>>> The biggest issue I have with this account is that they don't find
>>> routing
>>> errors on their own, this person stalks other peoples edits and
>>> "correcs"
>>> them using knowledge as their source, I find these routing errors
>>> 100%
>>> myself in real world situations, I have been editing and using OSM on
>>> my
>>> car
>>> gps for many years, this user edits other users edits based on no
>>> knowledge
>>> of the intersection at all, having a user like this should put anyone
>>> off
>>> making any routing edits when this person randomly edits 10 different
>>> intersections in 10 minutes and says they have knowledge.
>>>
>>> From: Phil Wyatt <mailto:phil at wyatt-family.com
>>> <phil at wyatt-family.com>>
>>> Sent: Saturday, 30 April 2022 9:44 AM
>>> To: 'Anthony Panozzo' <mailto:panozz at outlook.com
>>> <panozz at outlook.com>> ;
>>> talk-au at openstreetmap.org <mailto:talk-au at openstreetmap.org
>>> <talk-au at openstreetmap.org>>
>>> Subject: RE: [talk-au] Talk-au Digest, Vol 178, Issue 44
>>>
>>> Hi Anthony (slice0),
>>>
>>> Can I suggest the best way to get some resolution is to actually
>>> spell
>>> out
>>> in a changeset comment why you think the change made by Swavu is
>>> incorrect.
>>> That way everyone gets to learn from 'conflicts'. I also suggest you
>>> restrain your language or you may also face the wrath of the DWG.
>>>
>>> PS Swavu is not a bot.
>>>
>>> Cheers - Phil (tastrax)
>>>
>>> From: Anthony Panozzo <panozz at outlook.com <mailto:panozz at outlook.com
>>> <panozz at outlook.com>> >
>>> Sent: Saturday, 30 April 2022 12:46 AM
>>> To: talk-au at openstreetmap.org <mailto:talk-au at openstreetmap.org
>>> <talk-au at openstreetmap.org>>
>>> Subject: Re: [talk-au] Talk-au Digest, Vol 178, Issue 44
>>>
>>> User TheSwavu
>>>
>>> This account is either a bot account or someone that thinks they know
>>> more
>>> than they actually do, every single time anybody does a routing
>>> correction
>>> this account comes along and "fixes" it based on "knowledge" from the
>>> notes,
>>> let me just say I looked over some of the edit this account does and
>>> it
>>> breaks the routing for the most part, Changeset: 120344373 |
>>> OpenStreetMap
>>> <https://www.openstreetmap.org/changeset/120344373> and Changeset:
>>> 120198383 | OpenStreetMap
>>> <
>>>
>> https://www.openstreetmap.org/changeset/120198383#map=17/-34.76452/138.5930
>> [4]
>>> 1> are two examples of this account breaking routing, ive been
>>> wasting
>>> my
>>> time spending hours and hours fixing routing just for this shitty bot
>>> to
>>> come along and fuck it all up over and over again, I would like to
>>> ask
>>> DWG
>>> to take a real close look at this account and see if it can be banned
>>> from
>>> any further edits under the bot edit policy or straight out
>>> vandalism!
>>>
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL:
>>> <
>>>
>> http://lists.openstreetmap.org/pipermail/talk-au/attachments/20220430/d0f732e2/attachment.htm
>> [5]
>>> >
>>>
>>> ------------------------------
>>>
>>> Subject: Digest Footer
>>>
>>> _______________________________________________
>>> Talk-au mailing list
>>> Talk-au at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-au
>>>
>>> ------------------------------
>>>
>>> End of Talk-au Digest, Vol 178, Issue 46
>>> ****************************************
>>>
>>> _______________________________________________
>>> Talk-au mailing list
>>> Talk-au at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-au
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL: <
>>>
>> http://lists.openstreetmap.org/pipermail/talk-au/attachments/20220430/fa430fd0/attachment.htm
>> [6]
>>> >
>>>
>>> ------------------------------
>>>
>>> Subject: Digest Footer
>>>
>>> _______________________________________________
>>> Talk-au mailing list
>>> Talk-au at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-au
>>>
>>>
>>> ------------------------------
>>>
>>> End of Talk-au Digest, Vol 178, Issue 48
>>> ****************************************
>>>
>>> _______________________________________________
>>> Talk-au mailing list
>>> Talk-au at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-au
>>>
>>> _______________________________________________
>>> Talk-au mailing list
>>> Talk-au at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-au
>>>
>>>
>>>
>>>
>>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openstreetmap.org/pipermail/talk-au/attachments/20220430/35932361/attachment.htm
>> [7]
>>>
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: 4BDFEAA66B0849EAB3BD22E2119E4B36.png
>> Type: image/png
>> Size: 144 bytes
>> Desc: not available
>> URL: <
>> http://lists.openstreetmap.org/pipermail/talk-au/attachments/20220430/35932361/attachment.png
>> [8]
>>>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> Talk-au mailing list
>> Talk-au at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-au
>>
>>
>> ------------------------------
>>
>> End of Talk-au Digest, Vol 178, Issue 55
>> ****************************************
>>
>>
>> _______________________________________________
>> Talk-au mailing list
>> Talk-au at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-au
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.openstreetmap.org/pipermail/talk-au/attachments/20220430/4b0a0aab/attachment.htm>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Talk-au mailing list
> Talk-au at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
> ------------------------------
>
> End of Talk-au Digest, Vol 178, Issue 57
> ****************************************
>
> _______________________________________________
> Talk-au mailing list
> Talk-au at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
Links:
------
[1]
https://www.keepright.at/report_map.php?zoom=14&lat=-33.87613&lon=151.17154
[2]
https://www.openstreetmap.org/changeset/120198383#map=17/-34.76452/138.59301
[3]
http://lists.openstreetmap.org/pipermail/talk-au/attachments/20220430/418ba850/attachment-0001.htm
[4]
https://www.openstreetmap.org/changeset/120198383#map=17/-34.76452/138.5930
[5]
http://lists.openstreetmap.org/pipermail/talk-au/attachments/20220430/d0f732e2/attachment.htm
[6]
http://lists.openstreetmap.org/pipermail/talk-au/attachments/20220430/fa430fd0/attachment.htm
[7]
http://lists.openstreetmap.org/pipermail/talk-au/attachments/20220430/35932361/attachment.htm
[8]
http://lists.openstreetmap.org/pipermail/talk-au/attachments/20220430/35932361/attachment.png
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-au/attachments/20220501/31643ca0/attachment-0001.htm>
More information about the Talk-au
mailing list