OpenStreetMap

kocio has commented on the following diary entries

Post When Comment
Mistake in map alignment. I'm sorry, can I revert that? about 3 hours ago

Yes:

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

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

Developer wanted for CartoCSS 3 days ago

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?

On Vector Tiles 14 days ago

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.

On Vector Tiles 20 days ago

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

OpenStreetMap Carto release v4.12.0 about 2 months ago

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

Not Yours, OpenStreetMap 3 months ago

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

Not Yours, OpenStreetMap 3 months ago

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

Not Yours, OpenStreetMap 3 months ago

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.

Bolder - Starting a new client-side OpenStreetMap style 4 months ago

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

OpenStreetMap Carto release v4.10.0 4 months ago

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

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

OpenStreetMap Carto release v4.7.1 7 months ago

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

OpenStreetMap Carto release v4.7.0 7 months ago

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.

Say hello to the giant Multipolygons 8 months ago

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.

Say hello to the giant Multipolygons 8 months ago

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.

Say hello to the giant Multipolygons 8 months ago

I'm an OSM Carto co-developer, who was one of a few people active with this change. Unfortunately this particular problem has not been reported when we were making decisions and testing it, as nebulon42 noticed (who is also co-developer). I learned about it from the fresh weeklyOSM 387.

I think the main problem to think about is proportions and think about the complex problems, not just one particular issue related to it.

Until recently we had no big lakes visible on low zoom levels and (if I remember) that encouraged to tag them as coastline, both of which was much worse in my opinion. My investigation showed that it's possible to fix these issues by filtering out sub-pixel water areas. It was purely technical obstacle, and solving it allowed us to show all the small, but over-pixel areas on low zoom. So when we just stopped rendering "water haze" of sub-pixel size and we were able to show big waters, we end up also with "water haze" of small, but over-pixel water areas. That's why we tried to limit also this haze - but this time it was not a technical problem, it was purely cartographic decision, which partially reverts the change with small water areas.

Now - it's about fixing low levels mainly. The new filter removes smaller waters on z0-z7 only and is regressive (it's getting weaker when zooming in). On z8+ (which is still big) we just got rid of sub-pixel areas, not small, but over-pixel. We were testing it to not loose to much and we have found that sub-pixel haze was not that big.

I hope that background makes the whole problem a bit more clear. For me personally limiting over-pixel haze on low zoom levels makes map a bit more readable - we don't have to show all the possible details everywhere, "actual geography" is what we have on aerial pictures. Of course somebody might want to overcome the filter, but we can see if it will really happen or not.

OpenStreetMap Carto release v4.6.0 8 months ago

Previously grass was not visible in gardens, which is much more common problem IMO. But the main problem is that park and garden are more similar than garden and grass, see:

https://github.com/gravitystorm/openstreetmap-carto/issues/2956#issuecomment-346730261

Planned rendering changes of protected areas 9 months ago

Protect_class=7 is closer, but you tell us that won't be rendered.

No, I didn't. What made you think like that?

Please read again rendering section. I haven't said that anything would not be rendered, it's rather about rendering priority and testing how would this particular idea work in practice.

Planned rendering changes of protected areas 9 months ago

Please don't try to alter what's on the ground to make the rendering prettier.

I don't even plan to move away from home, let alone change some objects on the next continent...

The state of conservation areas in the world seems to be quite complicated and my ambition is rather to make it sane in general. I don't even have a hope to make it "pretty".

Planned rendering changes of protected areas 9 months ago

Thanks, that's another thing to test...

I will start with using different zoom levels, but most probably there will be more than just one change.

Planned rendering changes of protected areas 9 months ago

We already have keys for ownership - no need to introduce anything new and mix it with other features.

We have the name of the owner (I guess you mean operator= tag), but it does not tell if it's private, governmental or something other. That's why governance_type=private_landowner is needed.