This weekly report comes without relevant visible progress, but everything behind-the-scenes is always full of meaning as well.

As you can see in the screenshot (beyond other things like refactoring and documentation), I’m managing to build a provisional in-memory model of rules. This is because I can’t be in peace with myself before all the base “behind-the-scenes” work is made . In this case, when loading the rule file, I’m loading almost all rules (full support will come during time). When a CSS class is selected (in the screenshot, the aerialway-line class), a function will search all the models, returning all rules that have that CSS class associated.

In the screenshot you can see the provisional models of the following rules, that are in “osm-map-features-z17.xml” and have aerialway-line class associated:

<rule e="way" k="piste:lift" v="t-bar|j-bar|platter">
	<line class="aerialway-line piste-lift-t-bar-marker"/>
	<line smart-linecap="no" class='aerialway-struts'/>
</rule>

This is the first one: you can see in the screenshot that the “v” attribute is correctly parsed in the “values” property of the first javascript object. The class attribute isn’t splitted at the moment, because it’s splitted during searching. You can also notice that “smart-linecap” it’s not parsed at the moment. Obviously, this will change in the near future. This is the real meaning of “full support will come during time”

The other rule successfully matched is the following:

<rule e="way" k="aerialway" v="cable_car">
	<line class="aerialway-line aerialway-cablecar-marker"/>
</rule>

As you can see this is correctly parsed in the model.

In the meantime, during the week I’ve talked with my mentor, Frederik, about beginning to release some source code, so I’ve got a SVN account from TomH (thank you!). I plan to release something in the next days. More on that later.