Introduction

So, this is the final entry of a what has come to be a 6 entries series, regarding this year’s Google Summer of Code project and the work that has been done on the 3D Renderer OSM2World. This post will summarize the last 2 tasks that did not get their own separate entries as well as give an overview of the whole summer work, starting from the latest. The two tasks in question are those of Rendering Destination Signs and Guessing the positions of non-explicitly defined signs, as stated in the application document, which have proved to be particularly challenging to say the least; we will go through them later on this post.
So without further ado, let’s present what has been done so far in this Summer of Code, in a chronological order:

1. Font rendering for signs with custom text: https://github.com/tordanik/OSM2World/pull/147
2. Human readable traffic sign values: This particular task does not have a pull request of its own as its TODOs, mentioned in the application document, where gradually being implemented as parts of the other tasks (a good example of this can be found in this entry)
3. SVG texture support: https://github.com/tordanik/OSM2World/pull/151
4. Traffic sign catalogues: https://github.com/tordanik/OSM2World/pull/153
5. Destination signs: https://github.com/tordanik/OSM2World/pull/154
6. Guessing the positions of non-explicitly defined signs: https://github.com/tordanik/OSM2World/pull/155 (may be changed)

A summary is available for each of the first 4 tasks, in their corresponding diary entries, listed below in the same order:

1. Font rendering for signs with custom text
2. Human Readable traffic sign values
3. SVG texture support
4. Traffic sign catalogues

Let’s now see what the remaining 2 tasks are all about!

Rendering of Destination signs

… Voir l’intégralité

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:

Human-Readable values related additions

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:

… Voir l’intégralité

Intoduction

SVG texture support was an important part of for this Google Summer of Code project. Apart from the reasons mentioned in the application document, on why adding Scalable Vector Graphics support would be benefitial, its true importance lays on this fact: Most Wikimedia CC0 available images are SVG files. That would also be the reason that led in “swapping” priorities between the 3d and 4th task listed in the application; SVGs had to be supported if users were to make use of textures provided in traffic sign catalogues like this one.
By the end of it, this task ended up leaving some extra time in our hands, presenting a good opportunity to implement another useful functionality: Make external fonts configurable and able to be registered in the application. (Note: “external” refers to fonts not supported by default in the user’s OS). The need for a functionality like this (mostly) derived from the fact that texts on traffic signs use fonts not so widespread (e.g. Interstate) but it can also come in handy in many other cases as well.
The changes described bellow can be found under the July 12 2019 commits of this feature’s branch.
So, with that out of the way, let’s see how everything got blended into the project:

SVG textures support

The concept of implementing svg textures support was pretty straightforward: a really good support for png images already exists, that of course works with all target outputs of OSM2World; so converting svgs to pngs to make further use it would be the best course of action. As of the latest updates described in a previous diary entry, image layers in a texture are now of the ImageTextureData type. That of course makes ImageTextureData.java the appropriate class to implement such a mechanism.
A couple of changes took place in that class:

… Voir l’intégralité

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

… Voir l’intégralité

Introduction

This is the very first entry regarding the official work on this year’s Google Summer of Code! As seen in the subject line, the first task was about implementing the ability to render traffic signs that “require” custom text in their definition upon mapping them. This is preferred compared to the alternative of having a different texture stored in the textures folder for every traffic signs available, for obvious reasons (e.g. huge number of textures) as well as for scalability purposes. As the available time for each task is limited and a number of existing traffic signs are rarely mapped (tested with overpass), this first implementation showcases 2 widely used sign types, those of DE:274 (speed limit) and DE:1001-31 . So, let’s take a look on the changes of the past 2 weeks:

Restructuring

Material objects use a list of TextureData objects to define the data necessary in case a texture was going to be applied to a material. Each TextureData entry in this list represents a texture layer to be applied. Up until now, these layers always referred to an already stored image. So if we were going to implement the ability to render an image with text “on the go”, this had to be changed. Therefore the first step was to introduce a TextTextureData class and define the following hierarchy:

Abstract class	First implementation	Second implementation
TextureData	TextTextureData	ImageTextureData

A getFile() method was added to each of these classes with the purpose of

• Generating and saving an appropriate temporary image with text rendered, when it comes to TextTextureData
• Returning this.file when it comes to ImageTextureData

With that, the lists that previously accepted the “default” ImageTextureData are now able to accept layers of TextTextureData type as well.
That pretty much sums up the restructuring part so let’s move on to additions/changes on existing parts of the codebase.

… Voir l’intégralité

Today marks the official beginning of Google Summer of Code 2019! Given that, it might be a good time to introduce myself and let anyone interested know about my project for this summer. So let me begin with a few words about myself:

About me

My name is Iason Manoloudis and I am a Computer Science student in the Aristotle University of Thessaloniki, in Greece. I’ve been working on my application for OpenStreepMap as well as on the OSM2World project for some time now and after some back and forth with Tordanik, my application has been accepted! Working with an open source organization is a first for me and I really look forward to get more and more involved in the numerous aspects of OSM.

Regarding the project

Regarding this summer’s project, the main focus will be around implementing traffic sign rendering capabilities in OSM2World. This extends from “basic” speed limit signs to destination signs on highways with non-standard text, all the way to more generic implementations like svg texture support and more. The various tasks of it touch a (I could say) rather wide range of the existing codebase and for anyone interested, you are of course welcome to see more details on it in the application document. So far I have committed a small contribution as I get to learn my way around the project and, as it seems now, this exciting part of in-depth discovering a large project will never stop until the end of the summer.

I will make sure to post updates on the work here, in this diary, so stick around for weekly / bi-weekly entries as we go through this exciting period!