OpenStreetMap logo OpenStreetMap

Changeset When Comment
99470465 over 2 years ago

Please do not change the classification of places within Serbia, you have created a lot of mess, this is a town, not a village. I have found a couple of issues that you have made, please do not change anything in the future

132486692 over 2 years ago

I see that user is blocked by Data Working Group (DWG) osm.org/user_blocks/6875

I will help you with fixing the name to Warri on all the relations where it was changed to Wado

132486692 over 2 years ago

I saw that the change is made to node osm.org/node/501462908#map=19/5.55550/5.78501 but you have to correct relations also

132486692 over 2 years ago

Hi Jon Snow 47 ,
have you tries to contact user Streetvibes?

If the user is creating vandalism please report that to the DWG (for example you can contact user SomeoneElse which is a member of DWG) because they can block that account.

I have just fixed broken relation here, have not changed any tags.

As I can see you have local knowledge, can you fix the name to the proper one?

132291844 over 2 years ago

Fixed, thanks for the hint

132345281 over 2 years ago

Yes, that is the case, sometimes if you do not download all relations that are influenced by the cut, it can create broken boundaries, but no worries, it can be fixed easily :)

132151336 over 2 years ago

No problem, I will fix it, just wanted to double-check. Thanks

132151336 over 2 years ago

Hi Mohnish Landge,
you have broken 2 relations in this changeset
Bangalore North (10594855, v5)
Yelahanka taluku (14934841, v3)

Was this unintentional or there is any reason for this?

131940766 over 2 years ago

Can you specify the source for MZ Oglečeva? As far I know this is not a correct border, the one you have named and started creating relation for

131864740 over 2 years ago

Hi, I saw that you have reverted the Kyrgyzstan-Uzbekistan border, but the current state is also not correct. On the changeset that you commented on before doing this, you mentioned that you should be informed if someone is trying to fix the issue. I would like to make changes to their relations as they were before the first vandalism happened. Is this OK with DWG or do we need some more ground truth? Currently, we have self-crossing boundaries osm.org/way/809037412

131056905 over 2 years ago

Thanks for notifying me, I did this one by accident, sorry, I will pay more attention in the future (I usually do, but will double check in the future)

131345325 over 2 years ago

I have removed the coastline tag since it is not used properly. I have not deleted the way itself, can you describe what you wanted to tag or we should just delete it?

130599571 over 2 years ago

Hi archie, we have done a check of all 46130 highways that have been created/modified by our editors in Sweden and I can confirm that this one was the only error.

We have removed one more road that we have added just because we were uncertain of its existence on the field osm.org/changeset/131110158 so maybe someone local user can add it.

130599571 over 2 years ago

I see no reason for such resentment, but you certainly have a right to it. All edits on OSM can be verified by all users around the planet, but only a few users actually do this, so that's why I said THANK YOU for keeping an eye, but you certainly have the right to understand it however you want. I don't want to deepen the unnecessary discussion that deviated from the topic, which is the quality of the map. When I finish the check I will inform you about the results.

130599571 over 2 years ago

I will do the check also ASAP and inform you of the findings

130599571 over 2 years ago

Hi archie, thanks for reporting this issue.
The road has now been removed.
However, this is not vandalism, this is an accidental copy and offset of the road osm.org/way/111490069
There was no intention to create a wrong road on the map, it was a pure accident, which I agree should not happen, but it did.
We are not doing any automated imports, so human error can be expected. We are running checks after we finish the task and this would be picked up and would be removed, but thanks for keeping an eye, we really appreciate the community involvement.
I have checked all roads created or edited by magrej and have found only this one to be an error, so I would not call this a quality issue, but sure an issue that has been now solved.
BTW magrej is my colleague and he is a huge fan of Sweden, he has been traveling a lot of times to different places across the country and he even learned the language, so feel free to contact him and send him the community-created tasks, so we can jump in and help.

Hope this answered all the questions, but if you have more concerns feel free to comment.

Best regards,
Aleksandar Matejevic

131054820 over 2 years ago

Your edit broke the Beijing relation osm.org/relation/912940

Can you please fix this?

130282959 over 2 years ago

While I agree that this is an oversight on the part of the editor and that we should double-check before making the change, I strongly disagree with this way of labeling a road segment with a tunnel name.
There is a tunnel:name tag that should be used. Also, there is a variant for bridge:name

Here is the wiki documentation:
https://viki.openstreetmap.org/viki/Kei:tunnel#Hov_to_map

Also, this tag is used quite a bit on OSM
https://taginfo.openstreetmap.org/keis/tunnel%3Aname

Would it be in the interest of the community to map all these names correctly?

130719841 over 2 years ago

Can you check the intersection Avenida Juan Domingo Peron and Camino del Peru, user cleuco created some strange ways instead of circular junction which should be remodeled. I saw you was doing the changes, so you may have local knowledge

129944516 over 2 years ago

Hi stevea,
as I have said, I just corrected the member roles, but boundary looked stranged, so this is why I have put this for someone to review. Thanks for the info, but one question: Should we remove this relation completely since the data for CALFire is not compatible with the OSM one, or to just correct it to fire_district.