Introduction

This is the second post made regarding the Google Summer of Code 2019 progress. The first month is coming to an end and with it, the first 2 tasks as well. In this entry I will present what is new and what has changed, in regards to the first task as well as the work and decisions made on the second one. Exported images of demo renderings are also included at the bottom of this entry. You can see all the changes mentioned below in the pull request here
So, let’s begin:

Minor noteworthy changes on the 1st task

If you happened to follow my previous diary entry as well you may have noticed that it was mentioned that “Depending on their importance, I may include a brief of them in the next diary post”, referring to additional changes. Major ones are presented in the next paragraph below but I chose to also include the ones listed here; although they may not directly affect the flow/functionality of the program they still do play their role.
What is new:

• Javadoc is created in important parts of the code such as the configureMaterial() method in TrafficSignModule and the File field in both TextTextureData (TTD) and ImageTextureData. The later Javadoc addition is to demonstrate the major differences these fields have despite their overall similarity.
• Getter functions have been removed from TTD and its fields have been made public, following the concept of its parent superclass TextureData.
• "osm2world" is now appended to every prefix of a temporary image created in TTD getFile() method as a way to help users understand where those new files in their systems came from
• Last but not least, the hashCode() and equals() methods are now only defined in the TTD and ImageTextureData child classes instead of the TextureData parent one. Prior to that, an ImageTextureData object could be deemed equal to a TextureData one, as they used to bear the same fields, which should obviously not happen.

Major changes on the 1st task

• TextTextureData now accepts all super-class fields as constructor parameters. That also inevitably meant that all those fields should be made configurable for the TTD objects via the configuration file. Thus, support for this is also implemented in Materials.java configureMaterials() method

• Sticking to Materials.java configureMaterials(Config) method, this has also been restructured and had its flow altered, to improve readability and to avoid code duplication. That essential means 2 things

  1. The Wrap style parsing as well as the TexCoordFunction parsing are now methods as they are necessary for both types of texture layers.
  2. The “image” type is now used as the default type for a layer, by adding a
     String type = config.getString(typeKey, "image"); line

Based on that, the current flow is as presented below:

if ("text".equals(type)) {
        ...
        textureDataList.add(textTextureData);
} else if ("image".equals(type)) {
        ...
        textureDataList.add(imageTextureData);
} else {
        System.err.println("unknown type value: " + type);
}

• Temporary created images are no longer stored in /textures folder due to the fact that, in the case of application-crashing, these files would “stick around” until manually deleted. By using createTempFile(String, String) without a directory parameter, the files are stored in the default temporary-file directory of the OS (/tmp for Ubuntu). Upon restart/shutdown the contents of this folder are deleted so problem solved!

• POVRay target also ignores TTD layers. That is achieved by placing rather simple if layer instanceof TTD clauses in necessary parts of the code, being guided by the errors that occurred before that. As of now, for both obj and povray exports, if a TTD is present “above” and image layer, only the image layer will be rendered

Human-readable traffic sign values

For this task, the most important part is that of Add a configuration option of which country’s style of sign to assume, as same signs have different representations in different countries, as defined in the GSoC application document. The way that was going to be implemented was by defining configuration files for different countries (e.g. greece_config.properties) that would include entries that defined that style (and more). That was then going to be loaded together with the main configuration file without requiring any action by the user. So, to achieve that, classes that parse the configuration file needed to be altered. That was initiated with a change on OSM2World.java, which also holds the main class, by adding:

String locale = fileConfig.getString(localeKey);

if(locale != null) {
	String localeFileName = locale+"_config.properties";
	File localeProperties = new File(localeFileName);
	if(localeProperties.exists()) {
		fileConfig.append(new PropertiesConfiguration(localeFileName));
	}else {
		System.out.println(locale+"_config.properties file does not exist or it is not"
		+ "in the same directory as "+configFile.getName()+". Nothing happens");
	}
}

where localeKey stands for the name of the country defined in the main configuration file. But before going any further with altering other such classes (e.g. ReloadOSMAction.java), by digging further into the Java PropertiesConfiguration documentation it was found that this functionality is already implemented by default. What one has to do is add a line like include = pathToTheCountryConfigurationFile in the main .properties file and voila! Given that, it was then decided that no further action was necessary and a localization option as a command line argument is likely to be later implemented.

Png output of current results

The following renderings are created just by mapping the signs. An entry like <tag k='traffic_sign' v='DE:274-30' /> would create the sign in the first image and <tag k='traffic_sign' v='DE:274-50,1001-31[5]' /> would result to the sing in the second one.

GSoC Application document

https://github.com/JayGhb/GSoC-2019-Application

Coming up: SVG texture support