Skip to content
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

Map visualizer - initial filtering #6

Open
3 of 5 tasks
jirihelmich opened this issue May 10, 2016 · 1 comment
Open
3 of 5 tasks

Map visualizer - initial filtering #6

jirihelmich opened this issue May 10, 2016 · 1 comment

Comments

@jirihelmich
Copy link

jirihelmich commented May 10, 2016

This should speed things up when applied to a larger dataset and also improve UX:

  • When initialising the UI, do not load all the concepts, just concept schemes
  • 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)
  • Do not display unrelated concept schemes
  • 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
  • It's not very clear, what is the impact of enable/disable
@tobice
Copy link
Owner

tobice commented Jul 13, 2016

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants