I know that the best way to fetch the user position (not only cords, but also country name and city name) is using client side script, right?
But I have seen that user can deny to say his position, so, how can I determinate it in the server side? What is the best way to do it? Is there any Zend Framework extension?
It's possible with the IP but not 100% sure. You can look for web service like this one : http://www.ip2location.com/ or if you just want the country download the ip database.
You can find visitors position according to IP addresses. This data is not as exact as gps position or cell data information although at least you can find out visitior's country.
PHP has core functionality to access ip:
http://www.php.net/manual/en/reserved.variables.server.php
The are certain projects that can handle ip to place (country) conversion:
http://code.google.com/p/php-ip-2-country/
Related
I'm trying to define the API for the REST paths of a new service where I have devices, and each device has a current location.
It needs a bit of background to understand the problem:
This is about pushing current device locations to a central server
Position updates are sometimes calculated on the device itself (GPS) and sent from the device (smartphone) to a server, but sometimes also via an external service (e.g. WiFi positioning system) and send from that system to a server
Each device has a unique id which the smartphone knows. The WiFi positioning system cannot know this id, it just knows the WiFi mac address.
Each device has several interfaces for position updates (mac addresses)
Regardless of where / from which interface location updates come, all location data should be linked to the same unique device id
So much for the background. Now about the API design. As mentioned above, I may get location updates where only the mac address is known, and I may get location updates where the unique device id is known. In both cases I can assume the id I get is unique and theoretically I can say that mac address x belongs to device y. Practically, this means I have a non-unique index to my location REST API:
For an example, consider I have a device with ID "123" and two mac addresses "abc" and "xyz". Commonly, my REST API path would group locations under the unique device:
/devices/$id/location
Now the problem is that there are multiple (unique) ids, each however related to one same device.
Like for example this would push a location by unique device id from the smartphone (where I know that unique ID, but do NOT know the mac address of the interface):
PUT /devices/123/location
And this is where an external system which only knows the mac address is pushing the location update using the mac address as key:
PUT /devices/abc/location
PUT /devices/xyz/location
You can assume that internally I can relate mac addresses and unique device IDs to one unique internal device. I could update and return location and device info using either a mac address and a device id.
For example the following GET requests using either the unique device id or unique mac will return the same location object:
GET /devices/123/location
GET /devices/abc/location
GET /devices/xyz/location
But is that a valid REST design where I can have multiple paths to the same resource? Should I rather change my REST paths, and how?
It might be useful to think about how you would design a web site that supports this behavior...
You might design that protocol this way: the client loads a known bookmark URI. Available in the representation of that page are two links, one for clients that know the mac address, a different link for those that know the identifier. The client would choose the appropriate link to follow. The representation returned by that would be a form, customized for the specific use case; the description of the form would specify the expected fields. The client would fill in the known fields (ignoring any unknown fields, which presumably have reasonable default values), and submit the form. The browser would use standard processing rules to produce the appropriate HTTP request to the action specified in the form.
In this case, where what we are interested in is (effectively) looking up the URI of the resource we want based on the information we have, we would normally use GET as the form method. That would send a query to the server, and from there the server can communicate (perhaps via re-direct) the appropriate URI to use for that device.
Once you've got the correct URI to use, GET/PUT/POST/PATCH/DELETE should all work as you would expect.
is that a valid REST design where I can have multiple paths to the same resource?
If the identifiers are different, then the resources are different. You are, of course, allowed to have more than one resource that expresses some concept (or, to put it another way, two different resources are allowed to share a single semantic mapping).
For your specific case, it would probably be OK to have a resource for clients that know the device by id, and another for clients that know the device by location. However, sharing a single resource identifier for both cases simplifies the server side caching story.
Part of the point of REST: if you define your media types and relations carefully, the server should be able to change the caching strategies used without breaking any clients (because the clients are just following links and submitting forms provided by the server).
With ORSM there are 3 profiles for different modes of transport, cycle, foot and car. These come with OSRM.
According to the following post which was made 1 year ago, OSRM does not support multiple profiles:
OSM routing (OSRM): do I need to duplicate all data for different profiles?
Yet in the official documentation there is a profile argument as part of the URL called for retrieving a route from a running OSRM instance:
http://project-osrm.org/docs/v5.6.4/api/#general-options
The path would look something like this:
http://router.project-osrm.org/route/v1/driving/
Without driving, foot or cycle in the URL a route won't be retrieved so one of them is required for the API, yet if I compile a route for car on the server, but then use /foot/ in the URL to retrieve a route, it will still retrieve a car based route, completely ignoring 'foot'.
Could anybody from OSRM explain why something as useful as multiple profile support has been withdrawn, and what the point of driving is in the above URL seeing as it is ignored anyway and just appears to use the profile attached to the running instance of OSRM?
The solution to the problem of multiple profiles appears to be to host parallel copies of the routing machine for each profile and address different IP's, so again, what is the point of 'profile' in the URL?
Could anybody from OSRM explain why something as useful as multiple profile support has been withdrawn
The support has never been there. You will need to run separate osrm instances for each profile.
The URL option is merely there to make it easier to stick a nginx in front of your OSRM instances and distribute to the correct instance based on profile string.
We might implement multiple profiles in the same OSRM instance in the future, but this is still far out.
Ok... maybe forbidden by Apple, but assuming this is permitted. What would be the best way to get the current location (not difficult) and posting it to a web service (also not much of a challenge). The app is for an artist who wants people to see where he is at the moment. Personally, I wouldn't want people to know where I am 24/7 but that's performance art I guess. An exact location is not wanted but a town or area would be preferred. I could modify the string when it gets to the server and make it more vague by rounding the LOG and LAT.
The app the fans would use would retrieve his current location from the server and update the map view with a location.
I suppose one way would be for him to find out his coordinates and post that to a web page but I'd like it to update automatically.
A response with code is not necessary, just a general opinion on methodology/advisability would be appreciated
I would probably give him a webpage to go to that records his position every time he visits. It would be a private URL, and perhaps use some lightweight authentication. For versatility, I'd record the exact position in the database (in case he changes his mind on how it should work later on). However, you could use an external service or another purchased database with zips or city information with lat/lng data, so you could just provide users of the client app with his general vicinity rather than exact location.
The alternative would be to give him an ad hoc app that does the same thing, but putting together that location recording webpage would be a much simpler process. Could be handy for other things, too.
Here's a little writeup about getting location from mobile Safari, just as a reference: http://mobiforge.com/developing/story/location-iphone-web-apps
Why wouldn't you just use google latitude and read out his status?
I think this should really be done as a web page web-app. You can get coordinates from the device through mobile safari and you can skip the app approval process. You can also set it up so it runs fullscreen on his phone and he won't know the difference. You can also put a password on it.
There is a good chance it would not get approved as a regular app.
You can always meta refresh the page to keep it updating.
http://smithsrus.com/gps-geolocation-in-safari-on-iphone-os-3-0/
"Artist" must log in to his application (thus insuring that he want to share his coordinates with your webserver), then you use CLLocationManager to get his coordinates and make a reverse geocoding using Google Maps API to get country and city for given coordinates.
Can't see anything special about it :)
Generally speaking, how does an app like "Around Me" acquire the information it displays?
For example: the restaurants that show up in a list that are near me with the address and distance (I think I get the distance piece) where is this information extracted from? Is it Google or something?
I'm not asking how to implement this (that's over my head!) just get an idea of how it occurs.
Thanks StackOverFlow people.
I haven't seen that specific app, but most such apps either have an embedded database of locations or they dynamically query a server back-end (e.g. using HTTP) to fetch a set of locations near you. They know where you are because the app has access to location services to find out your geographic location.
The iPhone has a GPS unit which gives you your latitude and longitude, which it then sends to a backend server (Say Google Maps) and queries it for, in your case a restaurant. The server responds with a set of locations around you.
My current app needs to store address information for a user. I'm currently debating whether to use the customary street address / city / state / zip textboxes and dropdowns or to go with Google's method of simply having everything on one line. Any thoughts on the pros/cons of storing address information in either of these manners?
You should split it up. It will make it far easier to do reporting down the road. What happens if you want to pull up all the residents of a state or zip code, or city? If you use all one field, you will be stuck and wish you had split it up.
Also, users will forget to put in all the information you need if you don't prompt them for it.
Judging by the user-input tag on your post, I assume you are referring to how the user enters the data, and now how you are storing the data in your back-end database.
Presumably your database will still need to store this information as separate fields, if you want to be able to sort and analyse the information (e.g. for reporting and statistics purposes).
In this case, I think it would depend on how confident you are that you could parse the addressing information properly into its individual fields.
One hybrid option would be to allow the user to enter the address as a single line, and then do a best-effort parsing of the information into the separate fields. This is similar to how Outlook manages addresses for contacts - you enter all of the information into a single memo field, and then it splits it up for you. You can then correct if it interpreted any of the fields wrong.
I would be very much against just having a single text field where users enter their address. You'd be surprised how many people will leave out their zip code or some other important info if you don't have a specific field for it. Also, as others have mentioned, it make reporting much easier to report on this information later if all the data is pre-parsed. As other users mentioned, programs like outlook will parse this information, but only because the source of the data is often the signatures of emails, which is something that is never in a consistent format.
I tend to split it up, allows searching to be done for a specific section of the address and you can limit the addresses you want to handle by knowing the formatting i.e. Only ship to east coast addresses.
1) You should split it.
2) May I recommend you read this before you attempt to do international address input?
I concur with Kibbee. I was even surprised to see people don't even read the field's labels, inverting first and last name, postal code and city, etc.
No, you can't determinate if a postal code is valid, in a Web application targeting international customers...
Some countries have alpha characters in postal code, various lengths, no state info, etc.
Definitely split the input. If you can help it--and depending upon your business requirements--it may be wise to perform address verification at the point of entry. This will allow you to know that your addresses are going into your database clean and allow you to do a number of other things such as fraud prevention. Having a verified address can help reduce shipping costs if you're shipping physical goods to your customers and can help reduce credit card merchant fees by ensuring the correct ZIP Code is submitted during AVS verification.
In the interest of full disclosure, I'm the founder of SmartyStreets. We offer CASS-certified address verification services. Users can upload a list for scrubbing (CSV/Excel/etc) to our website or use our address verification web service API called LiveAddress.