OpenStreetMap

kocio has commented on the following diary entries

Post When Comment
OpenStreetMap Carto release v4.7.1 3 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 3 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 4 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 4 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 4 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 4 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 5 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 5 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 5 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 5 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.

Planned rendering changes of protected areas 5 months ago

For me there are more problems: - tags fragmentation - lack of clear classification system - borders clutter - labels clutter (as shown on your rendering)

My questions: 1. Maybe skipping borders would help, but when should they appear? 2. But you also show some border here - how did you select just the outer one?

Legende für die Standardebene 5 months ago

Thanks for this work!

I have updated it lately and there are still some things missing, but it is the most comprehensive key that we may have. I doubt that we could do that in the automated way.

Hail Hydra(nt)! - GenSan edition 9 months ago

In Poland we're using special app for hydrants surveying:

There are also special sites for viewing them:

OpenStreetMap Carto v3.0.0 over 1 year ago

To be more precise: subway entrances refs are rendered now.

Please add population numbers to places over 1 year ago

Hangzhou and Xuzhou are now visible, I guess - there were just some problems with the proper code, which were fixed in v2.44.1.

I think adding population numbers would be an overkill for a general map.

One Does Not Simply Walk into Mordor... over 1 year ago

There are also other places called Mordor, I don't know if these names are real or fake:

http://www.openstreetmap.org/way/409822789 http://www.openstreetmap.org/way/324839921

CJK fonts missing in standard layer (follow-up) over 1 year ago

That's probably problem with mod_tile not processing TTC file format.

GSoC'15 Project update over 1 year ago

Is it still a proof of concept or there's a chance to have it deployed?

OpenStreetMap Carto release v2.42.0 over 1 year ago

Quite fast, looking at last two versions it was up to one day:

https://github.com/openstreetmap/chef/issues/70 https://github.com/openstreetmap/chef/issues/71

For new version deployment watch this issue:

https://github.com/openstreetmap/chef/issues/75

New road style for the Default map style - the second version almost 3 years ago

Can you maybe give an example where this happens? It is worth testing.

Just a quick search.