man_made=beacon tag are mainly used for historic beacons (osm.wiki/Tag:man_made%3Dbeacon).

The rendering of seamark objects is not done by the main OSM renderer. To view these objects, use one of the seamark websites: http://opennauticalchart.org/?permalink=true&zoom=15&lat=59.45801&lon=24.75101&seamarks=true&coordinate_grid=true or http://map.openseamap.org/?zoom=15&lat=59.45594&lon=24.75200&mlat=59.46655&mlon=24.74155&layers=BFTFFFFFFTF0TFFFFFFFFF

The seamark tags fully describe these objects. No other tags are necessary except to add additional information.
osm.wiki/Seamarks/Buoys

Steve,

US lateral seamarks conform to the IALA-B system: port-hand marks are green and starboard-hand marks are red. (See: osm.wiki/Seamarks/Buoyage_Systems).

This beacon is a starboard-hand mark, not port. I note that you have made the same mistake on other lateral marks.

Also, apologies to chippy, who I now realise was not the mapper who created the duplicate, only the mapper who raised the issue.

Sequence of events:
24/5/15: node 1 restored as a tree in DE
3/11/15: node 3815077900 created at 0,0
1/12/16: node 1 deleted
30/1/17: node 1 restored, this time at 0,0 - on top of node 3815077900. Later that day, I deleted it.

The mapper that has created this confusion is "glglgl", and his comment on changeset 45651079 suggest that he was just playing.

I was replying to chippy! @chippy when you "restored" node 1, node 3815077900 was already in the database & had been since 2015. Therefore you had created a duplicate & that is why I deleted it.

You had created a duplicate of node 3815077900, which has been there since 2015.

You are right, the position is clearly incorrect. My contribution was only to correct the tagging, not the positioning. (See my comment on the previous changeset for this node). The original mapper imported this and many more objects using the source "http://www.notmar.gc.ca/go.php?doc=eng/services/list/pacific-coast/p310e2010". These documents do give very accurate positions. It appears that the import made no attempt to merge the objects with the existing map.

"name" and "seamark:name" do not necessarily have the same value. An object may be known to mariners by a different name than that used by the local area. For example, harbour may be named after the town by the local community, but may be listed under the name of the operating yacht club in nautical references.

Sorry, I made a bad choice. Much better would be "waterway:information", since the mapped object is a waterway, not a seamark. If you agree with this, I will make those changes.

My source was the tags that remained after redaction. Those tags belong to a long-since abandoned tagging proposal, so I converted them to the non-deprecated seamark tags using the values in the remaining tags, in addition to a couple of default values that my editing tool generates (buoy shape & topmark shape/colour). The lights tags used the values in the "description" tag.

If the light is located on the building, then it is a good idea to copy the node tags onto the building polygon & delete the node. If the beacon is a duplicate then delete it. I don't know whether the buildings are disused - try asking the original mapper.

Please note that the tag "seamark:type" can only take one value. This should be the master object. Other objects sharing the same node/way are implied by their attribute tags, or where they have no attributes, can be detailed in a "seamark:information" tag.

Oh dear! In that case I will remove all this data.

The data was extracted from http://www.vnf.fr/ecdis/data/Moselle.zip. The "national_information" value should be a French translation of the English "information" tag value. It looks as if the text has been truncated.

Please do not destroy recent on-the-ground surveys with out-of-date aerial photos.

Whoops! Fat finger trouble on my part. - now reverted

OSM have requested that depth data should not be put into their DB. Depths may be added to sunken objects, but not isolated spot depth soundings or depth contours. Therefore please delete these nodes.

The amphitheatre is being constructed to sit over part of the dry dock, but all of the dock will remain intact. As soon as I can get close enough to do a survey, I will map the new construction. The question is, what would be suitable tagging for an open-air amphitheatre?

I do not buy the argument that this tag makes things easier for consumers. Those that I know of all use the waterway=river/canal tagged linear ways. Anyway, good luck trying to persuade the other 290,000 instances of your case!