Initial Ontology
This model focuses on having a look at cycling infrastructure from a general point of view. So it is not meant to be leaning towards a single country, region, type or whatsoever. It should be a decomposition in multiple ways: (i) physically, so deviding the domain in components, (ii) logically, so creating a basic typology of cycling infrastructure objects, as well as (iii) functional, so decribing the functions of – and requirements to – types and components, mostly with some kind of rating, which will be either low to high or just binary.
The use case of the ontology is determining whether an infrastructure object for cyclists is fit to its task and for designing objects that are fit to their requirements, not over- or underfitted. Examplary competency questions for that domain are:
- What are the pros of a cycle track in comparison to a shared use path?
- What are the components of a certain cycling infrastructure object?
- What type would be best for given requirements?
Parametrization
The main idea of this ontology is helping in the situation when designing a new object and having problems about making good compromises between environment, comfort, safety and unfortunately economy. The main decisions and in our case – parametrization options of the model – that have to be considered are:
- estimated number of daily users
- implementation of supplementary components
- road material and width
- principle of organization between traffic modes or type of cycling infrastructure object
- marking color and other visual expertices like signs
Decomposition
The easiest decomposition is probably the physical one, grouped in CyclingInfrastructureDomain: a cycling infrastructure object always consists of some type of road, usually there are also signs and road markings, in some cases even independet street lights and traffic lights and separations towards other traffic modes. These components existentially need materials from which they were built.
Another more quite basic decomposition is the functional one: functions can be grouped in Safety, Comfort and Environmentental functions or requirements. Safety consists of pedestrian and cyclist safety, as well as visibility and structured interchanges, the latter of which also matter for comfort. Also very important for comfort are speed, smooth road surfaces and good orientation.
As mentioned before, a typology of cycling infrastructure objects is also extremely important. Different types result in different cross sections, components and spatial needs, but also different features, especially safety and comfort.
pmod_assignment01_cyclinginfrastructure
Parametric 3D Model
Just as the ontology before, the domain of this model is quite broad. To simplify it, I thought about it as a tool to easily visualize early routing drafts for cycling infrastructure.
One specific challenge when designing an infrastructure object for cyclists is, of course, finding an optimal course for the road. Very important as well is figuring out, which exact type of infrastructure object, as explained in the first assignment, is wanted and fits the surroundings best.
These two criteria match those of a conceptual design phase, therefore a rather low level of detail is required to represent the problem. This also helps with keeping a low complexity and quicker reactions to parameter changes.
At the end the visualization is required to:
- show the differences between lanes, acquired by color coding
- show the course of the whole road
- show the cross section of the road to indicate height differences
Following this scheme, as well as the possibilities mentioned in the first assignment, a handful of parameters arises:
- coordinates for creating the axis
- width of each lane
- height of each lane
- width of separation
- height of separation
- number of segments (curvature detail)
- minimal road thickness
Modelling logic
The road axis is generated using cubic interpolation between the given coordinates. This is a huge advantage, since it combines direct connections with smooth curvature, so economic and comfort aspects.
The different types described in the first assignment can get visualized by adjusting and/or setting parameters to zero, which triggers the model to let the equivalent objects to disappear.
Each lane is generated by extruding a strip of boxes from a line depending on a few parameters. By utilizing this procedure, in opposition to using a normal box generator, the lanes are very customizable regarding their position (offset from axis and height), as well as their proportions (number of segments and thickness). All lanes are bent along the axis to follow it’s course.
Experimenting with different cross sections
The selected alternatives initially come from the first assignment, where the ontology defined a broad typology for cycling infrastructure.
The variations happen only in the definition of the cross sections, i.e. the type of the infrastructure object.
The screenshots of the visualizations show that for the defined road axis, many different construction types can be implemented. A shared use road (Figure 1) does not make sense if there is a lot of space available and additionally a lot of users in an urban environment. In that case a bike lane (Figure 2) or even a cycle track (Figure 3) is much more efficient. Anyhow this is not an option for narrow streets with a lot of cyclists: in that example, a bike path (Figure 4) plus pedestrian lanes is much more appropriate. Therefore each type can be a good alternative, depending on the scenario, as discussed in detail in the first assignment. The implemented 3D model shows a Cycle Track on a spline axis.
