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

Mon Oct 10 10:47:23 BST 2022

Hi Gerd,

No  --*add-poi-to-lines* creates points from a line that has certain tags.
What I try to achieve is actually to remove points that are NOT part of a
line / or  part of a line that is not rendered in the map. There is no
reason to show a gate if you don't have a line/road.So essentially for me
there is no sense to show a gate for me if it is not part of a routable
line.
However points created by add-pois-to-lines are also not what I want -
because it would show the gate in an incorrect position.

So the clutch of using *--link-pois-to-ways * to get the access tags onto
the line - then never show an actual barrier=gate/highway=gate but only
show one created by the *--add-poi-to-line* command?  The logical solution
is to really only show a gate where it is tagged, but only if the map is
creating a routable line for it and remove all other barrier=* /
highway=gate / entrance=yes POI.

If this is too much work to implement - then drop it. But as far as I
understand right now there is no good solution by mkgmap for this. The same
would be for traffic lights - if you remove a road because your map does
not show private roads - but a private road has a traffic light - this
traffic light should not be in the map either. And yes I know the dilemma -
we need points to be looked at pre lines for --link-pois-to-ways to work,
but for some other things we would need to look at them later again. So
this would need to be some kind of seond_finalize rules in the points file
that is executed after the lines file - and removes points from the map
again. It's not a big problem - but right now this really makes it
inconvenient to put gates into your map - as 75% of gates are just
cluttering up the map without providing any information to the user (except
if you want to create a cataster type of map showing everything). Leaving
gates out completely on the other hand makes it very hard to show for
example with parks where people can enter and where not. As very often
there are service entries to parks not open to public - so these are the
main ones that we want to show in a map.

On Mon, 10 Oct 2022 at 08:35, Gerd Petermann <
gpetermann_muenchen at hotmail.com> wrote:

> Hi Felix,
>
> my first thought was that --add-poi-to-lines is all that you need, but
> maybe I've missed something?
>
> One problem with your suggested solution is that the current
> implementation in mkgmap processes
> (tagged) nodes before lines. I can't remember exactly why but a change
> probably causes side effects.
>
> Gerd
>
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von
> Felix Hartmann <extremecarver at gmail.com>
> Gesendet: Freitag, 7. Oktober 2022 23:12
> An: Development list for mkgmap
> Betreff: [mkgmap-dev] Test if POI is part of a line
>
> I read through the old
> poi-tagged-v3.patch
>
> is_in()function for point on line discussion - but what I want is actually
> different and should be much easier?
>
> Could there be a solution to check if a point is a single point vs if it
> is part of a open/closed line?
> Why?
>
> I would only like to display barrier/highway=gate point icons if they are
> part of a (best routable) line. Especially for gates  most are just useless
> clutter because they are tagged on private houses and similar.
>
> If there was a way to delete afterwards/or create only in first place
> those points that are part of a line would be good, best would be if they
> are only shown if part of a routable line (so after the lines stye-file is
> processed).
>
> --
> Felix Hartman - Outdoormaps LTD - Openmtbmap.org & VeloMap.org
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>

-- 
Felix Hartman - Outdoormaps LTD - Openmtbmap.org & VeloMap.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20221010/cf13d312/attachment.html>