<div dir="ltr"><div><div><div>Hi Gerd,<br><br></div>2. yes it's the case for both tags.<br></div>3. I'm fine with another name - maybe mkgmap:set_semi_connected_line=none and mkgmap:set_unconnected_line=none?<br></div>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).<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 18 September 2017 at 19:49, Gerd Petermann <span dir="ltr"><<a href="mailto:gpetermann_muenchen@hotmail.com" target="_blank">gpetermann_muenchen@hotmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Felix,<br>
<br>
1) the tag mkgmap:set_semi_connected_type is only special because it starts<br>
with the mkgmap: prefix, within the style processing it is treated like any<br>
other tag. The tag is first evaluated by mkgmap after all<br>
elements where processed by the style.<br>
2) I agree that the new function doesn't work well for a style that creates<br>
multiple lines for a single<br>
OSM way. I also think that this is the case with<br>
mkgmap:set_unconnected_type.<br>
3) You suggested to implement the new tag similar to<br>
mkgmap:set_unconnected_type, but<br>
it seems you never used it?<br>
<br>
It is easy to change the code so that it removes an overlay line when there<br>
is no routable line for the same OSM way. I have already coded this on my<br>
system. I can change the code to check if also the<br>
overlay line has a special tag, I just don't like the idea that<br>
mkgmap:set_unconnected_type or<br>
mkgmap:set_semi_connected_type should be used for this.<br>
<br>
Gerd<br>
<br>
<br>
Felix Hartmann-2 wrote<br>
<div><div class="h5">> thanks for the clarification.<br>
><br>
> Well in my opinion the algo should treat it as close as similar as<br>
> possible<br>
> to normal tags.<br>
><br>
> x=* {set mkgmap:set_semi_connected_<wbr>type=*}<br>
> as above without [] ---> applies to all objects that follow. also okay if<br>
> due to the special way it applies simply to all objects no matter if<br>
> before<br>
> or after<br>
><br>
> x=* {set mkgmap:set_semi_connected_<wbr>type=*} [0x01 road-class.. continue<br>
> with_actions]<br>
> same as above<br>
><br>
> x=* {set mkgmap:set_semi_connected_<wbr>type=*} [0x01 road-class.. continue]<br>
> only apply to the object created<br>
><br>
> x=* {set mkgmap:set_semi_connected_<wbr>type=*} [0x01 road-class]<br>
> only apply to the object created<br>
><br>
><br>
> The problem is simply that we don't have enough routable types - so many<br>
> styles use an invisible routable line overlaid with the visible line of<br>
> the<br>
> road/street - so both should be removed. Or take a bridge - if you decide<br>
> to not show the road for that semi_connected_bridge - you may also want to<br>
> not show the bridge.<br>
> I don't need this for fully non routable lines - but manybe other people<br>
> see sense in also applying the semi_connected or unconnected tags to fully<br>
> non routable objects.<br>
><br>
> E.g. stairs - maybe someone does not want them to be routable in his map -<br>
> but only show them if they are connected to a routable way. Right now<br>
> that's not possible. Same maybe for ferry lines, gondolas or public<br>
> transport platforms.<br>
><br>
> And yes - if it were possible to use it as a standard tag instaed of the<br>
> special tag - even better. I thought that was not possible due to the way<br>
> the tag works. Right now it definitely is a bit confusing as it's more or<br>
> less the only tag that works differently.<br>
><br>
> On 18 September 2017 at 08:11, Gerd Petermann <<br>
<br>
> GPetermann_muenchen@<br>
<br>
</div></div><div><div class="h5">>> wrote:<br>
><br>
>> Hi Felix,<br>
>><br>
>> sorry, was too fast. The algo counts each OSM way only once, so I think<br>
>> regarding the routable ways it works fine. The algo is simply not used<br>
>> for<br>
>> non-routable ines.<br>
>> If I got you right you also want that the overlaying non-routable line is<br>
>> removed when it has mkgmap:set_semi_connected_<wbr>type=none ?<br>
>><br>
>> What should happen if the style adds the same OSM way multiple times as<br>
>> routable line, sometimes with  mkgmap:set_semi_connected_<wbr>type=none ,<br>
>> sometimes without?<br>
>> Or with different values for the tag mkgmap:set_semi_connected_<wbr>type?<br>
>> What would be the meaning of mkgmap:set_semi_connected_<wbr>type=0x10806 for<br>
>> such an overlay line?<br>
>><br>
>> Sounds too complex for me.<br>
>><br>
>> I think we need a different logic here. My understanding is that you only<br>
>> want the non-routable overlay line(s) if at least one routable line was<br>
>> created for the same OSM way.<br>
>> So, we need a method to tell mkgmap that a given non-routable line should<br>
>> be ignored if no routable way line exists for the same OSM way.<br>
>> I think we should not use the special tags mkgmap:set_semi_connected_type<br>
>> or mkgmap:set_unconnected_type for this.<br>
>> Do you agree?<br>
>><br>
>> Gerd<br>
>> ______________________________<wbr>__________<br>
>> Von: Gerd Petermann<br>
>> Gesendet: Montag, 18. September 2017 06:47:12<br>
>> An: Development list for mkgmap<br>
>> Betreff: AW: [mkgmap-dev] mkgmap:set_unconnected_type differentiate<br>
>> between connected on both sides or on one side only<br>
>><br>
>> Hi Felix,<br>
>><br>
>> yes, you are right, when you create two or more routable lines from the<br>
>> same OSM way the algo counts them as connected on each point.<br>
>> I'll try catch this special case with a new patch.<br>
>><br>
>> Gerd<br>
>> ______________________________<wbr>__________<br>
>> Von: mkgmap-dev <<br>
<br>
</div></div>> mkgmap-dev-bounces@.org<br>
<span class=""><br>
> > im Auftrag von<br>
>> Felix Hartmann <<br>
<br>
> extremecarver@<br>
<br>
> ><br>
</span><div><div class="h5">>> Gesendet: Sonntag, 17. September 2017 23:19:27<br>
>> An: Development list for mkgmap<br>
>> Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate<br>
>> between connected on both sides or on one side only<br>
>><br>
>> well no - I did not want to use continue_with_actions - I mean that<br>
>> special tag is already set before - even If I set it on the line itself<br>
>> it<br>
>> seems to have no effect.<br>
>><br>
>> The tag once set should apply to all iterations created by continue of<br>
>> the<br>
>> way, not just to the first (if set in a rule without action).<br>
>> Only if set in the same rule using continue alone it should make a<br>
>> difference vs continue_with_actions - so this is clearly not the intended<br>
>> behavior right now.<br>
>><br>
>><br>
>> Addendum:<br>
>> I just tested using continue with_actions --- same problem. The second<br>
>> line is not type=non but simply processed. Maybe the filter thinks it is<br>
>> connected to it's underlying original line?<br>
>><br>
>><br>
>> In my understanding the special tag should be worked down for the<br>
>> overlying lines exactly like the underlying lines (I use continue often<br>
>> 3-4<br>
>> times on the same way - this case it's only matching once). Normal tags<br>
>> will also be evaluated for overlying ways.<br>
>><br>
>><br>
>> On 17 September 2017 at 22:56, Gerd Petermann <<br>
>><br>
<br>
> GPetermann_muenchen@<br>
<br>
</div></div>> <mailto:<br>
<br>
> GPetermann_muenchen@<br>
<span class=""><br>
> >><br>
>> wrote:<br>
>> Hi Felix,<br>
>><br>
>> I think you wanted to use continue with_actions ?<br>
>> Besides that the special tags have no effect on the overlay lines .<br>
>><br>
>> Gerd<br>
>> ______________________________<wbr>__________<br>
>> Von: mkgmap-dev <<br>
<br>
</span>> mkgmap-dev-bounces@.org<br>
<br>
> <mailto:<a href="mailto:mkgmap-">mkgmap-</a><br>
> ><br>
<br>
> dev-bounces@.org<br>
<span class=""><br>
>>> im Auftrag von Felix Hartmann <<br>
>><br>
<br>
> extremecarver@<br>
<br>
</span>> <mailto:<br>
<br>
> extremecarver@<br>
<div><div class="h5"><br>
> >><br>
>> Gesendet: Sonntag, 17. September 2017 22:13<br>
>> An: Development list for mkgmap<br>
>> Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate<br>
>> between connected on both sides or on one side only<br>
>><br>
>> Hi Gerd,<br>
>> sorry I should have tested better. Ì actually just inserted the rules<br>
>> into<br>
>> my normal ruleset and only used a clean lines file with example c) after<br>
>> noticing nothings seems to work - should have done that for b) too. So it<br>
>> seems there is some problem with continue following this statement!<br>
>> My testfile an the following lines file:<br>
>><br>
>> service=driveway & ( highway=service | highway=track | highway=path |<br>
>> highway=footway | highway=residential ) & access!=yes &<br>
>> access!=designated<br>
>> & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no |<br>
>> vehicle=private | vehicle!=* ) & foot!=private & foot!=yes &<br>
>> foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* &<br>
>> mtb:scale!=*   {set mkgmap:set_semi_connected_<wbr>type=none; set<br>
>> mkgmap:set_unconnected_type=<wbr>none}<br>
>> service=driveway {set mkgmap:set_unconnected_type=<wbr>none}     [0x13<br>
>> road_class=0 road_speed=0 resolution 24 continue]<br>
>> service=driveway                                            [0x1040c<br>
>> resolution 24]<br>
>><br>
>> leads to:<br>
>> unconnected driveway, as well as semi_connected driveway both ending up<br>
>> in<br>
>> the map as 0x1040c. However the first 0x13 road is not in the map<br>
>> (neither<br>
>> unconnected, nor semi_connected).<br>
>> So it seems like after the continue command the previous (1. line of<br>
>> rules) ruleset is simply ignored.<br>
>> And yes - my testfile was intentional designed this way because I wanted<br>
>> to test out if roads being joined could change something.<br>
>><br>
>><br>
>> Changing the lines file to:<br>
>> service=driveway & ( highway=service | highway=track | highway=path |<br>
>> highway=footway | highway=residential ) & access!=yes &<br>
>> access!=designated<br>
>> & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no |<br>
>> vehicle=private | vehicle!=* ) & foot!=private & foot!=yes &<br>
>> foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* &<br>
>> mtb:scale!=*   {set mkgmap:set_semi_connected_<wbr>type=none; set<br>
>> mkgmap:set_unconnected_type=<wbr>none}<br>
>> service=driveway   [0x13 road_class=0 road_speed=0 resolution 24<br>
>> continue]<br>
>> service=driveway   [0x1040c resolution 24]<br>
>><br>
>> leads to:<br>
>> same result.<br>
>><br>
>> even this:<br>
>> service=driveway & ( highway=service | highway=track | highway=path |<br>
>> highway=footway | highway=residential ) & access!=yes &<br>
>> access!=designated<br>
>> & ( bicycle=no | bicycle=private | bicycle!=* ) & ( vehicle=no |<br>
>> vehicle=private | vehicle!=* ) & foot!=private & foot!=yes &<br>
>> foot!=designated & bicycle!=designated & bicycle!=yes & sac_scale!=* &<br>
>> mtb:scale!=*   {set mkgmap:set_semi_connected_<wbr>type=none; set<br>
>> mkgmap:set_unconnected_type=<wbr>none}<br>
>> service=driveway {set mkgmap:set_unconnected_type=<wbr>none}     [0x13<br>
>> road_class=0 road_speed=0 resolution 24 continue]<br>
>> service=driveway   {set mkgmap:set_unconnected_type=<wbr>none}<br>
>>                            [0x1040c resolution 24]<br>
>><br>
>> leads to the 0x1040c line still being present in the final map. So the<br>
>> continue statement somehow havocs both the mkgmap:set_unconnected_type as<br>
>> well as the mkgmap:set_semi_connected_tye.<br>
>><br>
>> Felix<br>
>><br>
>> On 17 September 2017 at 19:52, Gerd Petermann <<br>
>><br>
<br>
> GPetermann_muenchen@<br>
<br>
</div></div>> <mailto:<br>
<br>
> GPetermann_muenchen@<br>
<br>
> > ><mailto:<br>
<br>
> GPetermann_muenchen@<br>
<br>
> <mailto:<a href="mailto:GPetermann_muenchen@">GPetermann_muenchen@</a><br>
<span class="">> > <a href="http://hotmail.com" rel="noreferrer" target="_blank">hotmail.com</a>>>> wrote:<br>
>> Hi Felix,<br>
>><br>
>> just in case it is not yet obvious:<br>
>> Some ways in your test data have  highway=path but no service=driveway.<br>
>> Your rules don't add a road for it, so you probably don't get what you<br>
>> expect from the patch.<br>
>><br>
>> Gerd<br>
>> ______________________________<wbr>__________<br>
>> Von: Gerd Petermann<br>
>> Gesendet: Sonntag, 17. September 2017 19:39:02<br>
>> An: Development list for mkgmap<br>
>> Betreff: AW: [mkgmap-dev] mkgmap:set_unconnected_type differentiate<br>
>> between connected on both sides or on one side only<br>
>><br>
>> Hi Felix,<br>
>><br>
>> I see the same result for b) and c) despite that one uses 0x01 and the<br>
>> other 0x13.<br>
>><br>
>> Gerd<br>
>> ______________________________<wbr>__________<br>
>> Von: mkgmap-dev <<br>
<br>
</span>> mkgmap-dev-bounces@.org<br>
<br>
> <mailto:<a href="mailto:mkgmap-">mkgmap-</a><br>
> ><br>
<br>
> dev-bounces@.org<br>
<br>
>><mailto:<a href="mailto:mkgmap-dev-bounces@">mkgmap-dev-bounces@</a><br>
> > <a href="http://lists.mkgmap.org.uk" rel="noreferrer" target="_blank">lists.mkgmap.org.uk</a><mailto:<br>
<br>
> mkgmap-dev-bounces@.org<br>
<span class=""><br>
> >>> im<br>
>> Auftrag von Felix Hartmann <<br>
<br>
> extremecarver@<br>
<br>
</span>> <mailto:<br>
> ><br>
<br>
> extremecarver@<br>
<br>
>><mailto:<br>
<br>
> extremecarver@<br>
<br>
> <mailto:<br>
> ><br>
<br>
> extremecarver@<br>
<span class=""><br>
>>>><br>
>> Gesendet: Sonntag, 17. September 2017 18:40:14<br>
>> An: Development list for mkgmap<br>
>> Betreff: Re: [mkgmap-dev] mkgmap:set_unconnected_type differentiate<br>
>> between connected on both sides or on one side only<br>
>><br>
>> only 24% of service=driveway have access tagging (mostly access=private)<br>
>> -<br>
>> however I guess 99% of those that are semi-connected and 99.99% that are<br>
>> unconnected are really not needed in a general map (no matter if they are<br>
>> private or not) - however you just cannot drop all service=driveways<br>
>> without access tags except for an automotive map as that often leads to<br>
>> missing important connectors and thereby big detours.<br>
>><br>
>><br>
>> also it could be worth a try if long distance autorouting worked better<br>
>> if<br>
>> a general rule in the finalize section or further in front like<br>
>> highway=* & mkgmap:semi_connected=yes {road_class='-2' road_speed='-2'}<br>
>> (or try with '-1') could improve routing results. But maybe they are<br>
>> penalized by the garmin algorithm already enough anyhow. Now that rule<br>
>> really won't work with the current way it works - and I don't even know<br>
>> it<br>
>> will help. It's just something,that i would try out if it were possible.<br>
>><br>
>> On 17 September 2017 at 18:26, Felix Hartmann <<br>
<br>
> extremecarver@<br>
<br>
> <<br>
</span>> > mailto:<br>
<br>
> extremecarver@<br>
<br>
>><mailto:<br>
<br>
> extremecarver@<br>
<br>
> <mailto:<br>
> ><br>
<br>
> extremecarver@<br>
<br>
>>><mailto:<br>
<br>
> extremecarver@<br>
<br>
> <mailto:<a href="mailto:extremecar">extremecar</a><br>
> ><br>
<br>
> ver@<br>
<br>
>><mailto:<br>
<br>
> extremecarver@<br>
<br>
> <mailto:<a href="mailto:extreme">extreme</a><br>
> ><br>
<br>
> carver@<br>
<span class=""><br>
>>>>> wrote:<br>
>> b) did not work when I tried it. I have a test file here (very simple):<br>
>> <a href="https://openmtbmap.org/wp-content/images/debug/driveways.osm" rel="noreferrer" target="_blank">https://openmtbmap.org/wp-<wbr>content/images/debug/<wbr>driveways.osm</a><br>
>><br>
>><br>
>> oh yeah the idea why semi_connected is needed camp up because many<br>
>> (mainly<br>
>> highway=service & service=driveway  and no other tags )in France and<br>
>> Switzerland are actually needed to get from roads for cars onto<br>
>> pathes/tracks. Often through a supermarket parking or similar while<br>
>> highway=service & service=driveway (likewise with no other tag) but<br>
>> mostly<br>
>> connected only on one side to public roads - are used to map ways to<br>
>> access<br>
>> a private house door or garden - they really clutter up the map hence I<br>
>> want to remove them. And yes - sadly far too little driveways add a<br>
>> foot=yes or foot=designated, or access=yes/access=designated while also<br>
>> far<br>
>> too many really private ways lack a access=private. Some people in OSM<br>
>> understand that service=driveway means it public without other tags,<br>
>> while<br>
>> others understand that it's private.<br>
>><br>
>> On 17 September 2017 at 18:14, Felix Hartmann <<br>
<br>
> extremecarver@<br>
<br>
> <<br>
</span>> > mailto:<br>
<br>
> extremecarver@<br>
<br>
>><mailto:<br>
<br>
> extremecarver@<br>
<br>
> <mailto:<br>
> ><br>
<br>
> extremecarver@<br>
<br>
>>><mailto:<br>
<br>
> extremecarver@<br>
<br>
> <mailto:<a href="mailto:extremecar">extremecar</a><br>
> ><br>
<br>
> ver@<br>
<br>
>><mailto:<br>
<br>
> extremecarver@<br>
<br>
> <mailto:<a href="mailto:extreme">extreme</a><br>
> ><br>
<br>
> carver@<br>
<span class=""><br>
>>>>> wrote:<br>
>> I've seen a couple - but yes - according to taginfo it's really little,<br>
>> <a href="https://taginfo.openstreetmap.org/tags/service=driveway" rel="noreferrer" target="_blank">https://taginfo.openstreetmap.<wbr>org/tags/service=driveway</a><br>
>> (most are highway=service, then residential and others are really really<br>
>> little).<br>
>><br>
>><br>
>> do you think you can change the behavior that b) will also work? If not<br>
>> I'm just going to rewrite my rules for highway=service - and drop the<br>
>> idea<br>
>> to get rid of track,residential, footway and path with service=driveway<br>
>> tag<br>
>> (and hope this does not change in future).<br>
>> All other things that are specified in {} brackets also work like b) -<br>
>> that's why I thought it should work that way too.<br>
>><br>
>><br>
>> Another possibility would be if it could be added to the finalize section<br>
>> instead. So have in finalize section<br>
>> ( highway=service | highway=track | highway=path | highway=footway |<br>
>> highway=residential ) & service=driveway  {set<br>
>> mkgmap:set_semi_connected_<wbr>type=none;<br>
>> set mkgmap:set_unconnected_type=<wbr>none}<br>
>> which would then overrule rules given higher up.<br>
>> (I did not try if this will work already - but I guess not).<br>
>><br>
>> On 17 September 2017 at 17:33, nwillink <<br>
<br>
</span>> osm@.co<br>
<br>
> <mailto:<a href="mailto:osm@">osm@</a><br>
> > <a href="http://pinns.co.uk" rel="noreferrer" target="_blank">pinns.co.uk</a>><mailto:<br>
<br>
> osm@.co<br>
<br>
> <mailto:<br>
<br>
> osm@.co<br>
<br>
> >><br>
> <mailto:<br>
>><br>
><br>
<br>
> osm@.co<br>
<br>
> <mailto:<br>
<br>
> osm@.co<br>
<br>
> ><mailto:<br>
<br>
> osm@.co<br>
<br>
> <mailto:<br>
> ><br>
<br>
> osm@.co<br>
<span class=""><br>
>>>>> wrote:<br>
>> Hi Gerd<br>
>><br>
>> In the UK , frequently public footpaths are linked to someone's driveway<br>
>> -<br>
>> I<br>
>> have to say it's often quite 'daunting' to walk up someone's drive in<br>
>> order<br>
>> to continue along a public footpath.<br>
>><br>
>> r<br>
>><br>
>> Nick<br>
>><br>
>><br>
>><br>
>> --<br>
>> Sent from:<br>
>> <a href="http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html" rel="noreferrer" target="_blank">http://gis.19327.n8.nabble.<wbr>com/Mkgmap-Development-<wbr>f5324443.html</a><br>
>> ______________________________<wbr>_________________<br>
>> mkgmap-dev mailing list<br>
>><br>
<br>
</span>> mkgmap-dev@.org<br>
<br>
> <mailto:<br>
<br>
> mkgmap-dev@.org<br>
<br>
> > ><mailto:<br>
<br>
> mkgmap-dev@.org<br>
<br>
> <mailto:<a href="mailto:mkgmap-dev@lists">mkgmap-dev@lists</a>.<br>
> > <a href="http://mkgmap.org.uk" rel="noreferrer" target="_blank">mkgmap.org.uk</a>>><mailto:<br>
<br>
> mkgmap-dev@.org<br>
<br>
> <mailto:<br>
> ><br>
<br>
> mkgmap-dev@.org<br>
<br>
>><mailto:<br>
<br>
> mkgmap-dev@.org<br>
<br>
> <<br>
> > mailto:<br>
<br>
> mkgmap-dev@.org<br>
<span class=""><br>
>>>><br>
>> <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" rel="noreferrer" target="_blank">http://www.mkgmap.org.uk/<wbr>mailman/listinfo/mkgmap-dev</a><br>
>><br>
>><br>
>><br>
>> --<br>
>> Felix Hartman - Openmtbmap.org & VeloMap.org<br>
>> Schusterbergweg 32/8<br>
>> 6020 Innsbruck<br>
>> Austria - Österreich<br>
>><br>
>><br>
>><br>
>> --<br>
>> Felix Hartman - Openmtbmap.org & VeloMap.org<br>
>> Schusterbergweg 32/8<br>
>> 6020 Innsbruck<br>
>> Austria - Österreich<br>
>><br>
>><br>
>><br>
>> --<br>
>> Felix Hartman - Openmtbmap.org & VeloMap.org<br>
>> Schusterbergweg 32/8<br>
>> 6020 Innsbruck<br>
>> Austria - Österreich<br>
>> ______________________________<wbr>_________________<br>
>> mkgmap-dev mailing list<br>
>><br>
<br>
</span>> mkgmap-dev@.org<br>
<br>
> <mailto:<br>
<br>
> mkgmap-dev@.org<br>
<br>
> > ><mailto:<br>
<br>
> mkgmap-dev@.org<br>
<br>
> <mailto:<a href="mailto:mkgmap-dev@lists">mkgmap-dev@lists</a>.<br>
<span class="">> > <a href="http://mkgmap.org.uk" rel="noreferrer" target="_blank">mkgmap.org.uk</a>>><br>
>> <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" rel="noreferrer" target="_blank">http://www.mkgmap.org.uk/<wbr>mailman/listinfo/mkgmap-dev</a><br>
>><br>
>><br>
>><br>
>> --<br>
>> Felix Hartman - Openmtbmap.org & VeloMap.org<br>
>> Schusterbergweg 32/8<br>
>> 6020 Innsbruck<br>
>> Austria - Österreich<br>
>> ______________________________<wbr>_________________<br>
>> mkgmap-dev mailing list<br>
>><br>
<br>
</span>> mkgmap-dev@.org<br>
<br>
> <mailto:<br>
<br>
> mkgmap-dev@.org<br>
<span class=""><br>
> ><br>
>> <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" rel="noreferrer" target="_blank">http://www.mkgmap.org.uk/<wbr>mailman/listinfo/mkgmap-dev</a><br>
>><br>
>><br>
>><br>
>> --<br>
>> Felix Hartman - Openmtbmap.org & VeloMap.org<br>
>> Schusterbergweg 32/8<br>
>> 6020 Innsbruck<br>
>> Austria - Österreich<br>
>> ______________________________<wbr>_________________<br>
>> mkgmap-dev mailing list<br>
>><br>
<br>
</span>> mkgmap-dev@.org<br>
<span class=""><br>
>> <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" rel="noreferrer" target="_blank">http://www.mkgmap.org.uk/<wbr>mailman/listinfo/mkgmap-dev</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> Felix Hartman - Openmtbmap.org & VeloMap.org<br>
> Schusterbergweg 32/8<br>
> 6020 Innsbruck<br>
> Austria - Österreich<br>
><br>
> ______________________________<wbr>_________________<br>
> mkgmap-dev mailing list<br>
<br>
</span>> mkgmap-dev@.org<br>
<br>
> <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" rel="noreferrer" target="_blank">http://www.mkgmap.org.uk/<wbr>mailman/listinfo/mkgmap-dev</a><br>
<span class=""><br>
<br>
<br>
<br>
<br>
--<br>
Sent from: <a href="http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html" rel="noreferrer" target="_blank">http://gis.19327.n8.nabble.<wbr>com/Mkgmap-Development-<wbr>f5324443.html</a><br>
______________________________<wbr>_________________<br>
mkgmap-dev mailing list<br>
<a href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-dev@lists.mkgmap.org.uk</a><br>
</span><a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" rel="noreferrer" target="_blank">http://www.mkgmap.org.uk/<wbr>mailman/listinfo/mkgmap-dev</a></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div><div>Felix Hartman - Openmtbmap.org & VeloMap.org<br></div>Schusterbergweg 32/8<br></div><div>6020 Innsbruck<br></div></div>Austria - Österreich</div></div></div></div>
</div>