Sorry, but that would cut the area with that name into two parts. The Chenal du Nord and Chenal du Sud are in the way. I use a guideline called "one point, one name" when naming bodies of seawater, and I have an additional guideline that says that a body of seawater with a single name cannot be cut into two disjoint areas.

That is the name of the wiki page, but the name of the city itself is just "St. John's". We do not put anything but the name of the city in the "name" field.

Your edit to the city name here is redundant. The exact city name is "St. John's". The fact that it is in Newfoundland and Labrador is indicated by the fact that it falls within relation #391196. And this node is supposed to be placed at the city hall, not at some random point within the city.

This seems to be a rather mal-formed changeset. One of the "Winter Harbour" relations in this changeset, #13714934, has itself as a member twice, and its two child relations take in many of Canada's Queen Elizabeth Islands.

According to the Quebec, Ontario and Manitoba Boundary Extension Acts of 1912, the jurisdictions of these three provinces terminate exactly at their Arctic shorelines. All islands within Hudson Bay, James Bay, Hudson Strait and Ungava Bay belong exclusively to what is now Nunavut. I am now correcting these boundaries to coincide exactly with these shorelines.

It is a rule I use when naming bodies of seawater. Any point on the sea is allowed to have a maximum of one name associated with it.

Yeah, that should actually be "natural"="isthmus".

natural=isthmus

What I did was simply reorder the relation members in order, forming closed loops. There must be something else wrong with Lakes Huron and Ontario. Maybe if we compare them to the other Great Lakes, we will find the problem.

Fixed in changeset #115255053.

Fixed. Thank you.

I will look into that. Thanks.

Those are indeed automated imports from CanVec. I have also been converting some of them to tidalflats as I come across them, using guidance from Canadian Hydrographic Service charts.

The tag "ocean=yes" has a purpose. It stems from a discussion on the talk-ca mailing list about issues with the maintainability of the area definition data I have been putting in for named bodies of seawater. Anyone can filter out data with that tag if they want to work on the coastline without worrying about breaking anything, even those relations I have been adding, as I have stated on talk-ca that I am willing to maintain the area definition data for seawater in Canada.

You duplicated Mermaid Cove.

relation/8332396

I am regularly visiting OSM Inspector and following up on anything it reports needs my attention.

In case you are wondering why it looks like part of the St. Lawrence Estuary has "dried up", it is because the coastline has been extended in this area, and it will take a bit of time for the coastline rendering routine in the OSM-Carto tiles to catch up to this.

Good job on helping to continue maintaining this coastline data. I have been in this area adding relations for named bodies of seawater, and we recently had a discussion on the talk-ca mailing list raising concerns that the data I was adding might not easily be maintainable in the face of other editors continuing to maintain the actual coastline data. I added a special tag to the bodies of seawater relations, "ocean"="yes", to allow other editors to filter out the data set I was adding so they can continue to maintain the coastline while I continue to maintain the named bodies of seawater. This is a perfect example of collaboration among multiple editors to improve many distinct facets of OpenStreetMap's database. Thank you so much, and keep it up.

In case you are wondering why it looks like this area of water has "dried up", it is because the coastline has been extended in this area, and it will take a bit of time for the coastline rendering routine in the OSM-Carto tiles to catch up to this.

I have been using Ctrl+Alt+D in JOSM in a bid to catch any relations I might have affected and make sure they remained intact. Obviously several relations fell through the cracks, and I intend to fix those with the aid of the OSM Inspector.

The postal code for this post office has changed to G6P 0A0.

Le code postal pour ce bureau de poste a changé à G6P 0A0.

Because that is how the whole BC coast is structured in OSM.