OpenStreetMap

GSoC 2019 - Traffic sign Catalogues - OSM2World

Posted by JasonManoloudis on 1 August 2019 in English (English)

Introduction

The completion of the Traffic sign catalogues task brings a long-desirable feature in OSM2World: being able to define and configure materials solely through the configuration file, without the need for them to exist in Materials.java!
During this main feature’s implementation, the Human Readable Traffic sign Values task also came to a more complete state by adding lines of code related to it, while progressing, to cover needs that came up.
This entry will be split into 3 parts, separately covering Human Readable (H-R) values-related additions to avoid possible confusion. It is worth mentioning that there are of course more changes than the ones explained here but as changes are being constantly made it would be practically impossible to include every detail that has changed since the last diary entry. Plus, it would turn out to be boring for the readers.
That being said, sample sign images with the material definitions/configurations that create them included can be found by the end of this entry!
Let’s get started:

I will try to keep things short and briefly present only the most important points as this is not the main focus of this entry:

  • A clear distinction between H-R values and non H-R values is now taking place in TrafficSignModule.java. Its simple implementation may seem obvious at first but it had to be validated by looking through a lot of Overpass data with a query like

[out:csv(traffic_sign;false)];
nwr[“traffic_sign”][traffic_sign~”:”]({{bbox}});
out;

that looks for traffic sign values that include “ : “ in their name i.e. are country prefix - sign ID pairs like DE:267 . Using that, one can see that there were no cases where a sign contained both a country-prefixed value and a human-readable one together (e.g. v=’DE:254, maxheight’ ) so the code below was deemed to be the way to go:


if(tagValue.contains(":")) { //if country prefix is used
    String[] countryAndSigns = tagValue.split(":", 2);
    if(countryAndSigns.length !=2) return;
    country = countryAndSigns[0];
    signs = countryAndSigns[1].split("[;,]");

    } else { //human-readable value

   signs = tagValue.split("[;,]");
   }

  • The trafficSign_signName_material = * property is now supported The above property will map a H-R sign name to its corresponding material definition for the specified country. Properties like that will be loaded into a separate configuration file, unique for every traffic sign catalogue, which will be loaded together with the catalogue & the main configuration file. These 3 lines (in the main config file) are enough to produce this result for the catalogue of Germany:
locale = Germany

include = ${locale}TrafficSignCatalogue.properties
include = ${locale}HumanReadableSigns.properties

The same principle can be applied for any other catalogue. Following the same syntax, trafficSign_signName_numPosts = * and
trafficSign_signName_defaultHeight = *
are also supported to define the corresponding TrafficSignType values for a sign.

Traffic Sign catalogues

The first thing that had to be done was to make the application able to handle non-predefined materials parsed from a configuration file:

/* If material is not defined in Materials.java, create new material
and add it to externalMaterials map */

if (material == null) {
	material = new ConfMaterial(Interpolation.FLAT, Color.white);
	externalMaterials.put(materialName, material);
}

The externalMaterials Map that can be seen here stores exactly what its name implies. It is also used in getMaterial(String fieldName) in Materials.java for this method to be able to also return the external ones.

Next up is the addition of a core method in TrafficSignModule, mapSignAttributes . Remember the trafficSign_signName_ values mentioned above? This is the method to parse and return them, if they exist, as they are essential for the creation of the sign. As for now, this function returns a Map containing the results of the parsing plus a couple of necessary values more, as Strings; a situation that might be later improved by having the method return a TrafficSignType instance. As this function is relatively large to be included here, only its brief javadoc is presented below:

/**
 * Parses configuration files for the traffic sign-related keys
 * trafficSign_NAME_numPosts|defaultHeight|material
 * 
 * @param country The sign country prefix, if it exists; empty string otherwise
 * @param sign The sign name (without country prefix and subtype/brackettext value)
 * @return A HashMap containing the above values if found | Empty map in case of "fatal" error
 */
private Map<String, String> mapSignAttributes(String country, String sign)


Wrapping this section up, are some final noteworthy points:

  • In both the material definitions (when it comes to traffic signs) and the trafficSign_signName_ keys it was deemed necessary to follow a single convention for the signName representation. That convention is the already used “ SIGN_countryPrefix_ID “ . So, to configure some attributes for the German sign 625-11 one could use:
material_SIGN_DE_625_11_transparency = BINARY
trafficSign_SIGN_DE_625_11_numPosts = 2
  • Global values for traffic sign height and a sign’s pole radius can be defined (preferably) at the beginning of each catalogue like this:
# Global values
defaultTrafficSignHeight = 2.6
standardPoleRadius = 0.038

However the presence of the trafficSign_signName_defaultHeight = * key for a specific sign will of course overwrite the global value for this sign only.

  • 2 more necessary configurable fields are added in TextTextureData. Those are textColor and relativeFontSize .
    textColor defines the text’s color, as its name implies, by parsing hexademical values from the configuration file. Its value defaults to #000000 (black).
    relativeFontSize is a way of configuring the text’s size in relation to the overall size of the image. The smaller the value the smaller the text size. Its use is showcased in the outputs below.

PNG outputs of signs defined solely in the German traffic sign catalogue configuration file

The depicted signs are generated using the following material definitions respectively:

material_SIGN_DE_266_transparency = BINARY
material_SIGN_DE_266_texture0_file = ./textures/signs-DE/regulation_signs/266.svg
material_SIGN_DE_266_texture0_width = 0.84
material_SIGN_DE_266_texture0_height = 0.84
material_SIGN_DE_266_texture1_type = text
material_SIGN_DE_266_texture1_text = %{traffic_sign.subtype}m
material_SIGN_DE_266_texture1_font = DIN 1451 Mittelschrift,PLAIN
material_SIGN_DE_266_texture1_topOffset = 65
material_SIGN_DE_266_texture1_leftOffset = 52
material_SIGN_DE_266_texture1_relative_font_size = 20

and the .osm file entry:

<tag k='traffic_sign' v='DE:266-5' />

DE:266

material_SIGN_DE_279_transparency = BINARY
material_SIGN_DE_279_texture0_file = ./textures/signs-DE/templates/275.png
material_SIGN_DE_279_texture0_width = 0.84
material_SIGN_DE_279_texture0_height = 0.84
material_SIGN_DE_279_texture1_type = text
material_SIGN_DE_279_texture1_text = %{traffic_sign.subtype}
material_SIGN_DE_279_texture1_textColor = #FFFFFF
material_SIGN_DE_279_texture2_file = ./textures/signs-DE/templates/279_stripe.png
material_SIGN_DE_279_texture1_font = DIN 1451 Mittelschrift,PLAIN

and the .osm file entry:

<tag k='traffic_sign' v='DE:279-50' />

DE:279

Application document:

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

Coming up: Rendering destination signs

Login to leave a comment