Add longitude and latitude as entry options for the location module.

+1 for this feature request.

Does anyone know http://www.earthcomber.com? It is using Drupal + Location has even integrated Google Maps directly: http://www.earthcomber.com/community/node/1185

They have lat/long showing....

Hola Gente :;-) (span.: Hi people )

I would like to give my vote to this one.

Doing a check on Zip-Codes worldwide, there is almost no coverage for most parts of the world.

For example: Central America: over 40 million people living here, the region is close to be integrated commercially with the NAFTA (North American Free Trade Area) and yet, with ZIP-Codes there is no way to find somebody in most countries or regions down here.

In exchange, there are good to excellent possiblities to index via

Country - Province - Place - related to Latitude / Longitude

These data is available, with more data like meotorological identifiers, altitude, for free from North American and other Weather Station services or even NASA.

Just Costa Rica, the weather data covers much more points, cities, towns or locations, than zip codes exist.

So my vote is for a layer, where the zip would come in handy - if there is one, and if You happen to know it.

But the prime funtion should look for Country, province (official) or region (un-official or touristic: example: "South Caribbean") and location / place.

Example: Costa Rica, South Caribbean, Punta Mona ...

Well, that is just 1cent ...

Saludos desde Costa Rica
(span. "Greetings from Costa Rica")

Roland

Here's a patch that adds latitude/longitude entry to the location form.
DETAILS:
*The patch creates a new permission called "submit latitude/longitude for locations".
*Roles with this permission will see a couple of extra textfields below the location form when editing a node.
*If the fields are left blank, then the location module will try to use the zipcode (if one is available) to determine the lat/lon.
*When a node is being edited, the lat/lon textfields will be prefilled values ONLY if the user manually entered a lat/lon on the previous edit.
*When a node is being edited, the lat/lon textfields will be left blank if the previous lat/lon values were determined automatically via postal code, rather than by manual entry.
*Filling in your own lat/lon values overrides whatever lat/lon values would be determined from the submitted postal code (if a postal code is submitted).

I will let this patch sit for a day or two to see what others think. Positive feedback (or lack of comments) == commit. If people have dissenting ideas about this setup, I'll look into updating the patch appropriately.

-Ankur

Here's a screenshot of what the forms looks like if the user has permission to submit a lat/lon for a location, assuming the patch posted directly above.

-Ankur

*When a node is being edited, the lat/lon textfields will be left blank if the previous lat/lon values were determined automatically via postal code, rather than by manual entry.

Err...this is no good. How do I know if there are "automatic" lat/lon values? These need to display, perhaps with a note that this was derived from postal code (although I don't think that that matters).

So, we're saying that whatever lat/lon were determined automatically should show up on the edit form.

The next question is: Should there be a note about where the lat/lon were pulled from in the edit interface? What about the view interface? My gut tells me we shouldn't include the lat/lon on the node view interface, much less include a note in the view interface about how the lat/lon were determined. My worry is the situation where someone did not submit a lat/lon and sees one show up in the edit interface.

For now, I'm going to modify the patch to display the lat/lon in the edit form regardless of how they were determined, with no notes anywhere in the process about how a particular lat/lon was determined.

Still willing to hear suggestions on the matter of when and where the lat/lon should be displayed and when and where the source of a lat/lon should be displayed.

-Ankur

There is a small typo in the patch as-is:

+    if (!empty($posted_location['latitude']) && !empty($posted_location['longitude']) && user_access('submit latitude/longitude for locationns')) {

should be

+    if (!empty($posted_location['latitude']) && !empty($posted_location['longitude']) && user_access('submit latitude/longitude for locations')) {

I've applied the attached patch to DRUPAL-4-6 and HEAD.

It's the same as before, except it displays a lat/lon (if you have the right permissions) when previewing or editing a node. If there is a lat/lon (whether it is user-supplied or determined automatically by postal code) the module tries to figure out whether it exactly matches the lat/lon as would be determined by the postal code. If it would, then the module marks the lat/lon in the database as having been determined by automatically by postalcode. Otherwise, we assume it is user-supplied. Saving the source of a latitude/longitude is important because in the future I plan on integrating location with a geocoder (see http://www.geocoder.us). And to this end, the module will need to know in a cron job or somesuch whether the lat/lon were determined manually, from postalcode, or from geocoder.

In anycase, to apply this update, you will need to run the database upgrade by moving the file location_upgrade.php to the base directory (the same directory as index.php) and selecting the update after the last update you selected.

-Ankur

Long-Lat is going to be a very useful feature... I can't wait to start playing with it!

Ankur said (18 Aug) 'I've applied the attached patch to DRUPAL-4-6 and HEAD.'

But I'm confused that the 'latest release' at http://drupal.org/project/location is (4.5.0, 11/05/2005 - 03:15) ... ?

Older versions at http://drupal.org/node/18723/release are :
location (API, module) 4.5.0 Released: May 11, 2005 - 03:15
location (API, module) 4.6.0 Released: May 10, 2005 - 08:15

Sorry if I'm being dumb, but where do I find a patched version of Location.module (I've not facility for running patches on my system) ?

Many thanks,
JohnG

Download the 4.6.0 version here:
http://drupal.org/files/projects/location-4.6.0.tar.gz

There is a bug though, so I'm reopening this, so ankur can fix it.

The line:

print "<h1>Not equal!</h1>";

looks like debug code, and causes problems.
It got committed and needs to be removed.

My bad :)

It's been fixed in the repository.

-Ankur

The logic of *where* the lat/lon came from should not be the job of this module. Any batch actions should throw up variances, but we *don't* need to store where the lat/lon came from.

Let's not screw with the location table any more than we have to. And also, DB changes are usually reserved for HEAD, unless completely unavoidable.

http://drupal.org/node/32058

has code for using geocoder.us to figure out lat/long

another option is to use google maps to figure it out, and read it from there. That may be against the TOS, depending on how you do it.

I think tracking the source of where geocoded data came from is worth while, since inaccurate info is quite annoying, and given the choice between geocoder.us or just zip code based, one is spot on, the other just close, etc. The system should always prefer the most accurate info it can get.

Instead of geocoder.us, why not use a geocoder that has world wide coverage like http://brainoff.com/geocoder/rest/? Might be good for us folks that aren't in the US... I'm working on integrating this into the location module right now.

Also, for what it's worth, I don't see much value in storing where lat-long data comes from.