MykoMap markers are all the same colour!

[ColmDC]

Describe the bug All markers now have the same colour.

To Reproduce

1. Go to See https://oxford.solidarityeconomy.coop/map.html for how they should look
2. Go to https://dev.oxford.solidarityeconomy.coop/map.html and you will see they are all now purple

Desktop (please complete the following information):

• PC Windows 10
• Firefox
• mykomap@3.0.6

[wu-lee]

Ok, so the problem is simple:

• the AwesomeMarkers plugin for Leaflet allows a "color" parameter for the icon
• this stitches the parameter string to a base CSS class name and inserts that into the icon HTML element
• the CSS class selects one of the predefined coloured markers supplied with AwesomeMarkers
• Except: mykomap hacks this by supplying the primary activity ID instead of a colour, and defining its own styles to map these to coloured markers
• This broke when activity ID changed from a form like "am60" to a form like "am:am60" (the latter is an abbreviated URI). The CSS class inserted is now no longer one which matches the ones defined

So this can be fixed by adding the right class definitions. However, that would be propping up a hack which in general doesn't work - we should not have hardwired assumptions about using any particular vocabs in mykomap.

This problem relates to an issue which I can't currently find, which notes that we shouldn't be hardwiring marker pins to vocabs like this, and to the issue (ditto) requesting custom marker icons. Fixing this properly would be to address these other issues.

[wu-lee]

Ok, so two choices above: workaround or fix, and it seems a good time to think again about a fix.

So a solution which might work for this and be quick and simple to implement:

• have two reserved initiative field names, say _shape_id and _color_id
• insert those (sanitised for HTML) as classes on the marker element, when they exist
• have these fields be defined in the data, or have a custom field definition in the config which computes them from other fields.
• define some preset colours and shape class definitions, which work out of the box
• allow these to be overridden with custom CSS definitions which can be inserted into the map's index.html page

I'm aware these should ideas should go in the respective ticket(s), I'll need to track those down. I think this would take a few hours work - less than a days'. Fixing this issue would then be a matter of adding a custom field to this map which is computed from primaryActivity.

[edit] On further reflection, I think I should not bake in the assumption of two degrees of freedom (shape and colour), as this may limit us in future. There is a simpler and more flexible way.

• Define a single reserved field, say markerClasses (camel case name to be consistent with already existing reserved fields like manLat)
• If supplied, this should contain a string, which will be sanitised (groups of invalid CSS class characters mapped to a single _) and inserted into the marker's class attribute.
• The string may include spaces to delimit multiple classes.
• Predefined classes should exist for the following colours, the same list of 20 as before, but allow these to be overridden/supplemented by custom CSS supplied in the map.
  • pink, navy, blue, aqua, teal, olive, green, lime, yellow, orange, red, fuchsia, purple, maroon, silver, gray brown, dark, dark-gray, white
• More than one dimension can be added by supplying the dimensions as distinct and non-overlapping sets of class values in this field, and thereby, with the addition of appropriate style definitions, control other aspects of the marker such as shape.

[wu-lee]

Ok, for now I'm going to make a minimal-change workaround fix, and just modify the sanitation code which already assumes a primaryActivities field, and make it strip off leading prefixes like am:. This will restore the colours as they were, but not solve the larger problem.

On reflection, and inspection, I recall from earlier work that we probably need to remove the AwesomeMarkers plug-in and replace it with something which doesn't impose a limit on the number of colours - as we discovered that some of our vocabs have more categories than we do colours. So it seems like this might push the cost of implementing it up higher than seems warranted just for this issue.

This fix will result in a new mykomap version which will need to be deployed on affected sites to fix the issue.

[wu-lee]

And, there are also the side-bar colours to consider. (These get restored with this workaround too, but the proposed fix needs to ensure it fixes this too.)

[wu-lee]

Custom markers epic is here: https://github.com/digitalcommons/allthethings#workspaces/megaboard-639bb01fc526ef0010ab662b/epics/Z2lkOi8vcmFwdG9yL1plbmh1YkVwaWMvMTQzMTE2

[wu-lee]

Fixed in v3.0.8

Limequery maps will all be affected by this, I've bumped the version of MM on the dev version of these to 3.0.8.

• https://dev.oxford.solidarityeconomy.coop/map.html
• https://dev.newbridge.solidarityeconomy.coop/map.html
• https://dev.mersey.solidarityeconomy.coop/

What others? DotCoop don't use primaryActivity, ICA does, but not the same vocab so I think has never fit in with the hardwired assumption of the "Activities (Modified)" vocab. Other newer ones somewhat similar, and so all these could perhaps wait for the proper fix?

[ColmDC]

Also https://maps.solidarityeconomy.coop/obo-public/

I agree, if the limequery and Airtable maps have colour again with this fix, then that satisfies this ticket, and we can leave the other to be addressed by the https://github.com/digitalcommons/allthethings#workspaces/megaboard-639bb01fc526ef0010ab662b/epics/Z2lkOi8vcmFwdG9yL1plbmh1YkVwaWMvMTQzMTE2 Epic

[wu-lee]

Bumped obo-public too (the dev version) https://dev.maps.solidarityeconomy.coop/obo-public/

[ColmDC]

Do we need to wait until https://dev.maps.solidarityeconomy.coop/owned-by-oxford/

https://dev.newbridge.solidarityeconomy.coop/ are bumped to 3.0.8 to close this ticket?

[ColmDC]

Just noticed that the shipshape address for the newbridge dev map is wrong.

[wu-lee]

Newbridge has been upgraded already (see above).

That shipshape thing is odd, don't remember doing that, but on prod-1 there's a symlink from the newbridge domain install to a newbridge subdirectory on the maps domain. Both prod and dev links in shipshape point at the symlinked site on the maps domain.

I've done the simplest thing for now and recreated the symlink on dev-1. So now shipshape finds the site again.

[wu-lee]

https://dev.maps.solidarityeconomy.coop/owned-by-oxford/ seems to be empty.

The directory's timestamp is June 8th, almost the same but slightly after some mykomap site files deployed on the top directory. That suggests to me I deployed there by accident, and then incompletely restored the zapped folders... so, whoops.

I've just redeployed that site - but it's on mm v1.3.1 - it doesn't have coloured pins, but requires upgrading a long way to get to 3.0.8. I should confirm it's worth it before I do?

[ColmDC]

I don't think this multi data set version of OBO, https://dev.maps.solidarityeconomy.coop/owned-by-oxford/ is being used, so good to see it visible from ship-shape but lets put upgrading it on the back burner.

So, happy to close this bug.