GEO Map Locator

Is it where your location is?





Find us on the map test: Gmap travel example: the destination is assign via Event's TV lat/long -titude values
Changing topic:
Banner Slider integration to Magento ecommerce  finale stock  RSS feeds integration to and from MODX  ModX CMS for a Catholic School  




Continue reading more details:

Detecting the User' Location

Currently, several ways exist to detect the user's location within a browser. None of these methods are part of the Google Maps API; instead, they are common industry standards.

  • Newer browsers are starting to support the W3C Geolocation standard. This standard is part of HTML5 and will likely become the de-facto standard going forward. All applications that wish to perform geolocation should support this standard.
  • Some browsers with Google Gears can use Google Gears Geolocation API. Since widespread support for the W3C standard is still forthcoming, checking for Gears is a good fallback mechanism.

As a user's IP address can only provide a rough estimate of a user's location, we don't recommend using this approach for geolocation. The W3C approach is the easiest and most fully-supported so it should be prioritized over other methods. If you do decide to use Google Gears, you should first check for whether the browser supports the W3C standard. (Note that using Google Gears will require you to load the Gears initialization Javascript).

The following example attempts to determine the user's location through the W3C navigator.geolocation property first, attempts a Google Gears approach second, and bails out if neither approach works.

// Note that using Google Gears requires loading the Javascript
// at http://code.google.com/apis/gears/gears_init.js

var initialLocation;
var siberia = new google.maps.LatLng(60, 105);
var newyork = new google.maps.LatLng(40.69847032728747, -73.9514422416687);
var browserSupportFlag =  new Boolean();

function initialize() {
  var myOptions = {
    zoom: 6,
    mapTypeId: google.maps.MapTypeId.ROADMAP
  };
  var map = new google.maps.Map(document.getElementById("map_canvas"), myOptions);
  
  // Try W3C Geolocation (Preferred)
  if(navigator.geolocation) {
    browserSupportFlag = true;
    navigator.geolocation.getCurrentPosition(function(position) {
      initialLocation = new google.maps.LatLng(position.coords.latitude,position.coords.longitude);
      map.setCenter(initialLocation);
    }, function() {
      handleNoGeolocation(browserSupportFlag);
    });
  // Try Google Gears Geolocation
  } else if (google.gears) {
    browserSupportFlag = true;
    var geo = google.gears.factory.create('beta.geolocation');
    geo.getCurrentPosition(function(position) {
      initialLocation = new google.maps.LatLng(position.latitude,position.longitude);
      map.setCenter(initialLocation);
    }, function() {
      handleNoGeoLocation(browserSupportFlag);
    });
  // Browser doesn't support Geolocation
  } else {
    browserSupportFlag = false;
    handleNoGeolocation(browserSupportFlag);
  }
  
  function handleNoGeolocation(errorFlag) {
    if (errorFlag == true) {
      alert("Geolocation service failed.");
      initialLocation = newyork;
    } else {
      alert("Your browser doesn't support geolocation. We've placed you in Siberia.");
      initialLocation = siberia;
    }
    map.setCenter(initialLocation);
  }
}

View example (map-geolocation.html)

Specifying the Sensor Parameter:

Use of the Google Maps API requires that you indicate whether your application is using a sensor (such as a GPS locator) to determine the user's location. This is especially important for mobile devices. Applications must pass a required sensor parameter to the <script> tag when including the Maps API javascript code, indicating whether or not your application is using a sensor device.

Applications that determine the user's location via a sensor must pass sensor=true when loading the Maps API JavaScript.

#
# Example using sensor when loading the Maps JavaScript API
#
<script type="text/javascript" src="http://maps.google.com/maps/api/js?sensor=true"></script>

Note that even if your device does not use a sensing device, you must still pass this parameter, setting its value to false.

Developing for Mobile Devices (iPhone & Android device):

The Google Maps API V3 has been designed to load fast and work well on mobile devices. In particular, we have focused on development for advanced mobile devices such as the iPhone and handsets running the Android operating system. Mobile devices have smaller screen sizes than typical browsers on the desktop. As well, they often have particular behavior specific to those devices (such as "pinch-to-zoom" on the iPhone). If you wish to have your application work well on mobile devices, we recommend the following:

  • Set the <div> containing your map to have width and height attributes of 100%. Be aware that some older desktop browsers don't display well with these values, however.

  • You can detect iPhone and Android devices by inspecting the navigator.userAgent property within the DOM:

    function detectBrowser() {
          var useragent = navigator.userAgent;
          var mapdiv = document.getElementById("map_canvas");
        
          if (useragent.indexOf('iPhone') != -1 || useragent.indexOf('Android') != -1 ) {
        mapdiv    .style.width = '100%';
        mapdiv    .style.height = '100%';
          } else {
        mapdiv    .style.width = '600px';
        mapdiv    .style.height = '800px';
          }
    }

    This allows you to alter layout for particular devices, as we've done here to change the screen real estate for each device.

  • The iPhone device respects the following <meta> tag:

    <meta name="viewport" content="initial-scale=1.0, user-scalable=no" />

    This setting specifies that this map should be displayed full-screen and should not be resizable by the user. Android devices running software version 1.5 (Cupcake) also support these parameters. Note that the iPhone's Safari browser requires this <meta> tag be included within the page's <head> element.

For more information on development for the iPhone, consult Apple's Developer documentation. For more information on development of Android devices, consult the Android documentation.

Localization in the V3 Maps API:

You may localize your Maps API application both by altering default language settings and by setting the application's region code, which alters how it behaves based on a given country or territory.

Language Localization:

The Google Maps API uses the browser's preferred language setting when displaying textual information such as the names for controls, copyright notices, driving directions and labels on maps. In most cases, this is preferable; you usually do not wish to override the user's preferred language setting. However, if you wish to change the Maps API to ignore the browser's language setting and force it to display information in a particular language, you can add an optional language parameter to the <script> tag when including the Maps API javascript code, specifying the language to use.

For example, to display a Maps API application in Japanese, add &language=ja to the <script> tag as shown below:

<script type="text/javascript" src="http://maps.google.com/maps/api/js?sensor=false&language=ja">

Note: loading the API in the manner shown above will use the Japanese language for all users regardless of user preferences. Be sure you wish this behavior before setting this option.

View example (map-language.html)

The Maps Javascript API also supports Bi-directional (Bidi) text containing characters in both Left-to-Right (LTR) and Right-to-Left (RTL) languages natively. Examples of RTL languages include Arabic, Hebrew and Farsi. Generally, you should specify RTL language pages to render properly by adding dir='rtl' to the page's <html> element. The following example renders a map of Cairo, Egypt using Arabic controls:

View example (map-rtl.html)

See also the supported list of languages. Note that we often update supported languages so this list may not be exhaustive.

Region Localization:

The Maps API serves map tiles and biases application behavior, by default, using the country of the host domain from which the API is loaded (which is the USA for maps.google.com). If you wish to alter your application to serve different map tiles or bias the application (such as biasing geocoding results towards the region), you can override this default behavior by adding a region parameter to the <script> tag when including the Maps API javascript code.

The region parameter accepts Unicode region subtag identifiers which (generally) have a one-to-one mapping to country code Top-Level Domains (ccTLDs). Most Unicode region identifiers are identical to ISO 3166-1 codes, with some notable exceptions. For example, Great Britain's ccTLD is "uk" (corresponding to the domain .co.uk) while its region identifier is "GB."

For example, to use a Maps API application localized to the United Kingdom, add &region=GB to the <script> tag as shown below:

<script type="text/javascript" src="http://maps.google.com/maps/api/js?sensor=false&region=GB">

The following examples show two maps, one which geocodes "Toledo" based on the default region (US) to "Toledo, Ohio" and one which biases results based on a region set to ES (Spain) to "Toledo, Spain."

 

Asynchronously Loading the Javascript API:

Generally, you load the Javascript Maps API as soon as you load your page by including the API with a <script> tag and executing your application Javascript code after that script has loaded. However, while this Javascript is being parsed, your browser may not render additional content on the page. In most cases, this delay is not noticable, but you may wish to load the Maps API Javascript code after your page has finished loading. You may also wish to load the Maps API Javascript on demand

It is simple enough to load the Maps Javascript API after a page loads by injecting your own <script> tag in response to a window.onload event, but you need to additionally instruct the Maps Javascript API bootstrap to delay execution of your application code until the Maps Javascript API code is fully loaded. You may do so using the callback parameter. This parameter takes as an argument the function to execute upon completing loading the API.

The following code instructs the application to load the Maps API after the page has fully loaded (using window.onload) and write the Maps Javascript API into a <script> tag within the page. Additionally, we instruct the API to only execute the initialize() function after the API has fully loaded by passing callback=initialize to the Maps API bootstrap:

function initialize() {
  var myLatlng = new google.maps.LatLng(-34.397, 150.644);
  var myOptions = {
    zoom: 8,
    center: myLatlng,
    mapTypeId: google.maps.MapTypeId.ROADMAP
  }
  var map = new google.maps.Map(document.getElementById("map_canvas"), myOptions);
}
  
function loadScript() {
  var script = document.createElement("script");
  script.type = "text/javascript";
  script.src = "http://maps.google.com/maps/api/js?sensor=false&callback=initialize";
  document.body.appendChild(script);
}
  
window.onload = loadScript;

View example (map-simple-async.html)

Versioning:

The Google Maps API team will regularly update this Javascript API with new features, bug fixes, and performance improvements. All API changes will be backwards-compatible, ensuring that if you launch an application using the currently documented interfaces, that application will continue to work without modification as the API is updated. (Note: experimental features are not covered by this guarantee. Features that are experimental will be clearly labeled in the API documentation.)

Types of Versions:

You can indicate which version of the API to load within your application by specifying it using the v parameter of the Maps Javascript API bootstrap request. Two options are currently supported:

  • The nightly (development) version, specified with v=3 or by omitting the v parameter. This version reflects the current version based off the trunk, including any bug fixes and new features as they are publicly released.
  • A numbered version, indicated with v=3.number, which specifies a feature set of the API. These numbered versions may either be a release version or a frozen version. (See below.)

The following bootstrap request illustrates how to request a specific version of the Maps Javascript API:

http://maps.google.com/maps/api/js?v=3.1&sensor=true_or_false

Each quarter, we will cut a new numbered version (the "release version") and release it for public use. Throughout the quarter we will continue to add bug fixes to this release version, which will be noted within the Maps Javascript API changelog, while ensuring that the feature set remains stable.

When we release a new numbered version, we will "freeze" the previous release version, meaning that we will no longer update it with any code changes, including bug fixes, ensuring it is completely stable. Each time we introduce a new frozen version in this manner we will retire the existing frozen version. That is, at any given time there will be only one frozen version available. Applications requesting numbered versions that have been retired will automatically receive the current frozen version.

Choosing an API version:

The following guidelines apply when choosing the appropriate API version for your Maps API v3 application:

  • Production applications should always specify a minor version (eg. 3.1, 3.2, etc.).
  • The Maps API Premier SLA does not apply to the current nightly (development) version. Maps API Premier applications must use the current Release version, or an earlier version to be covered by the SLA.
  • When developing a new Maps API v3 application, we recommend that you select the latest Nightly version by it's version number (eg. 3.2), and then continue to use that version until such time as you need to add additional features only available in a later version. In this way the version you are using will mature as your application develops, moving to be the Release and then Frozen version over time.
  • Production applications that request a version equal to or older than the current Frozen version should be tested against the latest Release version once per quarter in order to identify any unidentified issues with backwards compatibility that need to be addressed in that version before it is frozen.

Documentation of Versions:

Documentation will always reflect the nightly (development) version. However, for each version, we will offer a separately maintained reference.