So I have some code that gets the user's location from the phone as a CLLocation, then I do a reverse geocode on it. The problem is that the resulting MKPlacemark has 0 for altitude, despite the fact that the CLLocation had a value in the altitude field.
It makes sense that if I just ask for the address of some coordinates, I don't necessarily get altitude (as that would require topographic logic). Most of the questions on here suggest calling out to a topo service.
I am wondering why the reverse geocoder would not just preserve the altitude, and also asking people what their preferred solution has been to this problem. It's not like it's hard to figure out: I can pass the altitude in separately and then just jam it into my ultimate object (my own address class), but that's ugly.
This is indeed the state of these classes at this time. Probably a bug report with Apple is in order.
Related
I was wondering if anyone would be able to provide insight into whether or not the altitude returned by the CLLocation object is an Ellipsoidal height or a Geoidal height?
I know over in the Android world that the Location class has a member 'Altitude' which is defined as being 'meters above the WGS 84 reference ellipsoid'. This makes the value returned an Ellipsoidal Altitude and the results of a lot of testing seem to back this up.
However, the documentation for the CLLocation class does not make it clear what the altitude member in that class refers to (geoidal or ellipsoidal). A lot of testing has led me to believe that the alittudes are in fact geoidal heights but there is no documentation about whether this is true or not and if it is true, what geoid the heights are based off of (EGM96, Geoid 12B, Geoid 18, etc...). For my application's purpose I need to be able to get altitudes returned from CLLocation objects to be ellipsoidal heights (i.e. add the geoidal undulation calculated from whatever geoid model iOS is using) so that I can then apply a correction from a different geoid that a user has selected.
If anyone has any insight into this topic I would greatly appreciate it!
From altitude documentation,
Discussion
Positive values indicate altitudes above sea level. Negative values indicate altitudes below sea level.
https://developer.apple.com/documentation/corelocation/cllocation/1423820-altitude#declarations
and since geoid is a model of global mean sea level we can infer that returned heights are above the geoid, or orthometric.
https://en.m.wikipedia.org/wiki/Orthometric_height
I couldn't find any reference about the geoid model used in IOS.
When searching on Zillow using an address, the URL looks like this:
http://www.zillow.com/homes/{Street}", -"{City}," -"{State}" "{PostalCode}_rb/
However, there seems to be no documentation regarding the use of geographic coordinates in such a url.
How to use latitude and longitude instead of an address?
An answer in Can I search Zillow using latitude and longitude coordinates? - Zillow Questions (the 1st Google result on "Zillow search by coordinates") dated 03.2015 gives an example:
http://www.zillow.com/homes/#/homes/for_sale/fsba,fsbo,new_lt/1_pnd/88.769211,-70.092773,-90,-158.686523_rect/3_zm/0_mmm/
Testing shows that only the http://www.zillow.com/homes and /88.769211,-70.092773,-90,-158.686523_rect parts are required.
It's x0,y0,x1,y1 (the direction between the points can be any). (The coordinates in the example are quite strange and specify an area up to the North Pole. More realistic ones are e.g. 53.67068,-71.323242,13.453737,-127.045898_rect.)
Since the last test, the technique stopped working. Moreover, coordinates appear to have vanished from property details as well!
There is no way provided to bring up a specific object by coordinates - they are instead uniquely identified by an ID (ZPID - Zillow Property ID) - and the way to bring up one as of now is e.g. http://www.zillow.com/homedetails/7044216_zpid/.
A possible reason is there's no way to guarantee that coordinates identify anything or identify something uniquely. I.e. coordinates are conceptually a search term rather than a means of identification.
Finally, do keep in mind that all this is undocumented and is subject to change (you can already see one quite-a-change above). They only support API as the means to access their services programmatically.
I'm trying to extract location information from the user's Photo library using PhotoKit. Trouble is, all CLLocation objects have a horizontalAccuracy of 0...
Wether it is PHAssetCollection.approximateLocation.horizontalAccuracy or PHAsset.location.horizontalAccuracy doesn't make a difference.
This information is important in my use case, and I know for a fact that in certain circumstances accuracy can be absolutely dreadful( error radius of more than 500 metres ).
Any insights appreciated!
I'm working on a iPhone app that stores location data from a user. However, sometime the user doesn't have service.
Is there an API that estimates location data when the phone gets back into service? Or any other suggestions
No, there is no such API, because that would create wrong locations.
You have to write yourself such a method, that hopefully works in the scope of your application demands:
E.g You could do a linear interpolation when the GPS service has an outage for some seconds.
e.g:
A liner interpolation of lat and lon values work without special geographic calculations.
Just it would not work if you cross the datum limit (border longitude = 180E to 180 W),
and maybe not if you cross the poles.
But both situations will practically not happen.
This is my first time posting a question here, but I have found a lot of help from other people's questions.
My question refers to the -distanceFromLocation: function in CLLocation. I had assumed that finding the distance between point A and point B would be the same as that between point B and point A, but I have found that it is not. I have tested this in a very simple case:
CLLocation *test1 = [[CLLocation alloc] initWithLatitude:37.529530 longitude:-122.259232];
CLLocation *test2 = [[CLLocation alloc] initWithLatitude:47.900002 longitude:-103.495102];
NSLog(#"%f vs %f",[test2 distanceFromLocation:test1],[test1 distanceFromLocation:test2]);
[test1 release];
[test2 release];
The output to this was 1907269.942754 vs 1908105.959114, a difference of almost 900 meters.
Though 900 meters may be a small percentage, I am trying to determine if the user is closer to something than an annotation and 900 meters can change that.
My question is, which one of these values, if any, is correct? Also if which location I test against is important, do I need to always test against the same location (e.g. user to destination and annotation to destination rather than destination to user and annotation to destination)?
Sorry that the sample is a bit out of context, as my project is rather large and this illustrates my problem. Any help would be appreciated as this has caused me quite a bit of confusion and frustration.
The error you're observing is 1 part in 2000. Presumably the algorithm used in this method is optimized for speed, so sorting a list of locations on distance is fast, rather than accurate to the millimeter.
If you need accurate results, don't use these methods but find another way. If you need reproducible results, order the arguments in a defined way, e.g. always start with the lower latitude.