[OBO MykoMap] Add the ability to filter by postcode outer code

[ColmDC]

Record time against [OBO MykoMap] project.

Description

On the OBO map, add a filter which enables filtering out only entities within a specified Oxford outer postcode.
This is a range from OX1 to OX49, but with gaps.
This only needs to work for the OBO map, but when designing a solution, consider if it can be easly made generic.
Try and avoid requiring the addition of new fields in Airtable

[ColmDC]

Consider manually creating a vocab with all the Oxford postcodes present and in the data factory adding a new field and populating it when a well formed postcode is present in the OBO data from Airtable.

To make this generic, the vocabulary would need to be dynamically created each time data was processed and only displays outer post codes present in the data.

[lin-d-hop]

Hi @ColmDC
This issue needs to be clarified before development.

Do you mean:

In the MM search panel, add a additional filter drop down called 'Location' with the options 'Inner Oxford' and 'Outer Oxford'.
The search will be based on postcode of the organisation. If the postcode starts with OX1 to OX49 then the organisation will be returned within the 'Inner Oxford' filter. Otherwise it will be returned within the 'Outer Oxford' filter.

Question:
When you say 'there are gaps' do you mean:
a) Some postcodes in the OX1-OX49 range are actually in outer Oxford or
b) Some postcodes in the OX1-OX49 range just don't exist?

[ColmDC]

To be more precise I should have used the term Outward code.
"The outward code is the part of the postcode before the single space in the middle."
https://en.wikipedia.org/wiki/Postcodes_in_the_United_Kingdom

The Inward code is not used at all.

So

In the MM search panel, add a additional filter drop down called 'Location' where the options are all the valid Outward Oxfordshire Postcodes'.
https://en.wikipedia.org/wiki/OX_postcode_area
The search will be based on postcode of the organisation. If OX1 is selected, say, all the organisations with OX1 as the Outward part of their postcode will be selected.

Question:
When you say 'there are gaps' do you mean:
a) Some postcodes in the OX1-OX49 range are actually in outer Oxford or
b) Some postcodes in the OX1-OX49 range just don't exist?

b) There are some strings in the range OX1-OX49 that do not correspond to any postcodes. OX6 and OX8 for example.

[lin-d-hop]

Okay, so you would like:

• the filter drop down to contain a list of all outward codes that exist for all the enterprises on the MM.
• A user can select multiple outward codes and only organisations matching these outward codes will be displayed.

Does that sound right?

[wu-lee]

Note, something similar to this was already implemented on the original "owned-by-oxford" map, here:

https://maps.solidarityeconomy.coop/owned-by-oxford/

(The Owned by Oxford map was bifurcated into a "public" and a "private" fork, the original effectively becoming the "private", which hasn't had anything done to it for some time as all the work has been on the "public" fork.)

But in any case, my point is that I think we might be able to do this the same way (to be more accurate: the private map did something else, but we could do it the same way which later versions of the public map did it.)

It can be done using a "custom" field which is one with a value generated by a function from other fields, something Mykomap already supports. It splits the postcode in two, and inserts the first half. This is then treated like an ad-hoc vocab (meaning one which has no formal definition - it's just values which indicate some category, the set of which are inferred from the data).

That last point is a caveat: it's not an actual vocab field, and in the current Mykomap implementation "custom" fields only work like "value" fields, not "vocab" fields. So by using this method we'd:

• not have any means of translation, and
• the use of ad-hoc vocabs needs to be fully supported
  (That second point is there because IIRC there might have been some - deliberate - loss of functionality in some of the refactoring of MM which we'd need to check was rectified later, and rectify if not).

We may wish to add support in MM for "custom" fields which work like vocabs, which would remove the caveat.

Alternatively, we could implement this in the data factory - which can generate data fields however we want, including by computing things from other fields.

Another alternative might be to do it the CSV translation code, as the OBO data stopped using a triplestore as its source some time ago.. This could also generate simple computed fields like this, although perhaps with some custom extensions in the OBO source code.

Which is best? I'll need to think about the pros and cons.

[ColmDC]

There are a few ways to skin this cat, which we can look at when we decide to do it. For now, do we think the requirement is clear enough?

"A user can select multiple outward codes .. "

We have never supported multiple selection of filter options. This might be a nice extension of MM in general, but not part of this requirement.

[wu-lee]

The immediate snag for this is that the current version of MM does not support filters on non-vocab fields (which the shortenedPostcode - the outer postcode field - is not).

To make this easy, we need to add back ad-hoc vocab support. DigitalCommons/mykomap#201

In the mean time it can be supported but at the cost of making the field a full vocab field, which involves using (abbreviated) URIs as values and creating a vocab index with translations for them to reference. (This is an example of a case where that's not inherently necessary or helpful. Also not simple, as we'd need a comprehensive list of outer postcodes.)