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

Thu Nov 14 16:40:11 GMT 2019

Hi Gerd,
So you mean the only solution would be to change the style-file to the
following in order to have it working?

service=driveway {set mkgmap:set_semi_connected_type=none; set
mkgmap:set_unconnected_type=none} [0x13 road_class=0 road_speed=0
resolution 24 continue with_actions]
service=driveway & mkgmap:set_semi_connected_type=none {delete service;
delete highway; delete access}
service=driveway [0x1040c resolution 24]

But then I guess I would also have to change the other example to:
( service=parking_aisle | service=parkingaisle) {set
mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none}
( service=parking_aisle | service=parkingaisle) &
mkgmap:set_semi_connected_type=none {delete ....}

Felix

On Thu, 14 Nov 2019 at 16:50, Gerd Petermann <
gpetermann_muenchen at hotmail.com> wrote:

> Hi Felix,
>
> sorry, I replied to you instead of the list. In my example containing the
> island detection please replace "a semi-connected" with "an unconnected".
>
> Gerd
>
> ________________________________________
> Von: Gerd Petermann <gpetermann_muenchen at hotmail.com>
> Gesendet: Donnerstag, 14. November 2019 16:46
> An: Felix Hartmann
> Betreff: AW: [mkgmap-dev] mkgmap:set_unconnected_type differentiate
> between connected on both sides or on one side only
>
> Hi Felix,
>
> I think the patch works fine for your examples but not in this case:
> service=driveway {set mkgmap:set_semi_connected_type=none; set
> mkgmap:set_unconnected_type=none} [0x13 road_class=0 road_speed=0
> resolution 24 continue with_actions]
> service=driveway {set mkgmap:set_semi_connected_type=0x1040d; set
> mkgmap:set_unconnected_type=0x1040e} [0x1040c resolution 24]
> The overlay line will always be added  with 0x1040c. I think this is not
> obvious and therefore an error.
>
> I think the idea with a replacement type was similar to the new
> island-detection: reduce img size. For example, with a single line like this
> service=driveway {set mkgmap:set_semi_connected_type=0x1040c; set
> mkgmap:set_unconnected_type=0x1040c} [0x13 road_class=0 road_speed=0
> resolution 24]
> a semi-connected service way would still appear in the map (with 0x1040c)
> but not in NET or NOD while island detection only removes it from NOD.
>
> Regarding the error: The problem gets worse when your style adds the same
> OSM way more than 3 or more times with different values in
> mkgmap:set_unconnected_type, esp. when two or more routable ways are
> added. I think results are more or less unpredictable when you have both a
> "none" and a replacement type.
> Not sure how to handle these special cases.
>
> Gerd
>
> ________________________________________
> Von: Felix Hartmann <extremecarver at gmail.com>
> Gesendet: Donnerstag, 14. November 2019 16:09
> An: Gerd Petermann
> Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate
> between connected on both sides or on one side only
>
> Yes I sometimes use types for unconnected - but only none for
> semi_connected.
>
> And well the situation with continue is a bit complicated, but yes. I
> changed my style so that I can adjust what happens with continue.
>
> e.g:
> service=driveway {set mkgmap:set_semi_connected_type=none; set
> mkgmap:set_unconnected_type=none} [0x13 road_class=0 road_speed=0
> resolution 24 continue with_actions]
> service=driveway {set mkgmap:set_semi_connected_type=none; set
> mkgmap:set_unconnected_type=none} [0x1040c resolution 24]
>
> here both the invisible 0x13 road and the visible 0x1040c is removed.  So
> semi_connected is not only valid for roads but also for simple lines. This
> is a classic example as I feel that driveways clutter the map and don't
> need them for routing if they are semi_connected (because Garmin will route
> to destination with straight line too).
>
> I'm also using it as a general statement however:
> ( service=parking_aisle | service=parkingaisle) {set
> mkgmap:set_semi_connected_type=none; set mkgmap:set_unconnected_type=none}
>
> This overrules later occuring roads and removes them if they are
> semi_connected. And yes in this case overlay lines are supposed to be
> removed to in my understanding.
>
> On Thu, 14 Nov 2019 at 14:19, Gerd Petermann <
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com>>
> wrote:
> Hi Felix,
>
> no idea why you would modify to code instead of using option
> --min-size-polygon=14, so I agree this is not important.
>
> I was surprised to find that there is no documentation about
> mkgmap:set_unconnected_type. I found a lot of confusing posts about the
> expected behaviour, so it's very difficult to guess what it really should
> do. With the additional tag mkgmap:set_semi_connected_type it get's even
> more complicated.
> Since you wrote that the patch worked well for you I think we should just
> document what it does.
>
> The patch was written before option
> --add-boundary-nodes-at-admin-boundaries was implemented.
> A road with a node on a tile boundary is not removed when
> mkgmap:set_unconnected_type=none (or mkgmap:set_semi_connected_type=none)
> is found.
> I think we can ignore nodes on country borders here (like we do with the
> dead-end-check.
>
> My understanding so far, please improve:
> The algorithm first finds out how often a road (one OSM way) is connected
> to other roads. If there are zero connections and
> mkgmap:set_unconnected_type=none  is set, the way is removed (not written
> to the map). If there are other (overlaying) lines for the same OSM way and
> they also have mkgmap:set_unconnected_type=none they are also removed.
> Similar things happen with tag mkgmap:set_semi_connected_type=none for
> roads with exactly one connection to another road.
>
> There is also an option to specify a different type instead of none, e.g.
> mkgmap:set_unconnected_type=0x10804. This type must be a non-routable line
> type. The effect is that the line is not added as a road with the original
> type, instead it is added as normal line with the fiven type when the road
> is not connected to other roads. Similar with
> mkgmap:set_semi_connected_type=0x10804.
> The current patch doesn't care about overlay lines when a replacement type
> is given for the road, means, they are neither removed nor changed. Looks
> wrong to me.
> If I got that right you only use tag values "none" and nobody else uses
> this feature, so I'd prefer to remove the type change. In that case it
> would be better to also rename the tags, e.g.
> mkgmap:remove-unconnected=true and mkgmap:remove_semi_connected=true
>
> Any thoughts?
>
> Gerd
>
>
>
>
>
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>>
> Gesendet: Mittwoch, 13. November 2019 19:29
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate
> between connected on both sides or on one side only
>
> Hi Gerd,
> Nope that's the only one. Until yesterday I think it worked correctly. I
> never really check again in the last 1 year however.  And I do not use
> --housenumber option so far. It's very useful to filter out private ways
> which are not marked access=private - I mainly use it on
> highway=footway/path/track and so on (which should not have housenumbers
> anyhow).
>
> (well and what I hardly call a patch - + minSizePolygon =
> props.getProperty("min-size-polygon", 14);
> value 14 instead of 8. I think 8 is too small in
> src/uk/me/parabola/mkgmap/build/MapBuilder.java
>
> On Wed, 13 Nov 2019 at 19:00, Gerd Petermann <
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com
> ><mailto:gpetermann_muenchen at hotmail.com<mailto:
> gpetermann_muenchen at hotmail.com>>> wrote:
> Hi Felix,
>
> I already wondered where this code has gone. :o
> Hard to say if it is still useful. I probably would not want to use it in
> combination with option --housenumbers.
> I am able to modify the patch. Are there any other patches from me or
> others that you use?
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>>>
> Gesendet: Mittwoch, 13. November 2019 17:12
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate
> between connected on both sides or on one side only
>
> Could semi_con-v3.patch so the semi_connected tag be merged to trunk? It
> was compatible until now and is of really good use. Unfortunately - it
> conflicts with todays mkgmap update.
> Sorry I forgot to answer back in 2017 confirming that it worked splendidly.
>
> Felix
>
> On Thu, 21 Sep 2017 at 15:02, Felix Hartmann <extremecarver at gmail.com
> <mailto:extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>>>> wrote:
> Thanks for v3 - on a quick tryrout it works well now. I have not found
> time (and won't until Tuesday next week) to give it a full check.
> (and yes - I'm right now only using "none").
>
> On 21 September 2017 at 11:56, Gerd Petermann <
> GPetermann_muenchen at hotmail.com<mailto:GPetermann_muenchen at hotmail.com
> ><mailto:GPetermann_muenchen at hotmail.com<mailto:
> GPetermann_muenchen at hotmail.com>><mailto:GPetermann_muenchen at hotmail.com
> <mailto:GPetermann_muenchen at hotmail.com><mailto:
> GPetermann_muenchen at hotmail.com<mailto:GPetermann_muenchen at hotmail.com>>>>
> wrote:
> Hi Felix,
>
> sorry, did not search for a solution for my example, what I wanted to
> point out is that the algo may produce unexpected results whenever the
> style adds multiple lines for one way with conflicting
> mkgmap:set_semi_connected_type values.
>
> In your style you can probably only use value "none". I wonder if anybody
> uses the variant with a value that gives a different type.
>
> Gerd
>
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>>>> im Auftrag von Felix Hartmann <
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>>>>
> Gesendet: Donnerstag, 21. September 2017 11:16
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate
> between connected on both sides or on one side only
>
> As for your example - yes I guess only changing first occurence to 0x* -
> further occurences to none makes most sense. In general I think such a rule
> should not be used.
>
> So good practice would be either:
> highway=service & service=driveway {set
> mkgmap:set_semi_connected_type=none}
> highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue]
> highway=service & oneway=yes [0x10106 resolution 24]
>
> or
> highway=service & service=driveway {set
> mkgmap:set_semi_connected_type=0x10806} [0x07 road_class=0 road_speed=2
> resolution 22 continue]
> highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue]
> highway=service & oneway=yes [0x10106 resolution 24]
>
> or
> highway=service & service=driveway {set
> mkgmap:set_semi_connected_type=0x10806}
> highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue]
> highway=service & service=driveway {set
> mkgmap:set_semi_connected_type=0x10806}
> highway=service & oneway=yes [0x10106 resolution 24]
>
> but not your example and also not:
> highway=service & service=driveway {set
> mkgmap:set_semi_connected_type=0x10806} [0x07 road_class=0 road_speed=2
> resolution 22 continue with_actions]
> highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue]
> highway=service & oneway=yes [0x10106 resolution 24]
>
>
>
> On 21 September 2017 at 11:10, Felix Hartmann <extremecarver at gmail.com
> <mailto:extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>>>>> wrote:
> Somthing seems to be wrong with the patch:
>
> java.lang.NullPointerException
>         at
> uk.me.parabola.mkgmap.osmstyle.StyledConverter.findUnconnectedRoads(StyledConverter.java:1970)
>         at
> uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:605)
>         at
> uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:243)
>         at
> uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:157)
>         at
> uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:154)
>         at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:52)
>         at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:263)
>         at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:259)
>         at java.util.concurrent.FutureTask.run(Unknown Source)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
> Source)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> Source)
>         at java.lang.Thread.run(Unknown Source)
> Could Not Find C:\OpenMTBMap\maps\ovm_6431*.img
>
> On 19 September 2017 at 15:53, Gerd Petermann <
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com
> ><mailto:gpetermann_muenchen at hotmail.com<mailto:
> gpetermann_muenchen at hotmail.com>><mailto:gpetermann_muenchen at hotmail.com
> <mailto:gpetermann_muenchen at hotmail.com><mailto:
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com
> >>><mailto:gpetermann_muenchen at hotmail.com<mailto:
> gpetermann_muenchen at hotmail.com><mailto:gpetermann_muenchen at hotmail.com
> <mailto:gpetermann_muenchen at hotmail.com>><mailto:
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com
> ><mailto:gpetermann_muenchen at hotmail.com<mailto:
> gpetermann_muenchen at hotmail.com>>>>> wrote:
> Attached is v2 of the patch. It implements the removal of overlay lines
> when
> mkgmap:set_unconnected_type=none or mkgmap:set_semi_connected_type=none was
> found.
>
> I am still not sure what should be done if the tag has a value that gives
> another type instead of none.
> Assume your style uses
> highway=service & service=driveway {set
> mkgmap:set_semi_connected_type=0x10806}
> highway=service [0x07 road_class=0 road_speed=2 resolution 22 continue]
> highway=service & oneway=yes [0x10106 resolution 24]
>
> What would you expect for a semi connected way?
> We have 2 lines, the first is changed from 0x07 to 0x10806. It would not
> make much sense to change also the 2nd from 0x10106  to 0x10806.
> So, for now only the value none has an effect for the overlay line(s).
>
> semi_con-v2.patch
> <http://gis.19327.n8.nabble.com/file/t318326/semi_con-v2.patch>
>
> Gerd
>
>
> Felix Hartmann-2 wrote
> > That sounds good
> >
> > On Sep 19, 2017 11:23 AM, "Gerd Petermann" <
>
> > gpetermann_muenchen@
>
> > >
> > wrote:
> >
> >> Hi Felix,
> >>
> >> Felix Hartmann-2 wrote
> >> > 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).
> >>
> >> OK, I think I can change the code so that it stores the information
> >> whether
> >> or not a road
> >> is connected (or "semi-connected") once for each OSM way that is at
> least
> >> added once as a road.
> >> In a further step mkgmap would check each line for the existence of the
> >> mkgmap:set_unconnected_type tag and check if the corresponding OSM way
> is
> >> connected or not.
>
>
>
>
>
> --
> 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
> ><mailto:mkgmap-dev at lists.mkgmap.org.uk<mailto:
> mkgmap-dev at lists.mkgmap.org.uk>><mailto:mkgmap-dev at lists.mkgmap.org.uk
> <mailto:mkgmap-dev at lists.mkgmap.org.uk><mailto:
> mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk
> >>><mailto:mkgmap-dev at lists.mkgmap.org.uk<mailto:
> mkgmap-dev at lists.mkgmap.org.uk><mailto:mkgmap-dev at lists.mkgmap.org.uk
> <mailto:mkgmap-dev at lists.mkgmap.org.uk>><mailto:
> mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk
> ><mailto: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
>
>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
> Schusterbergweg 32/8
> 6020 Innsbruck
> Austria - Österreich
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk
> ><mailto:mkgmap-dev at lists.mkgmap.org.uk<mailto:
> mkgmap-dev at lists.mkgmap.org.uk>><mailto:mkgmap-dev at lists.mkgmap.org.uk
> <mailto:mkgmap-dev at lists.mkgmap.org.uk><mailto:
> 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
>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
> Schusterbergweg 32/8
> 6020 Innsbruck
> Austria - Österreich
>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
> Schusterbergweg 32/8
> 6020 Innsbruck
> Austria - Österreich
>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
> Schusterbergweg 32/8
> 6020 Innsbruck
> Austria - Österreich
>

-- 
Felix Hartman - Openmtbmap.org & VeloMap.org
Schusterbergweg 32/8
6020 Innsbruck
Austria - Österreich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20191114/255b970a/attachment-0001.html>