I'm currently developing an iOS app which shows realtime data, now I receive 33,265 timingpoints from the API, which are all stops. So stops on opposite sides of the street are counted as 2, bus stations which have multiple platforms are also counted as many times as there are platforms.
Now, this is confusing on a map. You'd want all data for example a bus station on one screen and don't browse past 10 platforms to get the bus you'd like to take. So how can I group these annotation, which have the same name, and often are near or overlapping each other?
You can find an example of the JSON results from the API here: http://pastebin.com/RiKS4G0Q
Just make a new entity Location and have a to-one relationship to each stop (reverse is to-many, of course). Now one stop can share a location and you can present the dat in an appropriate way. During import, you could decide to create a new location if the coordinates are close enough to each other (and maybe the stop names correspond).
Related
I am trying to show the current distribution of individuals across a world map, but I am running into trouble trying to standardize location data.
This is a simple feat with the locations of the American and Canadian individuals as they all follow a similar structure (City -> State -> Country). I would ideally like to show these on the city level so that each state with multiple individuals doesn't only contain one dot.
However, there are cities such as Kampala, Bicester, or Bucharest that do not have a state or province and the next largest region is the country itself.
If I use the city as the level of granularity, I see what I'm looking for in the US/Canada area but miss all of the geographical areas without a state. If I show only the State/Country, not only do I miss those without a state, but I also am only seeing one dot for each state whereas I want to see a dot for each city in the state that an individual resides in.
I tried to edit the unknown locations but was still unable to resolve the state/province conundrum. I am unsure how to get around this and can't find any resources discussing this issue. Can anyone point me in the right direction on how to standardize inconsistently formatted location data?
I am working on creating a map sales report to show the sales by product for various territories. The territories are based upon zip codes and are custom territories that overflow into multiple states or are partially in a state. I have gotten everything set up and it looks good for the most part...EXCEPT 2 areas.
1.) one of the sales numbers shows up in Alaska which is not viewable if a user is zoomed in on the USA (we are US-based so it's only relevant to show anyways). Is there a way to force a sales number to show up on a user-defined location? For instance, can I show this on the State of Washington instead of Alaska or can it only default to the largest (area) part of a user-created territory map?
2.) being that we are US-based is there a way to move the states Alaska and Hawaii closer to the US? I know that utilizing the dashboard is a workaround, but it does not look good.
I'm not sure this could be a complete answer, but I think this question has more than one take.
That being said, if your worksheet is based on zip codes in order to create a map, I don't think you can force Tableau to visualize data out of their original position based on the specific geographic role.
The only thing that come to my mind is switching your approach from geographical role (country, state, city, zip, etc) to a more generic lat/long coordinates.
Doing so, you can manually match your Alaska zip codes to lat/long more "continental" areas.
Anyway this would require a lot of data manipulation prior to Tableau.
An alternative way of accomplish something similar to what you say in your second point could lead you to use 3 seperate worksheets in a single dashboard: continental, Alaska, Hawaii.
I did something on US data and I was facing the same problem for Hawaii, so I decided to use a floating worksheet putting it on the bottom left corner of the continental map.
Is there a way I can match players using Google Play Game Service based on individual players' skill level in the game?
I have locally stored the player level of each player, and want a player to be matched to his/her closest ranked player.
For example: a player ranked 10 (beginner) should be paired with the closest ranked player available (e.g. 5 to 15) instead of an expert level 100 player, so that we can have a balanced competition.
There are two variables that can be set to influence the match making:
First, you can set a variant of the game using RoomConfig.Builder.setVariant(). This method takes an non-negative value indicating the type of match. The variant specified needs to match exactly with other participants in order for auto-matching to take place. I suppose you could be strict in your match making and use the variant as the player's level. In this way, players would only be matched with players of the same level. An alternative would be to group levels together in a range, for example levels 1-5 could play each other, likewise group 6-8, etc.
The second variable is the exclusiveBitMask. This is passed in when calling RoomConfig.CreateAutoMatchCritera(). This method takes the min and max number of players to match, and the exclusiveBitMask. This mask when logically AND'ed with the other players will equal 0. This is used for things like role based games (need to have 1 offense and 1 defense). One possible use of this would be to mask out high level vs. low level capabilities so there is no outrageous mismatch.
I think Clayton Wilkinson's answer is all correct and I voted it up.
But, I imagine the OP is hoping for some way to do skill-based matching without splitting the player-base into segments.
Sadly, the answer is no you can't. The choices are to use some other matchmaking system or split up your player base. If you choose to split your player base then you need a lot of concurrent users to avoid making your players wait a long time.
On a recent title we rolled our own matchmaking service based on Raknet because we wanted more nuanced matchmaking. It's a lot of hassle though, and GPGS is pretty great otherwise, so skill based matching would have to be a very high priority before you consider abandoning GPGS.
I'm working to develop an app with my team. It's based on Meteor and React. We have 2 collections: Rooms and Locations. Each room has an uniq location. We have a page where we list all the rooms and we can filter them. This is the most used feature. Insert of new room or new location can be done only by the admin.
We are design our filter (by date, by floor, by time, by location name). All the property we need are in the Rooms collection, excpetion done for the location name. We come out with two solutions:
duplicate the location name used in the filter also for each room in the Rooms collections.
get the list of rooms for each property.
I'm try to figure out which one is the best.
first option:
In that case we only need one collection: Rooms. Will cost O(n). The cost to add the location name to the new room will be the same since we already need to add the property id. The extra cost will be the space on MongoDB to save it.
second option.
In this solution we have all the data well structured in the DB. But to filter by location we need to parse each room and find the proper location in the location collections. Only this I think will cost O(n*m).
This is a simple case, we will never scale to much, but since I'm new to mongo I would like to know which one of the two approach can lead to have better performance.
I've gone through a lot of intro-level tutorials on MVVM and can certainly see its merits but I'm having a hard time applying it to my LOB application. I plan on using MVVM Light, though I don't think that's going to impact the overall design structure of my VMs.
Suppose I want to write a TaxiDispatcher application where I have a service that goes out every minute and fetches the latest status of each of my taxis. I also have a list of fixed locations that people can call from and request a taxi. The dispatcher would then assign an available taxi to that location. At any given time, each taxi would either be available to the dispatcher or assigned to one of the particular locations in order to pick up a customer.
My main screen (let's call it DispatcherView) would consist of a list of available taxis on the left-side of the screen and then two additional pieces of visual content: a list of my locations (whether or not a person is there requesting service, which taxi has been assigned to that location, etc..) and a list of taxi assignments (elapsed time since they've been assigned, location, etc..).
All 3 of those views work off the same 2 sources: the taxi data service and the list of my locations that I can dispatch a taxi to. Right now, I've got separate views and view models for each of the 3 views (UnassignedTaxisVM, DispatchLocationsVM and AssignedTaxisVM), each being injected with one, or both, of the data sources. When the dispatcher assigns a taxi from the unassigned list, I use a Messenger to communicate with the other VMs to let them know that the taxi has been assigned to a location (the DispatchLocationsView and AssignedTaxisView are both updated with this new information as a result). But when I'm wiring up each VM, I'm having to inject the same datasource(s) to each of my VMs and thus having to write similar code in each VM to respond to the command when the dispatcher assigns a taxi to a location. It may just be my lack of experience with the framework but it just smells bad to me.
Does it make more sense to simply have one VM (DispatcherVM), and have the DispatcherView be responsible for rendering all 3 pieces of visual content? I envision this would involve having 3 ObservableCollections (UnassignedTaxis, Locations, AssignedTaxis) in my DispatcherVM and binding the datasource of each of the sub-views. As new data comes in from my taxi data service, I'd parse/update to the appropriate ObservableCollection and have my views respond that way.
What's the best practice here? I've got 3 distinct, but similar, "views" of the same underlying data. Should I create seperate VMs for each of the views or have one VM expose a view that essnentially consists of 3 separate lists/datagrids, etc..?
It sounds like you have reusable plumbing across ViewModels. Have you considered using inheritance (i.g. a ViewModelBase class) to reuse that plumbing? If inheritance isn't right for your solution, you could go the route of one main VM that is composed of child ViewModels that the main ViewModel coordinates.
Both patterns are equally good solutions at a high level in my opinion. It's hard to know which is more appropriate without a lot of context.