[OBO MykoMap] Publish July 2024 Release of Map

[ColmDC]

Record time against OBO MykoMap Clockify Project

• [x] Confirm data is flowing through from Airtable
• [x] Ensure no really bad geolocations
• [x] Check configurations in current live version to bring across (like logo)
• [ ] Get approval from client for version on dev
• [ ] Move maps to maps.coop
• [x] Change config to use correct vocab for directory Panel
• [x] Change load script so that if there is no postcode or street address provided, no address is created, so the entity can be treated as having no address.

[ColmDC]

@wu-lee - OBO currenlty uses 3.0.8

Going to @3.1.6, https://dev.maps.solidarityeconomy.coop/obo-public/ we still have the markers coloured, but as we have the Nature of Organisation vocab in the directory, its not clear if the colour key is still working in the Directory panel.

Will we loose the marker colours if we upgrade to 3.1.18, to get the #co-ops filtered. (This is not an important fetaure for OBO at the moment.)

[ColmDC]

@wu-lee can you see any reason why there are 9 orgs with very different addresses clustered around the Tap Social

Tap Social, Unit 27 Curtis Industrial Estate North Hinksey Lane Oxford OX2 0LX

which is not positioned correctly either.

[wu-lee]

Will we loose the marker colours if we upgrade to 3.1.18,

The newest MM version (with counts) is 3.1.7 I think?

However, I think marker colours depend on initiatives having a primaryActivity field. which they will still have. (This needs to be unhardwired, but I don't believe that has been yet)

A coloured directory depends on the directory being set to the primaryActivity field, which it currently isn't because they want natureOfOrganisation at the top of the filters. (See https://github.com/DigitalCommons/mykomap/issues/235)

Following the thread from that issue (via https://github.com/DigitalCommons/mykomap/issues/237) it seems that the issue for decoupling the choice of directory field from the choice of the first field is this: https://github.com/DigitalCommons/mykomap/issues/248 - and is still outstanding.

[wu-lee]

can you see any reason why there are 9 orgs with very different addresses clustered around the Tap Social

Looking at the contents of standard.csv, they all have the same geolocation, and they all have sketchy Geocoded Address fields, which I infer get mapped to a generic "Oxford" location.

Top Social's address is sketchy because it has "Tap Social" in it - organisation names confuse the geocoder. The others are all "Oxford, Great Britain, ". Looks like the postcode isn't being taken into account.

Identifier	Name	Latitude	Longitude	Geo Container Latitude	Geo Container Longitude	Geo Container Confidence	Geocoded Address
KkO9rivAR55rm7	Mothers 4 Justice Ubuntu			51.746972	-1.228659	100	Oxford, Great Britain, OX1 1SS
N7r4MZoYLjDhtv	Young Women's Music Project			51.746972	-1.228659	86	Oxford, Great Britain, OX2
NhZhv3IjvIsfwP	Low Carbon West Oxford			51.746972	-1.228659	73	Oxford, Great Britain, OX2 0ET
St9YYJAsjO9iP4	Woodcraft Folk			51.746972	-1.228659	73	Oxford, Great Britain, OX4 1JA
fQLgIDodLAbr7L	Red Learning Coop			51.746972	-1.228659	86	Oxford, Great Britain, OX1
mhPRVJqMXN1qv9	Oxford Community Action			51.746972	-1.228659	73	Oxford, Great Britain, OX4 3LN
oT1GG0G8wjSLhl	Wellbeing Cooperative			51.746972	-1.228659	100	Oxford, Great Britain, OX4 3JR
vahghtpkk6Uzah	Tandem Collective			51.746972	-1.228659	86	Oxford, Great Britain, OX4
xKT58EV0NLUsom	Tap Social			51.746972	-1.228659	25	Tap Social, Unit 27 Curtis Industrial Estate;North Hinksey Lane, Oxford, Great Britain, OX2 0LX

[ColmDC]

Why would it ignore the postcode? Bizarre that they all ended up at that same address! And there is a co-op that is on that road. Navigate Cooperative.

[ColmDC]

The newest MM version (with counts) is 3.1.7 I think?

Yes. My typo. Sorry.

[ColmDC]

DigitalCommons/mykomap#248 - and is still outstanding.

So it is. Not sure why I thought it had been done.

[wu-lee]

Reordering the address fields so that the Geocoded Address has the postcode before the country improves things slightly - the list of ones mapped to the generic Oxford location is shorter:

Identifier	Name	Geo Container Latitude	Geo Container Longitude	Geocoded Address
N7r4MZoYLjDhtv	Young Women's Music Project	51.746972	-1.228659	Oxford, OX2, Great Britain
fQLgIDodLAbr7L	Red Learning Coop	51.746972	-1.228659	Oxford, OX1, Great Britain
vahghtpkk6Uzah	Tandem Collective	51.746972	-1.228659	Oxford, OX4 , Great Britain
xKT58EV0NLUsom	Tap Social	51.746972	-1.228659	Tap Social, Unit 27 Curtis Industrial Estate;North Hinksey Lane, Oxford, OX2 0LX, Great Britain

Tap Social isn't improved. Experimenting with the GeoAPIfy playground, the problem goes away if I tidy it, remove the organisation name, and "Oxford". Last point seems crucial as GeoAPIFy's result puts it in Vale of White Horse, not in Oxford. The result isn't very confident even then: 50%. There are two other candidates, which seem both to be for Curtis Industrial Estate (Amenity vs Suburb).

I've not actually pushed that change however, as I haven't checked what it does for the other locations - they might be worse. First option might just be to improve the addresses on these ones?

[wu-lee]

DigitalCommons/mykomap#248 - and is still outstanding.

So it is. Not sure why I thought it had been done.

I think it got closed - but not because it was done, it got superceded.

[ColmDC]

There are two other candidates, which seem both to be for Curtis Industrial Estate (Amenity vs Suburb).

It is in that estate. It's my local, would you believe it.

[ColmDC]

So

51.746972	-1.228659

is the heart of Oxford according to geoapifi!

[ColmDC]

DigitalCommons/mykomap#248 - and is still outstanding.

So it is. Not sure why I thought it had been done.

So let's drop that requirement. Let's see if the others are straight forward.

[wu-lee]

• Check configurations in current live version to bring across (like logo)

I'm trying to establish what configurations these might be... can you point me somewhere? I don't see anything about a logo in any of the OBO issues, for instance.

[wu-lee]

• Change load script so that if there is no postcode or street address provided, no address is created

Just checking that's definitely an "or" - not possibly an "and"?

[ColmDC]

I don't see anything about a logo in any of the OBO issues The map used to have an OBO logo in the top right hand corner, but it seems to have been lost in previous upgrade and no-one noticed. Might it be in a repository somehwere. If you can't find it easily I'd ask CAG about it. There are non translucent ones on their website. Can't see a translucent one.

[ColmDC]

I'm trying to establish what configurations these might be... can you point me somewhere? I

What I mean is, use the config settings like default open panels, zoom debt values etc, used in the current public one, unless it has been deliverately changed as a result of resent work.

[ColmDC]

Just checking that's definitely an "or" - not possibly an "and"?

Change load script so that if there is neither a postcode nor a street address provided, no address is created.

[wu-lee]

I don't see anything about a logo in any of the OBO issues The map used to have an OBO logo in the top right hand corner, but it seems to have been lost in previous upgrade and no-one noticed.

I can't find a logo in the OBO map repository at all, at any point. There aren't any other Owned by Oxford map repositories, so I think that means there hasn't ever been one?

Is the one you mean this one? (I don't recognise it, which also makes me think it's never been added.) It has transparency.

There's also this one (no transparency):

And this, which has transparency:

As I don't expect you know what CAG prefer, going to use the first one until someone tells me otherwise.

[wu-lee]

• Logo added as per above.
• Data conversion altered to omit a geocoded address and location if there is both no street address and no postcode.
• Extra tidying of address done (whitespace and punctuation removal/deduplication).
• Postcode field inserted before "Oxford" instead of after, in geocoded address. Designed to improve geocoding in those cases where there is just a postcode and no street address, which seem to result in the postcode being ignored.
• The "Oxford" city field is still added uniformly, inferred purely from being a map of Oxford organisations, although this can confuse the geocoder if the organisation is outside Oxford. But I'm not sure if we can rely on the locality being included in the street address? (And GeoAPIfy seems to get it wrong both ways round, .e.g. Oxford, OX4 1JA, Great Britain vs OX4 1JA, Oxford, Great Britain, unpredictably)
• Consequence of this seems to be some orgs now in North America, I think may be one of those wins on swings which loses on roundabouts? It's fiddly trying to track down why these happens, but I would hope that fixing the addresses would be the best first step, and any which still geocode badly can be inspected and possibly have their locations overridden.
• IIRC, CAG wanted the default panel to be the "about" panel, so I've set that (possible in latest version of MM)
• Setting the directory to be the Primary Activity - which will get coloured - as per https://github.com/DigitalCommons/mykomap/issues/235. But at the expense of not having "Nature of Organisation" first in the filter list. Decoupling that will be possible when https://github.com/DigitalCommons/mykomap/issues/248 done.
• Setting the "Nature of Organisation" to default to "Community Enterprise". This appears to be the case on the map currently on dev-1.
• Note this is still outstanding: https://github.com/DigitalCommons/owned-by-oxford-project/issues/30
• And this https://github.com/DigitalCommons/owned-by-oxford-project/issues/32 - which I think might be easiest and most correctly solved by first fixing this: https://github.com/DigitalCommons/mykomap/issues/201

[ColmDC]

Looking good. I think whenever a user sees something badly geocoded where there is not a very obvious fix to be made to the address, we recommend going straight for adding explicit lon/lat. This is what I'd recommend for the latest ones that want to appear in the US.

[wu-lee]

I've added addresses for Woodcraft Folk and Tap Social, and lat/lng for Tap Social and Damascus Rose.

The weird thing about these points is that all but one (Damascus Rose) geocode fine when I run the converter locally. On dev-1, it keeps putting them in the US, even if I clear the entries out of the geocoder cache... they just come back wrong.

Another weird thing is that Blackford Leys Community Larder has what looks like a correct lat/lng put into the spreadsheet, but it's not overriding the geocoding?

And now that I've cleared the cache and corrected some data, there are more pins in North America (were 5, now 7).

Another weird thing, is that some of those manual longitudes in airtable use 1.2 something instead of -1.2 something (which I think are mistakes). I've corrected those identical Blackbird Leys addresses which have identical by negative longitudes. Wary about correcting more of the entries just yet considering the last two points...

It's all super fiddly. Also - just heard from you you're also editing Airtable!

[wu-lee]

Ok, one video call later...

• Airtable was disallowing negative numbers - silently flipping them positive! Config changed for those Latitude/Longitude columns, and positive longitudes negated.
• Another problem in the data factory end: the choice of using the lat/lng values from the editable table fields or the imported "External Intiatives" fields depended on having a non-empty street address in the former. Which was preventing those editable lat/lng values overriding the external initiative lat/lng unless there was a street address. Altered to use the editble lat/lng values unless empty. (And the presence of either overrides the Geocoded lat/lng, as before.)
• Override location added for Oxfordshire Asian Women's Voices and Rose Hill and Iffley Low Carbon
• All pins now in Oxford, UK locality!

[wu-lee]

Note, the prod-1 server's data factory has been hot-fixed not to build the owned-by-oxford dataset until we get a sign-off from CAG that the map/data currently in development can go live.

We need to check with Oli S-B if deploying this data to the production Murmurations servers is ok, as the development data set is.

In the mean time, we don't want this holding up other datasets.

https://github.com/DigitalCommons/coopsuk/issues/22#issuecomment-2211499112