Show icons for POIs, even if there isn't room for labels

[bryceco]

Currently we display labels for some shops, but other shops get neither a label nor an icon. We should ensure that every shop (possibly every POI?) gets at minimum an icon.

[ZeLonewolf]

I believe this is a duplicate of #692. Most POI icons have not been implemented yet.

[bryceco]

Could we have a placeholder icon (like a dot) for things without an implemented icon? That would make it obvious when a POI is waiting on #692.

[wmisener]

"Every POI" is probably a bit too much of a can of worms (no renderer shows everything that one could add as a point to OSM, except maybe the editor interfaces like iD), but I think a general shop=* icon could be useful and go a long way toward addressing the emptiness that I think is bothering @bryceco. shop=* values have such a long tail of uncommon values anyways that a fallback rendering will probably be needed regardless.

One difficulty is that the OMT schema splits the OSM shop tag into multiple classes. Some have class shop, but other classes also contain places normally considered 'shops' colloquially, like alcohol_shop, clothing_store, grocery, etc. We'll have to make sure to check all reasonable values are covered if we implement a fallback.

A dot could work for shops, as could a nondescript shopping bag or something.

I'm not sure the other POI classes, like anything tagged amenity=* or something, would benefit as much from a consistent nondescript treatment, as they might represent too many possibilities and become more confusing than they are clarifying. Then again, a labeled black square representing "there's something here" has a long and proud tradition in American city maps...

[1ec5]

even if there isn't room for labels

Depending on the icon, I might quibble with this point. osm-carto’s fallback dots have always felt like a tease to me, even though they’re very useful in some mapping workflows. I’d imagine that part of the reason for those dots was the limited zoom levels that could be rendered. But this map can go beyond vector zoom level 20, which would be plenty enough to ensure that every POI we intend to label can have a text label as well as an icon.

[bryceco]

I understand. I'm not 100% clear on the goals of the project: At #88 (comment) @ZeLonewolf talks about it being a map primarily for navigating spaces (like a traditional non-OSM map), but the README says: "Promote collaboration and common purpose in OpenStreetMap’s American mapping community" which indicates it's at least partially intended for mappers.

For my purposes I want a map style suitable for people looking to edit the map (like OSM Carto). Vector OSM Carto is coming eventually so there are other options if that's out of scope for this project.

[1ec5]

Yes, many of us use this map day to day in our mapping activities, but the style is a bit too polished to serve as a raw view of the map. I find myself using the tile inspector almost as often.

The nice thing about a vector style is that you can easily tweak it either when building the stylesheet or at runtime. Since you need a more maximalist view of whatever is in the map data, maybe you could remove filters at runtime. We could make that easier for you by defining let expressions that you can manipulate rather than digging down into nested expressions. But if you’re willing to generate a style JSON yourself, we could even just put all the filters behind a flag that you can disable.

Ultimately, though, this style is inherently limited by the upstream decisions in OpenMapTiles about which features to include at which zoom levels of tiles. The same will be true of any OSM Carto replacement based on the Shortbread schema. Go Map!! doesn’t have the same constraint, because it’s working with a raw cut of OSM data.