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.

Every comment and suggestion is highly appreciated by our team. In these cases, you have mentioned ways may have a larger number of nodes than needed, but we do take care not to over node all the ways we are creating. For example, in straight ways, you will find very few nodes, just not to have long segment issues in inspector tools, and across South America, there was a massive number of deleted nodes done by our team for overnoded ways. I have read the post you have posted here and we do get aware of these large databases issues, and we will pay extra attention to these details in our future work. Thanks for the collaboration, I hope you are satisfied with our contribution in general.

We are using JOSM to trace aerial imagery for the missing roads as precisely as it can be. So far we never had an issue that someone is complaining about our work in terms of how accurate geometry looks. In our work, we are also fixing approximate way issues that are caused by under node representation of ways. Also I this way 301863751 looks like a total disaster. Since there is no limit about this on OSM Wiki, can you point me to that OSM Weekly because I could not find any article about this issue?

HI mariotomo, can you be more specific about the number of nodes, you consider these ways under noded or over noded?