This is the latitude and longitude of the location.
We might build an automated call to http://geocoder.us/ to get the LatLon for any given location as long as address information is avaliable. OR, more likely we'll use a geo_location module built by Ankur at CivicSpace.
We would need a similar call to something that could return a geocode for just a zipcode.
Explanation of Physical Data Model Implemented in CiviCRM
(contributed by Pat Dunleavey)
I'm thinking that what makes most sense is to enumerate two supported coordinate system types: "LatLong" and "Projected", which is essentially what I originally proposed (though now I understand better why). Pretending that we support projections is misleading at best. Rather, at the
application level we are simply distinguishing between unprojected (latitude/longitude) coordinates, and projected coordinates. That information, along with a units definition, would then be sufficient to be used by routines that calculate the distance between points or filter based
on point location with respect to a polygon, bounding box, or distance from a point.
Beyond that, what I suggest we do is include a field in the coordinate system info record for something called the Open GIS Consortium Well Known Text coordinate system definition.
This standard is becoming widely adopted (I use three GIS applications in my work, and all three use it). It's
documented at http://www.opengeospatial.org/docs/01-009.pdf. We would not actually do anything with this. It would simply by a place for users to store information about the coordinate system in a standard manner, and for
modules yet to be invented to use if they want.
We remove the utm_zone and coord_datum fields in this spec. Their purpose is covered by providing the OGC WKT string.
For example, here's a OGC WKT coordinate system description
for a UTM coordinate system:
PROJCS["NAD27 UTM, Zone 18 North, Meter",
GEOGCS["North_American_Datum_1927",
DATUM["North_American_Datum_1927",
SPHEROID["Clarke - 1866",6378206.4,294.9786982139006],
AUTHORITY["EPSG","6267"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",-75],
PARAMETER["scale_factor",0.9996],
PARAMETER["false_easting",500000],
PARAMETER["false_northing",0],
UNIT["METER",1]]
Get Lat/Lon from google
http://aaronland.info/weblog/2005/02/10/5597/
Additional Thoughts and Resources
This info is excerpted from CivicActions website posted by Dan Robinson and written by 'Anselm'. It provides some good links to standards and tools resources. http://dev.civicactions.net/?q=locativemedia_
There is a community focused on locative media at: http://locative.us http://locative.net
This community has established some patterns that I think are good for adding location capabilities to most projects. See:
http://locative.net/workshop/index.cgi?Locative_Packets
The standard pattern now for adding location support to services is to extend the rss/blogging habit that has become so popular. We add extra fields to what is stored in an rss feed basically - extending the grammer.
In drupal this would mean some extensions to the database to store location features in association with posts.
A 'location' field can be dealt with in many ways.
Ideally the user could type in a street address or a placename and the system could do a translation of that for them into something that it can manage itself ( I prefer longitude latitude as a universal internal key for location ). This new site does brute force geolocation based on user tags:
And we can use a location tool to turn street addresses into long lats:
Possible business logic for deriving lat and lon
Suggested by Boris Mann <borismann@gmail.com>
- Lookup lat/long from street address
- Lookup from zip/postal
- Fall back to straight entry if 1&2 fail/don't exist and/or override
possibility
And 3. might have a permission attached so only admin users can access it. I would know what to enter, or could use different strategies
(online, GPS unit, etc.) for finding out that info.
Geodetic Datum
Posted by Andrew Hoppin to civicspace-dev.
Please remember to include a field for the Projection / Geodetic Datum (see www.colorado.edu/geography/gcraft/notes/datum/datum_f.html if you don't know what that is).
Lat/longs from different sources don't match up precisely necessarily-- you have to know what projection they're in and may have to conduct a transform to get them in the same projection in order to match them up and, for example, plot a bunch of lat/longs from different sources on a = single map
Calculating Distances Between Locations
(algorithm notes from Pat Dunleavey)
Elsewhere in the application would need to be logic for calculating
distances between points in both Lat/Long and cartesian coordinate systems.
For cartesian coordinates, it's just the square root of (delta-X squared
plus delta-y squared). In Lat/Long, you need to either do some spherical
geometry and then convert to units like meters or miles, or over relatively
small areas you could treat it like a cartesian system where the X-scale is
defined as a function of the cosine of, say, the median Y coordinate. I can
spec that out for you if you like.
-Pat
Pat Dunlavey
Williamstown, MA
pat@pdcarto.com
Code Samples
From Aldon on the civicspace list:
<?php
// Put whatever address you want here...
$address = "247 Old Long Ridge Road, Stamford, CT";
$client = new xmlrpc_client("/service/xmlrpc", "rpc.geocoder.us",
80);
$message = new xmlrpcmsg("geocode", array(new xmlrpcval($address,
'string')));
$result = $client->send($message, 5);
// $v gets you down through the structure of the result to where the
real
data is
$v = $result->xv->me['array'][0]->me['struct'];
// The only other fields are information such as street, city and
state
which you already have
// If you pass a bad address, you don't get a fault, you just get
empty
values.
print "Lat = " . $v['lat']->me['double'] ."<br>";
print "Long = " . $v['long']->me['double'] . "<br>";

1 Comment
Hide/Show CommentsOct 31, 2011
Jeff Cote
A client of ours - a large foodbank - wanted to be able to sort the Proximity results ranked by the closeness of the result. They wanted to help their clients in finding the closest resource to their home. After some searching I found some inforamtion on taking the geo_code and converting them into distances. I adapted it for use in this project.
The links where I had initially found a technique for calculating the distances no longer contain that information, so I wonder now if it is a good technique or not. I do know that through testing, the calculated distances where close to distances on a map. The distances are a point to point distance and do not take into account the actual road/path that the clients would follow to get between their homes and the depot.
The calculation for distance:
The links where I may have found this information:
In order to use the calculation, copy, modify and override the CRM/Contact/Form/Search/Custom/Proximity.php file:
This will add the distance variable to the search results.
This code calculates the distance between the two points and sets the result.
(jeff at freeform dot ca)
(Freeform Solutions)