Warning: lengthy reply to an already-lengthy thread. On Nov 8, 2020, at 3:26 AM, Anders Torger <[email protected]> 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 have local chapter boards we (as members) elect to do some of the necessary housekeeping (legal, data, others) that a project this large requires. I'm actually in the process of "designing a technical solution" with two or three (maybe four) other long-term OSM volunteers: we collaborate on the syntax of improving park boundaries and protected areas (a confusing and doesn't-render-consistently problem area in OSM). It might take ANOTHER year to get this right, that's OK, we have the patience to do so. This isn't rare, it is OSM in action. It might take time, a lot of reading (of wiki, of technical documentation, sometimes repositories like GitHub...) and consultation with wiser, more experienced people when you run into a block, but those kinds of activities are true of any (larger) organization as one might strive to make it better, grow or solve problems within it. Again, you are asking good questions, but it seems you lack some experience in how OSM works, or suffer from what I'm sad to say I think a lot of volunteers in OSM find, that "how OSM works" can be opaque, confusing and even secretive. For workaday, straightforward tasks like mapping at at simple to intermediate levels, this isn't true, in fact OSM does pretty well there, our wiki documentation goes a long way to explain the "how" questions that many have. But for the inner machinations at the highest levels, you'll either need to pay attention to a lot of detail (e.g. board meeting minutes) or you might discover this is largely invisible and moves with what might be described as mysterious forces. Again, this is no different than many, even most larger or very large organizations. > As a result the pace of development is glacial. I disagree. Yes, the project can grow and develop more quickly, that is something we should work to improve. But "glacial" is an exaggeration. As you introduce yourself as a "newcomer," how are you able to characterize us as "glacial?" > 16 years of age and still basic cartography features missing, that's why I > started this thread in the first place. You have a core inside group that > thinks OSM is great in most ways and really nothing needs to be changed, I sincerely doubt that. While I respect your individual opinion here, I doubt you'll find widespread acceptance of that in OSM. > and even those things that needs change are just too hard to change so > there's little idea to even discuss it. No, they are not "too hard to change," though again, I respect that it might feel that way to you. And there is CERTAINLY a lot of discussion (right here, in fact) about change in OSM. Change is just about the only constant in this project! (I do exaggerate a bit here). > I've been criticized for putting out a narrative that the competition is may > be moving past us, but I do think that can happen in various parts of the > world. The two main "threats" are government maps made public / low cost and > Google Maps. I don't wish to criticize you, though I'm not sure I fully agree with your characterization of "competition." There are millions of maps created by humans. Each have purposes for being published, with specific target audiences in mind during their creation. Many (especially digital ones) are customizable as to what data or "look" the final "product" actually includes. In fact, that's a primary reason OSM is described as a data project: with "the truth of the real world in the database" (to the extent we have entered these data), the actual map (rendering) can be a pre-made renderer or wholly up to you. THAT is the power of OSM, especially as we emphasis "OSM is about our data, not how they render." > In many cases the public government maps can be used to our advantage as they > in many cases can be used as basis for an import. Of course. Vast amounts of government data are in OSM. In my country (USA), all data at the federal level is in the public domain (unless classified, e.g. military secrets). This is true at many state and local levels, too. Many in OSM say (rightly so, for some data) that public data should remain in these governmental digital realms, and that if OSM users want to use them, use them in their original form, rather than importing them into OSM. But others (also rightly so) say that a certain "baseline" of data from government sources DO belong in OSM. (Roads, rail, waterways, forests, parklands, landuse and other public lands are some of the good examples included which have been imported and truly do improve OSM's data). Where such data are determined to be a good match for inclusion in OSM and how they are imported has been the subject of MUCH discussion and we have evolved our Import Guidelines to better this process. Though I do remember the wild days of old, before Import Guidelines, and it was quite disorderly: little if any of the learning process that has evolved to allow us (the community) to make judgements about "good vs. bad" existed in those early days. OSM had to evolve this learning process and we still do so today. We vet and ponder Imports on a case-by-case basis (correctly, we have agreed by consensus) sometimes a proposed Import is an appropriate good idea, sometimes not. > But in certain countries, like Sweden where I live, this haven't worked well > despite the data has been there for 5 years and almost 100% of the Swedish > OSM map would benefit from import (of high quality!). This is a huge problem > for OSM here locally. I dare to say that the general view of Swedish people > regarding maps is that OSM is already obsolete. You could decide "OK, OSM is obsolete for Sweden" and walk away. You could decide "it will take a great deal of community building, expertise, effort and time, but we COULD make OSM around Sweden the best slice of Earth that OSM has." And both of those (as a conclusion and a goal) could be true, both at the same time. Once again, there are no magic wands. OSM takes effort, but many (myself included) find the benefits are worth the time and effort. I wouldn't call it "a huge problem for OSM here locally," I would call it "a huge opportunity for OSM to shine and be as good as it can be." It's all in your perspective of what OSM is and might / will be in the future. Think long-term with OSM. We do, already. > I know many that played around with it 7-8 years ago when maps were expensive > and hard to get, but now they use services that have maps based on government > data, and google maps is coming strong (although it's still pretty bad, but > it is showing progress). Now few even know that OSM is actually used via > providers in say facebook, and various global fitness applications. In other > countries the situation can be totally different of course. Your perspective sounds parochial (local, limited, not as broad as it could be). So what? that "many played around with it years ago?" So what? that "few even know that OSM is used by providers?" If you don't like the (e.g. fitness) apps' data in your country, then improve the map data in your country. The apps data will catch up and you can be proud that you improved OSM's data AND (therefore) the apps' map database (as one and the same thing). I do this all the time with local trails and such and download the results in Garmin maps that are published on a talk page periodically, then I hold in my hand my GPS with an SD card that has my and other OSM Contributors' edits on it. Yeah! Your other option is to simply not use OSM, as it appears it may not be suitable for your purposes. That's fine by us, we don't want to be something we are not. However, you may be surprised to discover that OSM is highly flexible as a geographic database: if you wish to make use of OSM in this way and improve what will end up being data you use as a consumer, not only do YOU benefit, but the rest of the OSM ecosystem does, too. That's how OSM works: give, take, give...and up and up the map grows — for everybody. > A board would not have as goal to run over people. It would identify risks, > identify things that needs professionalization, manage commercial > collaborations, and just make things happen. Our local (chapter) boards already do these things: LWG manages legal risks, some grant money has recently been allocated to "professionalization" (further development and refinement of services that OSM already uses, like geocoding). The "manage" aspect to "commercial collaborations" is a bit tricky to both talk about and do, as the corporations that choose to collaborate with OSM do so on a number of different levels (sponsorships exist, for example). However, corporations that wish to develop GOOD relationships with OSM learn sooner or later to "play by the rules" or they find themselves frustrated by the community (with reason). Saying "just make things happen," unfortunately is too vague for me to make sense out of, so I won't try. > Or maybe there is some other way forward. But I think something needs to > change if we want to 1) be able to attract new mappers, 2) stay relevant long > term. I don't wish to sound smug, as I'm as eager for wise improvement as any enthusiastic Contributor should be. But we ARE attracting new mappers and we ARE relevant long term. Please cite your evidence otherwise, unless it is your own personal dissatisfaction with certain (localized) aspects of the map not being as well-developed as you might like. The solution to that is to better develop OSM. And there are LOTS of "ways forward." You sound like you give up easily. Please don't. The creative spirit to ask questions, develop solutions within the community and literally change and grow as a maturing project is what makes OSM what it is. The (effectively dead-end) approach of complaining "it isn't good enough" or "it appears to be missing basic cartography features" (oh, you didn't say "appears," you asserted we DO) is NOT what OSM is about. I'm trying to help you see that your spirit seems to be going in the right direction, but your approach is stunting your ability to do so. Don't look for reasons why OSM is all wrong or not to your liking. Do look for how your creativity and contributions can MAKE it MORE to your liking. That "lights a fire" for others to do so, too, and so grows the map. > I strongly believe that openstreetmap.org needs to present a set of great end > user maps for the most common use cases. Then you appear to be mistaken in your interpretation of what OSM is. If you want those, and find them lacking, then build them — it sounds like you are talking about specific renderers, and there are many, many specialized renderers around the world that use OSM data to present its underlying data in precisely the rendering that you wish to see. If you build that renderer and find that the data it presents are lacking in some part of the world you wish to see rendered, the solution to that is to build the data in OSM. But saying "OSM needs to make this" is no different than wishing for a magic wand. There are no magic wands. > It might hurt business of mapbox and others short term, but will help them > long-term. There will always be need for additional styles and custom maps > even if the official OSM maps are made great for typical applications. Even though I have been to their headquarters, spoken to a lot of people there and use their products, I can't pretend I know enough about Mapbox's business practices to say (here, now) what would "hurt" Mapbox. And as a "newcomer" (your first words as you introduced yourself here), maybe you don't either. > We already have the start of that on www.openstreetmap.org and recently > another layer was added, but well, in my humble opinion the renderings are > not great due to lacking cartography features. Such complaints deservedly get (from me, here and now) the suggestion that you improve them. I have read (and re-read) your (nine specific) complaints that started this thread and they seem largely to be based on limited understanding and/or practice with OSM tags, mapping and Carto renderings, blending concepts of what you call "basic cartography features" with OSM's renderings (confusing "the territory for the map") when things like "grouping" (a common theme in your list) are not necessarily "basic cartography features." I WILL say "thank you for your questions," as they seem to point out some shortcomings, but these seem largely to be part of your understanding of cartography and mapping, not in some inherent limitations of OSM as a geographic database. Yes, that might underscore that OSM has some work to do in remedying the specific limitations in your particular understanding of what you might wish to see in renderings, so I continue to attempt to get at the root of what your complaints are. But I don't believe it is in some limitations in OSM's ability to provide "basic cartography features," as I don't believe it has those, even after reading your list of complaints. Do you want to map an "anonymous gravel yard" but don't know how? I don't know how, either, but if I had a burning desire to do so, I might search wiki, come up empty, then simply draw the polygon and tag it man_made=gravel_yard, including a note tag that offers specifics and why you "coined" a value for key man_made that is undocumented. That's not perfection, but it is OSM in action, and while it won't render (today, who knows about in two, three or five years, though...), it gives future mappers the basic data needed to make sense of your entry into OSM. That's OSM, right there. (Thank you for asking). But so is you asking "hey, it seems I want to map things, yet I can't discover how to tag them." Good for you. We're trying to help you here. But we don't need complaints from a newcomer that OSM needs to be things it will never be, or that we ought to be in the business of affecting businesses whose business it is to use OSM. That is broken, circular logic and hinders what you and we are trying to do (make great map data that can be used by anybody). Sure, you could propose "anonymous gravel yard" as a new feature proposal and go through what it takes to do that. (And I'm going through it right now, and I know it is a fair bit of sweat and work). Sometimes that is appropriate (like for broader things like Park boundary betterments), sometimes it is overkill (like maybe for anonymous gravel yards). I don't know, but the community does, so try it out. (Either coining a tag or making a proposal). One way or another you win, OSM as a community wins, the map (data) wins. Everybody wins. But not until you "do things" as OSM sees them and knows them to be done. We find ourselves on the tagging list, which is a very widely read forum and perhaps not appropriate. Try more-specific venues as I describe (actual coined tag on a node or polygon, or a modest proposal). The community WILL respond, I promise. > And the website is actually more of an entry point for mappers rather than > end users, which is really odd. I don't even know where to send newcomers > when I want to show them what OSM can do. I think www.openstreetmap.org > should be an end user site, and say something like edit.openstreetmap.org > could be the site as it is now. I think we need to think about how OSM is > experienced from the outside, unless we just want it to become a niche > handicraft object for ourselves. Thank you for your opinions. > And by the way the website looks exactly the same it did like 10 years ago. > That's good for an edit website for insiders. It's not good for being the > face of OSM, and contributes to the view that development is glacial even if > a lot happens under the surface. Sure people like us usually don't like > website fashion, but we can't just ignore how OSM is experienced from the > outside. Oh well, we can, but I don't think it's a good idea long-term. Thank you for your opinions. > Garmin has a vector rendering of openstreetmap in their connect fitness web > app, they also have Google and HERE as alternative layers. The vector > openstreetmap layer is no way showing near what actually is in the current > database, and there's various artifacts. A huge lake where I live is missing > alltogether (probably because the polygon is made in some way that vector > engine can't understand). I think this is just one example what happens with > the fragmented landscape of OSM map providers and that our own maps are not > able to fulfill the needs of typical applications. Garmin as being hugely > popular 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". Thank you for your opinions. Anders, we want to help. Let's take bite-size chews here, so we can masticate and swallow, without choking. Rome wasn't built in a day. SteveA _______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
