I have no clear opinion on that, but this is right question to ask, thanks!

Typical size is just one hint I wrote about. There is also relative size, typical usage etc.

I guess this comment is rather for previous article, because it was about urban/rural distinction. How does it relate to this entry?

I’m not sure, I only know changeset reverter. Please ask here for example:

https://help.openstreetmap.org/

There is also one paragraph in Spanish to remove. :)

The problem is that all of them generate some conflicts, so I’m not sure what could go wrong. I guess the best thing would be if you make manual corrections to avoid breaking things.

Reverting is OK for elements which has not been altered later - it’s produces normal changeset, but with opposite actions. If there were some other actions later, it become complicated.

Yes:

https://wiki.openstreetmap.org/wiki/Change_rollback

You can post bad changesets numbers, so I could do it using JOSM.

As far as i know it’s not, and I even tried once, but I don’t remember what is the main problem. Does it work with your fork?

I wonder what do you think about Maputnik? It’s a free map editor using Mapbox GL. Do you envision using it directly, using it as a base for much simpler user interface, or maybe you don’t think it’s suitable for this task? I remember that iD was based on Potlatch 2 architecture, and it still took 0,5 mln USD and months of work for a start.

Any other, probably more detailed/technical thoughts?

When thinking about “showcase of OSM capabilities”, I see mainly how rich OSM data are, and that is what I would try to show.

Map builder is a nice idea, that’s also what I want to have on OSM website eventually. OSM Carto conversion to vector is a step in this direction, but it’s always good to make migration smooth and that’s I think it’s needed. Another huge problem is hardware - we don’t have too much of it - and the team who would be able and willing to create such map builder. Do you have the idea how should we approach it?

I think it’s time to talk about details, not just general visions. I made a special subforum on rendering maps with vector thread in it - I suggest discussing things there:

https://forum.openstreetmap.org/viewforum.php?id=100

Bugfix release v4.12.1 has been published, it just removes surface tag rendering due to severe performance problems:

https://lists.openstreetmap.org/pipermail/talk/2018-June/080867.html

I still don’t see anything in the OSM data model that is “incompatible” with good cartography. Sometimes there are just shortcomings of the tools we use, sometimes tags are too vague and lack some details, and it can be quite irritating, but the data model is sane for me. Maybe it’s just the language you used in this entry, which is emotional (it’s fine for me, it’s your diary after all, I just wanted to make things clear).

I also understand why it’s easy to get something personal - in some cases there are just a few people involved. For example: if I would say “half of the osm-carto developers thinks that…”, it means exactly 4 persons in our team and I could name them easily. :-)

It might be preferred to have less elements on the map. In my opinion Google designed their map to be sketchy, because this is meant to be just location map. Their strength is full integrated geo stack, not the map itself.

So it’s easy to find OSM styles that are similar to GMaps (OSM Bright, Wikimedia Brighmed, Mapbox Streets…), but it’s hard to compete with GMaps+Google routing+aerial images+Street View+being default on Android devices+sponsored POIs (I guess).

Hi, Zverik,

As one of the mapping style developers, I have difficulty getting your point regarding it:

But now it’s obvious that nobody knows where to go next.

In multiple directions, because no single one is good for everybody.

It’s painful to look at developers’ attempts to continue, especially this year: they fruitlessly try to change established tagging principles, because the OSM data model is incompatible with good carthography.

Which examples do you mean? There are tags that are better and worse when trying to render them, but I don’t see any fundamental problem with the OSM data model.

We reached the ceiling of the rendering stack made five years ago.

It looks quite limited to me, sure, but still extendable.

The only way out is to throw it all away and start anew — exactly what authors are discussing these days.

There’s more than one way. Paul made a fresh new style and toolset (Bolder) and might add more features to the point where he’s happy with the amount of rendered objects. At the same time Andy is proposing evolutionary way instead - just adding intermediate vector phase, which allows rendering multiple versions based on the osm-carto.

Both ways can coexist on the same hardware, but even if that’s not possible, they can be developed in parallel, as many other styles and solutions.

Maybe I’m missing something you wanted to say, but from my point of view we’re now in a good point for OSM map styles to grow into healthy, diverse ecosystem.

Great, nice to see new approach here!

The announcement lacks the link to repository in the prominent place, I have found it through the issue ticket link in the last section.

The announcement also started a discussion at Dev list (just one comment currently):

https://lists.openstreetmap.org/pipermail/dev/2018-April/030217.html

We look for a coder to help us fight with spam:

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

Excuse me, I don’t speak Spanish, but automatic translation indicates this has probably nothing to do with this entry. If I’m wrong, try to explain what’s the matter and what it has to do with osm-carto release (in English would be the best).

Thanks!

Well, while our team is 8 persons strong in practice recently only 1-2 persons at any given moment are deciding and merging code.

That might sounds bad, but anybody can design an icon or prepare the code or suggest an idea and there are few people who try to do that. I hope there will be more of them and that’s why I ask a lot if somebody would like to try (do you?).

That’s the only way I can think of to solve more issues in the long run.

We might fix the problem with riverbanks not filtering them by size, but rendering them from some zoom level probably:

https://github.com/gravitystorm/openstreetmap-carto/pull/2952#issuecomment-353777483

You might discuss it there or open new issue.

If you want to make it really simple it is best to accept that way_area filtering for filled polygon rendering just does not serve any positive goal, it is purely a method of reducing rendering costs at the expense of quality.

I can not agree with that whole sentence, even if it is true in some details. In my opinion it definitely serves a positive goal: reducing the high frequency noise. While sub-pixel filtering was just a purely technical decision (my intention was only reducing rendering costs, exactly as you say, visual changes at high frequency was not planned), current (v4.6.0) filtering is made exactly for this reason (hiding unwanted details) - it has nothing to do with reducing rendering costs. Of course you might argue (a) if this really needed and (b) if this is the best method to achieve this goal, and I guess b) is probably what you mean - but that’s not what you just wrote.

For me personally these are 2 things that should not be mixed: 1. Cutting sub-pixel haze is acceptable, small trade off for showing big lakes. Not showing them on low zoom is unacceptable for me and many other people - it was a huge, common cartographic problem reported many times. 2. Current (much bigger) filtering is not necessary for me, it’s just one possible way to skin the cat, but there may be some better ones.

I will oppose any proposition which breaks rendering big lakes on low zoom as nasty regression, but anything else is welcome and I can discuss any proposed solution - especially pull requests.

I think it should be possible to treat riverbanks different than lakes. However this entry warns about filtering any kind of water on low zoom levels (see the last example with lakes).

And what is important to notice in the first place is that any act of limiting encourages cheating. If we allow rivers to be unfiltered, there is a danger that somebody will tag the lakes like riverbanks for example. So while being scared about big multipolygons is perfectly valid point of view, it does not say why the filtering was introduced and doesn’t compare the problems and the gains of some possible solutions. Writing diary entry might be as subjective and narrow as it gets (it’s personal after all), but when making decisions you should be aware of more than one problem and in the end accept that no solution is perfect.

So if you have some propositions what could be fixed, please report them on osm-carto issue tracker, so we could discuss them and choose the most appropriate solution. Diary comments is not the best place to improve osm-carto rendering.