Mooi dat die nu doorloopt. Ik heb het fietspad en de wal iets verder uitgelijnd op basis van recent beeldmateriaal.

Weet je ook hoe deze bebord is? G13 waarschijnlijk?

Bij Dronryp laat je hem nu aansluiten op een wandelpad. Klopt dat, of komt deze op deze way uit?

way/492116273

I'm not seeing anything weird with those plugins, and those actions on their own shouldn't cause such issues. This may have something to do with your specific runtime environment (Java version, environment variables, operating system, etc.).

I suggest you open an issue via the Report Bug form in the Help menu of JOSM. It helps to mention that this:

"EN 452: Москва => Берлин => Париж"

gets turned into:

"EN 452: Мо�ква => Берлин => Париж"

This is what is called a character encoding issue. The JOSM developer might know under which circumstances JOSM may cause that.

Your edits to this relation (and its reverse) have caused those tags to break a number of times. The chances of more of your edits having issues seems quite high, but may be harder to spot if it is only one letter that gets mangled.

Thanks. Relevant changeset with comments on this recurring problem: changeset/122076941

Can you recall what you did in this case? Which actions? Can you reproduce this. without uploading the result? (ToniE repaired this relation here: changeset/122111923)

What you did in this changeset will break tags in any relation with values in non-ASCII values; this is just a very visible relation spanning a large area. You may have broken quite a few lines of text in over 10,000 edits.

What exactly are you doing in JOSM? Some plugin? JOSM normally doesn't mess up text.

If you get mangled text during normal usage, you have found a serious bug in JOSM that should be reported.

That would just address a symptom, not the cause. This one gets many mappers' attention due to the size of the changeset; there are likely more relations this account thrashes which don't get spotted right away.

A tool that mangles Unicode has no place doing (semi-)automated edits here.

The tool also broke 'Paryż' (Paris) in name:pl, so even without Russian or ongoing connections beyond Poland this is an issue that must be fixed.

This changeset breaks the content of tags containing non-ASCII text (again). If you notice this: the DWG has been contact by me last week, and should be looking into it.

(The owner of this account does not read changeset comments.)

Zitten er bij OBS De Pipegaal meer scholen op dat terrein? Als het maar een school is, dan hoort amenity=school op de outline, en niet op de adresnode. landuse=education is dan niet nodig.

Looks like this problem is back (in the reverse of this train line) after a few edits that didn't break the text:

changeset/121886764

This tool is breaking character encoding of valid tags again. Please fix this!

Yes, if the address node is otherwise unused. In some (rare) cases multiple POI's share the same address, in which case one is merged with the empty address node (if not already done) and the other gets the same four addr: tags copied over.

Only the original address node (merged with the POI) keeps the source=BAG and source:date tags. That shows that it was imported from the authoritative address database.

Novice mappers often add POI's without adding them to the corresponding address node (and sometimes the exact address is unclear), so it's fairly common to see POI's without an address. Thanks for improving the data!

Also: don't add addr:country. It is not needed.

If you add addresses to POI's in the Netherlands, please reuse existing address (empty) nodes. Usually you can merge a POI lacking an address with an empty address node.

All addresses in the Netherlands are imported and updated frequently.

For example: Gino's IJssalon (node/4246778897) should be merged with node/2752227258

Standaard volgens wat precies? Op highway=bus_stop staat niets over bus=yes. Dat is ook nergens voor nodig, want een bus=yes is een access-tag. Die heb je alleen nodig als de bus er anders niet zou mogen komen (bijvoorbeeld een weg met access=no). Dat is doorgaans niet het geval bij highway=bus_stop.

Ik heb beide changesets teruggedraaid hier:

changeset/121795987

Ik heb geprobeerd een aantal fixes die wel kloppen te behouden, maar het is te veel om alles handmatig na te lopen.

Reisinformatiegroep: je mapt rustig door zonder even te reageren. Dat is wel jammer. Je intenties zijn ongetwijfeld goed, maar neem even de tijd om de warnings die tools zoals iD geven te begrijpen. Als een warning in Nederland vaak voorkomt en niet klopt, meldt dat dan op het forum, zodat we dat op kunnen pakken met de ontwikkelaar van iD.

De buurtgrenzen komen deels van de gemeente (via het CBS), en deels op basis van wat logisch is qua bebouwd gebied. Ik denk dat het meeste wel aardig klopt met lokaal gebruik (gezien de lokale websites van verenigingen etc.). Over (Dokkum) Noord ben ik het minst zeker.

En kijk eens goed naar deze luchtfoto:

https://postimg.cc/5jNdXmGg

En kijk nu nog eens naar de service-way die je hier verbindt met die steeg:

way/743811224

Je gaat dwars door het (ingetekende!) hek heen.

bus=yes op highway=bus_stop is ook overbodig.

De waarschuwingen die iD geeft zijn suggesties: het is niet de bedoeling dat je die blind toepast op een gebied. Daarmee verbeter je de data niet.

Brommerdoorsteekjes (way/685112824) mappen we in Nederland als highway=cycleway, niet path.

Die barrier=wall bij het Alvestêdeplein klopt ook niet. Dat zijn blokken, geen muurtjes.