New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Locate map pins by indexed WKT #336
base: 3.x
Are you sure you want to change the base?
Conversation
This removes the requirement for an entity load of the geo entity. It enables the possibility to show multiple locations per directory item as #333.
Question: as it's quite good to get rid of those entity loads, should we write an update hook as well? It's presently just new installs. |
This is the same change BHCC is making to support multiple geo locations for each directory entry. |
Tested locally and this works for me. To test multiple locations on a directory venue, needed to edit the field to allow mutliple. Got some warnings when enabling the localgov_demo module, like this:
Is that something we want to look at? |
If the maps with areas are also changing - they will be I think - then yes... because that's what that is. Realistically different storage/display for the areas would be best; but the quickest (config wise, not perforance) might just be changing the field type to accept something huge |
@ekes discussing on Merge Tuesday, might be nice to store as geojson... |
Interestingly because of the way the field is loaded (I'm trying to look if this is leaflet or search_api) it is then grabbing it from the entity. So for the original context of this issue being able to show results from multiple delta location fields, the fact it indexes nothing, isn't an issue 🤯 So it's an improvement. Keeping it as a string also makes sense, because fulltext tokenizes it etc. and puts it into the fulltext index which we for sure don't want. Fixes the original requirement. But it isn't then a performance improvement. Doing it from indexed data, and indexed data that's already formatted to json would be for sure a win, but it's also quite some more work. It needs both making sure that the db (it's not a solr problem) will store the length of data (and not handle it as tokenized text) and be sure that leaflet will get it from the search result directly. |
I'm having issues with this branch when I actully try and add a second geo to a directory. The SQL query for the location search gets changed (thanks to dumping a dqm inside search api db). SELECT DISTINCT "t"."item_id" AS "item_id", '1000' AS "score", ST_Distance_Sphere(Point('-0.1400561', '50.8214626'), ST_PointFromText(t.localgov_location)) / 1000 AS "localgov_location__distance"
FROM
{search_api_db_localgov_directories_index_default} "t"
WHERE "t"."localgov_directory_channels" = '21'
HAVING "localgov_location__distance" < '2' But once a second geo is present, it is changed to: SELECT DISTINCT "t"."item_id" AS "item_id", '1000' AS "score", ST_Distance_Sphere(Point('-0.1400561', '50.8214626'), ST_PointFromText(t.localgov_location)) / 1000 AS "localgov_location__distance"
FROM
{search_api_db_localgov_directories_index_default} "t"
LEFT OUTER JOIN {search_api_db_localgov_directories_index_default_localgov_loca} "t_2" ON t.item_id = t_2.item_id
WHERE ("t"."localgov_directory_channels" = '21') AND ("t_2"."value" < '2') |
Possibly related to this https://www.drupal.org/project/search_api/issues/3353060 ? |
Thanks @ekes, do we use those patches? I could try on of them and see if it resolves. |
I'll be honest I forgot I'd been working on it till you mentioned it there. So not sure if we did start testing them with LGD, the multivalued field only being an issue here more recently. Testing them, feeding back on the issue, and answering any of Thomas' questions that we can would seem a very good _thing_™ at this point. Sorry I'd forgotten about them. |
Discovery written up and patch added here https://www.drupal.org/project/search_api/issues/3353060#comment-15459294 |
Suggest we make a follow-up issue for this one. It won't be possible to remove them from the search results, because they come from a result - basing it on an index of locations with attached services would be solve it for the map, but would make it different from the results below which are directory entry based, so not work in this case. So either filtering the results post query, or centring the map in JS on the search point leaving the additional result outside the zoom, seem the two best options. |
Still hoping for some testing from @stephen-cox and me! @finnlewis Note: we are using this at Greenwich as a patch. |
@andybroomfield confirmed that this is working at BHCC @stephen-cox was going to test this... might you have a chance to review this week? |
Heres the actual errors from running PHPunit against this branch locally
|
This removes the requirement for an entity load of the geo entity.
It enables the possibility to show multiple locations per directory item as #333.