-
Beiträge
-
How about creating network_ref instead.
Only very view keys in mapsforge can have a not predefined value, all other have to be defined in tag-mapping.xml
So if Christian adds a new key „network_ref“, only values that are defined in the file are contained in the map.
Those rare keys are for nodes „name“, „addr:housenumber“ and „ele“ and for ways „name“, „addr:housenumber“ and „ref“, see here.Developer of Elevate mapstyle
That’s conclusive then. Thanks.
I think though that I will still want to avoid displaying the ref where a network runs along a major highway due to the uncertainty of which ref is in the tag.Voluntary and Velocity themes - https://voluntary.nichesite.org
@Christian: Can you please confirm that I should be looking for
network_mtb=“lay_mtb“
And that
network|network_mtb=“mtb|lay_mtb“
ought to catch mtb networks.
Because I’m not seeing an improvement on the latest GB map. For example http://www.openstreetmap.org/way/464515096 has both mtb and bicycle (lcn) relations on it, but only the bike one shows up on the map.Voluntary and Velocity themes - https://voluntary.nichesite.org
@Christian: Can you please confirm that I should be looking for
network_mtb=”lay_mtb”It works for me, but only if there isn’t a normal cycling route on the same way. So it works like network=mtb and makes not the intended difference.
While I had a look at MTB routes, I realized that the network=icn/ncn/rcn/lcn scheme applies as well (according to this it’s even required, although only 16% of route=mtb have a network tag). Wouldn’t it make sense to display add this while we’re restructuring the MTB routes?
Something like
network_mtb=mtb_route (no network tag)
network_mtb=mtb_icn
network_mtb=mtb_ncn
network_mtb=mtb_rcn
network_mtb=mtb_lcnDeveloper of Elevate mapstyle
You are both right.
While resolving of the relations works perfect fine, the network_mtb=lay_mtb gets lost while remerging the OSM-Files.This is’nt funny couse it’s at a very basic level of the whole process.
… resolving this will need a redesign of the whole stuff…At least the MTB -Routes will have to be prozessed to seperate ways – no other way is possible without adding more bugs.
This will take some time.
@Tobias: I will try it.Best regards
ChristianSomething like
network_mtb=mtb_route (no network tag)
network_mtb=mtb_icn
network_mtb=mtb_ncn
network_mtb=mtb_rcn
network_mtb=mtb_lcnHmm..
And what if more than one Relation with different Network_Tags are refering to one way?
This could be resolved by making seperate ways for each Network.
However – what if two relations with the same network_tag refer to one way – in this case the refs of both realtions have to be combined into one ref…..Lot of work, lot of prozessing time – however possible for the very few MTB-Rels.
Maybe there is another way to archive this…. ??
A relation can only have one network tag. Isn’t it possible to transform/rename this tag before inheriting it to a way?
Developer of Elevate mapstyle
Isn’t it possible to transform/rename this tag before inheriting it to a way?
Of course, it is.
I can do the following:network_mtb=mtb_route (no network tag)
network_mtb_icn=mtb_icn
network_mtb_ncn=mtb_ncn
network_mtb_rcn=mtb_rcn
network_mtb_lcn=mtb_lcnThe problem persists if you have eg. two relations with route=mtb and network=lcn refering to one way.
I this case the refs have to be combined in one string – possible but slow course a further seach in the (big) array have to be performed (or I just irgnore this issue 😉 )Altogether I want to preserve a minimum level of compatibility with earlier Versions of the Maps/Themes.
I’m really willing to improve the MTB-Layer – so lets lean back and think and discuss about how to to build a robust solution.
The problem persists if you have eg. two relations with route=mtb and network=lcn referring to one way.
I this case the refs have to be combined in one string – possible but slow course a further search in the (big) array have to be performedAs far as I can see, you already do something similar with hiking routes and cycle routes. For example, http://www.openstreetmap.org/way/41156200 is in a hiking relation (Midshires Way) and a cycle relation (NCN 6). You construct a combined ref for the path as 6/MW.
This discussion does make me see why Locus maps make separate routes for each relation, though that does have its own difficulties.Voluntary and Velocity themes - https://voluntary.nichesite.org
The problem persists if you have eg. two relations with route=mtb and network=lcn refering to one way.
I this case the refs have to be combined in one string – possible but slow course a further seach in the (big) array have to be performed (or I just irgnore this issue
)But at the moment you’re doing it for even more routes – all route=mtb (and route=cycling/hiking), no matter what network, are combined in one ref string.
Altogether I want to preserve a minimum level of compatibility with earlier Versions of the Maps/Themes.
Makes sense, if it isn’t too costly.
I’m really willing to improve the MTB-Layer – so lets lean back and think and discuss about how to to build a robust solution.
There’s no rush, at least here it’s no MTB season 🙂
What I always wondered – if you change in a relation „type=route“ to „type=multipolygon“, will it be contained in the map? Probably as separate ways as discussed above. In combination with „force-polygon-line=true“ in tag-mapping this could be also a solution.
Developer of Elevate mapstyle
Progress so far: There will be two seperate scripts for resolving the mtb-routes:
1.) Inheriting the tags from the relations to the underlaying ways and tagging of the routes with route priority with network=mtb – same as it has been so far for compatibility.2.) Seperate ways for route=mtb with their own ID’s, each reference from a relation will have its own way.
There is no priority – 1 reference from a relation is 1 new way.Tagging will finally be (to be disussed):
mtbnetwork (so similar to hknetwork)
values: imn,nmn,rmn,lmn
Value for routes with no network tag and route=mtb: umn (undefined mtb network)
Refs are inherited from relations and are NOT combined with hike/cycle network.There are relations with route=mtb + network=mtb.
For me the network in this case should be transformed to network=umn ??As for the tags inherited from underlaying ways:
Are you really shure that you want to have the tags
highway
mtb_scale
mtb_scale_uphill
inherited to the new, seperate mtb-ways??
For me thats no Problem – however, these tags exist in the underlaying „real“ ways.Another issue:
Up to now each way bound to a mtb_route received network=mtb.
So tagging errors like „route=mtb AND network=rwn“ were undedected.
With the new resolving scripts these routes are no longer resolved.Scripts are running, however there is still lot of work to do till a release.
Best regards
ChristianMy initial thoughts:
1. While I understand your desire for backwards compatibility with existing themes, this means some current issues remain.At present MTB routes and bicycle routes are amalgamated. First, I think there is a conceptual error in the way this is done that needs correcting. As Tobias posted above, network=icn|ncn|rcn|lcn can apply to both route=bicycle and route=mtb. The logically correct treatment is to have route=bicycle, mtbroute=mtb, network=icn|ncn|rcn|lcn|ucn, mtbnetwork=imn|nmn|rmn|lcn|umn.
Second, if a layer corresponding to network=mtb is currently turned off, it will also turn off some cycle networks. For example, I may want to do a rural cycle ride but don’t feel up to MTB routes, so turn off the MTB layer. This leaves gaps in the bicycle network. I suppose giving mtb routes low priority in the amalgamation with bicycle routes would go some way towards preserving backwards compatibility but overcome this, if possible.2. a) Separate ways for each route will preserve each MTB route but will cause design difficulties where routes overlap if using transparent highlighting. Your proposed tagging seems fine otherwise though.
b) Inheriting highway tags will not preserve backwards compatibility as current themes would render the duplicated highway as well as the original one. You could inherit the highway tag as mtb_highway, I suppose.Also I don’t find it balanced or obvious that each mtb route should end up as a distinct way but cycle routes are amalgamated, as are hiking routes.
Voluntary and Velocity themes - https://voluntary.nichesite.org
Thank Christian and John, I’m sorry for not getting back earlier – I’m pretty busy right now and will have look when I have more time at hand.
Developer of Elevate mapstyle
Hi,
By examining the Elevate style, it seems that all MTB routes have network_mtb=lay_mtb, instead of multiple values discussed above: imn,nmn,rmn,lmn,umn
Is this accurate? Is there some kind of documentation or reference for this tag? And for what actually do the scripts that process route relations?
Thanks!
- Sie müssen angemeldet sein, um zu diesem Thema eine Antwort verfassen zu können.