Blog - MapMyGlobe

One year ago, the Google Maps API development team released a small but pretty neat improvement to their Geocoding API: the ability to get the response’s accuracy level for a given address.

This feature enables applications to modify their zoom level according to the precision of the address that’s being geocoded, for example, “Paris” at the city zoom level, but “1 rue Royale, 75008 Paris” at the much more precise street address zoom level.

What the Google geocoder actually outputs (see reference) is a value between 1 and 8. And the GMaps zoom level is an integer between 1 and 19. So the question is: given a geocoding accuracy, which zoom level should I use to display the place? I didn’t find any answer to that question on the web so I decided to make up my own correspondence between the two scales. Any such correspondence is bound to be imperfect since two different cities can have very different sizes, however the method usually outputs a decent result.

var tabAccuracy = new Array(2,4,6,10,12,13,16,16,17);

function showAddress(address) {
  if (geocoder) {
    geocoder.getLocations(address,
    function(response) {
      if(response.Status.code!=200){
        alert('"' + address + '" not found');
      } else {
        place = response.Placemark[0];
        accuracy = place.AddressDetails.Accuracy;
        map.setCenter(new GLatLng(place.Point.coordinates[1],
             place.Point.coordinates[0]), tabAccuracy[accuracy]);
      }
    }
    );
  }
}

I calibrated the association on a few cities such as Paris, NYC and San Francisco, and I was a bit conservative to ensure that people with small screens still get the picture. Let me know if you find this scale useful.

Just a short post today to introduce the blog’s new header design. The Google Maps screenshots are a reference to the importance of the GMaps API in my web application, mapmyglobe.com. Right now the banner rotates between 4 different locations, which are important to me, because they are the places where this web app will have been conceived and built

But then I found out that the blog’s title and catchphrase were very difficult to read. Unfortunately CSS implementation still lacks text-stroke (text displayed on a white surrounding that makes it easier to read, like the text on the GMaps layers). So I’ve put together a quick javascript-and-CSS hack to have any text element that I want being displayed with a stroke. In my case I am stroking the blog’s title and tagline. This hack perfectly exemplifies DOM manipulation’s power, which is what I wrote about last time, so I thought I would write something about it. I’ve made it available right here: Text Stroke effect with Javascript and CSS.

Other than that, the project is moving along nicely, with some major refactoring going on right now… More on that later on.

Today I figured I would write about how I feel about the whole AJAX-y techniques set.

AJAX stuff is great and I use it a lot throughout the application I’m building right now, mapmyglobe.com. A lot has been written about it and I won’t repeat it all. The ability to asynchronously (first A) exchange small pieces of data between client and server without the need for reloading the whole page is great, and so is the seamless integration of XML (X) in lots of scripting languages, calling for spending time on the data processing rather than on the data transport and parsing, and thus providing an abstraction layer for data management (actually in web apps XML is often replaced by smaller-overhead syntaxes like JSON, but the concept is the same). And the whole Javascript (J) function stack provides a powerful framework for client-side, in-browser, interaction and processing.

But what I really feel strongly about, and which does not come to mind first when you talk about AJAX, is the DOM scripting. DOM (Document Object Model) scripting is the ability to dynamically modify the page’s html code, through Javascript functions. As such, DOM scripting is the root of the paradigm shift in web development: from the web being a set of documents being dynamically produced and served to the user, it’s now become a place where you can find real applications that react to the user’s actions, not the browser’s.

My main point is that DOM modification calls for bridging the gap between Flash, desktop widget applications or other multimedia formats that are visually impressive but poor for actual Internet-centered stuff such as user-generated content or search engine integration, and semantic, text-based media that’s great for machine readability but often lack the design assets and appeal. “AJAX”-y javascript effects tend to bridge both worlds and bring together semantic content and animation. We could just integrate user-generated text with fancy javascript effects, but that’s not what I aim at. What I want to do is enable user-generated animation. That’s what’s going to be really innovative. Stay tuned for it.

I just bought the domain name mapmyblog.com this morning. I have been thinking about building a Collaborative Mapping web app for some time now and I finally made up my mind last week and decided that it was time to go for it.

I won’t tell much about it today, I’ll just say that it will combine Google Maps and a wiki system, however in a way that will be totally different from what WikiMapia does, and that I’m feeling really enthusiastic about it.

Enough said about the app for today. What I also wanted to share with you today is my feedback on the domain registration / web hosting process. I have built several websites over the last couple of years, both in France and here in the U.S. It strikes me that although entry-level hosting here in the U.S. tends to be more expensive than in France, the configurations are a lot more powerful and it is so much easier and quicker to have them set up and running. While it used to take about a week to have a working host, database, DNS and subdomains a year ago in France, it took me only a few hours this morning to have everything up, so I don’t know what the causes are (given that I don’t know a lot about registration processes and DNS stuff) but it’s definitely worth spending a couple of extra bucks in order to save time to actually build a web application

Enough said for today. I am looking forward to being able to release a beta version and hope to do it some time around mid-September. I certainly hope you’ll like this project as much as I do.

Cheers,

Julien