Viewing 14 posts - 16 through 29 (of 29 total)
  • Author
    Posts
  • #15331
    Tobias
    Tobias
    Moderator

    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

    #15333
    JohnPercy
    JohnPercy
    Participant

    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.

    #15356
    ChristianK
    ChristianK
    Keymaster

    GB, Switzerland, Austria are ready for download.

    #15361
    JohnPercy
    JohnPercy
    Participant

    @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.

    #15365
    Tobias
    Tobias
    Moderator

    @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_lcn

    Developer of Elevate mapstyle

    #15367
    ChristianK
    ChristianK
    Keymaster

    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
    Christian

    #15369
    ChristianK
    ChristianK
    Keymaster

    Something like
    network_mtb=mtb_route (no network tag)
    network_mtb=mtb_icn
    network_mtb=mtb_ncn
    network_mtb=mtb_rcn
    network_mtb=mtb_lcn

    Hmm..
    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…. ??

    #15372
    Tobias
    Tobias
    Moderator

    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

    #15375
    ChristianK
    ChristianK
    Keymaster

    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_lcn

    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 ;-) )

    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.

    #15377
    JohnPercy
    JohnPercy
    Participant

    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 performed

    As 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.

    #15388
    Tobias
    Tobias
    Moderator

    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

    #15451
    ChristianK
    ChristianK
    Keymaster

    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
    Christian

    #15462
    JohnPercy
    JohnPercy
    Participant

    My 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.

    #15521
    Tobias
    Tobias
    Moderator

    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

Viewing 14 posts - 16 through 29 (of 29 total)

You must be logged in to reply to this topic.