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

Filtering functionality for graph #192

Closed
4 tasks done
oscarlorentzon opened this issue Sep 13, 2016 · 7 comments
Closed
4 tasks done

Filtering functionality for graph #192

oscarlorentzon opened this issue Sep 13, 2016 · 7 comments

Comments

@oscarlorentzon
Copy link
Member

oscarlorentzon commented Sep 13, 2016

It should be possible to filter the graph through the public API. The format of the filter API needs to be determined. Combined filters should be supported.

For filtering to work the graph needs to handle reset, i.e. all edges should be invalidated and cleared and handling current node should be done properly elsewhere.

Different potential filters include:

  • Panorama / Regular / Full panorama
  • User
  • Timespan
  • Sequence

Depends on the implementation of #191.

@oscarlorentzon
Copy link
Member Author

I do not see a use case for existential filters for this issue. The gpano property, which may not be set, is also wrapped in the pano and fullPano boolean properties which encapsulates all the use cases regarding showing pano or not.

This would leave us with the following filters:

Comparison
==
!=
<
<=
>
>=

Set membership
in
!in

Combining
all

@gyllen Thoughts?

@oscarlorentzon
Copy link
Member Author

The idea is that the implementation will not support nested properties so it will not be possible to filter on things like node.latLon.lat.

@gyllen
Copy link
Member

gyllen commented Nov 2, 2016

@oscarlorentzon Is it a big cost to include extistential filter (if not maybe we should do it for the sake of it)

Another question we might want to ask us is if ew want the filters to map exactly to the node properties. This is a bad example but lets say we want a boundingBox filter, is that something we should think about. I don't know.

@oscarlorentzon
Copy link
Member Author

oscarlorentzon commented Nov 3, 2016

Including the existential filter is not a big cost.

The filtering will be used when calculating edges for nodes.

What is a none node property exactly (filters to not map exactly to the node properties)?
What kind of none node properties do you want to filter on?
When would you do it?

@oscarlorentzon
Copy link
Member Author

The problem with the existential filter is that the node class is wrapping all underlying properties retrieved from the API. So even if the API result would have been an object without a certain property the node will have a property with that particular name and a has filter would always return true. !has would always return false for all defined node properties.

@gyllen
Copy link
Member

gyllen commented Nov 4, 2016

Ok I see, since we have a standard set of properties that are always set (and not dymamic as in geojson). There is no need for has filter. Skip then.

@oscarlorentzon oscarlorentzon added this to the 2.1.0 milestone Nov 7, 2016
@oscarlorentzon
Copy link
Member Author

The filters only apply to the spatial arrows, i.e. the sequence arrows will always be available no matter what filter is applied.

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