Ronan’s Blog

Google have today released a static Map API, for generating simple single image, non-interactive map images.

What are the benefits of this API?
To Google -> Decreased Bandwidth and processing, if static maps will suffice (for example a location map on a business webpage), then a single request on their data will be enough, rather than placing a map with panning & zooming capabilities on it.
To the User -> A single image map can be copied & pasted into e-mails & documents more easily for your average user, so that they don’t need an image editing tool.
So why do they feel this completely new API is required?
A slightly different operating mode (i.e. Single Image Mode) in the existing API with a simple set of instructions would surely be enough.
Google Static Maps API

We’ve been doing a huge amount of JavaScript-Centric Online spatial data editing recently and so any browser comparison that compares JavaScript performance is always of interest.

So, I saw this link yesterday and gave it a read, which was extremely interesting reading - It seems to indicate that Firefox 3 runs JavaScript ten times faster than IE7!
Firefox 3 Performance Gets a Boost
1) Firefox 3 Nightly (PGO Optimized): 7263.8ms
2) Firefox 3 Nightly (02/25/2008 build): 8219.4ms
3) Opera 9.5.9807 Beta: 10824.0ms
4) Firefox 3 Beta 3: 16080.6ms
5) Safari 3.0.4 Beta: 18012.6ms
6) Firefox 2.0.0.12: 29376.4ms
7) Internet Explorer 7: 72375.0ms

So, naturally after seeing this I downloaded a copy of Firefox 3 (Beta 3), but I downloaded the Portable Version so that I could run it without uninstalling Firefox 2. When I then ran it I was truly amazed at the performance of JavaScript. We have major intensive code for performing vertex editing and point snapping, which ran amazingly quickly on Firefox 3 and had no issues with scalability compared to Firefox 2. I’m looking forward to the official release now.

Today I read an Article about the use of Regular Expressions.
It could be boiled down to saying: “Regular Expression are cool & useful, but be careful and use sparingly“.
This made me wonder about Regular Expressions in my own code, and sure enough one popped to mind.
I wrote some regular expression code to anaylse String to see if they contain MAC Addresses in Java.
(Still useful code for those that have not yet moved to Java 6).

The difficult in recognising MAC addresses is that on different Operating Systems they are represented differently, with either a : or a - character in between each tuple or sometimes only having one HEX character in one or both of the first two tuples.

So, to avoiding writing complex code for each possible eventuality, this is the perfect opportunity to use Regular Expressions. At the core of this example is the following pattern:

Pattern macPattern = Pattern.compile( “(([0-9a-fA-F]){1,2}[-:]){5}([0-9a-fA-F]){1,2}” );

This pattern allows for 5 occurances of 1 or 2 HEX Characters followed by a : or - character then another occurance of 1 or 2 HEX Characters.

Once this is in place, the rest of the Java code is simply to read in the text containing the MAC address (either from file or via a Runtime Process) and look for instances of the MAC Address pattern in the line:
String[] macs = macPattern.split( theLine ); 

I find it extremely strange that the issue of JavaScript Memory leaks is not more widely addressed.
Frequently when looking at JavaScript libraries, even the big popular onces in some cases, I regularly come across these leaks. Now admittedly we may use JavaScript much more intensely than most others, as replacing a conventional desktop GIS tool, features geometry editing with all its bells and whistles requires a lot of processing, so maybe the code we are producing is highlighting these Memory leaks more than others normally would find.

Basically a Memory leak occurs when you access something from the document like so:
var sel = document.getElementById(”select”);
use the variable in some manner then return from the function.
Also, if sel is passed to another function then before that function has completed, ITS reference to sel must be also nullified.
To avoid the leak the sel variable needs to be set to null so that it gets removed.
I regularly use Drip to find such leaks and its a great bit of kit that anyone developing for the web should be using.

Its all a little bit annoying that these considerations need to be made when programming JavaScript, and most seem to largly ignore these memory Leaks; perhaps hoping that browsers will clean up after them. One other feature of JavaScript I’ve come across in the last week is the delete keyword, where variables can be deleted and not just their reference set to null. I’ve yet to experiemnt with this as it seems like its use could be a little dangerous.

Linked here ...  build.xml example

I’ve come across these startup parameters which really seem to speed up the performance of our servers. They only work in the latest versions (1.4.2_15 & 1.5.0_12). But they really make a noticeable difference.
-XX:MaxTenuringThreshold=8 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:-CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=40 -XX:+UseCMSInitiatingOccupancyOnly

Its probably a very bad sign that I laughed at the majority of these !

101 Ways To Know Your Software Project Is Doomed

At eSpatial we’re getting ready to release iSMART 5.3, one of the major new features is a completely revamped online spatial data editing capability. In the development team, we’re all pretty excited about its capabilities, because it like nothing we’ve seen before in a pure web (i.e. No Applet) mode.
Click the link below to get access to the early-access demo recording.
eSpatial _ next generation geospatial technology

I came across this hand bit of Java to allow you to parse XML while behind a restrictive firewall or without any internet connection at all. Previously, reading the DTD was causing java.net.UnknownHostException’s, the updated code stops the parser from trying to connect to the Internet to download the DTD.
DocumentBuilderFactory docBuilderFactory = DocumentBuilderFactory.newInstance();
DocumentBuilder docBuilder = docBuilderFactory.newDocumentBuilder();
//Here is the new code….
docBuilder.setEntityResolver( new EntityResolver() {
public InputSource resolveEntity(String publicId, String systemId)
throws SAXException, IOException {
return new InputSource(
new ByteArrayInputStream( ““.getBytes()));
}
} );

document = docBuilder.parse(xmlFile);

I’ve been watching with interested as a whole lot of people get excited about the new “My Maps” functionality in Google Maps. It looks quite impressive, but is really nothing new, well not to me anyway. We’ve been writing on-line digitizing functionality for a few years now adding more and more functionality with every release, the difference being that our product is a commercial one, which you will not find too many free-to-access public deployments of it which allows digitizing functionality.

Google Maps and our product have always had quite a different focus/market position and this is the first time that they’ve crossed paths (Ignoring the export to KMZ functionality I wrote last year). However, rather than starting to worry about another major competitor, I maintain the same position that I had when writing my Thesis (gCommerce - How GIS is facilitating modern business), that publicly available mapping solutions will just increase the usage of on-line maps and ultimately lead to generating more business as a whole for the industry.

I do feel a vague sense of jealously watching all the praise that I am reading for the “My Maps” functionality, but such is life I guess !

Google Maps: My Maps