[mkgmap-dev] Test if POI is part of a line

Sun Oct 16 18:33:32 BST 2022

Hi Gerd,

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.

In my question I was addressing situations similar to the example from 
the Wikis barrier=gate section 
<https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dgate> (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.

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

    /x------x------O++++x++++x /

      * /|x|//= node//
        /
      * /|O|//= node with barrier=gate/
      * /|------|//default way/
      * /|+++++|//way with access=private/

For example

    /Punkt: 17848298//
    //  Datensatz: 230db4cd//
    //  ...//
    //  Merkmale: //
    //    "access"="private"//
    //    "barrier"="gate"//
    //  Koordinaten: 54.1016042, 11.5995597//
    //  ...//
    //  Teil von: //
    //    Linie: Dünenstraße (3629239)//
    //    Linie: 546855848//
    //    Linie: 81154811/

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

But:
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.
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... :-)

 >I see no need to add lots of logic...

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.

Cheers, Felix
------------------------------------------------------------------------
*From:* Gerd Petermann [mailto:gpetermann_muenchen at hotmail.com]
*Sent:* Sunday, October 16, 2022 at 10:35 AM
*To:* Development list for mkgmap
*Subject:* [mkgmap-dev] Test if POI is part of a line

> 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<mkgmap-dev-bounces at lists.mkgmap.org.uk>  im Auftrag von Felix Herwegh<mlmmduk at herwegh.de>
> Gesendet: Samstag, 15. Oktober 2022 18:36
> An:mkgmap-dev at lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] Test if POI is part of a line
>
>> I would only like to display barrier/highway=gate point icons if they are part of a (best routable) line.
> 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
> mkgmap-dev at lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20221016/07ab2f4f/attachment-0001.html>