Colour data for hiking routes

[rwrx]

Is it somehow possible to get colour data for hiking routes - https://wiki.openstreetmap.org/wiki/Tag:route=hiking ? I assume that they are stripped during data retrieval. If they are stripped is it somehow possible to not strip this colour data information?

[nvkelso]

We already pass thru the way colour for roads layer features. But if the colour is on the hiking route relation I think we leave that behind right now. Is that what you're asking for? Can you provide a couple examples (ways and their relations), please?

[rwrx]

Hi @nvkelso, thanks for respoding so quickly. Yes, it is on hiking route relation. Here in Slovakia hiking routes are mapped really well. They have also assigned colour data in hiking routes relations. Here is one example: https://www.openstreetmap.org/relation/571351#map=14/48.1719/17.1185.

[rwrx]

Hi @nvkelso do you have some news regarding this? I could work on this a bit, but I just needs some hints. If I understand correctly vector-datasource is using some jinja templates to prepare data for tileserver? Could this to get it working just mean editing or creating new jinja templates?

[rwrx]

Are there some functions in vector-datasource to add properties from relations into roads? I can work on this.

[zerebubuth]

I'm a little rusty on this, but I think the place to start is with mz_get_rel_networks, which is the more generic of several methods we use to get relation information onto ways:

vector-datasource/queries/planet_osm_line.jinja2

Line 52 in 1c26f35

'mz_networks', mz_get_rel_networks(osm_id)

It currently fetches the route, network, and ref tags, but could be extended to fetch colour as well:

vector-datasource/data/functions.sql

Lines 120 to 141 in 1c26f35

	CREATE OR REPLACE FUNCTION mz_get_rel_networks(
	way_id bigint)
	RETURNS text[] AS $$
	SELECT
	array_agg(unnested)
	FROM (
	SELECT
	unnest(tags) AS unnested
	FROM (
	SELECT
	mz_modify_network(hstore(tags))->ARRAY['route','network','ref'] AS tags
	FROM
	planet_osm_rels
	WHERE
	parts && ARRAY[way_id] AND
	parts[way_off+1:rel_off] && ARRAY[way_id] AND
	hstore(tags) ? 'route' AND
	(hstore(tags) ? 'network' OR
	hstore(tags) ? 'ref')
	) inner1
	) inner2;
	$$ LANGUAGE sql STABLE;

The output from that (now a 4-tuple instead of a 3-tuple) eventually ends up in merge_networks_from_tags:

vector-datasource/vectordatasource/transform.py

Line 7643 in 1c26f35

def merge_networks_from_tags(shape, props, fid, zoom):

Where you'd need to fix the unpacking code to handle 4 elements. t, n, r was the route "type", network and ref from the database query, and would now also have a c for colour. There are a few of these - worth searching the code for anything saying mz_networks[i:i+3] to catch them all.

There's another function, extract_network_information, which takes the mz_networks data and expands it into the walking_* and other network properties that the Tilezen schema outputs. It should be possible to extend that code in a way that also outputs walking_network_colour or similar for the highest-ranked route colour.

vector-datasource/vectordatasource/transform.py

Line 7952 in 1c26f35

def extract_network_information(shape, properties, fid, zoom):

Hope that helps!

[rwrx]

Thank you a lot for these hints. I will play with this. I will also need osmc:symbol tag, but I have noticed that some roads are parts of multiple relations. Will this also be handled by this modification, or should I modify something else?

When it will be done, could it be merged into this repository? Or isn't this something you want?

[zerebubuth]

The mz_networks system is a generic framework to handle road, walking, cycling and bus networks and therefore probably captures none of them perfectly! If you find that what you need is more special-case and fitting it into the generic framework is getting difficult, then it might be worth just adding an extra part to the query to get only the information you need (presumably the network importance / level, colour, symbol and perhaps name/ref as well) and then add a post-processing stage specifically for it.

The system is designed to output a single "most important" route/network info for each element, but also an array of the full values (prefixed with all_). We never got around to implementing support for those in the Mapzen styles, but it's technically possible to symbolize all the values - the data is in the tiles (e.g: all_walking_networks, all_walking_shield_texts).

The way we've handled this for road networks is to have a system for describing the symbols (a.k.a. road shields) as text, which the client can then use to fetch the correct image. This is modelled on the OSM network description (e.g: things like US:I for the US Interstate system, or US:OK:Turnpike for the Oklahoma turnpike). If something similar would work for osmc:symbol (and taginfo says it's already quite systematic), then that might be the way to go, with some function to clean up any junk values.

I can't speak for whether it's wanted in the repository, that's something @nvkelso would be able to say. I think it's something that could be useful for the Walkabout outdoor style for sure.

[nvkelso]

Yes, @rwrx please submit a PR to this repo, addition of walking_network_colour for the walking routes would be of general benifit to the Tilezen community. Thanks!

[rwrx]

Hello @zerebubuth and @nvkelso I am currently working on this. I got working all_walking_network_colours and walking_network_colour but I have noticed that all_walking_network_colours is not present in MVT tiles.

On this page https://github.com/tilezen/vector-datasource/blob/6e057196694b7896862c8bc2786389ad5b083f0e/docs/layers.md I can see that: "Note that these properties will not be present on MVT format tiles, as we cannot currently encode lists as values.". Is it possible to add support for encode lists as values? Maybe comma separated? Or add something like all_walking_network_colours_str as comma separated list of values? I want to create styling visualizing hiking colouring something like this on mapy.cz:

[rwrx]

I have created pull request here: #2091