Open jirihelmich opened 8 years ago
When initialising the UI, do not load all the concepts, just concept schemes
I understand that this is in theory an optimization, but practically I see no benefit to it at this moment. The current bottleneck is on the client side (React). See #13
For each concept scheme, determine the number of related geo points (transitively via the instances, see how the filter is then applied - you will learn how to assemble the count query)
Just to make sure we understand each other, you mean something like...
SELECT (COUNT(?s) as ?count)
WHERE
{
?s s:geo [] ;
<$propertyUri> ?o .
?o skos:inScheme <$schemeUri> .
}
...where schemeUri
is the concept scheme? Marker counts for each concept are already calculated so I don't think this is a priority at this moment.
Do not display unrelated concept schemes
I don't understand this.
Make the list of concept schemes expandable - when a user clicks it, it should load the instances of the concept scheme and allow the configuration
Implemented in 63ada60. Nevertheless, as explained in the first point (or in #13) there is no real need to load the concepts lazily. The SPARQL queries are really fast and the only performance problem is with rendering lots of React elements at once. The filters are by default collapsed (i.e. way less rendering) which improves the performance.
It's not very clear, what is the impact of enable/disable
I'm aware of that. All filters are applied in a conjunction on the markers. If one filter has no values selected, then the result set is always empty. Disabling means removing one filter from the conjunction (it's not applied at all). I understand it can be confusing, on the other hand, it is confusing only for the user generating the application. The audience (end-users) do not have deal with this complexity. I would consider this part of the learning curve (I'll mention it in the documentation or in the videos).
This should speed things up when applied to a larger dataset and also improve UX: