Re: [Tagging] Fuzzy areas again: should we have them or not?
Thanks Kevin, point taken ;-) To summarize. This is the way I interpret this situation: OSM is a geodatabase, with a design that makes some geodata suitable for it, others less so. The overall design is not likely to change to accept more types of geodata, instead we would rely on extra data sources to generate maps which require data that is not suitable for OSM, such as elevation data for contour lines and possibly fuzzy areas for names. If fuzzy areas fit into the current OSM database or not is something we in the community don't agree on. Some of us think it does, others don't. Some think they are useful to making maps, but still not suitable for OSM. Some think they are not really useful or at least not important for maps either, they haven't seen a need for them. It's not only about generating maps, it's also about being able to ask the database if location X is located in the Red Sea / Sahara desert / other named but fuzzy area, or not and similar questions. If we want OSM to be able to cater such queries is really interesting and something that haven't been discussed much so far. It's hard to make constructive discussions on solutions when there is no agreement on that there is a problem that needs solving. Here we are exactly in that situation, we have not really come to the point to agree on a problem to be able to discuss solutions. My personal OSM-related interest for the time being is in map generation especially in rural and "uninhabited" areas, and making mainstream OSM-based maps better in those areas. OSM database is however both a superset and a subset of the data needed for generating these type of maps. While I personally desire that OSM database and its default renderer should be developed in a direction to "fill in the gaps" this is not a goal of OSM at large. I was naive in the beginning and thought that was the case or at least a desire shared by many in the community and that the type of map features I need would be seen as mainstream, but clearly it is not. Instead the enduring view is that the type of mapping I look into is better suited for OSM combined with extra data sources on the side and a custom renderer. Although I rather would see OSM moving towards grasping over a larger feature set which includes more of what I believe to be quite central to classic cartography and "what should be in any map", I stand more alone on that desire than I thought I would. This does not mean that there is any specific hostility against cartography, but there seems to be quite different views on what features that are important and not in maps. In other words many aspects that I thought was obviously important is not considered that by many/most OSM contributors. This fuzzy area thing touches exactly on such a subject and is therefore quite difficult to discuss. I think though it's already quite safe to say that there is not enough interest to make this a mainstream feature of OSM. It's also safe to say that those small scale fuzzy areas already exist in OSM and is manifested in various ways, so there are clearly not just I that need them in mapping. But I have no idea how we could move from that state. /Anders On 2020-12-22 00:16, Kevin Kenny wrote: Anders has been a bit confrontational___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fuzzy areas again: should we have them or not?
Thanks for the feedback Frederik, appreciate it. I don't think it's entirely fair though. I certainly don't write every day. Indeed I can write a lot as I'm quick on the keyboard, and I should probably try to be more on the point, that's fair. I have a tendency to get into sidetracks when talking about things that interest me, like maps. But if you look at it, it's a starter email, then it's just replies to replies. I started two threads yesterday. Anyone is free to reply at the speed they want. If replies come slower, my responses to them come slower. If I have less time to reply a certain day, my replies come slower, (I usually don't start threads busy days though). I don't require people to reply fast, never had. It's a thread, people don't need to dive into threads dealing in issues they are not interested in if they don't want to. And I certainly don't think I win if people don't reply, why would I do that? It's not really even about "winning" an argument, I don't see it that way, it's about presenting a viewpoint and the needs and argue for that and hopefully convince people that there is a need somewhere. If someone doesn't reply I just read what their last statement on the subject was. I don't invent new emails in my head that say "I agree" :-). But I'm not blind, I see it's not working out well, so regardless of what I think is fair or not I need to change the style or just back off. It's not that easy though when being passionate about a subject. Sorry for that. /Anders On 2020-12-21 22:08, Frederik Ramm wrote: Anders, On 12/21/20 21:36, Anders Torger wrote: Actually it seems to me that thinking about several tags at a time seems to be a fairly new concept ;-) I think this is approximately your 15th message today on the tagging list. Together, without quotes, you have written about 5,000 words of original content. Now, we are a community and your opinion is not worth more than that of others on the list of course. The total number of regular contributors on this list is perhaps around 20. If every one of these 20 wrote as much as you do - as would be their right - we'd end up with about 100,000 words on tagging, every day. The average reading speed of most adults is around 200 to 250 words per minute (and that does not include spending time to actually think about complex problems, just reading and understanding). If every one of the 20 active contributors were writing as much as you do, we'd each of us have to spend more than 6 hours reading this list every day. Even just what you wrote today takes 20 minutes out of the day of the average reader (and again, this is only for reading, not for thinking about the problem). Please consider that many of us juggle many different responsibilities, including work, family, or mapping. The next time you make a point, or raise a topic for discussion: 1. Ask yourself if there's another big discussion currently ongoing. If yes, maybe postpone the thing you want to discuss. 2. Ask yourself if you have already written more than 1000 words today. If yes, maybe postpone your message. 3. If you have just started a topic and people are, slowly and as their time permits, responsing to what you have written, resist the urge to fire off an immediate reply to everyone who writes something. This is not "Anders Torger versus the world". You can raise a topic, then you should give everyone some time to think about it and say their opinion. If you write so much that others stop replying, it doesn't mean you won; it means you have ruined the medium. Bye Frederik ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fuzzy areas again: should we have them or not?
Sorry, forgot to add that an alternative to fuzzy areas would be to do
like hamlet/village/town/city etc and have a bunch of these point names
for various natural features that we could place out instead of fuzzy
areas. Do you think that is better?
That combined with an external database for huge areas ("the Alps")
would fulfill most needs. Shaping text for the small fuzzy areas is not
really much of a thing so point naming would be satisfactory, but would
be quite many tags that needs introducing, while the fuzzy area is more
a continuation of areas that already exist and are to some extent
already in use. I also think a fuzzy area does provide some valuable
information and requires the mapper to make a healthy think over what
the name actually refers to and covers, and avoids the issue of "which
tag size to use".
That said, I would pick hierarchical point naming over nothing any day.
/Anders
On 2020-12-21 19:30, Mateusz Konieczny via Tagging wrote:
Dec 21, 2020, 16:42 by zelonew...@gmail.com:
On Mon, Dec 21, 2020 at 8:01 AM Frederik Ramm
wrote:
Our current data model is not suitable for mapping fuzzy areas. We can
only do "precise". Also, as you correctly pointed out, or basic tenet
of
verifiability doesn't work well with fuzzy data.
The current data model works just fine for fuzzy areas: it requires a
polygon combined with tagging that indicates that the area is "fuzzy".
Since the current data model allows both polygons and tags, fuzzy areas
could be mapped just fine from a technical standpoint.
Bigger problem is that with things like mountain ranges there are
multiple differing opinions
about borders.
For example in case of https://pl.wikipedia.org/wiki/Beskid_Wyspowy
multiple authors
give precise, unfuzzy borders (specific rivers or roads).
But different authors prefer different borders.
See for example https://en.wikipedia.org/wiki/Borders_of_the_oceans
and
https://en.wikipedia.org/wiki/Boundaries_between_the_continents_of_Earth
for other kind of differences. Modelling this is not fitting well how
OSM works.
So the one questions is, do we want fuzzy areas, the other is, if we
want them, how can they be established - because in our current
database
they cannot.
I think fuzzy areas make a lot of sense for cartography, but I
strongly
object to people adding hand-wavy polygons to OSM for fuzzy areas.
"Whether we want fuzzy areas" and "how they can be established" is
certainly an open question that requires additional intellectual
thought and consensus-building to achieve. However, the statement that
they "cannot" be established in our database is simply an opinion, not
a technical barrier.
I would not say cannot, but it is extremely poor fit to OSM data model
and how
OSM operates.
The statement that fuzzy polygons is "damaging" is an argument not
based in fact. It is not damaging to me to have building outlines,
which I do not care about. I can simply ignore them. Likewise, fuzzy
areas cause no damage to people that do not care about fuzzy areas,
provided that there is tagging that distinguishes them from non-fuzzy
areas.
It is not so easy. Someone mapped several fuzzy areas in my regions and
all of
them are extremely irritating while mapping.
Building outlines are not stretching for hundreds of kilometers and do
not appear in places where there is nothing at all and building outlines
are verifiable unlike mess like
https://www.openstreetmap.org/relation/1757627
and other from https://overpass-turbo.eu/s/11pc
Some day I will need to check whatever it is also one big copyright
violation
(for now I just left questions at ancient changesets that added this
mess).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fuzzy areas again: should we have them or not?
Cluttering could be a problem, but is an easy thing to solve with filters. As I edit i national parks now I have this huge national park polygon covering all work, which renders as a flat although half-transparent color in JOSM. It's easy to remove with a filter though, but actually I'm not disturbed by it enough to care to do it. If we actually define this as a feature we could have a filter setup for these in our tools. The question becomes more complex as there are several types of these areas. Regions in cities like this I haven't thought about before, I didn't know that it existed. It has quite different impact than a plateau in the mountains. I think it would be unfortunate if a few bad examples of fuzzy area use or (simple) limitations in our tools block all use or further development of them, as they are important for certain type of maps in certain areas. I guess cities can do well without region mapping or just use points which there is a quite rich definition for already (neighboorhood etc), but making an outdoor/rural map without naming nature and without proper support for zooming out (ie having some approximate size of the named features), greatly cripples the capabilities of maps rendered for those areas. Do you think there is a valid use for fuzzy areas in outdoor/rural areas, or would you rather see them not being used there either? /Anders On 2020-12-21 19:30, Mateusz Konieczny via Tagging wrote: Dec 21, 2020, 16:42 by zelonew...@gmail.com: On Mon, Dec 21, 2020 at 8:01 AM Frederik Ramm wrote: Our current data model is not suitable for mapping fuzzy areas. We can only do "precise". Also, as you correctly pointed out, or basic tenet of verifiability doesn't work well with fuzzy data. The current data model works just fine for fuzzy areas: it requires a polygon combined with tagging that indicates that the area is "fuzzy". Since the current data model allows both polygons and tags, fuzzy areas could be mapped just fine from a technical standpoint. Bigger problem is that with things like mountain ranges there are multiple differing opinions about borders. For example in case of https://pl.wikipedia.org/wiki/Beskid_Wyspowy multiple authors give precise, unfuzzy borders (specific rivers or roads). But different authors prefer different borders. See for example https://en.wikipedia.org/wiki/Borders_of_the_oceans and https://en.wikipedia.org/wiki/Boundaries_between_the_continents_of_Earth for other kind of differences. Modelling this is not fitting well how OSM works. So the one questions is, do we want fuzzy areas, the other is, if we want them, how can they be established - because in our current database they cannot. I think fuzzy areas make a lot of sense for cartography, but I strongly object to people adding hand-wavy polygons to OSM for fuzzy areas. "Whether we want fuzzy areas" and "how they can be established" is certainly an open question that requires additional intellectual thought and consensus-building to achieve. However, the statement that they "cannot" be established in our database is simply an opinion, not a technical barrier. I would not say cannot, but it is extremely poor fit to OSM data model and how OSM operates. The statement that fuzzy polygons is "damaging" is an argument not based in fact. It is not damaging to me to have building outlines, which I do not care about. I can simply ignore them. Likewise, fuzzy areas cause no damage to people that do not care about fuzzy areas, provided that there is tagging that distinguishes them from non-fuzzy areas. It is not so easy. Someone mapped several fuzzy areas in my regions and all of them are extremely irritating while mapping. Building outlines are not stretching for hundreds of kilometers and do not appear in places where there is nothing at all and building outlines are verifiable unlike mess like https://www.openstreetmap.org/relation/1757627 and other from https://overpass-turbo.eu/s/11pc Some day I will need to check whatever it is also one big copyright violation (for now I just left questions at ancient changesets that added this mess). ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] natural=fell not rendered, alternatives?
Thanks Steve, good to know about the wiki, I had a hunch that was how it's meant but wasn't really sure. Certainly descriptive for this tag. I guess I could "take over" the fell tag but starting massively use it for bare mountain landcover, but I shall look more closely into alternatives. Just starting using Overpass Turbo, seems like a really cool and useful tool, and impressively fast for the amount of data there is. With a bit of learning curve as you say though :-D. I think I've read about heath+alpine=yes somewhere, I'll see if I can make an OT search for it :-). /Anders On 2020-12-21 19:11, stevea wrote: Nice, Anders. You can use taginfo to get "the raw numbers" (quantity) of a particular kind of tagging. What might work specifically for you in this case is to use some well-crafted Overpass Turbo queries (over a specific area at first, you can use the "bbox" method of "what you see on-screen" or you can use the "geocodeArea" directive to restrict the query to a named place). OT querying takes some practice to become skilled in its vast power to query OSM data, but it is worth investing in the learning curve to do this, as it is likely (imo) the most powerful tool we have to ask our data "what about this, like this?" Usually, our wiki describe "tagging as is," what is known as "descriptive." On occasion, some wiki will be "prescriptive," meaning "here is how one SHOULD tag, though I make a point to say that any wiki which does that should say so explicitly. Good luck in your endeavors! SteveA On Dec 21, 2020, at 9:56 AM, Anders Torger wrote: I just discovered a strange(?) thing with the "natural=fell" tag which I missed at first: on the wiki page there's two purposes defined of this single tag, the first is landcover of bare mountain as discussed, and the other purpose is, quote from the wiki: "In the north of England, and probably in other areas of Norse influence such as Iceland, Norway and Sweden, there is a practice of naming the sides of hills, fells, rather than peaks. A single hill can have different names on different sides. This tag can be used to record such names." It's true that we do have such a practice although more so at lower altitudes. I recently added such a name on an alpine mountain as a fell cutout with a fixme tag (there is no other tag for slopes I think, didn't realize that "fell" is it). However as said we have "fell" in that sense in forested areas as well, even more common there. I guess if "fell without name tag" is defined as landcover, and "fell with name tag" is defined as fuzzy area naming a side of a hill it could work, but it's the first time I see this type of dual definition. Is it normal, or is the wiki page just documenting how this tag have ended up being used? /Anders ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] natural=fell not rendered, alternatives?
I just discovered a strange(?) thing with the "natural=fell" tag which I missed at first: on the wiki page there's two purposes defined of this single tag, the first is landcover of bare mountain as discussed, and the other purpose is, quote from the wiki: "In the north of England, and probably in other areas of Norse influence such as Iceland, Norway and Sweden, there is a practice of naming the sides of hills, fells, rather than peaks. A single hill can have different names on different sides. This tag can be used to record such names." It's true that we do have such a practice although more so at lower altitudes. I recently added such a name on an alpine mountain as a fell cutout with a fixme tag (there is no other tag for slopes I think, didn't realize that "fell" is it). However as said we have "fell" in that sense in forested areas as well, even more common there. I guess if "fell without name tag" is defined as landcover, and "fell with name tag" is defined as fuzzy area naming a side of a hill it could work, but it's the first time I see this type of dual definition. Is it normal, or is the wiki page just documenting how this tag have ended up being used? /Anders On 2020-12-21 18:27, stevea wrote: On Dec 21, 2020, at 7:10 AM, Tomas Straupis wrote: 2020-12-21, pr, 16:52 Anders Torger rašė: But what to do if the things you want doesn't really fit into what OSM currently is and strives to be... We are ALL OSM community. If somebody tells you that "I am OSM and only A is right" - do not believe them. YOU define what OSM is and where it is going to by DOING. The more I look at it, the more it seems that fragmentation is inevitable. Question is how much will remain "common". Thank you for saying it like this, Tomas. Fragmentation happens, though it is not the end of OSM when it does. Private projects, when they happen, don't necessarily harm OSM, they prove its strength as a solid foundation of data upon which are built bespoke / custom solutions. These even can (and do?) "link up" to form a stronger fabric which "rides along with" the solid foundation. There are examples of this in OSM right now. Truly, a lot of what was said in the last few posts are bullseyes on a target: • YOU define what OSM is by DOING (a crucially important truth!) • While "local renderers" are by definition limited in their scope, they need not be limited in their use: they can be practical/visual proofs of "better ways" (to do things), testing grounds for finding solutions to more international problems • There are already local communities creating local cartographic data schemas, this is already being talked about as becoming more-widely and better integrated among data consumers (like yourself, Anders — that's how this works) • Making OSM into what we might use in the future as a "baseline" map for a drop-in replacement for government maps (in Sweden, for example) will doubtless earn us growing contributions that surpass the government maps. Yes, that's a fair bit of sweat, work and time, but it is worth it! (That's a fantastic dream, well-stated and shared by many, Anders!) • Agreeing on the goals FIRST (among peers who can, do and will work towards them) takes energy, but it is worth it! • It is easy to get hooked on this kind of mapping / data / collaboration! It works, it is a lot of fun. Repeat ad infinitum. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fuzzy areas again: should we have them or not?
Maybe we need to split "small" and "large" fuzzy areas into different concepts. Or at least different discussions, as they are quite different in terms of how they affect the map and what needs they fulfill. I do see a risk of edit wars of large fuzzy areas that make great impact on overview maps. I already thought we had that on country borders in conflict areas and such, so maybe we already have routines to deal with that? If we can't introduce features due to edit war risk, maybe the problem is not the feature as such, but how we can handle edit wars? Edit wars is completely new to me though, so I don't know much about this problem area or how much we normally let it affect our features. I don't think these large fuzzy areas need to have very large amount of nodes by the way (they just lay on top, as they are defined as fuzzy it's unnecessary to specify lots of nodes), but they need to cover a large geographical area. You couldn't really edit them in JOSM or iD normally I think, but I don't think "normal" mappers would need to either. Having them in an external database and not integrate with the normal tools would be ok, and I guess that would also solve the edit war issue too. I'd very much like it to be rendered in OSM-Carto at some point though so we don't completely forget about it, but I would suspect that there are technical difficulties to do that with the current platform so we could skip that for now. However, fuzzy areas needed for rural and outdoor maps cover a wetland, a piece of forest, a small plateau, a slope of a mountain, a valley, a peninsula in a lake etc, those are unlikely to be a problem in terms of edit wars. They are also small enough to be accessible for edit in JOSM and iD today, and as I often mention already exists and renders in the form of bays and straits, which I actually need to use quite often as we have these in our lakes of different sizes and coverage, meaning that point naming without size differentiation doesn't work. Having a "fuzzy tag" I think is a good idea, although we could also do it as a flat structure with a list of tags that are defined as being fuzzy. Anything that works :-). If there is large opposition from the people that make the renderers most of us use against these type of features I don't think we have much chance of success though. I think it's hard to get crowd-sourcing going if there is no renderer at all supporting it. /Anders On 2020-12-21 17:16, Paul Allen wrote: On Mon, 21 Dec 2020 at 15:47, Brian M. Sperlongano wrote: The current data model works just fine for fuzzy areas: it requires a polygon combined with tagging that indicates that the area is "fuzzy". Since the current data model allows both polygons and tags, fuzzy areas could be mapped just fine from a technical standpoint. I assume that there is a technical limitation on the number of nodes in such a polygon. A limitation that may apply to any or all of editors, database tables and renderers. There may be some technical workarounds, there may not be. "Whether we want fuzzy areas" To an extent, everything we map is fuzzy, in that there is always imprecision. Aerial imagery may be offset. Roads may pass through woods giving little or no visual indication. GPS traces have errors and require many traces to achieve good precision. Everything we map is fuzzy in the sense that it is imprecise but we live with that and understand that the map is an approximation that we may be able to improve upon at a subsequent date. The dislike of fuzziness here appears to centre around verifiability. We don't want edit wars over the extent of a boundary for which no definitive answer can ever be given. We want rigidly defined areas of doubt and uncertainty. I'm not sure that a fuzzy tag will resolve that problem. The precise boundary of a wetland doesn't matter too much and a few tens of metres either way isn't a problem; when it comes to "The Alps" that is a different matter. Simply tagging an area as fuzzy doesn't mean another mapper won't disagree with your polygon and edit it. The statement that fuzzy polygons is "damaging" is an argument not based in fact. It is not damaging to me to have building outlines, which I do not care about. I can simply ignore them. Likewise, fuzzy areas cause no damage to people that do not care about fuzzy areas, provided that there is tagging that distinguishes them from non-fuzzy areas. The problem is the edit wars that may arise. Not a technical issue but a behavioural one. Further, since we have free tagging, there is nothing preventing mappers (especially ones not party to these conversations) from adding additional fuzzy areas to the database, mapped with some invented scheme, and potentially even creating data consumers to consume such invented tagging. Many tagging schemes in OSM have arisen in this manner. And there is the deeper problem. People will do it
Re: [Tagging] natural=fell not rendered, alternatives?
Good points. I think Norway and Sweden is quite well-known for good maps for hikers in the mountains (at least we think so ourselves :-) ), but indeed those do not require as quick updates as there's not much changing out there and so far no craftbeer on the top of Kebnekaise mountain. But maybe its coming... :-). I have no doubt though that if we could make a good baseline outdoor map which works as a drop-in replacement for the government maps, we could get more contributions that surpass what official sources can provide, such as various climbing routes. That's my dream, and one reason I started to map national parks. However if the base map lacks important base features, eg names in the nature or proper generalization, the map is considered less relevant for these areas and people won't contribute in the same way. I also agree with your other points, but it does boil down to that I need to do a lot of work :-O. On the other hand it's much easier to get things done when you have a small community that can agree on the goals, than most energy being spent on trying to convince each-other if a goal is even worthwhile to pursue or not, and making people upset in the process, which I myself have been guilty of. It's energy-draining for all of us. I've seen the large fragmentation in OSM, all those small private projects here and there, as a problem. Not the projects as such, those are great, many great and interesting ideas, but most seem disconnected from the main community and as such few make it back into mainline, but instead goes unmaintained and eventually peters out when the authors move on to other projects. But what to do if the things you want doesn't really fit into what OSM currently is and strives to be... I'll think about it over Christmas. I've invested way more time in OSM during the fall than I initially planned to. Mapping is dangerous, it's easy to get hooked ;-). /Anders On 2020-12-21 15:09, Tomas Straupis wrote: 2020-12-21, pr, 15:54 Anders Torger rašė: A local renderer would be limited in use <...> Not necessarily ;-) 1. It could be a practical/visual proof of a "better way". 2. It could be a testing ground for finding solutions to some international (wider than OSM, say ICA) cartographic problems. 3. If enough local communities create cartographic data schemas, they could technically align them (tagging-cartographic maillist?) and then data consumers would have to adopt to that as well. 4. I'm not aware of the outdoors map specifics in Sweden, but at least here OSM maps update much faster and also include specific/thematic information for tourism, cayaking, craftbeer, history and all other good things which official sources do not have. And having all of that in one database (rather than an overlay) has some important benefits. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] natural=fell not rendered, alternatives?
Thanks Tomas, much appreciated. I guess you are right, but if local country cartography is the only way, that lowers motivation to contribute a lot here locally. We have great local maps already. To me the attraction of providing to OSM is that the data gets broadly available in any end product that uses OSM data. So any mobile app using OSM maps suddenly gets much better maps here locally, even if the app was made for the US market in the first place. A local renderer would be limited in use, and then I could use just our local government maps directly. Which I indeed have done for some projects local to Swedish users. (Thanks for the fuzzy area PS too. Maybe external database is the way to go, I see many say that. But that is of little use if it's not getting used by standard renderers, and it seems like we maybe aren't into making rural/outdoor maps at all) /Anders On 2020-12-21 14:38, Tomas Straupis wrote: 2020-12-21, pr, 14:42 Anders Torger rašė: I personally want to see that the community work for a more defined mapping baseline with OSM-Carto as a strong reference, used as a motivational tool for crowd-sourcing, and as it is with the current provider landscape -- also work as an end product. It does in parts already, and I want to see more of that. I also got a sense of urgency, map density in OSM has improved a lot, data sources that a mapper has access too has also improved a lot since OSM started, so mappers can today map much more than they could before and are more motivated to do so, at least in some places in the world. I want the OSM technical platform to be ready for that. In OSM for natural reasons cartographers are a small minority comparing to majority of coders. Therefore cartographic goals do not get through a "coder filter" (it is more important for majority to have clean code than to have clean map). You might try, but in my experience the only way is to: * have a more cartographic agreement with local community (it is easier in small scale, as you can meet in person, show good examples and thus prove the value of cartography) * have your own country renderer (you can start with VPS for ~100EUR a year and go up as your usage grows). * have your own country editor with your regional tagging schema (I will publish instructions on how to do that in a month or two) * do most of the work yourself (or with a small group of cartography oriented people) at least initially as resistance will be there anyway until you prove/show results You will have cartographic maps and will not have to waste time agreeing on cartographic nuances with people who do not understand cartography. You will simply agree about them LOCALLY and use them (OSM has a rule of "free tagging"). P.S. Frederik is right about fuzzy features, even in cartographic perspective they do not belong in the same bucket as current OSM features. I think you should have a separate database for those. It is not hard to implement that as amount of data/changes is much lower. They later end up in the same database in similar GIS tables as main OSM data therefore are seamless to use in final products. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fuzzy areas again: should we have them or not?
I forgot to comment this. Just want to make sure that there is no misunderstanding: this is not primarily about labeling the Alps or the Atlantic or the Sahara desert. It's mainly about making rural and outdoor maps useful for a local context. Maps that hikers, mountaineers and hunters use when moving about in nature away from roads and residential areas. OSM can indeed continue to make huge progress in urban areas and car navigation etc without ever caring about making outdoor maps. And if that is what we want, that's fine. But if we actually do want the OSM data to *also* be used as a basis for outdoor maps away from the streets (and not just for an illustrative purpose, but for real use), we are crippling it by not having methods to map these names in a proper way. For outdoor and rural areas being able to work in an overview manner is also more important, as areas are huge, wide space between features, which makes simple point mapping place=locality style not work well. But it all boils down to, do we want to support these type of maps or not. /Anders On 2020-12-21 13:57, Frederik Ramm wrote: Please stop trying to frame this as "cartographers have a right to abuse the data model, and if someone doesn't want that, they need to present a viable alternative". We've come very far in OSM without such abuse and I don't see why it should suddenly be introduced. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fuzzy areas again: should we have them or not?
Thanks Frederik, if I interpret your answer correctly it is that we should not map these names at all (at least not within the scope of OSM database and OSM-Carto rendering), is that correct? As a mapper I would like to know what the strategy is so I don't waste my effort on dead ends. A technical comment: I don't see a need for wavy polygons or something fancy like that. Just regular polygons. They are by definition fuzzy, the polygon borders aren't supposed to be rendered, it's just a guide for renderers to know where to place text label. I see no need for a new datatype, I think the database is ready for fuzzy areas today, and is already being used (bays and straits). However, it becomes more and more clear that the leading profiles in the OSM community actually doesn't care *that* much about rural/outdoor map-making, or at least that the current view of what the data model should be is more important. I certainly don't mean this is a derogatory manner, it's perfectly fine to have that view. However, I on the other hand care very much about rural and outdoor map-making and desire that be an important end use for the OSM data I contribute, and I get a bit confused. I get thrown between hope and despair regarding the general community's view on this. A clearly stated strategy would be nice. Without that I get I like "maybe if I come up with a better idea to store these names they'll like it", but if we don't want them in the first place, I'd appreciate if we just say so. I know lettering across the alps and other huge areas is a favorite example, but in my context it's much more about the small ones. In rural areas we have about 5-10 of these types of names per 10x10 km square. Not mapping those make rural maps and outdoor maps a lot less useful than they could be. These names are used all the time by outdoor people. Not having them in large disqualifies OSM to be used for outdoor map end products, but if that is what the community wants I'm certainly ready to accept that. There's no use to map areas which we never intend to make useful maps for, so then I'll just skip those. There are still other areas to map. /Anders On 2020-12-21 13:57, Frederik Ramm wrote: Hi, On 21.12.20 10:20, Anders Torger wrote: In the mountains we have an number of named plateaus. There is a tag proposal for natural=plateau, but just like with natural=peninsula and similar tags there is an underlying question that we really need an answer to first: should we have fuzzy areas or should we not? I think I have laid out my point in https://lists.openstreetmap.org/pipermail/tagging/2020-December/056823.html Our current data model is not suitable for mapping fuzzy areas. We can only do "precise". Also, as you correctly pointed out, or basic tenet of verifiability doesn't work well with fuzzy data. So the one questions is, do we want fuzzy areas, the other is, if we want them, how can they be established - because in our current database they cannot. I think fuzzy areas make a lot of sense for cartography, but I strongly object to people adding hand-wavy polygons to OSM for fuzzy areas. We know there are disadvantages and no solution is 100% perfect, but sometimes there's a higher goal to fulfill. Having a nice lettering across the Alps is certainly not a "higher goal" for OSM as a whole; forcing fuzzy polygons for that into OSM is irrelevant for most and outright damaging for some use cases, and the advantage it would have for the one single use case of map rendering does not justify it. Please stop trying to frame this as "cartographers have a right to abuse the data model, and if someone doesn't want that, they need to present a viable alternative". We've come very far in OSM without such abuse and I don't see why it should suddenly be introduced. Bye Frederik ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] natural=fell not rendered, alternatives?
(Sorry if I missed a private message. I have a generic filter that throws all emails that match tagging in some way to one mailbox and sometimes I miss things.) Anyway, I'm talking about globally distributed open source projects, where you communicate in text over email and forums. Not a workplace. It's very different ways of communicating, and it always looks harsher than it is. You probably have a whole different view of me than you would have if we met in person. But point is taken, and I have noted that discussions go south here a lot quicker than I'm used to, and indeed that's ineffective. I'll try to provide a softer tone, because what I want really want is solutions to the issues. I guess one issue with my appearances here is that in my humble opinion many things in OSM are problematic, mostly a result of that it has piecewise evolved rather than it has had a solid design leadership, and it's got some growing pains. I've hidden that view poorly mainly because many issues I run into I think would have been non-issues if it has been more of a top-down design for a baseline feature set focusing on actual end uses. I now understand that this view is very provocative though, so I'll try to tone it down. I personally want to see that the community work for a more defined mapping baseline with OSM-Carto as a strong reference, used as a motivational tool for crowd-sourcing, and as it is with the current provider landscape -- also work as an end product. It does in parts already, and I want to see more of that. I also got a sense of urgency, map density in OSM has improved a lot, data sources that a mapper has access too has also improved a lot since OSM started, so mappers can today map much more than they could before and are more motivated to do so, at least in some places in the world. I want the OSM technical platform to be ready for that. /Anders On 2020-12-21 11:55, stevea wrote: On Dec 21, 2020, at 2:10 AM, Anders Torger wrote: I'm sorry if you experience it as that. Maybe I'm a bit too confrontational, and maybe I should express myself with a softer tone, I guess my style has become a bit shaped by to how we communicate engineer to engineer in programming projects. Anders, I’ve been an employee at Apple, Adobe and many startups (in Silicon Valley and my university city nearby on the coast), as an engineer, to other engineers. I have been a team leader, a manager and a director — on dozens of programming projects. I DON’T “guess” at your style and if you worked with me I’d give you as stern a talking to behind a closed door, just the two of us. That’s not as I do here on-list, precisely because YOU chose the more public venue, but also because you don’t answer my polite, private email. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fuzzy areas again: should we have them or not?
Yeah I know of that github project and I'm thinking of that an approach of having small fuzzy areas in the main database, and huge ones in a separate might be the way to go. One reason to have big names separate and not the small ones could be that the big names will be "completely" mapped almost right away and don't require crowd sourcing. However the small ones, as an example we have say 5-10 of these names per 10x10km square in Sweden, do require crowd sourcing from regular mappers. But then I ask myself, if we can have the small ones, why not have all, also the big ones, in OSM? We have already big scale information in the database. The clutter thing I think is just a tool issue which is already solved in JOSM (filters) and can be easily solved in iD. Or we could go the opposite way and move all fuzzy areas to an external database, also the small local ones. It's sort of a conceptual way to create it as a separate layer. I'm not against that from a technical perspective, but I'm worried if this data is not included in the main OSM database it's a big risk that it won't be available and won't be used by OSM-Carto and then mappers won't be motivated to contribute so we won't get the necessary crowd sourcing going. (I've heard that some think fuzzy areas is "mapping for the renderer" and that's the reason we don't really move forward on this issue. Unfortunately I don't remember the exact reasoning behind why it would be mapping for the renderer so I can't recreate that argument here, but I guess someone can fill that in. From my perspective I think fuzzy areas is the exacty opposite to mapping for the renderer, as the mapper just give information of name and rough size of an actual fuzzy area, and makes no decision on label placement or size. Sure one can misuse it and say make a fuzzy area much larger than it should be to make the renderer draw a large text just for the sake of it, but that's just regular misuse and something we need to relate to for all OSM tags and features.) /Anders On 2020-12-21 11:03, Janko Mihelić wrote: The fifth alternative is move the big areas to an outside repository: https://github.com/dieterdreist/OpenGeographyRegions This might be a great alternative until we find a better solution. And there might not be a better solution. Janko pon, 21. pro 2020. u 10:22 Anders Torger napisao je: Next question. In the mountains we have an number of named plateaus. There is a tag proposal for natural=plateau, but just like with natural=peninsula and similar tags there is an underlying question that we really need an answer to first: should we have fuzzy areas or should we not? Plateau, peninsula etc are naturally mapped like an additional low detail fuzzy area polygon on top of other land covers. My opinion has been made clear in other threads: I think fuzzy areas on top is an elegant solution for naming nature and something we should have. I think the cluttering issue can be solved with filters, but as these will be used in low numbers to start with I think cluttering will not be an issue for some time to come so it's something we could look into later. In any case that's a tool issue, not a database issue. If we don't want fuzzy areas, an other alternative is to have these as named points, (previously often made as "place=locality"). I think that is okay too, but then we need size classification on them like we have on residental isolated dwelling/hamlet/village etc so the renderer have enough information to know how large to make texts and which zoom level to show them. Having the same level for all names doesn't work. Fuzzy areas has the advantage of solving the text size automatically (not a mapper decision), and gives freedom to the renderer to place (and even shape) the text. Fuzzy areas also scale well up to huge sizes (like the Sahara desert) if we want that as well, which point text doesn't in the same way. We could decide to have fuzzy areas over a certain size in an external database too. I'm not super-stoked over the external database method though, as I think then it risks becoming like elevation/contours is today, ie not generally available and with varied quality. A disadvantage is that fuzzy areas have limits in verifiability and it arguably requires more knowledge/judgment from the mapper than roughly placing a point. On the other hand, optimal point placement also have cartography and verifiability issues. The underlaying issue here is of course that these type of names have never have defined borders and never will, but I think we cannot continue to pretend that they aren't relevant for a database mainly used to generate maps. We need to represent them in some way. A third alternative is not having names of this type at all. While I just said that it's not the way to go, if someone still has that as a clear opinion please make that clear rather than just point at di
Re: [Tagging] natural=fell not rendered, alternatives?
Thanks, good points and information. Indeed, the fell tag seems to be a bit misused. I would guess it could be because there are things actually named "Fell" there, and then inexperienced mappers may use the Fell tag as that seems appropriate. Incorrect use can be cleaned up in time though (fell is not used *a lot* so it's not like fixing place=locality uses...), and I think it shouldn't stop a useful tag. But sure we could perhaps make a new one, or a new tag combination if that is better. I have myself looked at the fell definition here: https://wiki.openstreetmap.org/wiki/Tag:natural%3Dfell And interestingly enough the "examples" photographs are from areas I'm actually currently mapping(!) so I thought if it was meant to be used at all, this is the place :-). It also matches up how maps are traditionally made here, so very good for the local community. We don't call these areas "fell" in our local language, but rather what would be translated to "bare mountain" (ie mountain above tree line), but the actual name of the tag isn't what matters, it's the definition. And the current wiki page clearly points at the use I'm looking for. Although the bare rock/scree altitude is quite clear and I'll probably map it as that in time, I'm afraid that if I map the mid altitude bare mountain with "heath" instead of fell, the heath definition will be a bit watered out due to the speckled and diffuse character of this nature. So I think it would be better with a specific tag that embraces this property of the land. /Anders On 2020-12-21 10:34, Andy Townsend wrote: On 21/12/2020 07:39, Anders Torger wrote: Hello, I'm doing further mapping of Swedish national parks, now in the mountains, and I have noted that natural=fell (habitat over tree line) is not rendered. Looking into why it seems that OSM-Carto implementors want more specific landcover tags to be used. ... This isn't really anything to do with tagging, but I can understand why some renderers decide not to render it. Usage, at least where am I, is hugely problematic: http://overpass-turbo.eu/s/11nH . Usage in the Pennines northwest of Leeds is almost exclusively just a bunch of names that have been copied from old out-of-copyright NPE maps. The features may be peaks, or patches of moorland, or something else again. If a renderer was to do something with them, it'd probably be as "place=locality". Further west examples like https://www.openstreetmap.org/way/412325588 correspond better to the wiki definition. In that example other landuse (woodland, heath) is also mapped. There are also some surprising uses in place of other tags - on https://www.openstreetmap.org/way/368051383 it surely means "trail_visibility"! Best Regards, Andy ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] natural=fell not rendered, alternatives?
Steve, I'm sorry if you experience it as that. Maybe I'm a bit too confrontational, and maybe I should express myself with a softer tone, I guess my style has become a bit shaped by to how we communicate engineer to engineer in programming projects. That is the jargon can be quite "hard" with many strong opinions clashing, but it's nothing personal. I've seen others in this list use the same "tough" way to voice their opinions so I thought it was okay. As long as one focus on the merits of the arguments, have an open mind to change opinion, is open to solutions one didn't think about, and don't go personal it usually works well. I can try go softer in jargon, but it won't change the fact that the reason I get on this list is when things either don't work or I don't find an answer to some question. So it will be "complaints" in some way or another. I think I do provide some solutions too though, although some may not be easy to realize or is not likable by everyone. That there are many "complaints" coming from me now is because I currently map *a lot* and mainly nature (which wasn't an original goal for OSM but something that has come later, so it's understandable that there are issues) and therefore come across many issues which have no clear answers. This is a list for tag discussion, strategy and related tools. Issues bubble up to here. If I had a clear answer I wouldn't even need to post, and there are many of those too (ie where I've found working solutions on the wiki or through OSM help). The reason I don't have a clear answer is that there is several issues with the current approaches, which I described in my post. If OSM intends to be for all globally, there is a need to consider local needs and respect local knowledge, not only consider a feature relevant if it is has global spread. Maybe these natural=fell issues are specific to Scandinavia (although I think Great Britian has similar), but they are real here. I try to make a case that it would be wise to render natural=fell, and describe why. There's a closed issue report on OSM-Carto github about this (yes I actually do some research before I post), and my arguments were shaped by that thread, to proactively meet what came up there so we don't need to have exactly the same discussion all over again. However, that I have a suggested solution doesn't mean that I'm open to other suggestions, maybe an alpine tag for indicating nature above tree line for example. I think it's however very difficult and not worthwhile to go very specific for our fell habitat, which I also described in the original post. Heath below the tree line is quite easy to identify, as it's surrounded by forest. Heath above the tree line is pretty chaotic, speckled with bare rock and scree. Hence a generic tag "fell" would suit perfectly well, and is already in existence, but it needs rendering in OSM-Carto to show mappers that there is backing for this tag. /Anders On 2020-12-21 10:12, stevea wrote: On Dec 20, 2020, at 11:39 PM, Anders Torger wrote: I'm doing further mapping of Swedish national parks, now in the mountains, and I have noted that natural=fell (habitat over tree line) is not rendered. Looking into why it seems that OSM-Carto implementors want more specific landcover tags to be used. I don't think that (somewhat randomly) requiring detailed landcover is a good design choice. Can Anders write anything here without telling OSM that it is broken and we don't know what we are doing? Anders, where did you study cartography or get an advanced degree in design? Ignoring the question speaks volumes. I think it would be better to have a defined hierarchy from more generic to more specific tags so the map can evolve. Thank you for your opinion. Taking the leap to high detail mapping directly makes covering the map very slow and sometimes inaccurate. Maybe. Again, only maybe. If you don't like OSM, you are welcome to not use it. Fell in particular is in parts so heavily speckled with slightly different covers it's hard to even see on the satellite photo what it is. Complain, complain, complain. You can have say 30% bare rock, 20% scree and 40% heath and 10% wetland in an area. So I guess I make that heath then as it's dominant? That would however be more misleading than actually setting a more generic tag like natural=fell. Forcing detailed mapping where this is very difficult to do is not a good idea. Bleating, bleeeating to this list with little to no constructive bent to your complaints is not a good idea. When we get to even higher altitude the growth disappear and we have just bare rock and scree so it becomes easier. It can at times be quite hard to differ between bare rock or scree though (the resolution of the satellite photos in the mountains is often not that great). I'm beyond thinking that this barrage of &qu
[Tagging] Fuzzy areas again: should we have them or not?
Next question. In the mountains we have an number of named plateaus. There is a tag proposal for natural=plateau, but just like with natural=peninsula and similar tags there is an underlying question that we really need an answer to first: should we have fuzzy areas or should we not? Plateau, peninsula etc are naturally mapped like an additional low detail fuzzy area polygon on top of other land covers. My opinion has been made clear in other threads: I think fuzzy areas on top is an elegant solution for naming nature and something we should have. I think the cluttering issue can be solved with filters, but as these will be used in low numbers to start with I think cluttering will not be an issue for some time to come so it's something we could look into later. In any case that's a tool issue, not a database issue. If we don't want fuzzy areas, an other alternative is to have these as named points, (previously often made as "place=locality"). I think that is okay too, but then we need size classification on them like we have on residental isolated dwelling/hamlet/village etc so the renderer have enough information to know how large to make texts and which zoom level to show them. Having the same level for all names doesn't work. Fuzzy areas has the advantage of solving the text size automatically (not a mapper decision), and gives freedom to the renderer to place (and even shape) the text. Fuzzy areas also scale well up to huge sizes (like the Sahara desert) if we want that as well, which point text doesn't in the same way. We could decide to have fuzzy areas over a certain size in an external database too. I'm not super-stoked over the external database method though, as I think then it risks becoming like elevation/contours is today, ie not generally available and with varied quality. A disadvantage is that fuzzy areas have limits in verifiability and it arguably requires more knowledge/judgment from the mapper than roughly placing a point. On the other hand, optimal point placement also have cartography and verifiability issues. The underlaying issue here is of course that these type of names have never have defined borders and never will, but I think we cannot continue to pretend that they aren't relevant for a database mainly used to generate maps. We need to represent them in some way. A third alternative is not having names of this type at all. While I just said that it's not the way to go, if someone still has that as a clear opinion please make that clear rather than just point at disadvantages of every suggested solution without coming up with an alternative. We know there are disadvantages and no solution is 100% perfect, but sometimes there's a higher goal to fulfill. The fourth and current alternative is leaving the question undecided, with some fuzzy areas active (bays and straits), some not rendered (peninsula), and passively see how it plays out in the coming years (or decades!). It's the simplest alternative, but as a mapper and OSM end user I hope we can make some real progress now. Worth mentioning is also the alternative to make a fuzzy cutout of the dominant landcover and name that. I've done quite some forest naming that way. However it's quite complicated and time-consuming to make these cutouts (complex multipolygon editing), and it only works well when the name is actually tied to the landcover as such, eg the name is on the forest, not a forest-covered peninsula or plateau. While I think it's okay to mix this cutout naming method when it works, and use fuzzy areas on top when that is required, I also think a viable option would be to name forests with fuzzy areas on top as well, but then we need a specific tag (or tag combination) so the renderer knows that it shouldn't make landcover rendering for that. I'd like to at least know where we are headed. I could use a tag which is not yet rendered, but it would be nice to know if the information will potentially ever be used, or if I'm maybe just wasting my time... /Anders ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] natural=fell not rendered, alternatives?
Hello, I'm doing further mapping of Swedish national parks, now in the mountains, and I have noted that natural=fell (habitat over tree line) is not rendered. Looking into why it seems that OSM-Carto implementors want more specific landcover tags to be used. I don't think that (somewhat randomly) requiring detailed landcover is a good design choice. I think it would be better to have a defined hierarchy from more generic to more specific tags so the map can evolve. Taking the leap to high detail mapping directly makes covering the map very slow and sometimes inaccurate. Fell in particular is in parts so heavily speckled with slightly different covers it's hard to even see on the satellite photo what it is. You can have say 30% bare rock, 20% scree and 40% heath and 10% wetland in an area. So I guess I make that heath then as it's dominant? That would however be more misleading than actually setting a more generic tag like natural=fell. Forcing detailed mapping where this is very difficult to do is not a good idea. When we get to even higher altitude the growth disappear and we have just bare rock and scree so it becomes easier. It can at times be quite hard to differ between bare rock or scree though (the resolution of the satellite photos in the mountains is often not that great). We already have more-generic-to-more-specific landcovers in other areas, you can provide wood without specifying tree type for example, or wetland without specifying type of wetland. (Parenthesis: going from more generic to more specific by adding additional specifying tags is an elegant design, I think it's a bit unfortunate that that design is mixed with a flat tag structure as well, but that's the way it is...). It seems like a very odd design choice to require more detailed mapping in alpine areas where this is rather difficult. If we look into how official maps do it in Sweden and Norway they don't have specific landcovers above the tree line, they have just "fell", and in addition significant wetlands, plus waters and streams of course. Fell indicates where we have bare mountain (above treeline), which is the key information outdoor goers need, plus waters and significant wetlands. Anyone that has been to these mountains know that once above the tree line the land cover is quite predictable, it's decided by altitude and steepness. At the fell altitude contour lines is key information, not if it's a patch of heath or bare rock, which rather just makes a map harder to read without providing valuable information. So far I have tagged these areas with natural=fell. I'm thinking about adding bare_rock at high altitude (and scree only when clear and significant), but in the medium altitude where there is growth more detailed mapping becomes very difficult. Heath would be the most natural generic tag for that area, but then we loose the distinction that it's above the tree line, as there already is some heath areas below the tree line. Maybe adding an extra tag like "alpine=yes"? I suppose it won't render differently from normal heath on any renderer though so we still lose the rather significant tree line information in actual maps. Suggestions are welcome. /Anders ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to put a name tag on an area with more than one type?
I'll make a small change to my naming strategy: use one multipolygon per natural tag set, and thus minimize the number of same-named polygons. Normally, when naming entities which has all the same natural tags but separate areas, such as a couple of ponds or islets with a collective name (common), it's made as a single multipolygon with several outers. I've heard that there are renderers that actually already today then render a single text label. As natural tags differ in this wetland a single multipolygon is not possible. However one can make one polygon per set of natural tags. For this Rimmjoáhpe wetlend I then get away with two multipolygons, thus greatly reducing the number of text labels rendered in some renderers, while still being compatible with the other method of keeping every adjacent polygon on their own. It also makes it easier to keep all parts together when editing as a multipolygon is also a relation. /Anders On 2020-12-15 09:52, Anders Torger wrote: Yes we actually have some of that up here too. I've chosen generally not to map it though as one cannot really verify it on the satellite photos, and here in the vast nature in north it's not really reasonable to visit all these places on foot so one have to rely on satellite photos for large parts of the nature. I'm quite sure that overlapping polygons is not how one is supposed to do it though. Soggy forests should have its own natural type, in Swedish we call it "sumpskog", and the best fitting OSM tag for that seems to be "natural=wetland; wetland=swamp". By the way, I've pushed an update of the Rimmjoáphe wetland now, removed the relation and made a multipolygon to span the river. On 2020-12-15 09:03, Ture Pålsson via Tagging wrote: 15 dec. 2020 kl. 08:26 skrev Anders Torger : And about wetlands, couldn't those be just rendered on top of forests so we didn't have to make these complex multipolygons? It does make sense to have overlapping wetland and forest, though. To take a swedish example: down here in 08-land (note to non-Swedes: Stockholm, telephone area code 08 :-) ), we get very little open bog, but a fair amount of soggy forest. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to put a name tag on an area with more than one type?
When I started using JOSM, which is not so long ago, I hated it. If one is used to graphic software from say Adobe etc, many things in the user interface feel backwards. But now when I've got into it, one can really work effectively. When I started I didn't really understand the multipolygon concept fully either, so the error messages I got was really cryptic, but now when I understand all these things JOSM works great. What I do miss in JOSM though is advanced tools for managing multipolygons, there are some splitting and joining and some additional tools as plugins, but these are generally limited in scope, so I often end up having to hand-edit the ways and relations when making more advanced splits/joins/geometry upgrades. For that the relation editor works very well though, but one really needs to know what one's doing :-). If one is a programmer and want to contribute to OSM mapping efficiency as the OSM map becomes more and more detailed, I believe developing more advanced and complete multipolygon tools for JOSM is a good bet. In iD, areas with multipolygons can be very hard to edit, unless you know how they are constructed so you can go in and hand-edit tags. So they can be a bit of a pain, but they are unavoidable if we want detailed mapping, and as the map develops we get more and more into this space. /Anders On 2020-12-15 10:21, Peter Elderson wrote: stevea : (Personally, I find JOSM's relation editor to be one of its most elegant features for a data structure as relatively complex as a relation. I am not qualified to judge elegance, but I find JOSM's relation editor the best there is. I don't think relations are very complex data structures, but the construct is versatile. It's what people do with them that makes it complex. But hey, the same goes for the node, the way and the area. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to put a name tag on an area with more than one type?
We should probably not have all these possible generalized areas in our db. Just as we probably shouldn't have a bedrock map in the db either, at least not until it can manage layers. But we could simply pick one criteria, document the definition of the "fuzzy area" and have that. Some criteria that is useful as a basis for making general-purpose maps. I don't think it's a problem to have fuzzy areas in the database as long as they can be identified as such and there is a clear definition of what they mean and what the concept of fuzziness is. Renderers shouldn't generally not render the border of these areas, and if they do for some particular illustration (to show where Black Forest is for example) they should make them really blurry and fuzzy. Sure one can always come up with arguments regarding verifiability, but in general I think they are quite weak. If we want this feature we can have it. If we don't want it, we can make up arguments against it. Often I see in discussions on this list that people not really say if they actually want a feature or not. They just put forward criticism on a certain implementation, without ever clarifying their standpoint on the feature as such. It does not apply to you Martin of course (you have clearly shown you want this feature, we're just discussing method, which is great), I just want to mention that I think we should all strive to do that, clarify our standpoint for or against a feature rather than just covering under technical arguments, sometimes increasingly strained and formulaic. Anyway, one can also argue that it is a problem from an editing standpoint to have these fuzzy areas overlay other areas increasing the clutter. While I think the argument has some merit, I think that is easily solved with a filter, already today supported in JOSM, and easily added to iD. As the areas are fuzzy it does not really matter if other natural polygons are edited and adjusted without adjusting the fuzzy area, they don't need (and probably shouldn't) share nodes with the underlying nature, so it's not a problem if they aren't visible at the same time per default. Although I argue for having these in the main database, I'm not really against to having it in a different database, that would technically work as well. I just see it as unlikely to catch on. If we have it in a separate database we could do it even if the majority of the OSM community isn't on board with the concept at all. OSM-Carto wouldn't render it, and as a result I think a major part of the mappers wouldn't even know that it exists. Just like it's unreasonable to think that mappers would know about naming concepts that render incorrectly in OSM-Carto (the Rijmmoáhpe wetland example). I also think that having concepts to name nature is important enough to serve the making of maps that it really should be in OSM main database. OSM can already name much of nature and mappers contribute to that, it just falls a bit short on these more complex cases. The concept of fuzzy areas has already been softly introduced with bays and straits. I see no reason why we shouldn't develop that capability further. Another challenge with having it in a different database is that of management and availability. It's strange to suddenly need two databases to render just common general-purpose maps, and who's going to make sure that it's available? I think that using the current OSM infrastructure is a safer bet. /Anders On 2020-12-15 09:50, Martin Koppenhoefer wrote: sent from a phone On 15. Dec 2020, at 06:11, Graeme Fitzpatrick wrote: If I look at a map eg https://en.wikipedia.org/wiki/Black_Forest#/media/File:Relief_Map_of_Germany,_Black_Forest.png, it tells me that the Balck Forest is a more or less oval-shaped area in Southern Germany. Why can't we draw a similar rough oval in OSM & call it Black Forest? have a look at this overview: https://de.wikipedia.org/wiki/Naturräumliche_Gliederung_des_Schwarzwaldes#Grobe_Gliederung these areas are not directly observable on the ground, yes, they are made (I suppose) by scientists according to certain criteria, but you will probably get different answers if you asked a biologist, a geologist or a linguist. And according to the scale that they are working in. Shall we really aim at having all these possible generalized areas and classifications as nested polygons in our db? Seems obvious that we can't. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to put a name tag on an area with more than one type?
Yes we actually have some of that up here too. I've chosen generally not to map it though as one cannot really verify it on the satellite photos, and here in the vast nature in north it's not really reasonable to visit all these places on foot so one have to rely on satellite photos for large parts of the nature. I'm quite sure that overlapping polygons is not how one is supposed to do it though. Soggy forests should have its own natural type, in Swedish we call it "sumpskog", and the best fitting OSM tag for that seems to be "natural=wetland; wetland=swamp". By the way, I've pushed an update of the Rimmjoáphe wetland now, removed the relation and made a multipolygon to span the river. On 2020-12-15 09:03, Ture Pålsson via Tagging wrote: 15 dec. 2020 kl. 08:26 skrev Anders Torger : And about wetlands, couldn't those be just rendered on top of forests so we didn't have to make these complex multipolygons? It does make sense to have overlapping wetland and forest, though. To take a swedish example: down here in 08-land (note to non-Swedes: Stockholm, telephone area code 08 :-) ), we get very little open bog, but a fair amount of soggy forest. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to put a name tag on an area with more than one type?
Impressive work! I had missed myself that the river flows through. To tie it together I would have made a multipolygon with two outers one on each side of the river, and I think I've already done that in some other wetland with the same issue. However that is not a fool-proof solution, as in some case you could have only bog on one side of the river and only marsh on the other, making it impossible to tie it together with a multipolygon. The simple answer is that this naming concept is fundamentally broken, and that we need to have some other concept, such as fuzzy areas. However I'll soon go through these edits again and then I will add multipolygon for the split, and if your renderer takes that into account we should end up with a single multipolygon. I think in the case of Muddus it will work in all cases, ie we won't hit the corner case described above which should be very rare. So I think this naming concept is okay as a stepping stone until we can move forward on this issue. I hope we can make a point though that this is not a acceptable as a long-term solution. Your example also demonstrates the importance of having a reference renderer that actually renders correctly. I would not have discovered that I've forgot to tie the wetland together if it weren't for that your renderer actually implements the algorithm. A proper reference render gives better geodata, as it allows mappers to with their own eyes see what's correctly represented or not. /Anders On 2020-12-15 06:22, Ture Pålsson wrote: 14 dec. 2020 kl. 22:30 skrev Anders Torger : Cool! It would be really nice to see a demo :-) Rijmmoáhpe renders sort of reasonably now at http://lab3.turepalsson.se/map . (On the generated PDF, not on the "slippy map". And it's a bit hard to find, since my low-zoom tiles are so bad!). Or check my PDF at http://lab3.turepalsson.se/map/download/ecb7556.pdf . It still gets two labels because the area is split in half by Rijmmojåhko flowing through it.___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to put a name tag on an area with more than one type?
Some more points after a night's sleep: I just remembered, another issue with opentopomap is that it doesn't render wetland names at all, which may be a bit strange for a map with topology. But we could look at some other map, geofabrik for example, and of course it renders the same way as OSM-Carto. I don't think you will find any renderer, except Ture's which just implemented it in this thread that does this. The thing is that this "well-established method" doesn't make much sense as far as I can understand. A renderer needs for each area with a name label scan for all adjacent areas to see which have same names. If names are the same it needs to calculate the area to figure out dominant nature type and then merge to a new area so it knows where to place the label. But sure, it's far from impossible. It's however strange having this algorithm that needs activation all the time (scanning for adjacent names) for still quite rare cases, and it's even more strange to leave it undocumented and expect that "other renderers" will implement it. But I'm not dumb (oh well, maybe a little) I really don't think that anyone believes that other renderers would implement it, it's just a standard argument to neutralize criticism of OSM-Carto's limited rendering. The answer is *always* that "some other renderer will do it properly". It's not exactly ideal for making progress. I think that having limited and "soft advice" wiki documentation of how geodata should be interpreted and rendered is a bad idea. However I think it could still work *if* OSM-Carto took on the role as being a reference renderer rather than just an "example renderer" which does some things right, and other things wrong. That does not mean that OSM-Carto needs to have the best most advanced cartography (although it would be nice), it just means that it needs to properly render the concepts which is supposed to work. If it did, maybe we would find out that the algorithm for doing so is unreasonably expensive, and we would need to change how data is arranged or introduce a new concept (I think fuzzy areas is the real answer here). I think it's really risky to design data arrangement concepts without having an own renderer to test them with. And about wasting mapper's time. What about that we have to punch holes and make river areas for rivers nowadays? Punch holes for waters in forest areas? And about wetlands, couldn't those be just rendered on top of forests so we didn't have to make these complex multipolygons? Managing multipolygons in complex nature is by far what I spend most time with. And imagine how much easier it would be to draw if multipolygons were allowed to have inners that touches outers. Now when you need to pull up an inner towards the outer edge, you need to change the shape of the whole outer multipolygon to go around. The tools available in JOSM for managing multipolygons is still very rudimentary. Split and join tools only work for the simplest cases, so you generally need to do these operations manually by cutting ways, making new ways and hand-edit the multipolygon relation. Simple-to-draw-but-hard-to-render multipolygons could still be converted to render-friendly polygons in a middle layer. Conversion and generalization is required regardless as soon as we move to vector tiles. Personally I don't have that big issue with those multipolygons, although not very effective it's kind of fun to make and manage these. But I do note that my fellow mappers in Sweden still typically just ignore that forest is drawn on top of their lakes and overall that the multipolygon concept is just difficult to grasp for many. So if we are really serious about "not wasting mappers' time", we should surely look into ease of editing, and think twice before we introduce a new drawing rule that makes it more difficult to edit. /Anders On 2020-12-14 22:25, Anders Torger wrote: I certainly agree that we should not waste mapper's time, but in this case it was mainly actually to make it easier for myself with JOSM to find my way back to all small pieces in a fragmented landscape. Not having this relation makes editing a fair bit harder as you can't really see which parts belong to the same (name labels are really not that visible in JOSM) and you need to click your way through or create a filter on the name, but since you don't want it I will remove it. It will probably lead to more work for me rather than less, but I won't invent something that everyone is against. It's a value in keeping it simple too. So we can put that to the side, don't worry there will be no relations. Opentopomap has some interesting features, but also it's own family of problems. The largest problem (except for limited server capacity) I think is that it renders borders between same tag areas, which causes lots of borders of technical po
Re: [Tagging] How to put a name tag on an area with more than one type?
Cool! It would be really nice to see a demo :-) I would be fine with your naming scheme, however you'll have to rely on the adjacent rendering as I will be removing all relations per request. As said I actually had them mostly for make my editing easier (without them it becomes harder to manage all tiny parts in JOSM), so it was a mistake by me to mention possible advantages for renderers too, but as I'm also a programmer it's hard not to think about those things in parallel. That it requires an merge-adjacent despite different natural tags and instead matching name makes me think that your renderer will probably be the first one implementing this, despite the claims that this is an established method... but I hope I'm wrong. /Anders On 2020-12-14 19:06, Ture Pålsson via Tagging wrote: 14 dec. 2020 kl. 15:49 skrev Anders Torger : Okay, but why does the OSM-Carto renderer, and all other renderers known to man(?) make multiple text labels then, when it should be a single one? Look at the result, it looks horrible. Do you really think this is the way it should be done, also long-term? Also note that the tags do differ, otherwise it would be a single multipolygon, it's both wetland=bog and wetland=marsh. I have implemented the merge-adjacent-areas scheme in my renderer. I’ll try to get a demo up… :-) Having said that, as a renderer implementer, I have a slight preference for the relation method. It is s implyeasier to join things on numeric id than to join them by adjacency. I noticed that you have tagged the ”name” relation as (if I remember correctly) type=natural, natural=wetland, name=Rijmmoáhppe I think it would be good to keep the set of possible values for the ’type’ tag small, so I’d like to propose another level of indirection; something like type=named_area, named_area=natural, natural=wetland, name=Peter’s Pot And having said all *that*, on the subject of adjacent-areas vs. relations, again as a renderer implementer, I very much prefer when there is one way rather than two of doing something. First of all, if there are two ways, I need to write code for both of them. Second, some things invariably end up being tagged with *both* schemes (adjacent areas with name tags *and* a relation) which means that I need to detect that case to eliminate duplicate labels. So if a majority of mappers find relations too hard to use, I think I would vote for the adjacent-areas method, even though using a relation seems ”cleaner”. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to put a name tag on an area with more than one type?
I certainly agree that we should not waste mapper's time, but in this case it was mainly actually to make it easier for myself with JOSM to find my way back to all small pieces in a fragmented landscape. Not having this relation makes editing a fair bit harder as you can't really see which parts belong to the same (name labels are really not that visible in JOSM) and you need to click your way through or create a filter on the name, but since you don't want it I will remove it. It will probably lead to more work for me rather than less, but I won't invent something that everyone is against. It's a value in keeping it simple too. So we can put that to the side, don't worry there will be no relations. Opentopomap has some interesting features, but also it's own family of problems. The largest problem (except for limited server capacity) I think is that it renders borders between same tag areas, which causes lots of borders of technical polygon splitting visible, which exists everywhere in the map if you like it or not. The development also seems to have stopped, so any issues it has now won't probably be fixed. And does it render this "well-established method" by automatically finding adjacent parts and showing only one label. I'm still waiting for the result, but I would be *very* (happily) surprised if it does. If OSM had been a normally managed project there would be numbered releases of a well-defined specification how OSM data should be interepreted by renderers. When there is no such thing, how can we expect that other renders should solve things, without documentation? There's so often reference to "other renderers" that does things right, but where's the examples? There may be one renderer that make some things right, but then others wrong (like opentopomap)... that there really is no showcase renderer under the control of OSM itself I personally think is the largest waste of mapper's time we do. I see people skipping things, guessing, making "creative" incorrect mappings just because OSM-Carto is so limited in what it can do. Not only beginners, also experienced mappers. Just one example, some are so fed up of that OSM-Carto cannot remove text of rivers inside lakes so they cut up the river and remove the name instead. If OSM-Carto quality and feature set would go up and the documentation (for mappers) with it, so would the geo data, of that I'm convinced. /Anders On 2020-12-14 21:45, Joseph Eisenberg wrote: Re; "Don't adjust your mapping to what you believe is most convenient for data users" I know this recommendation is unpopular with some mappers, because many of us just want to see a good-looking map, and if it takes duplicating relations and extra mapping work we will do it. But remember that your time as a mapper, even though you give it to OpenStreetMap freely, is actually valuable and should never be wasted on doing things that can be solved by better software on the database user end of things. We should never ask 10,000 mappers to spend 10 hours a year each to add something to the database which saves 10 hours of work for a database user. Sometimes this means that the rendering on openstreetmap.org [1] won't look perfect, but we can expect better results in the future with more advanced renderers. Consider for example how OpenTopoMap has really great natural=peak and natural=saddle rendering, which uses elevation and topography to adjust the rendering to look good with the contour lines and different zoom levels. This is somewhat complex, but it was done by an open-source, free map style. Once upon a time I planned to add prominece=* tags to all the peaks in my area so I could get good rendering results, but the solution which OpenTopoMap uses is much better: it's fully automated and fast. Adding the topographic prominence to every natural=peak to get better rendering is a huge waste of mapper time, when you can instead calculate it (or better yet the topographic isolation) at the time of rendering. Similarly mappers shouldn't map a huge relation which includes all parts of the water in a long river, since it is much easier to map and maintain smaller closed ways for each short part of the river water. If database users need one big area, they can pre-process the data to create the polygons: don't make life harder for mappers to save the database users a few CPU cycles. Your time is priceless, fellow mappers. The time of database users is usually a business expense. -- Joseph Eisenberg On Mon, Dec 14, 2020 at 10:44 AM Christoph Hormann wrote: Anders Torger hat am 14.12.2020 15:49 geschrieben: Okay, but why does the OSM-Carto renderer, and all other renderers known to man(?) make multiple text labels then, when it should be a single one? OSM-Carto renders labels primarily based on the following constraints: * due to the requirement of real time updat
Re: [Tagging] How to put a name tag on an area with more than one type?
Ok, understood. However as far as I know OSM lacks a standard document for render implementors to actually know how data should be interpreted. And if OSM-Carto does it wrong (albeit due to technical limitations), how can we expect that anyone else would do it right? Unfortunately I think the answer is that there is no documentation, and no other data consumer will do it correct. I may be wrong though, it would be great to know if there is any renderer out there that understands that it is a single entity and merge the labels. I actually don't enjoy being on this list creating havoc or plaguing you or anyone else with my daft questions, and I suspect people here doesn't enjoy my company much either :-), but don't worry this thread is nearing the end and I'll crawl back under my rock again and go back to mapping, which is what I truly want to do. But OSM in its current state with the way the docs and technical platform is made really begs for this to happen as soon as someone like me starts to make high detail mapping, and wants answers instead of just skipping, guessing or simplifying when tagging challenges arise. The only reason I get here is when the OSM wiki doesn't have answers, and on top of that I get pretty much random answers on OSM Help (which seems to be standard), and I need to go here to just get to know how one should map certain features, if it even is possible. Even here there are various answers and ideas circulating and it's not hard to see the cracks in the facade and different ideas even among "high ranking" OSM people. The truth is that OSM is not really ready for this type of mapping, and that's fine, but it seems to be ultra-sensitive to touch on the subject that maybe actually something in the technical platform needs development to meet the long-standing goals of OSM. I also react on the lack of vision and what seems to be a technical dead end of the platform. The way you express it makes it seem like OSM is dependent on external software providers. Forgive me for my ignorance, but don't we have "own" programmers? I know this isn't a traditional open-source project (which I'm used to contributing to), but aren't there at least some programmers that develop the technical platform according to the vision OSM has? Or do we just pick ready-made tools that are designed in other projects for other uses and we have no power to influence? If it's the latter I'm really worried... There are levels regarding "high quality cartography". We don't need to jump directly to the highest level with smartly scaled/shaped and sorted text labels. I would to start with be satisfied with correct rendering, and rendering multiple text labels where there by definition should be one I consider incorrect. If even that is "too expensive" no meet the goal(?) of "low quality low price", well, then I'm speechless. I've heard big words come out from the OSM foundation, about striving to provide the best geodata. Really motivational, making it enjoyable to contribute as a mapper. However when I see how the technical platform works today, and which features that are missing and on top of that get on this list and see the lack of interest and/or capacity to do anything about it I see a whole different story. /Anders On 2020-12-14 19:41, Christoph Hormann wrote: Anders Torger hat am 14.12.2020 15:49 geschrieben: Okay, but why does the OSM-Carto renderer, and all other renderers known to man(?) make multiple text labels then, when it should be a single one? OSM-Carto renders labels primarily based on the following constraints: * due to the requirement of real time updates more complex operations are severely restricted. Clustering features, aggregating the clusters geometry-wise and labeling the aggregates are such operations. * we want the relationship between the data in the database and the rendering results to be intuitively understandable for the mapper so they can derive useful feedback from the map. That also limits the complexity of data processing we can use. * like all zoomable interactive maps OSM-Carto has to deal with the problem that high quality labeling is zoom level dependent. At the same time having different approaches to labeling at different zoom levels adds a lot of complexity to the style - and OSM-Carto is already one of the most complex map styles in existence. Hence compromises are made that look better on some zoom levels than on others. As far as other map styles are concerned - i have said that before: high quality cartography is expensive and the bulk of the digital map market is low quality and low price - hence requires low costs. And the willingness to engage in strategic investment in methods for high quality cartography in the wider OSM ecosystem as well as in the open source GIS sector is so far rather small. What can you do as a mapper: Produce an accurate r
Re: [Tagging] How to put a name tag on an area with more than one type?
On 2020-12-14 15:22, Christoph Hormann wrote: Anders Torger hat am 14.12.2020 14:01 geschrieben: But i already explained that the fact that in OSM we add name tags to parts of roads, waterways, wetlands, forests or woods does not mean these are somehow separate from other features with the same name tags. Names of physical geography features in OSM are - as explained - local names. A polygon tagged natural=wood + name=foo means that this is an stretch of land covered with trees that locally is referred to with the name 'foo'. If you took a walk on a route that crosses such polygon you can correctly say that today's hike took you through 'foo'. However if your walk crossed five natural=wood polygons with name=foo you *cannot* say based on this that your walk took you through five 'foo' or through five parts of 'foo'. The splitting of the wood into five polygons is part of the data model we use, it does not represent any 'five-ness' is the verifiable reality. Okay, but why does the OSM-Carto renderer, and all other renderers known to man(?) make multiple text labels then, when it should be a single one? Look at the result, it looks horrible. Do you really think this is the way it should be done, also long-term? Also note that the tags do differ, otherwise it would be a single multipolygon, it's both wetland=bog and wetland=marsh. Why have I got the recommendation, by no lesser than Frederik Ramm (which I afterwards have figured out is a Geofabrik guy so he's probably pretty influential), to NOT split forests, "one feature should be one polygon": https://help.openstreetmap.org/questions/77436/is-it-okay-to-split-forest-into-multiple-parts-with-arbitrary-seams I've got suggestions of 4 - 5 different ways to handle these type of situations including drawing a new polygon on top of everything and not just care about JOSM warnings or OSM-Carto results. Probably all these suggestions coming from OSM contributors much more experienced than I am. As a newcomer I don't know who anybody is, what authority each of these posts have. So I think I have some right to be confused... and indeed I have got suggestion in this list to actually use a relation by at least one contributor, I don't remember from who now but I guess I can dig it out from the thread somewhere. "Verifiable" is tricky in terms of names of natural features as we all know, as many of those haven't defined borders. [...] I think you have a pretty fundamental misunderstanding here. I don't think so based on verifiability definition on the osm wiki, where borders are indeed discussed. But that's an irrelevant meta discussion, I'll leave it at that. Fuzzy areas do lack full verifiability as you cannot get a clear definition "is this inside or outside the area". As Frederik has pointed out in a different post this leads to some issues. I hope we can overcome those though. /Anders ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to put a name tag on an area with more than one type?
dian Ocean is, and renderers should consider drawing a label". Note that this is not "tagging for the renderer" (which is often code for "tagging that I don't like"), these are real, major features that actually exist in the real world and their absence makes OSM weaker. On Mon, Dec 14, 2020 at 8:04 AM Anders Torger wrote: To make a specific answer to "what additional verifiable local knowledge" this relation is intended to cover, is that the wetland is a single named entity, not multiple entities named the same. And here's some elaboration. This is 4 km wide wetland, in the real world named as a single entity, but it does consist of both bog and marsh, in the screenshot named each separate part as you suggested: https://www.torger.se/anders/downloads/Screenshot_2020-12-13-OpenStreetMap.png "Verifiable" is tricky in terms of names of natural features as we all know, as many of those haven't defined borders. Wetlands maybe so, but even in this case, are the small satellite wetlands part of Rijmmoàhpe or not? Noone knows, it was never defined. That's the way these names work. Does that mean that these type of names should not be in OSM at all? You tell me. I just try to contribute geodata to make maps for outdoor use. If OSM is not the platform, let me know. I'm not particularly experienced in how OSM use relations and why the are so "obnoxious" as Mateusz put it, but I have worked with arranging data in many projects and to me this is an obvious case of data that should be arranged as a container with all its parts. I also think that it would make it much easier to fix the renderer, it can easily get all parts for the single name, and as a added bonus get to know the "master type" (instead of having to go through all parts calculate the area to figure out which nature that is dominant to get the tag styling right). Etc. I didn't add it thinking about any renderer though, it was actually for myself to more easily keep track of all parts when editing on JOSM. With a parent relation I just need to click on one, and then on the parent relation to get all selected. Otherwise I need to create a filter on the name or something, so to me it's also more efficient for the mapper. And in the end I think that the individual parts should not have name tags at all, it should only be on the parent relation. The reason we put it on the individual parts now is to me obviously just because there is no renderer support available anywhere for naming these type of natural entities, and probably will stay that way for the foreseeable future. Having a relation on these new features makes them easy to find in the database and one can upgrade the tags later. I suppose it's much more complicated to make a filter to find parts named the same with shared borders, I don't really know how to do it in JOSM (but maybe one can?). So that's my reasons, but if you think they're bad I'll remove the relation. I would like to hear how you want to solve the problem instead though. As you see on the screenshot, the current situation is far from optimal with lots of tiny name tags where there should be only one. /Anders On 2020-12-14 13:28, Christoph Hormann wrote: Anders Torger hat am 14.12.2020 07:59 geschrieben: I'll gladly answer questions, but I think you need to rephrase. I suppose it is some hidden critique in there, but I honestly do not understand the question. It would be better for me if you put words on the critique instead of wrapping it in a question. There is no critique in there, i have not formed an opinion on the concept, i like to understand the reasoning behind this. Hence the question. The premise is that in OSM we record verifiable local knowledge about the geography of the world. And we try to record that in a form that is most efficient for the mapper. Hence the question what additional verifiable knowledge you intend to record with the additional data structures you propose to create that is not yet in what we already record today. -- Christoph Hormann https://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging Links: -- [1] http://openstreetmap.org___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to put a name tag on an area with more than one type?
I should have added that a long-term solution is probably some sort of collective concept to handle fuzzy natural areas, and then this wetland will also be named as a fuzzy natural area, although less fuzzy than your typical natural fuzzy area :-). But how long will that take to get realized, when a single tag can take years? I'd like to have some placeholder tagging for later upgrading so the data can be effective now rather than potentially never. So to me lots of small names all over the wetland and a relation to be able to find them later is indeed an ugly but still an acceptable stepping stone, and not the least a good reminder than something needs to be done. /Anders On 2020-12-14 14:01, Anders Torger wrote: To make a specific answer to "what additional verifiable local knowledge" this relation is intended to cover, is that the wetland is a single named entity, not multiple entities named the same. And here's some elaboration. This is 4 km wide wetland, in the real world named as a single entity, but it does consist of both bog and marsh, in the screenshot named each separate part as you suggested: https://www.torger.se/anders/downloads/Screenshot_2020-12-13-OpenStreetMap.png "Verifiable" is tricky in terms of names of natural features as we all know, as many of those haven't defined borders. Wetlands maybe so, but even in this case, are the small satellite wetlands part of Rijmmoàhpe or not? Noone knows, it was never defined. That's the way these names work. Does that mean that these type of names should not be in OSM at all? You tell me. I just try to contribute geodata to make maps for outdoor use. If OSM is not the platform, let me know. I'm not particularly experienced in how OSM use relations and why the are so "obnoxious" as Mateusz put it, but I have worked with arranging data in many projects and to me this is an obvious case of data that should be arranged as a container with all its parts. I also think that it would make it much easier to fix the renderer, it can easily get all parts for the single name, and as a added bonus get to know the "master type" (instead of having to go through all parts calculate the area to figure out which nature that is dominant to get the tag styling right). Etc. I didn't add it thinking about any renderer though, it was actually for myself to more easily keep track of all parts when editing on JOSM. With a parent relation I just need to click on one, and then on the parent relation to get all selected. Otherwise I need to create a filter on the name or something, so to me it's also more efficient for the mapper. And in the end I think that the individual parts should not have name tags at all, it should only be on the parent relation. The reason we put it on the individual parts now is to me obviously just because there is no renderer support available anywhere for naming these type of natural entities, and probably will stay that way for the foreseeable future. Having a relation on these new features makes them easy to find in the database and one can upgrade the tags later. I suppose it's much more complicated to make a filter to find parts named the same with shared borders, I don't really know how to do it in JOSM (but maybe one can?). So that's my reasons, but if you think they're bad I'll remove the relation. I would like to hear how you want to solve the problem instead though. As you see on the screenshot, the current situation is far from optimal with lots of tiny name tags where there should be only one. /Anders On 2020-12-14 13:28, Christoph Hormann wrote: Anders Torger hat am 14.12.2020 07:59 geschrieben: I'll gladly answer questions, but I think you need to rephrase. I suppose it is some hidden critique in there, but I honestly do not understand the question. It would be better for me if you put words on the critique instead of wrapping it in a question. There is no critique in there, i have not formed an opinion on the concept, i like to understand the reasoning behind this. Hence the question. The premise is that in OSM we record verifiable local knowledge about the geography of the world. And we try to record that in a form that is most efficient for the mapper. Hence the question what additional verifiable knowledge you intend to record with the additional data structures you propose to create that is not yet in what we already record today. -- Christoph Hormann https://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to put a name tag on an area with more than one type?
To make a specific answer to "what additional verifiable local knowledge" this relation is intended to cover, is that the wetland is a single named entity, not multiple entities named the same. And here's some elaboration. This is 4 km wide wetland, in the real world named as a single entity, but it does consist of both bog and marsh, in the screenshot named each separate part as you suggested: https://www.torger.se/anders/downloads/Screenshot_2020-12-13-OpenStreetMap.png "Verifiable" is tricky in terms of names of natural features as we all know, as many of those haven't defined borders. Wetlands maybe so, but even in this case, are the small satellite wetlands part of Rijmmoàhpe or not? Noone knows, it was never defined. That's the way these names work. Does that mean that these type of names should not be in OSM at all? You tell me. I just try to contribute geodata to make maps for outdoor use. If OSM is not the platform, let me know. I'm not particularly experienced in how OSM use relations and why the are so "obnoxious" as Mateusz put it, but I have worked with arranging data in many projects and to me this is an obvious case of data that should be arranged as a container with all its parts. I also think that it would make it much easier to fix the renderer, it can easily get all parts for the single name, and as a added bonus get to know the "master type" (instead of having to go through all parts calculate the area to figure out which nature that is dominant to get the tag styling right). Etc. I didn't add it thinking about any renderer though, it was actually for myself to more easily keep track of all parts when editing on JOSM. With a parent relation I just need to click on one, and then on the parent relation to get all selected. Otherwise I need to create a filter on the name or something, so to me it's also more efficient for the mapper. And in the end I think that the individual parts should not have name tags at all, it should only be on the parent relation. The reason we put it on the individual parts now is to me obviously just because there is no renderer support available anywhere for naming these type of natural entities, and probably will stay that way for the foreseeable future. Having a relation on these new features makes them easy to find in the database and one can upgrade the tags later. I suppose it's much more complicated to make a filter to find parts named the same with shared borders, I don't really know how to do it in JOSM (but maybe one can?). So that's my reasons, but if you think they're bad I'll remove the relation. I would like to hear how you want to solve the problem instead though. As you see on the screenshot, the current situation is far from optimal with lots of tiny name tags where there should be only one. /Anders On 2020-12-14 13:28, Christoph Hormann wrote: Anders Torger hat am 14.12.2020 07:59 geschrieben: I'll gladly answer questions, but I think you need to rephrase. I suppose it is some hidden critique in there, but I honestly do not understand the question. It would be better for me if you put words on the critique instead of wrapping it in a question. There is no critique in there, i have not formed an opinion on the concept, i like to understand the reasoning behind this. Hence the question. The premise is that in OSM we record verifiable local knowledge about the geography of the world. And we try to record that in a form that is most efficient for the mapper. Hence the question what additional verifiable knowledge you intend to record with the additional data structures you propose to create that is not yet in what we already record today. -- Christoph Hormann https://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to put a name tag on an area with more than one type?
Hello Frederik, good and clearly communicated points! I very much appreciate that, and I agree with the issues you describe. Those are indeed real problems. However, these fuzzy regions also exist on a small scale, and in my case it's always been about that. The features I'm mapping now are not the scale of "The Alps" or even the Black Forest, it's a named wetlands, 1-5 km wide, a single mountain, a slope, a hill, a heath, a small bay or strait in a lake, etc. These names are everywhere, with more or less defined borders (often less). Maybe there should be one system of fuzzy areas to handle both of these cases, or maybe there should be two, maybe small scale geography could be in OSM and large scale should be outside. I don't know. What I do know is that any institutionally made map has these names and that these are important for outdoor maps, just like names on lakes, and if we want OSM to be able to provide data for rendering high quality maps these names must be available somewhere and somehow. I hope that I don't need to argue that these names do have a place in maps, actually I think they are quite important for certain types of maps. I understand that probably outdoor maps is not a priority for most commercial uses of OSM, so it may not be much money in supporting this. I guess what people want to know on average is the nearest café in an urban area, not a guide in a remote national park. So I could also accept that OSM is not the place for storing geodata for outdoor maps, as long as it's clearly stated. It does feel like the normal OSM tagging process isn't really fit for making progress in this space, as this may require some strategic decisions implementing and making use of new technical platforms. So the first thing I'd like to see is that we get a consensus on a goal that we actually *want* these type of features, and then the exact solution can be discussed. As it is now we seem stuck at status quo, and I just see lots of passive opposition, my ideas of implementation are indeed probably not the greatest so I understand they get criticism and fairly so, but in the end I just stand there back at square one with the same problem and no solution in sight. There are indeed some good efforts to try to solve this for "The Alps" and similar names large scale names: https://github.com/dieterdreist/OpenGeographyRegions . Maybe this also could be used for small scale names I don't know, but these type of projects have little chance of catching on without coordinated support from a renderer and "official" OSM wiki docs with usage recommendations so mappers actually get to use it and contribute and eventually see the result. /Anders On 2020-12-14 12:39, Frederik Ramm wrote: Hi, On 14.12.20 12:20, Anders Torger wrote: My sense is that OSM community do want naming in nature as well, but only if it can be made very simple. Unfortunately that is not always compatible with reality, and here we are... Personally I think naming is desirable for clear features. This mountain peak, this protected tree, this lake. What I don't like in OSM is naming for large geographic areas, like "the Alps", "the Black Forest", or "the Bay of Biscay", for two reasons: First, there can be any number of such areas. Anyone can invent something. I can speak of the Alps, or the French Alps, or the Northern French Alps, or the Vanoise Massif, I can group some regions at will and make up a new name. These are not administrative boundaries where it is clear which of them exist "as a region" and and which don't. Of course everyone knows what I mean when I say "Germany north of Oldenburg" but that doesn't mean that "Germany north of Oldenburg" is a name that should be on the map, or a polygon we need in OSM. If I issue a tourist guide for, say, "Vanoise et Maurienna", does that then make "Vanoise et Maurienna" a region? How many people need to issue a tourist guide for this to happen? Second, these areas are usually ill-defined: There are some places that are clearly in the Black Forest, and some that are clearly not in the Black Forest, but there's not one boundary line - there's fuzziness. OSM is not good with fuzziness; OSM forces us to have an exact point or line or polygon for something. For fuzzy labels, you need a different system that should exist outside of OSM's current data types. Either by adding a new fuzzy data type to OSM (no need to assemble 1000 ways with a total of 20,000 points to exactly describe the outline of the Alps if all you want is a nice big lettering in approximately the right spot), or by keeping these cartography options in a separate system altogether. Bye Frederik ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to put a name tag on an area with more than one type?
Yeah, you may be right, but I see it like this: in cases where "complex"
naming is a reality, complex schemes are unavoidable, if we want to
support it at all. It's not like one would use the most complex method
in every case, just where it's needed. To use an old saying, Einstein I
think: "make it as simple as possible, but no simpler". Now we are at
some places making it so simple that it becomes incorrect.
I haven't really figured out if the OSM community as a whole actually
want to support these types of things though. It's quite meaningless to
fight for a tiny feature in this space if the whole concept of naming
nature is frowned upon. That there are so many features still missing or
poorly defined in this space after so many years does indicate that it
has least hasn't been a priority. It's called open*street*map after
all...
My sense is that OSM community do want naming in nature as well, but
only if it can be made very simple. Unfortunately that is not always
compatible with reality, and here we are...
/Anders
On 2020-12-14 11:39, Mateusz Konieczny via Tagging wrote:
Relations are quite obnoxious in regular editing and also
during actually using the data.
Dec 14, 2020, 08:07 by and...@torger.se:
Why is the relation problematic (honest question)?
I was starting to think that some sort of naming relation could be the
answer, ie you put both peaks in a relation with for example type=name;
natural=mountain; name=Kebnekaise.
In addition one should write clearly that peak serves dual purpose both
as naming peaks and mountains. Today on the wiki the peak is clearly
defined as only the summit, but it's often used as naming mountains
where the peak is nameless.
What we also could have is fuzzy naming areas, which we would need in
some way or another at some point anyway, so you would have an area
covering the mountain with name=Kebnekaise. I would have no problem
with that, but it seems to that it must be in a separate database as it
just too controversial to be in the main database.
/Anders
On 2020-12-13 21:12, Mateusz Konieczny via Tagging wrote:
Dec 13, 2020, 19:58 by and...@torger.se:
Do you have a suggestion of how to map Sweden's highest mountain,
Kebnekaise?
The mountain is called Kebnekaise, it has two peaks, one is called
"Sydtoppen" ("the south peak"), the other "Nordtoppen" ("the north
peak").
I admit that I have no good idea, if I would run into such case and
failed to find a better idea
(hopefully one will come) I would invent a new way to tag that.
natural=mountain? Main problem is where to put it - node at arbitrary
position between peaks?
Node at location of highest peak? Area? Relation? All of that is sadly
problematic.
(The mountain_range tag is a great tag, but I note that its status is
just "in use", it's not an approved tag :-O.)
It is perfectly fine to use tags that never went through tagging
proposal, though
I am not going to endorse this one. Tagging mountain ranges seems to
poorly fit OSM
with multiple different opinions where mountain range starts/ends and
inability to
verify it by survey.
All tags were in some stage rarely used before becoming heavily used,
only some cases went through a proposal process.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to put a name tag on an area with more than one type?
Sorry for perhaps adding further complexity, but if you haven't noted, one thing that crawls under the surface when it comes to names in nature is this "holy" principle: https://wiki.openstreetmap.org/wiki/Verifiability Names of natural features often don't have strict borders. Wetlands as in this example is typically quite defined, but there are cases also in Muddus when the wetland is so large that it has one name in one end and another name in the other. So I have to split the wetland at some point I find "suitable". That is not verifiable, there's never been a defined border, and another mapper could choose a slightly different split line. I don't see it as a big issue, as long as renderers don't render and outline these borders, but I can "read between the lines" that some on this list do. However fuzzy borders like this is not some narrow special case. Names in nature is very often this way, and many names have survived from times when the civilization weren't even much bothered by such borders at all. In lakes and sea we have a lot of these too of course, and there the fuzzy areas bay and strait actually do exist and serves the cartography well, but not without protests... I've seen desire to have these removed completely. I think OSM should either strive support nature naming as it works in reality (and document how to tag), or make a clear statement that names of this type should not exist in the database. I think the latter would be sad, but at the same time I find it extremely frustrating to get what I experience as "passive opposition" when I bring up these kind of needs. A clear statement would be nicer. On the verifiability page above there actually are is an example of fuzzy areas and that those can be accepted (hamlet used as an example). Nature naming is not discussed though. /Anders On 2020-12-14 10:41, Anders Torger wrote: For reference, here's Rijmmoáhpe again, a wetland which is about 4 km across, consisting of both bog and marsh: https://www.torger.se/anders/downloads/Screenshot_2020-12-13-OpenStreetMap.png It's located in Muddus national park, Sweden. I'm quite sure the recommendation Christoph refers to is simply to put names on each separate part, which is seen in the screenshot. It's unclear to me if this is seen by Christoph and others as a final and good solution, or just as "the best we can do for the moment". So I hope to get a clarification on that. Personally I see it as "the best we can do for the moment", but think that it of course should be rendered as a single name, and as such the name tag should not really be on each separate part, but on a relation. Sure a renderer could trace around and scan for neighboring areas with the same name and automatically, calculate the area of each part to find out the dominant nature type (required for name tag styling), and place a single name, but to me it does not seem like a proper way to arrange geo data for a single named natural entity. So what I have done in addition is to create a relation with type=natural; natural=wetland; name=Rijmmoáhpe with all the parts as members (role field unset). If that is just too controversial, I can skip that and leave with just naming the parts. I planned to do that at first, but as some of these natural features are quite heavily fragmented in small pieces just for a management point of view in JOSM I found this relation to be practical thing to have, so I added it. There's a whole family of unanswered questions regarding to names of nature. If Martin's fuzzy area concept was accepted and used https://github.com/dieterdreist/OpenGeographyRegions maybe many of these features would use that instead. Or maybe if place=locality concept on points was developed and diversified that could be used instead. I don't have any strong opinions on which method to use, I just want to be able to map with high detail and high quality and use any method that works. On 2020-12-14 10:05, Ture Pålsson via Tagging wrote: 13 dec. 2020 kl. 16:15 skrev Christoph Hormann : I am trying to understand what the issue is with the recommendation for mapping you have received from multiple sides here. Just to clarify, could you summarise what that recommendation is, for the Rijmmoáhpe case? The thread has become a little unwieldy (partially my fault... sorry about that!). ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to put a name tag on an area with more than one type?
For reference, here's Rijmmoáhpe again, a wetland which is about 4 km across, consisting of both bog and marsh: https://www.torger.se/anders/downloads/Screenshot_2020-12-13-OpenStreetMap.png It's located in Muddus national park, Sweden. I'm quite sure the recommendation Christoph refers to is simply to put names on each separate part, which is seen in the screenshot. It's unclear to me if this is seen by Christoph and others as a final and good solution, or just as "the best we can do for the moment". So I hope to get a clarification on that. Personally I see it as "the best we can do for the moment", but think that it of course should be rendered as a single name, and as such the name tag should not really be on each separate part, but on a relation. Sure a renderer could trace around and scan for neighboring areas with the same name and automatically, calculate the area of each part to find out the dominant nature type (required for name tag styling), and place a single name, but to me it does not seem like a proper way to arrange geo data for a single named natural entity. So what I have done in addition is to create a relation with type=natural; natural=wetland; name=Rijmmoáhpe with all the parts as members (role field unset). If that is just too controversial, I can skip that and leave with just naming the parts. I planned to do that at first, but as some of these natural features are quite heavily fragmented in small pieces just for a management point of view in JOSM I found this relation to be practical thing to have, so I added it. There's a whole family of unanswered questions regarding to names of nature. If Martin's fuzzy area concept was accepted and used https://github.com/dieterdreist/OpenGeographyRegions maybe many of these features would use that instead. Or maybe if place=locality concept on points was developed and diversified that could be used instead. I don't have any strong opinions on which method to use, I just want to be able to map with high detail and high quality and use any method that works. On 2020-12-14 10:05, Ture Pålsson via Tagging wrote: 13 dec. 2020 kl. 16:15 skrev Christoph Hormann : I am trying to understand what the issue is with the recommendation for mapping you have received from multiple sides here. Just to clarify, could you summarise what that recommendation is, for the Rijmmoáhpe case? The thread has become a little unwieldy (partially my fault... sorry about that!). ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to put a name tag on an area with more than one type?
Why is the relation problematic (honest question)?
I was starting to think that some sort of naming relation could be the
answer, ie you put both peaks in a relation with for example type=name;
natural=mountain; name=Kebnekaise.
In addition one should write clearly that peak serves dual purpose both
as naming peaks and mountains. Today on the wiki the peak is clearly
defined as only the summit, but it's often used as naming mountains
where the peak is nameless.
What we also could have is fuzzy naming areas, which we would need in
some way or another at some point anyway, so you would have an area
covering the mountain with name=Kebnekaise. I would have no problem with
that, but it seems to that it must be in a separate database as it just
too controversial to be in the main database.
/Anders
On 2020-12-13 21:12, Mateusz Konieczny via Tagging wrote:
Dec 13, 2020, 19:58 by and...@torger.se:
Do you have a suggestion of how to map Sweden's highest mountain,
Kebnekaise?
The mountain is called Kebnekaise, it has two peaks, one is called
"Sydtoppen" ("the south peak"), the other "Nordtoppen" ("the north
peak").
I admit that I have no good idea, if I would run into such case and
failed to find a better idea
(hopefully one will come) I would invent a new way to tag that.
natural=mountain? Main problem is where to put it - node at arbitrary
position between peaks?
Node at location of highest peak? Area? Relation? All of that is sadly
problematic.
(The mountain_range tag is a great tag, but I note that its status is
just "in use", it's not an approved tag :-O.)
It is perfectly fine to use tags that never went through tagging
proposal, though
I am not going to endorse this one. Tagging mountain ranges seems to
poorly fit OSM
with multiple different opinions where mountain range starts/ends and
inability to
verify it by survey.
All tags were in some stage rarely used before becoming heavily used,
only some cases went through a proposal process.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to put a name tag on an area with more than one type?
I'll gladly answer questions, but I think you need to rephrase. I suppose it is some hidden critique in there, but I honestly do not understand the question. It would be better for me if you put words on the critique instead of wrapping it in a question. I think it's fairly obvious that if the common method to tie together several separate entities that has a single name is to make a single multipolygon-relation with several outers, there should also be a relation for a single named entity with multiple natural types. It can't be a multipolygon, so it must be something else. Naming single entity natural features split into several sub-types is currently not a supported feature by OSM, although it is very hard to get people to actually say that (some do on this list, some don't). And after that it's very hard to get a statement if this missing feature is desirable to implement, or if OSM is not the place for this type of detailed geo data. I find that you are one of those that are very mysterious about what you actually think ;-), but seems to strive for status quo, so I assume that you think that the thing I need here is already supported sufficiently well, but I don't know, as you haven't said. /Anders On 2020-12-13 20:37, Christoph Hormann wrote: Anders Torger hat am 13.12.2020 20:08 geschrieben: [...] I think to actually have them all tied together in a unit is still a good idea, [...] That does not answer my question. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to put a name tag on an area with more than one type?
Like every Swede I have climbed the mountain, so I do have some local knowledge :-). There is an arete there, that's correct, but it's not named. Kebnekaise is the name of the mountain. It's Sami lands, as far as I understand the names of the mountains came first, then the names of the peaks came much later when people got interested in mountaineering, hence often anonymous names like "the grand peak", "the south peak" etc. In the past noone had time to entertain themselves with climbing mountains for fun :-). If we go to lower mountains in Sweden then peaks generally fit better as then people were closer around and hence say 90% of the time the mountain name is also the peak name. But sometimes there's a situation when the mountain has more than one peak, none of which is named, but the mountain is named. There's also situations where there are multiple nearby small peaks with separate names, and then the all have a group name, without really being a huge massif (the example I'm thinking about all small peaks are within 5 km on a single mountain). /Anders On 2020-12-13 21:30, Joseph Eisenberg wrote: Currently the features with the tag "name=Kebnekaise" are 2 ways which extend north-south and to the west from these two peaks and are also tagged natural=arete (an arete is a knife-edged ridge formed between 2 glaciers). https://www.openstreetmap.org/way/123215393#map=13/67.8934/18.4509=C https://www.openstreetmap.org/way/407174801#map=14/67.8999/18.5215=C Is this correct based on your local knowledge of the area?___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to put a name tag on an area with more than one type?
A common established method to name natural features with separated parts is as a multipolygon with several outers. There is one object that ties them all together. In this case a multipolygon is not possible, since the member types differ and "outers" share segments. I think to actually have them all tied together in a unit is still a good idea, it is one entity, not multiple entities named the same. If this ever gets supported by a renderer the logical way would be to have the name only on the relation and no name on the separate parts. /Anders On 2020-12-13 16:15, Christoph Hormann wrote: Anders Torger hat am 13.12.2020 15:28 geschrieben: So what I've settled for (for now) is as follows: - same name on each part (the only way to get the data useful *today*) - a new relation with all parts as members (role unset), type=natural, natural=wetland, name= I am trying to understand what the issue is with the recommendation for mapping you have received from multiple sides here. So what exactly is the verifiable knowledge that is supposed to be represented by your new relation type that is not already recorded in the mapping of physical features? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to put a name tag on an area with more than one type?
Do you have a suggestion of how to map Sweden's highest mountain,
Kebnekaise?
The mountain is called Kebnekaise, it has two peaks, one is called
"Sydtoppen" ("the south peak"), the other "Nordtoppen" ("the north
peak").
Currently it's mapped with the two peaks where one is called "Kebnekaise
Sydtoppen" and the other "Kebnekaise Nordtoppen". Not really correct,
but perhaps the least bad way to do it? When zooming out, on a regular
map you see the Kebnekaise name big over the mountain, but the names for
Sydtoppen and Nordtoppen is removed. I'd love something like a
possibility to put the peaks in a relation and put the mountain name in
the relation in cases like this.
Kebnekaise is not the only example, it's quite common with Swedish
mountain that the peaks themselves have quite anonymous names like those
on Kebnekaise, "Stortoppen" (the great peak) is another common name of
the highest peak on a Swedish mountain, where the mountain itself has a
different (and unique) name. You don't want to see the anonymous
"Stortoppen"-name when you zoom out the map. OSM-Carto has "solved"
these name prominence issues by removing all names pretty much
immediately, rendering overview maps useless.
One problem with the current peak tag is that the renderer has no
information about the size of the mountain. A peak even if really high
can be a small local peak on top of a large plateau.
(The mountain_range tag is a great tag, but I note that its status is
just "in use", it's not an approved tag :-O.)
/Anders
On 2020-12-13 18:54, Joseph Eisenberg wrote:
1) To tag a named "Torp" it sounds like there are several different
correct options, depending on what currently exists at the location.
If there is a single family home or a couple of homes used as
residences, it would be a place=isolated_dwelling mapped as a node at
the centre.
If it is still used as a farm, then place=farm can be used on a node
instead. This is treated as similar to place=isolated_dwelling by many
data users. It is also possible to map the area of the farmyard (around
the buildings) as landuse=farmyard and add the name to this feature, if
the name is only for the actual farm buildings and not for all the
surrounding areas.
For a named settlement with more than 2 families (but smaller than a
village), place=hamlet on a node would be appropriate. I'm not sure if
a torp is every that large?
If the torp is no longer inhabited, you can use a lifecycle tag to show
this: e.g. abandoned:place=farm or abandoned:place=isolated_dwelling or
abandoned:place=hamlet show that a former farm or small settlement are
now abandoned and no longer inhabited.
2) For a mountain:
Most mountains share a name with their highest peak, so natural=peak is
a great way to tag these.
But it's true that some "mountain" names are not the name of a peak. In
this case there are a couple other tags in use: natural=ridge is used
with a linear way which is drawn along the ridgeline. This works for
many named single ridges.
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dridge - example here:
https://www.opentopomap.org/#map=15/41.76382/-123.18038 -
https://www.openstreetmap.org/way/631166206/#map=13/41.7664/-123.1567=C
Sometimes a named "mountain" is not a single ridge but a whole range of
connected ridges. In this case we usually call it a "mountain range" in
English, and there is a somewhat uncommon tag for this
natural=mountain_range which I've used to map some ranges in my area.
This tag is harder to use. In some cases the best option is to use it
on a node at the center of the mountain range, in others it is possible
to use it on a linear way along the highest line of ridges at the
center of the mountain range.
https://wiki.openstreetmap.org/wiki/Tag%3Anatural%3Dmountain_range -
example:
https://www.openstreetmap.org/way/686647385#map=12/42.0515/-122.7575=C
While we can all disagree on how far down into the valley the mountain
extends, everyone agrees that the highest peak is part of the mountain,
so mapping peaks of a mountain as a node is 100% verifiably to be
correct. In some cases a linear way is also verifiable for a ridge or a
linear mountain range.
-- Joseph Eisenberg
On Sun, Dec 13, 2020 at 7:04 AM Ture Pålsson via Tagging
wrote:
13 dec. 2020 kl. 15:21 skrev Paul Allen :
I'm probably misunderstanding this, but torp doesn't seem to be a type
of
building. The tag building=torp says that this building IS a torp (as
opposed to a house, or a shop, or a garage, or a shed, or a barn).
If you feel a need to indicate that a building was once part of a torp,
building=torp isn't the way to do it.
You're right; I was extremely sloppy with terminology there. A torp is
(or rather was) a small farm, usually either part of a bigger farm and
farmed by a tenant, paying rent to the bigger farm in the form of work,
or farmed by a soldier (paying rent by, well, being a soldier). Today,
most of them are
Re: [Tagging] How to put a name tag on an area with more than one type?
Thanks. I also think that only having them tied by name is not a good concept. So what I've settled for (for now) is as follows: - same name on each part (the only way to get the data useful *today*) - a new relation with all parts as members (role unset), type=natural, natural=wetland, name= I don't intend this to be a final solution, but if that ever comes, having some sort of relation there makes it much easier to find and upgrade the tags. I'm unfortunately not in capacity to work with a pilot project, so this have to be done by "someone else" :-/. I also think that a "pilot project" should not really just look at one particular problem like this. There's a family of problems around mapping nature with high detail, and providing data that can be used to generate maps at different zoom levels. These are not unique to Sweden, but it's just basic cartography. The reason I stumble into these is not because I'm mapping in Sweden, it's because I'm mapping with high detail and have good data sources with access to those names (and also personal experience of using them and maps with them as I engage in outdoor activities). Norway has already come far with high detail land cover mapping here in rural north, much longer than we have in Sweden. They also have named nature, much of the naming is actually of the same type as this is part of Sami lands. How have our Norwegian friends solved the naming problem? Easy: by not putting any names in the map, except for lakes and stuff that is supported by OSM today. And this is of course what happens, and it's so frustrating. The inability of the OSM community to identify, implement and document basic cartography features leaves the geo data of lower quality than it could have been if these features would have been readily available for mappers to use *now*. It simply does not work that if a mapper needs a basic feature, he or she should then personally engage into OSM politics for many years(!) to *maybe* see it implemented. So instead most mappers just think "well, maybe I just skip that" and you don't get to hear about it and we can still pretend that noone actually needs the feature it's not realistic to think that OSM mappers in general should be persons deeply invested in how OSM community is organized and just jump right into the processes whenever needed. I think what mappers want to do is to map, and see their data on display *now*. I'm not blaming anyone, it's just an observation. I'm myself part of the OSM community, and I just said that I don't have the capacity to pull any strings in this type of pilot project, so I'm just as much to blame as any other. But now I'm at least putting the data in, so if someone eventually fixes this, the tags can be upgraded accordingly if needed. Before I did just like the typical mapper, I just skipped the names that couldn't be mapped properly, regardless of their importance. Now I try to put them in, in some way or another. /Anders On 2020-12-13 12:26, Peter Elderson wrote: My answer only targets the question in the subject. No matter whether you put the same name on all parts, or on or some kind of collective, you need a way for data users to know that all the parts together have a name. Tagging the same name on all parts makes the name a free text id needing uniqueness - for me a bad choice. Yet another polygon around the area, don't like that. I think we have too many of those already. Tagging all parts with a truly unique Id in a special key could do the trick, but who issues/manages the unique ids? Putting the parts as members in a relation achieves the same: a unique Id common to all the parts; the name tag and possible other common attributes go on the relation. This gives renderers the exact extent of the total area, and the extents of the subareas, which can have names and other attributes of their own. Since an MP does not cover all possible layouts, you would need a different type of relation. Maybe an existing type can be used, or a specialised type can be defined. I would think a pilot project could test the concept for mappers, renderers and other data users. If succesful, showcase. If not, document and delete. Peter Elderson Op vr 11 dec. 2020 om 17:11 schreef Anders Torger : Hello, I was on this list a while back expressing some frustration over limitations when tagging nature and thought about getting involved in a process for change, but I came to realize that it's not feasible for me in my current life situation, so I've decided to continue be a normal mapper as before, doing what I can do with features that exist today. Anyway, if to be a mapper at all, I still like to solve some of my naming issues in the best/least bad ways possible today. I'm currently mapping a national park in Sweden, Muddus. It's in Laponia and consists of mighty wetlands and old forest. These wetlands are n
Re: [Tagging] How to put a name tag on an area with more than one type?
We have these in the north as well, often old soldier settlements. Many are are still inhabited today, but the original building most often long gone. We also have those that are abandoned with little sign of that there ever being a building there. Strangely enough, sometimes the names for the abandoned places have more relevance today than those still inhabited. The inhabited places have modern addresses which are generally used instead, while the abandoned places can be used by hunters or other outdoor people for navigating in the landscape. But it varies place to place. I have use place=locality for some of these as I've seen others use it, but I haven't had time to give it much thought. It seems like we're trying to move away from place=locality and try to be more specific, which probably is a good idea. Currently I'm focusing mostly on nature. /Anders On 2020-12-13 11:10, Ture Pålsson via Tagging wrote: 12 dec. 2020 kl. 16:18 skrev Anders Torger : Indeed, place=locality seems to be a dead end, it's been misused quite much and there's talks about removing it from OSM-Carto, and you can't render good maps from it, so it's technically a poor concept as well. Around where I live (Stockholm), most place=locality seem to refer to old "torp" [1] and other (at least historically) inhabited places. At least the classic "Terrängkartan" (the "official" paper maps of Sweden, sadly no longer in production) rendered those differently from pure terrain names (upright vs. italic font). Here in the lake Mälaren valley almost every square meter has been farmed at some point, so most names refer to settled places (or archaeological traces of them). Up north where I grew up, and where Anders seems to be mapping, you get a lot more names that refer to bogs, slopes, mountains and that sort of thing. It would be nice to have that distinction in OSM, too. [1] https://en.wikipedia.org/wiki/Torp_(architecture) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to put a name tag on an area with more than one type?
Thanks. There are quite many abandoned tags for grouping things together, so site is in good company. It seems like site is mostly used for human-made features though, so I'm not sure it's suitable for natural features. For now I don't have the intention that the "natural" relation is going to be used by any renderer though, it's just to make it easy in JOSM to find all parts belonging to it. If some official method appears in the future it will be easy to do search and replace. /Anders On 2020-12-13 11:58, Hidde Wieringa wrote: I just wanted to add `Relation:site` [1] to this topic. This is not an approved tag (proposal [2], seems abandoned), but it is used to group 'things' together which cannot be grouped simply with a multipolygon. I do not expect this relation type to be rendered 'correctly' (whatever that may mean without a good proposal and definition) in many renderers, but the information will exist in OSM in a structured way for future renderers. Example query for South-Sweden: https://overpass-turbo.eu/s/119b Kind regards, _Hidde Wieringa_ [1] https://wiki.openstreetmap.org/wiki/Relation:site [2] https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site On 13-12-2020 11:28, Anders Torger wrote: Here's a real example of how this naming scheme ends up looking: https://www.torger.se/anders/downloads/Screenshot_2020-12-13-OpenStreetMap.png I have put the name on each part which is the enduring recommendation I've got. Some parts are multipolygons, some are just closed ways, as required. I also added a relation on top. I've got advice against that as no renderer will ever care, but I found that when editing it's hard to keep track of all parts big and small if there is no relation, so I added it as a help for the mapper. I set type=natural (to indicate that it's a natural object) and natural=wetland (to indicate what type of natural it is, without having to deduce from its members) and name on that relation. Nothing official, but at least easy to filter out and find. In Sweden the land cover mapping is heavily behind so I've started a mapping effort for natural areas and there are a bunch of naming problems to solve for which there is no documented way to do. So I do these reference areas and try to come up with the best methods (=least bad in some cases) so we in the local Swedish OSM community have something to refer to when new mappers want to help out and stumble into the same issues. As seen on the screenshot, the result in OSM-Carto looks pretty horrible, and to my knowledge it will be as horrible in any other renderer out there as the feature of naming "complex" nature just don't exist. It's the usual problem: mappers won't map things that don't show up on any renderer (or displays horribly like this), and renderers won't implement functions for things that aren't mapped. The OSM way is that mappers should take the lead and renderers will eventually follow (maybe). I think that process works really poorly today (the main reason being that OSM is just too large and diverse now for the original processes to work, in global scope every feature becomes just a tiny special interest not worth considering). That we still lack these cartography features 14 years into the project is witness to that. We need a render engine to take the lead, and more well-defined standard of how to arrange the data. I've got 4 - 5 different suggestions of how to put a name on this wetland. Imagine if all those naming schemes gets used, what a mess to implement a renderer... /Anders On 2020-12-13 00:55, stevea wrote: I don't approach this as getting solved in one multipolygon. I might use two multipolygons, one tagged wetland=bog, another tagged wetland=marsh, both tagged natural=wetland. Add name=* as appropriate. Closed ways (plus other things, with other tags) do overlap (these two seem they should not). Let renderers deal with such issues. Different than natural=* tagging, there is also a proposal that includes an "unadorned" boundary=protected_area tag (on a closed way or a relation), without a protect_class tag (one is not known or is "less known"). This might, someday, render as a simple green line. This conveys what is (an often legal) boundary, so it isn't natural=*. See if this proposal (https://wiki.osm.org/wiki/Proposed_features/Park_boundary) helps wrap your logic (and OSM's syntax, a boundary=protected_area tag, or its semantics, a perhaps-someday-drawn rendered green line) around this. Untangling natural, leisure and boundary tagging is ahead in OSM, things do get better. How (the Carto, for example) renderers draw natural=* on top of one another is actually a rich topic: it can be said these behaviors are renderer specific. (Yes, Carto "drawing order" is not necessarily perfectly defined). These are complex topics, getting better as proposals gain approval (a working strateg
Re: [Tagging] How to put a name tag on an area with more than one type?
It was just an example. Peak is "close enough" for now, and you can argue that it works for both mountain and individual peaks. That would be okay, but the problem with that is that there is no information for the renderer which peaks that should be shown when zoomed out. Some renderers just filter out the highest peak (I think opentopomap does that), which does work in say 80% of the cases, but sometimes the highest peak has a specific name, and the whole mountain is named something else. It's frustrating to see that many OSM folks seems to be "surprised" about these things, like it would be something super unique maybe only existing in Sweden. It's not. It's just basic cartography of natural features all over the world. I was for a while surprised that there's not more urgency to fix these type of issues, but once I've learnt about how the community works, I'm no longer as surprised, but it's still frustrating. I'm not going to make a wiki entry. I'm just a mapping contributor within the current framework, not an OSM developer, and I don't intend to become one. I've done my due diligence of OSM and concluded that its more about politics than about solving technical problems, and those things leads to me burning out. What I can do is contribute to the map. And I do. I'm a quite advanced mapper, including writing my own custom software tools to be able to map faster (not automated mapping, but aided manual mapping). When I stumble across things that I don't know how to map, I ask questions at OSM Help, and if the answer is not satisfactory there, I turn to here. I'm now actively involved in the small Swedish OSM community and we discuss how to best map things within the existing OSM feature set, and I try to come up with reference methods. I've lately been involved in following up vandalism. But my engagement ends there, I don't have the capacity to do more. If the only way to cater mapper's needs is for those individual mappers to navigate and penetrate OSM politics to what it has grown to today, I think we're stuck. I takes a special type of effort and dedication which few people posses, and unfortunately I'm not one of them. You will probably hear some rumbling frustration from my mapping efforts from time to time, but that's it. /Anders On 2020-12-13 01:14, stevea wrote: Anders, I didn't see this until after I sent my reply. I believe this list here is interested in what you call "missing features," as a list. I look at them as challenges of ours or frustrations of yours which can either be explained or solved. You might not like the explanations. For example, if you were to expound upon differences between "mountain" (as Anders, or Sweden understands it) and natural=peak (as OSM understands it), we're listening. You might be prompted to "make a proposal for mountain" or "write a wiki for how your first mountain=whatever or whatever=mountain tag you recently started to enter (because it is well thought-out, defined, follows sensible rules about 'what it is' and 'how it is tagged'...)" is now extant, and so on. To solve such frustrations doesn't necessarily include this or that about mountaineering. This is called reducing the map consumer's perspective, as you simply "tag well and accurately using a syntax expressing what you mean." If there is no such tagging, we might support it (as new tagging and/or a new proposal) and maybe someday it will be rendered. This is (partly) how our map data have grown, it is how our map data continue to grow. SteveA ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to put a name tag on an area with more than one type?
Here's a real example of how this naming scheme ends up looking: https://www.torger.se/anders/downloads/Screenshot_2020-12-13-OpenStreetMap.png I have put the name on each part which is the enduring recommendation I've got. Some parts are multipolygons, some are just closed ways, as required. I also added a relation on top. I've got advice against that as no renderer will ever care, but I found that when editing it's hard to keep track of all parts big and small if there is no relation, so I added it as a help for the mapper. I set type=natural (to indicate that it's a natural object) and natural=wetland (to indicate what type of natural it is, without having to deduce from its members) and name on that relation. Nothing official, but at least easy to filter out and find. In Sweden the land cover mapping is heavily behind so I've started a mapping effort for natural areas and there are a bunch of naming problems to solve for which there is no documented way to do. So I do these reference areas and try to come up with the best methods (=least bad in some cases) so we in the local Swedish OSM community have something to refer to when new mappers want to help out and stumble into the same issues. As seen on the screenshot, the result in OSM-Carto looks pretty horrible, and to my knowledge it will be as horrible in any other renderer out there as the feature of naming "complex" nature just don't exist. It's the usual problem: mappers won't map things that don't show up on any renderer (or displays horribly like this), and renderers won't implement functions for things that aren't mapped. The OSM way is that mappers should take the lead and renderers will eventually follow (maybe). I think that process works really poorly today (the main reason being that OSM is just too large and diverse now for the original processes to work, in global scope every feature becomes just a tiny special interest not worth considering). That we still lack these cartography features 14 years into the project is witness to that. We need a render engine to take the lead, and more well-defined standard of how to arrange the data. I've got 4 - 5 different suggestions of how to put a name on this wetland. Imagine if all those naming schemes gets used, what a mess to implement a renderer... /Anders On 2020-12-13 00:55, stevea wrote: I don't approach this as getting solved in one multipolygon. I might use two multipolygons, one tagged wetland=bog, another tagged wetland=marsh, both tagged natural=wetland. Add name=* as appropriate. Closed ways (plus other things, with other tags) do overlap (these two seem they should not). Let renderers deal with such issues. Different than natural=* tagging, there is also a proposal that includes an "unadorned" boundary=protected_area tag (on a closed way or a relation), without a protect_class tag (one is not known or is "less known"). This might, someday, render as a simple green line. This conveys what is (an often legal) boundary, so it isn't natural=*. See if this proposal (https://wiki.osm.org/wiki/Proposed_features/Park_boundary) helps wrap your logic (and OSM's syntax, a boundary=protected_area tag, or its semantics, a perhaps-someday-drawn rendered green line) around this. Untangling natural, leisure and boundary tagging is ahead in OSM, things do get better. How (the Carto, for example) renderers draw natural=* on top of one another is actually a rich topic: it can be said these behaviors are renderer specific. (Yes, Carto "drawing order" is not necessarily perfectly defined). These are complex topics, getting better as proposals gain approval (a working strategy so far). The example of natural=* tagging below is a topic of some confusion among mappers. For example, I don't believe Carto rendering is perfectly predictable without first knowing "size of all overlapping polygons." This can make "accurate" (or pleasing) natural tagging challenging or unpredictable in some circumstances. I believe at least some of what is rendered has to do with the size (and order entered?) of overlapping polygons. In short, I "tag the data I know" at the complexity I'm comfortable tagging them, as accurately as I know how, using OSM's wiki to describe tagging. Multipolygons differ from relations like them which aren't (like those tagged boundary=*), independently as far as renderers are concerned. It is easy to get confused, confusion exists in the map: semantics are blurry in some cases. This gets better with worldwide consensus, over years. This (how we learn to best tag and render) is an ongoing long-term OSM process. As a mapper, "tag accurately first," then let renderers interpret. SteveA On Dec 11, 2020, at 11:53 AM, Anders Torger wrote: Unfortunately I don't think that is possible. Multipolygons may only contain ways that have either role as i
Re: [Tagging] How to put a name tag on an area with more than one type?
Thanks. I appriciate that you say that features are actually missing in this context. The usual way things go when I've tried to discuss these issues in various OSM forums is that it's incredibly hard to get to a consensus that there actually even is a problem at all. I get suggestions to map it in some way that either not work at all or has no renderer support by any data user out there, and when I point out that the discussion just goes silent, and I'm probably just considered annoying. If one gets past the first hurdle and actually gets to a consensus that these things cannot be done today, the next hurdle is "do we want to support this?". Also here I tend to get stuck in meta-discussions about how hard these features are to render quickly on a map or difficult it is to store in the database or show it in the tools, without anyone voicing any opinion for or against the desire to actually have this feature, just seemingly trying to kill it with arguments that it's just too hard to implement. OSM-folks often say that OSM should support not only mapping of streets as the name implies, but also nature. But when I point at specifics required to actually do this in a good way, I find myself stuck. This wetland question was sort of put to an end with a reply "just name all parts the same". It does work for my particular use case, but as you point out it's far from a generic concept, and unlikely that it will be taken up by renderers as relation is missing. Wetlands do generally have sharp borders (although in the national park I'm mapping some of the wetlands are so large that they have different names in different places). When it comes to peninsulas, valleys, mountains, broad ridges, hills, slopes and more natural features we have names for, not so much. Personally I'm okay with just drawing an area on top, everyone understands that it's fuzzy. Just like we can do today with bays and straits. But as discussed in another post, there's overwhelming criticism from leading OSM profiles against having fuzzy areas in the main database so it's unlikely to happen. And as long as no widespread renderer actually uses the data and there's no wiki info on how to name these things there's no chance for this to catch on by regular mappers actually taking their time to put in the names. Mountains are in OSM usually mapped as a point, a peak. However, mountaineering was not an interest among those that actually named the mouintains, so often what has a name is the mountain, not the peak itself. But as OSM doesn't support naming mountains, there's lot of misleading naming out there. Today I had a mountain to name, it has three peaks, but only one name, and the name is on the mountain not the peak. The list goes on. For anyone knowledgeable in cartography missing features like this are easily identified. Sure we can choose to have a map that doesn't support them (and say that we only intend to support zoomed in urban contexts, I guess that's where the money is anyway), but it's not odd features in any way, any institutionally made map have them. /Anders On 2020-12-12 13:55, Martin Koppenhoefer wrote: sent from a phone On 12. Dec 2020, at 12:26, Anders Torger wrote: In the wetland case as described, there is no parent relation at all. The only thing that ties them together is implicitly by sharing borders and having the same name tag. It seems to me that an "official" way to edit should tie them together with a parent relation. Yes, we do not have a way to map toponyms for larger areas when we also want to map detailed landcover within. Christoph’s idea of using the same names on the parts fails when the individual parts have different names. We can’t map bigger geographic entities like deserts, swamplands, forests, highlands (besides the names for the smallest parts, or if they correspond to other entities with clear boundaries like nature reserves, or maybe by overlapping the same kind of objects, what is generally frowned upon) The logical way would be a parent relation with type=wetland (and actually have the name only there, but no renderer today understands that, it needs to be on the separate parts as well). What should the roles be? The most logical way would be to leave role field empty. Maybe a similar approach as the one for relations of type=group (i.e. a relation type which explicitly “inherits” its meaning from the members without the requirement but with the possibility for additional tags, a place to put a name for the ensemble) could be taken for area relations as well, e.g. the site relation could include the different wetlands, and a name (and e.g. wikipedia/wikidata reference, etc.) might be sufficient to map the “collective” of things? The nature would be implied by its members. The bigger such geographic entities become, the less you will typically be able to draw a hard line (fuzzyness of many
Re: [Tagging] How to put a name tag on an area with more than one type?
Indeed, place=locality seems to be a dead end, it's been misused quite much and there's talks about removing it from OSM-Carto, and you can't render good maps from it, so it's technically a poor concept as well. To render names properly for natural features the renderer needs to know the extent of the area, so when you zoom out it can sort and show labels at appropriate size (and advanced renderers can even bend and shape the names according to the containing area), just like it has always worked with lakes. Another way would be to make tags like we have for populated places, hamlet, villages, etc where the name tag type decides its prominence. This makes sense for populated areas as the area size is not what decides its prominence but rather the population size. However for natural features I think the area concept is elegant, and also gives much more information than just having a tag, as for natural features it's not always obvious (like a city) where the feature roughly starts and ends, or even what it is. For natural features it's also common in cartography to shape the text according to the shape of the feature (there are a few examples of renderers doing this already with OSM lakes, like opentopomap.org), and having an area gives the renderer great information to work with. So I think named areas is the way to go for natural features. Named areas on land, like the peninsula tag that exists today, makes the map data a bit crowded in the editor when you show all elements at once. I think it would work well enough as you just can filter them out in JOSM when editing other stuff, but the concept of named areas has got heavy criticism from leading OSM people so it seems to be impossible to get consensus for this in the main database. Peninsula and also the valley tags are ineffective due to this. Refusal to support/promote the feature in OSM hasn't meant that the names have disappeared from the real world though, so the need is still very much there. There just seems to be no way forward with the main database. So the only viable option indeed seems to put these things in a separate database. Although I think it would be preferable to have this type of basic feature represented in the main database, I'm for anything that works. However, how many mappers is willing to contribute to an extra database if there's no showcase of it actually being used in a map as accessible as osm.org? Wouldn't this database just fade away, just like so many OSM-related projects before it? I think that today map renderers has to lead the way showcasing great cartography, then mappers will follow. The other way around no longer works, the scope is just too big. As a mapper, I don't want to invent methods for basic mapping, I just want to go to a website and read how it should be done, do my mapping, and then see the result on a map freely accessible to anyone all over the world. To me that's the attraction of OSM and being a contributor. With a global scope of the map it's incredibly hard as in an individual mapper to start a geodata trend that grows and gets so big that some relevant render implementor actually starts using the data and show it on their maps. Would it be possible to get a global map renderer tied to the project so the database is actually used? I think it will be next to impossible to grow the database with voluntary contributions if there is no map showing it in active use. /Anders On 2020-12-12 14:03, Martin Koppenhoefer wrote: of course all of these could be tagged as place=locality nodes, but this is a compromise to drop a name, which does not allow to even guess about the extent, shape or orientation. My idea is to collectively curate a parallel dataset which can be used in addition. Just draw the thing roughly (thinking mainly about regional size features, not the very detailed OpenStreetMap editing map scale), e.g. here geojson.io and send it to me for inclusion ;-) https://github.com/dieterdreist/OpenGeographyRegions ideally you would also search the fitting wikidata object (the hope is to internationalize names through wikidata items). Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to put a name tag on an area with more than one type?
To make it clearer, here's a screenshot of the result of a test using this method: https://www.torger.se/anders/downloads/Screenshot_2020-12-12.png OSM-Carto makes one name tag per sub-part instead of just one for the whole which is both undesired and ugly, but I've come to understand that OSM-Carto is not really for making good cartography but for a debugging view where low computational overhead is prioritized over good cartography. I think that design choice is unfortunate, but not something I can do anything about, it is what it is. We hope that "someone else" does the cartography bit. It does become a bit confusing though when the naming method looks incorrect on the de-facto reference map that OSM-Carto has become, especially when this naming method is not documented anywhere. So it seems unlikely that "someone else" will actually make the rendering correct if there is no documented way of how the data is organized in these naming situations. The OSM way seems to be to let individual mappers make their own tagging to solve the problems they have. This ends up with a fragmented situation of diverse methods where none is big enough to catch on, and most mappers just choose the easy way out and just simplify the map so the simplest already established methods can be used. The easy way out for me here would be just to ignore that the wetlands are both bog and marsh and just make everything bog: problem solved by lowering geodata quality. And I think this is what many mappers do, it's very unsatisfying to map things that doesn't show up properly on any renderer one can find in use. But this time I'll try to be a good OSM citizen and take the lead in tagging if necessary. I just need to know that the method I choose is the best so it at least have some chance of survival so that my work doesn't go to waste. There are more challenges coming up so more questions will probably land on this list. /Anders On 2020-12-12 12:23, Anders Torger wrote: Sorry, I realize I have a followup question. Is this really the right way? There's a difference from the Rhine example. With rivers all the separate parts are tied together with a parent relation of the type waterway, and the parts have roles like "main_stream". In the wetland case as described, there is no parent relation at all. The only thing that ties them together is implicitly by sharing borders and having the same name tag. It seems to me that an "official" way to edit should tie them together with a parent relation. The logical way would be a parent relation with type=wetland (and actually have the name only there, but no renderer today understands that, it needs to be on the separate parts as well). What should the roles be? The most logical way would be to leave role field empty. To summarize: Suggested method of how to name a wetland that has more than one sub-type: * Prerequisite: each sub-type (marsh, bog etc) is a polygon (or multipolygon if required, for example if there's an inner water or forest) which shares segments with the neighboring sub-type, ie the wetland is a single entity. * Put the name on each part, same for all * Create a relation with type=wetland (no sub-type) and include all parts with role field empty, also name this relation with the same name (although no current renderer will care) What do you think about this way? JOSM thinks it's fine at least, I get no warnings :-). (Note that there's another case that can be solved with just a single multipolygon, when there's a single sub-type but the parts are separated, so each part can be an outer, this is also (quite) common, although more common for waters and islands than wetlands. The special thing with the discussed case is that it's a single entity all parts bordering to the next) On 2020-12-11 20:55, Anders Torger wrote: Thanks I'll do it this way then, this actually works and even gets rendered, although with OSM-Carto it becomes a name tag in each separate part so not exactly beautiful, but the data is there. /Anders On 2020-12-11 18:07, Christoph Hormann wrote: Anders Torger hat am 11.12.2020 17:07 geschrieben: The least bad way I've come up with is to just name all polygons belonging to the same wetlands the same, That is widely considered to be the correct way. It is established practice that mapping things like forest, wetland, farmland etc. can be split to differentiate tagging (like leaf_type, wetland type, crop etc.). The name tag is then applied to all components. Same as for waterways or roads where you can also split and apply the name to the components. This also matches the general concept in OSM that names are typically local properties and only locally verifiable. The Rhine river is called Rhein in Koblenz but Rhin in Strasbourg and Rijn in Rotterdam. ___ Tagging mailing list Tagging@openstreetmap.org https://
Re: [Tagging] How to put a name tag on an area with more than one type?
So your advice is to actually skip the parent relation object, and thus leave the parts separate and related implicitly just by shared borders and having the same name? Ok, fine by me. I certainly agree with you that data users probably won't turn complex patterns into something meaningful, as there is no real standard documentation of how to map things, just a wiki of soft and incomplete "advice", and lots of dead-end methods that never catched on. I rather avoid wasting time on using/inventing yet another of those dead-end methods. I think a better way would be a well-documented OSM-standard where the standards organization on itself figure out needs and take the lead rather than anonymous individual mappers like myself must invent own methods for needs that are really quite basic. But that just won't happen, so I know that I'm probably just wasting my time mapping at this detail level. But the OSM way is to let mappers take the lead and renderers (maybe) come after, I think it's a very BAD way now when OSM is as large as it is, but it's the way it is, so I'm in a take it or leave it situation. I enjoy mapping and OSM is the only free alternative there is. On 2020-12-12 12:43, Christoph Hormann wrote: My strong advise is not to make this more complicated than it is and especially not cargo cult some complex data model in the hope that data users will turn this into something meaningful - they won't. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to put a name tag on an area with more than one type?
Sorry, I realize I have a followup question. Is this really the right way? There's a difference from the Rhine example. With rivers all the separate parts are tied together with a parent relation of the type waterway, and the parts have roles like "main_stream". In the wetland case as described, there is no parent relation at all. The only thing that ties them together is implicitly by sharing borders and having the same name tag. It seems to me that an "official" way to edit should tie them together with a parent relation. The logical way would be a parent relation with type=wetland (and actually have the name only there, but no renderer today understands that, it needs to be on the separate parts as well). What should the roles be? The most logical way would be to leave role field empty. To summarize: Suggested method of how to name a wetland that has more than one sub-type: * Prerequisite: each sub-type (marsh, bog etc) is a polygon (or multipolygon if required, for example if there's an inner water or forest) which shares segments with the neighboring sub-type, ie the wetland is a single entity. * Put the name on each part, same for all * Create a relation with type=wetland (no sub-type) and include all parts with role field empty, also name this relation with the same name (although no current renderer will care) What do you think about this way? JOSM thinks it's fine at least, I get no warnings :-). (Note that there's another case that can be solved with just a single multipolygon, when there's a single sub-type but the parts are separated, so each part can be an outer, this is also (quite) common, although more common for waters and islands than wetlands. The special thing with the discussed case is that it's a single entity all parts bordering to the next) On 2020-12-11 20:55, Anders Torger wrote: Thanks I'll do it this way then, this actually works and even gets rendered, although with OSM-Carto it becomes a name tag in each separate part so not exactly beautiful, but the data is there. /Anders On 2020-12-11 18:07, Christoph Hormann wrote: Anders Torger hat am 11.12.2020 17:07 geschrieben: The least bad way I've come up with is to just name all polygons belonging to the same wetlands the same, That is widely considered to be the correct way. It is established practice that mapping things like forest, wetland, farmland etc. can be split to differentiate tagging (like leaf_type, wetland type, crop etc.). The name tag is then applied to all components. Same as for waterways or roads where you can also split and apply the name to the components. This also matches the general concept in OSM that names are typically local properties and only locally verifiable. The Rhine river is called Rhein in Koblenz but Rhin in Strasbourg and Rijn in Rotterdam. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to put a name tag on an area with more than one type?
Thanks I'll do it this way then, this actually works and even gets rendered, although with OSM-Carto it becomes a name tag in each separate part so not exactly beautiful, but the data is there. /Anders On 2020-12-11 18:07, Christoph Hormann wrote: Anders Torger hat am 11.12.2020 17:07 geschrieben: The least bad way I've come up with is to just name all polygons belonging to the same wetlands the same, That is widely considered to be the correct way. It is established practice that mapping things like forest, wetland, farmland etc. can be split to differentiate tagging (like leaf_type, wetland type, crop etc.). The name tag is then applied to all components. Same as for waterways or roads where you can also split and apply the name to the components. This also matches the general concept in OSM that names are typically local properties and only locally verifiable. The Rhine river is called Rhein in Koblenz but Rhin in Strasbourg and Rijn in Rotterdam. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to put a name tag on an area with more than one type?
Unfortunately I don't think that is possible. Multipolygons may only contain ways that have either role as inner or as outer. It may not contain other relations (still possible to upload, but not considered right according to the wiki). What should the ways be? We can't make the separate wetland parts as inner ways, (as areas formed by the inner ways are subtracted from the multipolygon), and even if we try it becomes illegal as inner ways cannot share segments with the outer way. We can't make the parts as outers either as they share segments. The outer must be the surrounding outline without the shared segments splitting the wetland in parts, and there are no inners (unless the parts themselves has inners). So then we have a multipolygon with just an outer. I could just as well be a plain polygon made from a single closed way. This would work if drawing order was defined, and that was the method I tried first. The container polygon must have a natural tag as well (the logical would be wetland here without further sub-classification). However the drawing order is not defined (I think, not 100% sure), so this is by the renderer interpreted as a wetland lying on top of the other wetlands. OSM-Carto will still render the insides, but the fill pattern of the outer polygon is drawn on top. On 2020-12-11 18:09, Brian M. Sperlongano wrote: Hello Anders, I would recommend creating a multipolygon relation (type=multipolygon) with each of the wetland pieces, and set the name= and appropriate natural= and wetland= tags on the relation. On Fri, Dec 11, 2020, 11:11 AM Anders Torger wrote: Hello, I was on this list a while back expressing some frustration over limitations when tagging nature and thought about getting involved in a process for change, but I came to realize that it's not feasible for me in my current life situation, so I've decided to continue be a normal mapper as before, doing what I can do with features that exist today. Anyway, if to be a mapper at all, I still like to solve some of my naming issues in the best/least bad ways possible today. I'm currently mapping a national park in Sweden, Muddus. It's in Laponia and consists of mighty wetlands and old forest. These wetlands are named, like is common in Sweden and Sami lands. For us navigating in wildlife, names in nature are important. A wetland polygon can be named in OSM, so the situation is better than for example for named slopes (also common). However, a wetland here can consist of both bog and marsh (and it's important to make the difference, since one is easy to walk on, the other not so much). That's two different natural types and thus can't be in the same multipolygon (as outers). Asking on OSM Help website for a solution I got the answer to make a new containing multipolygon and set the name on that. That would be quite elegant for sure, but JOSM warns about that, can't have a name without a type, and if I set the type, say natural=wetland without any subtype, I get a JOSM warning that I have natural features on top of eachother. If I still upload it OSM-Carto does render out the name but you can see that the wetland pattern of the outer polygon is drawn on top of the contained polygons, so it does not seem to be the way to do it. The least bad way I've come up with is to just name all polygons belonging to the same wetlands the same, and hope for that in the future smart renderers will understand that polygons with shared borders and shared name is the same named entity. Any ideas or suggestions? /Anders ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] How to put a name tag on an area with more than one type?
Hello, I was on this list a while back expressing some frustration over limitations when tagging nature and thought about getting involved in a process for change, but I came to realize that it's not feasible for me in my current life situation, so I've decided to continue be a normal mapper as before, doing what I can do with features that exist today. Anyway, if to be a mapper at all, I still like to solve some of my naming issues in the best/least bad ways possible today. I'm currently mapping a national park in Sweden, Muddus. It's in Laponia and consists of mighty wetlands and old forest. These wetlands are named, like is common in Sweden and Sami lands. For us navigating in wildlife, names in nature are important. A wetland polygon can be named in OSM, so the situation is better than for example for named slopes (also common). However, a wetland here can consist of both bog and marsh (and it's important to make the difference, since one is easy to walk on, the other not so much). That's two different natural types and thus can't be in the same multipolygon (as outers). Asking on OSM Help website for a solution I got the answer to make a new containing multipolygon and set the name on that. That would be quite elegant for sure, but JOSM warns about that, can't have a name without a type, and if I set the type, say natural=wetland without any subtype, I get a JOSM warning that I have natural features on top of eachother. If I still upload it OSM-Carto does render out the name but you can see that the wetland pattern of the outer polygon is drawn on top of the contained polygons, so it does not seem to be the way to do it. The least bad way I've come up with is to just name all polygons belonging to the same wetlands the same, and hope for that in the future smart renderers will understand that polygons with shared borders and shared name is the same named entity. Any ideas or suggestions? /Anders ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Basic cartography features missing, why?
A question, is this database only intended for very large polygons, or also rather small? From my mapping perspective here in Sweden fuzzy polygons exist down to say ~1 km size (generally speaking names of hills, valleys, peninsulas etc). In fact the most I run into is in the 2 - 10 km size. I also come across many bays and straits of similar sizes, those can be defined (and rendered) in OSM already today, but I now understand that many don't like that they exist, so maybe those should be managed in this type of separate database too? On 2020-11-09 10:08, Martin Koppenhoefer wrote: Am Mo., 9. Nov. 2020 um 09:37 Uhr schrieb Mateusz Konieczny via Tagging : In short: technically CC0 may be used, but it would be confusing as ODBL would still apply anyway. See https://wiki.osmfoundation.org/wiki/Licence/Licence_Compatibility#CC0 "CC0 licenced material is in general compatible, however the license only extends to material the licensor actually has rights in and specifically avoids making a statement on the status of any third party material included." So you could license this as CC0, but it does not mean that other limitations are not applying (limited extraction of just some shapes from OpenStreetMap may be doable without triggering ODBL - see https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Substantial_-_Guideline but such project would likely quickly pass it). For the avoidance of doubt, there is currently no data from OpenStreetMap in OpenGeographyRegions, and there will not be in the future, so that the data can be used without limitations. My intention is using it together with OSM data, but of course you can use it with whichever data you want. These regions, although it would be legally possible, should not be imported in OSM either, because they are in medium and large scale resolution and not suitable by their nature (not well defined on small scales, fuzzy boundaries, etc.). Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Basic cartography features missing, why?
om guy making a due diligence of the OSM project from a Swedish casual mapper perspective: ** Strive for more professionalization in certain areas, not necessarily permanent but run in time-limited projects ** Task force for imports, targeting weak areas ** Make import into separate layer, use the crowd of casual mappers to do merging with existing work ** Prioritize imports to reach a decent baseline, potential casual mappers are discouraged if they have basically a blank sheet to start with, especially if they live in an area where other high quality maps are easily accessible. ** Cartographic expert group, analyze current situation make action plan to fill in the gaps ** Strive to have clearer mapping guidelines, maybe have a professionalized short project to shape up the wiki guidelines. Instead of "nothing right or wrong, some renderers do like this, others like that" have stricter and more well-defined mapping guidelines and give OSM-Carto the status of reference implementation for the basic feature set rather than just an example implementation. This does not need to apply to exotic and experimental features, but basic things like, can we have polygons split with arbitrary seams or not (quite common practice, but also quite common that renderers make these seams visible). ** Allow the OSMF board to make more strategic decisions, or in some other way get a roadmap ** Decide which features to prioritize ** Avoid too much fragemented work when several people do the same things but none just don't catch on as it hasn't been anchored in the community first ** Strive to make the database (or tools) organized in layers ** Easier to work with as data gets dense, less problematic to introduce new types of mapping ** Separate osm.org in one for mappers and one for end users, make the end user site more modern and more fashionable, think about "selling" the project and market communication. ** We need casual mappers, lots of them, not everyone can be OSM champions. We need to think about "selling" to casual mappers, make it easy, attractive and encouraging to contribute. ** Presenting a good attractive map for end users is the best way to attract mappers ** Have a page on osm.org which tells about the project what it does how it works etc. ** Prioritize cartography over speed in rendering ** Give better generalization of names high priority, better overview maps ** The default map should have contour lines, a "simple" way to make the map look much more complete ** Import task force can look for country imports of height data, some countries have public data available at a considerable better quality than the common global source. ** Try to secure funding for server infrastructure and maintenance so the capacity is there to serve the demand ** Find a way so we don't need to be too afraid to compete with the commercial providers ** It's important for OSM success that there to the casual public is one solid high quality entity, today it's too fragmented On 2020-11-08 23:00, stevea wrote: On Nov 8, 2020, at 7:58 AM, Anders Torger wrote: I believe the processes available are limited in terms of fixing structural problems. You say you have long experience in open projects, that is a fantastic launchpad from which to join OSM and improve it, even criticize it. I read that you (here, now) begin to identify what some of these "structural problems" actually are, but your major criticism seems to be that "processes available are limited" (I disagree), while my response has been that I agree with you that improvements in OSM take a (relatively) long time to fix. Being consensus-based, OSM makes no apologies that major structural improvements take a (relatively) long time to fix, but major improvements usually DO take a long time to fix, regardless of organizational structure. To wit, even if OSM were run by a single autocratic despot, major structural improvements would still take a relatively long time to fix. This means "the processes available" being limited as specious (plausible, but wrong), as there is vast creativity on tap that OSM applies to solving problems: this is another example of the power of crowdsourcing being unleashed performing powerfully. Crowdsourcing doesn't apply simply to a bit of mapping here, a bit of mapping there adding up (though, that is true), it also applies to processes, code improvements / bug fixes, structural betterment, better wiki documentation, better tools and (over time), the voting in of better qualified board memberships which contribute sharper and better-applied skills to problems that need solving and improvements that need doing. Sometimes there is "a step backward with two steps forward," but that is true in any organization. OSM doesn'
Re: [Tagging] Basic cartography features missing, why?
myself are struck with frustration when they see these limitations. But I do understand, I come across as "complain complain complain, disrespect, baseless accusations, bla bla bla, I won't do anything myself except complaining". And well, I can see that as fair criticism of my thread :-/. I do feel a bit bad about not having the hours to back it up "to say I'll fix it myself, I'll start a community in Sweden, I'll handle those imports, I'll work and make generalization algorithm (in parallel to Tomas I suppose)". But I just don't have that capacity, and the alternative would be to just shut up and continue not knowing what's going on, so I chose to stir in the pot a little bit. But I'm a nice guy and I don't mean any harm :-). I truly want OSM to succeed globally *including* Sweden, *and* have great cartography as we expect here, but I just can't do it on my own. /Anders On 2020-11-08 15:09, stevea wrote: Warning: lengthy reply to an already-lengthy thread. On Nov 8, 2020, at 3:26 AM, Anders Torger wrote: Regarding a board that makes strategic decisions. The current concensus model with huge community has lead to that it's very easy to block an idea, and very hard to get it accepted and realized. Anders, here, we disagree. If you have a GOOD idea in OSM, you may implement it rather directly. If it is truly "good," the community will adopt it with enthusiasm. Sometimes there are misunderstandings by some (even at the top-most levels of the project, like the DWG), though for the most part, these are remedied with time. Sometimes people choose not to "be bold" (rather simply implementing something like a tag "in the wild") but rather go the route of proposals, voting and slower, more widely and immediately acceptable community acceptance, providing the vote goes to Approved. I have had experience with all of these: good ideas which were widely not well-understood (at first), even by DWG members, yet they are now well established and well run sub-projects within OSM, as well as poor ideas which didn't go anywhere at all because few or no community members support them. Presenting good ideas well takes effort, yes, but it isn't correct to characterize this as "very hard." Maybe for someone who has little or no experience in presenting an idea, communicating it well and having others accept this it might be "hard," (not "very hard"), but this is a life skill, not one limited to a worldwide, open project. It isn't (usually) the fault of a project (or institution) when good ideas well-presented to it get "blocked," much more often it is the idea or its presentation. If OSM truly has a "block" on accepting good ideas well-presented to it, we must fix this. But I don't believe this is true, nor do I believe this is widespread in OSM. If you have evidence otherwise, please present it. A good idea is often blocked just because the first suggested solution may not be the best. It's rare to see, "it's a good idea, but maybe we could implement it like this instead?", but it's rather "your idea for implementation is bad because xyz, end of discussion". Many of those that has ideas are casual laymen, like myself, and we don't have the ability to run these processes, and may not have the knowledge to come up with the best way to implement it. It's very hard to get a grasp of what's needed and what people actually think in general, it's more about shouting the loudest. With a larger database in more complex use cases it's also become much more technically difficult to make changes, so the people which actually can on their own design a technical solution is extremely rare. Again, I disagree it is about "shouting the loudest." While it may seem that the consensus process is more like dissonant cacophony, we largely remain civil while sifting out the wheat from the chaff (good ideas, like cream, DO tend to "rise to the top") and any "shouting" or disagreement is mostly a bit of heat on the way to achieving light. It can be messy, it isn't perfect, but building consensus isn't what is wrong with OSM, it is an important part of what is right. Speaking for myself, I don't want some "star chamber" (secretive cabal on high) to be developing the future of OSM. I want me, my fellow OSM volunteers, you and others to do so: this is called "organic grass-roots growth." As individuals, we all have strengths that allow us to contribute, these sorts of things tend to work themselves out with the usual "we need some help here, does anybody have the required expertise" and "I see a problem I might be able to solve like this, as I DO have some expertise in the specific realm..." so, you fix it, maybe with others, maybe by yourself. We don't really have "cabals on high" in this project, although we do hav
Re: [Tagging] Basic cartography features missing, why?
From a tool point of view (JOSM etc), multiple databases could be made to be experienced exactly the same as different layers, so I guess it doesn't matter that much. With layers you are supposed to be able to turn them on and off at will in your editor and choose which you see in an easy way, so such problems could be easily spotted and fixed anyway. You could also have automatic checkers for layer overlaps. Those issues could be managed, and I think the advantages of a layered design clearly outweigh the disadvantages, especially when we get more and more data density and more and more different types of data. I don't really care that much exactly how it's implemented, but a potential risk I see with having separate databases, perhaps maintained by some other entity, rather than readily integrated in the main database is that it will get stuck as a niche feature not used by OSM-Carto or any of the big providers. On 2020-11-08 13:41, Tomas Straupis wrote: 2020-11-08, sk, 12:31 Anders Torger rašė: To me it seems like an odd "political" design decision to have a separate database though. Why just not arrange the database in layers, and this could be a separate layer? From a technical perspective I suppose it wouldn't have to be layers as such, one layer could in actuality be a tag filter. It must be separate enough to: * not allow reusing objects from "main" database * to have different description on what is allowed in it (for example allowing objects borders of which cannot be precisely defined etc.) In general it is an advantage that the main database does not have layers. In "standard GIS" layers separate data thus we can get bus stops in the lake or on the building, road going into the lake etc. In OSM it is much easier to spot such problems (and fix them) because it is only one layer. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Basic cartography features missing, why?
opular in Sweden among fitness and outdoor people showing OSM in a rather bad way. That's not helping the widespread view here that OSM is becoming "obsolete". /Anders On 2020-11-08 08:43, Mateusz Konieczny via Tagging wrote: Nov 8, 2020, 05:31 by mach...@gmail.com: I absolutely agree with Seth, OSM should switch to vector tiles ASAP. Note that OSM would not switch to vector tiles. At most one more rendering would switch to vector tiles. For OSM Carto see https://github.com/gravitystorm/openstreetmap-carto/issues/3201 (not sure what is the state and what is the current blocker) (sorry if that is overly pedantic) And there should be several specialized layers: general car navigation map, sport map for hiking/cycling/skiing, transportation. All of that would be possible with vector tiles which are less computationally demanding to create. We already have multiple map styles. Their code is all on github so no need to reinvent the wheel and I think this could be easily modified for OSM purposes. https://github.com/FreemapSlovakia Is there somewhere description/summary of their software stack? If there is nobody who can or is willing to do it then let's hire someone who can. Or let a company like Mapbox do it. If someone, anyone is willing to sponsor hosting they can propose to add their tiles to OSM main site (see https://wiki.openstreetmap.org/wiki/Featured_tile_layers/Guidelines_for_new_tile_layers ) Though as business of Mapbox is to offer paid hosting of OSM data it is dubious that they would put special effort into competing with themself. Even free tier of their products requires giving credit card details. I would be willing to do regular monthly donations for someone's salary if that makes OSM better and more attractive. I am not sure how one may donate for specific target of vector tiles (it is also not mentioned at https://wiki.openstreetmap.org/wiki/Donations ). donati...@openstreetmap.org is appearing on the page, maybe asking there is there such possibility would be useful I also fully agree with Anders. OSM needs change. There should be some sort of committee with a clear vision that would enforce a unified style of mapping. While central power may be useful and offer some benefits, it is really poor place for it. Either some agreement can be reached and such committee is not needed or they would make decisions where large part of community disagrees with it. Except cases where this is absolutely needed, such entity would do more damage than benefit. It is absolutely ridiculous that we have features that are mapped in 2 or more different ways simultaneously e.g. riverbanks or sidewalks... Who is supposed to use and rely on such data? Duplicate tags are mildly irritating while processing, but it is not a serious or main problem for data consumers. (and it is from person who put a lot of effort into tagging improvements, wikifiddling, deprecating some unwanted values, deduplication and validator-related work and has some experience from data consumer side) Martin Date: Sat, 7 Nov 2020 08:36:52 -0600 From: Seth Deegan I actually just found that article about OSM's problems. One of the major topics mentioned, the fact that OSM acts as a database and not a map, and that this acts as a hinderance to the expansion and development of the project, is very true. As a result, I've came to think that implementing Vector tiles should be OSM's #1 development priority right now. If people who find OSM realize that there's a lot more data than just the raster images displayed by the standard tile layer, than they will be more likely to contribute and grow the OSM community. We're all here complaining about computational needs required by rendering servers, but there are some great vector tile implementations that require way less computational needs. Moral of the story: We need Vector tiles. El El sáb, nov. 7, 2020 a la(s) 05:24, Anders Torger escribió: This is great information, I didn't know about your project, very very interesting. I have recently come to understand the OSM-Carto technical challenges recently. I haven't given it much of a thought as a casual mapper for the past two years, just been a bit disappointed with how it looks. I am a programmer in profession though so when taking a deeper look and though about it I see these challenges. However, and this is a big however, I think that the face of openstreetmap really need to be a cartographic sound map. It's not right that a style seemingly designed mainly for speedy diagnosis should be the face of OSM. How many of our mappers are so technical that they understand this? And howcome did I not even know about this cartographic project of yours? If there are great styles out there but noone knows about them that's a problem. And even if we let the not-so-good-cartography be the first map we see on openstreetmap.org [1] (which m
Re: [Tagging] Basic cartography features missing, why?
Beautiful name label rendering! Regarding separate database, I think it's a good idea if that is the only way forward. Something needs to happen. Being able to fulfill basic cartography needs are not "new" ideas, I really believe that it should be a priority for a database used for generating maps so it's sad to see that it's being blocked. This is also a space which seems to be were we can have an edge when more and more maps are moving into vector. I see that many providers actually go backwards in cartography when moving to vector (due to worse name label management), but we could instead go forward, and topo.openmap.lt is an inspiring example. To me it seems like an odd "political" design decision to have a separate database though. Why just not arrange the database in layers, and this could be a separate layer? From a technical perspective I suppose it wouldn't have to be layers as such, one layer could in actuality be a tag filter. That we get stuck on arguments about cluttering the database with "unmaintainable polygons" I see simply as a database management problem. What if we in the future want to have specialty maps like say bedrock maps? Of course putting those polygons all over the others in the same database will be a mess. Already the data is slow to manage and edit for my lowly machine in dense areas as one get all layers at once even if one only wants to work on say coastlines. Once imported to JOSM I can work with filters, so it's manageable, but I think it would be *much* better if layers got to be a more defined feature. I also see that layers could be an advantage for import processes, you could create a separate layer for making a huge import which is not used in rendering, but used by casual mappers during long-term manual merging. (As a side note I also think that OSM needs a professionalized import task force working for a year or so to boost countries with good local public data and bad OSM data, instead of individuals here and there make their best attempts of making an import which can be really technically challenging, which we see the effects in our Swedish map now). On 2020-11-08 06:51, Tomas Straupis wrote: 2020-11-08, sk, 00:00 Anders Torger rašė: Maybe this is self-evident to anyone that knows more about this than I do, but I have to ask, are you saying that when we have to implement generalization to be able to serve vector tiles, it's also natural to include generalization of names? Meaning that we could see more names than we do now when we zoom out, so perhaps rural areas don't get the empty-map-syndrome? That would be awesome. Names do not take too much space in vector tile. I was talking about larger objects like landcover, water, buildings. In addition I still want some method to name features in the landscape though, that supports automatic generalization. I thought named areas was an elegant way to do this, but it seems some have very strong opinions against it. If we're talking about fuzzy features (which do not have specific boundaries) like mountain ranges, bays, straits etc. the problem is that just a point is not enough, text must have direction, sometimes even curvature to follow the geometry of the object ant thus "connect" the label with the object in our consciousness. Additionally, for some objects, say bays, we need totally different set of labels for different zooms and that can only be calculated if we have a polygon (check water labels and how they change https://topo.openmap.lt/#t/13/54.33547/24.36494/0/0/ starting with zoom 16 there is actually a lot of labels placed in different places of the waterbody). But placing polygons for fuzzy objects have problems: * borders are not verifiable on the ground (as there is actually no border - object is "fuzzy") * imprecisely drawn boundaries of such objects look bad in the editor, intersect with other objects and this kind of pushes mappers to simply use boundaries of existing features (like coastlines) which makes those object waay too precise for fuzzy objects. My personal opinion is that such objects could be moved to a separate database specific to fuzzy objects. That database should not have ANY connection to the main database so that mappers would not be able to reuse geometries of the main database. Thus license would be the same, toolchain would be the same, data could later be used alongside the data from the "main" database. Everyone should be happy, both arguments (Christophs and Frederiks) against such objects would be satisfied? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Basic cartography features missing, why?
I'm don't know that much cartography terms and techniques, I only know what I know from using maps. I have noted though that traditional maps simplify the geographic shapes depending on scale. Sometimes in interesting ways, instead of removing small islands they are sometimes drawn bigger instead. It's actually quite elegant as it makes the map pack more information. It's probably not the right thing to do for an automatic generalization though, as it would be impossible to know which islands that has importance enough to be enlarged and kept rather than just removed. Although OSM-Carto doesn't do any generalization of the shapes when zooming out I think it works quite fine on a computer screen, so I personally don't see it as a problem, but I guess a true cartographer will :-). In any case, when going to vector shapes it will obviously be necessary from technical reasons. Maybe this is self-evident to anyone that knows more about this than I do, but I have to ask, are you saying that when we have to implement generalization to be able to serve vector tiles, it's also natural to include generalization of names? Meaning that we could see more names than we do now when we zoom out, so perhaps rural areas don't get the empty-map-syndrome? That would be awesome. In addition I still want some method to name features in the landscape though, that supports automatic generalization. I thought named areas was an elegant way to do this, but it seems some have very strong opinions against it. Named points of natural features of different sizes would also work (like isolated dwelling < hamlet < village < town) but I don't think it is as elegant and provides less information as one actually can map out an area even if the borders are fuzzy. But, a point with size does the job so I think that is acceptable if one could get consensus on that. Points all with the same prominence which is offered today for some of the features I need to name does not work though as the generalization will then not be representative of the area. On 2020-11-07 20:44, Tomas Straupis wrote: One more thing to consider: generalisation is one of the most important things for cartography, but it is also extremely important for vector tiles. 2-3 years ago we've played with government data and it produced huge (up to 4MB) vector tiles (pbf) for middle scales (zoom 8-12). Browsers (especially mobile ones) were struggling with that amount of data. Even moderate generalisation reduced the amount of data to 0,5M. It is something which is currently brushed under the carpet as using raster will never produce a tile that large. What I'm saying here is that generalisation (the real one, not DP) will have to be done anyways as OSM community is starting to see the disadvantages of legacy raster maps and is getting used to the idea of vector maps (for the client, not between servers). 2020-11-07, št, 21:23 Anders Torger rašė: (I had to run it in Chrome, it didn't render properly in my Firefox, but this vector stuff is new tech and Linux Firefox seems to have some issues with that.) Strange. Firefox on linux is my primary browser, it is the way I always use/test *.openmap.lt... Okay, change that to "Firefox on *my* Linux computer" :-)... it's not the first time it seems like I am having issues with that which no-one else has... hmm... maybe I have been toying too much with the GPU settings. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Basic cartography features missing, why?
Hello Tomas, I just need to comment specifically on your https://topo.openmap.lt -- I'm very impressed! (I had to run it in Chrome, it didn't render properly in my Firefox, but this vector stuff is new tech and Linux Firefox seems to have some issues with that.) /Anders On 2020-11-07 07:52, Tomas Straupis wrote: We're playing around with a small project striving to comply with cartographic rules - topo.openmap.lt - some data is updated daily, generalisation is done weekly. But you already get generalised roads, buildings, smart lines for waterbody labels as well as text size and letter spacing. This should get cartographic simplification for waterways this coming spring (not DP or VW, but Wang-Müller). So this can be done, but OSM-Carto is not the place to do it. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Basic cartography features missing, why?
Yes good point. Actually, I don't even know if cartography makes the top ten list of how OSM data is used. Does it? For me personally cartography is *the* thing, and I guess I am guilty for arguing from my own perspective. Sure I use basic road routing capabilities too that stem from the data, but what makes it satisfactory for me to map more than just basic roads (which I indeed do a lot of) is that I see my data resulting in good looking and useful cartography (which today leaves some basic key things to be desired in my humble opinion). On 2020-11-07 16:50, Mateusz Konieczny via Tagging wrote: Nov 7, 2020, 16:41 by and...@torger.se: And in the end it's about the resulting map. Not only, OSM data is also used in other ways. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Basic cartography features missing, why?
Sorry for replying to myself again, but I realized the link I shared was not a true example, although the maps I linked to are built to look similar to vector data they are delivered as png tiles, and least on my computer (some services switch automatically between pixel/vector). This link (of another Swedish provider) should lead to a true vector map (which runs superduperslow on my old computer): https://www.hitta.se/kartan!~59.39246,17.88950,10z/tr!i=COl8SQsO It's using the same government data source as the eniro website, but unfortunately this one only has Sweden, not Norway and Finland. Interestingly enough it has another type of label algorithm that works worse than the old pixel map in rural areas (ie you need to zoom more than usual to see names). However this vector technology and presentation is very newly introduced so I expect it to be refined over the coming years. Personally I prefer the pixel renderings still as vector is a bit slow on many computers. But it's the future On 2020-11-07 17:45, Anders Torger wrote: Here's an example of vector maps for Norway, Sweden and Finland as presented by a popular Swedish address lookup service: https://kartor.eniro.se/?c=59.370292,17.690735=9 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Basic cartography features missing, why?
Thanks for those valuable points. I'm a layman, watching at OSM form the outside as a casual mapper and user. You're an expert on the inside. My perspective is thus limited, and also limited is the understanding of technical and infrastructure challenges. Regarding of comparing to government maps, I'm a bit sorry for putting that as a strong focus, it varies very much between countries the quality of this data and how it's presented etc. It's just that for me it's a central reference tool when making maps, and the OSM tools is actually preloaded with some of their maps. As an amateur mapper I think it's a good idea to look at professional cartography to see how naming are solved, and as I currently map locations I am very familiar with myself I actually know the names and how they are used, so I'm not just copying from the map. I maintain that the naming issues the thread started with are very real and relevant, and I think it is a problem that they cannot properly be addressed in the current infrastructure. If manual placement of point tags with manual prominence sorting rather than actual mapping of named areas is the better choice in practice, so be it. I'm the layman, you're the expert. I just see a problem and want it solved, somehow. However if the problem is that there is actually no widespread interest to improve in these areas or maybe even OSM shouldn't be used in this way, then ok. I'll know. A key reason for starting this discussion was to feel the pulse where this is going. If OSM is not meant to make cartography to the level I desire, and my desire is just seen as a tiny niche interest, then I know this is a dead end. It does diminish the satisfaction of my own mapping as cartography is one of my driving forces, but I cannot pretend that everyone is like me. I just hope that there are some other cartography fans out there that also like to see a move in this direction. The thing about falling behind, I'm guilty of that narrative, and I've mentioned google maps as one of the main threats (which I think is a realistic scenario), but what it's actually about is that I think OSM has become a bit too stagnant as does not seem to be able to adapt to changed situations and may risk become obsolete in developed countries. I put great importance to cartography here, which perhaps is a misjudgment (ie maybe just my own personal niche interest), but the reason I do it is because I believe many contributing mappers see that as important and makes it more pleasing to contribute, and what OSM needs is contributions, and especially so in Sweden where we are very much behind indeed (not behind Google maps though, which still is kind of bad...). I don't want to disrespect or anything like that, it's just a genuine worry from someone who wants OSM to succeed and grow and become good where I live. About quickly throwing overboard all values, I think one problem is that this community has become so sensitive that every hint of someone suggesting that something needs a change is interpreted as a direct threat. It's not my intention. I don't think we need to throw overboard all values, but I think there is a need to make adjustment due to the huge size and diversity of the community and the increased technical complexity, and the need to involve and manage more commercial interests. I think some centralized elements are required, and OSMF board probably need to be somewhat more involved in strategy. And I don't think we can use a process which takes 4 - 8 years to implement basic features, if some of those basic features are still missing 16 years into the project. I mean those names that brought up all this are hundreds of years old. It's not a new fashionable thing that a map needs to have one name for several entities. It's not a new thing that hills and valleys of varying sizes have names, etc. Sure there are things that are fashion of the day, and it's a good that the overall structure is conservative. I just get a sense that regardless of suggestion made, someone will immediately say in some way or another that change is impossible, and to me that is a bit worrying. /Anders On 2020-11-07 15:34, Christoph Hormann wrote: I wanted to quickly comment on two things where a misleading narrative seems to be represented in the discussion here so far. The first one is the idea that OSM community cartography is being held back by the lack of computing power. It is not. The resources that would be required to run various data preprocessings that have from time to time been considered in map style development are absolutely negligible compared to the ressources used by the OSMF for rendering and tile delivery. The problem is process development and maintainance. I have - together with Jochen - from 2015 to 2019 operated openstreetmapdata.com where we offered various preprocessed OSM data for cartographic applications updated daily and we
Re: [Tagging] Basic cartography features missing, why?
Hello Steve, thanks for that wonderful and inspiring post! I'll surely think about doing-what-can-be-done-with-the-current-tools-at-hand, and think about that the work can be built upon by others in the future. Most inspiring! And I'll also clarify, I don't expect some Swiss cartographic artwork to come out of the renderer. But I do think that OSM could go a lot further in that direction, and should strive to do so. That needs strategic high-level decisions. If cartographic renderings becomes a priority, other design decisions will follow. Now when many other factors are of higher priority, no improvement will happen. I will continue to be a casual mapper as long as the bike routing tools I use use OSM. I'm an egoistic contributor in that regard, I do it because I need have direct use for the data myself. I also map the places I grew up in and love, and I have a specific connection to rural areas (although I live in city now) so I do work there to, makes me feel good. Some do handicraft as relaxing hobby, and mapping is my handicraft. As I described in a different post, here in Sweden OSM doesn't have a particular strong position as the alternatives has come strong the past 5 - 7 years. OSM didn't reach a good baseline here before interest went down due to easily and cheaply accessible alternatives, so we are in a tricky situation. We need mappers and it's hard to convince regular people to contribute to OSM, "why do that when high quality maps are free?". I've written open-source software since the 1990s, so the open license thing is an easy sell to me, but to regular people the ideology bit doesn't really work. I haven't done a survey, but my theory is that the typical contributor here do it as a sort of pleasing handicraft. To make it pleasing the resulting product should be good, and I think there is more to do there, not the least for rural areas where the naming issues is most evident. /Anders On 2020-11-07 13:30, stevea wrote: On Nov 6, 2020, at 1:51 PM, Anders Torger wrote: ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Basic cartography features missing, why?
A move to prioritize cartography is probably not easy and there are lots of challenges. But I think it can be much better than it is today. I'm not too surprised that people in general would prefer google map with less information. The thing with cartography designed for paper is that it's extremely dense as you need to present all the information you can on a single page (you can't zoom), and being used to zoomable map seeing a map designed for paper can be a bit of a shock. Many of these government maps which are zoomable like your beautiful https://map.geo.admin.ch example is not actually a single map, but all the purpose-made maps at different scales, so each zoom level is meant to be used on its own, printed on paper. Probably that is not how OSM should work, and here in Sweden the government maps are now starting to appear in zoomable vector format and they work a bit differently, and look a bit less dense. The information is there though. Personally I like the art of cartography so I like the look of those traditional dense maps, but I also understand that a digital map may need to be a bit different. Here's an example of vector maps for Norway, Sweden and Finland as presented by a popular Swedish address lookup service: https://kartor.eniro.se/?c=59.370292,17.690735=9 They use government-provided data for all three countries. If you ask me I think it's a small step back compared to traditional cartography, example of that here: https://kso.etjanster.lantmateriet.se/?e=657065=6568677=7=default_background_noauth But I understand it's a matter of taste, and in any case the less designed and more automatic vector maps is the future, and it's also more suitable presentation format for the OSM data. However, if the community actually don't see that there is any problem with how the current OSM data is presented and do not want any change, so be it. I'm just a tiny part of the OSM community and I'm not here to tell what we as a whole should do, just voicing some opinions. I am however a bit afraid that the community due to its size has become unable to make strategic decisions, and I do believe that if OSM continues to be stagnant (which to me as a semi-outsider it appears to be), it will lose its position and fall into being a niche product at least in the developed countries. I think for example that Google Maps will develop quite significantly in the coming decade, both in data density and presentation. I think there's a very real risk that they will replace OSM in many places OSM is strong today. That would be sad, but end users don't really care if it's an open license or Google owns it, as long it's "free" to them they go for the best map. Locally here in Sweden we have the problem that OSM data is lacking in large parts of the country, combined with some strongly varying quality imports (imports is a whole other subject...), so we have a lot of mapping and fixing to do before we have a reasonable baseline, so it doesn't have a strong position today. OSM is still being used here as a side effect of international services using OSM, like facebook and various routing tools. I personally use plotaroute for my bike rides, and that was actually how I got into being a mapper, I needed to fix the maps to be able to draw the route, I also like the fact that I can add off-road tracks which aren't really available in normal maps, plus responding immediately to rebuilds in the city (which happens a lot during recent years). But noone here uses OSM for car navigation, the map is not good enough and there are other maps that provide that with 100% coverage. 10 years ago good map data was very expensive here in Sweden, nowadays it's not the case (except for some special uses), so regular users just choose the best map, cost is not an issue. And the result has become that OSM is normally only chosen if it's the only map a specific service uses, and one needs to use that particular service. Or if one like me is a mapper, but I consider that to be a niche. I don't know anyone except myself that contribute to OSM here. With my ~10 days active per year I'm top 15 mapper in the country, which says that OSM is not a huge thing here. In other words, I look at OSM from a perspective where it does not have a strong position today, and that it's free with open license unfortunately doesn't mean much here. The only thing that means something is the product the end user sees. /Anders On 2020-11-07 12:47, Tomas Straupis wrote: 2020-11-07, št, 13:24 Anders Torger rašė: However, and this is a big however, I think that the face of openstreetmap really need to be a cartographic sound map. During personal meetings as well as during different presentations in conferences I've been showing people two maps (one was google, another one was swiss topo https://map.geo.admin.ch). Google is one of the worst (from cartographic perspective) and
Re: [Tagging] Basic cartography features missing, why?
Probably the database should be organized in layers. The more
information there is, the messier it becomes to have everything visible
at once. With JOSM you can sort of simulate layers with filters on tags
(I use that feature all the time), so I'm not sure if it actually needs
to be layers in the database or if it just needs to be adaptation on the
tools side.
I disagree that names in the landscape is of little value, and actually
defining what it is covering is providing additional value over just
placing a point, and I think is opposite to tag for the renderer.
And in the end it's about the resulting map. The current use of points
won't do what's required to be able to make good cartography.
/Anders
On 2020-11-07 13:01, Frederik Ramm wrote:
Hi,
On 11/6/20 19:31, Anders Torger wrote:
** Tagging bays and straits as areas work great, as the renderer gets
and idea how prominent it is and it can make proper text sizing and
they
can be seen even if zoomed out if the area is large. Lots of our
lakes,
even quite small ones have sub-naming, and with these features I can
make really good mapping of this.
This is an absolute pain for me. We're seeing people define
ultra-precise multipolygons of various sizes with the single purpose of
getting a name rendered somewhere in a bay.
If this infects other areas of cartography, we'll see people build
thousand-node polygons for vaguely defined land areas ("the XY
lowlands", "the XY mountain range", "the XY plateau"). This is a very
sad development that makes editing more complicated and burdens the
database with information of very little value.
What people want to achieve is some lettering on the map, and because
the only way to get that is making huge polygons that purport do
describe the exact extent of something, that's what they do.
I think this needs to be stopped. We've created a
mapping-for-the-renderer mechanism by the back door. This is actually
*worse* than if we were to allow people to place a point somewhere and
annotate it with a desired label font size and orientation. Not that I
would advocate the latter, but what we have now has all the negative
features of the latter *plus* the side effect of creating giant,
unmaintainable polygons.
Bye
Frederik
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Basic cartography features missing, why?
Others can correct me if I'm wrong, but I think the problem is not really limited computing power, but it's a design thing. Update speed has a really high priority, too high if you ask me. So regardless of computer power available, we want the fastest update speed possible. For the main servers, as far as I understand they have ready-made tiles basically for the whole world. So there's always a tile ready to serve. When a database update comes in and a tile needs updating the old tile will continue to serve normally until the new is available. To give casual mappers feedback quickly we like this to happen fast. However as the web browsers cache data the mapper may see old data for a long time anyway, so I don't really think update needs to be fast (instead the user interface needs a mechanism to provide the mapper with progress information of the rendering), and then we can switch algorithms to more advanced and slower ones which focus more on cartography and less on speed. However (this is a bit of my guesswork, I haven't read up 100% on this) then we have all those private small servers serving tiles. In this case the hardware is quite simple and inexpensive and there's no practicality in having pre-made tiles for all the world, so you need to render on-demand. In this case it's of course of key importance that these tiles render really quickly or else the map simply won't appear when you browse to view it. I think what OSM needs now is that the main style presented to end users and mappers should be one with more expensive algorithms and a high focus on making the best possible cartography, and also focus on supporting all necessary features so mappers are motivated to tag the data correctly and detailed (ie we have some need in naming groups and areas etc previously discussed). This will be considerably slower to render and possibly quite difficult to develop. Then a computationally fast style could still be maintained for the on-demand use case. If we're smart we make them look similar, so the fast style could be used on-demand and trigger a background process with the slow style that fills up the area in time, as the map is generally viewed again in the same place. On 2020-11-07 12:13, Walker Bradley wrote: Dear all, First off I would like to state how fascinating this conversation is. I've been working with OSM data for years, and I never understood how the rendering actually worked. It seems like the challenges are two-fold. One is computing power and the other seems to be rendering algorithms. Computing power seems to be a constraint struggle without greater fundraising capacity, so could there be some work done on the rendering process? Could we do a specific and targeted fundraising effort to improve the renderer to make as much use of the limited computer power we have? How much would such an endeavor actually cost and how would one go about organizing that? On Nov 7, 2020, at 10:36, Anders Torger wrote: Sorry, I'm no expert so I should have been more humble and not state it as a "fact". I *think* multipolygon was supposed to be a way to make single entities of complex shapes, and these groups are not really single entities, but multiple entities with single names, and thus I find it "superior" to have a specific tag for that. I'm satisfied with using a multipolygon though, and that is what I do now. This group naming is fairly common where I map that I need it now and can't wait until some unspecified time in the future when a specific group tag might be rendered. I suppose you could turn the argument around and say that it's better to use multipolygon and not add bloat with a specific tag. And when the state is as it is, the multipolygon way is the closest to actually do what we need, I can agree with that. I'm all for results. /Anders On 2020-11-07 06:57, Mateusz Konieczny via Tagging wrote: Nov 6, 2020, 23:39 by and...@torger.se: One example is making a multipolygon instead of the semantically superior group, as multipolygon actually renders. Why multipolygon is supposed to be semantically inferior? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Basic cartography features missing, why?
This is great information, I didn't know about your project, very very interesting. I have recently come to understand the OSM-Carto technical challenges recently. I haven't given it much of a thought as a casual mapper for the past two years, just been a bit disappointed with how it looks. I am a programmer in profession though so when taking a deeper look and though about it I see these challenges. However, and this is a big however, I think that the face of openstreetmap really need to be a cartographic sound map. It's not right that a style seemingly designed mainly for speedy diagnosis should be the face of OSM. How many of our mappers are so technical that they understand this? And howcome did I not even know about this cartographic project of yours? If there are great styles out there but noone knows about them that's a problem. And even if we let the not-so-good-cartography be the first map we see on openstreetmap.org (which makes no sense), some of the other layers presented there should be one which focus on good cartography, and all that are there now have many of the same issues as the main style. I assume that many, perhaps most, casual mappers use the web editor. I'm really impressed with the web editor, it's great and is mostly user-friendly, you don't need to be a technical person to map, and that is how I think it should be. One thing with the web editor though is that unless you are technical enough to turn off caching (which essentially means putting the browser in development mode), you won't see the rendered results for a long time, even if reloading the page, you still get cached data. Thus it wouldn't matter if the rendering wasn't updated for a couple of hours or even more, the casual mapper won't see it anyway. I think that direct feedback is desirable of course, but compared to other goals I think it's less important, and one can work with the user interface in the web editor to mitigate this issue. Perhaps just have a way to probe the server so it can deliver some render status. The biggest problem today with the web editor regarding feedback is that to a casual mapper it may not be obvious that the map needs to be rendered at all and that can take time, and together with the web caching and different zoom levels it gets even more confusing. Many of us more experienced mappers know exactly how OSM works and renders, and we go blind for how a new user will experience it. One way to mitigate this could be to turn on some render info view in the web interface to show render status of tiles, maybe even estimated time left, and then a way to refresh the tiles without having to resort to putting the web browser in development mode with disabled cache. And now to the most important point, whether one likes it or not, OSM-Carto as being the face of OSM and the most commonly used style, is the de-facto reference and driver of features and tagging. If OSM-Carto doesn't support basic cartography features many mappers won't be motivated to tag for that, and then the cartographic styles will have less information than they need to make good maps. OSM-Carto due to its limited rendering capabilities also make casual mappers tempted to "tag for the renderer" just to get results, which for example can mean that villages are upped, and thus the cartographic style will get fed with incorrect information. In summary I think there are *very* strong arguments for that the main style shown at openstreetmap.org and the main style used for editors should be focused on providing great cartography (with the extension that it should probably present more features than a usual map, alternatively we need to split into several styles, all cartographic sound), and we must allow it to be be more computationally expensive and come up with smart ways to mitigate that in the tools. We can't stubbornly hold on to principles and use the same arguments that held up and worked well back in 2004, there are things that need to be revised. And one of these things is that we need to understand that good cartography needs priority, and good (online) cartography today has much tougher competition and therefore expectations than it had back in 2004. While searching the web for what's happening inside OSM I found this blog post from 2018 written by a longtime OSM contributor, where some of these issues are discussed: https://blog.emacsen.net/blog/2018/02/16/osm-is-in-trouble/ but it seems that not much has happened since, which makes me somewhat worried about the project's future. I don't think we need a revolution or something, but there are some things that need to start moving, and for some of these things the old processes no longer work. /Anders On 2020-11-07 07:52, Tomas Straupis wrote: 2020-11-07, št, 00:41 Anders Torger rašė: However, how important is it that update of the map is immediate for every database update? <
Re: [Tagging] Basic cartography features missing, why?
Sorry, I'm no expert so I should have been more humble and not state it as a "fact". I *think* multipolygon was supposed to be a way to make single entities of complex shapes, and these groups are not really single entities, but multiple entities with single names, and thus I find it "superior" to have a specific tag for that. I'm satisfied with using a multipolygon though, and that is what I do now. This group naming is fairly common where I map that I need it now and can't wait until some unspecified time in the future when a specific group tag might be rendered. I suppose you could turn the argument around and say that it's better to use multipolygon and not add bloat with a specific tag. And when the state is as it is, the multipolygon way is the closest to actually do what we need, I can agree with that. I'm all for results. /Anders On 2020-11-07 06:57, Mateusz Konieczny via Tagging wrote: Nov 6, 2020, 23:39 by and...@torger.se: One example is making a multipolygon instead of the semantically superior group, as multipolygon actually renders. Why multipolygon is supposed to be semantically inferior? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Basic cartography features missing, why?
Hello Graeme, the nature of these gravel yards vary a bit, but they can look like this: https://showmystreet.com/#12q73u_a3n0t_1v.a_-4f42 and they were made maybe 50 years ago. This one probably comes from the time the road was straightened in the 1970s or so. But there are also these things near say hydro power plants or other things construction, 50 - 70 years old. The thing with rural areas is that space is cheap, so there are many of these leftover spaces from past times. And of course there are also those that can be more easily identified as abandoned gravel pits were raw material for the roads were taken, there the quarry tag is more fitting. Anyway, these are rather good to have on a map as they today serve can serve as places to park your car or caravan when getting out into nature. About upping villages, I know exactly about that problem. Here it's typical that a village consists of a few farms (nowadays most of them inactive or at hobbyist level) and has 5 - 10 inhabitants. The villages are quite closely spaced and kids go to school and shopping is made in a nearby town, so it's quite nice to live here still if you like peace and quiet :-). Anyway these type of landscapes makes the fixed sizing and zoom visibility of name labels not work well. The names of these tiny villages are important for navigation and you need them on an overview map. If you look at our official maps how they do it, they actually don't up the villages (ie show them more prominently here in rural areas than in the densely populated south), but instead they render the names larger and keep them for longer when you zoom out, and when it becomes too cluttered they have information about which names to prioritize over others. And if you to that can name the landscape (which is limited support for in OSM), you get a good overview map for navigation. Here's a comparison between an official Swedish map and OSM in the same location to show the difference in (extreme) cases: https://www.torger.se/anders/downloads/comparison.png In OSM zoomed out maps in these areas unfortunately just looks like poorly designed cartography. Many of these villages are farmlands, so they cover a pretty big area and you see them from far. There's lots and lots of space to render name tags, but still there's no name. I understand that this is the effect when you 1) need to have a style that requires little processing power to render and 2) in combination need to have the same style for 1 million people per square km and 5 people per square km (like it is here). I don't think the right way to solve this is to have varying style depending on local density. What's needed is better and more computationally costly render algorithms that can deal with larger name tags and higher name tag density and then just have names visible from earlier zoom levels. However, the style of rendering has been fairly static for X number of years, and there's no sign that this ever will be solved. Many of us mappers just want one thing -- a good result *now*, not hope for it to *maybe* come in 5 years. So I understand that some do tag for the renderer, and simply up the villages. I see s many examples of "tagging for the renderer". It's said over and over again that you shouldn't do it, but people still do. It seems like OSM (=we) don't understand that we can't tell people to not tag for the renderer, if the renderer never improves. I think the map we see at openstreetmap.org needs to show progress and improve to gain credibility among casual mappers. Casual mappers don't know about all the technical challenges and algorithm complexity of making a good render. They do know how a good useful map with well-designed cartography looks though, and in many parts of the world those are easily accessible and already used by some online services. There is tough competition today, and if OSM can't compete with cartography I think it will be increasingly hard to recruit mappers, and those that do join will be tempted to tag for the renderer to just try to come somewhat close to what the official maps can show. On 2020-11-06 23:22, Graeme Fitzpatrick wrote: On Sat, 7 Nov 2020 at 04:34, Anders Torger wrote: ** Due to limitations in area-based name tagging the map looks empty just when zoomed out a little, as names disappear almost directly, so despite detailed mapping and tagging the overview map is not as useful as it could be. While the renderer can and does make proper decisions of prominence for bays and strait made as areas, point-based natural names often yield strange and misleading maps as vastly different sized areas have just a point for the name and no other differentiator, there's no way the renderer can make an appropriate render decision as the data is not there. Welcome, Anders. That is a problem that we encounter all the time in Australia, where there are huge expanses of empty, & official OSM g
Re: [Tagging] Basic cartography features missing, why?
On 2020-11-06 23:35, Martin Koppenhoefer wrote: Am Fr., 6. Nov. 2020 um 23:28 Uhr schrieb Anders Torger : I agree, but one renders (in some way at least), the other doesn't. Which one will the casual mapper choose? I'm a bit impatient and like to see results now. The cluster tag was drafted 2015, the group tag 2018. None of them render as far as I know. that's both not "old" in OSM. Almost all tags that are rendered currently have been around for at least double that time. The more you use a feature, the more likely it will eventually be implemented later on by data users. Nobody is going to invent and test a system just to render 100 objects. And indeed we are closing in to the core of the problem. I don't think the traditional OSM processes is keeping up with its own growth and the speed the competition is moving. Some reform in the organization is probably required at least in part, or else OSM is too stagnant for its own good. If OSM had a strategic working group that were responsible for some key developments in style and cartography they could on their own identify baseline features that are lacking or that can be improved. Cartography has been around for a very long time, long before computers. The naming issues I've described is not actually new and unique. I think all of them would have been picked up by such a strategic cartography group, which would implement features and suggest guidelines. And this is not really dictatorship either, if mappers won't use the features, so be it. A misjudgment and some unused code. There's still a place for a long term tagging process for more exotic things, but waiting many years for basic features this process has for one reason or another missed up to this point I think is a problem. If individual casual unorganized mappers like myself on their own shall make these features happen and have 4 - 10 years patience to see it maybe go through, it won't happen and the likelihood decreases the larger the community becomes. It's not suistainable today. How will Google Maps look in 4 - 10 years? AI and machine learning is coming. I think we need to keep moving and keep upping our game or watch us become irrelevant, at least in many countries. /Anders___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Basic cartography features missing, why?
Good point, so there's a balance. However, how important is it that update of the map is immediate for every database update? To me it seems more desirable to have a higher quality cartography at the price of a lower update rate. Longer tile generation times won't affect serving rate, just how quickly you see your edits appear in the map, which by the way seems to have improved significantly since I started mapping. You could argue, that the default style should focus on speed and commercial third party providers can focus on quality. While I think that argument has some merit, I see a problem as openstreetmap-carto is the de-facto driver for general-purpose tagging. If basic cartography features concerning naming for example doesn't appear on that or are rendered poorly, mappers won't be motivated to tag properly for it. One example is making a multipolygon instead of the semantically superior group, as multipolygon actually renders. /Anders On 2020-11-06 23:26, Martin Koppenhoefer wrote: Am Fr., 6. Nov. 2020 um 23:21 Uhr schrieb Anders Torger : I have not understood why there are these CPU limits, if it's "just" due to under-financed server infrastructure, or if it is a problem that can't be solved regardless of server infrastructure. As a layman one would think that some of these algorithms could run on GPU clusters these days, but I have no idea... it feels a bit problematic though if the quality of OSM's cartography is held back due to limited server infrastructure. if you want to create a map for publishing it, you can also do computationally expensive tasks in the process, but if you are updating and republishing continuously, every minute, you will want to reduce the computational effort. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Basic cartography features missing, why?
I agree, but one renders (in some way at least), the other doesn't. Which one will the casual mapper choose? I'm a bit impatient and like to see results now. The cluster tag was drafted 2015, the group tag 2018. None of them render as far as I know. /Anders On 2020-11-06 23:10, Martin Koppenhoefer wrote: Am Fr., 6. Nov. 2020 um 21:04 Uhr schrieb Mateusz Konieczny via Tagging : ** Support for group naming is limited. It's here very common that several smaller islands are named as a group, smaller ponds are named as a group etc, without having individual names. There are tags for that (group/cluster), but not rendered. Mostly because multipolygons are strictly superior. for groups, the group relation is clearly superior. First of all, it implies group semantics and is defined. For a multipolygon, it may not be clear what it is about, unless you invent tags for "a group of lakes", a group of ponds, a group of trees, a group of island. But still, it only works for areas, you cannot use multipolygons for groups of nodes or groups of lines, or mixes of these. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Basic cartography features missing, why?
Sorry for replying to myself, but I forgot to mention one important aspect that I myself hadn't realized until recently: it's seems to be a whole lot about processing power too. Name tag scaling and placement strategies are expensive algorithms compared to what we the default style does now, and I see repeatedly when various improvements to openstreetmap-carto is discussed that "the idea is good and would improve the style, but is unfortunately too computationally expensive so it's not feasible". I suspect that least some of the naming falls into that category, especially when doing smart things when zooming out to give good overview maps. I have not understood why there are these CPU limits, if it's "just" due to under-financed server infrastructure, or if it is a problem that can't be solved regardless of server infrastructure. As a layman one would think that some of these algorithms could run on GPU clusters these days, but I have no idea... it feels a bit problematic though if the quality of OSM's cartography is held back due to limited server infrastructure. /Anders On 2020-11-06 22:51, Anders Torger wrote: I'd love to help out if the workload and chance of success was reasonable, but I'm a bit wary about the tagging proposal process. Most of my mapping contributions is simple things like correcting and adding roads so all the various online route planners (and indeed bike computers) that use OSM in one way or another can work in the areas I spend time. For that the map does not need to be complete at all, I just need a graph of roads, and I use the regular government-provided maps to actually scout the area. Recently I got more interested in trying to make actual complete and good cartography, make maps that accurately describes the area (to a certain detail level) and doesn't require "a real map" on the side for scouting, in other words make OSM to be a real map in the areas I live. It would also be nice if one could make hiking maps for the mountains. This is an extremely ambitious goal, in Scandinavia, and probably many more countries, we are used at having really great cartography from a special cartography institute which is a part of the government. Previously the maps were expensive to get and you could only get it on paper. Today the main aspects exists for free in digital form (which is a good thing, it's made with tax payers' money after all). Here, this is the gold standard for a general-purpose map. However, when I see there are some key features missing in OSM to be able to reach that level, and each of those little features may take years of processing from proposal to actual implementation in a renderer (and even if a proposal goes through, I suppose it's not guaranteed that it may be implemented), then it feels like it's just too much for me, as I'm involved in many other volunteer projects too. Mapping is not even my main project. To make this happen it seems like I will end up with having to implement my own style and have my own tile server and using my own tags... it's just not feasible. What I have done so far in my own mapping applications which works sort of fine is to use ready-made government maps in a custom layer for the more zoomed out map (and indeed have an own tile server for that), and then switch to OSM for the most zoomed in levels. The limitations in name handling and missing names for large areas is less noticed when fully zoomed in. But it would be really cool if one could use OSM for the whole cartography experience. As far as I understand, OSM is supposed to be a decentralized and semi-anarchistic consensus community that's why the proposal process looks like it does, but somehow I was hoping for that there was a strategic work group with access to professional cartography expertise that on their own could recognize, pick up, and implement both the feature and the guideline for baseline type of "must have" features, while tagging proposal process would be for more exotic things. I'm afraid that with this thorough long-haul process and still pretty basic cartography features lacking, we may never see them. I understand that OSM is a geo database, not a map as such, and it seems like the actual map-making hasn't been a top priority but left to third parties, and this may be a reason that features required for top quality cartography has been left unimplemented for so long. Another thing with these naming features is while they are indeed important to reach professional-grade maps, you need to be a very patient and persistent perfectionist to actually care (sort of like an old-school cartographer), and have the endurance to continue to care. It's much easier to just skip the names that can't be mapped, or make them as a point and not care that zoomed out maps don't work well. We've seen plenty of desperate/chaotic use of place=locality tag just to get names when there is no real support. If
Re: [Tagging] Basic cartography features missing, why?
I'd love to help out if the workload and chance of success was reasonable, but I'm a bit wary about the tagging proposal process. Most of my mapping contributions is simple things like correcting and adding roads so all the various online route planners (and indeed bike computers) that use OSM in one way or another can work in the areas I spend time. For that the map does not need to be complete at all, I just need a graph of roads, and I use the regular government-provided maps to actually scout the area. Recently I got more interested in trying to make actual complete and good cartography, make maps that accurately describes the area (to a certain detail level) and doesn't require "a real map" on the side for scouting, in other words make OSM to be a real map in the areas I live. It would also be nice if one could make hiking maps for the mountains. This is an extremely ambitious goal, in Scandinavia, and probably many more countries, we are used at having really great cartography from a special cartography institute which is a part of the government. Previously the maps were expensive to get and you could only get it on paper. Today the main aspects exists for free in digital form (which is a good thing, it's made with tax payers' money after all). Here, this is the gold standard for a general-purpose map. However, when I see there are some key features missing in OSM to be able to reach that level, and each of those little features may take years of processing from proposal to actual implementation in a renderer (and even if a proposal goes through, I suppose it's not guaranteed that it may be implemented), then it feels like it's just too much for me, as I'm involved in many other volunteer projects too. Mapping is not even my main project. To make this happen it seems like I will end up with having to implement my own style and have my own tile server and using my own tags... it's just not feasible. What I have done so far in my own mapping applications which works sort of fine is to use ready-made government maps in a custom layer for the more zoomed out map (and indeed have an own tile server for that), and then switch to OSM for the most zoomed in levels. The limitations in name handling and missing names for large areas is less noticed when fully zoomed in. But it would be really cool if one could use OSM for the whole cartography experience. As far as I understand, OSM is supposed to be a decentralized and semi-anarchistic consensus community that's why the proposal process looks like it does, but somehow I was hoping for that there was a strategic work group with access to professional cartography expertise that on their own could recognize, pick up, and implement both the feature and the guideline for baseline type of "must have" features, while tagging proposal process would be for more exotic things. I'm afraid that with this thorough long-haul process and still pretty basic cartography features lacking, we may never see them. I understand that OSM is a geo database, not a map as such, and it seems like the actual map-making hasn't been a top priority but left to third parties, and this may be a reason that features required for top quality cartography has been left unimplemented for so long. Another thing with these naming features is while they are indeed important to reach professional-grade maps, you need to be a very patient and persistent perfectionist to actually care (sort of like an old-school cartographer), and have the endurance to continue to care. It's much easier to just skip the names that can't be mapped, or make them as a point and not care that zoomed out maps don't work well. We've seen plenty of desperate/chaotic use of place=locality tag just to get names when there is no real support. If that's the case, then it maybe is better to just relax, let go, and let OSM be what it is today and not try achieve what it can't do. For me this means going back to just doing road work, and switch to the government maps anytime I need a real map. I'm fine with that. On 2020-11-06 20:19, Andrew Harvey wrote: All great points there, I've ran into many of those myself. If you're interested in helping work on solutions to these, discussion here is probably the best place to start, once ideas gain some momentum you can start a tagging proposal https://wiki.openstreetmap.org/wiki/Proposal_process. Going through that process takes a huge amount of time, effort and communication, but usually results in well rounded documentation and considers a wide range of scenarios and creates better tags than just "using whatever tags you like". ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Basic cartography features missing, why?
and paper form, see the ability to name groups, and the ability to differentiate size of natural features as very basic functions required to produce high quality cartography. But OSM is a 16 year old project and still doesn't have widespread support for these basic features, essentially making high quality cartography an impossibility at least in this part of the world. This is strange, there must be something else going on. Maybe it's technically difficult to implement. Maybe it's technically difficult to make any new things at all as the database has grown. Maybe it's hard to get acceptance for new features as the community has grown large and diverse. Maybe OSM is not intended for mapping natural features. Maybe the ability to show anything useful other than maximally zoomed in isn't a priority. Maybe rural areas isn't important to OSM. I don't know. Oh, while these cartography issues indeed are more prominent in rural areas, we do have named areas in denser places in Sweden too like in and around Stockholm, it just doesn't hurt as much if you leave out these names as there are much other things to navigate by. Anyway, I'm not really prepared to fight or self-tag 10 of these objects just to try and see if these features might be accepted some years from now. I'm basically just checking out the status here to see if OSM and I has a future together :-). For my own mapping needs I don't absolutely need OSM, I can choose to work with the government data instead as much of that has been publically available since 2015. It's however nice to be able to contribute to something that is globally available with an open license, but great cartography is also important to me. I know I will get that from the government data. With OSM it seems... ehh... complicated. I'm not really prepared to significantly increase my mapping effort (Sweden in OSM is still too a large extent unmapped or poorly mapped) if despite exact and fully detailed contributions there will still be sub-standard maps coming out of it. /Anders Torger ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
