openstreetmap-carto 🚀 - Guidelines for adding new features

I also think this will be hard to reach general agreement, but anyway the problem is worth discussing.

We have different backgrounds for a start - for example you're the lead developer of the whole style (and not only this one), so you tend to see universal things, while I work mainly as a micromapper, so I see the world mainly through the z17+ zoom levels.

For me even the most crowded POI space according to some mappers is just mildly saturated with informations on z19 with a big hole in the center (and I see missing icon for Fired Earth shop, because the name tells me nothing, while we have needed info in our database). But on the other hand I don't remember this style may be used on other servers and for other purposes than only main OSM website.

This is not a bad thing per se - quite the reverse: I thing it's rather healthy. The more different people, the more chance to strike the balance. That makes everything much harder and longer, but that's the price of trying to do the best we can.

I would ask some questions before we start drawing the lines:

What are the most important goals of general map?

I would say it should show the things common people wants to find (and the most visible things, especially on micromapping level). On the lowest levels that would be physical view and readable country borders and names, with capitals visible early enough, on the medium level that could be readable roads, cities, touristic attractions, the borders of campuses and many other institutions and nature forms (IMO we excel at this and are still getting better, unlike on the lower and higher levels), and on the highest zoom levels that should be POIs (readable icon shapes and names when possible), highways shapes, trees, flower beds, overground pipelines and maybe even fire hydrants (red dot at z18+ is comparably important to black dot for bollard, which we have a lot by now). It's just a rough list, but I think you get the vision.

For me the rule of removing as much as we add may be the most correct at the medium level (however maybe that's too strict even there). For the lowest levels it's rather reworking things than adding/removing anything, and for the highest levels there's a lot of essential things which are not visible yet, so I hardly see the need to remove anything for now.

The numbers on Taginfo is one thing, but what about Wiki status? If we don't take the numbers blindly, maybe we should somehow look also if the tagging is "deprecated", "approved" or "de facto"?

kocio-pl on 3 Jul 2015

For every new feature added, (at least) one feature is removed

For any feature to be considered for this style, it must already be on one other osm.org front-page style

I would be for following the first - not necessarily in a strict 'quid pro quo' sense but strongly suggesting that anyone who suggests or creates PRs for adding new features should also make similar contributions w.r.t. removing.

But i would be strictly against the second. This is a typical 'preserving the status quo for the sake of conservation itself' rule. Innovation and progress need to start somewhere and since the standard style is the only one that is based on at least partly democratic control and does not have a strict thematic focus this rule - when obeyed strictly - will seriously cripple the ability to develop the style in a way that reflects mapping priorities in OSM.

In general i think formal rules are not very beneficial in this context, especially since people tend to read them the other way round - like if i create a PR that adds a feature that is already shown in another map and removes another one it will have to be accepted.

It seems to me that much of this matter is centered around POI icons which make up a large portion of recent PRs. I think these are a special case in the much broader field of map design in general and many of the problems here are related to the technical constraints that currently exist. Let's not implement global rules on map design just based in this specialized matter. In general improving readability of the map has often very little to do with how many types of features are shown but with how they are shown (and POI icons are often simply a fairly wasteful way of showing things).

Instead of a set of rules/guidelines i would create a checklist of questions that are to be considered to decide if a new feature is to be rendered. What comes to mind here is:

is the tagging to be rendered the established tagging in OSM for this kind of feature, i.e. are there no competing tags?
is use of this tag reasonably widespread compared to the occurrence of features that could be tagged, in particular consider the geographic distribution of features and the number of mappers using it?
is the quality of mapping of this type of feature sufficiently high on average (like accuracy of position and level of detail and accuracy of the geometry)?
is the meaning of the tagging sufficiently clearly defined and documented on the wiki?
is the feature itself of sufficient interest for the average map user to deserve being shown?
is the average map user sufficiently familiar with the nature of the feature to understand it at least with the help of a map key?
is what distinguishes this feature from other similar features that are either already rendered or not rendered but tagged differently sufficiently clear to the average map user?
is this feature in distinct form shown in some other kind of map (not necessarily OSM based, not necessarily digital)?
is it feasible to render the feature together with other similar features in a common styling?
could the feature be rendered as a styling variation of another feature that is already in the style instead of being rendered as a separate map element?
does the proposed styling work reasonably well on all zoom levels it is shown in all regions the feature occurs in?
does the suggested styling well represent differences and similarities to other features rendered?

The answers to these questions of course depend on your point of view, such list would not have the purpose of making the decision for you, it would be a helper for those in a position of making the decision (making a PR or merging a PR) and you could use your detailed answers to these questions to support your decisions.

And i said before and will repeat here: One of the most important aspects of style development i see much too little here is the critical review of changes after they have been rolled out. This in particular applies to the addition of new features.

imagico on 3 Jul 2015

@gravitystorm

For every new feature added, (at least) one feature is removed

I agree that we are at point where removing features may be better than adding more - for example in my road redesign I decided to display highway=motorway and highway=trunk using nearly the same style (I am copying it from Humanitarian style, the only planned difference is zoom level where road appears). I also want to get rid of highway=proposed.

Though it would be tricky to define how features are counted. 100 shop types displayed as a purple dot - is it a single feature or 100 (my bet that it is single)? Lets say that there are 27 road types that may be displayed with red dashes or not marking whatever road is private. Is it 54 features or 28? 27 road types where each may be private/public and paved/unpaved. Method for displaying access and surface status is the same across roads. Is it 29 features or 108? I think that it would not work as hard rule, but "removing features is not only acceptable but also welcomed" guideline would be great.

Also, features are not equal. Displaying shop=toys and shop=kiosk differently has lower impact than displaying highway=motorway and highway=trunk differently. Different icons for shops are quickly increasing number of features - but impact of making map more confusing is not high as these shop icons are quite intuitive. And in the worst case icon colour should make it clear that it is some kind of shop. Impact of #1239, #775 or #720 would be much more significant (as measured by increasing complexity of map) than one more shop icon. My feeling is that removing highway=proposed and adding 50 new shop icons would be balanced.

Basically, numbers-of-features based rules aren't usable. Just because there are millions of X doesn't mean we should put them on this map style. And just because only a few hundred Y have been mapped doesn't make them unsuitable.

I think that any request for rendering tag with less than 1000 occurrences and without really good explanation why it should be exempt from this rule may be rejected without discussion. "not used widely, therefore no rendering" allows to close majority of requests for new features without pointless discussion. It is especially helpful as it is common that people proposing to render rare tags are ready to debate endlessly. For example in case of #1239 effort to discuss, implement and test rendering is greater than effort that was needed to map existing occurrences of that tag.

And what may be a good explanation - for example one for rendering natural=shingle from #1217 ("In the code you can see that i included natural=shingle to be rendered like natural=scree to avoid mappers feeling additionally inclined to tag natural=scree despite this being technically wrong."). capital=yes would be clearly exempt as useful tag to describe really rare feature. But "this tag should be promoted" is not a good reason.

For any feature to be considered for this style, it must already be on one other osm.org front-page style

I would expand it to "style with rendering for the whole planet, updated at least once a month". That would include for example French-style renderer.

matkoniecz on 3 Jul 2015

2015-07-03 16:01 GMT+02:00 Christoph Hormann [email protected]:

For every new feature added, (at least) one feature is removed

For any feature to be considered for this style, it must already be
on one other osm.org front-page style

I would be for following the first - not necessarily in a strict 'quid
pro quo' sense but strongly suggesting that anyone who suggests or creates
PRs for adding new features should also make similar contributions w.r.t.
removing.

+1, sounds reasonable. Making the removal a hard requirement might lead to
nonsense for the sake of following the rules.

But i would be strictly against the second. This is a typical 'preserving

the status quo for the sake of conservation itself' rule. Innovation and
progress need to start somewhere and since the standard style is the only
one that is based on at least partly democratic control and does not have a
strict thematic focus this rule - when obeyed strictly - will seriously
cripple the ability to develop the style in a way that reflects mapping
priorities in OSM.

+1, it is also somehow arbitrary what is showcased on the front page, and
there are requirements like global availability that reduce the number of
potential new maps there mostly to people doing business with OSM (because
of the required ressources to offer an up to date global rendering that can
cope with the number of requests from osm.org).

Generally we should keep in mind that this is the main style of a global
project, and that the project is likely still "young" in a certain sense.
"We" are naturally already biased towards the "western world" and under the
influence of western culture / point of view (inevitably, just have a look
where we come from and where "we" live), and so are all our maps on the
front page (incl. HOT). With this requirement we would make this situation
even less changeable / open to changes that don't fit into or a needed in
the western world (and often don't matter because the features in questions
don't happen to occur in the western world).

In general i think formal rules are not very beneficial in this context,

+1

dieterdreist on 3 Jul 2015

Basically, numbers-of-features based rules aren't usable. Just because there are millions of X doesn't mean we should put them on this map style. And just because only a few hundred Y have been mapped doesn't make them unsuitable.

While I agree that they aren't always suitable, for shop and similar POIs where we have a generic fallback, I think it's a reasonable first pass.

More throughts from me later

pnorman on 3 Jul 2015

Definitely agree with the general idea. Really like the idea to use rendering questions as a means to improve documentation as @imagico seemed to suggest.
It might make sense to introduce some kind of pop poll for suggesting additions and removals. Then popular slots for addition could be freed up only if and when some removal suggestion reaches critical mass.This would avoid having to devise logical rules, and would just leave it to the community.

joostschouppe on 4 Jul 2015

Also, features are not equal. Displaying shop=toys and shop=kiosk differently has lower impact than displaying highway=motorway and highway=trunk differently. Different icons for shops are quickly increasing number of features - but impact of making map more confusing is not high as these shop icons are quite intuitive. And in the worst case icon colour should make it clear that it is some kind of shop. Impact of #1239, #775 or #720 would be much more significant (as measured by increasing complexity of map) than one more shop icon. My feeling is that removing highway=proposed and adding 50 new shop icons would be balanced.

While I agree with this conclusion, it reminds me of important hint we should consider crafting (not just adding or removing) any feature on the map:

Mind the scale.

The most general scale guide would be like:

Big scale - worldwide features, mainly natural ones (like continents and the oceans), but also country borders and capitals.
Medium scale - roughly speaking: anything from country to city level.
Small scale - anything from part of the city to street/building level (so called micromapping).

They are different beasts, really: most important big scale objects are areas, most important small scale objects are points, and medium scale is associated mainly with lines (however there is also mix of important areas and points involved).

Now - we tend to focus on medium scale and see virtually every feature through these "lenses". However the impact of displaying highway=motorway and highway=trunk differently is far less on both extremes than:

displaying the country borders differently than state/province borders or showing as many capitals and country names as it's possible (on the big scale)
displaying one kind of the shop differently than the others or displaying the real shapes of highways (on the small scale).

We may even treat the medium scale as a special case and take more care of it, but if something is less visible or just doesn't belong there, we should - metaphorically speaking - change our regular glasses for telescope or microscope, respectively.

kocio-pl on 5 Jul 2015

Instead of a set of rules/guidelines i would create a checklist of questions that are to be considered to decide if a new feature is to be rendered. What comes to mind here is:

My point about using other styles as a yardstick is to avoid exactly this outcome. You've listed 12 perfectly reasonable points that should be considered, but you're advocating that all those decisions should be made in this one style in this one repository. But we're already overwhelmed by conversation, and I'm trying to diffuse the amount of work and angst that goes into this style, not increase it further.

If you're unhappy about the number of styles on the front page, then we should either solve that (by increasing the number of styles) or change the rule (to include a wider acceptance criteria, as @matkoniecz suggested). But openstreetmap-carto will probably collapse under the weight of discussion if we need to go into such depths ourselves. I would like to expand this scrutiny effort, using the distributed knowledge of all the other people working on their own renderings, not just concentrate everything here.

gravitystorm on 6 Jul 2015

My suggestion was not meant to advocate more discussion. It is meant as a helper for (a) contributors to check their requests for adding new features to be viable before making them and therefore avoiding fruitless discussion and (b) style maintainers to make fast yet transparent decisions on closing issues/rejecting PRs without a pointless discussion.

I completely understand your desire to keep style development here focused on the important things and avoid the style degenerating in quality and readability - i just don't think this particular regulation would have a positive effect.

One thing that aggravates the problem of excessive unproductive discussions here is that there is no forum for generic OSM map styling discussion elsewhere. A lot of discussions started here are on a fairly generic level that is not really suited for this place. Discussions on how a certain POI tag can in principle be visualized with an icon for example are something not specific to this style and could IMO be separated from actual style development. Managing discussion here in a way that decidedly directs subjects on a level that is not specific to this style to a different place would help a lot. This certainly covers a lot of new feature discussions. If on the other hand someone has a concrete plan how a certain new feature could be shown in this style based on extensive research into the possibilities and suggests this here it would IMO be very bad if he/she would be turned down based on the formal argument that this feature is not shown in any other qualified OSM map without considering the merits of the suggestion itself.

I would like to expand this scrutiny effort, using the distributed knowledge of all the other people working on their own renderings, not just concentrate everything here.

That is a good idea, if however you put the barrier that high (for example like @matkoniecz: global maps with regular updates) the primary effect would be removing a possibility for style developers to contribute to OSM when new features are involved, especially those with limited ressources (who cannot run their own global map) and those not from regions with a large and well organized local community who have their own local focus style (like in Germany or France).

imagico on 6 Jul 2015

A problem: There is no truly "open" rendering style in OpenStreetMap. The database is open: people can and do add whatever they want. There's no equivalent on the rendering side: renderings are like castles with moats, with the hordes massing outside banging on the gates. The maintainers inside protecting the integrity of the rendering, and the masses outside complaining, are a hard dynamic for everyone.

The way out may be more top level maps, including a true _"bagel with everything"_ approach map with few rules, another new map focused explicitly on motorists, and an open community version of cycling, public transport and political maps. Organize this all on a new mailing list called [email protected], so osm-carto does not become the only focal point for discussion debate, hopes and dreams. Offer a mix of "curated" maps created with the integrity of a single voice (such as OpenCycleMap), and "open" maps created via a messier process.

@gravitystorm "For every new feature added, (at least) one feature is removed" is a particularly moat-like rule that ignores the fact that rendering is not a zero sum game. A small community could get it's feature rendered with little to zero impact on anyone else. Deciding to render trees or fire hydrants or road signs is a big deal, because there are so many. Other features (and here "motorhome toilet dump stations" or "farm product stands" come to mind) have essentially zero impact on anyone else, because they are located in areas that are otherwise empty on the map. Very close to exactly nobody is overwhelmed by clutter for such items, as there is no clutter.

brycenesbitt on 6 Jul 2015

👍2 ❤1

@gravitystorm I'm happy you started this discussion. My point of view:

For every new feature added, (at least) one feature is removed
For any feature to be considered for this style, it must already be on one other osm.org front-page style

I don't think I'd be personally in favour of either of these guidelines.

the map style will show hundreds of thousands of different things, and that's not tenable.

I think we can distinguish three (related but distinct) issues here:

displaying too many different features
using too many different symbols
displaying those symbols on too early zoom levels

@gravitystorm Which of these do you think are problems with our style?

In my opinion the problem is 3., and a bit of 2. I don't think 1. is a problem.

For example, rendering things like hackerspaces would be no problem to me at all if we render them with text only (no icon, addressing 2), and render them only on high zoom levels (addressing 3).

It stops being a map and is just a complex, unreadable, useless and ugly visualisation of the database.

I think that's the core issue. We do really bad at the issues you mention. I would expect though that we can do a lot by simply changing minimum zoom levels, and maybe even by toning down colours.

I think having concrete examples makes things easier to discuss.
@gravitystorm, what do you think of the example given by @kocio-pl? Too me on z19 the map is readable, useful and not terribly ugly. Would you prefer a reduction in the number of different icons, of even a reduction in the number of different displayed POI, here too?

matthijsmelissen on 7 Jul 2015

@brycenesbitt +1

I like the democratic, open aspect of this style very much, even if it's limited by many aspects. But I hate feeling like a "hordes agent" (?) inside the castle, just because I want to try some things rather than just keep the house tidy. I would be happy to work with some "development"/"working"/"for mappers" version of this style (less strict, with more features and testing stuff), but when I recently asked if new hardware donations could be used for this, @pnorman said it won't.

We definitely should have some place to talk about more general things related to rendering. Mailing list or maybe subforum on OSM forum would be easy to set. This alone could not resolve the problem of "open" rendering style, of course (talking without a chance of getting the real output will be harsh exercise in frustration), but that would be a good start.

The big question is how to make the rendering in OSM more open, collaborative process in a peaceful way, without anybody feeling ignored or being under pressure.

kocio-pl on 7 Jul 2015

I have two guidelines that I'd like to see implemented:

For every new feature added, (at least) one feature is removed
For any feature to be considered for this style, it must already be on one other osm.org front-page style

The style is currently in a place where removing features is more valuable than adding them, but I'm not sure that this is the most effective way reign this issue in. On the other hand, I don't really have an alternative suggestion.

I get the feeling that some people view this style as an OpenStreetMap project to design a style for osm.org. I do not consider it that. I consider it a project started by Andy for a style that shows off OSM data, and which is shown on osm.org. I have an interest in the latter, I would probably contribute much less to the former. Remember, Andy chose to put this project under @gravitystorm, not @openstreetmap.

Part of showing off OSM data is good cartography. Part of good cartography is being selective in what to render, which means not continually adding new features to the map.

pnorman on 7 Jul 2015

sent from a phone

Am 07.07.2015 um 10:32 schrieb Paul Norman [email protected]:

I consider it a project started by Andy for a style that shows off OSM data, and which is shown on osm.org.

this is not a project started by Andy AFAIK, but the continuation of _the_ OpenStreetMap main map (mapnik, the former "Chilton"-style), the only one published on osm.org that is generated with OSM(F) resources.

dieterdreist on 7 Jul 2015

Part of good cartography is being selective in what to render, which means not continually adding new features to the map.

Do you have any concrete suggestions of features that you'd prefer not to render?

matthijsmelissen on 7 Jul 2015

@pnorman - yes, this is Andy's project but being the style that is rendered on the main OSMF infrastructure comes with responsibilities to fairly deal with the wishes from the community. The OSM community needs to have a say in what is rendered on the project infrastructure and what is featured as the main map on the project website. Allowing everyone to directly edit the style would not work of course, so this influence has to be indirect. The current construct with a group of style maintainers responsible for channeling and structuring the requests and suggestions seems to work quite well though. (slight critique here: style maintainers currently all have a fairly technical background and approach to things. This is natural to some extent - merging pull requests and reviewing changes in a primarily technical task. But a more cartographic/geographic view of things can be helpful sometimes. I am not saying this needs to be changed or even that it could be changed, just an observation).

@math1985 - the primary problem about POIs IMO is the lack of a reliable prioritization system. As soon as not all POIs can be shown selection gets arbitrary.

And yes, there are areas where z=19 is overcrowded with POI icons or at least would be if those were fully mapped in these areas:

http://www.openstreetmap.org/#map=19/38.71272/-9.13924
http://www.openstreetmap.org/#map=19/1.29943/103.85460

I for one think one of the most pressing needs in this style is improving overall consistency in styling - features that are similar in reality should be similar in rendering and things that are different should be shown differently. This is often not the case currently but it is very hard to to improve since even small changes in styling can have enormous side effects on the overall look and readability. It is much easier to just add a new feature than to change existing styling without causing a mess. This is probably one of the main causes of feature creep here.

Maybe it would be a good idea to open a new separate issue to collect some ideas for what features could be well removed from the style.

imagico on 7 Jul 2015

Remember, Andy chose to put this project under @gravitystorm, not @openstreetmap.

I guess this is exactly where most of the tension comes from: the "private" style (designed mostly by few people with strong opinion how should it look like) being default visualisation for the community project. This community is rapidly growing, so I think the clash is unavoidable.

And this is not so clear from the beginning: the license is open, the GitHub makes participation easy, and there are many leaders in FLOSS world, so using private namespace for the project may suggest just the strong leadership. Nothing besides that really warns that you are on kind of the "private" ground and while the leaders are polite, they don't really like being "leaders" at all - they have their own clear vision and just allow others to participate to some extent.

Part of showing off OSM data is good cartography. Part of good cartography is being selective in what to render, which means not continually adding new features to the map.

I understand it. But on the other hand - part of community GIS project is having community influence on all parts of the process.

Try to imagine Wikipedia with lot of people writing things as they like it ("any tags you like"), but what gets showed at the main website are only some featured articles carefully selected by the few "super-editors". Some other thematic selections can be found, but most articles are not shown even if they could be, just because super-editors think the readers would be overwhelmed - no other encyclopaedia contains so detailed articles, anyway, so what's the problem?

Even Wikipedia has some limits what it can contain and what are formal requirements, but if it conforms these general rules, nobody limits it anymore - all the articles are visible.

kocio-pl on 7 Jul 2015

One thing that is really missing in this discussion is the option of the real time creation of "toggable" on/off thematic overlay layers of certain types of objects on the OpenStreetMap Rails web application via Overpass turbo API calls instead of trying to pre-render everything in a style.

This would circumvent the impossible task of trying to display everything, as @gravitystorm justly points out.

This would allow dedicated, specialized thematic rendering, without cluttering up the base map.

There are several existing implementations of this already, but unfortunately, on websites separate from the main Rails web application, and therefore not found or known by the average user. A good example is Marc Zoutendijk's OpenPoiMap:

http://openpoimap.org/

I really think adding such an option to the main Rails application, would lessen the burden on carto and other styles displayed on the main website, and potentially sharply reduce the number of requests for features being rendered.

Of course, this is not a solution for all types of objects, especially the ones needing layered rendering, but POI icons are a definite candidate.

mboeringa on 7 Jul 2015

Nothing besides that really warns that you are on kind of the "private" ground and while the leaders are polite, they don't really like being "leaders" at all

This is quite insulting, but I'm not sure if you are aware of how much so? I mean, I find this DEEPLY insulting.

I put a lot of effort into the initial port, and I made sure that the whole project - not just the code - was open to other people to get involved. I've built a whole team here: I've added multiple maintainers - all of whom have the same authority as I do - and we've accepted pull requests from many different people and put a whole ton of effort into helping dozens of new people - including you - get started, learn how things work, get your changes processed and incorporated. But you boldly state that this is still a "private" project with insufficient "community influence"?

And you make these statements on a thread where I've taken one of your complaints and instead of just decreeing new rules I even open things up for discussion and stated "we should come to a collective decision"?

Really?

gravitystorm on 7 Jul 2015

"private" ground

It is enough to check what is the proportion of proposed pull requests to rejected to see that it is really far away from truth https://github.com/gravitystorm/openstreetmap-carto/pulls?q=is%3Apr+is%3Aclosed And note that many marked as rejected by Github were merged manually or included in other PR.

matkoniecz on 7 Jul 2015

sent from a phone

Am 07.07.2015 um 12:43 schrieb mboeringa [email protected]:

One thing that is really missing in this discussion is the option of the real time creation of "toggable" on/off thematic overlay layers of certain types of objects on the OpenStreetMap Rails web application via Overpass turbo API calls instead of trying to pre-render everything in a style.

this is really a different issue, useful for searching stuff, while prerendering them is the basis for _exploring_ the area (aka see "what it is like")

dieterdreist on 7 Jul 2015

This is quite insulting, but I'm not sure if you are aware of how much so? I mean, I find this DEEPLY insulting.

I am surprised... and I'm sorry. I still don't feel there was any rudeness involved, because I don't even see it as a personal problem and I don't look for anybody to blame for it.

I already remember one time you felt urged by me and angry because of this, while I had no slightest intention to make anybody feel bad - I was just trying to get some decision because nobody (including you) told anything. How rude is it to ask anybody to just _tell_ anything and discuss things? I didn't expect anyone will "do the work as I said" - "I have no time" or "I decided that I won't fix it" are also perfectly valid answers one can discuss further, if needed. But no answer at all in community project - how do you think a newbie like me feels trying to get to know anything at all? I can make my homework - it's not a shame when you have to learn - but no documentation, no rules and no answers makes learning hard experience, requiring a lot of patience, guessing and being very persistent. I don't like it this way - I prefer open disagreement over being quiet "just in case".

This time is no different: for the start, just to be VERY clear - I respect you personally, your work and your point of view, I just disagree with the degree of being conservative regarding to rendering. I may be totally wrong in how I see your attitude toward leadership - you may love this, I don't know! - but for me it doesn't really look like this. If I put the words between quotation marks and it's not quotation, it means "as if" - I just try to show the problem by comparing, not to judge you or anybody else! I even wrote _exactly_ what I mean by this: (designed mostly by few people with strong opinion how should it look like).

If you don't like the word and find it insulting, I can drop it and describe the problem I see in different words. I think the leadership of community project is HARD - it's "more like herding cats" (as Linus Torvalds said it once) and we all know how obedient cats are... I didn't claim you've done nothing important for this style and project - simply because I don't think this is the case at all! I just want to say the formal things (like the open license and so on) are not everything for a community project to be healthy. The feeling you're welcome and can speak in the open way and being taken seriously is also important part of it. Lack of some important answers (you never answered why you generally don't like more icons, even if it was not just me who asked - at least I'm not aware of it) is not nice, nor constructive. Even in this thread @math1985 asked you personally a few questions, which are important to resolve some things - but unfortunately you omitted them again and instead answered me...

It may be hard to measure the effect of collaborative atmosphere, but let's look how many people are involved in mapping, how many discussion you can find on mailing lists about crafting the right tagging, and how many people discuss the rendering here. Of course, there are more technical difficulties when dealing directly with the code, but I believe if everybody get the message "you can also learn to code or even just discuss the rendering", there would be much more people involved, because many people care for rendering even more than for tagging. Yet they tend to tag for renderer rather than complain here. For me it's at least telling us something. And THIS shows the core of the problem for me - do you see it also?

I'm very happy you started this thread/issue and appreciate it a lot. I also try my best to not make things personal when the problem lies somewhere else IMO - and even this is not enough sometimes, because I clearly failed at showing it the way I really see it, so sorry once again, Andy. Please, try to answer more questions and show us more of the reasons you believe are true, because I see no other way to resolve general problems we have.

kocio-pl on 7 Jul 2015

@imagico

And yes, there are areas where z=19 is overcrowded with POI icons or at least would be if those were fully mapped in these areas:

http://www.openstreetmap.org/#map=19/38.71272/-9.13924
http://www.openstreetmap.org/#map=19/1.29943/103.85460

Most of big cities in the world will have a lot of shops, but now there are only some places well micromapped and I consider the issue the problem of tomorrow. And even then they will be crowded, but still well readable (so not "overcrowded" in my view) - you have showed probably the highest physically possible density of shops in the city (excluding some marketplaces, I guess), so it won't be worse than that at the highest zoom levels.

There are some things unreadable and overcrowded in the middle scale, however. If we should start with cleaning this style, I would start here for sure. The main roads should be much better soon, thanks to the work of @matkoniecz, but the only other things you can recognize there, are the sea/ocean, airports and city names. It's just much worse than anything related to POIs I ever saw!

But if we remove anything mainly/just to make the most dense places look better, we will hide some things in many more less dense places. The former ones are just a small percent of the latter ones, so effectively we will loose more than we will gain this way.

kocio-pl on 7 Jul 2015

@kocio-pl , it sounds as if you would like _more_ leadership, i.e. more rules or decisions from Andy? Or do you just want to hear his opinion more?
I think this repo works quite well at the moment, especially since more people have stepped forward as maintainers to share the burden and the workload. Andy is a "leader", but not the only one here, and he's certainly not imposing his will above everybody else.
Of course there are some issues that have been open long. But I think that's mostly because everybody here is doing this on their free time, and can't look at all the issues at once. I don't think any issue will be forgotten.

daganzdaanda on 7 Jul 2015

Back on topic:
I agree with most of what @imagico wrote.
Something like his checklist could be used to remind people of what a good addition should bring to the style."Scoring" low on that checklist should be the main reason to say no to a new addition.
If something has been proven to work in any other multi-purpose style, that should be a plus point, but not a reason to automatically copy the feature into carto.
Also, he is right about reminding us to review changes after roll-out. But if something throws up new problems, we usually catch them on the second try.

About icons:
I don't see many different icons as a problem. It's definitely better to have the icons than just a dot or the housenumber as before. In very dense situations I'd like to see a z20 someday, or density-based rules. But until then, the one thing that bugs me more is that very high dx between generic dot and Label. I'll open an issue about that.

daganzdaanda on 7 Jul 2015

this is not a project started by Andy AFAIK, but the continuation of _the_ OpenStreetMap main map (mapnik, the former "Chilton"-style), the only one published on osm.org that is generated with OSM(F) resources.

This isn't quite accurate - I know it's nitpicking, but it's important to get right. This is a fork of the "Chilton" style and obviously shows that great cartographic heritage. But I chose to use a different technology, different code hosting, a different way of working (via pull requests) and managing things (i.e. a team of maintainers), and I made new goals for this project, for example reusability of the stylesheets in other forks. This project was running for many months independently, before it also became the default cartography on osm.org

The OSMF is free to choose whatever stylesheets it likes to run on its hardware. It currently runs one style, and it currently runs this one. But at some point there will be a better option, and things will move on again, and a different style will be the default. Compare with the default online editor, for example - there have now been at least four. For the map styles, there have been at least three, if you count white-lines-on-landsat.

I feel that being the default stylesheet does come with responsibilities towards the wider OSM community, and I certainly bear those in mind (e.g. mapper feedback loop), but I wouldn't go as far as to say we're obliged to do things that we disagree with, even if they are popular with non-contributors. For this project, the final decisions are with the maintainers.

Of course the lines between "this project" and the wider community are deliberately blurred - just see my presentations, the workshops that we've run, the ability for anyone to comment or to make PRs! Even the choice of maintainers is open and flexible.

gravitystorm on 7 Jul 2015

displaying too many different features

using too many different symbols

displaying those symbols on too early zoom levels

@gravitystorm Which of these do you think are problems with our style?

is the biggest problem for me. A map becomes incomprehensible when it is too complicated or requires too much learning to make use of. Even I struggle to recognise features from our map due to the complexity of what we try to show - http://www.openstreetmap.org/#map=18/51.50275/0.00323 showing a wide grey line with white dashes confused me for a while this morning, and I resorted to using the query tool to figure out what the feature actually was.

It's also a burden when we're trying to change things. For example, by showing so many different landuse colours, when we want to change the building colours there's a big list of things to consider. It's not the best example, but I want to make sure people are aware that there is a non-zero burden on stylesheet development for every feature that is added to the style. It's not like we merge the PR and then there's no other consequences.

Is the second biggest problem. Having so many different icons makes it hard to read the map, since in crowded areas they all need viewing to figure out what they are and it's a huge list of things to (subconsciously) re-recognise when you pan the map around. Having a mixture of a few icons and generic symbols was my preferred approach, but I realise that most people preferred lots of icons so we've gone with that approach. It doesn't mean that I like it though :-)
is not a big problem, since it's easily solved. So this is why I'm focussed on the first two issues.

gravitystorm on 7 Jul 2015

Andy is a "leader", but not the only one here, and he's certainly not imposing his will above everybody else.

I've been trying _really_ hard not to impose my will here over the last few years. I know that I could, since making all the decisions myself works for my other map styles! But a big part of what is important to me is to make this a collaborative project rather than just "Andy's style". So in a lot of discussions I take a back seat, or keep out of it entirely, or wait for a while to see what other people are thinking before I give my own opinions.

i.e. more rules or decisions from Andy? Or do you just want to hear his opinion more?

Good questions.

gravitystorm on 7 Jul 2015

by showing so many different landuse colours, when we want to change the building colours there's a big list of things to consider

I may confirm that it is a problem. For example it is surprisingly hard to find road colours that will ensure that (a) road is clearly visible across all possible backgrounds (b) rendering is not terrible.

matkoniecz on 7 Jul 2015

I've been trying really hard not to impose my will here over the last few years. I know that I could, since making all the decisions myself works for my other map styles!

This is a stance that cannot be valued highly enough. Letting things happen is not easy, I'm not sure if I would be capable of that. Kudos also for opening Pandora's box once again and trying to hear people's opinions instead of just changing things. I suggest to watch Andy's talk at SOTM US on YouTube if you haven't done so yet.

Creating a map style is really really hard work. I tried it on a public transport style from scratch, which will be open if I ever finish it. Such a style omits a lot which this style doesn't. Still, at the beginning I was completely overwhelmed by the complexity of the features and the zoom levels. Getting a coherent representation is quite hard and having a design background initially doesn't help much as I discovered. Still I can only recommend to try it.

I think that democratically or procedurally working out which features to add and which not won't work, but I'm happy to be proven wrong. IMO a style cannot be a democracy as design cannot be really a democratic process. But a number of styles could benefit from each other and evolve together. So it would be better not to give this style a "constitution", but do democratize styles in general which is out of scope of this discussion.

Still, that would require increasing the number of available open styles (on osm.org?). Rendering capacity is an important bottleneck here, but maybe a vector tile stack could solve that in some years. Then it might be also possible to split responsibilities for the mapper feedback loop and the first impression on osm.org into two styles, which also would ease things a bit.

nebulon42 on 7 Jul 2015

@daganzdaanda

@kocio-pl , it sounds as if you would like more leadership, i.e. more rules or decisions from Andy? Or do you just want to hear his opinion more?

Basically, I want to know better what's going on: what are the decisions and the reasons and when decision maker(s) simply abstain or just don't have the resources. I don't care if we call better communication to be "more" or "less" leadership - it would be just better.

Andy is a "leader", but not the only one here, and he's certainly not imposing his will above everybody else.

Of course, I see that he trusts some people and lets me play here too. But I still don't know who decides and to what extent. The repo's owner has the last say on everything? Or maybe all the people with write access decide on their own? Since there are not many more people involved, I can't see how the rest of the community can influence this process, but that is interesting for me too (I'm one of them).

This thread helps me get the picture now, but as we see - these are not straightforward things if one has to explain them at all.

Of course there are some issues that have been open long. But I think that's mostly because everybody here is doing this on their free time, and can't look at all the issues at once. I don't think any issue will be forgotten.

When I think so or I don't care, I just leave such issue as it is. But when I'm not sure or I just think it is really forgotten or got stucked, I try to bring it back on the table. It means that I'm willing to help to resolve it. This is the best moment when somebody might say "I have no time for this, but would like to..." or "nobody cares, so do as you like, if you can".

But if I want something, the repo's owner says he doesn't like it and stops communicating after that, I don't know what to do... I can risk and try to do what I like (and that was what I really did it), but I also do it on my free time, so I'd rather know how big is the risk I take, before I made - say - 99% of the hard work only to be trashed eventually.

It doesn't have to be personal decisions every time, though. If there are some known rules, I would use them happily and just look for some help in this process. But, this way or another, it should be clear for the people what's going on - who decides, what are the rules and how much power they have. The leader is the person who may not code too much, because there can be other coders, he can also let other people take the responsibility for some things (again - look at Linus today), but she should be good at connecting all these dots - and that means communicating and making things clear.

kocio-pl on 7 Jul 2015

it sounds as if you would like more leadership, i.e. more rules or decisions from Andy? Or do you just want to hear his opinion more?

I'd like more rules or decisions from Andy.

pnorman on 7 Jul 2015

A map becomes incomprehensible when it is too complicated or requires too much learning to make use of. Even I struggle to recognise features from our map due to the complexity of what we try to show - http://www.openstreetmap.org/#map=18/51.50275/0.00323 showing a wide grey line with white dashes confused me for a while this morning, and I resorted to using the query tool to figure out what the feature actually was.

Sure, I also could not recognize it and eventually I had to use this fallback... :smile: However if I see the shop dot with a name which is not clear, I would have to do it much more frequently to know what kind of shop it really is.

We've already crossed the limit of any reasonable amount of features - list of keys on Wiki page is not complete, yet the table of contents alone takes more than the whole screen on my computer! So we go the other route: colors have meaning and we craft the symbols to be easy to understand and consistent. That works for me even if I don't know all the symbols.

The example you gave is special because it's a complex rendering and we are simply not able to explain all the possibilities that can be (especially this rare). But at least it looks like a kind of road and this is the most important information there.

Let's think how big is our scope - not just the whole globe, not just many scales (from the Earth down to buildings), not even just a lot of data (more than mighty Google wants to touch), but also constantly growing list of tagging schemes. One can not rely on classic cartography entirely under these circumstances, because there was no such things before. Abandon all hope of resorting to keys, you who enter here...

It's also a burden when we're trying to change things. For example, by showing so many different landuse colours, when we want to change the building colours there's a big list of things to consider. It's not the best example, but I want to make sure people are aware that there is a non-zero burden on stylesheet development for every feature that is added to the style. It's not like we merge the PR and then there's no other consequences.

It's always good to know the costs. That's why we try to test and discuss PRs before merging. The unfortunate consequence is that the bar is even higher for anybody trying to modify the style, but we can't just assume everything will be OK. Here I agree with you fully.

Is the second biggest problem. Having so many different icons makes it hard to read the map, since in crowded areas they all need viewing to figure out what they are and it's a huge list of things to (subconsciously) re-recognise when you pan the map around. Having a mixture of a few icons and generic symbols was my preferred approach, but I realise that most people preferred lots of icons so we've gone with that approach. It doesn't mean that I like it though :-)

I haven't noticed such problem and I was not aware it exists at all - I just see the colors and know instantly "oh, that is some eat-and-drink area, so it's probably important part of this town" or "funny, this street has so many book stores!" - and so on.

is not a big problem, since it's easily solved. So this is why I'm focussed on the first two issues.

I don't like messing with zoom levels too much, because we should remember that those dense areas are quite rare and such a universal change will be worse for all the rest. Instead I think we should use as much dynamic solutions as possible - way_area for areas, minimal space between the points and don't-know-what-yet for lines.

kocio-pl on 8 Jul 2015

Additional line and area types are a presentation problem. Differences in line shading, color and pattern only go so far, especially since there's no good key or index.
Additional POI types I do not see as leading to a clutter problem. This is doubly true of things with a rendered name, and things like shop with a well defined color scheme.

The examples of "cluttered" areas given so far in this thread seem quite fine. Mostly, they're urban areas with shops. One shop icon per shop seems very very reasonable at the highest zoom. Would anyone suggest, say, skipping shop icons? The natural density of the area has to come into this. If there's a shop every 10 meters then OSM ought have an icon every 10 meters.

brycenesbitt on 8 Jul 2015

2015-07-07 19:48 GMT+02:00 Andy Allan [email protected]:

this is not a project started by Andy AFAIK, but the continuation of _the_
OpenStreetMap main map (mapnik, the former "Chilton"-style), the only one
published on osm.org that is generated with OSM(F) resources.

This isn't quite accurate - I know it's nitpicking, but it's important to
get right. This is a fork of the "Chilton" style and obviously shows that
great cartographic heritage. But I chose to use a different technology,
different code hosting, a different way of working (via pull requests) and
managing things (i.e. a team of maintainers), and I made new goals for this
project, for example reusability of the stylesheets in other forks. This
project was running for many months independently, before it also became
the default cartography on osm.org

Yes, sorry for misreprenting this, you are of course right, this is a fork
of the old mapnik style, this is using different technology at the upper
layers (carto instead of writing xml, github instead of svn and trac). On
the other hand, this work has replaced the old style and is used as the one
and only OSMF-OSM map on osm.org, so it stands in a continuity with the old
style and is the "official successor". People would likely contribute less
to this project if it was perceived as your private project and not
featured on the main site.

dieterdreist on 8 Jul 2015

This isn't quite accurate - I know it's nitpicking, but it's important to get right. This is a fork of the "Chilton" style and obviously shows that great cartographic heritage. But I chose to use a different technology, different code hosting, a different way of working (via pull requests) and managing things (i.e. a team of maintainers), and I made new goals for this project, for example reusability of the stylesheets in other forks. This project was running for many months independently, before it also became the default cartography on osm.org

I'd probably say that from a cartographic and management standpoint, it's a fork, going in different directions. From a code standpoint, it's a guided rewrite.

As someone who has contributed to both the old osm.xml style and OpenStreetMap Carto, the technical differences (git vs svn, github vs trac, carto vs XML) enable the different ways of project management and cartography.

so it stands in a continuity with the old
style and is the "official successor"

People may view it like that, but as Andy has pointed out, that's not what it is from a cartographic goal and project management perspective.

As a partial aside, personally, I look forwards to the day something else is deployed on tile.osm.org and the default on osm.org, because it means that there's something even better for showing off OSM. I also want to raise that bar higher and higher by improving what we have here.

pnorman on 8 Jul 2015

Should we have some discussion platform then - be it a mailing list or subforum - for subjects that are outside the scope of simple cartographic issues and meta-issues (project governing like community-developers communication and technical problems like POI overlays or separate development tree)? I think this would be useful.

kocio-pl on 8 Jul 2015

osm-carto has become THE place to discuss rendering. A new mailing list: [email protected] could be worth a shot to try and even out that discussion: putting other rendering on an equal footing to osm-carto, and relieving some of the pressure on osm-carto.

brycenesbitt on 9 Jul 2015

A rendering list would be interesting, but I fear it would be like tagging@ and not be particularly useful to those doing work. I doubt style developers would read it regularly in that case.

osm-carto has become THE place to discuss rendering

I wouldn't say so. Most of my general rendering discussions take place elsewhere, generally direct with individuals. There's also stackexchange, help.osm.org, IRC, and other venues. The repo is one of the more active place where rendering discussions happen as this is one of the most actively developed stylesheets, but only a subset of rendering topics are relevant here.

The purpose of the issue tracker is to work on OpenStreetMap Carto. If there's regularly discussion happening here that doesn't further those aims, then we - as maintainers and moderators - need to step in and bring it back on topic or if that doesn't work, close down the issues.

pnorman on 9 Jul 2015

Yes the tagging@ list has become an unproductive pit.
But that does not necessarily mean rendering@ would.

@pnorman your statement that "Most of my general rendering discussions take
place elsewhere, generally direct with individuals." highlights the point
that OSM rendering is controlled by a small subset of the community, in
stark contrast to the data collection and tagging.

Separately I feel that an unintended side effect of osm-carto's relatively
curated rendering, is that it holds OSM back from engaging with new mapping
communities. Anyone wishing to map a new feature in OSM has to jump
through insane hoops to get that work visible to the world.

brycenesbitt on 9 Jul 2015

@pnorman I think you're still talking about clearly defined osm-carto problems, but I've just asked what about "subjects that are outside the scope of simple cartographic issues and meta-issues". They simply don't belong here and this thread shows it's important for the people to talk about more general problems also (I rarely see 12 participants in issues discussion for this repo); and it's clearly community thing, not just something to discuss between individuals.

@brycenesbitt I think forum would be better, because I don't expect so much discussion and it would be also much easier to find this subforum and individual threads (you can pin those most universal, like "OSM rendering basics"). What do you think about this? Do you still prefer mailing list over subforum?

kocio-pl on 9 Jul 2015

I prefer forum.

jojo4u on 9 Jul 2015

I'm happy to see people discussing non-openstreetmap-carto topics, either on a mailing list or a forum, but it's unlikely that I would be personally involved in those discussions since that would mean even _less_ time for me to participate here! I would suggest, however, two things:

Try using an existing mailing list, rather than starting a new one. The existing osm dev mailing list would be a good place to start. When the lists have less than 20 people they tend to run out of steam.
Cartography is, in my opinion, best started and then discussed later. So if you think there should be another style, start it yourself, and show your work-in-progress. Or if you want interactive icons (or whatever) shown on the osm website, create a demo and then ask for help. Otherwise the discussion tends to attract people who are happy to talk but unlikely to actually do anything beyond that.

I realise this topic has itself gone massively off-track. I will now try to bring it back on-track in my next comment.

gravitystorm on 13 Jul 2015

I made two suggestions for rules to implement, and I've gone through this topic and tried to summarize the feelings of people towards them:

For every new feature added, (at least) one feature is removed

Pro: gravitystorm, imagico, matkoniecz, dieterdreist
Anti: kocio-pl, brycenesbitt, math1985

For any feature to be considered for this style, it must already be on one other osm.org front-page style

Pro: gravitystorm, matkoniecz
Anti: imagico, dieterdreist, math1985

So, not really a consensus either way. Does anyone else have specific guidelines they would like to put forward for consideration? If you aren't proposing a guideline, then for now please refrain from commenting.

gravitystorm on 13 Jul 2015

For the second rule you can count me in @imagico camp (he summarized it right). But I don't have any guidelines to offer other than "mind the scale" I wrote already.

Maybe you've tried to be specific too early and answering two general questions I asked at the beginning could be useful before going into details?

kocio-pl on 13 Jul 2015

My suggestion of having a multi-criterion checklist instead of yes/no rules still stands. The purpose of this would be functioning as a helper for contributors as well as maintainers. The idea would be that a new feature suggestion that fails to meet a significant portion of the checklist criteria should ideally not be made in the first place and if made should be quickly rejected by the maintainers without elaborate discussion, ideally with a short statement regarding what criteria it fails.

If this truly helps avoiding pointless discussions and reducing the feature clutter in the style i can't say. But it seems unlikely it would have a significant negative impact.

imagico on 13 Jul 2015

@kocio-pl

What are the most important goals of general map?

The answer to this question is documented in https://github.com/gravitystorm/openstreetmap-carto/blob/master/CARTOGRAPHY.md udner Purposes.

matthijsmelissen on 13 Jul 2015

I've just looked at the list made by @imagico (unfortunately I had no time to read it carefully until now) and I can say it sounds reasonably and covers a lot of important factors (it even contains my criterion of scale and touches my second question). As subjective as the answers can be, it may be very useful as a general hint and I like that it's so flexible. I guess guidelines instead of rules are better crafted for such diverse goals and split developers community as we have now. I also could not find anything I disagree with, so I find it to be the best solution for our current lack of regulations. It would be great to make it a section in CARTOGRAPHY.md file probably.

@gravitystorm While I think it's not crucial to engage you in every rendering-related problem around, it would be of course much better if you can easily take part in such discussions. If you are subscribed to osm-dev or plan to do so, I will subscribe there too. I have already asked forum admin about creating new subforum and still got no answer, but if he would agree, I would use it as a general board about rendering OSM data and just send anybody with some particular problems to the list.

EDIT: osm-dev is moderated, which may be suboptimal for any bigger discussion we may have. Maybe general talk list would be better then?

kocio-pl on 13 Jul 2015

At this point, I would say we should have no increases to the number of icons on the map, and should aim at decreasing it.

pnorman on 13 Jul 2015

Why do you think so?

IMO more icons are important to make high scale tiles (especially z=19/z=max) really worth having, because typically at this level there simply isn't anything more interesting to see - even buildings are more like a background area there. The centre of a big city may look rather empty without them (especially comparing to overcrowded zoomed out view), let alone any less developed place.

The only real problems are they should be easy to recognize and not too dense. First one is the subject of discussions during testing phase, the second one should be ideally controlled with some dynamic method like minimal distance between the icons for given zoom level.

kocio-pl on 13 Jul 2015

style maintainers currently all have a fairly technical background and approach to things. This is natural to some extent - merging pull requests and reviewing changes in a primarily technical task. But a more cartographic/geographic view of things can be helpful sometimes. I am not saying this needs to be changed or even that it could be changed, just an observation

@imagico This is something I observed myself as well. I also realize I'm often overriding your cartographic arguments on the base of technical arguments. I think it's not only the maintainers that have a technical rather than cartographic backgrounds, but most of the people taking part in the discussion too (you're one of the exceptions). It would be nice if we could attract some more people with a cartographic background to the discussions. It might also make sense to add someone with a cartographic background to the team of maintainers at some point.

I for one think one of the most pressing needs in this style is improving overall consistency in styling - features that are similar in reality should be similar in rendering and things that are different should be shown differently.

@imagico Do you have any concrete examples?

Maybe it would be a good idea to open a new separate issue to collect some ideas for what features could be well removed from the style.

@imagico Good idea. I've got little time right now, could someone else create such an issue?

is the biggest problem for me. A map becomes incomprehensible when it is too complicated or requires too much learning to make use of. Even I struggle to recognise features from our map due to the complexity of what we try to show - http://www.openstreetmap.org/#map=18/51.50275/0.00323 showing a wide grey line with white dashes confused me for a while this morning, and I resorted to using the query tool to figure out what the feature actually was.
It's also a burden when we're trying to change things. For example, by showing so many different landuse colours, when we want to change the building colours there's a big list of things to consider. It's not the best example, but I want to make sure people are aware that there is a non-zero burden on stylesheet development for every feature that is added to the style. It's not like we merge the PR and then there's no other consequences.

@gravitystorm I think both examples are rather '2. using too many different symbols' than '1. displaying too many different features'. I'm using symbols/symbology in a very broad sense: I don't only mean the pictures in the symbols directory, but I also consider the different ways we render roads, and the different landuse colors, as symbols/symbology. It seems like you're problem is that it's yet another line rendering style, not the fact that the tunnel is rendered at all.

So in a lot of discussions I take a back seat, or keep out of it entirely, or wait for a while to see what other people are thinking before I give my own opinions.

@gravitystorm You're one of the few people here with a more cartographic background, so I'd be happy to hear more of your opinion - not so much because you're the project admin, but because you're have more experience with cartography. I think one of the reasons many of us are volunteering here is that we'd like to learn more about cartography. I think more high-level input (such as the current issue!) from your side are the most helpful.

But I still don't know who decides and to what extent. The repo's owner has the last say on everything? Or maybe all the people with write access decide on their own?

@kocio-pl: @gravitystorm has made it clear to the maintainers that the maintainers are all equal in deciding what to merge and what not to merge. In principle every maintainer can make decisions individually, but in practice of course we consult the other maintainers.

matthijsmelissen on 14 Jul 2015

Good idea. I've got little time right now, could someone else create such an issue?

Is it better to have one big "hunt for removable features/rendering differences" or to open/reopen specific ones like "drop rendering of highway=proposed"? I think that the second one would be better (I have some ideas).

matkoniecz on 14 Jul 2015

This is something I observed myself as well. I also realize I'm often overriding your cartographic arguments on the base of technical arguments. I think it's not only the maintainers that have a technical rather than cartographic backgrounds, but most of the people taking part in the discussion too (you're one of the exceptions). It would be nice if we could attract some more people with a cartographic background to the discussions. It might also make sense to add someone with a cartographic background to the team of maintainers at some point.

The conflict between design and technical constraints is to some extent inevitable. There are simply limits to what you can do in a real time updated map. One of the reasons why people with a cartographic background do not show up much here is because these restrictions can get frustrating very soon.

On the other hand technical limits are sometimes too quickly put forward to dismiss suggestions. For example the idea to relate different features to each other is something that could be helpful in many places (like for orienting symbols on nodes) but so far has not been used.

Also there is the principle that rendering is supposed to be close to the data to be clear to the mapper - which is sometimes also overdone. Mappers will get a better sense for abstraction required in mapping if they see also higher levels of abstraction are put to good use in rendering.

Note i come from an engineering background and have no formal cartographic education - i have simply probably read more on cartography and studied more classic maps than most people here.

Regarding overall consistency in styling - i can identify a number of areas where this is a problem

labels - use of different fonts and colors does not follow a recognizable overall scheme. Labels for very different features are often quite similar while labels for similar features can be very different. Admin unit labels are a big mess right now due to their prioritization.
general use of color - most obvious area here is roads which is currently addressed. Icon colors are also a problem (like the use of blue for very different things)
cross zoom consistency - most obviously the problem of things appearing and disappearing again when zooming in. Also scaling of features with zooms is a problem, many things (like road widths) do not work well on the highest zooms.
same scale consistency across different latitudes. My general favorite, see also #1290

(sorry for getting off-topic here - just trying to quickly answer the question, if there is need for discussion please open a new issue on overall consistency)

For creating a general 'features to be removed' collection - @matkoniecz might be right, just collecting suggestions might not lead to much except a lot of non-specific discussion. You could create a 'feature removal' label though to collect all issues and PRs dealing with removal of features.

imagico on 14 Jul 2015

sent from a phone

Am 14.07.2015 um 01:19 schrieb math1985 [email protected]:

Even I struggle to recognise features from our map due to the complexity of what we try to show - http://www.openstreetmap.org/#map=18/51.50275/0.00323 showing a wide grey line with white dashes confused me for a while this morning

looks like bogus mapping, a generic path with no access tags (something I'd expect in a rural setting) and a bridge attribute on a unconnected way that appears to represent a skywalk, I guess footway would have been more intuitive here

dieterdreist on 14 Jul 2015

I like the general notion we took during this long and hairy discussion. While I'm suspicious about "removing" features from the map, "unifying" some of them visually sounds great to me.

Having real meta-issues on GitHub would be helpful, but for now we may also use labels (+: they are here, -: no obvious place to discuss more general things and only owner/collaborators can asign them) and Wiki pages (+: flexible and allows any sort of discussion and restructuring on the fly by anyone, -: outside the GitHub).

kocio-pl on 14 Jul 2015

github provides an own wiki, but changes are not easy trackable.

HolgerJeromin on 14 Jul 2015

At least they are trackable at all. But I think tracking is not that important here - the more important feature would be that we have current list of things which anybody could edit, not only repo maintainers (so it may be more useful for planning than issue comment, because they need to be updated by respective authors too).

kocio-pl on 14 Jul 2015

continuation from https://github.com/gravitystorm/openstreetmap-carto/issues/1677#issuecomment-141642604 (it is off-topic there and on-topic here)

my old comment

I think that it is desirable for tag to pass through proposal process (as it means that multiple people looked at tag definition and found no significant problems - some problems may be not obvious for everybody from the start).

response by @imagico

On a general note I would strongly advise against making this a criterion here (which is why i left it out of the list of criteria on https://github.com/gravitystorm/openstreetmap-carto/issues/1630#issuecomment-118359389) - the proposal process can help improving quality of tagging concepts but practically it often does not. Cargo-culting it as a substitute for a thorough look if a tag and its use are well suited for rendering in a map is a very bad idea and would only lead to further degrade the proposal system towards becoming primarily a vehicle to push specific interests in mapping priorities.

matkoniecz on 19 Sep 2015

can help improving quality of tagging concepts but practically it often does not

In part it is about hope that definition of tag will be improved (what sometimes happens). But it is also method for pushing "what is the proper method to tag X" out of this issue tracker.

Cargo-culting it as a substitute for a thorough look if a tag and its use are well suited for rendering in a map

Certainly not substitute - for me it is prerequisite (it applies mainly to less popular and new tags). Certainly not guarantee that tag will be rendered (it would be absurd).

matkoniecz on 19 Sep 2015

What i meant to say is that if a tag went through a proposal process should not make a difference here. If a tag got better defined by going through a proposal process that should play a role but if it does this without going through the proposal formalities even better.

There is nothing wrong with suggesting to people who want to have a tag rendered here to create a proposal for them first - especially since writing a good proposal will often already solve or at least point out obvious problems. But in return considering the fact that this has formally happened to allow assuming a certain level of consistency in definition of the tag as well as community support is not a good idea.

imagico on 19 Sep 2015

I don't look at the wiki proposal process at all for evaluating tags. All the proposal process is for is listing a feature on the map features page, and listing its status as approved. A tag not being approve doesn't mean you shouldn't use it, and it doesn't mean it shouldn't be rendered.

pnorman on 20 Sep 2015

sent from a phone

Am 20.09.2015 um 09:46 schrieb Paul Norman [email protected]:

I don't look at the wiki proposal process at all for evaluating tags.

you might find some interesting hints there though, e.g. links to alternative tagging schemes, or information whether the tag is in use for different things

dieterdreist on 20 Sep 2015

I don't look at the wiki proposal process at all for evaluating tags. All the proposal process is for is listing a feature on the map features page, and listing its status as approved. A tag not being approve doesn't mean you shouldn't use it, and it doesn't mean it shouldn't be rendered.

As a map designer you are of course interested in current data. But osm-carto shapes tagging probably as much as the wiki does. So having the two worlds without overlap sounds sad.

Your statement about the proposal process is probably exaggerated to make a point. The canonical structure and the discussion about new proposals are very helpful.

jojo4u on 21 Sep 2015

We're not doing very well at removing features. Should we put in a freeze on new features until we've improved the situation?

pnorman on 5 Nov 2015

I don't disagree but i think some reliable numbers would be good - looking at recent PRs it does not seem that obvious feature additions are so much more frequent than feature removals.

If you look at icons additions are certainly in the majority. If you look at landcovers unifications (which qualify as feature reductions i think) seem to trump additions.

imagico on 5 Nov 2015

Personally I'm still not quite convinced a feature reduction is necessary.

I guess part of the process should be finding out what the problem is exactly. Would it help looking at some examples that are currently rendered particularly bad, and think of how we could improve them?

matthijsmelissen on 5 Nov 2015

I agree with @math1985 on it.

It's also not entirely quite clear what we call "feature addition" - for example in some (probably many) cases I was just replacing general dot icons used for shops with something more specific, so I would call it "rendering change".

The same for "feature removal" - for example the work @matkoniecz put into roads rendering was not about removing features, but the effect on visibility was tremendous - a lot of clutter was effectively removed better than if we drop some features.

kocio-pl on 5 Nov 2015

The same for "feature removal" - for example the work @matoniecz put into roads rendering was not about removing features, but the effect on visibility was tremendous - a lot of clutter was effectively removed better than if we drop some features.

+ 1, cartographically there is still a lot to gain. The work done by @matkoniecz on the roads and @nebulon42 on the shields, was a big step forward in this respect.

mboeringa on 5 Nov 2015

It's also not entirely quite clear what we call "feature addition"

Actually that is quite clear - any change that adds something to the map that was previously not rendered or that renders things differently that were previously rendered identically. There are changes doing that, there are changes doing the opposite (i.e. feature removal) and there are changes which are neutral in this regard.

To be honest - of all recent contributors here you are probably the one with the strongest relative overhang of feature additions. I mean this just matter-of-factually, not to diminish your contributions. Individually there is nothing good or bad about either feature additions or removals, it is the overall balance that has to work.

imagico on 5 Nov 2015

I mean this just matter-of-factually, not to diminish your contributions.

Sure, I don't feel offended in any way, because this way or another you're right - some POIs didn't have an icon before - and it's not something I think is shameful or what. I just said it's not clear to me what we want to avoid - more rendering features (visual elements), as you see it or just rendered features (new tagging schemes), as I see it, simply because this was not written in more details.

But it's just not important problem for me - major one being I don't find this policy worth following because it offers too simplistic point of view.

kocio-pl on 5 Nov 2015

A plea from the wilderness...

Please, consider map users before adding yet more icons for features. Whenever I look at an area that I'm not familiar with rendered in the standard style, I usually have to query the data there to find out what something is. As a test (I happened to be looking at http://www.openstreetmap.org/way/346287712 for a help question and just headed for the nearest town), I zoomed in randomly on http://www.openstreetmap.org/#map=19/52.35000/4.88904 . I had no idea about the "department store" icon (other than it's some sort of shop). The fountain I initially assumed to be some part of the public transport infrastructure from the colour. I'm someone who's vaguely familar with what's happening in OSM-carto development (at least, I see the github messages going past), and if I have a problem working out what's represented on the map you can guarantee that someone seeing the standard style on osm.org for the first time will too.

I'm aware that almost the first line of https://github.com/gravitystorm/openstreetmap-carto/blob/master/CARTOGRAPHY.md says the style should be "a feedback mechanism for mappers", though it'd be more so if the same icons, or at the vary least some of the same iconography, were used in all of the the OSM editors, but they don't seem to be (though JOSM's fountain is at least similar to the standard style's).

The problem is that providing a unique symbol is at the expense of communicating what a particular feature is - with fewer symbols it could be obvious that the fountain in the square is some sort of "arty" thing and not a "public transporty" one, and users have always got the option to query an individual feature to see what it is - which with the symbols as they are now people have to do anyway, because there are simply too many to remember. It's especially true with shops - and there the name is usually the giveaway of what sort of shop something is.

The other purposes highlighted at the top of cartography.md (clear mapping and customisability) lose out when there is a unique icon for everything. Back in the day there was the "standard" style and also "OsmaRender", which no-one could accuse of looking nice but was excellent for mapper feedback. I've suggested before having _two_ standard styles, as the contradictory requirements in cartofgraphy.md means that one can't do all three well.

SomeoneElseOSM on 5 Nov 2015

@SomeoneElseOSM Thanks for the feedback.

@nebulon42 has been working on a Mappaint style for JOSM based on the icons here. It can be found at https://github.com/gmgeo/osmic-josm-style (you can add it under View-Map Paint Styles). I'd be happy if that were made the default, but that's not really up to me to decide. The other way around, using the JOSM icons in the default style, is not really an option, because the JOSM icons are all rather inconsistent in style.

matthijsmelissen on 5 Nov 2015

@SomeoneElseOSM

I've suggested before having two standard styles, as the contradictory requirements in cartofgraphy.md means that one can't do all three well.

Oh, there will be much rejoicing in OSM when we will have two - or more - general styles with community input (one clean and one focused on feedback), but currently we don't have this luxury: seems like nobody is willing to continue Tiles@home project (I guess this is what you meant when you wrote about "OsmaRender"?) and we have not enough technical resources to host the second style.

If you want clean style there's for example a MapQuest Open right on the main OSM website, but if you want more general features, there's no better place that I'm aware of than osm-carto.

kocio-pl on 6 Nov 2015

Oh, there will be much rejoicing in OSM when we will have two - or more - general styles with community input (one clean and one focused on feedback)
...
If you want clean style there's for example a MapQuest Open right on the main OSM website, but if you want more general features, there's no better place that I'm aware of than osm-carto.

There will be an alternative, once I finish my ArcGIS Renderer for OpenStreetMap...

mboeringa on 6 Nov 2015

If you want clean style there's for example a MapQuest Open right on the main OSM website, but if you want more general features, there's no better place that I'm aware of than osm-carto.

Mapquest is not clean at all because of all the ugly JPEG artifacts :(

jojo4u on 6 Nov 2015

@mboeringa Any details or links? I am very skeptic about relying on proprietary software for community related activities, but who knows...

@jojo4u Image quality is one thing, the style properties is another.

kocio-pl on 6 Nov 2015

@mboeringa Any details or links? I am very skeptic about relying on proprietary software for community related activities, but who knows...

It is not a replacement of any of the open source projects and styles, it is an _alternative_, and will open up rendering for those who are unfamiliar with all the current solutions, but do have solid background in GIS and could contribute to OSM as well in the future.

I have posted a year ago on the OpenStreetMap forum (http://forum.openstreetmap.org/viewtopic.php?id=26451). The rendering results presented there are outdated though, since I've done major work since then. Additionally, contrary to what I wrote there, I have developed the main style in a full multi-scale renderer, and added the option for creating and managing arbitrary custom styles.

mboeringa on 6 Nov 2015

nobody is willing to continue Tiles@home project (I guess this is what you meant when you wrote about "OsmaRender"?)

The tiles@home project is a technical dead-end, as is osmarender.

The issue is that there are two groups of people: those who are able to to set up a style project and those who want a style with the cartographic goals of osmarender (render everything). These groups have little overlap. Personally, I have zero interest in contributing to a render everything style.

But, even if it would be good to have a style where the top priority is to render everything, this isn't it, and this isn't the issue tracker to plan it.

The addition of new features if one of the big drivers of complexity. I'd like something more nuanced than a flat no new features, but what we've been trying hasn't been working.

pnorman on 6 Nov 2015

sent from a phone

Am 05.11.2015 um 22:09 schrieb SomeoneElseOSM [email protected]:

users have always got the option to query an individual feature to see what it is - which with the symbols as they are now people have to do anyway, because there are simply too many to remember.

with good icons you shouldn't need an explanation to understand what is represented.

dieterdreist on 6 Nov 2015

but what we've been trying hasn't been working.

You keep repeating that, but it's still not entirely clear what you mean. I have a general idea, but I think a more precise explanation of the issues you have with the map is necessary in order to make progress.

Gradual changes likely won't work very well, so I think it'd be a good idea if somebody created a radically different map, at least for the sake of discussion. What about a map with no POI icons at all, for example? It would also be nice if we could render it at @pnorman's server.

matthijsmelissen on 6 Nov 2015

The addition of new features if one of the big drivers of complexity.

I am not sure this is the case - complexity in code mostly comes from more sophisticated rendering. Simple additions usually do not add that much code.

Here is a quick look at the numbers since this issue was opened. Mostly i classified the PRs based on their title so there could be errors. a1 means fully new features, a2 means rendering differently something that was previously rendered identically. az are things rendered at additional zoom levels. The same for r1/r2/rz regarding removal. n are neutral visible changes and - are invisible changes.

PR   | a1 | a2 | az | r1 | r2 | rz | n  | -
---- | -- | -- | -- | -- | -- | -- | -- | --
1930 |    |    |    |    |    |    |    | x
1918 |    |    |    |    |    |    | x  |
1917 |    |    |    |    |    |    | x  |
1915 |    |    |    |    |    |    | x  |
1914 |    |    |    |    |    |    | x  |
1910 |    |    |    |    |    |    | x  |
1907 |    |    |    |    |    | x  |    |
1906 |    |    |    |    |    | x  |    |
1905 |    |    |    |    |    |    | x  |
1904 |    |    |    |    |    | x  |    |
1902 |    |    |    |    |    |    |    | x
1901 |    |    |    | x  |    |    |    |
1900 |    |    |    | x  |    |    |    |
1893 |    |    |    |    |    |    | x  |
1888 |    |    |    |    |    |    | x  |
1881 |    |    |    |    |    |    | x  |
1878 |    |    |    |    |    |    |    |
1876 |    |    |    |    |    |    | x  |
1875 |    |    |    |    |    | x  |    |
1872 |    |    |    |    |    |    |    | x
1871 |    |    |    |    |    |    | x  |
1867 |    | x  |    |    |    |    |    |
1862 |    |    |    |    |    |    | x  |
1861 |    |    |    |    |    |    | x  |
1859 |    |    |    |    |    |    |    | x
1855 |    |    |    |    |    |    |    | x
1851 |    |    |    |    |    |    |    | x
1849 |    |    |    |    |    |    |    | x
1848 |    |    |    |    |    |    |    | x
1847 |    |    |    |    |    |    |    | x
1846 |    |    |    |    |    |    |    | x
1845 |    |    |    |    |    |    |    | x
1844 |    |    |    |    |    |    | x  |
1843 |    |    |    |    |    |    | x  |
1841 |    |    |    |    |    |    |    | x
1840 |    |    |    |    |    |    |    | x
1839 |    |    |    |    |    |    |    | x
1836 | x  |    |    |    |    |    |    |
1830 |    |    |    | x  |    |    |    |
1825 |    |    |    |    |    |    | x  |
1814 |    |    |    | x  |    |    |    |
1810 |    |    |    |    |    |    | x  |
1809 |    |    |    |    |    |    | x  |
1808 |    |    |    |    |    |    | x  |
1805 |    |    |    |    |    |    | x  |
1804 | x  |    |    |    |    |    |    |
1801 |    | x  |    | x  |    |    |    |
1798 |    |    |    |    |    |    | x  |
1792 |    |    |    |    |    |    |    | x
1791 |    |    |    |    |    |    | x  |
1789 |    |    |    |    |    |    |    | x
1788 |    | x  |    |    |    |    |    |
1782 |    |    |    |    |    |    |    | x
1778 |    |    |    |    |    |    | x  |
1777 | x  |    |    |    |    |    |    |
1773 |    |    |    |    |    |    | x  |
1763 |    |    |    |    |    |    | x  |
1762 |    |    |    |    |    | x  |    |
1761 |    |    |    |    |    | x  |    |
1758 |    |    |    |    |    |    |    | x
1747 |    |    |    |    |    |    |    | x
1744 | x  |    |    |    |    |    |    |
1739 |    |    |    |    |    | x  |    |
1738 |    |    |    |    |    |    |    | x
1736 |    |    |    |    |    | x  |    |
1732 |    |    |    |    |    |    | x  |
1728 |    |    |    |    | x  |    |    |
1726 |    |    |    |    |    |    |    | x
1723 |    |    |    |    |    |    |    | x
1720 |    | x  |    |    |    |    |    |
1714 |    |    |    |    |    |    | x  |
1713 |    | x  |    |    | x  |    |    |
1712 |    |    |    |    |    |    | x  |
1703 |    |    |    |    |    |    | x  |
1702 |    |    |    |    |    |    | x  |
1699 |    |    |    |    |    |    |    | x
1696 |    |    |    |    |    |    | x  |
1694 |    |    |    |    |    |    |    | x
1692 |    |    |    |    |    |    | x  |
1690 |    |    |    |    |    |    | x  |
1689 |    |    |    |    |    |    | x  |
1687 |    |    |    |    |    |    |    | x
1685 |    |    |    |    |    |    |    | x
1682 |    |    |    |    |    | x  |    |
1680 |    |    |    |    |    |    | x  |
1676 |    |    |    |    |    |    | x  |
1675 |    |    |    |    |    |    | x  |
1674 |    |    |    |    |    |    | x  |
1671 |    |    |    |    |    |    |    | x
1667 |    |    |    |    |    |    |    | x
1664 |    |    |    |    |    |    | x  |
1663 |    |    |    | x  |    |    |    |
1662 |    |    |    |    |    | x  |    |
1658 |    |    |    |    |    |    | x  |
1655 |    |    |    |    | x  | x  |    |
1653 |    |    |    |    |    |    |    | x
1652 |    |    |    |    |    |    |    | x
1650 | x  |    |    |    |    |    |    |
1647 |    |    |    |    |    | x  |    |
1641 |    |    |    |    |    |    |    | x
1639 |    |    |    |    |    |    |    | x
1638 |    |    |    |    |    | x  |    |
1635 |    |    |    |    |    | x  |    |
1633 | x  |    |    |    |    |    |    |
1632 |    | x  |    |    |    |    |    |
1629 | x  |    |    |    |    |    |    |
---- | -- | -- | -- | -- | -- | -- | -- | --
sum  | 7  | 6  | 0  | 6  | 3  | 14 | 40 | 32

imagico on 6 Nov 2015

As an aside, re Mapquest Open, it's not really an option since Mapquest haven't updated their "open" tiles for a while (at least a month). The main "mapquest.com" site has some Mapbox tiles on it (not sure what type - but they're essentially monochrome and I can't think of a purpose I'd use that style for).

SomeoneElseOSM on 6 Nov 2015

@math1985 Interesting idea.

@imagico Thanks for the analysis.

@SomeoneElseOSM I don't check MQO, because there's nothing interesting for me (where should one report it BTW?). The map on MapQuest.com is very pale and clean, so you can show POIs on dynamic overlays - this is a primary use of such design in my opinion (being unobtrusive background for some interesting features). Unfortunately we don't have POI overlays on OSM.org and it's not even clear if we can (or not).

kocio-pl on 6 Nov 2015

Interesting remark regarding offloading features from layers by using uMap+Overpass (which is also not clear if would be included on OSM.org website): https://github.com/openstreetmap/openstreetmap-website/issues/1056#issuecomment-156369810.

kocio-pl on 13 Nov 2015

This is very similar to #660.

matthijsmelissen on 16 Nov 2015

but what we've been trying hasn't been working.

You keep repeating that, but it's still not entirely clear what you mean. I have a general idea, but I think a more precise explanation of the issues you have with the map is necessary in order to make progress.

We've been trying (or should have been trying) to avoid unbounded addition of features and cartographic complexity.

I am not sure this is the case - complexity in code mostly comes from more sophisticated rendering. Simple additions usually do not add that much code.

I dread working with the layers that render amenity icons. I didn't used to, even though they were oddly expressed a year ago.

I also dread working with the road/rail layers, but less so than I used to.

pnorman on 16 Nov 2015

I dread working with the layers that render amenity icons.

You're talking mainly about the SQL, right?

matthijsmelissen on 16 Nov 2015

I dread working with the layers that render amenity icons.

You're talking mainly about the SQL, right?

I don't really distinguish them, most changes involve both MSS and YAML changes. As well as involving parts of .text

pnorman on 16 Nov 2015

I don't have a better place to write about interesting new tool to check the usage of a given tag over time. I've found to my surprise that adding new features in osm-carto has no visible effect on using them more. Objects like amenity=social_facility or highway=elevator are visible for many months, yet I don't see their usage is influenced in a any way by appearing in this style.

kocio-pl on 29 Aug 2016

👍1

That's really cool! I have no time to run the tool right now, could you show some screenshots?

I wonder if you're able to see the effect of adding presets in iD / JOSM?

matthijsmelissen on 29 Aug 2016

I see I can run it online on http://taghistory.raifer.tech/

Does it take into account deleted objects?

matthijsmelissen on 29 Aug 2016

I don't know, you should ask @tyrasd about details.

kocio-pl on 29 Aug 2016

sent from a phone

Il giorno 29 ago 2016, alle ore 13:50, kocio-pl [email protected] ha scritto:

Objects like amenity=social_facility or highway=elevator

the first cannot be reasonably represented without looking at the subtags and the second is not occurring very often outside of buildings

dieterdreist on 29 Aug 2016

I don't understand what are you trying to say. I can see that their usage is growing, but this does not seem to be related to the moment they've started to be visible on osm-carto.

kocio-pl on 29 Aug 2016

I might have a counter example. If you look at natural=saddle there is a huge spike which coincides with the availability of the osm-carto release which added the rendering for it. Since usage has almost doubled over a short period I suspect something else beyond normal additions by mappers.

nebulon42 on 1 Sep 2016

👍2

If anyone is interested in making less casual analysis than our examples, I would be happy to see it.

kocio-pl on 1 Sep 2016

Some analysis, but not particularly related to this repository:
www.openstreetmap.org/user/Math1985/diary/39404

matthijsmelissen on 1 Sep 2016

👍2 ❤1

Since usage has almost doubled over a short period I suspect something else beyond normal additions by mappers.

Somebody did a series of mechanical edits, retagging thousands of instances of mountain_pass into saddle.
http://www.openstreetmap.org/changeset/28122761

matthijsmelissen on 1 Sep 2016

Somebody did a series of mechanical edits, retagging thousands of instances of mountain_pass into saddle.
http://www.openstreetmap.org/changeset/28122761

Interesting analysis.
By curiosity I quickly checked some nodes randomly and almost all of them (not all anyway) do not cross a road and are expected to be saddles.

Ircama on 1 Sep 2016

I see I can run it online on http://taghistory.raifer.tech/

Just FYI, it broadly supports browsers (e.g., Firefox, Chrome, ...) but does not look to run on IE11.

Ircama on 2 Sep 2016

Another quite interesting analytic tool from the same person - OSM tile access logs viewer (so we know which areas are currently the most interesting for viewers):

http://osm-tile-access-log-viewer.raifer.tech
https://www.openstreetmap.org/user/tyr_asd/diary/39434

kocio-pl on 18 Oct 2016

[… http://taghistory.raifer.tech/ …] Does it take into account deleted objects?

Yes, it does.

tyrasd on 18 Oct 2016

👍1

We ultimateley failed to find common rules, therefore I close it now. If any new ideas would appear, it can be reopened, of course.

kocio-pl on 20 Oct 2017

I made an update on the stats i did in https://github.com/gravitystorm/openstreetmap-carto/issues/1630#issuecomment-154371089 - for all PRs merged since the beginning of 2017:

category | count
-------------|----------
a1 (fully new features) | 45
a2 (new differentiation of things previously rendered identically) | 10
az (additional zoom levels) | 9
r1 (fully removed features) | 3
r2 (unification of features previously rendered identically) | 2
rz (less zoom levels) | 12
n (neutral regarding addition but visible) | 87
invisible | 73

Interesting is also the changing rate of modifications in the different categories - about 25 of the 45 fully new features (more than half) were added since the beginning of the year while only about a dozen of the 87 neutral visible changes (which is mostly bug fixes, styling adjustments etc.) is from 2018.

By the way the three PRs from the r1 category were #3174, #2573 and #2554.

imagico on 24 Apr 2018

Thanks, that's interesting and quite detailed (241 cases analyzed). It would be interesting to know how the open issue tickets can be categorized, even if they're not as clear, because multiple solutions might be used. Simple search shows 48 (of 358) tickets with the word "add" in title.

kocio-pl on 24 Apr 2018

I see from https://github.com/gravitystorm/openstreetmap-carto/issues/3201#issuecomment-385020472 that in your view this analysis proves something special and disturbing ("lacking responsibility", I guess), but I think it's quite simple: there are more than one "shift" during these 5-6 years and it's natural thing for a living project to evolve.

When Andy started style reimplementation, it was one man show focused on strict matching old features 1:1. Then it has grown to a small team of coding experts expanding it by mutual consensus (you call it a "bubble" when you don't like the output) - which was first shift from the original goal.

Then it became rather tight - second shift, where the team members were still very productive, but were both experienced and afraid of changes (described quite good in https://github.com/gravitystorm/openstreetmap-carto/issues/1630#issuecomment-118993423). Which was frustrating for some people like me.

Then some other shift has started slowly - it was harder and harder to make consensus and creator became less active. Next thing was making team bigger, but it didn't help with very different visions. Experienced team members become less active too, so it was harder to see any move, even if it could be quite easy to decide some things. I tried to gain some experience and deploy my visions to avoid project halt.

Then a new trend has begun and this is what you have observed - people from outside of the team started to design, discuss, code and decide things more and more. This is the onboarding success, but it's quite natural that they come with adding things, because fixing and groundwork are harder. This also explains acceleration - there are more people active than before, so they made more changes (some of the changes are just waiting for implementation).

I hope vector fork(s) will make the rendering fun again for both experienced and new developers. That will be next shift from the current state - and this might go in multiple directions in parallel.

kocio-pl on 28 Apr 2018

For better understanding: My analysis in https://github.com/gravitystorm/openstreetmap-carto/issues/1630#issuecomment-384056965 was specifically meant to be based on objectively verifiable categories. I thought about also classifying PRs by other criteria, for example in how far they work towards or against the goals of this style, but such more specific analysis would require more work in defining and documenting criteria to be scientifically sound. Maybe some other time.

I am completely fine with and frankly i expect these observations to be used to support different views of the development of this style. Which of these views actually best represents reality is something you can ultimately only determine by critically evaluating its validity against this reality. This is hard and i therefore rarely observe it to happen and the lack of solid literature on OSM cartography and how it relates to cartography in general does not make it easier.

I explained this more elaborately in private conversation among the maintainers recently - which is where i mentioned the 'bubble' @kocio-pl is referring to. Since that is difficult to understand for those who have not been in this conversation here a quote of the part in question:

If you look over recent changes by maintainers merged or approved by
other maintainers you will also find in many cases that no substantial
discussion is taking place (i.e. discussions where pros and cons of a
change are analyzed, alternatives and context considered and it is
attempted to look at all relevant aspects of a problem). Like here:

https://github.com/gravitystorm/openstreetmap-carto/pull/3107
https://github.com/gravitystorm/openstreetmap-carto/pull/3144
https://github.com/gravitystorm/openstreetmap-carto/pull/2972
https://github.com/gravitystorm/openstreetmap-carto/pull/3065
https://github.com/gravitystorm/openstreetmap-carto/pull/3103

To me as a relative outsider now since i no more actively participate in
development at the moment this more and more feels like a filter bubble
with developers re-affirming each others views rather that critically
reviewing things. Occasionally i make a comment trying to broaden the
perspective on the matter in question (like in the last example above)
but usually it feels like i am mostly inconveniencing people by
bringing in complications that originally did not seem to exist inside
the filter bubble. Only in rare situations where a topic is carried
outside the realm of osm-carto (like with the boundary relations/lines
recently or
https://github.com/gravitystorm/openstreetmap-carto/pull/2816) we seem
to get a fairly exhaustive discussion of a matter that has the
potential to significantly widen the horizon of those participating.

@kocio-pl - you are speaking of _your visions_ - a year ago in https://github.com/gravitystorm/openstreetmap-carto/pull/2462#issuecomment-296640383 i called for you and others to write down the design principles that guide you. Nothing happened since then. Maybe that is something you want to look into. Note this is not something you should try to do in five minutes, i would recommend at least a few hours time for that. Trying to formulate your intentions in a consistent form that is comprehensible by others can be an eye opening experience.

imagico on 28 Apr 2018

I like the numbers - if they don't help me, they are at least inspiring and interesting, so I'm happy with your work. Sometimes I have no idea what they mean (like some tag history charts showing that in some cases lack of rendering or adding new features have no effect on tagging). In this case however nothing surprised me - not the number of "a" (adds), nor the number of them in this year. And I don't see anything wrong with it - more fixing (and probably removing) will be possible when we will have more regular contributors. As much as I feel adding things is perfectly right, I care also for other actions and try to do them too (#2869 is out of my reach, but would be great).
As of the meaning of "bubble"/consensus, it's probably not good to go to the extremes. Too much consensus/single man work and you end up with biased choices, too few of it and any decision making is impossible. I like team work, when people have at least common goal, but can change details and share some work. Therefore I'm more happy with #2671 then with some my own changes which had not a single comment, even if I was asking.
My intentions are quite simple probably:
I want to have a rich map in the first place (hence adding features when they don't overlap too bad),
I want to make it clear and readable (hence moving some smaller elements later to not obfuscate the area or support for fading area colors on midzoom),
I like it to be diverse (hence merging the marketplace, as it can be quite popular outside Europe, but also adding outdoor symbols or advertising column)

As you can see, all these are the points from our goals. But I'm not willing to invest more time into writing them down, because we differ in how we understand them, so there's no use in trying to be more precise:

I see the goal of a rich map and feel safe with adding, since we're unable to add even most of all the keys, but team mates seem to not follow this goal and read the last sentence as warning, while for me it's more like a safe reminder for people unaware that it's impossible to have everything (impossible, not "forbidden"!).
I see the fading colors as a tool to make map more readable, while you for example see the reverse effect of exactly the same action and reading the same rule.
I see diversity not only for different countries (how this is always mentioned), but also urban/outdoor, big/small elements and so on
Encouraging correct mapping and adaptability don't create tension, IIRC, so we probably don't differ that much in that respect. Maintainability is not a direct source of conflicts too, but it's probably a part that comes to mind when opposing adding more shop/amenity code, while I see the road code as much worse problem.

How could we solve this by stating things more clearly? I think we just can't.

I think community building around osm-carto, but also around OSM map rendering, is very important, but that's not a style goal, rather my personal goal. This is important part of my vision anyway.

I doubt stating all that helps anything. Instead of trying to better share the box we're in (creating better rules), I prefer to make more space (I mean more styles and personalization).

kocio-pl on 28 Apr 2018

sent from a phone

On 28. Apr 2018, at 03:27, kocio-pl notifications@github.com wrote:

I hope vector fork(s) will make the rendering fun again for both experienced and new developers.

while it allows for individual adaptation due to client side rendering (eg languages used for labels, or multiple coloring schemes), vector rendering requires vector tiles though, so I wouldn’t expect this change to make the system more flexible for people working on the style, rather the opposite because of the decisions in what comes when in for which resolution in the (data) tiles, and eventually external projects depending on certain things being in the tiles at certain zoomlevels, etc.
Something like let’s render foo 2 zoomlevels earlier would be much harder to do than it is now, where you have basically one dataset (besides very few features like borders and the coastline where it are 2), and also inclusions of new features will probably become rarer.

dieterdreist on 28 Apr 2018

Yes, that won't solve all the rendering problems. It's just a real step toward overcoming them.

I think the sheer amount of OSM data is the biggest problem now, because the entry barrier for using them is so high. I think it's not a coincidence that even communities render only their own country with their style/fork - see the OSM Swiss for example. Only the strongest ones, as German or French are showing all the world.

It's even worse when it comes to the personal maps. uMap is just scratching the surface. Klokan pre-rendered vector tiles in the Docker containers are rather a technology preview. I think we need kind of community Mapbox Studio service:

full database - no need to manage the data, like importing the planet.osm for days or keeping them fresh
online presence - not just on a home machine
user friendly (visual) style editor

With v4.x we have an hstore and OSMF keeps database fresh, so we have it, the online presence is also there. But we have just one style rendered there, so making it possible to have few more, even limited by osm-carto queries, is just better.

kocio-pl on 28 Apr 2018

sent from a phone

On 28. Apr 2018, at 16:26, kocio-pl notifications@github.com wrote:

I think the sheer amount of OSM data is the biggest problem now, because the entry barrier for using them is so high

if you just want to create some maps you usually don’t need the whole world, or if you do you don’t need a lot of features (at world scale), so the amount of data is not really an issue if you know what you want to do. If you still want the whole world at small scales you either have to have the resources or be patient, you still can import everything on cheap consumer hardware if you bring a week or two, SSDs have become significantly cheaper in the last years ;-)

dieterdreist on 28 Apr 2018

if you just want to create some maps you usually don’t need the whole world, or if you do you don’t need a lot of features (at world scale), so the amount of data is not really an issue if you know what you want to do.

I don't think it's so easy. Firstly because we have exactly this problem with rendering area:highway=* in Polish community - we would love to cover the whole world to spread this tagging scheme, but it needs better hardware than what we have:

http://osmapa.pl/w/area/

There's also an important question - why would you like to limit the map if you could show the names of all the places with your language and with your style (for example showing "Pekin" label instead of "北京")? And why the OSMF doesn't render multiple styles with many languages (Wikimedia plans to cover all the languages, but it's wealthy organization nowadays), just one style with default names?

"If you know what you're doing" you can use a big machine (24-32 GB rather then 4-8 GB of RAM for example) and import the planet in ~24h for a start (!), but if you'd like to just play with maps, there are too many things you lack. I will try to learn people using QGIS, but even importing only Poland will take ~1,5 h, so it's not casual activity.

If you still want the whole world at small scales you either have to have the resources or be patient, you still can import everything on cheap consumer hardware if you bring a week or two, SSDs have become significantly cheaper in the last years ;-)

If you're determined and patient you can do amazing things! But that's why I say about high entry barrier - it's perfectly possible in many cases, but it's just very hard.

kocio-pl on 29 Apr 2018

I don't think it's so easy. Firstly because we have exactly this problem with rendering area:highway=* in Polish community - we would love to cover the whole world to spread this tagging scheme, but it needs better hardware than what we have:

yes, for a national mapping community it is desirable to have a global style and diff updates, and if you also want to provide a tileserver it requires a powerful machine.

There's also an important question - why would you like to limit the map if you could show the names of all the places with your language and with your style (for example showing "Pekin" label instead of "北京")? And why the OSMF doesn't render multiple styles with many languages

maybe they are only waiting for someone to propose it again who has a good plan how to implement it.

but even importing only Poland will take ~1,5 h, so it's not casual activity.

downloading Poland and cropping out your city bounding box with osmium and importing this will probably only take a few minutes, and you can do a lot of stuff with a whole city. 1,5h is not an infinity, especially as you do not have to do something, you can do something else in the meantime.

If you still want the whole world at small scales you either have to have the resources or be patient, you still can import everything on cheap consumer hardware if you bring a week or two, SSDs have become significantly cheaper in the last years ;-)

If you're determined and patient you can do amazing things! But that's why I say about high entry barrier - it's perfectly possible in many cases, but it's just very hard.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

dieterdreist on 29 Apr 2018

maybe they are only waiting for someone to propose it again who has a good plan how to implement it.

Yes, of course:

https://wiki.openstreetmap.org/wiki/Top_Ten_Tasks#Localized_map_rendering

But "good" means "we're not able to render raster tiles for each language with our hardware using current toolset":

_However, this needs to be made possible without taking too many resources._

kocio-pl on 29 Apr 2018

Reopening: while there was not consensus about this back in 2015 and 2016, it would still be good to document our process for deciding when accept or reject a new feature request.

jeisenbe on 23 Mar 2020

👍1

Openstreetmap-carto: Guidelines for adding new features

Most helpful comment

All 115 comments

Related issues