In Norway we have lots of toponyms referring to groups of things, including lakes, so it bothers me that there isn’t any developed standard for mapping these things. I’d like to make some proposal for lake groups, perhaps mirroring Tag:place=archipelago - OpenStreetMap Wiki. But first I want to gather some creative input from you guys.
How would you like to see this lake group represented?
As a multipolygon, or some other grouping relation?
Under which main tag? place=..., natural=..., water=...?
What makes these lakes to form some kind of official group? Is it just the same name, expanded by the prefix “Inner” and “Ytter” or is there any other reason making these lakes form a group?
If it is just a matter of the same name used for natural features which is quite common in many countries all over the world not only for lakes but also for peaks, streams and other locations I would not see any additional value to create “group relations” for those.
An archipelago is another issue - the grouping of the islands is not due to name sameness, but does have some geopolitical impact at least.
If there is no profound reason for grouping such natural objects I would refrain from it.
There is a registered toponym in the central Norwegian place name registry, referring to these two lakes as a union. The criteria for inclusion in said registry is usually some level of usage over time by the local population. It is the existence of a commonly used (and in this case official) name for the group that makes the group interesting to map as such.
The group name is plural, while the lake names are of singular form, so not the same names. “Inner” and “ytter” mean “inner” and “outer” respectively, implicitly referring to the group. Note that both the lake names and group name are official names.
A hypothetical example in English with similar structure:
Group: Bear Lakes
Lake 1: Outer Bear Lake
Lake 2: Inner Bear Lake
The Norwegian names don’t refer to bears, but that’s not the point.
Struggling to follow what you mean here. What do you mean by “same name”?
I don’t see the difference you talk of. This has nothing to do with name similarity. It has to do with the existence of a name for the group. Same thing with archipelagos. Also, how does archipelagos have more geopolitical impact? Furthermore, when did geopolitical impact become an interesting criteria to decide what to map in OSM? People map trash cans.
Is the existence of an official toponym not a profound reason to you? If so, why not?
I’m not familiar with all the details of how they have bumped around in OSM over the last couple of decades, but I do know that the Great Lakes of North America have had their fair share of difficulties in how they are expressed in OSM (there were some “coastline” issues if I recall correctly…) and they certainly are a (pretty major) “hydrological system” unto themselves.
Some of the issues surrounding the Great Lakes might shed light on what you might be trying to achieve here.
You could use the proposed group relation for this. On the relation, the tags type=group and name=* should be sufficient unless there is more you want to add…
What’s the difference with the more popular type=site? Their descriptions seem to overlap a little.
type=site "A site relation is used to group several objects which together have a single identity as a whole but cannot be accurately described by other data types. type=group “The group relation is used for groups of things that share a common name or other property as a group.”
The difference is that a site requires a tag to describe what it is about, because it is typically a mix of different things, while a group consists of same things and does not a require additional tags because can infer from its members what is it.
However, that restriction limits functionality. For example, just recently I mapped a lake in my area whose one part is natural=water but a significant part is a natural=wetland; wetland=bog, and yet another is wetland=reed_bed. The parts are separated by causeways, but they share a common name. I can see the feature being potentially useful for other kinds of (semi-) heterogenous object groupings.
I see type=site as applicable to man-made features, while type=group more suitable for natural features, but ivanbranco indeed has a point that there’s a potential overlap, and a gray area between.
For example, just recently I mapped a lake in my area whose one part is natural=water but a significant part is a natural=wetland; wetland=bog, and yet another is wetland=reed_bed. The parts are separated by causeways, but they share a common name. I can see the feature being potentially useful for other kinds of (semi-) heterogenous object groupings
that’s a site, sites are not limited to man_made features IMHO.
I would like to mention type=cluster has similar numbers as type=group. It’s true some in both are used wrongly, but attempts to correct them are also affected by some unproposed mass re-tagging =cluster to =group in the past, as I have discovered earlier this year. Proposal talk:Cluster (2015) - OpenStreetMap Wiki
I prefer =cluster as the wording is less vague and misleading than “group”, which is prone to misunderstanding and misuse as exemplified by worry in Proposal talk:Group Relation - OpenStreetMap Wiki question. “Cluster” emphasizes each object is an individual entity, related by a common name. This contrasts well with =site as it represents one “site” with a feature tag, having different parts inside. =cluster or =group may not be limited to “natural” landforms. I have floated the idea on whether bridge-tunnels and multiple parallel or serial crossings (consisting of several bridges and tunnels) could also be applicable (which are not appropriate for type=bridge and type=tunnel), as well as disconnected groups of arts (depending on how its tagging is to be solved).
I have the feeling you misunderstood my post. If the 2 lakes form some kind of a local ecosystem and/or there is a common name for the group this is a profound reason to create a group for them in OSM as well.
If 2 lakes do just bear the same name with some prefix like “inner” and “outer”, “great” and “small”, “upper” and “lower” etc. because the lakes are so remote and unimportant that nobody cared about giving them different names then there is no reason to create a group for them in OSM imho.
There are lots of such places given names like for instance “Kleiner Dachsberg” and “Großer Dachsberg” for 2 peaks being close to each other (meaning “Small badger mountain” and “Big badger mountain”) without them forming a kind of group. These are just names and nothing more than this. For those I would refrain from creating any kind of group relation.
I’m ok with anything as long as it doesn’t involve individual ways being part of several relations - i.e. I would advocate for some kind of cascading model.
In Copenhagen, there is what looks like four individual but neighbouring lakes: Relation: 6244787 | OpenStreetMap - and to make matters more complicated, two of them together form a lake called “Sortedams Sø” …
I might have, yeah. Sorry if I sounded slightly rude.
Let me see if I understand you correctly: your opinion seems to be that if I came across two lakes named e.g. Outer Bear Lake and Inner Bear Lake, i shouldn’t just “invent” a grouping called Bear Lakes because of the nominal similarity.
If that is the essence of your opinion I wholeheartedly agree with you. And it seems you understand that this is not what I’m trying to do here either. I realize in hindsight that it would be easy to get confused about this from my initial post, though.
Just a quick look along the Idaho-Montana border gives the Blossom Lakes, the Bonanza Lakes, the Oregon Lakes, the Trio Lakes, the Steep Lakes, the Siamese Lakes, the Cedar Log Lakes, the Middle Fork Lakes, the Two Lakes, the Twin Lakes, the Triple Lakes, and probably a bunch I’ve overlooked. Sometimes individual lakes will get descriptors such as “Upper” and “Lower” or “Large” and “Small”, but it’s fairly common to simply refer to a group of lakes with a single name.
My impression is that the issues surrounding the Great Lakes mostly has to do with their enormous size; both the individual lakes, as well as the grouping. I don’t think we have any lake groups in Norway of such a size that a e.g. a multipolygon would start becoming unwieldy if it was used to represent the group.
That being said, I’m not opposed to finding a unifying solution that will work for both large and small lake groupings. I just have to admit that it’s more of a “nice to have” for me, rather than a necessity.
I’ve encountered this proposal before, and I find it intriguing. I’m open to the idea, but there’s a few things holding me back.
The proposal seems to still be in draft mode, which makes me uncertain about it. If I were to map a bunch of lake groups using this schema, it would be frustrating if it was rejected at a later point. To address this we could probably shepherd the proposal though the full proposal process, perhaps with lake groups as an explicitly described special case.
I’m a bit skeptical of the the idea of implicitly inferring the group type for two reasons:
Moving more work from the mapper onto the renderer can slow down adoption on the side of data consumers, which again makes it less appealing to make use of the schema.
I also think it makes validation way harder, making it very easy to ruin a group relation. If a mapper by accident adds a non-lake to a lake grouping relation they won’t get a warning as you still have a valid group; it just stops being a group of lakes. Perhaps just a group of “natural features” or something. Explicitly stating what your group is supposed to consist of is a good thing. It can work a bit like a type annotation in a programming language. A Python type checker will yell at you if you try to add a float to a list[int]. We want the same in OSM in my opinion.
Neither of these obstacles are insurmountable, though.
I might be misunderstanding, but is this the same problem? Isn’t Lake Saimaa a single lake with potentially lots of named bays?
Don’t get me wrong; this is an interesting problem too. There are lots of lakes with sub-parts that are named like full lakes in their own right, and there are some questions as to how to tag these. The solution to this problem might be the same as mine, or it might be a different one. Do you think they should be tackled together?
I’m open to consider this one as well, but I note that this proposal hasn’t gotten approval either. It would then need to be revived.
I take it that you’re not a fan of using a multipolygon, then? I see that point. As a mapper it makes more sense to me to construct a relation where the lakes them selves are members. It means less work both in creating, but also maintaining the relation.
The counterpoint is that multipolygons already have seen widespread adoption, meaning that the path to seeing these groups rendered is probably shorter if we go with a multipolygon.
Thanks for making me aware of this case. This is exactly what I want to tackle.
A site relation is ok, but a problem I have with it is that it is hard to determine what the site type is when the site has many additional tags alongside the intended “main” tag(s). There also doesn’t seem to be much renderer adoption despite this pattern existing for a while. It is worth asking why, and if it can be improved on.
Thank you so much! I think this thread benefits from documenting concrete examples. That makes it easier to verify that a schema is applicable to any weird edge cases. It also provides a sense of scale of the “problem” at hand. Feel free to share any group relation links if you encounter any.
I’m a bit skeptical of the the idea of implicitly inferring the group type for two reasons:
Moving more work from the mapper onto the renderer can slow down adoption on the side of data consumers, which again makes it less appealing to make use of the schema.
yes, it makes it more difficult for data consumers when they have to infer information from the members, there could be some logics in tools like osm2pgsql to move the information into the resulting db, there would be at least 2 useful ways, one is creating a central point with the name, size and type (e.g. water related, natural feature related, peak related, place related etc.), where the type ultimately depends on the targeted map style/distinctions you want to make.
The other is adding information from the group (e.g. name and type) to the individual members as synthesized tags, (in the simple form this would not work if they are at the same time part of several groups that you are interested in, do you have an idea how to solve it?).
It is not something to expect very soon but would come if this way of mapping became popular
I also think it makes validation way harder, making it very easy to ruin a group relation. If a mapper by accident adds a non-lake to a lake grouping relation they won’t get a warning as you still have a valid group; it just stops being a group of lakes.
this is up to the data consumer how fault tolerant they want to be. Generally, it is possible to add specific tags to group relations, it just isn’t required. Do you suggest to invent specific tags for every kind of group imaginable, e.g. group of lakes, group of peaks, group of trees, group of rocks, group of farms, group of sculptures, group of ponds, group of springs, group of villages, group of islands (this one has already a specific tag), …
Would be doable,thinking about it there are not so many.
Perhaps just a group of “natural features” or something. Explicitly stating what your group is supposed to consist of is a good thing. It can work a bit like a type annotation in a programming language. A Python type checker will yell at you if you try to add a float to a list[int]. We want the same in OSM in my opinion.
but it depends on the context, maybe “natural” feature is sufficient for you, maybe you want to distinguish mountains, water, forest and more. I think requiring the group members to be „of the same kind“ (tagging wise, not regarding the geometry type) is an essential requirement, otherwise it is a site or something else.