Organized editing activities in the scope of Mapbox Contribute

Hello!

We would like to give you more information about our activity so we’ve created the following documents to better explain how our team works and how we make changes.

There’s a links to our Github tickets:
• Mapbox Contribute https://github.com/mapbox/mapping/issues/396
• Mapbox Dealerships https://github.com/mapbox/mapping/issues/397

And links to our page in OSM Wiki:
• Mapbox Contribute https://wiki.openstreetmap.org/wiki/Organised_Editing/Activities/Mapbox_Contribute
• Mapbox Dealerships https://wiki.openstreetmap.org/wiki/Organised_Editing/Activities/Mapbox_Dealerships

We would really appreciate your feedback, any questions you have about this project, as well as local insights that will make our work better.

Best regards,
Member of Mapbox team, Anastasiya

Welcome to this forum, Mapbox team!

For mapping in the Netherlands, rather than using global imagery I suggest using national sources, see https://forum.openstreetmap.org/viewtopic.php?id=64644 for more details.

Are there any mapping themes that Mapbox focuses on specifically, like roads or points of interest?

Are you in contact with other organised editing teams, such as TomTom?

That was one of the links Anastasiya shared with us: https://wiki.openstreetmap.org/wiki/Organised_Editing/Activities/Mapbox_Dealerships

TomTom is/has no organized editing team, see for a complete list: https://wiki.openstreetmap.org/wiki/Category:Organised_Editing_Teams

Hi Anastasiya, thanks for sharing this information about your team’s work!

At TomTom we actually do have organised editing activities. They are described on the page Organised Editing/Activities/TomTom. In the overview you mentioned, our page is listed under the letter O because of the “Organised Editing” in the page title.

I apologize, you’re totally right.

This Mapbox changeset drew my attention: https://www.openstreetmap.org/changeset/117810994#map=19/53.19454/5.76552

The obvious error is the (accidental I presume) use of a no-straight-on turn restriction instead of only-straight-on. Congratulations! You just broke traffic in the lovely city of Leeuwarden. :slight_smile:

I assume both relations were intended to be only-straight-on. Based on that assumption: is this correct? I wouldn’t perform a U-turn there, and I wouldn’t recommend anyone else to do so, but is it desirable to place these turn-restrictions there?

The road has dashed lines:

So two questions:

  • Is it legal to perform a turn there?

  • If yes, is it desirable that we map advisory turn-restrictions?

I’m fine either way I think, but this may need some more eyeballs.

Turns kunnen worden verboden door verkeersbord (verplichte rijrichting/keerverbod), pijlen op wegdek, doorgetrokken streep of wegcategorie (autosnelweg/autoweg). Daarnaast kan er een bijzondere praktische reden zijn voor een turnrestrictie vanwege wegontwerp (scherpe hoek in stoeprand in plaats van ronde bocht die het praktisch onmogelijk maakt om bocht te nemen - wel of niet legaal afhankelijk van je interpretatie van art. 5 Wegenverkeerswet) of situatie (kan bijv. niet keren op wisselbaan omdat die nooit in beide richtingen tegelijk open is). Op basis van jouw beschrijving is geen van beide hier van toepassing.

No (except for special cases as mentioned above). The introduction of the wiki page mentions that default driving behaviour in a jurisdiction should not be mapped with turn restrictions.

Indeed it is straightforward for pathfinder applications to prohibit or penalise such turns based on their sharp angle (possibly combined with highway=* value).

Hello! Thank you for paying attention to that case, it was a one-time incident, we took into account your comment!
and thank you JeroenvanderGun for the clear explanation, it’s very helpful!
We are happy to work with such an attentive and loyal community as you :slight_smile:

I’m sure the use of the wrong turn-restriction was a simple error; those happen, that’s fine. We’ll spot them eventually.

Adding these restrictions where turning is actually illegal, like here, is fine too.

The underlying question here now is not about the accidental mistake of using no-straight-on instead of only-straight-on, but about the nature of this class of edits. The same thing is done here for a road that doesn’t even have a centre line. The point is that turning there is not illegal, and a turn restriction should probably not be used at all in that case.

This node
https://www.openstreetmap.org/node/5974751790
Is on a straight line, the line goes further for 12 meter , this 12 meter should get overtaking=no.
A u-turn is not allowed at that point.

That overcomplicates it a bit. Here; I’ve just moved the split a bit northward. Now it sits at the point where you can make a (really dumb) U-turn.

With a small car you may be able to easily make that u-turn. Tagging turn restrictions without legal reasons (or obvious physical ones, i.e. clearly designed to disallow certain turns), should not be done in my opinion.

I got the advice to use" no_u_turn" and not 'only_straight_on".

Because the white line is a prohibition (verbod) for not making a u-turn.
There is no command (gebod) for only straight on.
The prohibition should be applied.

Only 1 relation is needed because of the lanes get oneway=yes.

Per Lanes wiki the split node should be at the “puntstuk”. In this case the dashed line connects directly to the “puntstuk”, so no need for an overtaking=no segment. (If there would be a very short overtaking=no segment, I wouldn’t bother with a u-turn restriction.)

If you want to it perfectly mapped with lanes=* and placement=* you need (per the wiki) three sections: one combined (as it is now), one short transitional section tagged with placement=transition from just about where I split the road to the ‘puntstuk’, and then continue with the two separate lanes.

But that’s not really necessary here and all this fluff detracts from the main point of contention here that goes unanswered: is Mapbox actively mapping advisory only-straight-on restrictions or is this one mapper repeating the same mistake a few times?

Here’s a Mapbox edit I stumbled upon: https://www.openstreetmap.org/changeset/113529911
For a start, all edits of this user appear to carry the description “tag improvement”, which isn’t very informative. Plus, in this case, the “improvement” consisted in removing the building tag from a building. Hardly an improvement in my book.
I’m not sure how this got triggered (because of leisure=sports_centre?), but that process clearly needs tweaking.

Ik kom nu ook steeds vaker “#mapbox_contribute” edits tegen, die over het algemeen van lage kwaliteit zijn.

Twee voorbeelden:

Voor beide geldt dat het lijkt dat er weinig tot geen controle plaatsvindt bij het mappen van deze POIs. Wat kunnen wij hier het beste aan doen? Ik heb bij deze twee voorbeelden (maar er zijn veel soortgelijke gevallen) een opmerking geplaatst bij de changesets, maar nog geen reactie gehad (ondanks dat de mapper erg actief is).

En deze: https://www.openstreetmap.org/changeset/123084615 + https://www.openstreetmap.org/changeset/123003746 (gebouwgeometrieën aangepast, klopt niet meer met de BAG).
En deze: https://www.openstreetmap.org/changeset/123001648 (gebouwen toegevoegd met BAG tags gekopieerd van ander gebouw, terwijl die er niet eens in staan).

Ik heb mapper gevraagd op de comments en/of hier te reageren.

Aanvulling: bovengenoemde drie change sets zijn inmiddels op mijn verzoek teruggedraaid. Althans, volgens de mapper. Echter zijn bij de tweede alle pandjes met iD verwijderd, inclusief een aantal die uit de BAG kwamen… dit gaat zo niet langer.

Thank you for your attention, politeness and support. Mapper answered to all comments you have done and fixed mistakes. We raised question for team what accuracy and evidence for mapping should be one more time not to do such mistakes.