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. 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.
As a result the pace of development is 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, and even those things that needs change are just too hard to
change so there's little idea to even discuss it. 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.
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. 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. 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.
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.
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 strongly believe that openstreetmap.org needs to present a set of
great end user maps for the most common use cases. 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.
We already have the start of that on www.openstreetmap.org [3] and
recently another layer was added, but well, in my humble opinion the
renderings are not great due to lacking cartography features. 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
[3] 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. 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.
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".
/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 <and...@torger.se>
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 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 [1] 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? <...>
OSM-Carto is a style whose purpose is to visualise OSM data to
MAPPERS, do it quickly (fast feedback is essential). OSM-Carto also
has a requirement to be easily deployable by almost anybody on any
hardware. This means that pre-processing of data is impossible as per
requirements (not a design decision). And without pre-processing it is
impossible to have a cartographically sound map. So even while the
OSM-Carto team is doing a terrific job and they do have people with
good cartographic knowledge (like Christopher), but OSM-Carto does not
have such a purpose - cartography.
We're playing around with a small project striving to comply with
cartographic rules - topo.openmap.lt [2] - 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.
Therefore if you want to have a cartographically sound map - you
will need a separate project - separate rendering and stuff. You're
totally right - for general (not mapper) use, minutely update is less
important than cartographically correct representation. And also not
everything has to be generalised, some parts could be updated very
fast, some could be updated weekly or even monthly. Segmentation of
data could also get more attention (re-calculating only the parts
which need re-creation). Such tasks could even push forward topics
which are currently the target of generalisation and multiple
representation group of International cartographic association - I
really think OpenStreetMap has people and capabilities to have a say
there.
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
--
Thanks,
Seth
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Links:
------
[1] http://openstreetmap.org/
[2] http://topo.openmap.lt/
[3] http://www.openstreetmap.org
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
