Browse icons as svg #5080
Browse icons as svg #5080
Conversation
Should they? How about landuses, for example? |
|
I believe the current icons originate from osm-carto, and are mostly 9-10 years old. In the meantime, carto has moved from png to svg, and updated some of their icons. In a way, this PR is catching up with changes in the default style. Landuse is a good question. I would do them in a second step, once the node icons have been migrated to svg. We don't have to do everything at once. |
Why not inline |
mmd-osm
force-pushed
the
patch/browsesvg
branch
from
eeab529 to
e3db323
Compare
|
This seems like a good idea. Would you use some Gem for it, like https://github.com/jamesmartin/inline_svg and change the browse view / browse_helper.rb accordingly? Do we already have something similar in the code base today, which we could reuse? |
mmd-osm
force-pushed
the
patch/browsesvg
branch
4 times, most recently
from
83483af to
983f066
Compare
|
@AntonKhorev : Just for clarification: is this the approach you had in mind? https://stackoverflow.com/a/68569598/3501889 It seems the target svg need to include a "fragment identifier" to make this work, which is currently not the case for the carto svg files. See https://stackoverflow.com/a/72140723/3501889 I tried these changes in a browser window by adding the svg to the DOM, and it works fine. Changing colors is also much easier now. By the way, the inline_svg gem is loading the file when rendering the page and injecting the contents into the HTML document, which is not great for caching. |
mmd-osm
force-pushed
the
patch/browsesvg
branch
4 times, most recently
from
b6cea61 to
61867fc
Compare
|
I wanted inline svg with a bunch of openstreetmap-website/app/views/directions/search.html.erb Lines 3 to 78 in 59571f8 |
mmd-osm
force-pushed
the
patch/browsesvg
branch
from
61867fc to
37984a5
Compare
|
Thank you for the details the inline approach! I think it would be a bit challenging to always include all symbol svg files in the browse page due to their total size (around 200K). I thought about adding some configuration table to move most of the logic from browse.scss to a yml file (at least for svg). For this purpose I have introduced a new config/browse_image.yml, and the corresponding initializer in config/initializers/browse_image.rb. (see most recent push). In some cases the same image is used for different tags, so we would need some sort of configuration anyway to map tags to svg images and define how they should be filled. In the next step BROWSE_IMAGE can then be used in helpers/browse_helper.rb to find out if an SVG exists for a "{key}_{value}", and then use the external_svg approach I mentioned in my previous post. In browse_helper.rb something similar to the following would be needed. Also, we would need to define some css classes for the new svg images. elem_icon = icon_tags(object).map { |k, v| "#{k}_#{v}" }.last
elem_icon_detail = BROWSE_IMAGE[elem_icon.to_sym]
external_svg(elem_icon_detail[:image], elem_icon_detail[:fill]) if elem_icon_detail def external_svg(identifier, fill, attributes = {})
file_name, fragment = identifier.split("#")
fragment ||= "icon"
attributes[:xmlns] = "http://www.w3.org/2000/svg"
attributes[:class] = fill
file_name = "browse/#{file_name}"
content_tag :svg, attributes do
tag.use :href => "#{image_path(file_name)}##{fragment}"
end
end |
mmd-osm
force-pushed
the
patch/browsesvg
branch
7 times, most recently
from
d772ead to
0fcdb3d
Compare
|
I believe the code should be good for another review. The screenshot below shows mixed svg/png rendering (1 png, rest is svg). The exact symbol location probably need some further tweaking in CSS. Also, the code in browser_helper.rb might need some improvements. Focus right now should be that we're ok with the approach.
|
mmd-osm
force-pushed
the
patch/browsesvg
branch
2 times, most recently
from
96ae532 to
eb714c5
Compare
If they specify path coordinates to a millionth fraction of a pixel, it's not surprising. |
mmd-osm
force-pushed
the
patch/browsesvg
branch
from
eb714c5 to
e48f5f1
Compare
Ok, I think you would need to further elaborate on your proposal, because it’s still not clear to me how this looks in detail. Please provide some working code snippets which addresses both position and coloring of svg. Also some comment why it is better or what issues it solves. We can then look into this in more detail and work out the best approach. |
|
Here's another comparison at 250% zoom. The old rendering looked a bit off, in particular for the (part of ways...) section.
As mentioned earlier, the new icons + colors are based on https://wiki.openstreetmap.org/wiki/OpenStreetMap_Carto/Symbols. It is expected that some of them differ from the old ones. |
Reformatted version of https://wiki.openstreetmap.org/wiki/File:Highway_mini_roundabout.svg without the white background
mmd-osm
force-pushed
the
patch/browsesvg
branch
from
be6f334 to
ef1810f
Compare
Rescale golf svgs to 14
Multiple icons can be stored in a single .svg file, with #... denoting the respective icon.
mmd-osm
force-pushed
the
patch/browsesvg
branch
from
ef1810f to
efe3657
Compare
Generated by 🚫 Danger |
#5385 as a first step in replacing css backgrounds with images. See how I only use one pixel value of 20px / 1.25rem.
Part of ways I'd do them completely differently, see #5317. |
The browse icons haven't been updated for quite some time and are still served as PNG icons. As the icons should reflect the current carto style, I copied a fair amount to this PR, and added some coloring similar to amenity-points.mss.
One of the design goals for the conversion was to use osm-carto svg files as-is, and at the same time use svg files as < img >, rather than inlining them. This has some implications on coloring: color values need to be translated to a filter, for which i used https://blog.union.io/code/2017/08/10/img-svg-fill/ + https://stackoverflow.com/questions/24933430/img-src-svg-changing-the-styles-with-css/52041765#52041765
Before converting more icons in browse.scss + common.scss, I wanted to get some feedback if the overall approach is sound. As an example, for the fill parameter I tried "#666666" as parameter value, as well as the original color descriptions from osm-cargo (e.g. "amenity-brown"). I find the latter a bit easier to understand.
Please take a look, and let me know how we should proceed.