Yes, it is used few thousand times but it is minuscule compared to normal tags. Maybe it would be possible to deprecate this tags and use normal tagging? And use say ref=1 instead of seamark:berth:name=1 ?
Main benefit would be avoiding special tagging of standard property for one specific object type. Which is just confusing with no redeeming value.
Yes, deprecation would also add some confusion and editing affected objects would require editing them and adding a new entry to object histories. And update for data consumers if anyone is using this tag. And probably having duplicate tags for some time.
BTW, seamark:berth:name | Keys | OpenStreetMap Taginfo lists no project using this tagging. Obviously, it does not mean that noone is using this tagging, there may be some projects not listed there.
I also deeply dislike seamark: graffiti in property keys like seamark:type=berth but I guess that ship has sailed on this one and it is too late to fix seamark:type:* tag family?
But reinventing ref= etc in key specific to given feature seems to be a far worse offender.
Caveat: In cases that are not ref= , name= corresponds to seamark:*:national_name= , not seamark:*:name= (being name:*-Latn= specifically in some guides, not name:en= either) description= is a mix of seamark:*:national_name= and seamark:*:national_information= (again worse in some guides: seamark:*:information= needs to be description:en= on the contrary , not description:*-Latn= as opposed to seamark:*:name= )
As you can seen, it has many standards itself, and is very confusing. Using OBJNAM for all of name= , ref= , and description= is its shortcoming, where OSM is better.
That is at least a bit misleading as it implies “nobody” is using the tag, but naturally, openseamap does use it. It seems you are hell bent on replacing ATYL (which includes sub projects and communities ability to design their own tagging schemes, and to be ignored if necessary) by ATML.
I am going to interpret this one as “it should be kept as is”.
And yes, if people in general will not be enthusiastic about this idea I will just ignore this tagging schema (I am doing it with many other already), and be less likely to make similar thread about other similar case.
And if I would be doing “everything must be done in way that I like” then OSM tagging schema is a really bad place to do this, and guaranteed to end with pointless frustration if approached this way.
Looking at the example on the wikipage, it looks like much of that tagging comes from imports. Sure, OpenSeaMap uses it and would have to be on board with any such switch, but it’s not like some mapper painstakingly designed this scheme to be able to map this in OSM. It’s just copied from existing standards to make imports easier.
Without much regard for OSM, I might add.
My impression was that this thread is supposed to gauge opinion rather than immediately deprecating it. If you’d like to add people to this conversation, you can just do so.
We can still discuss whether the tagging could be improved. If there is no discussion, how can we find that out otherwise?
I don’t think questioning the intentions is necessary at this point.
Time spend on editing OpenStreetMap wiki, making tagging proposals, making bot edits, discussion on OpenStreetMap forums would NOT be covered by this proposal and would NOT be paid for.
part. That I put deliberately put there myself. As either of these could be potentially controversial and it could make it worse.
(and me getting involved in either is neither new nor something that I planned to change*, though depending on various things I may do them differently)
*though maybe not planning to do so was a strategic mistake, and I should avoid making any tagging schema proposals or starting any deprecation discussions. Maybe also I should avoid participating in either.
Also, it was not posted on OSM Weekly, I have not researched who may be using this tag, not contacted Seamark community, not investigated where seamarks may be discussed, I have not made proposal on wiki, I have not contacted people who used this tag etc.
Because if this probing thread will not have a clear support then contacting all relevant people is premature. This makes sense only if it would seem that there is a real possibility for going with it. Maybe it is actually a good tagging schema and I miss reason why it was done this way.
Or it should be kept in the same way as highway=unclassified will be kept despite being deeply confusing and unfortunate.
I tend to agree, that it’s common OSM practice to tag the name/reference of an object in name or ref. Sure I can add that information to any other key based on ATYL. But that doesn’t mean others can’t shift the information to commonly used tags.
Applying above logic to your question, it makes sense to deprecate seamark:berth:name= and advocate a transition to name, ref or description. But I don’t see any reason to deprecate seamark:type=berth since there is no such common other way (AFAIK).
Seamark tags are a right royal pain in the posterior, but mostly not for the problem you state. The problems become clear once you start thinking in terms of real world objects, rather than just OSM (or seamark) keys and values.
Let’s take a simple example to start with - a rock. There are obviously examples of those mapped as natural=rock without seamark tags, but the converse of that is also true (mapped without natural=rock with seamark tags). Some of course have both.
Where an object is mapped with one set of tags or another but not both, you can’t assume that there is only one object in OSM. This lighthouse looks like a duplicate of this one, and likewise this of this.
You can’t fix these problems by “deprecating” tags - only by examining the seamark data and merging it where it’s pretty obvious that an seamark object is a duplicate of an “OSM” one. After this conflation it absolutely makes sense to ensure that something for which OSM tags are appropriate (like a rock or a lighthouse) actually does have those tags.
I’ve spent a bit of time over the last couple of days going through seamark tag usage in UK and Ireland, and have made a start on conflation where it obviously needed doing - although there the establishment needs a survey because it’s apparently changed hands (maybe @Richard will have a bit of local knowledge there).
Back to the original question - a seamark:type=berth is less challenging than some examples, because it is basically a “maritime thing” (although actual usage for berth type things, such as mooring, can be iffy). A seamark:berth:name is just the name for one of those, and given the combinations, any sane data consumer would want to check both anyway. Separately to worrying about keys and values, let’s worry about OSM objects - does this chimney actually exist? Shouldn’t it have a man_made=chimney tag if it does?
The problem is, while I’m not in love with the seamark tagging scheme (as probably most readers of this are not), simply changing certain tags in it without buy in from that community, particularly given, as you noted, it is tagging that is only actually consumed by that group, just breaks it for them without any notable gains for anybody else.
If you think that ship berths are something that should be mapped with conventional OSM tagging then propose that and we can double tags things at least for the immediate future and maybe migrate later on.
It is not imported. Some parts are, for instance ENCs are public in US. And it is using a norm. You may dislike S-57/S-101 standards, but they are standards. To check the rendering of a navigational cart you have a 256-page document. And it doesn’t check everything, just the very top of the iceberg. If you want to reinvent the wheel, just do. Come back in 10 years or more (likely ways more), and with the corresponding converters.
Even moving from the good old S-57 to the S-101 isn’t straight forward.
@SomeoneElse yes, the mentioned duplicates seem to be duplicates. But as you said, nothing easy (you can have lights close to lighthouses), be nothing special here: if you don’t know, you don’t do, you may reach the authors of the two objects to check.
Standards are fine, and standards change. Btw, are you (as in, the nautical community) going to change the tags in OSM to reflect the S-101 standard?
Of course, we have the privilege of moving incrementally. If the switch gets approved (and that may well take 10 years), not everything has to be done on day 1. Arguing that it’s a lot of work doesn’t really help here, considering that creating the map in the first place was a lot of work too!
You should do some basic research before commenting on a topic. =berth are at shore, the size of a ship. =anchorage are towards the sea, accommodating multiple ships, with plenty of space to travel and maneuver. =anchor_berth are the spots inside.
1,2,3. This is consulting on the deprecations. The next steps will be taken later. Is announcing in the wiki article and informing authors during the process required, expected, and needed though?
4. Depending on your definition of “technical”, there is. It mixes names and numbers together, and they can’t be recorded separately. The languages and scripts to be used aren’t specified clearly, at least on wiki. The standard is fundamentally flawed.
5. Someone has to do the work, whether volunteer or paid. There’s no conflict of interest here.
6. These are universal attributes. All fields should have a level of quality, and be understandable and acceptable by outsiders and newcomers.
As you don’t make the difference between an anchorage and a berth, you’ve first to understand the basic concepts. For information, OSM is based on S-101, one difference being pontoons being part of the skin of earth (S-57) or not (S-101). If you don’t understand skin of earth, read group 1 .
.