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?
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
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] natural=fell not rendered, alternatives?
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] natural=fell not rendered, alternatives?
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". "Don't let the bastards grind you down" - U2 :-) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
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?
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. -- Tomas ___ 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] natural=fell not rendered, alternatives?
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. -- Tomas ___ 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] natural=fell not rendered, alternatives?
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. > That is the jargon can be quite "hard" with many strong opinions clashing, > but it's nothing personal. Your jargon isn’t what I experience in professional software engineering settings, it is what I hear from smart-aleck, spoiled children or teenagers. I don’t take it personally, that’s a mistake on your part. I find it wholly ineffective. Because it is. > 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. While on occasion here, I have seen a certain swagger and displays of, let’s say, “attitude,” I haven’t seen the constant, aggressive, highly negative “toughness” that you bring. It is relentless. What others do is ask questions. By contrast, what you do is complain and say what is wrong with how we already do things. We’ve gotten a lot done and have much to do yet, but we partly do that with dialog, not by giving cookies to children. > 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. The problem isn’t jargon. I understand jargon, the list understands jargon. (And if or when we don’t we ask for clarification, usually getting it. That’s part of how good dialog works). The problem is that your complaints to this list are nearly completely lacking in “good questions” that any of us can field (or, given your poor attitude, really want to). They are as I have described them. Only very rarely are they well-posed questions. Please endeavor to remedy that and I virtually guarantee that you will find people who reply with thoughtful answers, or at the very least helpful direction. But plain and simple, nobody likes a complainer. > 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) Please be careful about assumptions that you make and how they affect you: this is part of what is ineffective with your interactions with this list. OSM doesn’t need you to make excuses (like that you or anybody “understands that “there are issues”). > and therefore come across many issues which have no clear answers. To you, now, when you haven’t clearly and politely asked your question. Try this: before posting your “issues,” distill them down to one or two well-crafted questions that someone on this list MIGHT be able to answer succinctly. Before you actually write it, consider some possible answers. Ask: might it be X, is Y even possible, does Z seem like a feasible direction to explore if this has never been done in OSM before? Like that. It works! > 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). I understand how that works, you are correct. This IS a (good) place to turn when the wiki or other sources do not satisfy your craving to know how to do something in OSM. It is HOW one does that questioning here that (partly) determines how likely you are to get an answer. Well-crafted, judgement-free, lacking-in-assumptions questions do well. Non-questions that are judgmental and assume (a little, a lot) do poorly, as you have discovered. > 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. You can describe these “issues” in the course of the dialog with someone who engages you here if and as they actually provide a blockade to
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 "my preferences are the best" is not that great: I'm
Re: [Tagging] natural=fell not rendered, alternatives?
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
Re: [Tagging] natural=fell not rendered, alternatives?
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 "my preferences are the best" is not that great: I'm already there! > 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...). More than a bit unfortunate are posts by constant complainers. > 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. It seems like a very odd choice to write to a list with little more than "you folks are wrong, why don't you simply do things the way that _I_ want them done?" Even after we (I, others...) politely and patiently engage you, do you expect us to keep doing so when it appears you cannot write to this list with little more than a litany of complaints? > Fell indicates where we have bare mountain (above treeline), which is the key > information outdoor goers need Says you. Others might agree, others disagree, not everybody thinks like you. OSM aims to be for all, not just you. > 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. The reason humans make maps is because nature, the world around us, is always changing in some way and is absolutely NOT predictable. Maps are an approximation of reality, not reality. There is no such thing of value as "quite predictable." The first time something happens that wasn't predicted, you'll learn the value of that. > 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. I'm pretty sure of one thing: you are not hard to read. I see your name in the From header and know that I'm about to read someone hostile to OSM who can't seem to make even constructive criticism. It's all rock-throwing, here's what's wrong with you and why don't you do things my way? (Without so much as a "please"). > 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
