The technical side of the blog is a project for me that allows me to experiment with different technology – it uses ASP.NET, C#, JavaScript, JSON (for cross domain scripting), Google Earth/Maps/Fusion Tables/Analytics. There is some Silver Light and Flex/Flash, but HTML/JavaScript works across a wider range of browsers.
Blog: I chose Google Blogger because it is very widely used, I don’t need to host it myself and I can customise it greatly. If I was prepared to host it myself and deal with the upgrades, there are a lot of good choices out there depending on your language preference (Joomla, wordpress.org, umbraco.org etc). If you are looking to use an existing hosted one, wordpress.com looks very professional from the start, TravelPod has some basic built in mapping facilities, but none allow customisation. We use Live Writer to compose the blog as it allows offline use and HTML editing.
Maps: The points of interest were plotted in Google Earth and the route saved as a KML file to be plotted on the blog using Google Maps API. The actual route is recorded on a Garmin GPSMAP 62S which by default records the route as a GPX file. This is uploaded into an online database, the number of points reduced using the Douglas Peucker algorithm and then synchronised with a Google Fusion Table for plotting the line on the map. Tracks4Africa is the best source of POI, roads and directions – their maps are great too.
Images: There are plenty of great sites out there for hosting pictures. Flickr appears to be the most professional, Picassa Web the easiest to use and best integration with the Picassa desktop application and Facebook has the obvious social feedback. I chose to host them myself as it gives me the most control over the size and quality (I can upgrade to full resolution in the future) and it provides me with a backup where policies can’t be changed without my permission. If I had time to automate something, I may have chosen to use Facebook as a second copy for the feedback and comments.
Charts: The charts use the Google Charts API – the REST version rather than the more powerful javascript version because they are faster with slow internet.
Offline: All components can be worked on offline and synchronised when we find internet – data is stored in an Access DB (quick and easy to modify) and synced (communication with server uses a modified version of Rijndael Encryption) with SQL Server online or Fusion Tables. I expect some major changes in mobile internet / roaming charges in the future will greatly simplify this.
Backups: I have a master copy of the photos and 2 backups. You can never have enough and they should preferably be in different locations.
Blog: I chose Google Blogger because it is very widely used, I don’t need to host it myself and I can customise it greatly. If I was prepared to host it myself and deal with the upgrades, there are a lot of good choices out there depending on your language preference (Joomla, wordpress.org, umbraco.org etc). If you are looking to use an existing hosted one, wordpress.com looks very professional from the start, TravelPod has some basic built in mapping facilities, but none allow customisation. We use Live Writer to compose the blog as it allows offline use and HTML editing.
Maps: The points of interest were plotted in Google Earth and the route saved as a KML file to be plotted on the blog using Google Maps API. The actual route is recorded on a Garmin GPSMAP 62S which by default records the route as a GPX file. This is uploaded into an online database, the number of points reduced using the Douglas Peucker algorithm and then synchronised with a Google Fusion Table for plotting the line on the map. Tracks4Africa is the best source of POI, roads and directions – their maps are great too.
Images: There are plenty of great sites out there for hosting pictures. Flickr appears to be the most professional, Picassa Web the easiest to use and best integration with the Picassa desktop application and Facebook has the obvious social feedback. I chose to host them myself as it gives me the most control over the size and quality (I can upgrade to full resolution in the future) and it provides me with a backup where policies can’t be changed without my permission. If I had time to automate something, I may have chosen to use Facebook as a second copy for the feedback and comments.
Charts: The charts use the Google Charts API – the REST version rather than the more powerful javascript version because they are faster with slow internet.
Offline: All components can be worked on offline and synchronised when we find internet – data is stored in an Access DB (quick and easy to modify) and synced (communication with server uses a modified version of Rijndael Encryption) with SQL Server online or Fusion Tables. I expect some major changes in mobile internet / roaming charges in the future will greatly simplify this.
Backups: I have a master copy of the photos and 2 backups. You can never have enough and they should preferably be in different locations.
No comments:
Post a Comment
Note: only a member of this blog may post a comment.