<div dir="auto">Not sure which Felix you meant. For me it was not about that poi influencing the routing, but the opposite. If mkgmap created a reputable line only then display the gate. <div dir="auto"><br></div><div dir="auto">E.g. if excluded using semi-connected marker, then also remove the gate.</div><div dir="auto">Typical scenario a highway=path entering a residence garden and the highway=gate tag on the path.</div><div dir="auto">What I want are gates for say a public garden or theme park, or similar.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 16 Oct 2022, 23:18 Felix Herwegh <<a href="mailto:mlmmduk@herwegh.de">mlmmduk@herwegh.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div>
      <div id="m_1052365431164764217rwhMsgHeader">Hi Gerd,</div>
      <div><br>
      </div>
      <div>the quote ("best routable") was from Felix Hartmanns opening
        post. I just try to render my maps as focussed and decluttered
        as possible for keeping a bike rolling without loosing too much
        attention on the map while not using routing. But as far as I
        understand I see similarities in identifying objects to omit.</div>
      <div><br>
      </div>
      <div>In my question I was addressing situations similar to the
        example from the <a href="https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dgate" target="_blank" rel="noreferrer">Wikis
          barrier=gate section</a> (either with or without an additional
        barrier=fence or the like crossing), a barrier node being part
        of two ways hence being processed from both by
        --add-pois-to-lines.</div>
      <div>
        <blockquote>
          <p><i>Based on the location below, the gate node should be the
              end of a way. A new way starts with the gate node and it
              should have the access set to private if the access is
              restricted.
            </i></p>
          <pre><i>x------x------O++++x++++x
</i></pre>
          <ul>
            <li><i><code>x</code></i><i> = node</i><i><br>
              </i></li>
            <li><i><code>O</code></i><i> = node with barrier=gate</i></li>
            <li><i><code>------</code></i><i> default way</i></li>
            <li><i><code>+++++</code></i><i> way with access=private</i></li>
          </ul>
        </blockquote>
      </div>
      <div>For example <br>
      </div>
      <blockquote>
        <div><i>Punkt: 17848298</i><i><br>
          </i><i>  Datensatz: 230db4cd</i><i><br>
          </i><i>  ...</i><i><br>
          </i><i>  Merkmale: </i><i><br>
          </i><i>    "access"="private"</i><i><br>
          </i><i>    "barrier"="gate"</i><i><br>
          </i><i>  Koordinaten: 54.1016042, 11.5995597</i><i><br>
          </i><i>  ...</i><i><br>
          </i><i>  Teil von: </i><i><br>
          </i><i>    Linie: Dünenstraße (3629239)</i><i><br>
          </i><i>    Linie: 546855848</i><i><br>
          </i><i>    Linie: 81154811</i><br>
        </div>
      </blockquote>
      <div>Hence, having a gate between a bad track (later on not
        rendered due to quality, already filtered from the RaceSurf
        include) and an acces=no road (later on not rendered for just
        that) could have rendered an isolated gate from the latter road
        segment. <br>
        That's where I took the problematic turn, trying to make a
        decision on all possible ways connecting a gate, instead of more
        consequently filtering all roads before having points derived
        from them in the first place. So another RelevantRoads include
        file for dual use in points and lines it will be.</div>
      <div><br>
      </div>
      <div>But:<br>
      </div>
      <div>For my sample above, the gate then still will be rendered
        from the "Dünenstraße", although not needed, since "Dünenstraße"
        will just end there in my map because neither of lines 546855848
        or 81154811 will be rendered.</div>
      <div>Honestly, I was additionally flirting with trying to use
        different icons for gates with and without a barrier line
        (fence), since those without and on suitable roads occasionally
        could just void nice shortcuts for a bike... :-)<br>
      </div>
      <div><br>
      </div>
      <div>>I see no need to add lots of logic...</div>
      <div><br>
      </div>
      <div>Sorry, that was not my intention. I'm still searching my way
        into OSM and mkgmap and only wanted to make shure, not to miss
        an existing concept as more than once before. I should better
        have omitted that raw idea of mine, thought it might help
        understand my train of thought.<br>
      </div>
      <div><br>
      </div>
      <div>Cheers, Felix<br>
        <hr id="m_1052365431164764217rwhMsgHdrDivider" style="border:0;border-top:1px solid #b5c4df;padding:0;margin:10px 0 5px 0;width:100%">
        <div style="font-family:Tahoma!important;color:#000000!important;font-size:13px!important"><b>From:</b> Gerd
          Petermann [<a href="mailto:gpetermann_muenchen@hotmail.com" target="_blank" rel="noreferrer">mailto:gpetermann_muenchen@hotmail.com</a>]</div>
        <div style="font-family:Tahoma!important;color:#000000!important;font-size:13px!important"><b>Sent:</b> Sunday,
          October 16, 2022 at 10:35 AM</div>
        <div style="font-family:Tahoma!important;color:#000000!important;font-size:13px!important"><b>To:</b> Development
          list for mkgmap</div>
        <div style="font-family:Tahoma!important;color:#000000!important;font-size:13px!important"><b>Subject:</b>
          [mkgmap-dev] Test if POI is part of a line</div>
        <br>
      </div>
    </div>
    <blockquote type="cite" style="border:none!important;margin-left:0px!important;margin-right:0px!important;margin-top:0px!important;padding-left:0px!important;padding-right:0px!important">
      <pre>Hi Felix,

I do understand that one would want to avoid rendering gates which are not on highways, but I don't understand why you care about
the effect on routing. That's a completely different story and I think mkgmap handles this very well with the --link-pois-to-ways option.
Or maybe you mean something else?

A barrier node should never be connected to more than one way, else it is a mapping error and mkgmap reports this in the log (if enabled).
It should be a rare case and thus I see no need to add lots of logic to avoid the rendering.
The corresponding nodes should be fixed in OSM.

Gerd

________________________________________
Von: mkgmap-dev <a href="mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk" target="_blank" rel="noreferrer"><mkgmap-dev-bounces@lists.mkgmap.org.uk></a> im Auftrag von Felix Herwegh <a href="mailto:mlmmduk@herwegh.de" target="_blank" rel="noreferrer"><mlmmduk@herwegh.de></a>
Gesendet: Samstag, 15. Oktober 2022 18:36
An: <a href="mailto:mkgmap-dev@lists.mkgmap.org.uk" target="_blank" rel="noreferrer">mkgmap-dev@lists.mkgmap.org.uk</a>
Betreff: Re: [mkgmap-dev] Test if POI is part of a line

</pre>
      <blockquote type="cite" style="border:none!important;margin-left:0px!important;margin-right:0px!important;margin-top:0px!important;padding-left:0px!important;padding-right:0px!important">
        <pre>I would only like to display barrier/highway=gate point icons if they are part of a (best routable) line.
</pre>
      </blockquote>
      <pre>Since I try to declutter my maps as best as possible I too had "remove non-relevant gates" on my to do list and followed up on that today.
Accounting for points mapped on or between ways and access restrictions optionally stemming from point and/or way I was able, to already thin out my gates significantly. The include file is just "re-used" from my lines processing.

# NoAccess gates on relevant highways
# only works w/ mkgmap option --add-pois-to-lines
if (mkgmap:from-node:barrier ~ '.*(gate)' & highway=*) then
# gate on highway
   include "../inc/RaceSurf";
   # tagging of (preselected) elements w/ hgh:surface=(Race|noRace)
   # depending on quality in regard to race (and gravel) bike use

  if (hgh:surface=Race) then
       (mkgmap:from-node:access ~ 'no|private
        & !(mkgmap:from-node:bicycle ~ 'yes|permissive')
        ...)
      # relevant access restricted by point
     |
       (access ~ 'no|private'
        & !(bicycle ~ 'yes|permissive')
        ...)
     # relevant access restricted by road segment
                                                                                 [...]
  end
end

But I was not able, to solve the probably most interesting situation:
If a (gate) point is part of two (or more) consecutive ways, it is processed multiple times from --add-pois-to-lines, but one would need the tags of all ways involved at the same time to make the final decision on whether or not to render this point. (That is -for starters-, if not at least two ways were deemed interesting, the gate might not be rendered although from one way alone, it would).

Is there a concept, allowing to do that?

The only idea I came up with would be, to use the mkgmap:line2poitype tag to flag these POIs somehow and finally delete all, if not at least 2 of those where placed at the exact same location. Somewhat similar to deleting identical POIs at the same location as documented for the nearby-poi-rules. In the latter case (>2), delete all but one...

Cheers, Felix
_______________________________________________
mkgmap-dev mailing list
<a href="mailto:mkgmap-dev@lists.mkgmap.org.uk" target="_blank" rel="noreferrer">mkgmap-dev@lists.mkgmap.org.uk</a>
<a href="https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" target="_blank" rel="noreferrer">https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a>
</pre>
    </blockquote>
  </div>

_______________________________________________<br>
mkgmap-dev mailing list<br>
<a href="mailto:mkgmap-dev@lists.mkgmap.org.uk" target="_blank" rel="noreferrer">mkgmap-dev@lists.mkgmap.org.uk</a><br>
<a href="https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" rel="noreferrer noreferrer" target="_blank">https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a></blockquote></div>