Using the Nokia Here (Javascript) API, is it possible to have a Polyline - defined by a relatively sparse but potentially large set of coordinates - snap to roads without making a route query?
If you are unable to positively surprise me, and this is not possible as I assume, any additional suggestions for achieving the same result with a minimum amount of routing queries (or other approach you find 'optimal')? Thus far I am thinking of dividing the coordinate sets into smaller sets if required, getting the route for them separately, then combining the data of the resulting Shapes (Strips) and caching it all in a database for later display..
If you are using the Enterprise Routing API you could do the following:
1) Make a series of routing requests to HERE from your point A to your point B using the manueverattribute=none&routeattributes=none parameters in the request which suppresses unwanted information. Store the routeId in your database:
http://route.st.nlp.nokia.com/routing/6.2/calculateroute.json?...&manueverattribute=none&routeattributes=none&app_id=YOUR_APP_ID&app_code=YOUR_APP_CODE .
2) When a user queries your sparse database from from your point A to your point B , retrieve the routeId from your database and make a query to HERE using the getroute endpoint passing in the id from previous request as shown:
http://route.st.nlp.nokia.com/routing/6.2/getroute.json?routeid=your_route_id&app_id=your_app_id&app_code=your_app_code&manueverattribute=none&routeattributes=shape
This way you can get away with storing the minimal amount of information yourself - i.e. a matrix of all possible start points against all possible end points, and use the RESTful routing API to do all the intermediate calculations.
Related
I am currently working on a University project and I am going to create a hitch hiking mobile app. I am looking to use phonegap and Javascript on the front end and laravel as my RESTFUL API. I have looked at he Google maps API documentation but I have still not seen a plugin for Laravel which allows GPS route details to be stored on the backend in laravel.
I presume the mapping of routes between drivers and hitch hikers will need to be done on the server as details of all routes (journeys) will need to be stored and for searching.
Has anyone ever worked on a similar hitch hiking project and how would you check if a hitch hicker's route matches with a Driver's route. Surely this mapping must be done on the server and is there any API for Laravel that supports this?
My interpretation to how your service will work is that both hitch hikers and drivers will state their current location and their intended destination, and hitch hikers will be able to request rides based on matching routes/destinations (which is a pretty cool idea actually).
Based on that interpretation, here's how I might go about implementing it.
1. Create a Journey
A Journey model would be a the journey the user wishes to make. It would be comprised of many Waypoint models (at least 2, the minimum being the start and end points).
There would be a one-to-many relationship between a Journey and Waypoint.
A user creates a Journey and you use the Google Maps Directions API to store the Waypoints for it.
2. Periodically update a user's location
A user will eventually move between waypoints. When they do, you want to know where they are so you can update their position so that they're able to be accurately represented on a map of active users (I imagine you'll have one, displaying the locations of various Drivers and Hitchhikers, similar to Uber).
3. Match users based on similar waypoints
Use the waypoint data you have stored against a driver and hitchhiker's routes to find similar routes/journeys and make suggestions as to which hitchhikers a driver may pick up. You can even use the API data to give estimated times of pickup based on the distance between the driver and the hitchhiker.
There's more to consider, but that'd be a pretty decent starting point.
You would want to think about re-routing (what if a user can't go between certain waypoints due to roadworks, or perhaps they take a wrong turn - think about how your SatNav might handle it), perhaps the ability to plan trips in advance, etc.
To actually answer your questions, yes, if you wanted to use Laravel for this you'd map the routes and match the waypoints server-side.
Let's take the scenario where I am a hitchhiker.
I want to get from A to G.
I'm currently at waypoint C
Driver X is on another route which happens to have my waypoints C, D, and E in it. To find Driver X, you could do something like (pseudocode):
// Find a driver with similar waypoints
Driver::withSimilarWaypoints($myJourney->remainingWaypoints())->all();
// withSimilarWaypoints scope
function scopeWithSimilarWaypoints($waypointsCollection)
{
$query->whereHas('waypoints', function ($query) use ($waypointsCollection) {
$query->where('passed', 0)->whereIn('waypoint_identifier', $waypointsCollection->pluck('waypoint_identifier'));
}
}
In this case waypoint_identifier would have to be the same for me and Driver X, so perhaps a hash of the waypoint object or you could use place_id as returned by the API.
You'd also want to make sure you're not matching against waypoints you've both already passed (hence remainingWaypoints() and where('passed', 0).
Driver X is estimated to arrive at waypoint C in 8 minutes, so I decide to wait for them (or I can request a lift via the app)
All that should be a pretty decent jumping off point for your service. I quite like the idea – good luck!
I am creating a simple game in html5 canvas. i run it using javascript . ANd i want it to be a multiplayer game. but first i need to have a database where i can put the x and y position of an object that will run in every 30 milliseconds(it is the keyframes of my game animation.) . i need to save it in a file or database so other players can see the update of x and y position of other players...i hope you get my point...
now i am asking what database or file should i use to do this data position updating . that can be able to update that fast
For a scenario like this, you will probably get more mileage if you cache locations in memory locally, but then periodically "sync" them with the database. This will require ways to resolve conflicts in position (e.g. if the position you predict / have on the client-side JavaScript deviates from the actual position as reported by the database) but will allow you to be more efficient (e.g. updating at a faster rate when players are nearer to your player and less frequently when they are far away, for example). It will also allow you to animate your player's movements more steadily without jank in the event that a particular database request falls outside of your frame rate requirements.
As for the database, itself, there are a lot of databases to choose from. However, if you don't want to write the server-side code to provide an API for interacting with your database, then you may be interested in Firebase, which provides direct access from client-side JavaScript (without the need to create your own server / API layer on top of the database). Of course you can also use any other database -- Google Cloud Datastore, Google Cloud SQL, MySQL, Cassandra, MongoDB -- and write an appropriate API server layer in the language of your choice (which could also be JavaScript) to provide access to the underlying data, as a valid option as well (and, in fact, that might make more sense if you already have or plan to have a frontend webserver).
How many objects is too many to process in javascript?
I've got a mapping application (google maps api) that has a 100,000 lat/long markers (with names). It's really simple data, but I it bogs down the page loading it.
Are there ways to deal with this? I'm not sure if the problem is that I'm loading too many objects, or if I just need to store/access the data in a less intensive way.
I verify every day that 100,000 polygons with a significant number of coordinates (30 to 500 lat / lng each) involve a general slowing down of the duration of 3 to 5 seconds with a machine of discrete performance. You can make it more reactive the application suddvidento the population with a series of calls ajax portions sorted data .. This is often not easy from the point of view of application, but if it is possible allows a net improvement of performance even thanks to the asynchronous management of population data rendering them on the map.
Best way to know what's going wrong is to profile the CPU and the memory. It could just be too much data adding up, given it's 100,000 objects. Even with only a few properties on each, it adds up.
It's also possible that it just has trouble rendering that many points on the map. Depending on the business logic of your application, you can add something like a search or default filters to reduce the number needing to show.
First of all, I am not sure this question should be in stackoverflow or other stackexchange network. So if wrong place just move for me.
It is better to calculate the distance between 2 points of lat/lng in DB or js?
Since Google maps provide computeDistanceBetween(). This is really easy to use, but i am thinking if i have 10000 rows and only 5 rows are within the distance and to display into the map.
Any idea?
If your question is only about where it should be calculated then I prefer client side. It is simple, fast, more flexible and dinamic, and you unload your server.
Without knowing much about your problem, I'd probably go with doing calculation-intensive tasks on the client side (or "in JS"). This will never put too much load on your server-side application, by distributing it among clients.
Of course there are many variables you have to take into account to choose the best approach.
Other things you may consider:
doing it server-side and caching the results,
using google-api and also caching it on your server,
many many more...
It depends to the frequency of calculations.
If your points are permanent then you can calculate all required distances only once before inserting the row into table and save the calculated result to provide it to clients later.
But if calculations are repeatable and coordinates of points will be changed eventually then it's better to use client-side calculations.
Really it's not that hard task for browser to execute some JavaScript which will calculate distances even for a lot of points.
Also if you have really tons of input data you can consider some background pre-calculations on client-side and caching of results in localStorage* so your users will never wait.
* store.js could help you to ensure cross-browser compatibility.
Where it is better to calculate distance is completely dependent on your application. If you the client has the information then it is better in JS.
In this scenario you appear to be trying to calculate the nearest points stored in your database to a given point. This is most certainly better handled by the database using geospatial indexes.
The typical algorithm narrows down the result set with a unsophisticated approach. Within x & y +/- 10KM and then with that result set do a full calculation.
I would say if your information is in the database then look into using built in geospatial tools for your DBMS.
Fellow Overflowers,
Am working in a project in which I need to place (pin) on map (Google in my case), a stream of data. One data record consist of 11 columns and the last 2 ones, are "city" and "country".
The data source is an html page, using the usual table tags, this is a business model and can not be changed. I managed to parse and analyze them using Nokogiri and finally store them in an array.
The idea is to pin each data in the map and ballon the rest of the 9 columns.
The hint: data are refreshed every 1 minute.
I can not figure out the approach: Shall i use arrays or a database to save the data? The average number of records to be displayed is 120 at the same time, on the map.
..and has anybody implemented something similar, could there be a comment regarding the performance?
Thanks a bunch...
Petros
I think you will get problems when geocoding Country, City every minute. Probability you reach limit or encounter some failure is very high. The rest (refreshing with ajax and removing/adding 100+ markers) will be no problem.
So, if I'd do it I would created local database with geocodes (latitude and longitude) for Country+City. I would gather geocodes (that is not present in database) via google.maps.Geocoder right in the javascript and send them back with AJAX to append to the table. I suppose, your country+city database get complete rapidly and you no need to extensive geocoding anymore, also for exceptions you always have geocoder ready in javascript to resolve new city. It should work like a charm.
Alternative is to use static geocoder right in your server side just after you get new portion of data. But I would prefer first approach.