[mkgmap-dev] mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only

Tue Sep 19 10:03:11 BST 2017

Well I would like it to apply to non routable lines too - if continue
with_actions is used - basically just treat routable and non routable lines
the same (the initial check should only look at routable lines though I
guess).

Before 2707 if I remember right all copies were removed no matter if you
used continue, continue with_actions or no continue.

On Sep 19, 2017 10:07 AM, "Gerd Petermann" <GPetermann_muenchen at hotmail.com>
wrote:

> Hi Feix,
> again: There REALLY is no problem with continue or continue with_actions
> here and there never was. The function triggered by the tag just doesn't do
> what you expect.
>
> I try again to make clear how mkgmap:set_unconnected_type works:
> The code in mkgmap keeps routable lines separated from non-routable lines.
> Each line is based on a way that was processed by the style rules in the
> lines file.
> If the style adds e.g. 4 different lines for the same OSM way you have 4
> line instances refering to the same OSM id, each may be routable or not.
> After (!) all OSM elements are processed by the style rules mkgmap
> computes the nodes which are shared by routable lines (or short roads).
> If a road is not connected to any other road (one with a different OSM id)
> and the tag mkgmap:set_unconnected_type=none
> is set this routable line is not added to the map. The line instance is
> removed. In r2599 this also triggered the removal of all non-routable lines
> for the same OSM way.
> This triggering was removed with r2707 so that now the overlay line is
> still added to the map.
>
> My understanding is that you want to control this triggering somehow and
> we have to think about a situation where the style adds e.g. 2 roads and
> one overlay line
> for the same OSM way and only one road has the tag
> mkgmap:set_unconnected_type=none.
>
> Gerd
>
>
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von
> Felix Hartmann <extremecarver at gmail.com>
> Gesendet: Dienstag, 19. September 2017 09:29:09
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate
> between connected on both sides or on one side only
>
> oh yeah - I remember.
>
> The problem ist neither the old nor the current behaviour works correctly
> in comparison to other tags.
> I complained that it applies to all occurences - even though using continue
> (i only used a line like highway=abc {set mkgmap:set_unconnected_type=none}
> [0x?? road_class=? road_speed=? continue] )
>
> I really think the best solution if strict sticking to rules without []
> block, and respecting continue vs continue with_actions is not possible
> would be to have to different special tags - one removing also all non
> routable overlay lines, while the other tag does not.
> Back then I only used mkgmap_set_unconnected_type=none to remove
> unconnected roads that make autorouting go crazy (it's unconnected -
> someone starts a route there - and the route just breaks - mainly because
> people did not connect the road correctly - and it has nearly invisible
> gaps on both side - which Potlach v1 was a bit famous for) - now the use
> case is more to filter out clutter for the semi_connected so I rather want
> to have it also filter out all overlays. (I'm fine using continue
> with_actions as supposed).
>
> On 19 September 2017 at 08:16, Gerd Petermann <
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com>>
> wrote:
> Well, I just noticed that mkgmap:set_unconnected_type is not yet
> documented.
> When I implemented it with r2599 I decided to remove all overlay lines if
> the road is unconnected and mkgmap:set_unconnected_type=none is used.
> Later, Steve changed this in r2707, the reason was that you complained
> about
> the old behaviour.
> Please read these old threads carefully:
> http://gis.19327.n8.nabble.com/Serious-mkgmap-Bug-set-
> unconnected-type-not-respecting-continue-command-tp5775051.html
> http://gis.19327.n8.nabble.com/Commit-r2707-Don-t-complete-remove-an-
> unconnected-road-tp5777740.html
>
> My understanding of these discussions is that we need is an option or tag
> that controls what to do with an overlay line when the underlying road was
> removed.
>
> Gerd
>
>
> Felix Hartmann-2 wrote
> > But does it mean semi_connected or unconnected? I would like to have both
> > as option if possible.
> >
> > On 18 September 2017 at 21:22, Gerd Petermann <
>
> > gpetermann_muenchen@
>
> >> wrote:
> >
> >> Hi all,
> >>
> >> what do you think about a tag named mkgmap:remove-if-no-road=yes ?
> >> I would add code to check all non-routable lines for this tag.
> >> If no routable line is found for the same OSM way the line is removed.
> >> This check is performed after the processing of the 2
> mkgmap:set_xxx_type
> >> tags
> >> and maybe other routines which remove routable lines because they are
> too
> >> short
> >> etc.
> >>
> >> Gerd
> >>
> >>
> >> Felix Hartmann-2 wrote
> >> > 3. I'm fine with another name - maybe mkgmap:set_semi_connected_
> >> line=none
> >> > and mkgmap:set_unconnected_line=none?
> >> > Well I actually already went through my style and added
> >> > mkgmap:set_semi_connected_type=none - I'm just missing the overlays
> >> also
> >> > being removed as explained to fully use it. I actually had not noticed
> >> > that
> >> > mkgmap:set_unconnected_type=none did not remove all the lines that I
> >> > intended to be removed by it because I never properly checked it using
> >> a
> >> > test file - and there are not many unconnected ways in real OSM data
> >> > (while
> >> > there are far more semi_connected lines/ways). Actually I think it
> >> should
> >> > be semiconnected as we alo use unconnected and not un_connected (even
> >> > though it is two words in proper spelling).
> >>
> >>
> >>
> >>
> >>
> >> --
> >> Sent from:
> >> http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
> >> _______________________________________________
> >> mkgmap-dev mailing list
> >>
>
> > mkgmap-dev at .org
>
> >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >>
> >
> >
> >
> > --
> > Felix Hartman - Openmtbmap.org & VeloMap.org
> > Schusterbergweg 32/8
> > 6020 Innsbruck
> > Austria - Österreich
> >
> > _______________________________________________
> > mkgmap-dev mailing list
>
> > mkgmap-dev at .org
>
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
> Schusterbergweg 32/8
> 6020 Innsbruck
> Austria - Österreich
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20170919/d1413030/attachment-0001.html>