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
