[OSM-talk] An open letter to OSMF board members.
ndrw6
ndrw6 at redhazel.co.uk
Mon Jun 6 12:35:00 UTC 2022
Hi Włodzimierz and all,
I have been going through the whole process on several occasions (I have
contributed office=* rendering and a few smaller features or bug fixes)
and I share your frustrations. This post is not to answer your questions
but to illustrate my own findings and explain some organizational and
technical aspects causing problems.
OSM Carto style is the "face of OSM". It is the default visualization of
our data, it is community maintained and in line with project goals.
Other styles exist but they are either smaller scale deployments or
styles used by commercial users of OSM data. Majority of OSM users do
care about the presentation as much as they care about the quality of
the data themselves.
There is a continuous conflict of interest on what the default style
should be. Should it promote OSM as a whole, should it build local
communities, should it support mapping, should it focus on navigation,
be a base layer for custom maps, prioritize densely populated cities or
country walks, support interior mapping or 3D mapping.
OSM Carto uses a preconditioned database and Mapnik for tile
rasterization. This is important because this is where many limitations
come from. After tiles are rendered there is no further customization
(no language, PoI, traffic layers). Everything has to be baked in at the
rasterization phase. Some alternative maps (example of a nice one:
https://bexhill-osm.org.uk/?T=pois) try drawing on top of the base map
but this is not scalable beyond local maps.
That "one size fits all" issue is aggravated by the UI for selecting
alternative layers on osm.org. Whether we like it or not, the de-facto
standard for it is a widget at the bottom left of the window like the
one used on maps.google.com.
So, we have a default map with bland colors (people want to use it as a
base map), which does not show information people are looking for, yet
is overloaded with many other details. The map is not localized (does
not adapt to the the language of the user), is not interactive - users
would like to click on the map to check details of objects. And the map
scales poorly on devices with HDPI screens.
Then there is Carto style development itself.
After a good start a decade ago the development has stalled for a few
years, until new maintainers have stepped in. Props to Daniel for doing
an excellent job. However, the project is both understaffed and at the
same time too many people are involved in decision making. A lot of time
and effort goes into "bike shedding" and the above constraints and
conflicts of interests are making this process very difficult.
My own hand experience was that unless you are technical enough to
implement all changes yourself multiple times and then fight for them in
all the draining discussion where all the above tradeoffs are discussed
over and over there is virtually no way the feature will be merged. This
is where "scratching your own itch" originates from - it is simply too
much work to put into something you do not particularly care about. Even
for things people do care for, there is a pain threshold contributors
are willing to endure. Filing a feature request ticket is like asking
someone to do all the hard work for you - unless one of the maintainers
steps in, there is little chance anything will happen. And as
maintainers try to remain neutral they do not usually implement large
changes on their own.
There are also some technical difficulties:
For efficiency reasons Carto does not query the OSM database directly.
There are extra pre-computed tables and indices created to speed up the
rendering but historically any changes to these tables they were
difficult to deploy. The style itself consists of SQL queried sourcing
data from these tables and CSS stylesheets processing them on the way to
the Mapnik rasterizer. All three steps filter and manipulate data and
there are a lot of difficulties in keeping these elements of the
pipeline in sync (for example, querying lots of data only to have them
filtered out in CSS or Mapnik is very inefficient) or even within each
step (a lot of OSM elements have multiple, often conflicting tags and
they are considered in parallel).
Other limitations are:
- Imperfect support for relations (the code operating on points/ways
does not see which relation it originated from, everything has to be
done top-down)
- The style is global, which mean it does not adapts to regional tagging
conventions. Because it is mostly developed by "Western" contributors it
ends up reflecting their view of the world and OSM. This is not done
deliberately, it is just a result of social and technical dynamics
described above.
- Mercator projection - the main issue here is the "zoom level", which
is a key inputs for selecting and filtering objects. However, the same
zoom level means very different things in Norway and in Singapore.
Again, the map is optimized for European/US latitudes.
- OSM data do not provide enough information on how prominent objects
are. A small object in the middle of the field can by a landmark, yet in
the middle of city centers we want to be much more selective. There are
some heuristics based on tag types and some auxiliary information (area)
but for the most part Carto dumps all the objects at Mapnik and asks it
to display them randomly based on rendering order and area constraints.
Best,
-ndrw
On 31/05/2022 22:59, Włodzimierz Bartczak wrote:
> Dear board members,
>
> it has come to my attention that many community members feel that
> openstreetmap-carto is stagnating. Some feel that there is no vision, no
> project goals, and that maintainers don't care about the community
> instead trying to follow their own agendas. I am concerned that it may
> negatively impact long term health of the project.
>
> As the first/default style that is visible on https://openstreetmap.org
> <https://openstreetmap.org/> openstreetmap-carto can be considered one
> of core OpenStreetMap projects. While it may not be as important as the
> backend API and database it is the first thing that anyone going to
> OSM's site sees. It is therefore of great interest to the entire project
> that the style is maintained and community is involved and proud of the
> results.
>
> OpenStreetMap grew as a project and right now it is one of the largest
> open datasets of geospatial data. Many researchers as well as companies
> from startups to FAANG rely on OSM. There are more mappers than ever.
>
> For a very long time it was all serviced by volunteers but with that
> growth there is a need for more time and professionalism from
> maintainers. As the project grows so does the responsibility. We know
> that OSM Foundation is trying to help by e.g. hiring new SRE, hiring iD
> developer, organizing committees and working groups, creating grant
> programmes.
>
> I believe that openstreetmap-carto should at least get involved in
> Software dispute resolution panel and if possible start leveraging paid
> resources to help with maintenance and design.
>
> What was reported to us first was that one of our members tried to make
> a Pull Request
> <https://github.com/gravitystorm/openstreetmap-carto/pull/4512> adding
> rendering of some feature to the style and maintainers were hesitant to
> accept it even after extensive discussions and clear interest from the
> community. That in itself would not have been a cause for concern - not
> everything can/should be displayed on the map - but the last comments in
> the discussion turned to general issues with project maintainership and
> it was clear that many community members are dissatisfied with how
> openstreetmap-carto maintainers conduct the discussions and make
> decisions about the project.
>
> Most concerning however was the comment from swedneck
> <https://github.com/gravitystorm/openstreetmap-carto/pull/4512#issuecomment-1100642468> that
> one of openstreetmap-carto maintainers revealed information about him
> that he was not comfortable sharing (doxxing) and that nothing was done.
> Andy - openstreetmap-carto creator - was informed in another comment
> <https://github.com/gravitystorm/openstreetmap-carto/pull/4512#issuecomment-1101720910>and
> ignored it. The issue was raised on OpenStreetMap discord
> <https://discord.com/channels/413070382636072960/787125151959351307/966810172330745926> where
> Amanda - board member - saw it but claimed that carto's Code of Conduct
> does not list that doxxing is explicitly forbidden. This is very
> disappointing as it damages community's trust in the project. Since then
> another maintainer Mateusz corrected that some actions were taken but
> this generated a comment only after I made diary entry
> <https://www.openstreetmap.org/user/Cristoffs/diary/399189> that
> elicited 46 comments making some noise within the community.
>
> Problems with openstreetmap-carto were raised in discord
> <https://discord.com/channels/413070382636072960/787125151959351307/966745293276217345>and
> again many community members expressed that the project is not very
> receptive to feedback. In one of threads for Question Of The Week event
> moderator asked what would the community like to change about
> openstreetmap-carto and the first response
> <https://discord.com/channels/413070382636072960/965526689411129344/965536544381370398> it
> was proposed that maintainers should be replaced. This response received
> seventeen "+1" reactions.
>
> It's clear that there are many people disappointed with the current
> state of affairs which for such an important project is concerning. I
> don't think geospatial data can be disassociated from a map. OSMF
> choosing to focus only on database/API and editors is not enough in my
> opinion.
>
> I hope this message will open discussion and meaningful actions can be
> taken to restore community's faith that their input is valued in the
> project.
>
> --
>
> Włodzimierz Bartczak
>
> wiceprezes zarządu
>
> mobile: +48 608 497 044
>
> skype:live: wzbartczak <https://join.skype.com/invite/aFmhghAmPAVI>
>
> Stowarzyszenie OpenStreetMap Polska
>
> ul. Piotrkowska 28 lok. 2U, 90-269 Łódź
>
> REGON: 101078372 KRS: 0000385002 NIP: 7272776770
>
> www.openstreetmap.org.pl <http://www.openstreetmap.org.pl/>
>
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
More information about the talk
mailing list