The difference between two sets, obtained using two around queries - is this the right approach?
nw(around:20000,15.8433,74.4969)->.small;
nw(around:60000,15.8433,74.4969)->.big;
(area.big; - area.small;)->.mid;
(
nw[tourism=attraction](area.mid);
nw[historic=memorial](area.mid);
nw[amenity=place_of_worship](area.mid);
nw[water=lake](area.mid);
);
out geom;
Basically, I need tourist locations between 20 and 60 km from a certain place.
I tried using difference between result set of 'around' clause.
I am not sure if my approach is right and efficient.
I have a PostGreSQL table that has a geometry type column, in which different simple polygons (possibly intersecting) are stored. The polygons are are all areas within a city. I receive an input of a point (latitude-longitude pair) and need to find the list of polygons that contain the given point. What I have currently:
Unclustered GiST index defined on the polygon column.
Use ST_Contains(#param_Point, table.Polygon) on the whole table.
It is quite slow, so I am looking for a more performant in-memory alternative. I have the following ideas:
Maintain dictionary of polygons in Redis, keyed by their geohash. Polygons with same geohash would be saved as a list. When I receive the point, calculate its geohash and trim to a desired level. Then search in the Redis map and keep trimming the point's geohash until I find the first result (or enough results).
Have a trie of geohashes loaded from the database. Update the trie periodically or by receiving update events. Calculate the point's geohash, search in the trie until I find enough results. I prefer this because the map may have long lists for a geohash, given the nature of the polygons.
Any other approaches?
I have read about libraries like GeoTrie and Polygon Geohasher but can't seem to integrate them with the database and the above ideas.
Any cues or starting points, please?
Have you tried using ST_Within? Not sure if it meets your criteria but I believe it is meant to be faster than st_contains
Is it possible to rank search results based solely on proximity (and other filters) to a specific point and ignore the custom ranking formula (likes)?
For example, I'd like to rank results closest to times square strictly by distance and for the query to not care about the likes attribute.
I suppose the likes attributes is one of you own.
You can do what you need by removing the attribute like from the custom ranking.
If you need 2 way to search, you can do a replica index, with the same data but a different ranking formula: https://www.algolia.com/doc/guides/ranking/sorting/?language=go#multiple-sorting-strategies-for-an-index
My combination chart has two y-axes, one for price and one for value. This data is being pulled from the same table.
Is it possible to filter each of the two axes differently? Whenever I filter the table as a whole, it obviously affects both axes. Is there a way around this?
I don't think you can do that, the underlying data set for any visualization is the same no matter the split or the way you choose to display it (in your case, two axes).
If you need the two to react differently to filtering, I suggest you make two visualizations and apply 2 different filtering schemes to them (you will need that, as they are both coming from the same data table).
If this does not meet the requirements, please specify the rationale behind it, we might be able to come up with better idea.
I want to aggregate bins in tableau.
See the following figure:
I want to aggregate (merge) the NumberM from 6 untill 16 in one category. 5+/(6 and higher) for example and sum the values of 6-16 in that category. I think this can be done with a few simple clicks but I am not able to manage.
Thanks in advance,
Tim
There are several ways to classify data rows into different groups or classes: each with different strengths.
Create a calculated field As emh mentioned, one approach is to create a calculated field to assign a value to a new field indicating which group each data row belongs to. For the effect you want, the calculated field should be discrete (blue). If your calculation doesn't return a value for in one case, e.g. an if statement without an else clause, then the field will be null in that case which is a group in itself. This is a very general approach, and can handle much more complex cases. The only downsides are the need to maintain the calculated field definition and that the cutoff values are hard coded and by itself can't be changed dynamically via a control on the view. BUT those issues can by easily resolved by using a parameter instead of a numeric literal in your calculated field. In fact, that's probably the number one use case for parameters. If you think in SQL, a discrete field on a shelf is like a group by clause.
Use a filter If you only want a subset of the data in your view, e.g. data rows with NumberM in [6, 16] then you can drag the NumberM field onto the filters shelf and select the range you want. Note for continuous (green) numeric fields, filter ranges include their endpoints. Filters are very quick and easy to drop on a view. They can be made dynamically adjustable by right clicking on them and creating a quick filter. Its obvious from the view that a filter is in use, and the caption will include the filter settings in its description. But a filter doesn't let you define multiple bins. If you think in SQL, a filter is like a where clause (or in some cases using the condition tab, like a having clause)
Define histogram bins If you want to create regular sized bins to cover a numeric range, such as values in [1,5], [6,10], [11-15] ..., Tableau can create the bin field for you automatically. Just right click on a numeric field, and select Create Bins.
Define a group Very useful for aggregating discrete values, such as string fields, into categories. Good for rolling up detail or handling multiple spellings or variants in your data. Just right click on a field and select Create Group. Or select some discrete values on an axis or legend and press the paperclip option. If you then edit a group, you'll see what's going on. If you think in SQL, a group is like a SQL case statement.
Define a set Another way to roll up values. The definition of a set can be dynamically computed or a hard coded list of members. Both kinds are useful. You can combine sets with union, intersection, set difference operators, and can test set membership in calculated fields. Sets are useful for binary decisions, rows are divided into those that are members of the set and those that are not.
Filters, sets, groups, calculated fields and parameters can often be combined to accomplish different effects.
Most if not all of these features can be implemented using calculated fields, especially if the business rules get complicated. But if a filter, bin, group or set fits your problem well, then it's often best to start with that, rather than define a calculated field for each and every situation. That said, learning about the 4 kinds of calculated fields really makes a difference in being able to use Tableau well.
You can do this with calculated fields.
Go to: Select Analysis > Create Calculated Field.
Then use this formula:
IF NumberM > 5 THEN "OVER 5"
You can then use that calculated field as a filter on the worksheet in your screenshot.
Answering my own question:
With Tableau 9 this can be easily done with the increased flexibility of the level of detail expressions (LOD). I can really recommend this blog on that subject and many more Tableau functions.