Rails and geo plugins

After looking into Cartographer and YM4R I started searching for other geo tools for Ruby.

I found several and started creating a list. My idea was to make a comparison between the features of the different plugins. But I soon found out James Stewart did this already in his Comparing rails geo-plugins post. He moved the information to a wiki, on which the most recent information about the different Geo plugins can be found. On this page you’ll also find some great reviews of the different plugins.

I started looking into GeoKit, acts_as_geocodable and actsaslocateable. The last one isn’t suitable for my application, because it can only deal with US addresses. That’s also true for some of the geocoding services the other two support. The only one1 with support for Dutch addresses is the Google geocoding service, so sadly no fall back mechanism for Dutch addresses when one geocoding service isn’t available.

There are a few differences between the remaining two plugins.

acts_as_geocodable makes use of a gem called Graticule. This gem takes care of the actual geocoding, communicating with external services, etc. The acts_as_geocodable plugin takes care of the Rails specific stuff (extra find methods, etc).

GeoKit has all the functionality in the plugin, but Bill Eisenhauer, one of the authors, said “there’s no reason why this needs to be packaged entirely as a plugin”. So maybe this will change one day.

Another important difference is the way the two plugins store the geocoded information. GeoKit can handle existing models with longitude and latitude columns. You can specify the names of the columns with the column_name parameters (the defaults are ‘lat’ and ‘lng’).

The acts_as_geocodable plugin creates two new tables. The first is called geocodes and stores the longitude and latitude for a given address. The second table links the geocodes into your model in a polymorphic way.

Both plugins als have a feature the other plugin doesn’t have (as far as I can tell).

acts_as_geocodable can update the address fields with the data returned from the geocoding service, just add acts_as_geocodable :normalize_address => true to your model.

GeoKit has the ability to look up a location based on the user’s IP-address.

Which of the two is better? I don’t know. They almost have the same feature set, GeoKit does IP-based location lookups, while acts_as_geocodable separates its functionality between the plugin and the gem and has the ability to normalise addresses.

I think it’s a matter of taste, which one to choose. Or is there any difference in performance? I guess I have to test this.

For now, I think I’ll start with GeoKit for my application. I really like the ability to keep my own models with the longitudes and latitudes.

1 Maybe someday I’ll write a post about addresses and zip codes in The Netherlands and why the aren’t available for free.

Book: “Beginning Google Maps Applications with Rails and Ajax”

Previous post I mentioned a new book about Google Maps and Rails: Beginning Google Maps Applications with Rails and Ajax.

I haven’t read the book, but I’ve download chapter 7 and I think it’s an awesome book. A recommendation for everybody who’s building Google Maps Mashups with Rails.

You can even get it for free. There’s a contest where you can win a copy of the book, they are giving away 3 free copies. They call it a ‘contest’, but all you have to do is leave your name and email address. You have to hurry, because they’ll randomly draw three entries on March 15th, 2007 (deadline is midnight March 14th EDT).

If you haven’t won a copy on the 15th, you could always order a hard-copy (also available as an ebook)

All the examples of the book can be viewed online and the sourcecode can be downloaded.

Google Maps and Ruby on Rails

For a new project I’m working on, I will make extensive use of Google Maps. At this moment I’m doing some research to find out what the best practices are to use Google Maps in Rails applications. I also want to find out what tools there are.

The first projects I ran into are the tools which simplify the creation of a map: Cartographer and YM4R. These two projects give the user a Ruby based approach for building maps. According to Andre Lewis in his Google Talk about Ruby and Google Maps you’ll run into the limitations of these projects very soon if you’re building complex applications. Andre is one of the writers of the new book about Google Maps and Rails, called “Beginning Google Maps Applications with Rails and Ajax: From Novice to Professional”.

These tools can be very useful if you want to build a Google Maps application fast or if you don’t want to make your hands dirty on the Javascript (or maybe you just don’t have the knowledge).

The application I’m building will be rather complex and I don’t mind programming in Javascript. So I’m not going to make use of this kind of tools. The next category of tools you can use in building maps, are the geocoding tools. These will be the subject of a future post.

B.t.w. It looks like the cartographer project is dead, so if you want to use this way of building maps, there’s only one solution left, YM4R.

About this blog (4): English or Dutch

This is the fourth post in the ‘about this blog’ series and is a follow up of the previous one about decisions. It’s about the decisions whether to write in English or Dutch.

As you may have noticed, the main language on this website is Dutch, while I’m writing this blog in English. Why not stick to one language for everything? Or translate the site as a whole?

First of all, I’m Dutch, so my native language is Dutch. Because of this writing in Dutch is more easily for me than writing in English. There are a few reasons why I chose to write this blog in English:

  • To improve my English writing skills. I’m using English a lot for communicating with others. When I’m writing an email, sometimes I can’t find the words to express myself. By writing in English on this blog, I hope it’ll be more easily for me to express myself and not to make stupid mistakes we Dutch sometimes make.
  • I hope sometimes I have something to write about that’s interesting for a broader audience than only the Dutch-speaking.

The main reason why only the blog is written in English is that most of my customers are Dutch and I didn’t have time to translate everything. Maybe someday I’ll have a complete bilingual website.

I won’t say I’ll never write in Dutch on this blog, because I can imagine that sometimes I want to write about something that’s only interesting for Dutch speaking. But I’ll have to find out what the best way will be to do this.

About this blog (3): Decisions

This is the third post in the ‘about this blog’ series: Decisions.

Before starting this blog I had to make a few decisions. Some of them were easy to make, others were not so easy to make.

The first decision was which blogging sofware to use. I already wrote about this one in the first post of this series: About this blog (1): Custom Made

During the development of the blogging software I ran into a rather difficult decision: what kind of URL schema am I going to use? There’s been written a lot about this subject, so I started reading.

One of the most important things about URL design is to keep URLs simple and human readable. If these two are true for your URLs a search engine won’t have problems crawling your blog.

I started looking at other blogs and noticed there are many different ways to design an url. Here are a few (random) examples:









Because I’m using Ruby on Rails the last example would be the easiest to build. But I like /yyyy/mm/title-without-spaces better.

Does it really matter which one you choose? I don’t think so. All of the above URLs are SEO friendly. Some people argue you should not add dates to your URLs, while others think it’s good for your permalink structure to do so.

I decided to use dates in my weblog URLs although it’s slightly more complex to implement with my Restful weblog controller. I did it because I like the resulting structure of URLs which can be used as an archive: ”/weblog/2007/” gives all posts from 2007, ”/weblog/2007/01/” gives all posts from january 2007, etc. I left the day out of the URL, because I don’t think it’s very useful (I’m not planning on writing tens of posts every day).

Next decision was more easy to decide: Use full or partial text feeds. It was more easy, because I personally like reading blogs which use full text feeds, so I’m using a full text feed.

The final decision was a difficult one: which language to use, english or dutch. This will be the subject of the next post in this series.

Google Coop

Today I’ve been experimenting with Google Coop. It’s very easy to create your own custom search engine and add it to your website. You can take a look at my experiments (sorry only dutch).

I can think of many situations where Google Coop can be handy. For example:

  • Only add sites to the searchlist which you think are trustworthy about the subject
  • Add sites which are interesting for the community of your website. You could even allow others to add sites to the searchengine. This way you can build it together.
  • Create a local searchengine by only adding websites about a certain location (e.g. only sites you know about Amsterdam)

The resulting searchengine can also be added to your personalized Google Homepage.

Google Maps API feature request

Through this article at the geonames blog I found the ‘API Feature Requests’ page.

This page lists feature requests for the Google Maps API. If you like a feature and it’s already listed, you can write your name next to it to. If it’s not listed you can append it to the list.

There are a few very interesting feature requests.

‘Compatibility with other map APIs’. This is the feature request the article at the Geonames weblog talks about. Indeed it would be very nice if there’s a common API which is shared between all the Map vendors. There can be different reasons why you want to switch between different maps, eg the license changes, the area your application is about is covered better in a different map, etc. One problem I can think of with this approach is the that the feature set is not the same for every Map. So this common API can only cover the basics, but maybe that’s enough?

If you want a common API right away you have to take a look at projects like myMap, or Mapstraction. These projects are adding an extra layer on top of the major Map APIs from Google, Microsoft and Yahoo. You could also use the Open Layers API which also supports the APIs of these vendors.

Another nice feature request is ‘Ability to restrict geocoder to a particular region, country’. If this would be possible and your application is about a specific region you even could create an auto completion search on addresses.

If you’re using the Google Maps API a lot, take a look at the list and add your name or feature request to it.

About this blog (2): Status

This is the second post in a series I’m writing about this blog, a sort of “The making of….”. This time the status of this blog.

The main thing I can say about the status of this blog is “It works!”.

When building this blog I used the some of the guidelines from the great book Getting Real by 37signals:

  • “Build half a product, not a half-ass product”: This blog’s main purpose is to help me to write. That’s why I started with building the Posts functionality, not with the comments, tagging, etc. These can be added later on (tagging is already implemented).
  • “Don’t wast time on problems you don’t have”: At the moment I started writing this blog, all the posts fitted on one page (and they still do). So why worry about pagination and creating next/previous links? That’s something I have to take care of before the list of posts grows too big to fit on one page.

At this moment a part of this website is still static, e.g. the homepage. After I’ve written a new blog entry I have to manually add it to the homepage (a list of the three latest posts is shown on the homepage). Is this a problem? No! Would it be nice to have the three latests posts show up on the homepage automatically? Absolutely!

Another example, there’s no automatic ping build in right now. After a post has been added I go to the Technorati website and press the ping button. Is this a problem? No! Would it be nice if the blogging software did this automatically? Absolutely!

Because of the things I have to do manually it takes a little more time to publish an entry, but it’s not impossible.

My css is not complete, not every Textile markup element has a customized style. I just use them and when something isn’t displayed the way I want it to, I’ll add it to the css.

In the near future I’m planning to add the following features:

  2. Pagination
  3. Ping
  4. Trackback
  5. Everything else I come up with

“Start with what you really need and add everything else later”, that’s something I’m planning on doing in my other projects also.

About this blog (1): Custom Made

In my first post I promised to write some more about this blog and how I created it. I’m going to write a few posts about this subject, so let’s start with the first one: Why I use custom made blogging software.

Before creating my own blogging software I looked at a lot of out-of-the-box products or blogging platforms (why reinventing the wheel?).

Because I’m on a journey from Java development to Ruby on Rails development I specially looked at the Rails based blogging software, like Typo, Mephisto and SimpleLog. There are a few reasons why I decided to build my own blog from scratch:

  1. I wanted a simple blogging app. Not one with which I could maintain my complete website. Just use it for the weblog and integrate it into the website (which is also a Ruby on Rails app). This must be possible with the three programs I looked into, but all the tutorials and howto’s I found were based on building a standalone weblog.
  2. For another project I’m working on I needed the possibility to create a lot of (small) weblogs. In Mephisto it’s possible to create multiple pages which behave like a weblog, but I needed a weblog which is related to a user.
  3. I’m not that experienced with Ruby on Rails and building your own blogging app seems to be a good start 😉

Next time I’ll tell some more about the status of the software and what still needs to be done.

Google geo developer day

Yesterday I got a phone call from Google. The lady on the phone said Google is organizing a Geo developer day in Amsterdam somewhere in march. She asked me to whom she could address the invitation.

After the call I realized I didn’t ask for the precise date, so I guess I have to wait for the invitation. I can’t find any information about this developers day on the web.

The lady said she got my phone number from this website. Probably the Stemlocaties Amsterdam page (Google Maps mashup with all vote locations for the Dutch General Elections) got their attention somehow 🙂

update 1: Today (March 1) I got the invitation, so now I know the date :-). The program looks very interesting, so Google count me in!

update 2: Read my report about the GeoDay