Viewing 9 posts - 16 through 24 (of 24 total)
  • Author
    Posts
  • #54515
    Avatar photoJohnPercy
    Participant

    @Tobias
    Wenn Sie in Elevate die Fläche testen, testen Sie area=”~|no” mit highway cores und highway casings. Alle anderen Tests für Nicht-Bereiche gelten einfach für area=”~”. Ist das Absicht? Können Sie bitte erklären, warum?
    Wie Sie vielleicht vermuten, hat dies damit zu tun, dass ich mein Design so geändert habe, dass es mit der Erkennung multi Polygone funktioniert.

    Voluntary and Velocity themes - https://voluntary.nichesite.org

    #54516
    Avatar photoTobias
    Keymaster

    @Christian, danke, ich war das Wochenende unterwegs und teste unter der Woche in Ruhe.

    Wenn Sie in Elevate die Fläche testen, testen Sie area=”~|no” mit highway cores und highway casings. Alle anderen Tests für Nicht-Bereiche gelten einfach für area=”~”. Ist das Absicht? Können Sie bitte erklären, warum?

    Gute Frage, mancher Code ist so alt, dass ich selber nicht mehr weiß warum. Und wenn es geht stört es ja auch nicht. Schätze ich hatte mal ein Problem an einer anderen Stelle, bei dem ich ein “no” durch ein “~” ergänzt habe (oder umgekehrt) und habe es sicherheitshalber bei allen ähnlichen Situationen gemacht.

    Developer of Elevate mapstyle

    1 user thanked author for this post.
    #54517
    Avatar photoJohnPercy
    Participant

    Ich habe eine Beta-Version zusammengestellt, die mit der Oxford-Karte funktioniert. Es richtet sich an Locus-Benutzer, funktioniert aber auch mit den anderen aktuellen Karten-Apps.
    Sie können es unter https://voluntary.nichesite.org/beta.html herunterladen

    I’ve put together a beta version that works with the Oxford map. It’s aimed at Locus users but will work with the other recent map apps.
    You can download it from https://voluntary.nichesite.org/beta.html

    Corrected multi polygon for pedestrian area
    Corrected multi polygon for pedestrian area

    Incorrect multipolygon for pedestrian area
    Incorrect multi polygon for pedestrian area

    Voluntary and Velocity themes - https://voluntary.nichesite.org

    2 users thanked author for this post.
    #54560
    Avatar photoTobias
    Keymaster

    I’m making some progress. I need to test on it being a multi polygon (MP) and on not being a multi polygon (~). I’ve got the first test working but not the second. This may be due to an error in my theme.
    However it will only work if based_on_rel can only be MP or empty, so your scheme of having different possible values for it won’t work.

    I finally found the time. It works for me:

    		<rule cat="nomtb" e="way" k="leisure" v="ls_track" closed="yes" zoom-min="14"><!–zm–>
    			<rule e="way" k="area|based_on_rel" v="yes|mp">
    				<rule e="way" k="piste:type|highway|tourism|attraction" v="~">
    					<area fill="#DDF2A07B" />
    					<line stroke="#B36C4C" stroke-width="0.2" />
    				</rule>
    			</rule>
    			<rule e="way" k="area|based_on_rel" v="area_no|~">
    				<line stroke="#B36C4C" stroke-width="1.6" />
    				<line stroke="#F2A07B" stroke-width="1.2" />
    			</rule>
    		</rule>
    

    I think for leisure=track one can assume that a future, different based_on_rel occasion which will result in wrong rendering is unlikely, so a “~” should do. The other use case is highway=pedestrian – theoretically it might be that it is part of a hiking relation; but usually there are additional ways for routing when there are pedestrians areas because the latter don’t really work. But I might be wrong…

    Developer of Elevate mapstyle

    1 user thanked author for this post.
    #54565
    Avatar photoTobias
    Keymaster

    John’s example is a highway=footway, so I see John’s point. But the possible separation of routes from highways will maybe lead to tags like based_on_rel=route – but these wouldn’t be associated with the highway=* as like it is today, right?

    Developer of Elevate mapstyle

    #54566
    Avatar photoChristianK
    Keymaster

    But the possible separation of routes from highways will maybe lead to tags like based_on_rel=route – but these wouldn’t be associated with the highway=* as like it is today, right?

    Seperating routes from underlaying highways:

    I can inherit the tags from underlaying ways to route-copys from these ways.
    Its quite an effort and if there are (eg) 5 routes refer to a ways you would have 5 times (eg) a ways with highway=secondary|cycleway|whatever stacked upon each other

    So you have to ensure that ways with a tag like based_on_rel=route do NOT render the ordinary tags 5 times upon each other.

    If I don’t inherit the tags of the underlaying ways you can only render routes as simple lines w/o any further attributs like highway,tunnel,oneway,lane##,sac_scale, mtb_scale and many others.
    Whereas tags that are only used as attributs (non-renderable) are IMO non-critical and can be inherited to route-copied-ways w/o problems (??)

    A possible solution is to identify copied/inherited tags as “inh_” so highway=secondary becomes inh_highway=secondary
    This in consequence would mean that I have to make a table with tags that have to be copied in tag-mapping from “tag” to “inh_tag” with all EQs and flags.
    Possible

    AND: keep in mind that with the alps.map we would have additional 1,15mio hiking and 0.5mio cycle ways.
    Thats a lot to render on a smartphone.
    Thats a lot to inherit ways during map-make.
    That means a BIG impact on map-size.

    However, I we (eg) seperate I#N|N#N from R#N|L#N as we discussed we would have to seperate couse otherwise we ran into a non solvable 15tags problem, so lets think about seperating routes from underlaying ways.

    Tobias/John: Which tags have to be copied to “tag” to “inh_tag” if we make copies from ways referenced by route-relations?

    #54569
    Avatar photoJohnPercy
    Participant

    1. Lomaps have a similar basic scheme of separating routes from highways with a tag “lm_highway” that inherits the associated highway. In addition only tunnel and bridge are inherited. This is to allow for the correct offset for marking the routes. Obviously the ref and name attributes of the relationship are applied to the route, not the highway. This is the minimum solution.
    In addition they have a similar scheme of separating osmc-marked routes from highways that puts the underlying highway into groups according to width of rendered line, and also creates an “osmc_order” tag (value of 1,2,3,4,5) where multiple routes are attached to a highway to allow for *all* the routes to be shown with differently offsets. (Currently it is just all the routes with different osmc colours.) This is the (almost) maximum solution and increases the complexity of the theme.
    2. I realise my previous concern could be solved by testing for “area|based_on_rel” = “~|route|area_no” for example, if necessary
    3. My difficulty with getting the test to work turned out to be due to Locus showing both the small Oxford test map and the larger Great Britain standard map for the same area at the same time, due to its auto switching setting.

    [DE]
    1. Lomaps haben ein ähnliches Grundschema zur Trennung von Routen und Highways mit einem Tag „lm_highway“, das die zugehörige Autobahn erbt. Außerdem werden nur Tunnel und Brücke vererbt. Dies dient dazu, den richtigen Versatz für die Markierung der Routen zu ermöglichen. Offensichtlich werden die Attribute ref und name der Beziehung auf die Route und nicht auf die Highway angewendet. Dies ist die Minimallösung.
    Darüber hinaus verfügen sie über ein ähnliches Schema zur Trennung von osmc-markierten Routen von Autobahnen, das die zugrunde liegende Highway entsprechend der Breite der gerenderten Linie in Gruppen einteilt und außerdem ein „osmc_order“-Tag (Wert 1,2,3,4,5) erstellt. Dabei sind mehrere Routen an eine Highway angeschlossen, damit *alle* Routen mit unterschiedlichen Versätzen angezeigt werden können. (Derzeit sind es nur alle Routen mit unterschiedlichen osmc-Farben.) Dies ist die (fast) maximale Lösung und erhöht die Komplexität des Themas.
    2. Mir ist klar, dass mein vorheriges Problem gelöst werden könnte, indem ich bei Bedarf beispielsweise auf „area|based_on_rel“ = „~|route|area_no“ teste
    3. Es stellte sich heraus, dass meine Schwierigkeiten, den Test zum Laufen zu bringen, darauf zurückzuführen waren, dass Locus aufgrund seiner automatischen Umschalteinstellung sowohl die kleine Oxford-Testkarte als auch die größere Großbritannien-Standardkarte für dasselbe Gebiet gleichzeitig anzeigte.

    Voluntary and Velocity themes - https://voluntary.nichesite.org

    2 users thanked author for this post.
    #54571
    Avatar photoTobias
    Keymaster

    Its quite an effort and if there are (eg) 5 routes refer to a ways you would have 5 times (eg) a ways with highway=secondary|cycleway|whatever stacked upon each other

    Would it be possible to create only copies for each kind of route/route-group? E.g.
    – lcn/rcn/ocn
    – ncn/icn
    – mtb
    – lwn/rwn/own
    – nwn/iwn
    – and probably osmc?
    For those cases when there are several routes on a way…

    So you have to ensure that ways with a tag like based_on_rel=route do NOT render the ordinary tags 5 times upon each other.

    But you wouldn’t need this if there’s a “inh_highway” etc., would you?

    Tobias/John: Which tags have to be copied to „tag“ to „inh_tag“ if we make copies from ways referenced by route-relations?

    At the moment only these tags are used in Elevate for rendering routes:
    highway=*
    cycleway_lane|cycleway_track=*
    tunnel=*
    osmc_color=*

    The order for OSMC as mentioned by John is probably a good idea, too.

    Developer of Elevate mapstyle

    #54605
    Avatar photoChristianK
    Keymaster

    Also lassen wir das mal so wie es ist.
    Die Anforderungen sind nun soweit klar, und ja eine Gruppierung ist IMO notwendig.

    Das dies einen Komplettumbau der OAM bedeuten würde ist klar.

    Well…..

    2 users thanked author for this post.
Viewing 9 posts - 16 through 24 (of 24 total)
  • You must be logged in to reply to this topic.