Hi Eman_Mehrez.
Thanks for pointing this out, I have checked and corrected this. It was an unintentional mistake.
Best regards,
Aleksandar Matejevic

Hi mego_map.
Thanks for pointing this out, I have checked and corrected all the roads that were affected while creating relations. It was an unintentional mistake. Now it is corrected.

Best regards,
Aleksandar Matejevic

Please read how to use natural=coastline tag

osm.wiki/Tag:natural%3Dcoastline

Does this park exist or this is it still in construction?

Your edit broke a lot of relations, like Jeumpa, Peudada. You have deleted a lot of boundaries. Please revert or fix the changes you have made.

I have removed natural=coastline from the way 1099376780, please check and tag correctly

I have removed natural=coastline tag from the way 1099370131, please check the tagging

Hello, these are attributes from the original Settlements Ungeneralised - OSi National Statistical Boundaries - 2015 and it is left intentionally so we can do a future join if a new dataset becomes available. This is done in the same manner as it was done for "Experimental import of Irish places and POIs from GNS Dataset" but it can easily be changed to some other OSM tag. If it does not bring a lot of issues I would like to leave it as is until all polygons are added and the community reviews them.

I will then create a line instead of this relation if this is OK with the communities.

Hi SomeoneElse,
I agree that the OSM wiki states that this tag should not be used on polygons or relations, but this range is so huge, so it covers a lot of mountain peaks and it would be impossible to map it, it would still be a bad geometry, and also, other big mountain ranges are already mapped with polygon relations, so this is why this approach is taken.

Thanks guillemmal, I really appreciate this solution, looking forward to improve the geometry and relation members in the future.

I agree that a relation should be created with the existing geometries, but this was not done because there is no clearly defined border and it is easier to correct two lines than to correct the members of the relation, so for now, it is left to only correct the geometries. I received comments for Venezuela and Colombia, and also for Lima, and I corrected those parts, so I expected the same reaction from other communities. Honestly, I really appreciate local knowledge, but I find it unacceptable that OSM has, say, the Alps but we don't have the Andes which are greater and more massive. I'm more for cooperation first to define some geometry that is "final" and then I will easily replace part by part with existing geometries that are already on OSM

I would ask you to reconsider not to delete this relationship but to correct it according to local knowledge, so that in the end you get the most accurate possible boundary. By the community's assertion that the relation is incorrect, I get the impression that you actually know where the border is, if the problem was the bus route, you could have just moved the relation border to an adequate place instead of deleting it. This is why we don't have the Andes on the map and they are the largest mountain range in the world?

I think deletion should be the last option. As I created the relation, you could contact me first to see if we could fix this, not just delete the whole relation.
Imagine if someone came along and deleted all your map entries that they don't like or don't think are accurate enough?

@iriman, I agree that both islands have Wikipedia links and if you visit the page you will find out that these are disputed areas. But you still need tagging in order to render this on the map. Imagine you create a point, add a Wikipedia link of the airport, and is that an airport? Will it render on the map? Will the search engine will find it? No, this is why we have other attributes.

Please revert the change for the Thumb islands, it does not affect Iran or UAE borders, it is just a relation that has all the correct attributes for disputed territories, not the administrative ones.
I understand that this is a sensitive area, but if you look at this https://en.wikipedia.org/wiki/List_of_territorial_disputes you will find that lot of territories are in more or less similar situations. This is why we map them as claims, this does not mean that they belong to a specific country.

Hi, iriman, can you explain how was this a "vandalism and unverifiable edits and fixes some problems on territorial borders of Iran"?
I have added relation with boundary=claim, claimed_by, disputed_by, and this can be verified on several sources, but take Wikipedia as an example https://en.wikipedia.org/wiki/Greater_and_Lesser_Tunbs

No change of the Iran border was made.
Can you please revert your edit which removed claimed boundaries?

Hi SekeRob,
This was a typo, thanks for fixing it. I was looking how to tag this correctly since it is salt dry part of the lake, so it has some water just when it is under heavy rain. Using wetland=saltmarsh is not applicable since this is for coastal parts only, not for lakes. I think intermittent and salt=yes in this way reflects the real condition

Hi Andy, we will ensure that our team is acting according to the requirements you have mentioned. Thanks for pointing this out.

Best regards,
Aleksandar Matejevic

Hi,
The main question here is: Does this circular junction has the complete right of way or not?

According to OSM wiki
osm.wiki/Key:junction if the circular junction has the right of way then junction=roundabout has to be used and if not, then junction=circular is the appropriate tag with the oneway=yes combination.

If this is roundabout then oneway=yes is implied and redundant so it should be removed because this will become an error on most QC tools for OSM and more importantly someone can easily, by mistake, switch tag to oneway=-1 and create a big issue with routing.

Here is an example of this situation and you will see that the routing is wrong: osm.org/directions?engine=fossgis_osrm_car&route=23.77854%2C38.79242%3B23.77989%2C38.79442#map=18/23.77972/38.79342

So if this is not a roundabout then borovac should change this to junction=circular and return oneway=yes, but if this junction has right of way then the current taging is correct.

ashs_as, can you provide the info about this junction right of way?

I have seen that you have put name=GWH Service Road.
On the basemap it is Railway Parade and there are Mapillary streetside imagery that you can see the signs with that name. However, in AUS it is common that streets tends to have segments with different names, but can you change the name to Great Western Highway Service Road since by OSM standards abbreviations are not wanted thing, and second, can you add tag alt_name=Railway Parade since it is on official NSW Basemap, so in that way, no one will remove some of the names and both versions will have ground truth.

I have added the note that Approximation is done using OpenTopoMap and the idea is to have starting relation created so everyone that have knowledge of the exact boundary can simply adjust the geometry of each part so at the end there is a precise mountain range.

I will work on updating it to precise boundaries, in next period all comment's are welcome, and you can also fix the parts you have more knowledge of.