This may sound weird, but i need to know what the maximum amount of digits in a coordinate in the Google maps API is.
Say for an example, i use their "Web Services" API to find an address, then what is the longest possible lat/lng number? like xxx.xxxxx...
I see them referring to a 10 digit number (not counting the dot) in their documentation for the web services api, but i don't know if that's the max?..
Personally i haven't seen anything more than 7 digits after the dot returned, but i know google can at least search for a seemingly endless coordinate.
If anyone knows for sure what the longest coordinate you can expect returned is, please let me know.
SQL-wise:
Latitude/Longitude should use FLOAT/DOUBLE precision.
It's definitely not recommend to use e.g. VARCHAR(20) because numeric comparisons would fail for sure.
API-wise:
Same applies for the Maps JS API;
about the various Data-APIs I'm not sure (and have no time to test that)
(probably just precision-reduction/proximity...)
PHP Manual - Floating point numbers:
The size of a float is platform-dependent, although a maximum of ~1.8e308 with a precision of roughly 14 decimal digits is a common value (the 64 bit IEEE format).
update just being down-voted (5 years later) without a reason (most likely by someone, who failed to comprehend)... while newer versions of mySQL even feature a Point datatype, in order to represent coordinates... still API wise, the data is always posted as String.
Related
If you look at the output of a html5 geolocation request,
it has 14 LAT decimals.
https://www.w3schools.com/Html/tryit.asp?filename=tryhtml5_geolocation
I only find descriptions online, that 9 decimals are already
0,11mm exact.
Why are there 14 decimals?
I can hardly believe, that GPS can tell you micrometer exact position.
And also, what for would that be good?
Why? 1) to pursue precision. 2) to enable people interessed in many details, for their systems to work properly, to use them. 3) because it's very easy for developers like us, to ripoff the unnecessary (from our point of view) decimal parts.
Regarding Google's Geocoding Webservice: Is there documentation (beyond Google's documentation), articles, or anything out there regarding how to format addresses to get accurate results.
Some of my locations have names preceding the address. If it recognizes a street address in the string, I can usually get rooftop back. In some cases having a single quote or special character in the name will cause it to just recognize the address and geocode rooftop.
However, I am also seeing cases where it finds the exact place correctly as an establishment, a church for example, but still says the 'location_type' is approximate. Other cases where having words preceding the address causes it to only seem to recognize the zip code and it just geocodes the zip.
I am wondering if anyone has insight into how Google's Geocoding webservice API recognizes/parses locations? What causes it to see the address in one case, but only see a zip in another?
Also, is there maybe a better way to interpret accuracy than just that 'location_type' field?
So basically you have to follow the standard mailing address format that is used by the respective country the address falls in and refrain from using apt/house/suite numbers. Use street number for the building/complex/entity rather than names.
This is what you need to go through. However, please do your research first and ask a question as a last resort.
I am building an application that uses both GeoNames and Google Places API. The thing is, when I do a search nearby by a specific location (say lat: 47.16, lng: 27.56) on both of the services I do not know how to remove entities that appear both in the results from Google Places and the results from GeoNames(findNearby). I was thinking about using location (latitude and longitude) but it isn't accurate enough. Also, the name varies considerably so this wouldn't work either. Another idea that crossed my mind would be using the types (feature codes for GeoNames and type for Google Places), but there are a lot of types and obviously I can not do a cross reference manually. Any ideas?
Note: I want to use both of them as this is a school project and the requirements specify using more than one source of info.
Thanks.
I think that, unfortunately, the reason you haven't received an answer is that there is no answer that would fully satisfy the requirements.
Even with one provider, a single coordinate could be associated with multiple results. Imagine a large building in New York, for example, where dozens of companies each occupying a floor or part of a floor in the same building, and yet they would all be associated with the same (latitude, longitude) coordinate.
Now consider two sources. Source A says there's a doctor at that location (let's say on the 7th floor). Source B says there'S a doctor too. Can we assume they're the same doctor? Nope. It might be another doctor on another floor. Or it could be the same doctor. It's impossible to tell. The point is, you could try to use feature codes / types to reduce the number of hits by assuming similar locations are the same location, but it's still an assumption.
Anyway, good luck with your assignment from 3 years ago. It was a good idea nonetheless. :)
I want to get geocode from google, and I used to do it with the V2 of the API.
Google send in the json a pretty good information, the accuracy, reference here : http://code.google.com/intl/fr-FR/apis/maps/documentation/javascript/v2/reference.html#GGeoAddressAccuracy
In V3, Google doesn't seem to send me exactly the same information. There is the array "adresse_component", which seem bigger if the accuracy is better, but not exactly.
For example, I have a request accuracy to the street number, the array is of size 8.
Another query is accuracy to the route, so less accuracy, but the array is still of size 8, as there is a row 'sublocality', which not appear in the first case.
Ok, for a result, Google send a data 'types', which have the 'best' accuracy. This types are here : http://code.google.com/intl/fr-FR/apis/maps/documentation/geocoding/#Types
But, there is no real order, and if I wan't the result better than postal_code, I have no clue to how to do that.
So, how can I get this equivalent of the V2 accuracy, whithout some dumb and horrible code ?
Well, there is the location type, which is not so bad :
location_type stores additional data about the specified location. The
following values are currently supported:
"ROOFTOP" indicates that the returned result is a precise geocode for which we have location information accurate down to street address precision.
"RANGE_INTERPOLATED" indicates that the returned result reflects an
approximation (usually on a road) interpolated between two precise
points (such as intersections). Interpolated results are generally
returned when rooftop geocodes are unavailable for a street address.
"GEOMETRIC_CENTER" indicates that the returned result is the geometric
center of a result such as a polyline (for example, a street) or
polygon (region)."
"APPROXIMATE" indicates that the returned result is
approximate.
I test if the location_type is different of approximate, and it gives some good results.
With Google deprecating their Geocoding v2 API later this year, there's going to be a ton of people migrating their geocoding logic to v3 and this very question is going to crop up: How to map the 'location_type' string to an equivalent 'accuracy'?
Here's a decent mapping:
"ROOFTOP" -> 9
[Everything else] -> 4 to 8 (aka the text string might as well read "GARBAGE")
If something other than ROOFTOP is specified, use the area of 'northeast' and 'southwest' to decide if it is accurate enough for you.
Now what should happen if you don't get something "accurate"? Run a Google Places text search query for the same address. Google Places does geocoding as well and, with Billing enabled, you can get 10,000 Places text search queries per day (no rate limit) and Google claims they won't charge the card (they supposedly just use it for verifying the account). With Billing, you get 100,000 queries, but Places text search queries have a "cost" of 10 times the amount of a regular Places query, hence the aforementioned 10,000 limit. Places can be finicky though and you should only consider responses with one result.
Sometimes Places queries will not return a zipcode - especially if one isn't sent. If you need the zipcode, take the lat/lng results of the Places query and feed it back into the geocoder, which will usually spit out an address with a zipcode (and very frequently a ROOFTOP match).
It should be noted that the official Geocoding API courtesy limit is 2,500 requests per day with a rate limit of one per second per IP address. Therefore, following the above formula will likely decimate and may even halve the number of geocodings available to you.
If you need more than the Google Geocoding limit (who doesn't?), invent your own mini geocoding service with something like the OpenStreetMap database. Clone the parts of OpenStreetMap that you need and write your own geocoder (or use a library). Then you can geocode to your heart's content with no quantity limit or rate limit. If you still use Google Maps, you can use Google's geocoder as a fallback should the OSM geocoder not be accurate enough for all cases.
Alternatively, if you trust your users to not submit bogus data (really?) and have to use the Google geocoding service, you could also abuse a user's web browser by having the browser geocode information for you and then feed the results to your server. You might burn through the user's daily limit and you risk someone pushing bogus data, but if you are going to all that trouble, do you actually care?
At any rate, the tips above should suffice for interim usage for most users to get a working v3 API set up. Ran into this issue myself, so figured I'd share with the community a halfway decent solution. I still think v2 was the better API - integer accuracy ratings instead of ugly text strings always wins out.
Paula's answer is good but you do need to also consider John's comment that ROOFTOP can return garbage.
I use a post-geocode-query sanity checker to get rid of those cases where location_type is 'ROOFTOP' but the address has nothing to do with the address you sent to google - this sanity checker compares the new address with the old address and considers what changed and by how much. The google geocoder is good at fixing typos, sometimes, but it can also make some non-sensical decisions - for instance choose a different city, a different state, or a different country. You need to decide if the result is a fix in a typo or if the geocode logic went astray.
So, don't just assume ROOFTOP == 9. It can also be garbage if the new address is way off from the original that you sent.
For things like Apartments or building with multiple units, the location_type = 'RANGE_INTERPOLATED' may also be accurate when the result type is 'subpremise'.
Remember, geocoding is not the same thing as address validation. They have some overlap but google geocode logic tries too hard to get you an answer, even when your input is garbage.
If I had lat/long data for all our leads in Salesforce, is there a way to write a query to group them, or say list all the leads within 10 miles of San Francisco, CA ?
[EDIT: Clarification]
I have thousands of leads with both a full address, and long/lats.
I want to build a query on these leads that will give me all of the leads near San Francisco, CA. This means doing GIS type work within salesforce.
I could of course filter specifically on city, or zipcodes or area code, but this presents some problems when trying to rollup a whole metro area.
Yes. You need to Reverse GeoCode them with a tool/service. In the past I have used Maporamas service but it was quite expensive and that was before Google maps and virtual earth existed so I am sure there is something cheaper(free) out there now.... Googling around I have found this and this
EDIT:
OK from What I understand you are trying to calculate the distance between 2 lat/long points. I would start by discounting the ones that where outside you sphere of (lets say) 10 miles. So from your central point you will want to get the the coordinates 10 miles, East, West, South and North. To do this you need to use the Great-circle distance formula.
From that point you have you Sales Force Data if you wish to break this data up further then you need to order the points by distance from the central point. To do this you need to use the Haversine formula
I am not sure what you language preference is so I just included some examples from SQL(mainly) and C#
Haversine Formula in C# and in SQL
Determine the distance between ZIP codes using C#
Great Circle SQL
Great Circle 2
Use GeoHash.org (either as a web service or implement the algorithm). It hashes your lat-long coords into a form that appears similar for nearby places. For example A may have a hash like "akusDf3af" and B might have a hash like "akusDf3b2" if they are nearby. Then do a SOQL query that looks for places starting with the same n characters as a known location. Your n will determine the radius of the lookup.
These are some great technical solutions that can provide very exact answers, but two things to consider:
geospatial proximity does not map neatly to responsibility
Ownership calculation seems to be done best through postal code lookups or other rules that don't allow for gaps or overlaps. Otherwise, you'll have two (or more) salespeople fighting over leads that are close to both of them, and ignore those leads that are far away from both of them.
So, if you're using geo-calculations like those above to assign ownership, just acknowledge the system will leak and create business rules to accomodate for that. But a simple postal lookup to define territories (as salesforce's own territory management feature does) might be better.
I'd suggest the problem we're trying to solve geospatially is not who owns which lead. Rather, given all the leads you own, which are nearby?
maps often offer more data per pixel than columnar reports
Again, geospatial data in a report may not be the best answer. A lead 50km away, but along a major road, is more interesting than another lead 50km away on the other side of a mountain or lake. Or a lead close to other leads is more interesting than a lead by itself.
A report can't show this, but a map can.
Salesforce has some great examples of Google Maps integrations. Instead of a columnar report called "My Nearby Leads", why not a visualforce page, with a google map inside? You're giving the user far more information than a columnar report could. They might like it better, and it's easier to implement than trying to calculate some of the equations above.
Just another perspective that may (or may not) be appropriate to the problem at hand.
This post is really old, but is showing up at the top of Google results, so I figured I would post some info to it anyways.
2 nice mapping tools are batchgeo.com and geocod.io. Geocod.io can even give you lat and long coordinates from an address.
If you just need a one time calculation, you can use Excel. Export all your leads with the lat and long. Then go to Google Maps and get the lat and long in decimal degrees for the city center of wherever you want to measure to.
Then use this formula in excel to calculate the distance between the coordinates in miles. Lat1dd and Long1dd are the coordinates for one point, and the lat2dd and long2dd are coordinate points for the other point.
=3963*ACOS(COS(RADIANS(90-lat1dd))*COS(RADIANS(90-lat2dd))+SIN(RADIANS(90-lat1dd))*SIN(RADIANS(90-lat2dd))*COS(RADIANS(long1dd-long2dd)))
After you run it, just sort the results from smallest to largest to get those results that are the closest.
I haven't done this next part yet, but conceptually it should work. We have a field that lists the major market each account is in. Example, Chicago IL. I am going to build a trigger or formula field that essentially says IF(Market="Chicago IL") then use X and Y for the lat and long. These will be hardcoded as the city center for that specific market. The query will then run each individual account's lat and long against the one from the city center to calculate a distance.
If you wanted to break the market into different zones, you could adjust your formula so it uses < and > on the lat and long fields. Everything less than X but greater than Y goes in Zone A, etc.
Hope this helps someone.