Proposal talk:Marine-tagging

mojar/minor lights

How do you tag major and minor lights using this scheme? I will start a thread ("Tagging Seamarks") on the OSM mailing list for further discussion on that.--Rahra 21:49, 15 August 2010 (BST)

do you have an example for me for major and minor seamarks? (S57 only knows the values you can find unter "light:category=*" herer in the proposal). I seriously hope this disscussion on the mailing list won't get such a mess, than the threads 1 or 2 years ago *g* why won't discuss it here in the Wiki-discussion-section?--Cbm 23:03, 15 August 2010 (BST)

Major and minor lights have a different rendering. Have a look at this scan INT-1, p. 55. According to this it is 470,5 of IHO spec. Why mailinglist? Because it may reach more people interested in marine mapping and because email is much more comfortable.--Rahra 07:54, 16 August 2010 (BST)

strange... i looks like the s57 do not have a value for differ beteen major/minor lights....

The distinction of major vs. minor light symbols is not used by all producers and HOs in the first place. For example, Admiralty charts use symbols for minor lights excessively, while the commercial producer Imray never does. ENCs and other digital data tend to include the range with all lights that have major symbols, which is why there isn't a need for an attribute carrying this distinction in S-57. Arne Johannessen 02:12, 18 August 2010 (BST)

S57 Category of Light:

  1. directional function: a light illuminating a sector of very narrow angle and intended to mark a direction to follow. (IHO Dictionary, S-32, 5th Edition, 2778)
  2. leading light: a light associated with other lights so as to form a leading line to be followed. (adapted from IHO Dictionary, S-32, 5th Edition, 2794)
  3. rear/upper light
  4. front/lower light
  5. aero light: an aero light is established for aeronautical navigation and may be of higher power than marine lights and visible from well offshore. (IHO Chart Specifications, M-4, 476.1)
  6. air obstruction light: a light marking an obstacle which constitutes a danger to air navigation. (IHO Dictionary, S-32, 5th Edition, 2767)
  7. fog detector light: a light used to automatically determine conditions of visibility which warrant the turning on or off of a sound signal. (IHO Dictionary, S-32, 5th Edition, 1885)
  8. flood light: a broad beam light used to illuminate a structure or area. (adapted from The Collins Dictionary)
  9. strip light: a light whose source has a linear form generally horizontal, which can reach a length of several metres. (IHO Chart Specifications, M-4, 478.5)
 10. subsidiary light: a light placed on or near the support of a main light and having a special use in navigation. (Admiralty List of Radio Signals, UK Hydrographic Office)
 11. spotlight: a powerful light focused so as to illuminate a small area. (The Collins Dictionary)
 12. front, rear, upper, lower: terms used with leading lights to describe the position of the light on the lead as viewed from seaward.
 13. moiré effect: a short range (up to 2km) type of directional light. Sodium lighting gives a yellow background to a screen on which a vertical black line will be seen by an observer on the centre line. (IHO Chart Specifications, M-4, 475.8)
 14. emergency light: a light available as a backup to a main light which will be illuminated should the main light fail.
 15. bearing light: a light which enables its approximate bearing to be obtained without the use of a compass. (IHO Chart Specifications, M-4, 478.1)
 16. horizontally disposed: a group of lights of identical character and almost identical position, that are disposed horizontally.
 17. vertically disposed: a group of lights of identical character and almost identical position, that are disposed vertically.

finishing voting...approved?

18 : 2... looks like it's approved now, isn't it?--Cbm 11:59, 14 August 2010 (BST)

Maybe so ... but let's not rush to conclusions. There appears to have been an unusually high amount of constructive discussion over the past few days. Let's wait it out for a bit. :) Arne Johannessen 02:12, 18 August 2010 (BST)

buoy:category

with that, we can differ between major, minor and other buoys/beacons(e.g. for sport)--Cbm 15:55, 10 November 2009 (UTC)

proposal ready for vote?

it's becoming quite here. is that a sign for we are ready for a voting? --Cbm 21:36, 9 November 2009 (UTC)

you should send it out on the mailing list. --Skippern 11:17, 11 November 2009 (UTC)

specifying special_purpose marks?

instead of just using and calling it "buoy=special_purpose" we should use better values to describe the function of the seamark. E.g.:

buoy=danger_area (e.g. the "yellow buoy with yellow X" or the "white buoy with orange bands and diamond")

buoy=prohibited_area (e.g. the "yellow buoy with red X" or the "white buoy with orange bands and crossed diamond"

buoy=information (e.g. "white buoy with orange bands and rectangle"

buoy=restrictive_area (e.g. "white buoy with orang bands and cicrle"

buoy=mooring (could be e.g. just a yellow buoy, or "bluee-white buoy" or "orange-white buoy"...)

buoy=anchorage_area

buoy=weather (ODAS = large yellow buoys with a small antenna rack and usually a yellow flash)

buoy=science (ODAS = large yellow buoys with a small antenna rack and usually a yellow flash)

buoy=tsunami

buoy=fog_detection

buoy=race (usually not permanent, colors might be odd, with commercial banners, and odd shapes, etc)

buoy=diving (shape, size and color varies, usually with a pole and a dive flag (signal flag A or red flag with white diagona line, depending on geographical area)

buoy=swimming (e.g. the "yellow buoy with yellow X" or a line of small yellow buoys)

And to know, how the buoy looks like in each region therefor we have the "describing-tags" like buoy:color=*, topmark:shape=* etc..--Cbm 15:23, 21 August 2009 (UTC)

added a few examples of description --Skippern 23:46, 21 August 2009 (UTC)

added descripions, too :) --Cbm 00:31, 22 August 2009 (UTC)

Note that "Special Purpose" implies IALA to some people. Some countries prefer to use non-IALA marks for some of the mentioned buoy categories. Perhaps an additional tag might be even better here than just reusing buoy=*. Arne Johannessen 02:12, 18 August 2010 (BST)

light and light-sectors

there are 2 possible ways to catch light-sectors:

• all-in-one / combined:

lightsector:[no.]=[color]:[start]:[end]:[range]:[ele]

alternative:

lightsector:[no]=[start]:[stop]:[light character]:[signal group]:[color]:[period]:[elevation]:[nominal range] (e.g. "Fl(3) R 8s 30m 15M" = lightsector:1=x°:y°:flashing:3:red:8:30:15")

• value-seperated:

lightsector:1:character=

lightsector:1:signal_group=

lightsector:1:color=

lightsector:1:period=

lightsector:1:sector_start=

lightsector:1:sector_end=

lightsector:1:ele=

lightsector:1:range=

which one do we prefer? --Cbm 12:22, 19 August 2009 (UTC)

I vote for combined when using editor, the two of them makes no difference, but for those who decides to mark manually the combined is much easier to use, and less room for making errors. Syntax documentation is important, but direction of arguments is logical, so no need to change that. It is possible to amend more variables later if needed. Unset variables should be allowed with :: (i.e. 360 degree light could be tagged as light:1=white:::5M). Missing one variable at least, height of light above sealevel (height/ele). --Skippern 01:03, 22 August 2009 (UTC)

maybe it's better to name the combined methode "lightsector". so it's lightsector:1=white:0:120:5M:18m for example, but a 360° light is better to catch with light:color=white light:range=5nM --Cbm 11:40, 22 August 2009 (UTC)

lightsector:#=* is even better, thanks for adding ele. --Skippern 12:52, 22 August 2009 (UTC)

with making this difference between lightsectors and (360°-)lights we are also able to collect seamarks with more than just one (360°-)light. E.g. I found some light-charachteristics on the spanish-wikipedia-site like:

"Al F W Fl R",

*Al F W Fl RG",

"Al F W Fl (3)G" or

"Al F W Fl WRR"

so we can catch these special lights with e.g.: "Al F W Fl R" = "light:1:color=white + light:1:character=fixed + light:2:color=red + light:2:character=flashing".

but maybe there is a better methode for this special-lights? --Cbm 13:31, 22 August 2009 (UTC)

I found a shorter way for pic.1 and pic.3. Just call the "light:character=fixed_and_flashing" + light:color=color(fixed)-color(flashing). Just like we're using the keys with "light:character=alternating + light:color=red-green-white" for example. But for the rest, I think, we still need light:1=, light:2=... etc. --Cbm 00:37, 23 August 2009 (UTC)

pic.2 and pic.4 are also possible, I think.

pic.2 -> "light:character=fixed_and_flashed light:color=white,red-green"

pic.4 -> "light:character=fixed_and_flashed light:color=white,white-red-red"

but is this good enough? --Cbm 10:07, 23 August 2009 (UTC)

Separating the lights matches exactly the method defined by the IHO (S-57 APPENDIX B.1, Annex A - Use of the Object Catalogue for ENC, 12.8.3), so I guess this would make sense :-). Regarding the combined method, I would suggest to have the values ordered in traditional manner which is: light character, signal group, color, period, elevation, nominal range (e.g. Fl(3) R 8s 30m 15M) --HeikoE 14:36, 22 August 2009 (UTC)

is there a need for light:character and period in the sector-values? Aren't these data for the light? E.g.:

light=yes

light:character=flashing

light:signal_group=2

light:period=8s

light:ele=30m

lightsector=[start]:[end]:red:15M

this could be a useful mix of combined and value-seperated. --Cbm 10:20, 23 August 2009 (UTC)

Different sectors can have different characters and periods, so these attributes should be applied to each sector (handle each sector as a different light with all of it's attributes - see INT1 IP 30.3 and IP 42). --HeikoE 11:46, 23 August 2009 (UTC)

under that premise there is no need for the differentiation between light and lightsector, is it? If it's not a 360°-light (which is default when no explicit sectors are given) it has light:sector_start=* and light:sector_end=*. --Cbm 16:40, 23 August 2009 (UTC)

Right, the sectors are are an attribute of the light, so it may be sufficient to have only light as the key (light:1=x°:y°:flashing:3:red:8:30:15 with the combined model or separate as you have mentioned light:n:attribute=value). --HeikoE 22:36, 23 August 2009 (UTC)

The degree symbol should not be necessary as we know the sector is marked in degrees, and not in radians. --Skippern 22:56, 23 August 2009 (UTC)

Yes, of course, I've just copied the example from above :-) --HeikoE 23:17, 23 August 2009 (UTC)

maybe it's better to set [sector_start]:[sector_end] as last attributes?

so it's:

light(:[no])=[character]:[signal_group]:[color]:[period]:[elevation]:[range]:[sector_start]:[sector_stop] for sector-lights and

light(:[no])=[character]:[signal_group]:[color]:[period]:[elevation]:[range] for 360°-lights.

Or doesn't it matter? *g* --Cbm 23:45, 23 August 2009 (UTC)

Yes it matters, the order of arguments have to be fixed, and for the usage mandatory arguments must be before optional arguments. :[sector_start]:[sector_stop] is mandatory, elevation and range can be omitted without breaking the logic. --Skippern 00:02, 24 August 2009 (UTC)

so your arguments prefer which order? :-) --Cbm 05:40, 24 August 2009 (UTC)

light:[no]=[start]:[stop]:[color]:[character]:[signal_group]:[period]:[range]:[elevation]

Mandatory arguments in bold, optional arguments (in this order) in normal type. --Skippern 09:38, 24 August 2009 (UTC)

My understanding of light(:[no])= is, that simple single-character/single-color lights would be tagged with light= whereas sector lights would get a light:no= for each sector, right? Declaring start/stop as mandatory in the sector case makes of course sense then.

On the other hand, many single-character/single-color lights also have sectors of visibility (e.g. many harbour entrance lights), so start/stop would also make sense for the light= case, however definitely not as mandatory arguments.

Anyway we would get different argument schemes for light= and light:no=. The latter begins with start/stop, the former not. Error prone.

I suggest the following tagging scheme:

light=[yes|no|full_characteristic] where full_characteristic means the typical label as known from charts, e.g. "Fl WRG 5s" (for multi-character lights e.g. a comma separated lists would do)

light:[no]=[character]:[signal_group]:[color]:[period]:[elevation]:[range]:[sector_start]:[sector_stop] (mandatory args bold)

A simple harbour entrance light would be tagged as

light=F R

light:1=fixed::red

The full_characteristic with light= is basically unstructured and probably redundant information. On the other hand it's easy to understand and maybe often the only information you have about a light (how do you tag a light if you know it has WRG sectors but don't know the sector boundaries? I don't see much benefit in adding light:1-3 if the most important information is missing). Additionally for many uses it should be enough to retrieve the full_characteristic from the database (e.g. when looking for a short descriptive label).

If more details are available, light:[no]= comes into play. Even if there's only a single light, there would be a light:1= (but not light:2=).

One more thing: I wouldn't use a dedicated field for signal_group. For me it's part of character.

My two cents --Fumpel 16:08, 2 September 2009 (UTC)

In the case of a single color single character light with a sector, than I see no problem tagging it with the sector tag, even if it is only one sector (the other sector is the blind sector, right?), while light=* would indicate that it is a 360 degree light. Shadows formed by external structures and land cover is than ignored by the code, but can be derived from using the height of the light and the elevation and height of the land and the external structures. Though in many cases these lights are marked as 360 degree in marine maps, and the user have to take account for any blind spots. I see no point in using a combined syntax for light, while it can be combined with other tags to gather this type of information. The reason I separate period, elevation, and range from the combined syntax is that they often are the same for all sectors of the light, and therefor can be marked with light:range=* and other, while the data for each sector must be tagged in a uniform way. Only at odd exceptions that sectors have different elevation, range, character, etc. One example is Grip Fyr (outside Kristiansund, Norway), which have a long range light on the top of the tower to guide vessels closer to the coast, than at a lower height some lights indicating a shallow area outside of the light, and at the bottom a leading light for getting safely to the island where the tower is located. This is basically 3 lights located on the same structure, they can be derived to 3 different nodes, though this position data is not available through any sources I know. Tagging these 3 lights on the same node with different height, range, period, character, etc can only be done with sectors, and yes, sectors will overleap. --Skippern 18:52, 2 September 2009 (UTC)

I like the idea of separating common values, though I think it rather affects character, signal_group, period and elevation. Range usually differs per color. But how about putting it the other way round? Combined syntax for light=, override with individual tags per sector

light=[character]:[signal_group]:[color]:[period]:[elevation]:[range]:[sector_start]:[sector_stop]

Sample directional light:

light=Fl::WRG:5s:10m

light:1:sector=10:15

light:1:color=R

light:1:range=15M

light:2:sector=15:30

light:2:color=W

light:2:range=18M

light:3:sector=30:45

light:3:color=G

light:3:range=14M

If there were a fourth sector with different character, one could override with e.g. light:4:character=Oc

And yes, that way light:#:sector is not mandatory. OTOH in particular sector boundaries, range and elevation are rather difficult to get by observation. I expect that it will be a common case that sector colours and characters are known, just the sector boundaries will be missing. For these cases it should still be possible to enter the known bits. --Fumpel 13:56, 3 September 2009 (UTC)

If we combine all this into one tag we can keep the syntax as it is found on charts and other documents, e.g.:

light=Fl WRG 5s

I think this is more readable. Renders can then choose to put that directly onto a map. Of course, then the height needs to be taken care of seperately:

light:height=10

I think stuffing too many properties into one tag is not a good idea. The above I would only support because it is already an established standard. Otherwise I would prefer separate tags for everything.

Also, I don't like when tag values are partially overridden by subsequent tags. This makes the tagging scheme unnecessarily complex. I think it is best to avoid any overriding of tags. Therefore, I would rewrite the above example to:

light:height=10

light:1=Fl R 5s

light:1:sector=10:15

light:1:range=15

light:2=Fl W 5s

light:2:sector=15:30

light:2:range=18

light:3=Fl G 5s

light:3:sector=30:45

light:3:range=14

Another way of sticking multiple lights (or sectors) onto the same object could be the use of relations. --Mjulius 21:04, 8 September 2009 (UTC)

Just one aspect to think about: an agreed intention was to keep it simple and useable even without an specialized editor. We're talking about the description of a light, regardless if it's on a buoy, a beacon or a lighthouse. So I think the syntax of a combined value should be always the same and preferably should follow the syntax shown in the nautical charts so anybody is able to contribute even if there's less knowledge about any sophisticated data structure. This means to have just the least common denominator in the combined value and collect the sector information in an additional separate value:

light[:no]=[character]:[signal_group]:[color]:[period]:[elevation]:[range]

+ optional: light[:no]:sector1=[start] + light[:no]:sector2=[end] (where sector1 is the start angle and sector2 is the end angle of the sector, according to S-57)

Hm, a buoy doesn't have an elevation, no clue how to handle this. Your thoughts? --HeikoE 06:01, 25 August 2009 (UTC)

Unused variables can be entered by :: --Skippern 09:03, 25 August 2009 (UTC)

Cardinal south

Hm, any ideas about a cardinal south light? (e.g. Q(6)+LFl.15s) --HeikoE 18:30, 17 September 2009 (UTC)

what about this try?:

light=yes

light:colour=white

light:signal_period=15

light:description=Q(6)+LFl.15s

light:1:character=quick

light:1:signal_group=6

light:2:character=long_flashing

The nautical data model is already done?

Hi! Back from a trip, I spot your work... First: this is a very nice work!

But the data model for nautical maps in OSM is already done. And of course it is corresponding to S-57. We are scripting two editors for seamarks (online and offline), working as a GUI, so the user don't need to know anything about S-57. And he never should attribute something by hand.

I would be very happy, if you would like to help in our developper team! Please call me or send me a mail.

Thanks, --Markus 20:58, 11 August 2009 (UTC)

• Hi Markus, I'm glad you join the discussion here. I know the oseam tagging scheme and in my opinion it's very overheaded. E.g. there is no need to use "seamark:..." in front of every key. Also there is an unneeded "hyper-redundance" ;) (e.g. seamark:buoy_lateral:light= instead of just saying light=). Third point is, that there is no clear splitting between function and the thing itself (buoy_lateral instead of saying seamark=buoy buoy=lateral_port). These points we try to improve with this proposal :) I hope you will join the discussion again. Regards --Cbm 11:50, 12 August 2009 (UTC)

The importance is that the tags are clean, logical, and follow the S-57 standard. If blindly building upon the S-57 tables, as for example found in "Guide Lines to Chart Corrections" by British Admirality, the tagging structure becomes very complicated. Finding a logical way to simplify the tagging scheme both to make it simpler and cleaner, within the framework of S-57 should be the goal of this proposal. I see no problem of using other OSM tags within S-57, such as man_made=tower is of interest to many marine maps, and should be part of the wider S-57 tagging scheme for OSM and OSeaM. --Skippern 01:55, 13 August 2009 (UTC)

light-category

I think about a lot abot the strukture in light (and topmark). First I thought light= should be also a value about color (next to just "yes"). But I think light= should also be the light-categories and the colors should be put into light:color=. What do you think? --Cbm 09:28, 7 August 2009 (UTC)

Could you be a little more specific on how you where thinking? --Skippern 09:39, 7 August 2009 (UTC)

Best I give an example:

If there is a red light -> light=yes + light:color=red.

If there is a leading white light -> light=leading + light:color=white.

Using it that way we use the same logic as with the key "buoy" -> buoy=lateral_starboard (if a user don't know the function-terminus like e.g. "lateral_port" or "cardinal_east"... he/she can even use buoy=yes it won't kill the logic) plus buoy:color=green. --Cbm 10:41, 7 August 2009 (UTC)

Overexagerated redundancy make two problems (atleast)

1. Documentation of the tags
2. Rendering rules

It won't hurt to have some redundency, for example, bouy=lateral together with buoy:color=green is the same (in at least 99.99% of the cases) as buoy=yes and buoy:color=green. In this case, buoy=yes is the general description, while buoy=lateral is a more precise tagging, and should be advised as the default way to tag lateral buoys. It shouldn't be necessary to tag the lateral buoys as port and starboard as the colors together with a check wether it is within IALA region A or B (which can be done with a relation as soon as the boundary=maritime+border_type=IALA have been tagged). --Skippern 04:34, 17 August 2009 (UTC) (Why was this comment removed? --Skippern 01:24, 18 August 2009 (UTC))

IMO buoy=lateral could be a possible value but lateral_port, lateral_starboard, cardinal_north, regulatory_info,... is better because if gives clear and distinct information for navigation. --Cbm 12:16, 19 August 2009 (UTC)

IMO buoy=lateral_port / lateral_starboard obsoletes buoy:color, and make it more complicated for non-marine taggers. (almost) anybody can see the difference between a green or a red buoy, but not many non-marine persons know whether it means port or starboard. With the difference of IALA regions we make it even more complicated for them. Simplifying it with only lateral + color will make most people understand what we want without comprimising the quality of the tags. For cardinal buoys it is different, since they all are black/yellow, so cardinals have to be identified correctly with N, S, E or W values. A wiki page must explain these values thurogly to prevent imunderstandings. --Skippern 00:03, 20 August 2009 (UTC)

if a non-marine person don't know the function of a buoy, then he/she shouldn't tag buoy=[function] at all but just (e.g.) "seamark=buoy + buoy:color=blue-white" or "seamark=buoy + buoy:color=white + buoy:pattern=orange bands". IMO lateral_port and lateral_starboard + buoy:color identifies the buoy clearly (without knowing something about IALA-zones). Btw. cardinal-marks can also clearly identify by color, but buoy=cardinal_north, etc. is a much more efficient way :-) --Cbm 01:13, 20 August 2009 (UTC)

It will not be clear for a non-mariner the difference between yellow-black, black-yellow, yellow-black-yellow and black-yellow-black, while red-white and white-red can be accepted as the same. I just mean if a non-mariner is able to tag buoy=yes + buoy:color=green, than he would also be able to read off the wiki that he can tag buoy=lateral, without knowing what IALA region he is in. Same also a mariner on holiday might glance and see if it is a green or red lateral buoy without concerns about IALA region, in a work situation he should of corse always know what IALA region he is in. To say that non-mariners should not tag marine features is the same as to ignore a large part of the community that will be able to help out, though I would prefare mariners verify the map regurarly, even (or specially) in areas where non-mariners do a large part of the tagging. --Skippern 09:44, 20 August 2009 (UTC)

But buoy=lateral + buoy:color=green doesn't have any more information than buoy=yes buoy:color=green, do it? Only with IALA-infoyou can get it's function. Instead using buoy=lateral_port, lateral_starboard the function is totally clear even without a color-value (if you know the IALA-region). If a non-mariner don't know the difference between port and starboard he shouldn't just tag buoy=* at all but just seamark=buoy and additional proofable info like buoy:color, topmark=yes or light=yes.--Cbm 19:48, 20 August 2009 (UTC)

I think I start to see your point, I do partly agree with you, but let it rest here. I do not think we can fully agree on the approach. Of corse buoy=lateral_port is a much better approach than for example buoy=lateral + buoy:lateral=port, but maybe it can be just the latter as we already know it is a buoy? This approach can also work for cardinal buoys... --Skippern 23:56, 20 August 2009 (UTC)

When thinking about it I come to think that since we already know it is a buoy (seamark=buoy than buoy=* is not needed for lateral and cardinal buoys as we can specify that information directly with buoy:lateral=* and buoy:cardinal=* - buoy:color=*, topmark=*, light=* maybe even some tag for radar reflectors and other aids can enhance the information. BTW have you added a tag for AIS identified buoys? There are some near Sunk / Thames Approach at least have it. --Skippern 23:56, 20 August 2009 (UTC)

Topmark

I took the liberty to add the colors yellow and black to topmarks, black is more common than red and green combined, and many special yellow marker buoys (edge of beach areas etc.) often have a yellow x-shaped topmark.

Lighthouse

I think it would be better to have an own tagging for lighthouses.

"seamark=landmark

landmark=tower

tower=light"

is not enough. There are other towers with lights, but a lighthouse is a special seamark.

Not all lighthouses are placed on land. There are many lighthouses standing in water (Großer Vogelsand).

So my proposal for lighthouses:

seamark=lighthouse

We have to discuss the other tags for lighthouses. There are different kinds of lighthouses. (leading lights, sector lights...). Maybe it makes sense to create relations for leading lights to put together rear light and front-light

But the first tag should be "seamark=lighthouse".

--Klabattermann 22:10, 29 July 2009 (UTC)

I like that. seamark=lighthouse sounds simple and useful :) --Cbm 22:50, 29 July 2009 (UTC)

Beside lighthouses are not always towers. Along the Norwegian coast there are many that are on simple structures, houses, small huts, etc. I feel a lighthouse are any navigational aid in form of a light where no other seamarks are present (i.e. a single light mounted on a post on a small islet is a lighthouse, while a light mounted on a lateral buoy is a lateral buoy with light) --Skippern 01:55, 30 July 2009 (UTC)

Yes, that's another argument for using seamark=lighthouse instead of landmark=tower. --Klabattermann 09:18, 30 July 2009 (UTC)

• I changed the proposal-page :) --Cbm 12:08, 30 July 2009 (UTC)

I come to think of another reason to use seamark=lighthouse - it does not interfare with other tags that might be already on the same node/area. For example, it can already be tagged with building=tower, historic=ruin, tourism=viewpoint, amenity=place_of_worship --Skippern 18:22, 1 August 2009 (UTC)

• Is it really necessary to replace the already existing tag man_made=lighthouse? Wouldn't it be better to extend new tags to the already existing tag instead of a completely new tag? I know that seamark=lighthouse don't conflict with the already used man_made, and combinging the two tags is just unnecessary complicated. --Skippern 04:17, 17 August 2009 (UTC)

IMO there is no need to replace man_made=lighthouse. but für seanavigation we should use seamark=lighthouse to identify --Cbm 11:21, 17 August 2009 (UTC)

Clearance

Maybe the proposed tag for clearance can be used to tag the free sailing height under bridges? Proposed features/clearance I suggest clearance:sailing=* for that data, attached to the bridge as way or the highest point as node. --Skippern 23:38, 29 July 2009 (UTC)

Changed to maxheight:sailing=* in the proposal. --Skippern 09:51, 31 July 2009 (UTC)

maxheight:sailing=* sound useful for me, but what about tidal differences? --Cbm 18:33, 31 July 2009 (UTC)

"Free Sailing Height" is a definition based upon "chart 0", so it can always be corrected against tidal tables. FOr exemple, the bridge Gjemnessundbrua in Norway have a free sailing height of 42 meters, it is close to the port of Kristiansund. If the tide data for Kristiansund is 123 for the given time of the passage, you should remove 1.23 meter from the free sailing heigh. If the vessel air draft is more than 40 meters, I would not attempt to pass, if less than 40 meters than it is safe to pass. --Skippern 05:59, 1 August 2009 (UTC)

Most if not all countries define clearance heights with reference to a high tide datum. Britain uses HAT, Norway uses MHWS if I recall correctly. Around Kristiansund the difference might be up to 2,0 metres. So in your example, sailing Gjemnessundet should in fact be safe with at least 42 metres of air draught, as long as there aren't very strong wind effects increasing the tide beyond normal high tide levels. But you not attempting to pass is quite okay – better a couple of metres too much room for safety than a few centimetres too little! :) Arne Johannessen 02:12, 18 August 2010 (BST)

Sticking to examples from Norway, the incident with the Varodd bridge? Actually one of the last grand cruice liners built in Finland was too high to pass Great Belt bridge, but did so in a closely calculated stunt, with maximum speed on low tide, and funnels removed, but this is extreme cases. --Skippern 08:42, 18 August 2010 (BST)

Proposal is under vote, do let mariners decide the fate of this! --Skippern 19:01, 10 September 2009 (UTC)

Areas

On Seamaps you find many areas. (Roadsteads,military area, restricted area, nature reserve...). I think we need a tagging-schema for this.

My proposal: area=yes

waterway=roadstead|military_area|...

name=...

comment=... (for further information about area)

I already mapped a roadstead as example:

http://www.openstreetmap.org/browse/way/38308606

--Klabattermann 22:17, 30 July 2009 (UTC)

You can see it here: http://tools.geofabrik.de/osmi/?view=water&lon=9.55477&lat=53.61444&zoom=14 --Norftase 23:20, 13 August 2009 (UTC)

I think we should stick to the S-57 scheme, it is not that complicated as it is said here. Basically there are military areas, restriction areas, anchoring areas and some others

My proposal: New features

nautical_area=miltary_area military_area_type=firing|diving|mine_laying|practice|access_prohibited military_activity=air|torpedo|mine_warfare|amphibious_landing|firing...

nautical_area=restricted_area restricted_area_type=nature_reserve|dredging|turning|anchoring|offshore_production...

nautical_area=anchoring category_anchoring=general|deep_water|quarantine|explosive|tanker|sea_planes|time_restricted|pleasure_crafts

nautical_area=nature_reserve category_nature_reserve=marine_reserve|bird_sanctuary|seal_sanctuary|pssa|national_park...

nautical_area=dumping_area category_dumping=explosives|dredging_material|chemical_waste|wrecks...

for all areas restriction=anchoring_prohib|anchoring_restr|fishing_prohib|no_wake... name=... status=active|inactive|temporary... start_date=... end_date=...

for anchoring also point features Can anybody help me translate this into a proposal, i'm not familiar with this procedure. For those who ask about sense of these features: fishermen should know where to throw their lines in, where this is prohibited and what kind of things could be fished (see chemical ammunition in the Baltic Sea). --Venusman 07:33, 26 July 2010 (UTC)

• These tags actually have very little to do with S-57. But that's a Good Thing⁄™! I think areas are some of the most important features on a nautical chart and hope we'll be seeing these tags in a formal proposal soonish. Arne Johannessen 02:12, 18 August 2010 (BST)

Waterway=safe_water

I propose waterway=safe_water as an imaginary line in the middle of the lateral corridor. More details should becollected and discuused here --Cbm 15:16, 2 August 2009 (UTC)

It is rendered here: http://tools.geofabrik.de/osmi/?view=water&lon=12.12077&lat=54.16609&zoom=14 --Norftase 23:16, 13 August 2009 (UTC)

Maybe waterway=safe_water is not so good, because there is waterway=river and sometimes the river-way is the same way as the safe_water-way. Maybe we should change it to waterway:navigation=safe_water or something like this? --Norftase 23:17, 13 August 2009 (UTC)

Subsea assets

I suggest that we also find tags for subsea assets, such as pipelines, cables, well heads, fouls, seabed materials. There are also need for tags for platforms (oil platforms), fpso (floating production and storage units), loading and mooring buoys. I think skerries will be tagged with natural=rocks or an equivalent.

• Difficult to map most subsea assets. They're even more difficult to survey than a water depth surface. But sometimes beacons or buoys indicate anchoring prohibitions around cables, for example, so some inference is definitely possible here. Other than that, we're dependant on data imports from 3rd parties as far as available here I'm afraid. Still, we do need tags, of course. Arne Johannessen 02:12, 18 August 2010 (BST)

Around most platforms and fpso's there are a 500m safety zone (measured from the extremities of the structures), that should be marked on the maps aswell, same around some well heads. Platforms that does not stand on the seabed with fixed structures (floating) also have a series of anchors and chains around it, usually marked with a note in the maps. Same for fpso's. We should for this reason have a note:marine=* for such notes.

Some other areas that often are marked with borders on a marine map is dumping grounds, caution areas, special dangers, etc. One example of this is in the Skagerakk (North Sea) where there have been found mustard gas in fishing gear. A zone marked with Caution: Mustard Gas is tagged in the maps. --Skippern 01:22, 11 August 2009 (UTC)

color or colour - british or american english

with one do we wanna use? personally I prefer the american english, but that's just out of habit --Cbm 08:27, 5 September 2009 (UTC)

I prefer British English because OSM is from UK, because most of us learn British English at school and the English contribute much more to OSM than the American. --phobie m d 09:56, 5 September 2009 (UTC)

Maybe we can find any objective arguments for the one or the other? The fact that OSM starts in UK isn't enough, I think, because it's a world-wide-project now.

One objectiv argument could be, that S57 is also written n british-english. But is that enough? --Cbm 11:00, 6 September 2009 (UTC)

Yeah, what with the naval and cartographic history of the British Empire, one might argue that this is enough grounds for this decision. Also, the IHO is based in Europe... ;-) But the only real argument to be made are other tags already present in OSM. Are those British or American? If you find a clear example in Map Features or Tagwatch, follow it. Otherwise, take a vote or something and be done with it. :) Arne Johannessen 02:12, 18 August 2010 (BST)

Considering the key:colour exists and is beeing used for a multitude of things that i a good example. the key is sometimes used as color aswell. Acording to tagwatch colour 37000 objects and color 7000 objects. I think colour is the best alternative. --Thod 19:51, 5 December 2011 (UTC)

IALA Region A and B?

Two types of lateral marks exist: one in the Americas, the Philippines, South Korea and Japan (so called IALA Region B) and one in the rest of the world (IALA Region A). See [1] for details. I think we should distinguish between the two system in OSM (esp. in drawing). --Flomigulau 15:59, 6 October 2009 (UTC)

There is no need to differ between them in tagging, only in rendering, and if a map covers both regions, the renderer can be told where to use A or B by relations. boundary=maritime have documented how to tag the border between IALA Region A and IALA Region B, and hopefully the two relations will be in place in not too long time. --Skippern 22:21, 7 October 2009 (UTC)

tagging

See this changeset for an example how buoys would be tagged to corresponde with both tagging schemes currently in use for tagging of marine features. Both schemes in use simultaneously. --Skippern 16:00, 17 August 2010 (BST)

landmark-conspisiousy

as we can see here: User:Skippern/INT-1#E:_Landmarks we have nearly for anything on land a tag already. So it's only about conspiciousy, I think.

So I propose, to cancel the whole landmark=-thing but think about a

conspisious=*

conspisious:nautical=*

conspisious:nautical:visible=*

conspisious:nautical:radar=*

conspisious:aero:visible=*

conspisious:aero:radar=*

with values like

yes, promiment, obvious,....

Any suggestions? :) --Cbm 23:44, 28 August 2010 (BST)

INT-1 chart symbol S5 is for Radar-conspicious feature. This can even be for objects not mentioned elsewhere in INT-1, though there are chances they already are tagged in OSM. --Skippern 16:49, 8 September 2010 (BST)

height, depth, elevation

I guess, we have to discuss the usage of these words, to get a usefull structure of terms and meaning.

height -> vertical length of an object

depth -> vertical distance under a chosen "height-datum" (I guess "lowest astronomical tide" should be our choice?)

elevation -> vertical distance to mean-sea-level 

--Cbm 15:20, 29 August 2010 (BST)

elevation is covered by external SRTM data, and in general depth should be treated the same way (except for depth of objects) --Skippern 16:11, 29 August 2010 (BST)

SRTM is nonexistent north of roughly 61°N (and elsewhere), and sparse. Alv 16:25, 29 August 2010 (BST)

But the data should still be external. Some elevation points, such as peaks, should still be in OSM, but any data to generate height curves should be external. The map would be impossible to edit with all height and depth data in it. --Skippern 16:27, 29 August 2010 (BST)

Who wrote anything about drawing extra contour lines? I'd love to have elevation figures for all lakes in Finland - the vast majority of them don't change significantly, not by tides nor by the season. Or on any object where the elevation is constant or a spot height. Alv 17:14, 29 August 2010 (BST)

e.g. lights of lighthouses have elevation-value. and catching depth is not so trivial. on the one hand we can tag a depth-point with ele=-xx but also with depth=yy but only with depth:datum=* or anything like this. so I guess ele= would be easier, but on the ocean ele=-20 has no use without knowing the waterlevel. also interesting if we focused on tidal-areas --Cbm 23:26, 29 August 2010 (BST)

If we use ele=-xx than it must refer to same 0 point as ele=xx, which I believe is highwaterline. Or else there will be a gap of heights in the tidal water belt. --Skippern 02:48, 30 August 2010 (BST)

If I read INT-1 right the chose height-datum is "mean-sea-level" --Cbm 06:30, 30 August 2010 (BST)

Again, nautical charts typically have three different height datums (see S-4 sections B-405, B-380–B-382, B-302):

• Chart Datum (CD) for depths and drying heights is typically zeroed near low water level,
• Height Datum for clearance heights beneath bridges etc. is typically zeroed near high water level, and
• Height Datum for topographic heights of mountain tops etc. is typically zeroed at mean sea level.

Accoording to S-4, the two height datums are supposed to be identical, but in my experience they frequently are not. Also, some countries use a fourth height datum for overhead power cables (as recommended by the IHO), but chart producers and users are frequently not aware of the distinction; some countries even use a fifth height datum for landmarks and lights. Additionally, depths in nautical charts are not usually actual (bathymetric) depths, but Nautical Depths, which are typically lower for safety reasons. The lines described in INT 1 as symbol I30 accordingly aren't really “depth contours”, but rather nautical warning lines (cf. Stocks 1956) and as such do have a place in OSM. Arne Johannessen 12:25, 30 August 2010 (BST)

We will need a way to represent these kinds of distinction in OSM, because we're going to be confronted with heights and depths in some if not all of these contexts sooner rather than later. On the other hand, we don't need a discussion about precise cartographic vertical reference systems (LAT vs. MLWS vs. MLW), because we typically don't have data accurate enough for that to be of any concern anyway (cf. Behind the Nautical Chart for accuracy in hydrographic surveying). That might change at some point of course, and I'm hoping it will. For now, just agreeing on a way to tag maximum, minimum and average water levels will go a long way. Suggestions:

• tagging depth: distinguish between (and find tags for):
  • minimum depth, “a low water datum” [sic!] (for navigational purposes)
  • “maximum depth” (useful for beaches and lakes, e. g. “can I stand up in the water there?”)
  • “average depth” (typical/bathymetric/mean depth – e. g. for ocean basins where tides aren't important, or for lakes which rarely reach their extreme water levels, or for areas of little tidal range like the Baltic)
• tagging clearance heights: find some suitable variation(s) of existing tag maxheight=*
• tagging topographic heights: existing tag ele=* (which is ill-defined, but that's besides the point)
• tagging heights of landmarks and lights: best to use the topographic height (ele=*), simply because it is by far the easiest one to survey

• • maybe we should tag light:ele= with a plus. e.g. light:ele=+8 so that it's clear thats it's +8meters above the elevation thewaterlevel has? --Cbm 18:13, 30 August 2010 (BST)

I believe that light heigh generally are noted above mean water level (MWL). I rather see this tagged light:height=* with numerical value of meters above MWL, while height=* on the same light above ground will be tagged height=* and the base where the lighthouse stand (ground level of the light) is ele=* --Skippern 18:24, 30 August 2010 (BST)

• tagging object heights above ground: existing tag height=*

Obviously, we won't always need every one out of this plethora of values tagged. Having any single one of them already goes a long way in giving a good first impression, and adding all would in fact be redundant anyway. But because we're going to meet these different kinds of data in the field, we'll need a way to distinguish them by appropriate tagging. Arne Johannessen 12:25, 30 August 2010 (BST)

This give even more reason to follow my suggestion of only tagging depth on objects, and leave the general depth to be handled by a separate database. There is a project somewhere of making a free Bathometric databasa similar to SRTM, but data harvesting are only in the beginning yet. --Skippern 14:10, 30 August 2010 (BST)

INT 1 table

Tables of the INT 1 sections can be included with the templates {{Table:INT-1:header}} + {{Table:INT-1:}} + {{Table:INT-1:footer}} (where # is (capitol) letter of chapter) --Skippern 16:09, 8 September 2010 (BST)