[OSM-talk] Tagging Seamarks

[Christian Wagner]

> 
> > So it would appear that we actually have
> > * one official proposal, currently under discussion (also used by FT)
> > * one private scheme, with private tags (exclusively used by OSeaM)
> > 
> > Now, the thing is I'm not really sure about this assessment. What I wrote
> > above is my current understanding of the situation, which may be wrong.
> > I'd appreciate input from FT or OSeaM project members on this matter, or
> > really from anyone at all!

You are pretty much right about that.

> > > This is extremely frustrating!
> > > Computers do not care about attribute names and we shouldn't also as long
> > > as both schemes fulfill the same requirements.
> > 
> > This is not just a naming issue. The tagging concepts of the schemes are
> > rather different (contrary to what has been alleged somewhere on the
> > Wiki).

Can you elaborate a bit about that? From what I found out by comparing
it myself I get the impression that everything that could be described
by one taging scheme could also be done by the other. Only thing is
that the "official" proposal can be much does it much more the "OSM-
way" (e.g. human readable and writeable! tags).


> > Anyway, one thing I find particularly remarkable is that on just about
> > every one of the Wiki pages, someone wrote something about that this
> > tagging scheme "followed" IHO standard S-57, and how important and cool
> > that would be, while actually (and thankfully), none of those schemes even
> > come close to S-57.
> > 
> > S-57 is basically a soon-to-be-obsolete, proprietary and binary file
> > format, so "following" it wouldn't really make a lot of sense for OSM. Not
> > sure why so many people wrote that. Perhaps someone on this list is able
> > to enlighten me?

I'm not sure if S-5 is soon to be obsolete. It is my understanding tat
there are a lot of professional grade chartplotters around that can
understand that format, so it should work for quite a while. Also (this
is probably wrong, I picked it up in the cruisersforum somewhere) S-57
is a non- encrypted vector format, whereas all the following ones are.
A very important thing for a free as in speech mapping project. For
example- S-57 format is, apart from the old cm93 format, the only
vector format that the open source chartplotter "opencpn" (opencpn.org)
can understand- simply because it could be implemented royalty free.
> 
> Arne,
> 
> I'm a little bit more into details of all that, yet.
> The approaches of FT and OpenSeamap are a little bit different. OpenSeamap uses 
> the OSM database exclusively while FT has its own database (as far as I 
> understood) and they put just some pieces of information into the OSM 
> database. Also FT puts just an overlay on top of the Openstreetmap map but 
> Openseamap completely renders a seamap with focus on seamap features.
> 
Which, for the ordinary user, is basically the same. What you see is
the ordinary OSM map as a background and some seamarks on top (the ones
from OSeaM are a bit nicer IMHO- but anyways.)

When you say that FT put "just some pieces of information" into the
OSM- database- it sounds a bit untrue IMHO. To my knowledge they just
have the defaults for some of their objects to be exported to the OSM
database turned off. You can allways opt in to export. A big junk of
their data comes from the OSM- database itself, so it doesn't need to
be exported anyways (contrary to OSeaM- FT can understand the OSeaM-
taging scheme).
> 
> Regarding the tagging schemes. Openseamap uses this "proprietary" seamark:*=* 
> scheme but FT uses just a subset of the official proposal. There is page which 
> documents it:
> http://wiki.openstreetmap.org/wiki/DE:FreieTonne/Symbole
> (It is in German but if you take a brief overview you'll partially understand 
> it (German words: Bake=beacon, Tonne=buoy, 
> Leuchtfeuer=light,Rot=red,Weiß=white,Grün=green)).
> This is the reason why I personally favor Openseamap more than FT. In 
> addition, FT is focused more on inland waterways.

I wouldn't say it is focused more on inland waterways- there are just
much more, and much more different objects that could be mapped on
lakes and rivers than there are at sea. 

Using a subset of the official proposal is often enough to get your
icon rendered correctly. Often you don't have much more information
about a seamark than basic type, color, shape, topmark, light yes/no.
These are just five basic key/value pairs.

Radar beacon, sound, light characteristics, -color and -period are
information, often not available to the ordinary mapper if he just
passes a buoy by day. Mind you, I do not mean to suggest that the
marine tagging scheme should be unsophisticated- and the proposed one
isn't- as said above, you could describe everything that the OSeaM
scheme can, If not, add some keys- what's the big deal?

>  A further question for me is what is "official" and what is "private"?
> Both of those tagging schemes are similar although the structure is different, 
> as you mentioned. And, what is IMO much more important, the Openseamap scheme 
> is already rendered on OpenSeamap which is not true for the other one and I 
> stick with the opinion of the Openseamp guys: a seamap should be rendered 
> different than a street map because different objects are important.
> 
As said above I don't see a big difference between the two products-
both are basically Mapnik with seamarks on top. If you would live
around Rügen island (I don't BTW) you would be mad that the data that has the
proposed marine tags isn't rendered by the OSeaM guys.

> However, as an IT guy I prefer the Openseamp scheme to the offical one because 
> it is more modular from a technical point of view. Thus, I hope that people 
> out there do not still ignore the Openseamap scheme. After all, I translated 
> it into English ;)
> 
> Regarding S-57: I think what they mean is that they orient on the S-57 schemes 
> in respect to which attributes exist on which objects.
> 
Which doesn't matter much. Mkgmap can translate OSM format into Garmin
format- both have absolutely nothing in common and it does work quite
well. Having a nice, human readable and writeable taging scheme eases
the actual mapping (which is by far the biggest, most work intensive
part in the generation of an open source map) by a huge amount, while
having a complicated but easy to translate scheme eases the work of the
programmer who writes the converter. This just has to be done once. 

Not rendering  all the data is available and promoting double taging is
a waste of time and effort for the mappers too. 

Which way is more efficient?

Cheers, Christian