Guidelines for adding new features

[gravitystorm]

In a different issue @kocio-pl says:

"AFAIK there are currently no policy on the amount of tag uses yet. It's just a matter of individual taste and feeling."

I don't want thinks to be unpredictable, so we should come to a collective decision rather than it depending one individual taste. But it's a tricky subject, and causes a huge amount of bad feelings, since every mapper wants every tag to show up somewhere, and unfortunately for us, that somewhere is almost always here.

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

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.

When it comes to adding new things - well, there are roughly hundreds of thousands - perhaps millions - of different "things" in OpenStreetMap and they almost all could be added to this style. If we add things and don't remove things, then the map style will show hundreds of thousands of different things, and that's not tenable. It stops being a map and is just a complex, unreadable, useless and ugly visualisation of the database. So we need to have a plan to remove things if we keep adding more and more. I know people disagree with me here, and claim that there's no downside to adding more features (or new features won't be drawn in the same place as existing ones, or can't see the problem with having millions of different icons) but they are wrong. And the way we are doing it at the moment - where we add new features every week since "one or two more can't hurt" is unsustainable.

For the second point, if a feature is so obscure that no other rendering - even including specialist renderings - contain that feature, then I think it's inappropriate to add it to a general style. It should be the case that the main map style is a good summary of the data available, and then if you want to see more information on a topic, you can switch to another, perhaps specialist, map. Having features appearing only on the general style and not elsewhere is completely back-to-front.

Other proposals are, of course, welcome!

[matthijsmelissen]

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?

1. 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.

[matkoniecz]

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).

[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.

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.

[dieterdreist]

sent from a phone

Am 14.07.2015 um 01:19 schrieb math1985 notifications@github.com:

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

[kocio-pl]

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).

[HolgerJeromin]

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

[kocio-pl]

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).

[matkoniecz]

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]

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).

[imagico]

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.

[pnorman]

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.

[dieterdreist]

sent from a phone

Am 20.09.2015 um 09:46 schrieb Paul Norman notifications@github.com:

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

[jojo4u]

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.

[pnorman]

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

[imagico]

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.

[matthijsmelissen]

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?

[kocio-pl]

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.

[mboeringa]

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.

[imagico]

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.

[kocio-pl]

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.

[SomeoneElseOSM]

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.

[matthijsmelissen]

@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.

[kocio-pl]

@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.

[mboeringa]

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...

[jojo4u]

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 :(

[kocio-pl]

@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.

[mboeringa]

@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.

[pnorman]

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.

[dieterdreist]

sent from a phone

Am 05.11.2015 um 22:09 schrieb SomeoneElseOSM notifications@github.com:

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.

[matthijsmelissen]

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.

[imagico]

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

[SomeoneElseOSM]

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).

[kocio-pl]

@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]

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.

[matthijsmelissen]

This is very similar to #660.

[pnorman]

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.

[matthijsmelissen]

I dread working with the layers that render amenity icons.

You're talking mainly about the SQL, right?

[pnorman]

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

[kocio-pl]

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.

[matthijsmelissen]

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]

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

Does it take into account deleted objects?

[kocio-pl]

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

[dieterdreist]

sent from a phone

Il giorno 29 ago 2016, alle ore 13:50, kocio-pl notifications@github.com 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

[kocio-pl]

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.

[nebulon42]

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.

[kocio-pl]

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

[matthijsmelissen]

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

[matthijsmelissen]

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

[Ircama]

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]

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.