New subject: mkgmap:set_unconnected_type differentiate between connected on both sides or on one side only

14 Nov 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@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@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@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@hotmail.com<mailto:gpetermann_muenchen@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@lists.mkgmap.org.uk<mailto:
mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
extremecarver@gmail.com<mailto:extremecarver@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@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
...
<mailto:gpetermann_muenchen@hotmail.com<mailto:
gpetermann_muenchen@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@lists.mkgmap.org.uk<mailto:
mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:
mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:
mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <
extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:
extremecarver@gmail.com<mailto:extremecarver@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@gmail.com
<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:
extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:
extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:
extremecarver@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@hotmail.com<mailto:GPetermann_muenchen@hotmail.com
...
<mailto:GPetermann_muenchen@hotmail.com<mailto:
GPetermann_muenchen@hotmail.com>><mailto:GPetermann_muenchen@hotmail.com
<mailto:GPetermann_muenchen@hotmail.com><mailto:
GPetermann_muenchen@hotmail.com<mailto:GPetermann_muenchen@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@lists.mkgmap.org.uk<mailto:
mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:
mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:
mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:
mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:
mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:
mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:
mkgmap-dev-bounces@lists.mkgmap.org.uk>>>> im Auftrag von Felix Hartmann <
extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:
extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:
extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:
extremecarver@gmail.com<mailto:extremecarver@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@gmail.com
<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:
extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:
extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:
extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto:
extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:
extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:
extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:
extremecarver@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@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
...
<mailto:gpetermann_muenchen@hotmail.com<mailto:
gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com><mailto:
gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
...
...
<mailto:gpetermann_muenchen@hotmail.com<mailto:
gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com>><mailto:
gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto:
gpetermann_muenchen@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@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
...
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:
mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:
mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
...
...
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:
mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:
mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:
mkgmap-dev@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@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
...
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:
mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:
mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@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

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

Felix Hartmann

Gerd Petermann

Gerd Petermann

tags

participants (2)