Stumbled upon this changeset when doing a "small towns"-check (place-nodes with a population and not more than 10 buildings in 800 metres around the node) and found only one (n/52242558).
Has there ever been a check as to the data quality of the import? Was it described in the wiki 16 (!) years ago? The above mentioned node seems to be nowhere near the settlement where 155 people might live o.O

Reverted with changeset/143857330

Hi Yacel,

are there really two locations of fuel in the same street with the same name?

Bonjour obi76,

with this changeset you added the wreck of the RMS Titanic, even though it already exists as a node node/7316994661 that is located closer to the coordinates of the sinking that are common knowledge.

Are there any source material that point to the location of the wreck where you put it?

Glad to hear back from you.

Hi Omar,

Is "." really the name of this shop? This sounds strange?

K

Hallo pox,

du hast hier eine Änderung an der Langestraße gemacht, die so eigentlich nicht gedacht war. Name=Langestraße sollte der offizielle Name sein, alt_name (alternativer Name) wäre mit Lange Straße dafür gut, um diese auch in der Suche finden zu können - vor allem dann wenn der Name lokal manchmal auch so benutzt wird.

Noch ein Hinweis: du schreibst in den Kommentar "Name korrigiert nach Geoportal", ich vermute du meinst das Geoportal von Niedersachsen mit Straßennamen und Hausnummern. Dieses ist von der Lizenz, unter der die Daten veröffentlicht werden, (noch) nicht OSM-kompatibel und darf daher nicht als Grundlage für irgendwelche Änderungen in OSM herangezogen werden.

Gruß Kai

Das Verkehrskonzept, in der source ist "nur" der Modellversuch, endgültig festgelegt wurde die Regelung im Verkehrsentwicklungsplan, abrufbar unter https://www.weyhe.de/portal/seiten/verkehrsentwicklungsplanung-der-gemeinde-weyhe-900000209-21850.html?rubrik=9000014

Bonjour BREYSSE JM,

vous avez ajouté un marquage à l'hippodrome qui coupe la piste 06/24.

Conformément à "Une fonctionnalité, un élément OSM", aeroway=runway et highway=raceway peuvent s'exclure mutuellement. De plus, tous les morceaux ondulés (virages / coins) ne sont probablement pas utilisables comme piste.

Est-ce que j'oublie quelque chose ?

Merci de m'avoir répondu !

Kai

Hi BREYSSE JM,

you added a tagging to the racetrack that intersects the runway 06/24.

In accordance to "One feature, one OSM element" aeroway=runway and highway=raceway might be mutually exclusive. Additionally, all the squiggly bits (turns/corners) are most likely not usable as a runway.

Am I overlooking something?

Thanks for getting back to me!

Kai

#MapillaryCleanup

I honestly don't know how to respond to this. The only sensible idea on how to do this the next time came from the community post I made https://community.openstreetmap.org/t/begin-of-automated-edit-for-mapillary-key/3426/6.

Me personally, I wouldn't use is_in because, as the wiki states, "In some regions, where all administrative boundaries are fully mapped, this tag is no longer required. " so that wouldn't be a workable indicator either.

After the amount of backlash against changesets that where "too large" for someone's taste, I don't think that that would have been a wise choise, apart from 3 countries having more than 10k changes (according the HDYC), so they would have had to been split again.

I am very sorry that you do not agree with the way this change is performed. Next time, I will find a better way to get on about this.

K

Hi,

first of all I didn't "just" change that too, because it wasn't part of the discussion around this automated edit. There have been lots of discussions around the edit in the first place - whether to do it or not - and I am NOT going to simply change that without a proper community-discussion.

Secondly, it's a whole different level of effort to get the affected objects (because there are those that have an image tag with an old link but not a mapillary value), so the whole process of finding the right objects starts all over again.

I will do this in due time.

Kai

Hi maraf24,

the user that created this object has the habit of adding the image URL - I guess there are quite a few that have mapillary images that don't work any longer.

Whenever the "main" edit is done, I will ask everyone how the images tag shall be handled, thanks for reminding me :)

Hi,

you might be right, but there is nothing wrong with the script.

The script does exactly one thing: Change the ID of the "mapillary" key from the old to the new ID. Somebody mistook the red thingy for a fire_hydrant and mapped it according to the picture (alas, it's unwise to do so if one has never been in the area).

Just delete the object if it doesn't exist, I don't mind, but the script is working as intended. The source data is obviously off from the real world.

Hello Marc,

also, to add insult to injury, I have not found any pattern at to how they might habe been group geographically. So, if a CS contained, say, 50 objects, they might have been all over the globe resulting in CSs with large bounding boxes, something that's also detested by the OSM community.

The only other way would have been to add even more data duplication, get the bounding boes of all objects in the todo-database and figure out a way to change those that are in a 100 km² area - which might have resulted in changesets containing just 1 or several thousands of objects.

I might have overlooked the obviously best solution - but can't see it right now. Yes, a changeset for every old ID might be excessive, but it was my best idea for now.

Kai

Hello Marc,

The discussion on the mailing list is linked from the Wiki (I don't have it to hand right now).

There was no input on how to accurately merge changes.

The reason you see an per-object changeset is that there are quite a lot of objects with a unique id and the bot starts at the lowest number of objects per one Id.

Later changesets will contain more obejcts with the same Id.

Kai

Hi GPar, thanks for pointing this out.
In the mapillary image from 2020, where this node was changed to a traffic light (https://www.mapillary.com/app/?pKey=642385810051599) there's still a traffic light to be seen, in photo from 2021 (https://www.mapillary.com/app/?pKey=930665197502104) it looks like the complete street layout has changed.
I am not a local, this change was made by a script that updated the mapillary value only.
If you are in the area, please correct the mapping around here accordingly, thanks!
Kai

Hi!

You added a strange mapillary value to node/9528124545 that to me doesn't look like it would be working with any of the URLs of mapillary.

Would you please check that? Maybe a copy&paste oversight?

Thanks.

Kai

Hi Rico and thanks for answering.
You're probably right, the account is never going to answer.
When opening the shop's homepage they still show their address as being in that street, so I guess that was also just a fluke.
I have reverted the changeset (with changeset/127231799).

Good morning,

I don't see what you want to tell me with linking the wiki article.

The article clearly shows that the key in question is supposed to have mapillary's image ID. This ID is now numerical instead of alpha-numerical, which this script changed.

Please elaborate what your issue is with this change.

Thank you.