Update Seamarks with List of Lights

I started to work on a skript to compare the lights in OSM to recent data from the list of lights.Implicitly, I'll find tagging errors and probably some questions will arise or I'll ask for some help.

Here are the first questions ;)

a) Is it allowed to tag areas with seamark:light:*=*?

b) Is it a sector number required in the keys if there is a light with just a single sector?I.e. is it *required* to be tagged as "seamark:light:1:sector_start=*" or is it allowed to be tagged with "seamark:light:sector_start=*"?

Re: Update Seamarks with List of Lights

Bernhard,

a) Yes. The renderer places the symbol at the centroid of the area. Many lighthouses have been mapped this way - when the actual building outline was mapped, the mapper often transfered the tags from the original node to the (closed) way or multiploygon.

b) Yes. Sectored lights must have a subscript, even there is only one sector. Very often a single sector is inferred by partial obscuring of an otherwise all-round light. Please do not do this as it makes for a very untidy map. Instead tag it as "seamark:light:visibility=part_obscured" + "seamark:light:information=*" with the details of the visible or obscured arc(s). In other words, only use sectors where there is a navigational intent for the sector arc & not some artifact of the light's siting.

Re: Update Seamarks with List of Lights

malcolmh wrote:

Bernhard,

a) Yes. The renderer places the symbol at the centroid of the area. Many lighthouses have been mapped this way - when the actual building outline was mapped, the mapper often transfered the tags from the original node to the (closed) way or multiploygon.

Ok.

malcolmh wrote:

b) Yes. Sectored lights must have a subscript, even there is only one sector. Very often a single sector is inferred by partial obscuring of an otherwise all-round light. Please do not do this as it makes for a very untidy map. Instead tag it as "seamark:light:visibility=part_obscured" + "seamark:light:information=*" with the details of the visible or obscured arc(s). In other words, only use sectors where there is a navigational intent for the sector arc & not some artifact of the light's siting.

Ok. There will be a lot of lights that we have to correct because at the original import in 2010, we imported lights which are "obscured by the shore, etc." as sectored lights. I agree that this is not a good idea and it is better to use visibility + information but for whatever reason, at the time then we did it.I'll update my parser accordingly.