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

Wed Nov 13 16:12:17 GMT 2019

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>
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> 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> im Auftrag von
>> Felix Hartmann <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>> 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>>
>> 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>
>> 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
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20191113/b12a7663/attachment.html>