When you deleted way/983659928 and way/983659929, did you also intend to delete relation/13217651 ?

Did you intend to delete way/883243862 ? It was part of relation/12000621 which you did not delete.

Hello, I noticed that you had some `mapwithai:source` tags in this changeset. These tags are not supposed to go into OSM, and the MapWithAI plugin removes the tags when the objects are added to the OSM layer through `Data` -> `MapWithAI` -> `MapWithAI: Add selected data`. The default shortcut for that action is `shift` + `a` (note: after initial install, a JOSM restart may be required for the shortcut to be the default).

If the `MapWithAI: Add selected data` action does *not* work for your workflow, please let me know why, and how it could be fixed.

way/911091504 had `mapwithai:source=MassGIS OpenSpace`. Do you mind telling me what your workflow is/was so I can attempt to fix that issue going forward?

Thanks,
Taylor (JOSM MapWithAI plugin maintainer)

Thank you for telling me how it got into the OSM DataSet. I'll add a bug report to the plugin repo so I can remember to fix it (there was a _lot_ of data with `mapwithai:source`, so it wasn't just you).

No problem. I thought it was probably accidental, but it might not have been. You are a bit more local than I am, after all.

I don't know if you are going to revert the deletions, or just redraw the road, but either way, good luck, and have fun. :)

Did you intend to delete way/449879791? It is still visible on all publicly available imagery. And the deletion definitely does not match your changeset comment.

If you did intend to delete the way, it would have been nice to know why (e.g., the road was razed/demolished).

If that deletion was accidental, were the rest of the ways deleted in this changeset also accidental deletions?

No. This was a case of taking a `name:en` which was a transliteration and moving it to `int_name`, since it was not actually an English translation. I assumed that the user that added the original `name:en` had backing information. This was fairly soon after I started working at Kaart, but I made assumptions based how I had been editing prior to being hired by Kaart. In short, I assumed that information that someone else had added to an object was generally correct, although it might be entered in an incorrect fashion (e.g., `opening_hours=Monday-Friday 8AM to 8PM` or `surface_type=asphalt`).

See changeset/30485569 for the changeset that actually added `name:en=Siru`.

IIRC, you reached out about a similar issue about adding `name:el` tags when `name:en` tags existed. It looks like I may have added a check for transliterated names in `name:en` around the time I was editing this way (edit on 12/3 to add `name:el` since there was a `name:en`, edit on 12/4 to move `name:en` to `int_name`, which would have removed the need for `name:el`).

Hopefully this wall of text answered your question (no, I did not look at images for the int_name) and explain why I made the change. :)

Just out of curiosity, does way/455311233 actually exist? (I don't know why the changeset bounding box doesn't include it, but it was created in this changeset).

Can you please make your changesets more geographically precise? (i.e., if you make modifications in Kentucky and then in one in California, they should not be in the same changeset).

It makes it harder to QC an area with OSMCha (or see editors in an area with OpenStreetMap History) when there are changesets spanning most of the country that only modify three ways and eight nodes.

Don't worry about it.

I've added a validator check to the current release of MapWithAI, so you can update plugins for that.

I'll continue to try to replicate, but it just isn't happening for me. Can you send me a JOSM status report? ( incoming+gokaart-josm-mapwithai-14305243-issue-@incoming.gitlab.com )

I'd prefer one right after it occurs again, if at all possible.

Don't go out of your way to replicate, but if you do see it occurring again, please let me know.

You had an extraneous `conn` tag on node/1276835037. I'm removing it. I *think* that it is probably due to a bug in the MapWithAI plugin, specifically with undo redo, and I'm trying to track it down.

Do you remember what you were doing with this changeset? Did you see any bug report popup from JOSM? What version of the MapWithAI plugin are you using?

Thanks,
Taylor

Source should be "Licencia de Datos Abiertos - Uruguay"

> Greek translations are useless, since the local name is already greek.

I did not translate the name tag to Greek. I copied the name tag to the name:el tag, but only if there was a name:* tag as well. (I initially did this regardless of a name:* tag, but I felt that was too much data churn).

> Please use nothing more than what you see on street signs, which is
> Prefix=*
> name=*
> int_name=*

That is exactly what I did. I didn't add prefix=* (is that even an accepted tag?), but I did add name=name:el=<Greek name on sign> and int_name=<Non-Greek name on sign> (name:el was usually only added when there was another name:* tag on the object).

Here is why I added name:el tags that were the same as name tags:

I add name:el tags partly as a hint to the data consumer (in Greece, I could probably get away with not adding that tag, since they use the Greek alphabet, which looks nothing like Latin characters), but I do consider it best practice, when a name:* tag exists, to make certain that the data consumer knows what language the "name" key is in. It also ensures that if someone comes in and "translates" the name tag (e.g., "Οδός" -> "Street"), the name:el tag will still exist and be used until someone comes along and fixes the translation changeset.

For the record, I used osm.wiki/Names#Localization when using this tagging scheme. In the example, they had the default name as "name" and then the same name in "name:de" (since this is on the sign, it is still valid). This strongly implied (to me) that when a name:* exists, the name value should also exist on one of the name:* tags. In Greece, this was name:el.

Furthermore, osm.wiki/Multilingual_names#Greece follows the same general scheme, which indicated that name:el was optional. At the time I wrote this reply, the naming convention was:

name=* and (optionally) name:el=* name in Greek ("Οδός" is omitted) e.g., "Σταδίου", "Ελευθερίου Βενιζέλου".

int_name=* transcribed name e.g., "Stadiou", "Εleftheriou Venizelou", "Plateia Eleftherias", (ISO 843).

name:en=* (optional): translation of the property only. (names must not be translated) eg. "Πλατεία Ελευθερίας" is translated to "Eleftherias square" and not "Freedom square".

old_name=* (optional): old Greek name; e.g., "Πανεπιστημίου".

In short, if you do not like the tagging scheme I used (where I added name:el tags when a name:* existed), please change/clarify the wiki.

If it helps, I just went through the all of the ways that I modified in this changeset, and someone came in after me and changed many of the name:* to int_name (most of the name:* were name:fr tags, and I don't read French, which is why I didn't touch them). The name:el tags are still valid, so I am not going to remove them, but I wouldn't have added them if I knew for certain that the name:fr tags were really int_name tags. I would have just changed the name:fr to int_name.

I've see that you added lanes, turn:lanes, and destination:lanes to a node. These are typically better expressed on the way itself.
In this case, it looks like you are trying to express the joining/leaving of lanes where the roundabout (which should be tagged as junction=roundabout) and an incoming way join.

That being said, Mapillary street-level imagery from 2019-02-22 does not support the roundabout having four lanes.

I would recommend attaching way/673217256 to node/5890332379 and expanding the roundabout to match the middle of the roundabout in aerial imagery. I would recommend using Maxar Premium Imagery (in iD, the editor you use, you can get it by going to the background icon (keyboard shortcut "b") and selecting "Maxar Premium Imagery (Beta)". Bing imagery tends to be out of date and poorly aligned.

Mapillary imagery: https://www.mapillary.com/app/?lat=40.87470752711111&lng=26.63457548866667&z=17.22655837864439&focus=photo&dateFrom=2017-01-01&pKey=AEjh2GXZ-nc2QFlQTs9Jag

Thank you for contributing, and have a good day,
vorpalblade77-kaart

Note: This is NOT the Ministry of Finance.

`cas` should be `gas`.
---

Published using OSMCha: https://osmcha.mapbox.com/changesets/67563113

This should have said `I added a speed bump...` instead of `I added s speed bump...`.
---

Published using OSMCha: https://osmcha.mapbox.com/changesets/67656888

Thanks.

I hope the greater OSM community will find the checks from our validator code helpful in the future.

Saintam1,
Thank you for connecting about this. I have come across several areas where the landuse was connected to the road and chose to disconnect it to provide more clarity.

I disconnected it from the highways since it seems ambiguous and incorrect to state in a changeset comment that `I added a traffic_signal to a highway` on a landuse.

For example, let's say I added a surface to a road along with a maxspeed sign with the comment `I added a surface and a maxspeed to a road`. If an inexperienced mapper were to see that comment on a landuse, they might think that I added the surface to the landuse or I was unintentionally modifying a landuse when I shouldn't be.

I know that in JOSM, when you add a node to a highway by clicking on it, it will often connect two ways that are either on top of one another or very close together (dependent upon zoom level), so I figured a better long-term solution to (hopefully) avoid having non-related edits on a landuse would be to remove the landuse from the highways. Ideally, I would have also improved the accuracy of the landuse, but the imagery that Bing and the others provide aren't (currently) good enough to make it easy, unless I missed one that does have fairly detailed imagery.

I probably won't be disconnecting landuses from ways in the future though, since I added a validator test to make certain that I don't accidentally modify landuses. See https://github.com/KaartGroup/KaartValidator/blob/master/kaart.validator.mapcss#L641 for the test and https://github.com/KaartGroup/KaartValidator/commit/2e9e1a0ecac683cff038a9feef8069d05ebc9af6#diff-5ad36fba4276fd0c3284257bb267515dR641 for the actual commit. I'm probably going to extend the test for other boundaries, which is why it is `node:new < *[/landuse/]:modified` instead of `node:new < *[landuse]:modified`.

Our team welcomes the feedback that you have provided and appreciate your willingness to work with us to improve the map in Sofia! These types of conversations allow us to help improve our processes for future editing. If you have any other comments specific to editing in Bulgaria please let me know so that I can modify our validator too.

Thank you for the feedback. I look forward to continuing to work with you.