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.

Sign up for GitHub

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

Jump to bottom

Adds numeric value comparison filters #79

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Adds numeric value comparison filters #79

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
19d1cd8
Added numeric value comparison filters
MikeGodin Jul 30, 2015
3ffeff1
Merge pull request #1 from MikeGodin/Numeric-filters
MikeGodin Jul 30, 2015
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 23 additions & 1 deletion lib/cartoRenderer.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1073,10 +1073,32 @@ var cartoSelectorIsMatch = function(definition, feature, source, zoom) {
for (var filterKey in definition.filters) {
var filter = definition.filters[filterKey];

if (filter.op === "=") {
switch (filter.op) {
case "=":
if (feature.properties[filter.key] !== filter.val) {
return false;
}
break;
case "<":
if (feature.properties[filter.key] >= filter.val) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I might be missing the obvious, but why not use the same comparison operator that you’re handling? (e.g. do feature.properties[filter.key] < filter.val here because you are evaluating ">" instead of >=.) What you’ve got is technically equivalent, so it works, but makes reading it a bit confusing.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait, nevermind, that was a dumb comment. Ignore me :P

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The filters work by returning early from the property loop based on a single false match, rather than iterating over the entire set of properties to ensure they all are true.

I don't know if it would be more performant to use a true functional method, but it's following the pattern of the previous implementation of the = matcher.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that’s what I realized right after posting. Too distracted this morning, I guess. Also been a while since I wrote this :P

I think encapsulating each of the kinds of tests in this method might be better for reading, though it would be slower. Either way, not really in the scope of work for this PR. My bad.

return false;
}
break;
case ">":
if (feature.properties[filter.key] <= filter.val) {
return false;
}
break;
case "<=":
if (feature.properties[filter.key] > filter.val) {
return false;
}
break;
case ">=":
if (feature.properties[filter.key] < filter.val) {
return false;
}
break;
}
}
}
Expand Down