Porting some french-style solutions [meta-issue] #1402
Comments
https://github.com/cquest/osmfr-cartocss
The main technical difference is they have a database with hstore, which we don't have yet. |
|
cc @cquest It would be nice if we could pull commits from one project to the other. Don't know if it's feasible. For reference, the diffstats are +10k -5k one way and +18k/-2k. |
|
Pick all the cherries you want ;) When I forked and started add my own stuff, I was not familiar with git. For the low level zooms, I'm planning to rework on it, to speed up Le 18/03/2015 19:17, Paul Norman a écrit :
Christian Quest - OpenStreetMap France |
|
Regarding introducing new SVG shop icons (if desired) I think we should not add new SVG icons that are not pixel-aligned. And I don't say this because I would want to design all of them myself. I'm also not sure if "flooding in" new shop icon tickets will increase the likelihood of them being introduced, just a thought. |
|
We added generic shop icons to avoid having to add new icons for every shop. I'm considering if the 16 new issues should be closed. |
|
@nebulon42: My feeling is that they are good enough for me on French OSM (I don't know if they are pixel-aligned so call it a blind test of quality), so I prefer having them as they are and then correcting/replacing if not satisfactory for anyone else. |
|
@pnorman: I thought generic icon was introduced to avoid giving too high visibility to "not correct" shop types and make mappers try harder than "shop=yes/whatever" and I consider it smart move. But what is the real problem with adding more (even "correct") icons? Is it purely technical, political or practical maybe? |
Personally I would be happy with adding more icons. I have never fully understood the argument against adding more icons, but maybe @pnorman or @gravitystorm can repeat the argument once more (perhaps in #660). By the way, I think this topic is very useful, thanks @kocio-pl for opening it! |
|
I also would be happy with adding new, clearly recognizable icons for popular shops (2000+ uses) that are well defined without tagging conflicts (no icons for shop=seafood and shop=fishmonger) and have a definition on wiki. |
Why so cautious? I also don't think it would at all! Please don't treat me like project spammer or what. It was only having the icons that are ready to be used which made me think it's worth creating all the tickets. I really appreciate the time of developers spent on making rendering better (including you!), so I try to open the tickets only when I'm sure there are strong merits to do so. And this one was no other - just incidentally this time I had a lot of such (IMO!) strong cases. The number is irrelevant here, only the justification. Maybe I made it too fast - sorry - but after @pnorman said no single word against them and @cquest gave us the green light, I thought now we're on a safe ground. So I cherry picked all the low hanging fruits. |
|
Relax, I didn't say anything about Spam. |
|
2015-03-19 0:28 GMT+01:00 math1985 [email protected]:
I agree. I believe the reluctance towards adding more icons is grounded in |
|
The legend in itself is very basic. Even the features included there - like areas - are hard to recognize, since they are presented only as a color bar with no important details (trees in the forest, dashing in allotments). Some other features like parkings, single trees, bollards, gates or proposed highways are just absent. The same for any font style. As of now we also don't have any icon in the legend (railway station and peak being the only exceptions), so nothing new - no matter how many do we render, we already depend entirely on their recognizability. |
|
I have icons for another 8 popular shop types ready. But before proposing PRs I'd like to have the green light from maintainers that this will be probably considered for merge as there seem to be 2 in favour, 2 against additional shop icons. There have been two additional shop icons lately and one being currently proposed. Shall I go ahead with this? |
|
I'd rather say 3-5 in favour: 3 for sure (me, @math1985, @matkoniecz), 2 most probably (@dieterdreist and you, I guess =} ). But still the simple voting count is of no use if @gravitystorm alone would oppose - that would be 3-5 vs infinity probably. ;-) |
|
Indeed, this is not a democracy, and I'd prefer if decisions were based on convincing arguments rather than vote counts. It's a shame @gravitystorm has not had time so far to join this discussion. |
Generally they're too detailed. |
|
|
User Wuzzy really pulled up and now there's a Wiki page for standard tile layer. It is not complete yet, but I guess we should use them as a simple documentation for what osm-carto does render and probably mention it in the Readme. More informations can be found in this message on a general Talk list. |
|
@kocio-pl: Could you please update your list and cross out things that have been done already? This would make it easier to see what is still open. |
|
Sure - I guess I've checked all resolved (or mostly resolved, as shop=beverages is still below 10k uses and I don't think it's that important) items. |
|
Do we plan to touch any issues I mentioned here other than just icons (namely I. Low zoom level and II. Middle/high zoom level) or they are too broad or we have any other problem with them? |
|
As far as I'm concerned we could leave the issue open. |
|
the lines on sport pitches (#1126) could be added to the list. |
|
Thanks, I added it and some checkers too. I thought nobody else is interested, since there was no discussion on those "other" topics, but if we don't give up the idea, I'm happy to keep those things open and track the progress. Given that @cquest is following and open for code migration, we can discuss some details with him, but first we should decide what we want to have at all, what could be done first and what we want to be done differently. |
|
I'm interested (but lack spare time to actively work on it at the moment). |
|
Thinking about it, with the french style using a JSON MML and us using YAML, moving code over is basically impossible, as we'd need to rewrite any layers |
|
Code porting can be a problem then, but we can still use some of their ideas if we like them or just take the inspiration. I was surprised nobody commented their rendering for a start. |
This is interesting for me, as I'd like to take care of low levels here. What is the current state of this idea? |
|
I've paused on working on the french style for the moment. |
|
This is also interesting thing for me. 😄 If you will have some links to try or even half-baked conclusions, I would be happy to hear about it too. |
|
Some more interesting features may be found in a special guide. |
|
There are some new changes in French style, in case anybody is interested: https://cquest.hackpad.com/Rendu-OpenStreetMap-FR-v2017-PYR3VV1ZrSe |
|
I feel that porting is not a way to go - I learned a lot about this style and I don't need separate ticket for finding interesting solutions, so I'll close it now. |
I'd like to have multiple French-style ( http://tile.openstreetmap.fr/ ) solutions, which I consider good, in the osm-carto. I don't know if that's always technically feasible, because I'm not sure what infrastructure are they using ( https://github.com/osm-fr/layers-mapnik-styles maybe?) and if the license is compatible, but maybe sometimes it would be just simple code porting. We already have French-style tree rendering issue ( #978 ), so I want more of their good stuff.
This should be cut into specific issues eventually, but here we can identify them at general level and make early decisions before flooding the board with multiple issues.
I. Low zoom level
text-label-position-tolerance), so they don't overlap city labels - especially capitalsII. Middle/high zoom level
III. High zoom level
POI icons we could use:
The text was updated successfully, but these errors were encountered: