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 (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@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@lists.mkgmap.org.uk> im Auftrag von Felix Herwegh <mlmmduk@herwegh.de>
Gesendet: Samstag, 15. Oktober 2022 18:36
An: mkgmap-dev@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@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev