May 27, 2008

The least exciting screenshot ever :)

Posted in GSoC tagged , , , , , , , , at 3:23 am by fadinlight

Yes, I know… this is not what is expected to be a great “first day working” post, especially when talking about the great Google Summer of Code. But most of the time, what can be seen can play tricks on us. This is what I achieved today:

Not really astonishing, huh? 🙂 Let’s see what’s behind that javascript alert.

Why?

Following my purpose of having a Object representation of Osmarender’s rules and/or css classes (to better manage and pointing to them in my code), I should make a relation that involves, for example, a rule with the features (key/value pairs) involved. Furthermore, I should be sure that a rule can be applied to the matching feature (for example “circle” can be applied only to nodes). Not enough, a feature can be applied to more than one type (for example, “highway=pedestrian” can be applied to ways and areas as well). So a model representation of standard features must be considered.

As you can see, in the alert is printed a linearized version of a tree. You can see “macrocategory”,”category”, and “key”,”value”. To improve the usability of the GUI, and to encourage templating for newbie users in the future, I’ve thought about giving a faceted approach on map features classification. What can’t be seen from this printing, is that all the features listed are in a single facet (which I called “wiki”), but multiple facets are allowed within the code. This was not a major overhead of coding time beside the original purpose of modeling key/value pairs, but can lead to a great end user usability feature when dealing with the GUI.

What?

To achieve this goal, many Javascript tricks are involved, for example protecting the code itself to external overwriting. If I have a Javascript object to represent element types (node, way, area), I should be sure that the integer that represents internally those elements (and can be called, for example with a simple “elements.WAY”) will be not overwritten. This is not so simple to achieve in Javascript, because all objects can be overwritten at any time. I’m not sure this is the right way to go (but I’m sure is prone to bugs at the moment, for example a double check for arguments is needed), because I couldn’t test it so much (I’ll dig the Net for common patterns, if any), but it’s an handy solution at the moment, even if home-made. A simple example of Javascript function overloading is shown as well.

var elementTypes = function() {
	// if the object that calls the function is not already an instance return a new object. This example provide a rough overloading implementation of object constructors
	if (!(this instanceof arguments.callee)) {
		// if the function is not called with an argument (e.g. elements.WAY) then only a reference to the internal representation is wanted
		if (arguments.length==0) return new elementTypes();
		if (arguments.length == 1) {
			// if the function is called with an argument, which is an array of types (e.g. [elements.WAY,elements.NODE]), then an object that should be included in a Feature object is wanted. The object returned will call itself the section "if (arguments.length==1)" below
			if (!(arguments[0] instanceof Array)) throw new Error("not an array");
			return new elementTypes(arguments[0]);
		}
	}

	// Public variables that references names of functions that returns the integers
	this.WAY = "_WAY";
	this.NODE = "_NODE";
	this.AREA = "_AREA";

	// Private variable that will store the types compatible with the feature
	var _mytype=null;

	// Private functions that returns the integer that represent a type
	var _NODE = function() {
		return 0;
	}
	var _WAY = function() {
		return 1;
	}
	var _AREA = function() {
		return 2;
	}

	// If this is an object that should be included in a feature
	if (arguments.length==1) {
		// Unnullify the _mytype private variable, it will be an array of types (for example highway=pedestrian can be applied to ways and areas as well)
		_mytype=new Array();
		// Iterate the array passed as the argument of the function
		for (type_defined in arguments[0]) {
			// Create a new object in the array
			_mytype[_mytype.length] = {
				// Assign the value of the object. This is achieved by eval() the type in the argument and adding "()" to call the desired function
				value: eval(arguments[0][type_defined] + "()"),
				// Create a value that remember the type requested
				toString: arguments[0][type_defined]
			}
		}
	}

	// This is a public function that returns the types associated to the feature
	this.getTypes = function() {
		//returning a clone object to avoid accidental overwriting
		return clone(_mytype);
	}
}

Beside any further testing, even if it’s easy to use, I don’t like the fact that I should call the function one time to retrieve the constants I want, and then apply the function to a public variable of that instance to achieve the goal. Perhaps, in the future, if I won’t have the time to search a better solution, I can hide this calling in the library in some way.

var elements = elementTypes();
var typeToIncludeInAFeature = elementTypes([elements.WAY,elements.NODE]);

How?

The most interesting part of my community bonding period, beside happy talking with my mentor, Frederik, and OSM community in the irc channel and/or in the italian community and/or with Dieterdreist, was to explore and dig further in Javascript. As stated in the MDC, Javascript is the world’s most misunderstood programming language. And this is surprising what Javascript can do with its functional programming support. Studying more of it, let me realize that all that I’ve learnt and practised about object oriented programming (including design techniques, UML, etc.), even if greatly useful most of the time, was a lightly incomplete view of the world, and sometimes ineffectual for the scope of the project.

At this time, I’ve learnt a lot about Javascript programming and patterns, but I can’t say I achieved the right confidence to do a graceful design. Even if I’m traditionally a light supporter of BDUF development (“light” because I’m always open to intelligent compromises), I think that I would stay with some Agile influences. Furthermore, I would like to lower the technologies involved, thus embracing a little of KISS: I’ve seen that Dojo has lot of commodities for object orientation and such, but what about people who wants to extend my code in the future? They should learn my code, Dojo internals, Sarissa, etc… not so much inviting.

May 22, 2008

Meeting Dieterdreist, meeting end users

Posted in GSoC tagged , , , at 11:29 pm by fadinlight

This afternoon I’ve met Dieterdreist (and his great mapping bike ;)) to discuss about OSM in general, the state of Rome’s map and another little brainstorming about my project’s usability.

After a drink in a bar under the heavy rain, we used some bar’s towels to draw some mockups about the project’s GUI interface. We had also talked a bit about the object model behind all the functionalities, that should meet Osmarender’s great ruling managing, giving a simple and beautiful interface to end users.

He was agree about my idea on faceting OSM features and gave me also a hint about letting end users manage all zoom levels colors with the same interface at the same time, with cool features to reduce the effort and time the end user would spend in the setup.

More on that later…!