I am trying to locate all stations of a city through here's transit-api
but it seems there exists a constraint in the maximum number of results (50).
Are you aware of any other way?
Thanks a lot!
This is the accurate API to locate the near by transit stations, however it can only return 50 at a time. The alternative way to change centre and radius of the city to calculate all the transit stations.
https://developer.here.com/documentation/examples/rest/public_transit/station-search-proximity
https://transit.api.here.com/v3/stations/by_geocoord.json?center=52.520501,13.403565&radius=1000&max=50&app_id=xxxx&app_code=xxxxx
Related
I have a list of locations with zipcodes. I have another list of Distribution Centers that serve these locations. Is there anyway to map the nearest DC to each of these locations? I am an extremely green coder, but i have some experience with R
I'd need more information to give you some possible code to solve your problem however, here is one approach to solving your problem.
Convert your zipcodes to longitudes and latitudes.
Not sure what location data you have on your distribution centers, but you should be able to find a way to retrieve the long/lat of each of these.
For each zipcode, compute the the distance to each DC (using their respective longs/lats). To compute the distance, use the haversine formula. Find the minimum of these distances. This is your solution.
Inbound https://maps.googleapis.com/maps/api/distancematrix/json?origins=Mount+Monodnak&destinations=Boston+MA
Outbound: https://maps.googleapis.com/maps/api/distancematrix/json?origins=Boston+MA&destinations=Mount+Monadnock
You can see that data is returned on the outbound leg to the mountain but not on the return back. Travel mode needs to be driving.
I Geocoded Mount Monadnock to get the latitude and longitude and tried the nearestRoad api call but that also returned {}
Here is the URL with my API key removed (but is required) roads.googleapis.com/v1/nearestRoads?points=42.8610804,-72.1083267&key=
A solution I am considering is to find the lat long bounds of the zip code area and find which point is closest to the destination to calculate distance and duration but that is obviously not ideal.
Any ideas or insight would be much appreciated, thanks.
I am participating in a starter Kaggle competition(Crimes in San Francisco) in which I want to predict the category of a crime using a bunch of predictor variables including X and Y coordinates of a crime. As I doubt of the predictive power of the coordinates, I want to transform these variables to something more relevant to the crime category.
So I am thinking that if I had the neighbourhood of San Francisco in which the crime took place, it would be more informative than the actual coordinates of the crime. I can find the neighbourhoods online but of course I cant use the borders of each neighbour to classify the corresponding crime because their shapes are not rectangular or anything like that.
Does anyone have any idea about how I could solve this one?
Thanks guys
Well that's interesting AntoniosK and it's getting close to what I want to accomplish. The problem is that the information " south-east and 2km from city center" can lead to more than one neighborhoods.
I am still thinking that the partition of the city in neighborhoods is valuable because the socio-economic and structural differences between them ( there is a reason why the neighborhoods of each city are separated as such, right?) can lead to a higher probability for a certain category crime and a lower one for another.
That said, your idea made me thinking of using the south-east etc mapping and then use the angle of the segment(point to city center) with x axis to map the point to appropriate neighborhood. I am on it right now. Thanks
After some time on the problem I found that the procedure I want to perform is titled " reverse geocoding". It also turns out that there are some api's to solve this. The best according to my opinion is revgeocode() function contained in ggmap package(google's edition). This one though has a query limit per day(2500 queries) unless you pay for extra.
The one that I turned to though is geonames package and GNneighbourhood function that turns coordinates to neighbours. It is free, though I have experienced some errors(keep in mind that this one is only for US and Canada cities)
revgeocode function-ggmap package
Gnneighbourhood-geonames package
Mine are follow-ups to the question & answer in Approaches for spatial geodesic latitude longitude clustering in R with geodesic or great circle distances.
I would like to better understand:
Question #1: If all the lat / long values are within the same city, is it necessary to use either fossil or distHaversine(...) to first calculate great circle distances ?
or, within a single city, is it OK to run clustering on the lat/long values themselves ?
Question #2: jlhoward suggests that :
It's worth noting that these methods require that all points must go into some cluster. If you just ask which points are close together, and allow that some cities don't go into any cluster, you get very different results.
In my case I would like to ask just ask "which points are close together", without forcing every point into a cluster. How can I do this ?
Question #3: To include one or two factor variables into the clustering (in addition to lat/long), is it as easy as including those factor variables in the df upon which the clustering is run ?
Please confirm.
Thanks!
"within a single city, is it OK to run clustering on the lat/long values themselves ?"
Yes, as long as your city is on the equator, where a degree of longitude is the same distance as a degree of latitude.
I'm standing very close to the north pole. One degree of longitude is 1/360 of the circumference of the circle round the pole from me. Someone ten degrees east of me might only be ten feet away. Someone one degree south of me is miles away. A clustering algorithm based on lat-long would think that guy miles away was closer to me than the guy I can wave to ten degrees east of me.
The solution for small areas to save having to compute great-circle ellipsoid distances is to project to a coordinate system that is near-enough cartesian so that you can use pythagoras' theorem for distance without too much error. Typically you would use a UTM zone transform, which is essentially a coordinate system that puts its equator through your study area.
The spTransform function in sp and rgdal will sort this out for you.
Here is the question I have for all
I already have an existing system that does the "Near By Zipcodes" search.
The purpose of this post is to see if I can optimize the process.
Currently, I have about 43k zipcode records.
The way my current algorithm works is I select 1 record and do a full table scan of 43k records.
Is there a way to only take a subset (lat range, long range) and do the calculation that way?
You can get lat/lon for the centroids of all the zip codes from google, or geocoder.us (or wherever you get your geo data). Use them in your where clause as a rough guide to narrow your search.
What I usually do is bracket my searches plus and minus one degree. As mentioned, degrees latitude are about 69 miles. With longitude, things get a little more complicated. The closer you get to the North pole, the shorter the distance will be from one degree of longitude to another. For instance, at the Florida / Georgia border, one degree of longitude is about 55 miles apart, but at the California / Oregon border, it's only about 50 miles apart.
You first need to have the latitude / longitude for your starting location and probably want to set 4 variables such as: beglat, endlat, beglong and endlong. Assign the beglat to the starting location's latitude minus one degree, the endlat to the starting location's latitude plus one degree, etc. For a tighter search radius, you can choose half a degree or something else.