Search results map - #1027

Screenshot:

coverage: 98.063% (+0.2%) from 97.861% — julian-schneider:feat/search-results-map into IQSS:develop

@julian-schneider Great work!
If you want to look at the performance you could have look at the stress tests that I did some time ago; you could probably reuse the test data generating Python code and possibly the Jmeter tests.
https://github.com/DANS-KNAW/dataverse-dataset-geomap-view/tree/main/examples/testdata/stresstests

FWIW: Using ?query_entities=false in the Dataverse API is a factor or 10x faster, so unless you needed the added info, I'd definitely add it.

Made some updates, here's a short video showcasing the behavior 🗺️

Note that each dataset's marker is placed in the center of its bounding box (averaged, if it has more than one). These bounding boxes come from the geospatial metadata block.

Initially, the map loads the 50 geospatial datasets that are the most relevant results of the search query. "Load more" fetches the next 50 datasets and adds them into the view.

Regarding performance:

Thanks for linking your stuff @PaulBoon! I've used the data generation tool to produce an initial set of around 200 datasets for testing purposes.

So far I've only executed the project locally using dev-env/run-env.sh. The API is taking a long time to answer search queries, taking about 10s to fetch the current page size of 50 datasets.

@qqmyers I'm not sure why, but query_entities=false currently does not seem to have an effect when running the project locally, as mentioned above. These 2 requests:

• api/search?q=*&type=dataset&subtree=root&start=0&per_page=50&fq=geolocation:*&query_entities=false
• api/search?q=*&type=dataset&subtree=root&start=0&per_page=50&fq=geolocation:*&query_entities=true

yield the same API response, and take about the same time. Also, to populate the map I definitely need the bounding boxes, so I need to use metadata_fields=geospatial:*. And I assume that probably prevents me from using query_entities=false anyway, right?

query_entities was restored as a working parameter in Feb. 2025 so Dataverse releases before then won't use it. If that's not the issue, I can't think of anything off-hand. As for getting the bounding box, those fields are in solr - I'd guess that means you don't need to query the entities, but I'm not sure w/o checking. I guess it would be easy to check once the issue with not being able to see a difference with query_entities true/false is resolved.

(Ah yes when executing run-dev.sh unstable, I accidentally ran quite an old image (version 6.5) where query_entities didn't function, thanks for pointing me in the right direction @qqmyers 👍)

With that fixed, now I'm getting the drastic speed-up from query_entities=false. Sadly, using this does cause the geospatial information to be skipped, even with metadata_fields usage:

The query api/search?q=*&type=dataset&subtree=root&start=0&per_page=50 &metadata_fields=geospatial:*&fq=geolocation:*&query_entities=false responds without metadataBlocks, e.g. this item:

{
  "name": "Test dataset 27  with 2 boxes 3ee7538a-8b72-461d-8221-7dc29a05f2bd",
  "type": "dataset",
  "url": "https://doi.org/10.5072/FK2/VOS4AT",
  "global_id": "doi:10.5072/FK2/VOS4AT",
  "description": "test",
  "published_at": "2026-08-14T10:47:38Z",
  "publisher": "Root",
  "citationHtml": "Admin, Dataverse, 2026, \"Test dataset 27 with 2 boxes 3ee7538a-8b72-461d-8221-7dc29a05f2bd\", <a href=\"https://doi.org/10.5072/FK2/VOS4AT\" target=\"_blank\">https://doi.org/10.5072/FK2/VOS4AT</a>, Root, V1",
  "identifier_of_dataverse": "root",
  "name_of_dataverse": "Root",
  "citation": "Admin, Dataverse, 2026, \"Test dataset 27 with 2 boxes 3ee7538a-8b72-461d-8221-7dc29a05f2bd\", https://doi.org/10.5072/FK2/VOS4AT, Root, V1",
  "publicationStatuses": [
    "Published"
  ],
  "authors": [
    "Admin, Dataverse"
  ]
},

As far as I can tell, SolrSearchResult.java and SolrSearchServiceBean.java decide which fields from Solr are added into the API response. Do you think we could get the geospatial information in there? Or would it be possible to add a parameter that allows specifying which fields from the Solr schema should get returned (so, similar to metadata_fields)?

Bummer. In general, I can’t think of any reason we couldn’t return more fields from solr, someone would just have to do the work.

The only thing I can think to make sure you’re search is as fast as currently possible is to use the geo_point/geo_radius parameters to just find the datasets that would be in view.