I'm using Routing REST API V8 to collect travel time data. I understand that the difference between 'duration' and 'baseDuration' is traffic consideration. How is 'baseDuration' being calulated?
My guess is that it is some kind of free-flow travel time. In that case there must be an average speed along a given segment. Which goes back to the question, how is free-flow travel average speed determined?
Thank you
Yes, You are right BaseDuration is the time "without realtime traffic on the route" and Duration includes current traffic reduced speeds.
So answer to your question how free-flow travel average determined is based on map long-term traffic pattern info, functional road class, speed category, country specific limits, etc
Please note this situation:
You request a ROUTE A --> B
There is a major road closure and therefore HERE diverts you around adding 30m to the journey. This is good.
The BaseDuration is now calculated for the actual given route and NOT for the normal route, i.e. without road closures.
So you might get the same figure for BaseDuration and Duration as there is no traffic in the diverted route... it does not give you 30m as it gives you the information against the provided route.
OK,
Mark
Related
is there any possibility to get exact time spent on a certain level in a game via firebase analytics? Thank you so much 🙏
I tried to use logEvents.
The best way to do so would be measuring the time on the level within your codebase, then have a very dedicated event for level completion, in which you would pass the time spent on the level.
Let's get to details. I will use Kotlin as an example, but it should be obvious what I'm doing here and you can see more language examples here.
firebaseAnalytics.setUserProperty("user_id", userId)
firebaseAnalytics.logEvent("level_completed") {
param("name", levelName)
param("difficulty", difficulty)
param("subscription_status", subscriptionStatus)
param("minutes", minutesSpentOnLevel)
param("score", score)
}
Now see how I have a bunch of parameters with the event? These parameters are important since they will allow you to conduct a more thorough and robust analysis later on, answer more questions. Like, Hey, what is the most difficult level? Do people still have troubles on it when the game difficulty is lower? How many times has this level been rage-quit or lost (for that you'd likely need a level_started event). What about our paid players, are they having similar troubles on this level as well? How many people have ragequit the game on this level and never played again? That would likely be easier answer with sql at this point, taking the latest value of the level name for the level_started, grouped by the user_id. Or, you could also have levelName as a UserProperty as well as the EventProperty, then it would be somewhat trivial to answer in the default analytics interface.
Note that you're limited in the number of event parameters you can send per event. The total number of unique parameter names is limited too. As well as the number of unique event names you're allowed to have. In our case, the event name would be level_completed. See the limits here.
Because of those limitations, it's important to name your event properties in somewhat generic way so that you would be able to efficiently reuse them elsewhere. For this reason, I named minutes and not something like minutes_spent_on_the_level. You could then reuse this property to send the minutes the player spent actively playing, minutes the player spent idling, minutes the player spent on any info page, minutes they spent choosing their upgrades, etc. Same idea about having name property rather than level_name. Could as well be id.
You need to carefully and thoughtfully stuff your event with event properties. I normally have a wrapper around the firebase sdk, in which I would enrich events with dimensions that I always want to be there, like the user_id or subscription_status to not have to add them manually every time I send an event. I also usually have some more adequate logging there Firebase Analytics default logging is completely awful. I also have some sanitizing there, lowercasing all values unless I'm passing something case-sensitive like base64 values, making sure I don't have double spaces (so replacing \s+ with " " (space)), maybe also adding the user's local timestamp as another parameter. The latter is very helpful to indicate time-cheating users, especially if your game is an idler.
Good. We're halfway there :) Bear with me.
Now You need to go to firebase and register your eps (event parameters) into cds (custom dimensions and metrics). If you don't register your eps, they won't be counted towards the global cd limit count (it's about 50 custom dimensions and 50 custom metrics). You register the cds in the Custom Definitions section of FB.
Now you need to know whether this is a dimension or a metric, as well as the scope of your dimension. It's much easier than it sounds. The rule of thumb is: if you want to be able to run mathematical aggregation functions on your dimension, then it's a metric. Otherwise - it's a dimension. So:
firebaseAnalytics.setUserProperty("user_id", userId) <-- dimension
param("name", levelName) <-- dimension
param("difficulty", difficulty) <-- dimension (or can be a metric, depends)
param("subscription_status", subscriptionStatus) <-- dimension (can be a metric too, but even less likely)
param("minutes", minutesSpentOnLevel) <-- metric
param("score", score) <-- metric
Now another important thing to understand is the scope. Because Firebase and GA4 are still, essentially just in Beta being actively worked on, you only have user or hit scope for the dimensions and only hit for the metrics. The scope basically just indicates how the value persists. In my example, we only need the user_id as a user-scoped cd. Because user_id is the user-level dimension, it is set separately form the logEvent function. Although I suspect you can do it there too. Haven't tried tho.
Now, we're almost there.
Finally, you don't want to use Firebase to look at your data. It's horrible at data presentation. It's good at debugging though. Cuz that's what it was intended for initially. Because of how horrible it is, it's always advised to link it to GA4. Now GA4 will allow you to look at the Firebase values much more efficiently. Note that you will likely need to re-register your custom dimensions from Firebase in GA4. Because GA4 is capable of getting multiple data streams, of which firebase would be just one data source. But GA4's CDs limits are very close to Firebase's. Ok, let's be frank. GA4's data model is almost exactly copied from that of Firebase's. But GA4 has a much better analytics capabilities.
Good, you've moved to GA4. Now, GA4 is a very raw not-officially-beta product as well as Firebase Analytics. Because of that, it's advised to first change your data retention to 12 months and only use the explorer for analysis, pretty much ignoring the pre-generated reports. They are just not very reliable at this point.
Finally, you may find it easier to just use SQL to get your analysis done. For that, you can easily copy your data from GA4 to a sandbox instance of BQ. It's very easy to do.This is the best, most reliable known method of using GA4 at this moment. I mean, advanced analysts do the export into BQ, then ETL the data from BQ into a proper storage like Snowflake or even s3, or Aurora, or whatever you prefer and then on top of that, use a proper BI tool like Looker, PowerBI, Tableau, etc. A lot of people just stay in BQ though, it's fine. Lots of BI tools have BQ connectors, it's just BQ gets expensive quickly if you do a lot of analysis.
Whew, I hope you'll enjoy analyzing your game's data. Data-driven decisions rock in games. Well... They rock everywhere, to be honest.
The OR-Tools documentation (https://developers.google.com/optimization/routing/routing_options) for the VRP routing options describes the two first solution strategies the following way:
PATH_CHEAPEST_ARC: Starting from a route "start" node, connect it to the node which produces the cheapest route segment, then extend the route by iterating on the last node added to the route.
GLOBAL_CHEAPEST_ARC: Iteratively connect two nodes which produce the cheapest route segment.
Can someone explain me what the difference between the two heuristics is? Unfortunately I haven't found any other information on the internet or the documentation.
The first one grows a route by extending it.
The second one connect the closest nodes together until it creates routes.
Is it possible to solve the Multiple Depot Vehicle Scheduling Problem (MDVSP) in OR-tools?
The problem is detailed in this paper, but here is a brief summary.
We are given a set of depots and the number of available vehicles at each. We are given a set of timetabled trips, and we know the origin, destination, start time, end time, and a set of depots that can serve a given trip. While connecting two trips, that is assigning a vehicle to serve for two trips sequentially, there may be an unoccupied travel, so called a dead-head trip. There are also dead-heads while going from a depot to the first trip and returning from the last trip to a depot. The objective is to minimize the sum of all dead-head trip costs while ensuring each trip is served by exactly one vehicle and the number of vehicles used does not exceed the availability. (Other trips/links, i.e., occupied trips, must in any case need to be served/traversed; so, there is no need to include them in the objective).
Seems you want to take into account the arc cost only if vehicle is empty. (note: fixed typo)
AFAIK, there is no easy way to do it using OR-Tools. In C++ you may use the DimensionDependentDimension and returning the arc cost if a capacity dimension is zero, and zero otherwise...
Also I'm curious why you would like to only count dead-trip e.g. if the overall vehicle route is several time longer with very few dead-trip instead of a shorter route with few dead-trip why would you want to incentive the first one ?
e.g. a route of 100km with 1km dead-trip is two time better than a 50km route with 2km dead-trip...
For multiple depots please take a look at
vrp_starts_ends.py
For TimeWindows: vrp_time_windows.py
Did you take a look at the documentation ?
e.g. https://developers.google.com/optimization/routing/cvrp
using routing.NextVar(A).SetValues([A, B]) you can force the chain A->B
ref: https://github.com/google/or-tools/blob/49b6301e1e1e231d654d79b6032e79809868a70e/ortools/constraint_solver/routing.h#L1364-L1366
note: Solver won't have the possibility to use A->C->B even if is shorter than A->B->C or C->A->B (supposing TW allow both of them...)
Context
The service I'm building needs to performs two steps using the HERE API.
It needs to calculate the optional route between multiple waypoints. This can be achieved using the Waypoint Sequencing API.
It also needs to display the route on a map, so I need polylines for the route. This can be retrieved using the Routing API.
The problem
According to the docs:
The Fleet Telematics Waypoints Sequence does not include route details in its responses. To request a route, use the HERE Routing API.
That is, the use of the two distinct services cannot be avoided. However, there seem to be major differences between the services. For example, when calculating the optimal route, you may restrict certain road types, such as tollroad or motorway, to a degree. On the other hand, Routing API, I can only avoid certain types, and it's an either-or choice.
Here's (no pun intended) an example: let's say the user wants to avoid toll roads unless absolutely necessary, thus he sets tollroad to -3 in the Waypoint Sequencing API. When the actual route is calculated, we only have the choice to allow toll roads, meaning, potentially every part of the route will go through such roads, or disallow them entirely.
The question itself
Is there any way I'm missing to "mediate" between the results of the two services? Essentially, I would like to display the route the Waypoint Sequencing API found to be ideal for all the provided options.
The HERE Waypoints Sequence API v8 resource findsequence allows you to optimize for distance covered in a journey or for travel time. Use the parameter improvefor (available values: distance and time). By default, HERE Waypoints Sequence optimizes waypoints for travel time.
So HERE WSE service optimizes waypoints for travel time and travel distance.
Check this for all parameters of WSE : https://developer.here.com/documentation/routing-waypoints/api-reference.html
And requests to the Routing API must include the route travel mode and two consecutive waypoint coordinates from the response from HERE Waypoints Sequence API v8
So I am working on a webservice to access our weather forecast data (10000 locations, 40 parameters each, hourly values for the next 14 days = about 130 million values).
So I read all about RESTful services and its ideology.
So I understand that an URL is adressing a ressource.
But what is a ressource in my case?
The common use case is that you want to get the data for a couple of parameters over a timespan at one or more location. So clearly giving every value its own URL is not pratical and would result in hundreds of requests. I have the feeling that my specific problem doesn't excactly fit into the RESTful pattern.
Update: To clarify: There are two usage patterns of the service. 1. Raw data; rows and rows of data for several locations and parameters.
Interpreted data; the raw data calculated into symbols (Suns & clouds, for example) and other parameters.
There is not one 'forecast'. Different clients have different needs for data.
The reason I think this doesn't fit into the REST-pattern is, that while I can actually have a 'forecast' ressource, I still have to submit a lot of request parameters. So a simple GET-request on a ressource doesn't work, I end up POSTing data all over the place.
So I am working on a webservice to access our weather forecast data (10000 locations, 40 parameters each, hourly values for the next 14 days = about 130 million values). ... But what is a ressource in my case?
That depends on the details of your problem domain. Simply having a large amount of data is not a good reason to avoid REST. There are smart ways and dumb ways to model and expose that data.
As you rightly see, your main goal at this point should be to understand what exactly a resource is. Knowing only enough about weather forecasting to follow the Weather Channel, I won't be much help here. It's for domain experts like yourself to make that call.
If you were to explain in a little more detail the major domain concepts you're working with, it might make it a little easier to give specific advice.
For example, one resource might be Forecast. When weatherpeople talk about Forecasts, what words keep coming up? When you think about breaking a forecast down into smaller elements, what words do you use to describe the pieces?
Do this process recursively, and you'll probably be able to make a list of important terms. Don't forget that these terms can describe things or actions. Think about what these terms really mean, what data you can use to model them, how they can be aggregated.
At this point you'll have the makings of something you can start building a RESTful system around - but not before.
Don't forget that a RESTful system is not a data dump wrapped in HTTP - it's a hypertext-driven system.
Also don't forget that media types are the point of contact between your server and its clients. A media type is only limited by your imagination and can model datasets of any size if you're clever about it. It can contain XML, JSON, YAML, binary elements such as a Bloom Filter, or whatever works for the problem.
Firstly, there is no once-and-for-all right answer.
Each valid url is something that makes sense to query, think of them as equivalents to providing query forms for people looking for your data - that might help you narrow down the scenarios.
It is a matter of personal taste and possibly the toolkit you use, as to what goes into the basic url path and what parameters are encoded. The debate is a bit like the XML debate over putting values in elements vs attributes. It is not always a rational or logically decided issue nor will everybody be kind in their comments on your decisions.
If you are using a backend like Rails, that implies certain conventions. Even if you're not using Rails, it makes sense to work in the same way unless you have a strong reason to change. That way, people writing clients to talk to Rails-based services will find yours easier to understand and it saves you on documentation time ;-)
Maybe you can use forecast as the ressource and go deeper to fine grained services with xlink.
Would it be possible to do something like this,Since you have so many parameters so i was thinking if somehow you can relate it to a mix of id / parameter combo to decrease the url size
/WeatherForeCastService//day/hour
www.weatherornot.com/today/days/x // (where x is number of days)
www.weatherornot.com/today/9am/hours/h // (where h is number of hours)