GeoJSON conversions

Looking some more at converting route relations into GeoJSON it quickly became clear that some options are less useful than others. One thing that causes problems are braids. A braid is where a route splits into two alternate routes. I thought about this in advance and didn't think they would be much of a problem, but I was wrong. If a route is a two-way route where you could travel along it in either direction there are braids more often than I expected. Dual carriageways immediately cause problems as the route would take separate carriageways depending on the direction. Roundabouts with flares similarly have alternate routes depending on direction and a few complex junctions also have alternative routes too. One-way systems in a town also forces different routes to be used. Then there are the genuine alternative routes giving an option such as a picturesque versus quicker route.

My original plan was to try to create a single GeoJSON LineString to represent the whole route. This is clearly not possible as each braid cannot fit into a single LineString and braids are the norm not the exception. Another way is to treat each way in the OSM relation as a separate GeoJSON LineString.

GeoJSON can have a single object in it or multiple objects. Each object can also be a multiple object in itself. A LineString has a single line, a MultiLineString has multiple lines, but, confusingly, a MultiLineString counts as a single object. Each single object is a feature and GeoJSON can hold a collection of features, known as a FeatureCollection. These can be mixed types of points, lines and polygons, though for now I'm only interested in lines. If an object is described as a feature, the feature can also have properties, indeed it must have properties.

I'm going to experiment with the options and see what works.