Page MenuHomePhabricator

Update to latest maki
Open, Stalled, Needs TriagePublic

Description

Background

Although the documentation says: https://github.com/mapbox/simplestyle-spec/tree/master/1.1.0 maki icons will be supported as markers, there are some maki icons not supported.

e.g. mountain, which is essential as there are many articles on mountains and this is the natural icon, I guess.
(same for volcano, stadium, castle)

See https://de.wikipedia.org/wiki/Hilfe:Kartographer/Maki_Icons#/maplink/0 for the gaps. (generated with <maplink> iterating over all the icons)

Challenges

It seems like makizushi is only worried about mapnik upgrades and it's becoming deprecated. Therefore, makiwich is going to be the successor map marker creator.

With the current stack is not possible to have the latest maki running, unless we migrate to libraries that use makiwich. That is also a problem because we have third-party libraries relying on makizushi, like geojson-mapnikify which is a dependency for tilelive-overlay, and they are following the same path as makizushi.

It's a considerable change of codebase that we are not able to work right now.

This task was mentioned at the 2021 Community Wishlist Survey (https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2021/Miscellaneous/Kartographer_icon_improvements), which got the No. 41 out of 268 proposals, with 59 votes.

Event Timeline

MaxSem renamed this task from Not all maki icons supported to Update to latest maki.Sep 12 2016, 11:00 PM
MaxSem added a subscriber: MaxSem.

makizushi still uses maki 0.5.0, so we need to either contribute a patch upstream or fork (this is much more complicated than just updating version number due to massive changes in maki 1.0).

MSantos changed the task status from Open to Stalled.Sep 18 2018, 10:07 PM
MSantos added a subscriber: MSantos.

It seems like makizushi is only worried about mapnik upgrades and it's becoming deprecated. Therefore, makiwich is going to be the successor map marker creator.

With the current stack is not possible to have the latest maki running, unless we migrate to libraries that use makiwich. That is also a problem because we have third-party libraries relying on makizushi, like geojson-mapnikify which is a dependency for tilelive-overlay, and they are following the same path as makizushi.

It's a considerable change of codebase that we are not able to work right now.

This might be easier to do now that npm has aliases perhaps ?

Throwing links in:

https://github.com/mapbox/makiwich/blob/master/package.json#L12 lists "@mapbox/maki": "^4.0.0" as dependency.

https://github.com/mapbox/makizushi/blob/master/package.json#L12 lists "maki": "0.5.0" as dependency.

That is also a problem because we have third-party libraries relying on makizushi, like geojson-mapnikify

https://github.com/mapbox/geojson-mapnikify/blob/master/package.json#L32 lists "@mapbox/makizushi": "^3.0.1" as dependency.

MSantos updated the task description. (Show Details)
Em updated the task description. (Show Details)

Just a note. These icons were basically part of the mapbox api. If we want to keep them and also update them, this should probably become a simple microservice alla:

https://maps.wikimedia.org/poi-icons/alias
https://maps.wikimedia.org/poi-icons/maki/v0.5/iconname
https://maps.wikimedia.org/poi-icons/maki/v1.0/iconname
https://maps.wikimedia.org/poi-icons/wmf/v1.0/iconname

Where iconname is basically an api for makizushi compositing: base-symbol-tint-size-retina
And alias would point to familyname/iconname

And a json mapping table in the service config of alias names to icons, where alias is the name of icons as used in our JSON fragments and they then point to the actual versioned icon that we want that alias to target.

That way we can make sure our json doesn't break etc. and we can add our own icons when we want. It's a bit similar to how we switched from geshi syntax highlight names to pygments as well. And you could even use specific icons from the json fragments by including them as 'wmf/v1.0/garden' if you want something other than the default alias.

Ideally we'd also include some marker in the json to indicate that we are using this as an icon api.