Although I am drawing your attention to it now, it should be noted that this is still somewhat under development!

Anatomy of a geocoder

To begin geocoding your data you will need a geocoder. This is not something that Elgg comes installed with by default, although here’s one I coded earlier.

This geocoder users the Google maps API to do the actual encoding, and provides two primary features.

• It handles the plugin hook “geocode”,”location”
• It listens to all create events and attempts to tag it with the latitude and longitude – either from a ->location metadata on the object itself, or from the user’s current ->location – you could get more creative, this is a simple example.

When you attempt to geocode a location you call the function elgg_geocode_location(). This in turn triggers the above plugin hook and attempts to encode the data.

For efficiency once a location has been geocoded the result is cached. Future attempts to code the same location will return the result from the cache.

Once installed and configured, new content (wire posts etc) will be tagged with a latitude and longitude. Fill in your profile location field and try it out for yourself!

Location based searches

Once things are tagged with a location, you can start to use location as a starting point for searching by using some of the location aware search functions in location.php.

This hasn’t currently been hooked up to the Elgg interface in any way, but that doesn’t stop you making use of it in your plugins.

GeoRSS

This is something you’ll be pleased to know that you get for free!

As you list your entities using the Elgg listing tools using the RSS view, if an entity has a position defined it will be included using standard geoRSS simple notation, i.e:

<georss:point> 45.256 -71.92 </georss:point>

Happy coding!

In a nutshell, Elgg 1′s object model is a simplification of what we’ve done with Elgg 0.x (from now on called Elgg classic), reducing things to their essential components.

In Elgg 1 you have at the highest level three things:

• Entities: Things in the system; users, blog posts, etc…
• Metadata: Information about an Entity (called Extenders in Elgg 1).
• Relationships: Define how one object is related to another.

Conceptually this is very clean but also very flexible. Because entities, relationships and metadata have a consistent interface we can do some very cute things.

One thing in particular – arbitrary mixed type feeds – which were pretty much impossible in Elgg classic now become very easy indeed.

Don’t know what I mean? Well, suppose you were looking for Blog posts tagged with “Firefly”, in Elgg classic you could have these listed out in a feed.

Fine.

But suppose you wanted to show videos or music tagged with “Firefly” on the same page? What if you want to write a plugin that displays flash games or store files on S3 and want them to show up in the same stream?

All very easy now. Cute eh?

The above is a rather simplistic example of what is possible. I have hinted at some other applications a few posts back…