I have recently posted a question regarding getting the user location which I thought I had solved using geolocation.GeoLocationProvider. However, I am having strange behaviour on different devices. On an iphone 5s, I get the most accurate and smallest circle marking my position. On a galaxy S3 I get very large circles and takes long to connect. I then connected a Nexus to my mobile over bluetooth and shared 3G internet. Funnily enough, my position was not showing at all. In all 3 cases, I tried going into bing maps and google maps and they all have shown my position very accurately. Is there anything I am skipping for this discrepancy between my code and bing/google maps' code?
Thanks you all,
Justin
The Bing Maps site uses the same functionality. All this does is wrap the different web based geolocation API's for different browsers into one easy to use class. This method pulls the location from the browser built-in geolocation functionality (older browsers had several different ways of doing this). This will make use of a GPS device if it has access (small circle), fall back to WIFI or IP address (large circles). A couple of things worth checking, if this is being used in an app, have you enabled access to the geolocation sensors? If this is being used in as a web app through the browser, did you get a prompt to allow access to your location and did you press Allow? If the device isn't able to access the GPS and it's using share WIFI from another phone I could see how this might confuse things.
Another option is to use the HTML5 geolocation API: http://www.w3schools.com/HTML/html5_geolocation.asp
Related
Inside iOS It's possible to get the user ETA using MKDirectionsRequest to get the user ETA from a place to another, but how to get this data inside watchkit without asking for the iOS app? It's important to the watch app be full standalone, so communication with the iOS it's not an option.
Im developing to watchOS series 2 with watchOS4 beta 6
Sadly routing is not available in WatchKit at the moment and according to the documentation, it won't be available in watchOS4 either.
Even if requesting data from the iOS app would be an option for you, I don't think it is the right way to go. For this to work, you would need to have your iOS app running at least in the background, which isn't always feasible.
However, a good alternative is to use the Google Maps Directions REST API. It works perfectly on watchOS and you need less network requests to achieve the same goal than if you used Apple Maps. For instance, you don't need to do any geocoding, you can use coordinates for the destination and an address or even the name of a place mark (such as an airport) as the starting point. Using MapKit you would first need to geocode the address before you could get destinations. You can also get both an ETA and the directions in the same request using the Google Maps Directions API, for which you would need two requests using MapKit.
I am researching how to create an app for my work that allows clients to download the app (preferably via the app store) and using some sort of wifi triangulation/fingerprints be able to determine their location for essentially an interactive tour.
Now, my question specifically is what is the best route to take for the iPhone? None of the clients will be expected to have jail broken iPhones.
To my understanding this requires the use of the wifi data which is a private api therefore not meeting the app store requirements. The biggest question I have is how does American Museum of Natural History get away with using the same technology, but still available on the app store?
if you're unfamiliar with American Museum of Natural History interactive tour app, see here:
http://itunes.apple.com/us/app/amnh-explorer/id381227123?mt=8
Thank you for any clarification you can provide.
I'm one of the developers of the AMNH Explorer app you're referencing.
Explorer uses the Cisco "Mobility Services Engine" (MSE) behind the scenes to determine its location. This is part of their Cisco wifi installation. The network itself listens for devices in the museum and estimates their position via Wifi triangulation. We do a bit of work in the app to "ask" the MSE for our current location.
Doing this work on the network side was (and still is) the only available option for iOS since, as you've found, the wifi scanning functions are considered to be private APIs.
If you'd like to build your own system and mobile app for doing something similar, you might start with the MSE.
Alternatively, we've built the same tech from Explorer into a new platform called Meridian which provides location-based services on both iOS and Android. Definitely get in touch with us via the website if you're interested in building on that.
Update 6/1/2017
Thought I would update this old answer - AMNH is no longer using the Wifi-based system I describe above, as of a few years ago. They now use an installation of a few hundred battery-powered Bluetooth Beacons (also provided by Meridian). The device (iOS or Android) scans for nearby beacons and, based on their known locations and RSSI values, triangulates a position. You can read more about it in this article.
Navizon offers an indoor positioning solution that works for iOS as well as any other platform. You can check it out here:
http://www.navizon.com/product-navizon-indoor-triangulation-system
It works by triangulating the WiFi signals transmitted by the device. Since it doesn't require an app to run on the phone, it bypasses the iOS limitations and can locate any other WiFi device for that matter.
Google recently launched an API called Maps Geolocation API. You can use it for indoor tracking of devices, which essentially can be used to achieve something similar to what AMNH's app does.
I would do this using Augmented Reality. There is a system sort of in place for this, the idea being that you place physical markers that have virtual information associated with them. I believe the system I saw was a type of bar code. When a user holds up the phone with the app, the app uses the camera to read the code and then display information. This could easily be used to make a virtual tour type app distributable through the app store and not even require a WIFI or 3/4G connection. This assumes that you simply load your information and store it locally with your app. Then to update it you simply push an update through the app store. Another solution is to use a SOAP/REST service and provide the information in that way, and this does not use private API's, though it does require some form of internet connection. For this you can see a question I asked about this topic a little bit ago:
SOAP/XML Tutorials Question
In addition, you could load a map of your tour location, and based on what code is scanned you can locate the user on the map and give suggested routes based on interests etc.
I found this tutorial recently on augmented reality, I haven't gone through it, but if its anything like the rest of Ray's tutorials, it will be extremely helpful.
http://www.raywenderlich.com/3997/introduction-to-augmented-reality-on-the-iphone
I'll stick around to clarify any questions or other concerns you may have with your app.
To augment the original answer for devs who were using Cisco MSE for indoor location - now they have an iOS and Android SDK which enables you to do indoor location using the MSE. A simulator can be used as well to develop the app without implementing the infrastructure to start with : https://developer.cisco.com/site/cmx-mobility-services/downloads/
For indoor location you can use Bluetooth LE beacons since it's a very accessible technology nowadays, there are several methods:
Trilateration: it uses 3 beacons, but with the noise and attenuation of Bluetooth signals, it gets quite difficult to determine the exact position and also it's not easy to use more than 3 beacons to increase accuracy.
Levenberg Marquadt method: used to solve non-linear squares problems showed good results on indoor positioning.
Dead Reckoning method: using the motion co-processor of the device, giving an initial position you can calculate the moving path of the device. Not that easy to implement anyway.
I wrote a post on the topic, you can find more info here: http://bits.citrusbyte.com/indoor-positioning-with-beacons/
And you can use this iOS app for your own indoor positioning experiments: https://github.com/citrusbyte/beacons-positioning
I doubt the American Museum is actually using private APIS; you'll probably find the routers that have been setup serve different responses to each other, so the app can detect it's position in the museum.
If you are looking for a cheaper to way to do the same task, you could have signs with QR codes, and use an open source library to let users scan these barcodes as they move through the museum, and update the onscreen content accordingly. On an even more low tech level, you can just tag each area with unique numbers, and distinguish that way.
I'm using the Geolocation API (often referred to as "HTML5 Geolocation") to get the current position of the user. It is updated automatically if you move (checked every second). Primarily targeted (and currently tested) at iPhones, but should work on other mobile devices too. You can see an example here:
http://jsbin.com/uyoyey/
The accuracy, which you can see in each line after the pipe, is around 3000 (meters) when I'm testing (outside). Which is quite bad obviously. The native Maps-App on my iPhone is way more precise. Approximately around 10 to 30 Meters (by looking at the map and where I am standing. Checking long- and lat-values in another app also gives more accurate numbers.
When I now switch back to Safari the accuracy jumps to 10 to 30 but reverts back to 3000 after a second.
Questions:
Can you replicate this behavior?
Why is the location so far off in the first place?
Is there a difference between accessing GPS-Data via Geolocation and CLLocationManager (which I think is used by native apps)?
Thanks!
Update 1:
I'm getting more accurate results when testing on other places (larger city) but am now wondering if the native Apps also use Motion Tracking to update the location. Which would explain why the Maps App can track my steps while Safari doesn't recognize them.
Update 2 (03.08.11):
In an email-conversation with Peter-Paul Koch he wrote that Safari mainly uses wifi for Geolocation to preserve battery life. Which may explain the differences.
Im still not entirely sure what is going on though.
Old: Here are the test result for getCurrentPosition function with wifi turned off on android 2.2, iOS4, and iOS5.
On both android browser and iOS 4 Safari, I'm getting GPS accuracy level in magnitude of 1000 meters. But on iOS 5 Safari, I'm able to get down to 5 meter accuracy. Seems GPS has improved on iOS 5, but it is just a small slice of the market out there. Overall, it is still not good to develop web app that relies on accurate GPS reading.
Something I found during testing - the android browser GPS stops responding after about 70 calls made to getCurrentLocation. This might be a device specific problem but it is another unreliable factor in browser based GPS functionality.
Update: I was testing with the watchPosition function call and it is produced much more accurate result on Android and iOS4. It the way to go... Sample code: http://jsbin.com/ugebif/3
I can’t, but only due to laziness :)
I’m not sure, but I suspect Safari is using the non-GPS parts of the iPhone’s location awareness.
Again, I’m not sure, but Dive into HTML5 mentions that the HTML5 geolocation API lets you pass a PositionOptions object to getCurrentPosition, and that this object has an enableHighAccuracy property.
Setting that to true might make Safari use the same high-accuracy positioning as CLLocationManager. (I’ve no experience with this myself though.)
I'm trying to integrated in our iOS app. Due to the bad relationship between Google & our government, Google Map is not a good idea.
We have bought a local map service company's javascript & Web Services based SDK, now we want to use it on iOS. But it seems that MapKit does not support customer tiles.
So here are my current ideas:
Use UIWebView. But I tried that map in Safari, I can't drag to move the map nor use two fingers to zoom. I think I need to call some javascripts while touch events happens.
Build a costumer UIScrollView, download map images and display them using iOS sdk. But that map service does not have API to download images, I tried to read their 200KB+ undocumented javascript to find out the relationship between location & image files, but I got no results for now.
Both the two ways could face certain legal risks. I'm not sure what the purchase contract is like.
I need suggestions about the two ways or some new ideas. Thanks guys.
There are a couple of non-Google map implementations available on github that you might be able to use (linked via CocoaControls):
NAMapKit
MRMapView
I want to build an iPhone App that should contact a server that is nearest to its location.
The app itself knows where the servers are located and it should find out which one to choose.
Because I expect many users with an iPod touch I can't use GPS to do this.
On StackOverflow and ServerFault I found this possible solutions:
Use Anycast technology to route users => I can't use this method because the device itself should route the requests and know where they are going.
Get country code and use the Google Directions API to determinate which server is nearest.
Get location by IP (GeoDNS etc.) and do the same (see above).
Method 2 seems good but I have three questions to that:
The API sends me the whole route from point x to point z. I just want to have distance. Is there a way to do that?
Google says they have a usage limit of 2,500 request per day. How do they control that? By IP? I ask this because they say you don't have to use an API key - how do they control then?
Is is a good idea to use Google without having any trouble later? My app itself will be free but I'll have In-App Purchases in it. Does that matter?
I hope somebody has experience in this. Thanks in advance!
Paul
In many cases, iOS will still return a location when requested on devices without GPS. Remember, the first generation iPhone didn't have GPS, but could still do location based services. iOS will use a number of techniques (IP geolocation, skyhook, etc) to find the location of a user, in addition to GPS.
Anyway, to answer some of your questions:
The 2,500 requests per day is per end user, or typically per IP address. So you shouldn't need to worry about getting capped. You should however be aware that you need to display a Google Map to use the API, so if you're using their API and not using a mapView you may have an issue.
I'm not entirely sure why you would need to use the Google directions API in the first place. If you can get lat/lon coordinates of both the user's current location and your servers you can just use iOS's built-in CoreLocation methods to get the distance between them, and decide accordingly ([CLLocation getDistanceFromLocation]).