Re: [mkgmap-dev] Question on routing difference

[N Willink]

Hi Minco


Thanks for your suggestion of using the toll option.

On my Fenix, this option is not available but instead I have used 
'ferry' as a tag and this seems to work!



r


Nick

On 07/06/2022 15:16, lig fietser wrote:

Harri,
Thats why I use on my Openfietsmap not routable lines for highways 
with bicycle=no.
I misuse the avoidance of toll roads to force the routing to take 
cycle routes only.
In my scripts I retag all highways that are not part of a cycle route 
relation with toll=yes,

and all cycle routes with toll=no
I also "upgrade" cycleways and lower classified roads, but this comes 
indeed with a penalty of

slow or even impossible route calculations.

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question on routing difference

[Bernhard Hiller]

Hi all,
we had some discussions on the weirdness of Garmin's routing algorithm
in the past.

In August 2014, I described an example, and popej could give a good
explanation:
https://www.mkgmap.org.uk/pipermail/mkgmap-dev/2014q3/thread.html#21825

Beyond that, "newer" Garmin outdoor devices (ehm, my Oregon is from
2013) have "activity routing" which causes odd artifacts even when you
think that you do not use it: it may send a car to a cycleway parallel
to a primary road. or a bicycle onto a motorway. Hence the trick by
ligfietser to use non-routable lines for non-cyclable ways is important.
Perhaps you can find the messages some where on the forum
https://forum.openstreetmap.org/

Regards,
Bernhard

Am 07.06.2022 um 16:16 schrieb lig fietser:

Harri,
Thats why I use on my Openfietsmap not routable lines for highways
with bicycle=no.
I misuse the avoidance of toll roads to force the routing to take
cycle routes only.
In my scripts I retag all highways that are not part of a cycle route
relation with toll=yes,
and all cycle routes with toll=no
I also "upgrade" cycleways and lower classified roads, but this comes
indeed with a penalty of
slow or even impossible route calculations.


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question on routing difference

[lig fietser]

Harri,
Thats why I use on my Openfietsmap not routable lines for highways with 
bicycle=no.
I misuse the avoidance of toll roads to force the routing to take cycle routes 
only.
In my scripts I retag all highways that are not part of a cycle route relation 
with toll=yes,
and all cycle routes with toll=no
I also "upgrade" cycleways and lower classified roads, but this comes indeed 
with a penalty of
slow or even impossible route calculations.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question on routing difference

[Harri Suomalainen]

Garmin routing seems to be like it uses only major roads (based on route 
class) to figure out any longer routes and uses small roads only in the 
beginning and end to get to the larger routes.


This is a pain in bicycle routing because it can direct to large roads 
even when wanted. It seems if there is no valid route, garmin uses what 
is has. It can direct bicycle to a bicycle=no road like a major trunk or 
motorway. (That is at least how my cycling garmin devices definately 
work, even in cycle mode).


If you increase road class of smaller roads, they get taken into account 
too. But the route calculation and recalculation can be VERY long. When 
I tried elevating cycleways to similar class with motorways, a 17km 
route took on some earlier devices something like 20mins to 
calculate/recalculate the route.


I've never tried toll roads. Petrhaps I could misuse that in my style to 
make large roads that bicycle is not allowed to be "toll" and make 
garmin avoid them better. This message gave me an idea to try out. I've 
no idea how well that would work as there are practically no toll roads 
where I live.


On 5/29/22 5:17 PM, Gerd Petermann wrote:

Hi jan,

maybe my routing profile for OFM bike is different?

Not sure what Minko recommends today. Mine says "Faster Time", Standard  Elevation Mode, 
only road type avoidance is for "Roll  Roads".
When I remove the toll roads avoidance the route is different and follows the 
major road.

Gerd



Von: mkgmap-dev  im Auftrag von jan meisters 

Gesendet: Sonntag, 29. Mai 2022 16:07
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Question on routing difference

Hi Gerd,

here OFM lite gives the same unwanted result as OFM full :-(

Jan


Am 29.05.2022 um 14:54 schrieb Gerd Petermann :

Hi Jan,

the artifical way would be a highway=residential, not path. Anyhow, I tried to 
reproduce the different routing results with the mentioned change in the OFM 
lite style
but found no difference, the wanted route is calculated for both versions.

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Sonntag, 29. Mai 2022 14:10
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Question on routing difference

Hi Jan,

not sure if you would find it with that id, since it would be an artificial 
way. Don't have time now, will look into this later.

Gerd


Von: mkgmap-dev  im Auftrag von jan meisters 

Gesendet: Sonntag, 29. Mai 2022 14:07
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Question on routing difference

Hi Gerd,

do you mean another routable line?
All (routable) highways are echotagged in my style atm, but I can´t find 
27463238 twice.

Jan



Am 29.05.2022 um 09:16 schrieb Gerd Petermann :

Hi Jan,

might be the oneway:bicycle=no on way 27463238 which can create an additional 
path in the opposite direction.

Gerd


Von: mkgmap-dev  im Auftrag von jan meisters 

Gesendet: Samstag, 28. Mai 2022 20:15
An: Development list for mkgmap
Betreff: [mkgmap-dev] Question on routing difference

Hi all,

I´m using an altered copy of the OFM style and therefore sometimes compare the 
results.
One routing difference I found I was able to lead back, but the cause I don´t 
understand at all.

My test-route should prefer the small residential „Altengabengäßchen“ over the 
primary „Viktoriastrasse“.
Latest OFM does, my version not since I removed {add bicycle=yes} from this 
line:
highway=path & surface ~ '(paved|asphalt|sett|concrete|paving_stones|paving_stones:30)' 
& access!=no & access!=private & vehicle!=no { set highway=pedestrian; add 
bicycle=yes; add motorcar=yes; }

But unfortunately there is no path or pedestrian in the test-route, nor is it 
an option to use one.
Anyone has an idea how this path>pedestrian rule could affect routing on 
residential/primary?
Same happens when I replay the change with the original OFM.

Up-to-date osm.pbf, route from BC and screenshots are here: 
https://files.mkgmap.org.uk/download/556/test_route.zip

Thanks
Jan
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question on routing difference

[lig fietser]

Hi Jan,
I also get the same route as test-route-b_yes-removed.jpg with the latest OFM 
Germany from 10=05-2022
(website is finally up to date since today).
It only takes the Altengabengäßchen when you move the via point closer to the 
junction Altengabengäßchen,
or when you select "avoid toll roads". I really don't know why, because there 
are no bike routes on these streets.
What I use is routing over short distance. avoid nothing (sometimes unpaved).  
Actually I don't use my Garmin at all,
I prefer Osmand with mobile phone (android) now 


Cheers, Minko








Van: mkgmap-dev  namens jan meisters 

Verzonden: zaterdag 28 mei 2022 11:15
Aan: Development list for mkgmap 
Onderwerp: [mkgmap-dev] Question on routing difference

Hi all,

I´m using an altered copy of the OFM style and therefore sometimes compare the 
results.
One routing difference I found I was able to lead back, but the cause I don´t 
understand at all.

My test-route should prefer the small residential „Altengabengäßchen“ over the 
primary „Viktoriastrasse“.
Latest OFM does, my version not since I removed {add bicycle=yes} from this 
line:
highway=path & surface ~ 
'(paved|asphalt|sett|concrete|paving_stones|paving_stones:30)' & access!=no & 
access!=private & vehicle!=no { set highway=pedestrian; add bicycle=yes; add 
motorcar=yes; }

But unfortunately there is no path or pedestrian in the test-route, nor is it 
an option to use one.
Anyone has an idea how this path>pedestrian rule could affect routing on 
residential/primary?
Same happens when I replay the change with the original OFM.

Up-to-date osm.pbf, route from BC and screenshots are here: 
https://files.mkgmap.org.uk/download/556/test_route.zip

Thanks
Jan
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question on routing difference

[jan meisters]

Hi Gerd,

I just played with the routing prefs to see if I could change something ;-)

I´m using it like this: 
https://files.mkgmap.org.uk/download/557/OFM_default-BC_Mac.png 
<https://files.mkgmap.org.uk/download/557/OFM_default-BC_Mac.png>
And same here, checked toll-avoidance routes as preferred, unchecked over the 
primary.

Toll-avoidance should prefer bicycleroutes according to Minko.
I´ve unchecked long ago for some reason, don´t remember why and have to 
recompare.
But same as no path is routed there is no bicycleroute …

Jan


> Am 29.05.2022 um 16:17 schrieb Gerd Petermann 
> :
> 
> Hi jan,
> 
> maybe my routing profile for OFM bike is different?
> 
> Not sure what Minko recommends today. Mine says "Faster Time", Standard  
> Elevation Mode, only road type avoidance is for "Roll  Roads".
> When I remove the toll roads avoidance the route is different and follows the 
> major road.
> 
> Gerd
> 
> 
> 
> Von: mkgmap-dev  im Auftrag von jan 
> meisters 
> Gesendet: Sonntag, 29. Mai 2022 16:07
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Question on routing difference
> 
> Hi Gerd,
> 
> here OFM lite gives the same unwanted result as OFM full :-(
> 
> Jan
> 
>> Am 29.05.2022 um 14:54 schrieb Gerd Petermann 
>> :
>> 
>> Hi Jan,
>> 
>> the artifical way would be a highway=residential, not path. Anyhow, I tried 
>> to reproduce the different routing results with the mentioned change in the 
>> OFM lite style
>> but found no difference, the wanted route is calculated for both versions.
>> 
>> Gerd
>> 
>> ____________
>> Von: mkgmap-dev  im Auftrag von Gerd 
>> Petermann 
>> Gesendet: Sonntag, 29. Mai 2022 14:10
>> An: Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] Question on routing difference
>> 
>> Hi Jan,
>> 
>> not sure if you would find it with that id, since it would be an artificial 
>> way. Don't have time now, will look into this later.
>> 
>> Gerd
>> 
>> 
>> Von: mkgmap-dev  im Auftrag von jan 
>> meisters 
>> Gesendet: Sonntag, 29. Mai 2022 14:07
>> An: Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] Question on routing difference
>> 
>> Hi Gerd,
>> 
>> do you mean another routable line?
>> All (routable) highways are echotagged in my style atm, but I can´t find 
>> 27463238 twice.
>> 
>> Jan
>> 
>> 
>>> Am 29.05.2022 um 09:16 schrieb Gerd Petermann 
>>> :
>>> 
>>> Hi Jan,
>>> 
>>> might be the oneway:bicycle=no on way 27463238 which can create an 
>>> additional path in the opposite direction.
>>> 
>>> Gerd
>>> 
>>> 
>>> Von: mkgmap-dev  im Auftrag von jan 
>>> meisters 
>>> Gesendet: Samstag, 28. Mai 2022 20:15
>>> An: Development list for mkgmap
>>> Betreff: [mkgmap-dev] Question on routing difference
>>> 
>>> Hi all,
>>> 
>>> I´m using an altered copy of the OFM style and therefore sometimes compare 
>>> the results.
>>> One routing difference I found I was able to lead back, but the cause I 
>>> don´t understand at all.
>>> 
>>> My test-route should prefer the small residential „Altengabengäßchen“ over 
>>> the primary „Viktoriastrasse“.
>>> Latest OFM does, my version not since I removed {add bicycle=yes} from this 
>>> line:
>>> highway=path & surface ~ 
>>> '(paved|asphalt|sett|concrete|paving_stones|paving_stones:30)' & access!=no 
>>> & access!=private & vehicle!=no { set highway=pedestrian; add bicycle=yes; 
>>> add motorcar=yes; }
>>> 
>>> But unfortunately there is no path or pedestrian in the test-route, nor is 
>>> it an option to use one.
>>> Anyone has an idea how this path>pedestrian rule could affect routing on 
>>> residential/primary?
>>> Same happens when I replay the change with the original OFM.
>>> 
>>> Up-to-date osm.pbf, route from BC and screenshots are here: 
>>> https://files.mkgmap.org.uk/download/556/test_route.zip
>>> 
>>> Thanks
>>> Jan
>>> ___
>>> mkgmap-dev mailing list
>>> mkgmap-dev@lists.mkgmap.org.uk
>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>> 
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question on routing difference

[Gerd Petermann]

Hi jan,

maybe my routing profile for OFM bike is different?

Not sure what Minko recommends today. Mine says "Faster Time", Standard  
Elevation Mode, only road type avoidance is for "Roll  Roads".
When I remove the toll roads avoidance the route is different and follows the 
major road.

Gerd



Von: mkgmap-dev  im Auftrag von jan 
meisters 
Gesendet: Sonntag, 29. Mai 2022 16:07
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Question on routing difference

Hi Gerd,

here OFM lite gives the same unwanted result as OFM full :-(

Jan

> Am 29.05.2022 um 14:54 schrieb Gerd Petermann 
> :
>
> Hi Jan,
>
> the artifical way would be a highway=residential, not path. Anyhow, I tried 
> to reproduce the different routing results with the mentioned change in the 
> OFM lite style
> but found no difference, the wanted route is calculated for both versions.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von Gerd 
> Petermann 
> Gesendet: Sonntag, 29. Mai 2022 14:10
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Question on routing difference
>
> Hi Jan,
>
> not sure if you would find it with that id, since it would be an artificial 
> way. Don't have time now, will look into this later.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von jan 
> meisters 
> Gesendet: Sonntag, 29. Mai 2022 14:07
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Question on routing difference
>
> Hi Gerd,
>
> do you mean another routable line?
> All (routable) highways are echotagged in my style atm, but I can´t find 
> 27463238 twice.
>
> Jan
>
>
>> Am 29.05.2022 um 09:16 schrieb Gerd Petermann 
>> :
>>
>> Hi Jan,
>>
>> might be the oneway:bicycle=no on way 27463238 which can create an 
>> additional path in the opposite direction.
>>
>> Gerd
>>
>> 
>> Von: mkgmap-dev  im Auftrag von jan 
>> meisters 
>> Gesendet: Samstag, 28. Mai 2022 20:15
>> An: Development list for mkgmap
>> Betreff: [mkgmap-dev] Question on routing difference
>>
>> Hi all,
>>
>> I´m using an altered copy of the OFM style and therefore sometimes compare 
>> the results.
>> One routing difference I found I was able to lead back, but the cause I 
>> don´t understand at all.
>>
>> My test-route should prefer the small residential „Altengabengäßchen“ over 
>> the primary „Viktoriastrasse“.
>> Latest OFM does, my version not since I removed {add bicycle=yes} from this 
>> line:
>> highway=path & surface ~ 
>> '(paved|asphalt|sett|concrete|paving_stones|paving_stones:30)' & access!=no 
>> & access!=private & vehicle!=no { set highway=pedestrian; add bicycle=yes; 
>> add motorcar=yes; }
>>
>> But unfortunately there is no path or pedestrian in the test-route, nor is 
>> it an option to use one.
>> Anyone has an idea how this path>pedestrian rule could affect routing on 
>> residential/primary?
>> Same happens when I replay the change with the original OFM.
>>
>> Up-to-date osm.pbf, route from BC and screenshots are here: 
>> https://files.mkgmap.org.uk/download/556/test_route.zip
>>
>> Thanks
>> Jan
>> ___
>> mkgmap-dev mailing list
>> mkgmap-dev@lists.mkgmap.org.uk
>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question on routing difference

[jan meisters]

Hi Gerd,

here OFM lite gives the same unwanted result as OFM full :-(

Jan

> Am 29.05.2022 um 14:54 schrieb Gerd Petermann 
> :
> 
> Hi Jan,
> 
> the artifical way would be a highway=residential, not path. Anyhow, I tried 
> to reproduce the different routing results with the mentioned change in the 
> OFM lite style
> but found no difference, the wanted route is calculated for both versions.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag von Gerd 
> Petermann 
> Gesendet: Sonntag, 29. Mai 2022 14:10
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Question on routing difference
> 
> Hi Jan,
> 
> not sure if you would find it with that id, since it would be an artificial 
> way. Don't have time now, will look into this later.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag von jan 
> meisters 
> Gesendet: Sonntag, 29. Mai 2022 14:07
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Question on routing difference
> 
> Hi Gerd,
> 
> do you mean another routable line?
> All (routable) highways are echotagged in my style atm, but I can´t find 
> 27463238 twice.
> 
> Jan
> 
> 
>> Am 29.05.2022 um 09:16 schrieb Gerd Petermann 
>> :
>> 
>> Hi Jan,
>> 
>> might be the oneway:bicycle=no on way 27463238 which can create an 
>> additional path in the opposite direction.
>> 
>> Gerd
>> 
>> ____
>> Von: mkgmap-dev  im Auftrag von jan 
>> meisters 
>> Gesendet: Samstag, 28. Mai 2022 20:15
>> An: Development list for mkgmap
>> Betreff: [mkgmap-dev] Question on routing difference
>> 
>> Hi all,
>> 
>> I´m using an altered copy of the OFM style and therefore sometimes compare 
>> the results.
>> One routing difference I found I was able to lead back, but the cause I 
>> don´t understand at all.
>> 
>> My test-route should prefer the small residential „Altengabengäßchen“ over 
>> the primary „Viktoriastrasse“.
>> Latest OFM does, my version not since I removed {add bicycle=yes} from this 
>> line:
>> highway=path & surface ~ 
>> '(paved|asphalt|sett|concrete|paving_stones|paving_stones:30)' & access!=no 
>> & access!=private & vehicle!=no { set highway=pedestrian; add bicycle=yes; 
>> add motorcar=yes; }
>> 
>> But unfortunately there is no path or pedestrian in the test-route, nor is 
>> it an option to use one.
>> Anyone has an idea how this path>pedestrian rule could affect routing on 
>> residential/primary?
>> Same happens when I replay the change with the original OFM.
>> 
>> Up-to-date osm.pbf, route from BC and screenshots are here: 
>> https://files.mkgmap.org.uk/download/556/test_route.zip
>> 
>> Thanks
>> Jan
>> ___
>> mkgmap-dev mailing list
>> mkgmap-dev@lists.mkgmap.org.uk
>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> 

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question on routing difference

[Gerd Petermann]

Hi Jan,

the artifical way would be a highway=residential, not path. Anyhow, I tried to 
reproduce the different routing results with the mentioned change in the OFM 
lite style
but found no difference, the wanted route is calculated for both versions.

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Sonntag, 29. Mai 2022 14:10
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Question on routing difference

Hi Jan,

not sure if you would find it with that id, since it would be an artificial 
way. Don't have time now, will look into this later.

Gerd


Von: mkgmap-dev  im Auftrag von jan 
meisters 
Gesendet: Sonntag, 29. Mai 2022 14:07
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Question on routing difference

Hi Gerd,

do you mean another routable line?
All (routable) highways are echotagged in my style atm, but I can´t find 
27463238 twice.

Jan


> Am 29.05.2022 um 09:16 schrieb Gerd Petermann 
> :
>
> Hi Jan,
>
> might be the oneway:bicycle=no on way 27463238 which can create an additional 
> path in the opposite direction.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von jan 
> meisters 
> Gesendet: Samstag, 28. Mai 2022 20:15
> An: Development list for mkgmap
> Betreff: [mkgmap-dev] Question on routing difference
>
> Hi all,
>
> I´m using an altered copy of the OFM style and therefore sometimes compare 
> the results.
> One routing difference I found I was able to lead back, but the cause I don´t 
> understand at all.
>
> My test-route should prefer the small residential „Altengabengäßchen“ over 
> the primary „Viktoriastrasse“.
> Latest OFM does, my version not since I removed {add bicycle=yes} from this 
> line:
> highway=path & surface ~ 
> '(paved|asphalt|sett|concrete|paving_stones|paving_stones:30)' & access!=no & 
> access!=private & vehicle!=no { set highway=pedestrian; add bicycle=yes; add 
> motorcar=yes; }
>
> But unfortunately there is no path or pedestrian in the test-route, nor is it 
> an option to use one.
> Anyone has an idea how this path>pedestrian rule could affect routing on 
> residential/primary?
> Same happens when I replay the change with the original OFM.
>
> Up-to-date osm.pbf, route from BC and screenshots are here: 
> https://files.mkgmap.org.uk/download/556/test_route.zip
>
> Thanks
> Jan
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question on routing difference

[Gerd Petermann]

Hi Jan,

not sure if you would find it with that id, since it would be an artificial 
way. Don't have time now, will look into this later.

Gerd


Von: mkgmap-dev  im Auftrag von jan 
meisters 
Gesendet: Sonntag, 29. Mai 2022 14:07
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Question on routing difference

Hi Gerd,

do you mean another routable line?
All (routable) highways are echotagged in my style atm, but I can´t find 
27463238 twice.

Jan


> Am 29.05.2022 um 09:16 schrieb Gerd Petermann 
> :
>
> Hi Jan,
>
> might be the oneway:bicycle=no on way 27463238 which can create an additional 
> path in the opposite direction.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von jan 
> meisters 
> Gesendet: Samstag, 28. Mai 2022 20:15
> An: Development list for mkgmap
> Betreff: [mkgmap-dev] Question on routing difference
>
> Hi all,
>
> I´m using an altered copy of the OFM style and therefore sometimes compare 
> the results.
> One routing difference I found I was able to lead back, but the cause I don´t 
> understand at all.
>
> My test-route should prefer the small residential „Altengabengäßchen“ over 
> the primary „Viktoriastrasse“.
> Latest OFM does, my version not since I removed {add bicycle=yes} from this 
> line:
> highway=path & surface ~ 
> '(paved|asphalt|sett|concrete|paving_stones|paving_stones:30)' & access!=no & 
> access!=private & vehicle!=no { set highway=pedestrian; add bicycle=yes; add 
> motorcar=yes; }
>
> But unfortunately there is no path or pedestrian in the test-route, nor is it 
> an option to use one.
> Anyone has an idea how this path>pedestrian rule could affect routing on 
> residential/primary?
> Same happens when I replay the change with the original OFM.
>
> Up-to-date osm.pbf, route from BC and screenshots are here: 
> https://files.mkgmap.org.uk/download/556/test_route.zip
>
> Thanks
> Jan
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question on routing difference

[jan meisters]

Hi Gerd,

do you mean another routable line?
All (routable) highways are echotagged in my style atm, but I can´t find 
27463238 twice.

Jan


> Am 29.05.2022 um 09:16 schrieb Gerd Petermann 
> :
> 
> Hi Jan,
> 
> might be the oneway:bicycle=no on way 27463238 which can create an additional 
> path in the opposite direction.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag von jan 
> meisters 
> Gesendet: Samstag, 28. Mai 2022 20:15
> An: Development list for mkgmap
> Betreff: [mkgmap-dev] Question on routing difference
> 
> Hi all,
> 
> I´m using an altered copy of the OFM style and therefore sometimes compare 
> the results.
> One routing difference I found I was able to lead back, but the cause I don´t 
> understand at all.
> 
> My test-route should prefer the small residential „Altengabengäßchen“ over 
> the primary „Viktoriastrasse“.
> Latest OFM does, my version not since I removed {add bicycle=yes} from this 
> line:
> highway=path & surface ~ 
> '(paved|asphalt|sett|concrete|paving_stones|paving_stones:30)' & access!=no & 
> access!=private & vehicle!=no { set highway=pedestrian; add bicycle=yes; add 
> motorcar=yes; }
> 
> But unfortunately there is no path or pedestrian in the test-route, nor is it 
> an option to use one.
> Anyone has an idea how this path>pedestrian rule could affect routing on 
> residential/primary?
> Same happens when I replay the change with the original OFM.
> 
> Up-to-date osm.pbf, route from BC and screenshots are here: 
> https://files.mkgmap.org.uk/download/556/test_route.zip
> 
> Thanks
> Jan
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question on routing difference

[Gerd Petermann]

Hi Jan,

might be the oneway:bicycle=no on way 27463238 which can create an additional 
path in the opposite direction.

Gerd


Von: mkgmap-dev  im Auftrag von jan 
meisters 
Gesendet: Samstag, 28. Mai 2022 20:15
An: Development list for mkgmap
Betreff: [mkgmap-dev] Question on routing difference

Hi all,

I´m using an altered copy of the OFM style and therefore sometimes compare the 
results.
One routing difference I found I was able to lead back, but the cause I don´t 
understand at all.

My test-route should prefer the small residential „Altengabengäßchen“ over the 
primary „Viktoriastrasse“.
Latest OFM does, my version not since I removed {add bicycle=yes} from this 
line:
highway=path & surface ~ 
'(paved|asphalt|sett|concrete|paving_stones|paving_stones:30)' & access!=no & 
access!=private & vehicle!=no { set highway=pedestrian; add bicycle=yes; add 
motorcar=yes; }

But unfortunately there is no path or pedestrian in the test-route, nor is it 
an option to use one.
Anyone has an idea how this path>pedestrian rule could affect routing on 
residential/primary?
Same happens when I replay the change with the original OFM.

Up-to-date osm.pbf, route from BC and screenshots are here: 
https://files.mkgmap.org.uk/download/556/test_route.zip

Thanks
Jan
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Question on routing difference

[jan meisters]

Hi all,

I´m using an altered copy of the OFM style and therefore sometimes compare the 
results.
One routing difference I found I was able to lead back, but the cause I don´t 
understand at all.

My test-route should prefer the small residential „Altengabengäßchen“ over the 
primary „Viktoriastrasse“.
Latest OFM does, my version not since I removed {add bicycle=yes} from this 
line:
highway=path & surface ~ 
'(paved|asphalt|sett|concrete|paving_stones|paving_stones:30)' & access!=no & 
access!=private & vehicle!=no { set highway=pedestrian; add bicycle=yes; add 
motorcar=yes; }

But unfortunately there is no path or pedestrian in the test-route, nor is it 
an option to use one.
Anyone has an idea how this path>pedestrian rule could affect routing on 
residential/primary?
Same happens when I replay the change with the original OFM.

Up-to-date osm.pbf, route from BC and screenshots are here: 
https://files.mkgmap.org.uk/download/556/test_route.zip

Thanks
Jan
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] question about output-dir and indexing

[Gerd Petermann]

Hi Karl,

better combine (merge) the input files first and feed the combination to 
splitter.
Use e.g. osmconvert [1] to merge  the files, e.g.
osmconvert denmark-latest.osm.pbf finland--latest.osm.pbf norway-latest.osm.pbf 
-o=scandinavia.o5m
java -jar splitter.jar ... scandinavia.o5m

Make sure that you download all the merged files at the same day to avoid 
version conflicts.

reg. deletealltags: If you don't want parkings in your map you should better 
remove/comment the rules which would create those objects.
This allows mkgmap to ignore the unwanted objects much earlier.

Gerd
[1] https://wiki.openstreetmap.org/wiki/Osmconvert


Von: mkgmap-dev  im Auftrag von 7700 
<7...@foskan.eu>
Gesendet: Dienstag, 6. Oktober 2020 09:19
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] question about output-dir and indexing

Hi Gerd and Carlos.
Both your commends made a difference in moving forward!

Two more questions before i dig deeper on my own.
I will be trying to make a map of the scandinavian countries, denmark, norway,
sweden.
It safe to generate each country first by using country data from geofabrik,
compile tiles for each country and then combine the three to one gmapsupp or
will that make border areas inaccessible because maps tiles overlay each
other?
If this is not a good way, what is a good way?


If i want to make a minimalistic map, and remove a lot of things.
Say all parkings. is it correct to use the deletealltags for the types of data
i want to remove?



Regards
Karl

On måndag 5 oktober 2020 kl. 20:29:58 CEST Gerd Petermann wrote:
> Hi Karl,
>
> the option
> --read-config=se/splitted/template.args
> tells mkgmap to read further args from se/splitted/template.args .
> When you look into that file you'll notice that it contains several lines
> with input-file=... So, mkgmap compiles a lot of tiles with the default
> options before it looks at the options following this first one. Later, it
> compiles the same tiles again with your options. Try
>
> java -Xmx4G -jar ../mkgmap/mkgmap-r4585/mkgmap.jar
> --max-jobs
> --family-name="NORDIC"
> --country-name="Sweden"
> --country-abbr="SWE"
> --family-id=7700
> --latin1
> --net --route --index --split-name-index
> --output-dir=se/tiles/
> --read-config=se/splitted/template.args
> --description="Sweden routable."
> --gmapsupp
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von 7700
> <7...@foskan.eu> Gesendet: Montag, 5. Oktober 2020 19:32
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: [mkgmap-dev] question about output-dir and indexing
>
> Hi.
> I am very new to making maps so therefor in case i am asking something
> obvious it is because i don't know better yet.
>
> I am trying to generate a map for a country (trying sweden) and observe a
> strange thing with --output-dir for mkgmap (r4585).
> Files are written to other directories than to the --output-dir
>
>
> Starting at a base directory i have created this structure:
>
> ├── gmapsupp
> └── se
> ├── splitted
> └── tiles
>
> The idea is that for sweden i will store splitted pbf files in a separate
> directory and tiles in a separate.
>
> at first i download data to the ./se/ directory:
> wget https://download.geofabrik.de/europe/sweden-latest.osm.pbf
>
> then split the data, adding the --output-dir=se/splitted/
> this works fine.
>
> now i want to generate the *.img tiles from the splitted files. Doing this
> from the base directory.
>
> java -jar ../mkgmap/mkgmap-r4585/mkgmap.jar
> --read-config=se/splitted/template.args
> --remove-short-arcs
> --family-name="NORDIC"
> --country-name="Sweden"
> --country-abbr="SWE"
> --description="Sweden routable."
> --mapname=7771
> --family-id=770
> --latin1
> --net --route --index --split-name-index
> --output-dir=se/tiles/
> se/splitted/*.osm.pbf
>
>
>
> When i run this from the base directory
> numbered *.img files and ovm_*.img files are first written to the base
> directory and then last to the target directory.
> After the program finishes there are files both in base directory from where
> i executed the program, as well as the directory given in output-dir. The
> files in the output-dir directory are larger than the ones in the base
> directory. Is this an error or should i take care of both sets of files?
>
>
>
> Trying to use --index to create a searchable index or street names, for
> this, do i need to add a separate file/style to make it work?
> if yes, are there examples which you can point to?
>
>
> Regards
> Karl
>
>
>
> ___
> mkgm

Re: [mkgmap-dev] question about output-dir and indexing

[7700]

Hi Gerd and Carlos.
Both your commends made a difference in moving forward!

Two more questions before i dig deeper on my own.
I will be trying to make a map of the scandinavian countries, denmark, norway, 
sweden.
It safe to generate each country first by using country data from geofabrik, 
compile tiles for each country and then combine the three to one gmapsupp or 
will that make border areas inaccessible because maps tiles overlay each 
other? 
If this is not a good way, what is a good way?


If i want to make a minimalistic map, and remove a lot of things.
Say all parkings. is it correct to use the deletealltags for the types of data 
i want to remove?



Regards
Karl

On måndag 5 oktober 2020 kl. 20:29:58 CEST Gerd Petermann wrote:
> Hi Karl,
> 
> the option
> --read-config=se/splitted/template.args
> tells mkgmap to read further args from se/splitted/template.args .
> When you look into that file you'll notice that it contains several lines
> with input-file=... So, mkgmap compiles a lot of tiles with the default
> options before it looks at the options following this first one. Later, it
> compiles the same tiles again with your options. Try
> 
> java -Xmx4G -jar ../mkgmap/mkgmap-r4585/mkgmap.jar
> --max-jobs
> --family-name="NORDIC"
> --country-name="Sweden"
> --country-abbr="SWE"
> --family-id=7700
> --latin1
> --net --route --index --split-name-index
> --output-dir=se/tiles/
> --read-config=se/splitted/template.args
> --description="Sweden routable."
> --gmapsupp
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag von 7700
> <7...@foskan.eu> Gesendet: Montag, 5. Oktober 2020 19:32
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: [mkgmap-dev] question about output-dir and indexing
> 
> Hi.
> I am very new to making maps so therefor in case i am asking something
> obvious it is because i don't know better yet.
> 
> I am trying to generate a map for a country (trying sweden) and observe a
> strange thing with --output-dir for mkgmap (r4585).
> Files are written to other directories than to the --output-dir
> 
> 
> Starting at a base directory i have created this structure:
> 
> ├── gmapsupp
> └── se
> ├── splitted
> └── tiles
> 
> The idea is that for sweden i will store splitted pbf files in a separate
> directory and tiles in a separate.
> 
> at first i download data to the ./se/ directory:
> wget https://download.geofabrik.de/europe/sweden-latest.osm.pbf
> 
> then split the data, adding the --output-dir=se/splitted/
> this works fine.
> 
> now i want to generate the *.img tiles from the splitted files. Doing this
> from the base directory.
> 
> java -jar ../mkgmap/mkgmap-r4585/mkgmap.jar
> --read-config=se/splitted/template.args
> --remove-short-arcs
> --family-name="NORDIC"
> --country-name="Sweden"
> --country-abbr="SWE"
> --description="Sweden routable."
> --mapname=7771
> --family-id=770
> --latin1
> --net --route --index --split-name-index
> --output-dir=se/tiles/
> se/splitted/*.osm.pbf
> 
> 
> 
> When i run this from the base directory
> numbered *.img files and ovm_*.img files are first written to the base
> directory and then last to the target directory.
> After the program finishes there are files both in base directory from where
> i executed the program, as well as the directory given in output-dir. The
> files in the output-dir directory are larger than the ones in the base
> directory. Is this an error or should i take care of both sets of files?
> 
> 
> 
> Trying to use --index to create a searchable index or street names, for
> this, do i need to add a separate file/style to make it work?
> if yes, are there examples which you can point to?
> 
> 
> Regards
> Karl
> 
> 
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] question about output-dir and indexing

[Carlos Dávila]

mapname and description are taken from template.args. Try removing those 
parameters from your command line.
Regarding index, in order to get right addresses you need to supply 
bounds file (--bounds). You can get it from 
http://osm.thkukuk.de/data/bounds-latest.zip


El 5/10/20 a las 19:32, 7700 escribió:

Hi.
I am very new to making maps so therefor in case i am asking something obvious
it is because i don't know better yet.

I am trying to generate a map for a country (trying sweden) and observe a
strange thing with --output-dir for mkgmap (r4585).
Files are written to other directories than to the --output-dir


Starting at a base directory i have created this structure:

├── gmapsupp
└── se
 ├── splitted
 └── tiles

The idea is that for sweden i will store splitted pbf files in a separate
directory and tiles in a separate.

at first i download data to the ./se/ directory:
wget https://download.geofabrik.de/europe/sweden-latest.osm.pbf

then split the data, adding the --output-dir=se/splitted/
this works fine.

now i want to generate the *.img tiles from the splitted files. Doing this from
the base directory.

java -jar ../mkgmap/mkgmap-r4585/mkgmap.jar
--read-config=se/splitted/template.args
--remove-short-arcs
--family-name="NORDIC"
--country-name="Sweden"
--country-abbr="SWE"
--description="Sweden routable."
--mapname=7771
--family-id=770
--latin1
--net --route --index --split-name-index
--output-dir=se/tiles/
se/splitted/*.osm.pbf



When i run this from the base directory
numbered *.img files and ovm_*.img files are first written to the base directory
and then last to the target directory.
After the program finishes there are files both in base directory from where i
executed the program, as well as the directory given in output-dir.
The files in the output-dir directory are larger than the ones in the base
directory. Is this an error or should i take care of both sets of files?



Trying to use --index to create a searchable index or street names, for this,
do i need to add a separate file/style to make it work?
if yes, are there examples which you can point to?


Regards
Karl



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] question about output-dir and indexing

[Gerd Petermann]

Hi Karl,

the option
--read-config=se/splitted/template.args
tells mkgmap to read further args from se/splitted/template.args .
When you look into that file you'll notice that it contains several lines with 
input-file=...
So, mkgmap compiles a lot of tiles with the default options before it looks at 
the options following this first one. Later, it compiles the same tiles again 
with your options.
Try

java -Xmx4G -jar ../mkgmap/mkgmap-r4585/mkgmap.jar
--max-jobs
--family-name="NORDIC"
--country-name="Sweden"
--country-abbr="SWE"
--family-id=7700
--latin1
--net --route --index --split-name-index
--output-dir=se/tiles/
--read-config=se/splitted/template.args
--description="Sweden routable."
--gmapsupp

Gerd


Von: mkgmap-dev  im Auftrag von 7700 
<7...@foskan.eu>
Gesendet: Montag, 5. Oktober 2020 19:32
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] question about output-dir and indexing

Hi.
I am very new to making maps so therefor in case i am asking something obvious
it is because i don't know better yet.

I am trying to generate a map for a country (trying sweden) and observe a
strange thing with --output-dir for mkgmap (r4585).
Files are written to other directories than to the --output-dir


Starting at a base directory i have created this structure:

├── gmapsupp
└── se
├── splitted
└── tiles

The idea is that for sweden i will store splitted pbf files in a separate
directory and tiles in a separate.

at first i download data to the ./se/ directory:
wget https://download.geofabrik.de/europe/sweden-latest.osm.pbf

then split the data, adding the --output-dir=se/splitted/
this works fine.

now i want to generate the *.img tiles from the splitted files. Doing this from
the base directory.

java -jar ../mkgmap/mkgmap-r4585/mkgmap.jar
--read-config=se/splitted/template.args
--remove-short-arcs
--family-name="NORDIC"
--country-name="Sweden"
--country-abbr="SWE"
--description="Sweden routable."
--mapname=7771
--family-id=770
--latin1
--net --route --index --split-name-index
--output-dir=se/tiles/
se/splitted/*.osm.pbf



When i run this from the base directory
numbered *.img files and ovm_*.img files are first written to the base directory
and then last to the target directory.
After the program finishes there are files both in base directory from where i
executed the program, as well as the directory given in output-dir.
The files in the output-dir directory are larger than the ones in the base
directory. Is this an error or should i take care of both sets of files?



Trying to use --index to create a searchable index or street names, for this,
do i need to add a separate file/style to make it work?
if yes, are there examples which you can point to?


Regards
Karl



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] question about output-dir and indexing

[7700]

Hi.
I am very new to making maps so therefor in case i am asking something obvious 
it is because i don't know better yet.

I am trying to generate a map for a country (trying sweden) and observe a 
strange thing with --output-dir for mkgmap (r4585).
Files are written to other directories than to the --output-dir


Starting at a base directory i have created this structure:

├── gmapsupp
└── se
├── splitted
└── tiles

The idea is that for sweden i will store splitted pbf files in a separate 
directory and tiles in a separate.

at first i download data to the ./se/ directory:
wget https://download.geofabrik.de/europe/sweden-latest.osm.pbf

then split the data, adding the --output-dir=se/splitted/
this works fine.

now i want to generate the *.img tiles from the splitted files. Doing this from 
the base directory.

java -jar ../mkgmap/mkgmap-r4585/mkgmap.jar 
--read-config=se/splitted/template.args 
--remove-short-arcs 
--family-name="NORDIC" 
--country-name="Sweden" 
--country-abbr="SWE" 
--description="Sweden routable." 
--mapname=7771 
--family-id=770  
--latin1 
--net --route --index --split-name-index 
--output-dir=se/tiles/ 
se/splitted/*.osm.pbf



When i run this from the base directory
numbered *.img files and ovm_*.img files are first written to the base 
directory 
and then last to the target directory.
After the program finishes there are files both in base directory from where i 
executed the program, as well as the directory given in output-dir.
The files in the output-dir directory are larger than the ones in the base 
directory. Is this an error or should i take care of both sets of files?



Trying to use --index to create a searchable index or street names, for this, 
do i need to add a separate file/style to make it work?
if yes, are there examples which you can point to?


Regards
Karl



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question (only): Is mkgmap-default-style Routing by foot/bicycle according to Usecase ?

[AnkEric]

Hi Gerd,

Oké, now I understand.
Yes, motorway is a routable way.

highway=primary [0x1 resolution 18-19 continue with_actions]
highway=primary [0x10014 resolution 20-21 continue with_actions]
highway=primary & bicycle!=no [0x03 road_class=0 road_speed=1 resolution 22
continue with_actions]  

Ehhh, NO...!!!

[bicycle=no] will NOT set road_class and road_speed. So my primary is NOT
routable.

Also my motorway is NOT routable.

highway=motorway [0x1 resolution 18-19 continue with_actions]
highway=motorway [0x10014 resolution 20-21 continue with_actions] 

So: ( highway=* & bicycle=no | highway=motorway )  are NOT routable.

> and that the via points are at the same place?

Absolute position waypoint/viapoint is 100% identical (same point), but
relative position to highway might be different IF highway nodes have been
relocated by mkgmap (???, remember ???).

But I have been playing around with via-point position.
Mkgmap will always use the motorway, unless the via-point is closer to
another highway not having bicycle=no.

> My understanding is that the Garmin routing algo ignores all restrictions
> when the via or target point is only reachable on a "prohibited" road.

I don't know or understand.
What I do know: all [highway=service], [surface=sand/gravel],
[highway=steps], [route=ferry] is SET to "mkgmap:unpaved". Therefore I need
to explicitly PUT a via-point ON the ferry before the ferry will be used for
navigation.
But these highway are routable therefore I can force navigation on these
highways.

Anyway: my question is not about my own map. Now I understand it's thanks to
the non routable highways my GPS won't send my ON a motorway.

Question is: 
Is it oké (by design) makgmap-default-style will navigate me using a
motorway IF (and only IF) I put a VIA-point on TOP of the motorway?
I admit: that's my error.
But mkgmap-BaseCamp-GPS should help me and tell me: "Don't be stupid, Eric!"





--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question (only): Is mkgmap-default-style Routing by foot/bicycle according to Usecase ?

[AnkEric]

> reg. 3) are you sure that the motorway is routable in your map 

My Map (with or without quotes), is a Bicycle Map ONLY.
All highways are either [bicycle=yes] OR [bicycle=no].
If [bicycle=no] this implies a highway is NOT routable (access=no).
Therefore all the non-routable ways are gray and ignored for routing (by
BaseCamp, GPS and navigator Anke). Simpel; -)
So selecting a vehicle type for routing is not relevant. Exception: routing
by foot on a bicycle map will ignore [oneway=yes]. Which is sometimes a way
out if OSM-Mapping is not correct (oneway=yes without oneway:bicycle=no).

> and that the via points are at the same place?

Yes they are. I Set 2 Waypoints and 1 Viapoint, Create Route and THEN ONLY
Switch Map. And Recalculate Route.

> My understanding is that the Garmin routing algo ignores all restrictions
> when the via or target point is only reachable on a "prohibited" road.

No answer before dinner and I have to think about what you mean... to be
continued...

Eric




--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question (only): Is mkgmap-default-style Routing by foot/bicycle according to Usecase ?

[Gerd Petermann]

Hi Eric,

a routable way with access=no is not the same as a non-routable way.
If the motorway is a line without road_class or road_speed it is not routable.

Gerd


Von: mkgmap-dev  im Auftrag von AnkEric 

Gesendet: Mittwoch, 25. März 2020 18:27
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Question (only): Is mkgmap-default-style Routing by 
foot/bicycle according to Usecase ?

> reg. 3) are you sure that the motorway is routable in your map

My Map (with or without quotes), is a Bicycle Map ONLY.
All highways are either [bicycle=yes] OR [bicycle=no].
If [bicycle=no] this implies a highway is NOT routable (access=no).
Therefore all the non-routable ways are gray and ignored for routing (by
BaseCamp, GPS and navigator Anke). Simpel; -)
So selecting a vehicle type for routing is not relevant. Exception: routing
by foot on a bicycle map will ignore [oneway=yes]. Which is sometimes a way
out if OSM-Mapping is not correct (oneway=yes without oneway:bicycle=no).

> and that the via points are at the same place?

Yes they are. I Set 2 Waypoints and 1 Viapoint, Create Route and THEN ONLY
Switch Map. And Recalculate Route.

> My understanding is that the Garmin routing algo ignores all restrictions
> when the via or target point is only reachable on a "prohibited" road.

No answer before dinner and I have to think about what you mean... to be
continued...

Eric




--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question (only): Is mkgmap-default-style Routing by foot/bicycle according to Usecase ?

[Gerd Petermann]

Hi Eric,

reg. 3) are you sure that the motorway is routable in your map and that the via 
points are at the same place?
My understanding is that the Garmin routing algo ignores all restrictions when 
the via or target point is only reachable on a "prohibited" road.

Gerd


Von: mkgmap-dev  im Auftrag von AnkEric 

Gesendet: Mittwoch, 25. März 2020 17:34
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Question (only): Is mkgmap-default-style Routing by 
foot/bicycle according to Usecase ?

Is mkgmap-default-style Routing by foot/bicycle according to Usecase?

1. Navigate from "_START" to "_FINISH".
Routing is OK for both foot and bicycle.
Routing will not use the Motorway.

<http://gis.19327.n8.nabble.com/file/t344065/1_Routing_Foot_Bicycle_Start_Finish_OK.png>

2. Add one Viapoint "_VIA" AND put it ON the Motorway.
My deliberate Error is just for "testing" purposes. Although I have made the
same mistake in real life several times.
Foot and Cycling are very much prohibited on the Motorway.
Now Routing will follow the Motorway. Which is an error, dangerous and an
offence.

<http://gis.19327.n8.nabble.com/file/t344065/2_Routing_Foot_Bicycle_Start_VIA_Finish_ERROR.png>

3. My "own" Map is specific to Car or Bicycle or Foot only.
My Bicycle_Map (or Foot_Map) will avoid the "_VIA" as much as possible.
Simply refuses to use the motorway because of explicit [bicycle=no].

<http://gis.19327.n8.nabble.com/file/t344065/3_Routing_Foot_Bicycle_Start_VIA_Finish_OK.png>

Just a "proof of concept" question!
I'm considering to migrate for my Car-map to mkgmap-default-style.
Car only, so incorrect routing for foot/bicycle is no issue. For me...

Eric (AnkEric)




--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Question (only): Is mkgmap-default-style Routing by foot/bicycle according to Usecase ?

[AnkEric]

Is mkgmap-default-style Routing by foot/bicycle according to Usecase?

1. Navigate from "_START" to "_FINISH".
Routing is OK for both foot and bicycle.
Routing will not use the Motorway. 


 

2. Add one Viapoint "_VIA" AND put it ON the Motorway.
My deliberate Error is just for "testing" purposes. Although I have made the
same mistake in real life several times.
Foot and Cycling are very much prohibited on the Motorway.
Now Routing will follow the Motorway. Which is an error, dangerous and an
offence.


 

3. My "own" Map is specific to Car or Bicycle or Foot only.
My Bicycle_Map (or Foot_Map) will avoid the "_VIA" as much as possible.
Simply refuses to use the motorway because of explicit [bicycle=no].


 

Just a "proof of concept" question!
I'm considering to migrate for my Car-map to mkgmap-default-style.
Car only, so incorrect routing for foot/bicycle is no issue. For me...

Eric (AnkEric)




--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question (RFC): Is function [has-period-ended] an option?

[Gerd Petermann]

Hi Eric,

I don't see how this function improves mkgmap. Such a check makes sense in OSM 
QA tools like Osmose.
FWIW: You can use overpass wizzard to search for e.g. access:conditional~"- 
*2019"

Gerd


Von: mkgmap-dev  im Auftrag von AnkEric 

Gesendet: Samstag, 21. März 2020 10:42
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Question (RFC): Is function [has-period-ended] an 
option?

Mapillary, Survey, local knowledge: road closure in future from date_start
till date_end

https://www.mapillary.com/map/im/a4s9RiyhwiYQ2KecMuD2HQ

I can see this Closure on the Map by "red dots" showing on the way.
Hoover over or Click to show [opening_hours] or [access:conditional].
This is a "Warning" only, not implying routing is not possible.
So if I forget to Delete these tags afterwards (by the end of construction
period): no harm.
Also planning a future route is still possible (routing is possible) if my
trip is after construction period has ended.

<http://gis.19327.n8.nabble.com/file/t344065/Closed_by_opening_hours.png>

In JOSM:

<http://gis.19327.n8.nabble.com/file/t344065/Closed_by_opening_hours_JOSM.png>

My Challence:
I have to Delete these tags once Construction Period has ended:
access:conditional=no@ (2020 Mar 20 18:00-24:00;2020 Mar 21-22 00:00-24:00;
2020 Mar 23 00:00-06:00)
fixme=TO BE DELETED Construction period ENDS 2020 Mar 23 06:00

The fixme is a reminder warning: PLEASE DELETE by "2020 Mar 23". Don't
forget, since this is sloppy and poluting the map.

The requested Function should return an Offset between
[LAST_DATE_ALSO_HAVING_YEAR_SPECIFIED] and an Offset_Date (" mmm dd").
So the Challenge is to find the "Last date" (" mmm dd") in a complex
opening_hours or conditional  value.
The value to supply is up to me:
${bicycle:conditional}
${access:conditional}
${opening_hours}

In above example Value_Last_Date to be found is: "2020 Mar 23".
Hours are to be ignored (not relevant).

This - example - warning has not yet "ended". It's still active!
Next week I should Delete it.

FWIW: OpenFietsMap also shows these warnings (it was introduced by OFM).
Only disadvantage: only Rendered on cycleways. IMO it should be Rendered on
ALL ways.

And I hate running into a construction-closure-trap! Most specific on
bicycle these closures should be avoided in trip-route-planning.






--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question (RFC): Is function [has-period-ended] an option?

[AnkEric]

Mapillary, Survey, local knowledge: road closure in future from date_start
till date_end

https://www.mapillary.com/map/im/a4s9RiyhwiYQ2KecMuD2HQ

I can see this Closure on the Map by "red dots" showing on the way.
Hoover over or Click to show [opening_hours] or [access:conditional].
This is a "Warning" only, not implying routing is not possible.
So if I forget to Delete these tags afterwards (by the end of construction
period): no harm.
Also planning a future route is still possible (routing is possible) if my
trip is after construction period has ended.

 

In JOSM:

 

My Challence:
I have to Delete these tags once Construction Period has ended:
access:conditional=no@ (2020 Mar 20 18:00-24:00;2020 Mar 21-22 00:00-24:00;
2020 Mar 23 00:00-06:00)
fixme=TO BE DELETED Construction period ENDS 2020 Mar 23 06:00

The fixme is a reminder warning: PLEASE DELETE by "2020 Mar 23". Don't
forget, since this is sloppy and poluting the map.

The requested Function should return an Offset between
[LAST_DATE_ALSO_HAVING_YEAR_SPECIFIED] and an Offset_Date (" mmm dd").
So the Challenge is to find the "Last date" (" mmm dd") in a complex
opening_hours or conditional  value.
The value to supply is up to me:
${bicycle:conditional}
${access:conditional}
${opening_hours}

In above example Value_Last_Date to be found is: "2020 Mar 23".
Hours are to be ignored (not relevant).

This - example - warning has not yet "ended". It's still active!
Next week I should Delete it.

FWIW: OpenFietsMap also shows these warnings (it was introduced by OFM).
Only disadvantage: only Rendered on cycleways. IMO it should be Rendered on
ALL ways.

And I hate running into a construction-closure-trap! Most specific on
bicycle these closures should be avoided in trip-route-planning.






--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question (RFC): Is function [has-period-ended] an option?

[Gerd Petermann]

Hi Eric,

I fear I don't understand what this post is about. The program doesn't evaluate 
opening_hours or similar tags. It would be possible to add a style function
which would expect a valid date and calculate an offset to another date like 
maybe current date-time or a given date which might be in the past or in the 
future.
How would you use this to improve the map? If you just want to parse your fixme 
tags I'd say it is not related to mkgmap.
The evaluation of the meaning of an opening_hours value is very complex, see 
https://github.com/simonpoole/OpeningHoursParser

Gerd


Von: mkgmap-dev  im Auftrag von AnkEric 

Gesendet: Freitag, 20. März 2020 15:13
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Question (RFC): Is function [has-period-ended] an option?

Way/Area closure Period (from date_start until date_end) is – in general –
not on OSM.

Some exceptions:

opening_hours = Mar 15-Jun 15 off "bird breeding season"

Construction period is between two dates.

Or:
opening_hours = 2019 Feb 18-2019 Mar 29 closed "Reconstruction period
Defensie Eiland"

Or:
access:conditional = no @ (2019 Feb 18-2019 Mar 29)

For me it's hard to not forget to remove by the end of construction period.

Therefore I Set:
fixme = opening_hours to be deleted by 2019 Mar 21

Still, hard to not forget.

Question: Can mkgmap implement a new function?
[period-has-ended]
Function:
 - Is there a date (" mmm dd") in opening_hours? Including ""?
 - If yes, find the last date.
 - If Today > Last_date Then [has-period-ended] = True

Even better:
Function has-period-ended (MyDate).
Opening_hours (closure) will have ended (or not) after Map production date
or start of my holiday: MyDate.

I guess mkgmap Logging option (-Dlog.config=filename) can be used to
generate a text file having all my Errors. I do hope { echotags "Error
message... " } can be logged as well.
Or I could Render outdated Warnings on the Map, differently from actual
Warnings.

And if this is an option, has mkgmap a preference for [opening_hours] or
[access:conditional]?
access:conditional is more straight forward, easier to interpret.
But opening_hours has the option to add free text: "Reconstruction period
Defensie Eiland", "ferry during working hours" (extra information and
explanation).




--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Question (RFC): Is function [has-period-ended] an option?

[AnkEric]

Way/Area closure Period (from date_start until date_end) is – in general –
not on OSM.

Some exceptions:

opening_hours = Mar 15-Jun 15 off "bird breeding season"

Construction period is between two dates.

Or:
opening_hours = 2019 Feb 18-2019 Mar 29 closed "Reconstruction period
Defensie Eiland"

Or:
access:conditional = no @ (2019 Feb 18-2019 Mar 29)

For me it's hard to not forget to remove by the end of construction period.

Therefore I Set:
fixme = opening_hours to be deleted by 2019 Mar 21

Still, hard to not forget.

Question: Can mkgmap implement a new function?
[period-has-ended]
Function:
 - Is there a date (" mmm dd") in opening_hours? Including ""?
 - If yes, find the last date.
 - If Today > Last_date Then [has-period-ended] = True

Even better:
Function has-period-ended (MyDate).
Opening_hours (closure) will have ended (or not) after Map production date
or start of my holiday: MyDate.

I guess mkgmap Logging option (-Dlog.config=filename) can be used to
generate a text file having all my Errors. I do hope { echotags "Error
message... " } can be logged as well.
Or I could Render outdated Warnings on the Map, differently from actual
Warnings.

And if this is an option, has mkgmap a preference for [opening_hours] or
[access:conditional]?
access:conditional is more straight forward, easier to interpret.
But opening_hours has the option to add free text: "Reconstruction period
Defensie Eiland", "ferry during working hours" (extra information and
explanation).




--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about ovm-work-files

[Gerd Petermann]

When you create an overview map and the ovm file is found it is used, else
mkgmap adds an empty area in the overview map.

Gerd

Carlos Dávila-2 wrote
> I don't see any option to tell mkgmap to reuse them. How is it done?
> 
> El 22/11/16 a las 19:42, Gerd Petermann escribió:
>> Hi Carlos,
>>
>> yes, you can reuse the tiles for this.
>>
>> Gerd
>>
>> Carlos Dávila-4 wrote
>>> mkgmap keeps ovm files unless --remove-ovm-work-files=true is specified.
>>> What are these files useful for once overview map is created? Can they
>>> be reused afterwards, for example if you create two or more img from the
>>> same input tiles or if you combine previously created img in a later
>>> step?
>>>
>>>
>>> ___
>>> mkgmap-dev mailing list
>>> mkgmap-dev@.org
>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://gis.19327.n8.nabble.com/Question-about-ovm-work-files-tp5886386p5886387.html
>> Sent from the Mkgmap Development mailing list archive at Nabble.com.
>> ___
>> mkgmap-dev mailing list
>> 

> mkgmap-dev@.org

>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> 
> 
> -- 
> Por favor, no me envíe documentos con extensiones .doc, .docx, .xls,
> .xlsx, .ppt, .pptx, .mdb, mdbx
> Instale LibreOffice desde http://es.libreoffice.org/descarga/
> LibreOffice es libre: se puede copiar, modificar y redistribuir
> libremente. Gratis y totalmente legal.
> LibreOffice está en continuo desarrollo y no tendrá que pagar por las
> nuevas versiones.
> 
> ___
> mkgmap-dev mailing list

> mkgmap-dev@.org

> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





--
View this message in context: 
http://gis.19327.n8.nabble.com/Question-about-ovm-work-files-tp5886386p5886391.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about ovm-work-files

[Carlos Dávila]

I don't see any option to tell mkgmap to reuse them. How is it done?

El 22/11/16 a las 19:42, Gerd Petermann escribió:

Hi Carlos,

yes, you can reuse the tiles for this.

Gerd

Carlos Dávila-4 wrote

mkgmap keeps ovm files unless --remove-ovm-work-files=true is specified.
What are these files useful for once overview map is created? Can they
be reused afterwards, for example if you create two or more img from the
same input tiles or if you combine previously created img in a later step?


___
mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





--
View this message in context: 
http://gis.19327.n8.nabble.com/Question-about-ovm-work-files-tp5886386p5886387.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



--
Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, 
.ppt, .pptx, .mdb, mdbx
Instale LibreOffice desde http://es.libreoffice.org/descarga/
LibreOffice es libre: se puede copiar, modificar y redistribuir libremente. 
Gratis y totalmente legal.
LibreOffice está en continuo desarrollo y no tendrá que pagar por las nuevas 
versiones.

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about ovm-work-files

[Gerd Petermann]

Hi Carlos,

yes, you can reuse the tiles for this.

Gerd

Carlos Dávila-4 wrote
> mkgmap keeps ovm files unless --remove-ovm-work-files=true is specified. 
> What are these files useful for once overview map is created? Can they 
> be reused afterwards, for example if you create two or more img from the 
> same input tiles or if you combine previously created img in a later step?
> 
> 
> ___
> mkgmap-dev mailing list

> mkgmap-dev@.org

> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





--
View this message in context: 
http://gis.19327.n8.nabble.com/Question-about-ovm-work-files-tp5886386p5886387.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Question about ovm-work-files

[Carlos Dávila]

mkgmap keeps ovm files unless --remove-ovm-work-files=true is specified. 
What are these files useful for once overview map is created? Can they 
be reused afterwards, for example if you create two or more img from the 
same input tiles or if you combine previously created img in a later step?



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about high density Contour Lines

[Gerd Petermann]

Hi Markus,

did you get my answer to your previous post here ?  See
http://gis.19327.n5.nabble.com/Garmin-Contour-Lines-tp5871714p5871720.html

Gerd

Markus P. wrote
> Hello
> 
> Is there a limit of minimum Contour-Line spacing ?
> Because my own created Contour-Lines look a little squared and overlap
> each other.
> 
> I use Global-Mapper to export Contour-Lines as a .osm File.
> So mkgmap should be able to convert the Contour-Lines into a Garmin Map.
> 
> Can anyone tell me how to create ContourLines with a spacing of 1m or 50cm
> as a separate Map?
> 
> glg Markus
> ___
> mkgmap-dev mailing list

> mkgmap-dev@.org

> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





--
View this message in context: 
http://gis.19327.n5.nabble.com/Question-about-high-density-Contour-Lines-tp5872228p5872231.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Question about high density Contour Lines

[Markus P.]

Hello

Is there a limit of minimum Contour-Line spacing ?
Because my own created Contour-Lines look a little squared and overlap each 
other.

I use Global-Mapper to export Contour-Lines as a .osm File.
So mkgmap should be able to convert the Contour-Lines into a Garmin Map.

Can anyone tell me how to create ContourLines with a spacing of 1m or 50cm as a 
separate Map?

glg Markus
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about the overview map

[Thomas Morgenstern]

Hallo, ich habe die WW Autoroute DEM Basemap 3.0 auf meinem Nüvi. Bei 
Bedarf kannst mich privat unter tho...@img2ms.de kontaktieren. ~50 MB 
Dateigröße

mfg

Am 19.04.2016 um 21:13 schrieb Jakob Mühldorfer:

Can one get these basemaps somewhere?
The one on my Nüvi 205 is gone (yes that was my fault, i admit)

Am 19.04.2016 um 20:57 schrieb franco_bez:

Hi Andrzej,

my map reaches up to zoom level 16.

I just tested, and you are right, starting from a certain Zoom level the
Basemap takes over if enabled.
With my map the 50km Zoom still shows my map, no basemap visible. 
Beginning
from 80km there is only the Basemap, and the device becomes reactive 
again.


Thanks again for the hint :-)

Ciao,
   Franco



--
View this message in context: 
http://gis.19327.n5.nabble.com/Question-about-the-overview-map-tp5872108p5872169.html

Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about the overview map

[Jakob Mühldorfer]

Can one get these basemaps somewhere?
The one on my Nüvi 205 is gone (yes that was my fault, i admit)

Am 19.04.2016 um 20:57 schrieb franco_bez:

Hi Andrzej,

my map reaches up to zoom level 16.

I just tested, and you are right, starting from a certain Zoom level the
Basemap takes over if enabled.
With my map the 50km Zoom still shows my map, no basemap visible. Beginning
from 80km there is only the Basemap, and the device becomes reactive again.

Thanks again for the hint :-)

Ciao,
   Franco



--
View this message in context: 
http://gis.19327.n5.nabble.com/Question-about-the-overview-map-tp5872108p5872169.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about the overview map

[franco_bez]

Hi Andrzej,

my map reaches up to zoom level 16.

I just tested, and you are right, starting from a certain Zoom level the
Basemap takes over if enabled.
With my map the 50km Zoom still shows my map, no basemap visible. Beginning
from 80km there is only the Basemap, and the device becomes reactive again.

Thanks again for the hint :-)

Ciao,
  Franco



--
View this message in context: 
http://gis.19327.n5.nabble.com/Question-about-the-overview-map-tp5872108p5872169.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about the overview map

[Andrzej Popowski]

Hi Franco,

GPS should switch to basemap at lower scale, if basemap is enabled.

Maybe your map has extended level definition? Basemap starts at 
resolution 17, I think you should limit your detailed map to levels with 
resolution 24-18.


--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about the overview map

[franco_bez]

popej wrote
> have you enabled base map in GPS? It should be item like "Worldwide DEM 
> Basemap" in menu of your GPS.

Hi Andrzej,

No I do not have the Basemap enabled, anyway it's really old. 
Maybe it would show up in the blank spaces, maybe not.
But even if I enable the GARMIN Basemap my OSM map will still not perform
well in these extreme Zoom Levels. 
It slows down reactiveness of my device and almost crashes the system trying
to render the OSM map in 120km Zoom.

I think that best practice is to avoid these Zoom Levels.

Ciao,
  Franco




--
View this message in context: 
http://gis.19327.n5.nabble.com/Question-about-the-overview-map-tp5872108p5872146.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about the overview map

[Andrzej Popowski]

Hi Franco,

have you enabled base map in GPS? It should be item like "Worldwide DEM 
Basemap" in menu of your GPS.


--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about the overview map

[franco_bez]

Hi Thorsten and Andrzej,

thanks for the feedback.

In the map style I use there are no details on the top level.
Only Motorways and Major Cities.

Zooming out to the scale "30km" works  fine, but zooming further out does
not really work.

Here's a sample:
 

So I think I will have to live with the limitation of my old Oregon.

Ciao,
 Franco



--
View this message in context: 
http://gis.19327.n5.nabble.com/Question-about-the-overview-map-tp5872108p5872144.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about the overview map

[Andrzej Popowski]

Hi Franco,

> Is there any way to get an overview map working on the mobile device,
> or do we have to avoid zooming out too far?

Each Garmin GPS comes with base map preinstalled. It is a world map 
similar to preview map on PC. GPS displays base map when you zoom out.


You can replace base map with preview map, but there is not much reason 
to do it.


--
Best regards,
Andrzej

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about the overview map

[Thorsten Kukuk]

On Mon, Apr 18, franco_bez wrote:

> Is it true that the overview map is only used by Mapsource and Bascamp on the
> PC, but does not work on the mobile devices themselves ?

Yes.

> Is there any way to get an overview map working on the mobile device, or do
> we have to avoid zooming out too far?

For this, there are the resolutions/levels.

With every level, I display less informations, and with the 
highest level/lowest resolution, I only display the same few
informations as with the overview map, means mostly highways
and the POI of some very big cities. This works pretty well
on my 62s.

  Thorsten

-- 
Thorsten Kukuk, Senior Architect SLES & Common Code Base
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Question about the overview map

[franco_bez]

Is it true that the overview map is only used by Mapsource and Bascamp on the
PC, but does not work on the mobile devices themselves ?

I'm looking for a solution for the following problem:

When you zoom out to a really big scale ( 100km for instance ) the Oregon
will not be able to render all of the display area. Of course  the map is
large enough ( DACH ) , but if you zoom out to show all of Germany at once
the Oregon can not handle this.

I suspect that it has to scan all the 3.8GB of my dach.img for elements to
display and this is simply too much.

I thought that an overview map might fix this problem.

Is there any way to get an overview map working on the mobile device, or do
we have to avoid zooming out too far?

Ciao,
  Franco



--
View this message in context: 
http://gis.19327.n5.nabble.com/Question-about-the-overview-map-tp5872108.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about using different ROAD CLASS's andROAD SPEED's for one linetype.

[Walter Schlögl]

Greg,
I can still not find any error in your code, no idea, why it’s not working.
Walter

From: greg crago 
Sent: Wednesday, March 09, 2016 7:28 PM
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Question about using different ROAD CLASS's andROAD 
SPEED's for one linetype.

Walter I tried again, and STILL get my CUSTOM ICONS and GENERIC ICONS drawn on 
top of each other. 
This time I am initializing the variable mkgmap_symbol=no 


amenity=fast_food { set mkgmap_symbol=no }
amenity=fast_food & cuisine=grill [0x2a03 resolution 24]
amenity=fast_food & name ~ '.*[Aa]rby.*'   {set mkgmap_symbol=yes} 
[0x6017 resolution 24 continue]
amenity=fast_food & name ~ '.*[Bb]urger [Kk]ing.*' {set mkgmap_symbol=yes} 
[0x6016 resolution 24 continue]
amenity=fast_food & name ~ '.*[Dd]onald.*' {set mkgmap_symbol=yes} 
[0x6007 resolution 24 continue]
amenity=fast_food & name ~ '.*[Dd]omino.*' {set mkgmap_symbol=yes} 
[0x6011 resolution 24 continue]

amenity=fast_food & name ~ '.*KFC.*'   {set mkgmap_symbol=ye;} 
[0x6006 resolution 24 continue]
amenity=fast_food & name ~ '.*[Pp]izza [Hh]ut.*'   {set mkgmap_symbol=yes} 
[0x6004 resolution 24 continue]
amenity=fast_food & name ~ '.*[Ss]ubway.*' {set mkgmap_symbol=yes} 
[0x600F resolution 24 continue]
amenity=fast_food & name ~ '.*[Tt]aco [Bb]ell.*'   {set mkgmap_symbol=yes} 
[0x6008 resolution 24 continue]
amenity=fast_food & name ~ '.*[Ww]endy.*'  {set mkgmap_symbol=yes} 
[0x6005 resolution 24 continue]
amenity=fast_food & mkgmap_symbol!=yes { name '${name}'} [0x6012 resolution 24 
continue]
amenity=fast_food [0x2a07 resolution 24]

Do I have a syntax error?

Greg

On Tue, Mar 8, 2016 at 11:07 PM, greg crago <gregcr...@gmail.com> wrote:

  Walter, I am getting both my CUSTOM Fast Food Symbols and my GENERIC fast 
Food symbols drawn on top of each other. 

  Here is my fast food section in my POINT file:

  amenity=fast_food & name ~ '.*[Aa]rby.*'   {set mkgmap:label:1=' '; 
set mkgmap_fast_food_symbol=yes} [0x6017 resolution 24 continue]
  amenity=fast_food & name ~ '.*[Bb]urger [Kk]ing.*' {set mkgmap:label:1=' '; 
set mkgmap_fast_food_symbol=yes} [0x6016 resolution 24 continue]
  amenity=fast_food & name ~ '.*[Dd]onald.*' {set mkgmap:label:1=' '; 
set mkgmap_fast_food_symbol=yes} [0x6007 resolution 24 continue]
  amenity=fast_food & name ~ '.*[Dd]omino.*' {set mkgmap:label:1=' '; 
set mkgmap_fast_food_symbol=yes} [0x6011 resolution 24 continue]
  amenity=fast_food & name ~ '.*KFC.*'   {set mkgmap:label:1=' '; 
set mkgmap_fast_food_symbol=yes} [0x6006 resolution 24 continue]
  amenity=fast_food & name ~ '.*[Pp]izza [Hh]ut.*'   {set mkgmap:label:1=' '; 
set mkgmap_fast_food_symbol=yes} [0x6004 resolution 24 continue]
  amenity=fast_food & name ~ '.*[Ss]ubway.*' {set mkgmap:label:1=' '; 
set mkgmap_fast_food_symbol=yes} [0x600F resolution 24 continue]
  amenity=fast_food & name ~ '.*[Tt]aco [Bb]ell.*'   {set mkgmap:label:1=' '; 
set mkgmap_fast_food_symbol=yes} [0x6008 resolution 24 continue]
  amenity=fast_food & name ~ '.*[Ww]endy.*'  {set mkgmap:label:1=' '; 
set mkgmap_fast_food_symbol=yes} [0x6005 resolution 24 continue]
  amenity=fast_food & mkgmap_fast_food_symbol!=yes { name '${name}'} [0x6012 
resolution 24 continue]
  amenity=fast_food [0x2a07 resolution 24]

  0x6012 is my Generic Fast Food icon
  0x2a07 is my INVISIBLE fast food icon for POI searchability

  Can I add a variable "mkgmap_fast_food_symbol=yes" and test it later?

  I am using similar variables for my other categories (fuel [set 
mkgmap_fuel_symbol=yes] , restaurants [mkgmap_restaurant_symbol=yes])

  Greg

  On Sun, Mar 6, 2016 at 4:29 PM, greg crago <gregcr...@gmail.com> wrote:

I have not tested POI search capability on my GPS and I suspect "NO" I do 
not think it will work without CONTINUE. 

I added  mkgmap:label:1=' ', because I did not want the NAME obscuring the 
ICON symbol so I blanked out the name


Greg

On Sun, Mar 6, 2016 at 10:17 AM, Walter Schlögl 
<walter.schloegl-re...@aon.at> wrote:

  Hi Greg,

  in my code it is working with CONTINUE as well as with 
CONTINUE_WITH_ACTIONS
  but it is not working without CONTINUE.

  I am using CONTINUE only if I need the function CONTINUE without actions, 
which is very seldom.

  Is this code working in your script without any CONTINUE?
  If yes, then I do not understand why.
  What is {set mkgmap:label:1=' '} doing?

  Walter

  From: greg crago 
  Sent: Sunday, March 06, 2016 4:12 PM
  To: Development list for mkgmap 
  Subject: Re: [mkgmap-dev] Question about using different ROAD CLASS's 
andROAD SPEED's for one linetype.

  If I have a list of custom FUEL icons in my line file: 

  amenity=fuel & (name ~ '.*[Bb][Pp].*' | brand ~ '.*[Bb

Re: [mkgmap-dev] Question about using different ROAD CLASS's andROAD SPEED's for one linetype.

[greg crago]

Walter I tried again, and STILL get my CUSTOM ICONS and GENERIC ICONS drawn
on top of each other.
This time I am initializing the variable mkgmap_symbol=no


amenity=fast_food { set mkgmap_symbol=no }
amenity=fast_food & cuisine=grill [0x2a03 resolution 24]
amenity=fast_food & name ~ '.*[Aa]rby.*'   {set mkgmap_symbol=yes}
[0x6017 resolution 24 continue]
amenity=fast_food & name ~ '.*[Bb]urger [Kk]ing.*' {set mkgmap_symbol=yes}
[0x6016 resolution 24 continue]
amenity=fast_food & name ~ '.*[Dd]onald.*' {set mkgmap_symbol=yes}
[0x6007 resolution 24 continue]
amenity=fast_food & name ~ '.*[Dd]omino.*' {set mkgmap_symbol=yes}
[0x6011 resolution 24 continue]
amenity=fast_food & name ~ '.*KFC.*'   {set mkgmap_symbol=ye;}
[0x6006 resolution 24 continue]
amenity=fast_food & name ~ '.*[Pp]izza [Hh]ut.*'   {set mkgmap_symbol=yes}
[0x6004 resolution 24 continue]
amenity=fast_food & name ~ '.*[Ss]ubway.*' {set mkgmap_symbol=yes}
[0x600F resolution 24 continue]
amenity=fast_food & name ~ '.*[Tt]aco [Bb]ell.*'   {set mkgmap_symbol=yes}
[0x6008 resolution 24 continue]
amenity=fast_food & name ~ '.*[Ww]endy.*'  {set mkgmap_symbol=yes}
[0x6005 resolution 24 continue]
amenity=fast_food & mkgmap_symbol!=yes { name '${name}'} [0x6012 resolution
24 continue]
amenity=fast_food [0x2a07 resolution 24]

Do I have a syntax error?

Greg

On Tue, Mar 8, 2016 at 11:07 PM, greg crago <gregcr...@gmail.com> wrote:

> Walter, I am getting both my CUSTOM Fast Food Symbols and my GENERIC fast
> Food symbols drawn on top of each other.
>
> Here is my fast food section in my POINT file:
>
> amenity=fast_food & name ~ '.*[Aa]rby.*'   {set mkgmap:label:1='
> '; set mkgmap_fast_food_symbol=yes} [0x6017 resolution 24 continue]
> amenity=fast_food & name ~ '.*[Bb]urger [Kk]ing.*' {set mkgmap:label:1='
> '; set mkgmap_fast_food_symbol=yes} [0x6016 resolution 24 continue]
> amenity=fast_food & name ~ '.*[Dd]onald.*' {set mkgmap:label:1='
> '; set mkgmap_fast_food_symbol=yes} [0x6007 resolution 24 continue]
> amenity=fast_food & name ~ '.*[Dd]omino.*' {set mkgmap:label:1='
> '; set mkgmap_fast_food_symbol=yes} [0x6011 resolution 24 continue]
> amenity=fast_food & name ~ '.*KFC.*'   {set mkgmap:label:1='
> '; set mkgmap_fast_food_symbol=yes} [0x6006 resolution 24 continue]
> amenity=fast_food & name ~ '.*[Pp]izza [Hh]ut.*'   {set mkgmap:label:1='
> '; set mkgmap_fast_food_symbol=yes} [0x6004 resolution 24 continue]
> amenity=fast_food & name ~ '.*[Ss]ubway.*' {set mkgmap:label:1='
> '; set mkgmap_fast_food_symbol=yes} [0x600F resolution 24 continue]
> amenity=fast_food & name ~ '.*[Tt]aco [Bb]ell.*'   {set mkgmap:label:1='
> '; set mkgmap_fast_food_symbol=yes} [0x6008 resolution 24 continue]
> amenity=fast_food & name ~ '.*[Ww]endy.*'  {set mkgmap:label:1='
> '; set mkgmap_fast_food_symbol=yes} [0x6005 resolution 24 continue]
> amenity=fast_food & mkgmap_fast_food_symbol!=yes { name '${name}'} [0x6012
> resolution 24 continue]
> amenity=fast_food [0x2a07 resolution 24]
>
> 0x6012 is my Generic Fast Food icon
> 0x2a07 is my INVISIBLE fast food icon for POI searchability
>
> Can I add a variable "mkgmap_fast_food_symbol=yes" and test it later?
>
> I am using similar variables for my other categories (fuel [set
> mkgmap_fuel_symbol=yes] , restaurants [mkgmap_restaurant_symbol=yes])
>
> Greg
>
> On Sun, Mar 6, 2016 at 4:29 PM, greg crago <gregcr...@gmail.com> wrote:
>
>> I have not tested POI search capability on my GPS and I suspect "NO" I do
>> not think it will work without CONTINUE.
>>
>> I added  mkgmap:label:1=' ', because I did not want the NAME obscuring
>> the ICON symbol so I blanked out the name
>>
>> Greg
>>
>> On Sun, Mar 6, 2016 at 10:17 AM, Walter Schlögl <
>> walter.schloegl-re...@aon.at> wrote:
>>
>>> Hi Greg,
>>>
>>> in my code it is working with CONTINUE as well as with
>>> CONTINUE_WITH_ACTIONS
>>> but it is not working without CONTINUE.
>>>
>>> I am using CONTINUE only if I need the function CONTINUE without
>>> actions, which is very seldom.
>>>
>>> Is this code working in your script without any CONTINUE?
>>> If yes, then I do not understand why.
>>> What is {set mkgmap:label:1=' '} doing?
>>>
>>> Walter
>>>
>>> *From:* greg crago <gregcr...@gmail.com>
>>> *Sent:* Sunday, March 06, 2016 4:12 PM
>>> *To:* Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk>
>>> *Subject:* Re: [mkgmap-dev] Question about using different ROAD CLASS's
>>&g

Re: [mkgmap-dev] Question about using different ROAD CLASS's andROAD SPEED's for one linetype.

[Walter Schlögl]

Hi Greg,

if you are getting both symbol
it means that this condition 
& mkgmap_fast_food_symbol!=yes 
is not evaluated, right?

I have no idea why. 
I am not having this issue with nearly the same code.

Walter

From: greg crago 
Sent: Wednesday, March 09, 2016 5:07 AM
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Question about using different ROAD CLASS's andROAD 
SPEED's for one linetype.

Walter, I am getting both my CUSTOM Fast Food Symbols and my GENERIC fast Food 
symbols drawn on top of each other. 

Here is my fast food section in my POINT file:

amenity=fast_food & name ~ '.*[Aa]rby.*'   {set mkgmap:label:1=' '; set 
mkgmap_fast_food_symbol=yes} [0x6017 resolution 24 continue]
amenity=fast_food & name ~ '.*[Bb]urger [Kk]ing.*' {set mkgmap:label:1=' '; set 
mkgmap_fast_food_symbol=yes} [0x6016 resolution 24 continue]
amenity=fast_food & name ~ '.*[Dd]onald.*' {set mkgmap:label:1=' '; set 
mkgmap_fast_food_symbol=yes} [0x6007 resolution 24 continue]
amenity=fast_food & name ~ '.*[Dd]omino.*' {set mkgmap:label:1=' '; set 
mkgmap_fast_food_symbol=yes} [0x6011 resolution 24 continue]
amenity=fast_food & name ~ '.*KFC.*'   {set mkgmap:label:1=' '; set 
mkgmap_fast_food_symbol=yes} [0x6006 resolution 24 continue]
amenity=fast_food & name ~ '.*[Pp]izza [Hh]ut.*'   {set mkgmap:label:1=' '; set 
mkgmap_fast_food_symbol=yes} [0x6004 resolution 24 continue]
amenity=fast_food & name ~ '.*[Ss]ubway.*' {set mkgmap:label:1=' '; set 
mkgmap_fast_food_symbol=yes} [0x600F resolution 24 continue]
amenity=fast_food & name ~ '.*[Tt]aco [Bb]ell.*'   {set mkgmap:label:1=' '; set 
mkgmap_fast_food_symbol=yes} [0x6008 resolution 24 continue]
amenity=fast_food & name ~ '.*[Ww]endy.*'  {set mkgmap:label:1=' '; set 
mkgmap_fast_food_symbol=yes} [0x6005 resolution 24 continue]
amenity=fast_food & mkgmap_fast_food_symbol!=yes { name '${name}'} [0x6012 
resolution 24 continue]
amenity=fast_food [0x2a07 resolution 24]

0x6012 is my Generic Fast Food icon
0x2a07 is my INVISIBLE fast food icon for POI searchability

Can I add a variable "mkgmap_fast_food_symbol=yes" and test it later?

I am using similar variables for my other categories (fuel [set 
mkgmap_fuel_symbol=yes] , restaurants [mkgmap_restaurant_symbol=yes])

Greg

On Sun, Mar 6, 2016 at 4:29 PM, greg crago <gregcr...@gmail.com> wrote:

  I have not tested POI search capability on my GPS and I suspect "NO" I do not 
think it will work without CONTINUE. 

  I added  mkgmap:label:1=' ', because I did not want the NAME obscuring the 
ICON symbol so I blanked out the name


  Greg

  On Sun, Mar 6, 2016 at 10:17 AM, Walter Schlögl 
<walter.schloegl-re...@aon.at> wrote:

Hi Greg,

in my code it is working with CONTINUE as well as with CONTINUE_WITH_ACTIONS
but it is not working without CONTINUE.

I am using CONTINUE only if I need the function CONTINUE without actions, 
which is very seldom.

Is this code working in your script without any CONTINUE?
If yes, then I do not understand why.
What is {set mkgmap:label:1=' '} doing?

Walter

From: greg crago 
Sent: Sunday, March 06, 2016 4:12 PM
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Question about using different ROAD CLASS's 
andROAD SPEED's for one linetype.

If I have a list of custom FUEL icons in my line file: 

amenity=fuel & (name ~ '.*[Bb][Pp].*' | brand ~ '.*[Bb][Pp].*'){set 
mkgmap:label:1=' '} [0x6018 resolution 24]
amenity=fuel & (name ~ '.*[Cc]itgo.*' | brand ~ '.*[Cc]itgo.*'){set 
mkgmap:label:1=' '} [0x600b resolution 24]
amenity=fuel & (name ~ '.*[Ee]xxon.*' | brand ~ '.*[Ee]xxon.*'){set 
mkgmap:label:1=' '} [0x600a resolution 24]
amenity=fuel & (name ~ '.*[Kk]roger.*' | brand ~ '.*[Kk]roger.*')  {set 
mkgmap:label:1=' '} [0x6003 resolution 24]
amenity=fuel & (name ~ '.*[Mm]arathon.*' | brand ~ '.*[Mm]arathon.*')  {set 
mkgmap:label:1=' '} [0x6009 resolution 24]
amenity=fuel & (name ~ '.*[Mm]obil.*' | brand ~ '.*[Mm]obil.*'){set 
mkgmap:label:1=' '} [0x6001 resolution 24]
amenity=fuel & (name ~ '.*[Ss]hell.*' | brand ~ '.*[Ss]hell.*'){set 
mkgmap:label:1=' '} [0x6000 resolution 24]
amenity=fuel & (name ~ '.*[Ss]peedway.*' | brand ~ '.*[Ss]peedway.*')  {set 
mkgmap:label:1=' '} [0x6002 resolution 24]
amenity=fuel & (name ~ '.*[Ss]unoco.*' | brand ~ '.*[Ss]unoco.*')  {set 
mkgmap:label:1=' '} [0x600d resolution 24]
amenity=fuel & (name ~ '.*[Vv]alero.*' | brand ~ '.*[Vv]alero.*')  {set 
mkgmap:label:1=' '} [0x600c resolution 24]
amenity=fuel {name '$(name)'} [0x2f01 resolution 24]

You are telling me that these will NOT be found in a FUEL SEARCH (0x2f01) 
on the GPS because I do not have 'continue_with_actions' at the end of each 
action?

Do I have to add CON

Re: [mkgmap-dev] Question about using different ROAD CLASS's andROAD SPEED's for one linetype.

[greg crago]

Walter, I am getting both my CUSTOM Fast Food Symbols and my GENERIC fast
Food symbols drawn on top of each other.

Here is my fast food section in my POINT file:

amenity=fast_food & name ~ '.*[Aa]rby.*'   {set mkgmap:label:1=' ';
set mkgmap_fast_food_symbol=yes} [0x6017 resolution 24 continue]
amenity=fast_food & name ~ '.*[Bb]urger [Kk]ing.*' {set mkgmap:label:1=' ';
set mkgmap_fast_food_symbol=yes} [0x6016 resolution 24 continue]
amenity=fast_food & name ~ '.*[Dd]onald.*' {set mkgmap:label:1=' ';
set mkgmap_fast_food_symbol=yes} [0x6007 resolution 24 continue]
amenity=fast_food & name ~ '.*[Dd]omino.*' {set mkgmap:label:1=' ';
set mkgmap_fast_food_symbol=yes} [0x6011 resolution 24 continue]
amenity=fast_food & name ~ '.*KFC.*'   {set mkgmap:label:1=' ';
set mkgmap_fast_food_symbol=yes} [0x6006 resolution 24 continue]
amenity=fast_food & name ~ '.*[Pp]izza [Hh]ut.*'   {set mkgmap:label:1=' ';
set mkgmap_fast_food_symbol=yes} [0x6004 resolution 24 continue]
amenity=fast_food & name ~ '.*[Ss]ubway.*' {set mkgmap:label:1=' ';
set mkgmap_fast_food_symbol=yes} [0x600F resolution 24 continue]
amenity=fast_food & name ~ '.*[Tt]aco [Bb]ell.*'   {set mkgmap:label:1=' ';
set mkgmap_fast_food_symbol=yes} [0x6008 resolution 24 continue]
amenity=fast_food & name ~ '.*[Ww]endy.*'  {set mkgmap:label:1=' ';
set mkgmap_fast_food_symbol=yes} [0x6005 resolution 24 continue]
amenity=fast_food & mkgmap_fast_food_symbol!=yes { name '${name}'} [0x6012
resolution 24 continue]
amenity=fast_food [0x2a07 resolution 24]

0x6012 is my Generic Fast Food icon
0x2a07 is my INVISIBLE fast food icon for POI searchability

Can I add a variable "mkgmap_fast_food_symbol=yes" and test it later?

I am using similar variables for my other categories (fuel [set
mkgmap_fuel_symbol=yes] , restaurants [mkgmap_restaurant_symbol=yes])

Greg

On Sun, Mar 6, 2016 at 4:29 PM, greg crago <gregcr...@gmail.com> wrote:

> I have not tested POI search capability on my GPS and I suspect "NO" I do
> not think it will work without CONTINUE.
>
> I added  mkgmap:label:1=' ', because I did not want the NAME obscuring
> the ICON symbol so I blanked out the name
>
> Greg
>
> On Sun, Mar 6, 2016 at 10:17 AM, Walter Schlögl <
> walter.schloegl-re...@aon.at> wrote:
>
>> Hi Greg,
>>
>> in my code it is working with CONTINUE as well as with
>> CONTINUE_WITH_ACTIONS
>> but it is not working without CONTINUE.
>>
>> I am using CONTINUE only if I need the function CONTINUE without
>> actions, which is very seldom.
>>
>> Is this code working in your script without any CONTINUE?
>> If yes, then I do not understand why.
>> What is {set mkgmap:label:1=' '} doing?
>>
>> Walter
>>
>> *From:* greg crago <gregcr...@gmail.com>
>> *Sent:* Sunday, March 06, 2016 4:12 PM
>> *To:* Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk>
>> *Subject:* Re: [mkgmap-dev] Question about using different ROAD CLASS's
>> andROAD SPEED's for one linetype.
>>
>> If I have a list of custom FUEL icons in my line file:
>>
>> amenity=fuel & (name ~ '.*[Bb][Pp].*' | brand ~ '.*[Bb][Pp].*')
>> {set mkgmap:label:1=' '} [0x6018 resolution 24]
>> amenity=fuel & (name ~ '.*[Cc]itgo.*' | brand ~ '.*[Cc]itgo.*')
>> {set mkgmap:label:1=' '} [0x600b resolution 24]
>> amenity=fuel & (name ~ '.*[Ee]xxon.*' | brand ~ '.*[Ee]xxon.*')
>> {set mkgmap:label:1=' '} [0x600a resolution 24]
>> amenity=fuel & (name ~ '.*[Kk]roger.*' | brand ~ '.*[Kk]roger.*')
>> {set mkgmap:label:1=' '} [0x6003 resolution 24]
>> amenity=fuel & (name ~ '.*[Mm]arathon.*' | brand ~ '.*[Mm]arathon.*')
>> {set mkgmap:label:1=' '} [0x6009 resolution 24]
>> amenity=fuel & (name ~ '.*[Mm]obil.*' | brand ~ '.*[Mm]obil.*')
>> {set mkgmap:label:1=' '} [0x6001 resolution 24]
>> amenity=fuel & (name ~ '.*[Ss]hell.*' | brand ~ '.*[Ss]hell.*')
>> {set mkgmap:label:1=' '} [0x6000 resolution 24]
>> amenity=fuel & (name ~ '.*[Ss]peedway.*' | brand ~ '.*[Ss]peedway.*')
>> {set mkgmap:label:1=' '} [0x6002 resolution 24]
>> amenity=fuel & (name ~ '.*[Ss]unoco.*' | brand ~ '.*[Ss]unoco.*')
>> {set mkgmap:label:1=' '} [0x600d resolution 24]
>> amenity=fuel & (name ~ '.*[Vv]alero.*' | brand ~ '.*[Vv]alero.*')
>> {set mkgmap:label:1=' '} [0x600c resolution 24]
>> amenity=fuel {name '$(name)'} [0x2f01 resolution 24]
>>
>> You are telling me that these will NOT be found in a FUEL SEARCH (0x2f01)
>> on the GPS because I do not have 'continue_with_actions' at the end of each
>> action?
>>
>> Do I have to add CONTINUE_WITH_ACTIONS or could I just use CONTINU

Re: [mkgmap-dev] Question about using different ROAD CLASS's andROAD SPEED's for one linetype.

[greg crago]

I have not tested POI search capability on my GPS and I suspect "NO" I do
not think it will work without CONTINUE.

I added  mkgmap:label:1=' ', because I did not want the NAME obscuring the
ICON symbol so I blanked out the name

Greg

On Sun, Mar 6, 2016 at 10:17 AM, Walter Schlögl <
walter.schloegl-re...@aon.at> wrote:

> Hi Greg,
>
> in my code it is working with CONTINUE as well as with
> CONTINUE_WITH_ACTIONS
> but it is not working without CONTINUE.
>
> I am using CONTINUE only if I need the function CONTINUE without actions,
> which is very seldom.
>
> Is this code working in your script without any CONTINUE?
> If yes, then I do not understand why.
> What is {set mkgmap:label:1=' '} doing?
>
> Walter
>
> *From:* greg crago <gregcr...@gmail.com>
> *Sent:* Sunday, March 06, 2016 4:12 PM
> *To:* Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk>
> *Subject:* Re: [mkgmap-dev] Question about using different ROAD CLASS's
> andROAD SPEED's for one linetype.
>
> If I have a list of custom FUEL icons in my line file:
>
> amenity=fuel & (name ~ '.*[Bb][Pp].*' | brand ~ '.*[Bb][Pp].*')
> {set mkgmap:label:1=' '} [0x6018 resolution 24]
> amenity=fuel & (name ~ '.*[Cc]itgo.*' | brand ~ '.*[Cc]itgo.*')
> {set mkgmap:label:1=' '} [0x600b resolution 24]
> amenity=fuel & (name ~ '.*[Ee]xxon.*' | brand ~ '.*[Ee]xxon.*')
> {set mkgmap:label:1=' '} [0x600a resolution 24]
> amenity=fuel & (name ~ '.*[Kk]roger.*' | brand ~ '.*[Kk]roger.*')
> {set mkgmap:label:1=' '} [0x6003 resolution 24]
> amenity=fuel & (name ~ '.*[Mm]arathon.*' | brand ~ '.*[Mm]arathon.*')
> {set mkgmap:label:1=' '} [0x6009 resolution 24]
> amenity=fuel & (name ~ '.*[Mm]obil.*' | brand ~ '.*[Mm]obil.*')
> {set mkgmap:label:1=' '} [0x6001 resolution 24]
> amenity=fuel & (name ~ '.*[Ss]hell.*' | brand ~ '.*[Ss]hell.*')
> {set mkgmap:label:1=' '} [0x6000 resolution 24]
> amenity=fuel & (name ~ '.*[Ss]peedway.*' | brand ~ '.*[Ss]peedway.*')
> {set mkgmap:label:1=' '} [0x6002 resolution 24]
> amenity=fuel & (name ~ '.*[Ss]unoco.*' | brand ~ '.*[Ss]unoco.*')
> {set mkgmap:label:1=' '} [0x600d resolution 24]
> amenity=fuel & (name ~ '.*[Vv]alero.*' | brand ~ '.*[Vv]alero.*')
> {set mkgmap:label:1=' '} [0x600c resolution 24]
> amenity=fuel {name '$(name)'} [0x2f01 resolution 24]
>
> You are telling me that these will NOT be found in a FUEL SEARCH (0x2f01)
> on the GPS because I do not have 'continue_with_actions' at the end of each
> action?
>
> Do I have to add CONTINUE_WITH_ACTIONS or could I just use CONTINUE?
>
> If this is correct, this is why you define 0x2f01 as INVISIBLE, but is
> necessary in order to preform a POI SEARCH?
>
> Greg
>
>
>
> On Sun, Mar 6, 2016 at 5:03 AM, Walter Schlögl <
> walter.schloegl-re...@aon.at> wrote:
>
>> Hi Greg,
>>
>> all supermarkets are found in the POI list if you give supermarket the
>> POI Nr 2E02.
>> shop=books is the POI Nr 2E03, shop=mall is POI Nr 2E04 and so on.
>>
>> So usually all supermarkets would have the same Icon also,
>> but with the solution shown below you can give different supermarkets
>> different icons.
>>
>> If you would just map all Aldi-supermarkets to 3501 without continue
>> it would get the correct icon, but not found any longer in the search
>> list.
>>
>> Do you use this feature on your Garmin device, to search for Point of
>> interests?
>>
>> Walter
>>
>>
>> *From:* greg crago <gregcr...@gmail.com>
>> *Sent:* Saturday, March 05, 2016 10:53 PM
>> *To:* Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk>
>> *Subject:* Re: [mkgmap-dev] Question about using different ROAD CLASS's
>> andROAD SPEED's for one linetype.
>>
>> I have re-read your posts and I think I am still confused about your
>> statement
>>
>> "you can also club together POIs with different Icons to the same
>> POI-List entry"
>>
>> Again, what is a 'POI-list entry' and how is this a benefit?
>>
>> I understand about specific store BRANDS and using unique POINTS and then
>> use a GENERIC icon for the rest of the category.
>>
>> Greg
>>
>> On Sat, Mar 5, 2016 at 4:49 AM, Walter Schlögl <
>> walter.schloegl-re...@aon.at> wrote:
>>
>>> Hi Greg,
>>>
>>> here an example for supermarkets
>>>
>>> shop=supermarket & (name~'Hofer.*'  | name~'HOFER.*'){ set
>>> mkgmap_symbol=yes}[0x3501 resolution 23 continue with_actions]
>>> shop=supermarket & (name~'Aldi.*'   | name~'ALDI.*'){ set
>>> 

Re: [mkgmap-dev] Question about using different ROAD CLASS's andROAD SPEED's for one linetype.

[Walter Schlögl]

Hi Greg,

in my code it is working with CONTINUE as well as with CONTINUE_WITH_ACTIONS
but it is not working without CONTINUE.

I am using CONTINUE only if I need the function CONTINUE without actions, which 
is very seldom.

Is this code working in your script without any CONTINUE?
If yes, then I do not understand why.
What is {set mkgmap:label:1=' '} doing?

Walter

From: greg crago 
Sent: Sunday, March 06, 2016 4:12 PM
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Question about using different ROAD CLASS's andROAD 
SPEED's for one linetype.

If I have a list of custom FUEL icons in my line file: 

amenity=fuel & (name ~ '.*[Bb][Pp].*' | brand ~ '.*[Bb][Pp].*'){set 
mkgmap:label:1=' '} [0x6018 resolution 24]
amenity=fuel & (name ~ '.*[Cc]itgo.*' | brand ~ '.*[Cc]itgo.*'){set 
mkgmap:label:1=' '} [0x600b resolution 24]
amenity=fuel & (name ~ '.*[Ee]xxon.*' | brand ~ '.*[Ee]xxon.*'){set 
mkgmap:label:1=' '} [0x600a resolution 24]
amenity=fuel & (name ~ '.*[Kk]roger.*' | brand ~ '.*[Kk]roger.*')  {set 
mkgmap:label:1=' '} [0x6003 resolution 24]
amenity=fuel & (name ~ '.*[Mm]arathon.*' | brand ~ '.*[Mm]arathon.*')  {set 
mkgmap:label:1=' '} [0x6009 resolution 24]
amenity=fuel & (name ~ '.*[Mm]obil.*' | brand ~ '.*[Mm]obil.*'){set 
mkgmap:label:1=' '} [0x6001 resolution 24]
amenity=fuel & (name ~ '.*[Ss]hell.*' | brand ~ '.*[Ss]hell.*'){set 
mkgmap:label:1=' '} [0x6000 resolution 24]
amenity=fuel & (name ~ '.*[Ss]peedway.*' | brand ~ '.*[Ss]peedway.*')  {set 
mkgmap:label:1=' '} [0x6002 resolution 24]
amenity=fuel & (name ~ '.*[Ss]unoco.*' | brand ~ '.*[Ss]unoco.*')  {set 
mkgmap:label:1=' '} [0x600d resolution 24]
amenity=fuel & (name ~ '.*[Vv]alero.*' | brand ~ '.*[Vv]alero.*')  {set 
mkgmap:label:1=' '} [0x600c resolution 24]
amenity=fuel {name '$(name)'} [0x2f01 resolution 24]

You are telling me that these will NOT be found in a FUEL SEARCH (0x2f01) on 
the GPS because I do not have 'continue_with_actions' at the end of each action?

Do I have to add CONTINUE_WITH_ACTIONS or could I just use CONTINUE?

If this is correct, this is why you define 0x2f01 as INVISIBLE, but is 
necessary in order to preform a POI SEARCH?

Greg



On Sun, Mar 6, 2016 at 5:03 AM, Walter Schlögl <walter.schloegl-re...@aon.at> 
wrote:

  Hi Greg,

  all supermarkets are found in the POI list if you give supermarket the POI Nr 
2E02.
  shop=books is the POI Nr 2E03, shop=mall is POI Nr 2E04 and so on.

  So usually all supermarkets would have the same Icon also, 
  but with the solution shown below you can give different supermarkets 
different icons.

  If you would just map all Aldi-supermarkets to 3501 without continue 
  it would get the correct icon, but not found any longer in the search list.

  Do you use this feature on your Garmin device, to search for Point of 
interests?

  Walter


  From: greg crago 
  Sent: Saturday, March 05, 2016 10:53 PM
  To: Development list for mkgmap 
  Subject: Re: [mkgmap-dev] Question about using different ROAD CLASS's andROAD 
SPEED's for one linetype.

  I have re-read your posts and I think I am still confused about your 
statement 

  "you can also club together POIs with different Icons to the same POI-List 
entry"


  Again, what is a 'POI-list entry' and how is this a benefit?


  I understand about specific store BRANDS and using unique POINTS and then use 
a GENERIC icon for the rest of the category.


  Greg

  On Sat, Mar 5, 2016 at 4:49 AM, Walter Schlögl <walter.schloegl-re...@aon.at> 
wrote:

Hi Greg,

here an example for supermarkets

shop=supermarket & (name~'Hofer.*'  | name~'HOFER.*'){ set 
mkgmap_symbol=yes}[0x3501 resolution 23 continue with_actions]
shop=supermarket & (name~'Aldi.*'   | name~'ALDI.*'){ set 
mkgmap_symbol=yes}[0x3501 resolution 23 continue with_actions]
shop=supermarket & (name~'Lidl.*'   | name~'LIDL.*'){ set 
mkgmap_symbol=yes}[0x3502 resolution 23 continue with_actions]
...
shop=supermarket & mkgmap_symbol!=yes
[0x3500 resolution 23 continue with_actions]
shop=supermarket[0x2E02 resolution 
21] # POI

There is one common symbol on 3500 and dedicated symbols on 3501 and above.
(Hofer and Aldi is the same supermarket with the same Logo but with 
different names in Austria and Germany)
If I find a dedicated name of the supermarket, I will show the 
corresponding symbol. (at the moment about 30 in my list)
All other supermarkets will get the common symbol.
And all of them will get additionally an unvisible POI (well, not totally 
unvisible but just 1 dot) for the POI-List
Since this 1 dot POI is placed at resolution 21, I can click on it also in 
lower zoom levels.

I’m doing the same with amenity=fuel (more than 20), shop=car and many 
oth

Re: [mkgmap-dev] Question about using different ROAD CLASS's andROAD SPEED's for one linetype.

[greg crago]

If I have a list of custom FUEL icons in my line file:

amenity=fuel & (name ~ '.*[Bb][Pp].*' | brand ~ '.*[Bb][Pp].*'){set
mkgmap:label:1=' '} [0x6018 resolution 24]
amenity=fuel & (name ~ '.*[Cc]itgo.*' | brand ~ '.*[Cc]itgo.*'){set
mkgmap:label:1=' '} [0x600b resolution 24]
amenity=fuel & (name ~ '.*[Ee]xxon.*' | brand ~ '.*[Ee]xxon.*'){set
mkgmap:label:1=' '} [0x600a resolution 24]
amenity=fuel & (name ~ '.*[Kk]roger.*' | brand ~ '.*[Kk]roger.*')  {set
mkgmap:label:1=' '} [0x6003 resolution 24]
amenity=fuel & (name ~ '.*[Mm]arathon.*' | brand ~ '.*[Mm]arathon.*')  {set
mkgmap:label:1=' '} [0x6009 resolution 24]
amenity=fuel & (name ~ '.*[Mm]obil.*' | brand ~ '.*[Mm]obil.*'){set
mkgmap:label:1=' '} [0x6001 resolution 24]
amenity=fuel & (name ~ '.*[Ss]hell.*' | brand ~ '.*[Ss]hell.*'){set
mkgmap:label:1=' '} [0x6000 resolution 24]
amenity=fuel & (name ~ '.*[Ss]peedway.*' | brand ~ '.*[Ss]peedway.*')  {set
mkgmap:label:1=' '} [0x6002 resolution 24]
amenity=fuel & (name ~ '.*[Ss]unoco.*' | brand ~ '.*[Ss]unoco.*')  {set
mkgmap:label:1=' '} [0x600d resolution 24]
amenity=fuel & (name ~ '.*[Vv]alero.*' | brand ~ '.*[Vv]alero.*')  {set
mkgmap:label:1=' '} [0x600c resolution 24]
amenity=fuel {name '$(name)'} [0x2f01 resolution 24]

You are telling me that these will NOT be found in a FUEL SEARCH (0x2f01)
on the GPS because I do not have 'continue_with_actions' at the end of each
action?

Do I have to add CONTINUE_WITH_ACTIONS or could I just use CONTINUE?

If this is correct, this is why you define 0x2f01 as INVISIBLE, but is
necessary in order to preform a POI SEARCH?

Greg



On Sun, Mar 6, 2016 at 5:03 AM, Walter Schlögl <walter.schloegl-re...@aon.at
> wrote:

> Hi Greg,
>
> all supermarkets are found in the POI list if you give supermarket the POI
> Nr 2E02.
> shop=books is the POI Nr 2E03, shop=mall is POI Nr 2E04 and so on.
>
> So usually all supermarkets would have the same Icon also,
> but with the solution shown below you can give different supermarkets
> different icons.
>
> If you would just map all Aldi-supermarkets to 3501 without continue
> it would get the correct icon, but not found any longer in the search list.
>
> Do you use this feature on your Garmin device, to search for Point of
> interests?
>
> Walter
>
>
> *From:* greg crago <gregcr...@gmail.com>
> *Sent:* Saturday, March 05, 2016 10:53 PM
> *To:* Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk>
> *Subject:* Re: [mkgmap-dev] Question about using different ROAD CLASS's
> andROAD SPEED's for one linetype.
>
> I have re-read your posts and I think I am still confused about your
> statement
>
> "you can also club together POIs with different Icons to the same
> POI-List entry"
>
> Again, what is a 'POI-list entry' and how is this a benefit?
>
> I understand about specific store BRANDS and using unique POINTS and then
> use a GENERIC icon for the rest of the category.
>
> Greg
>
> On Sat, Mar 5, 2016 at 4:49 AM, Walter Schlögl <
> walter.schloegl-re...@aon.at> wrote:
>
>> Hi Greg,
>>
>> here an example for supermarkets
>>
>> shop=supermarket & (name~'Hofer.*'  | name~'HOFER.*'){ set
>> mkgmap_symbol=yes}[0x3501 resolution 23 continue with_actions]
>> shop=supermarket & (name~'Aldi.*'   | name~'ALDI.*'){ set
>> mkgmap_symbol=yes}[0x3501 resolution 23 continue with_actions]
>> shop=supermarket & (name~'Lidl.*'   | name~'LIDL.*'){ set
>> mkgmap_symbol=yes}[0x3502 resolution 23 continue with_actions]
>> ...
>> shop=supermarket & mkgmap_symbol!=yes
>> [0x3500 resolution 23 continue with_actions]
>> shop=supermarket[0x2E02
>> resolution 21] # POI
>>
>> There is one common symbol on 3500 and dedicated symbols on 3501 and
>> above.
>> (Hofer and Aldi is the same supermarket with the same Logo but with
>> different names in Austria and Germany)
>> If I find a dedicated name of the supermarket, I will show the
>> corresponding symbol. (at the moment about 30 in my list)
>> All other supermarkets will get the common symbol.
>> And all of them will get additionally an unvisible POI (well, not totally
>> unvisible but just 1 dot) for the POI-List
>> Since this 1 dot POI is placed at resolution 21, I can click on it also
>> in lower zoom levels.
>>
>> I’m doing the same with amenity=fuel (more than 20), shop=car and many
>> others.
>> My map has many dedicated symbols which makes it easier to find a POI at
>> one short look even without using the search function.
>>
>> Walter
>>
>>
>>

Re: [mkgmap-dev] Question about using different ROAD CLASS's andROAD SPEED's for one linetype.

[Walter Schlögl]

Hi Greg,

all supermarkets are found in the POI list if you give supermarket the POI Nr 
2E02.
shop=books is the POI Nr 2E03, shop=mall is POI Nr 2E04 and so on.

So usually all supermarkets would have the same Icon also, 
but with the solution shown below you can give different supermarkets different 
icons.

If you would just map all Aldi-supermarkets to 3501 without continue 
it would get the correct icon, but not found any longer in the search list.

Do you use this feature on your Garmin device, to search for Point of interests?

Walter


From: greg crago 
Sent: Saturday, March 05, 2016 10:53 PM
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Question about using different ROAD CLASS's andROAD 
SPEED's for one linetype.

I have re-read your posts and I think I am still confused about your statement 

"you can also club together POIs with different Icons to the same POI-List 
entry"


Again, what is a 'POI-list entry' and how is this a benefit?


I understand about specific store BRANDS and using unique POINTS and then use a 
GENERIC icon for the rest of the category.


Greg

On Sat, Mar 5, 2016 at 4:49 AM, Walter Schlögl <walter.schloegl-re...@aon.at> 
wrote:

  Hi Greg,

  here an example for supermarkets

  shop=supermarket & (name~'Hofer.*'  | name~'HOFER.*'){ set 
mkgmap_symbol=yes}[0x3501 resolution 23 continue with_actions]
  shop=supermarket & (name~'Aldi.*'   | name~'ALDI.*'){ set 
mkgmap_symbol=yes}[0x3501 resolution 23 continue with_actions]
  shop=supermarket & (name~'Lidl.*'   | name~'LIDL.*'){ set 
mkgmap_symbol=yes}[0x3502 resolution 23 continue with_actions]
  ...
  shop=supermarket & mkgmap_symbol!=yes[0x3500 
resolution 23 continue with_actions]
  shop=supermarket[0x2E02 resolution 
21] # POI

  There is one common symbol on 3500 and dedicated symbols on 3501 and above.
  (Hofer and Aldi is the same supermarket with the same Logo but with different 
names in Austria and Germany)
  If I find a dedicated name of the supermarket, I will show the corresponding 
symbol. (at the moment about 30 in my list)
  All other supermarkets will get the common symbol.
  And all of them will get additionally an unvisible POI (well, not totally 
unvisible but just 1 dot) for the POI-List
  Since this 1 dot POI is placed at resolution 21, I can click on it also in 
lower zoom levels.

  I’m doing the same with amenity=fuel (more than 20), shop=car and many others.
  My map has many dedicated symbols which makes it easier to find a POI at one 
short look even without using the search function.

  Walter


  From: greg crago 
  Sent: Friday, March 04, 2016 11:37 PM
  To: Development list for mkgmap 
  Subject: Re: [mkgmap-dev] Question about using different ROAD CLASS's andROAD 
SPEED's for one linetype.

  I am still confused. 
  Can you explain it one more time and use an example.

  Greg

  On Fri, Mar 4, 2016 at 11:13 AM, Bernd Weigelt <weigelt.be...@web.de> wrote:

Hi Greg

No, this line catches only cuisine=french *or* cuisine=sea food, not
'cuisine=french;sea food;...' This key/value pair will be ignored

---
cuisine~'.*;.*'
{
set cuisine='${cuisine|part:}';
}

This rule helps, to use the first part in the POIs, but all other will be
ignored, too. Have it in my filter file.

My example in my first answer is not really good, because the rule has to be
executed in a loop until the last value, but i think MKGMAP didn't do this

Bernd

Am Freitag, 4. März 2016, 10:01:52 CET schrieb greg crago:
> Bernd, Is this the same as (in the line file)
>
> amenity=restaurant & (cuisine=french | cuisine=sea food | cuisine=german |
> cuisine=. ) [0x01150 resolution 24]
>
> Greg



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



--
  ___
  mkgmap-dev mailing list
  mkgmap-dev@lists.mkgmap.org.uk
  http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev 

  ___
  mkgmap-dev mailing list
  mkgmap-dev@lists.mkgmap.org.uk
  http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about using different ROAD CLASS's andROAD SPEED's for one linetype.

[greg crago]

I have re-read your posts and I think I am still confused about your
statement

"you can also club together POIs with different Icons to the same POI-List
entry"

Again, what is a 'POI-list entry' and how is this a benefit?

I understand about specific store BRANDS and using unique POINTS and then
use a GENERIC icon for the rest of the category.

Greg

On Sat, Mar 5, 2016 at 4:49 AM, Walter Schlögl <walter.schloegl-re...@aon.at
> wrote:

> Hi Greg,
>
> here an example for supermarkets
>
> shop=supermarket & (name~'Hofer.*'  | name~'HOFER.*'){ set
> mkgmap_symbol=yes}[0x3501 resolution 23 continue with_actions]
> shop=supermarket & (name~'Aldi.*'   | name~'ALDI.*'){ set
> mkgmap_symbol=yes}[0x3501 resolution 23 continue with_actions]
> shop=supermarket & (name~'Lidl.*'   | name~'LIDL.*'){ set
> mkgmap_symbol=yes}[0x3502 resolution 23 continue with_actions]
> ...
> shop=supermarket & mkgmap_symbol!=yes
> [0x3500 resolution 23 continue with_actions]
> shop=supermarket[0x2E02 resolution
> 21] # POI
>
> There is one common symbol on 3500 and dedicated symbols on 3501 and above.
> (Hofer and Aldi is the same supermarket with the same Logo but with
> different names in Austria and Germany)
> If I find a dedicated name of the supermarket, I will show the
> corresponding symbol. (at the moment about 30 in my list)
> All other supermarkets will get the common symbol.
> And all of them will get additionally an unvisible POI (well, not totally
> unvisible but just 1 dot) for the POI-List
> Since this 1 dot POI is placed at resolution 21, I can click on it also in
> lower zoom levels.
>
> I’m doing the same with amenity=fuel (more than 20), shop=car and many
> others.
> My map has many dedicated symbols which makes it easier to find a POI at
> one short look even without using the search function.
>
> Walter
>
>
> *From:* greg crago <gregcr...@gmail.com>
> *Sent:* Friday, March 04, 2016 11:37 PM
> *To:* Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk>
> *Subject:* Re: [mkgmap-dev] Question about using different ROAD CLASS's
> andROAD SPEED's for one linetype.
>
> I am still confused.
> Can you explain it one more time and use an example.
>
> Greg
>
> On Fri, Mar 4, 2016 at 11:13 AM, Bernd Weigelt <weigelt.be...@web.de>
> wrote:
>
>> Hi Greg
>>
>> No, this line catches only cuisine=french *or* cuisine=sea food, not
>> 'cuisine=french;sea food;...' This key/value pair will be ignored
>>
>> ---
>> cuisine~'.*;.*'
>> {
>> set cuisine='${cuisine|part:}';
>> }
>>
>> This rule helps, to use the first part in the POIs, but all other will be
>> ignored, too. Have it in my filter file.
>>
>> My example in my first answer is not really good, because the rule has to
>> be
>> executed in a loop until the last value, but i think MKGMAP didn't do this
>>
>> Bernd
>>
>> Am Freitag, 4. März 2016, 10:01:52 CET schrieb greg crago:
>> > Bernd, Is this the same as (in the line file)
>> >
>> > amenity=restaurant & (cuisine=french | cuisine=sea food |
>> cuisine=german |
>> > cuisine=. ) [0x01150 resolution 24]
>> >
>> > Greg
>>
>>
>> ___
>> mkgmap-dev mailing list
>> mkgmap-dev@lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>
>
> --
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about using different ROAD CLASS's andROAD SPEED's for one linetype.

[Walter Schlögl]

Hi Greg,

here an example for supermarkets

shop=supermarket & (name~'Hofer.*'  | name~'HOFER.*'){ set 
mkgmap_symbol=yes}[0x3501 resolution 23 continue with_actions]
shop=supermarket & (name~'Aldi.*'   | name~'ALDI.*'){ set 
mkgmap_symbol=yes}[0x3501 resolution 23 continue with_actions]
shop=supermarket & (name~'Lidl.*'   | name~'LIDL.*'){ set 
mkgmap_symbol=yes}[0x3502 resolution 23 continue with_actions]
...
shop=supermarket & mkgmap_symbol!=yes[0x3500 
resolution 23 continue with_actions]
shop=supermarket[0x2E02 resolution 21] 
# POI

There is one common symbol on 3500 and dedicated symbols on 3501 and above.
(Hofer and Aldi is the same supermarket with the same Logo but with different 
names in Austria and Germany)
If I find a dedicated name of the supermarket, I will show the corresponding 
symbol. (at the moment about 30 in my list)
All other supermarkets will get the common symbol.
And all of them will get additionally an unvisible POI (well, not totally 
unvisible but just 1 dot) for the POI-List
Since this 1 dot POI is placed at resolution 21, I can click on it also in 
lower zoom levels.

I’m doing the same with amenity=fuel (more than 20), shop=car and many others.
My map has many dedicated symbols which makes it easier to find a POI at one 
short look even without using the search function.

Walter


From: greg crago 
Sent: Friday, March 04, 2016 11:37 PM
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Question about using different ROAD CLASS's andROAD 
SPEED's for one linetype.

I am still confused. 
Can you explain it one more time and use an example.

Greg

On Fri, Mar 4, 2016 at 11:13 AM, Bernd Weigelt <weigelt.be...@web.de> wrote:

  Hi Greg

  No, this line catches only cuisine=french *or* cuisine=sea food, not
  'cuisine=french;sea food;...' This key/value pair will be ignored

  ---
  cuisine~'.*;.*'
  {
  set cuisine='${cuisine|part:}';
  }

  This rule helps, to use the first part in the POIs, but all other will be
  ignored, too. Have it in my filter file.

  My example in my first answer is not really good, because the rule has to be
  executed in a loop until the last value, but i think MKGMAP didn't do this

  Bernd

  Am Freitag, 4. März 2016, 10:01:52 CET schrieb greg crago:
  > Bernd, Is this the same as (in the line file)
  >
  > amenity=restaurant & (cuisine=french | cuisine=sea food | cuisine=german |
  > cuisine=. ) [0x01150 resolution 24]
  >
  > Greg



  ___
  mkgmap-dev mailing list
  mkgmap-dev@lists.mkgmap.org.uk
  http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about using different ROAD CLASS's andROAD SPEED's for one linetype.

[greg crago]

I am still confused.
Can you explain it one more time and use an example.

Greg

On Fri, Mar 4, 2016 at 11:13 AM, Bernd Weigelt  wrote:

> Hi Greg
>
> No, this line catches only cuisine=french *or* cuisine=sea food, not
> 'cuisine=french;sea food;...' This key/value pair will be ignored
>
> ---
> cuisine~'.*;.*'
> {
> set cuisine='${cuisine|part:}';
> }
>
> This rule helps, to use the first part in the POIs, but all other will be
> ignored, too. Have it in my filter file.
>
> My example in my first answer is not really good, because the rule has to
> be
> executed in a loop until the last value, but i think MKGMAP didn't do this
>
> Bernd
>
> Am Freitag, 4. März 2016, 10:01:52 CET schrieb greg crago:
> > Bernd, Is this the same as (in the line file)
> >
> > amenity=restaurant & (cuisine=french | cuisine=sea food | cuisine=german
> |
> > cuisine=. ) [0x01150 resolution 24]
> >
> > Greg
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about using different ROAD CLASS's andROAD SPEED's for one linetype.

[Bernd Weigelt]

Hi Greg

No, this line catches only cuisine=french *or* cuisine=sea food, not 
'cuisine=french;sea food;...' This key/value pair will be ignored

---
cuisine~'.*;.*'
{
set cuisine='${cuisine|part:}';
}

This rule helps, to use the first part in the POIs, but all other will be 
ignored, too. Have it in my filter file.

My example in my first answer is not really good, because the rule has to be 
executed in a loop until the last value, but i think MKGMAP didn't do this

Bernd

Am Freitag, 4. März 2016, 10:01:52 CET schrieb greg crago:
> Bernd, Is this the same as (in the line file)
> 
> amenity=restaurant & (cuisine=french | cuisine=sea food | cuisine=german |
> cuisine=. ) [0x01150 resolution 24]
> 
> Greg


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about using different ROAD CLASS's andROAD SPEED's for one linetype.

[greg crago]

Bernd, Is this the same as (in the line file)

amenity=restaurant & (cuisine=french | cuisine=sea food | cuisine=german |
cuisine=. ) [0x01150 resolution 24]

Greg

On Fri, Mar 4, 2016 at 3:25 AM, Bernd Weigelt  wrote:

> Am Donnerstag, 3. März 2016, 20:59:09 CET schrieb greg crago:
>
> Hi Greg
>
> you can use it for such construction like cuisine=burger;pizza;german;...
>
> set a visible symbol with
>
> cuisine~'.*;.*'  {0x011500   resolution 24 continue}#custom point 1
> and an invisible point for everything you want to have in the searchable
> POI-
> list.
>
> [_point]
> Type=0x02A01
> ExtendedLabels=N
> dayxpm="1 1 2 1" colormode=16
> "$ c #FF"
> "% c none"
> "%"
> [end]
>
>
> 0x2A01  Dining(American)
> 0x2A02  Dining(Asian)
> 0x2A03  Dining(Barbecue)
> 0x2A04  Dining(Chinese)
> 0x2A05  Dining(Deli/Bakery)
> 0x2A06  Dining(International)
> 0x2A07  Fast Food
> 0x2A08  Dining(Italian)
> 0x2A09  Dining(Mexican)
> 0x2A0A  Dining(Pizza)
> 0x2A0B  Dining(Sea Food)
> 0x2A0C  Dining(Steak/Grill)
> 0x2A0D  Dining(Bagel/Donut)
> 0x2A0E  Dining(Cafe/Diner)
> 0x2A0F  Dining(French)
> 0x2A10  Dining(German)
> 0x2A11  Dining(British Isles)
>
> >
> > Walter, I see that advantage of using INVISIBLE linetype and VISIBLE
> > overlay linetypes (line bicycle lanes, 1 way arrows to indicate 1-way
> > roads, etc), but I do not know what you can do with INVISIBLE POI and
> > overlay POI. What kind of custom POI can you build?
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about using different ROAD CLASS's andROAD SPEED's for one linetype.

[Bernd Weigelt]

Am Donnerstag, 3. März 2016, 20:59:09 CET schrieb greg crago:

Hi Greg

you can use it for such construction like cuisine=burger;pizza;german;...

set a visible symbol with

cuisine~'.*;.*'  {0x011500   resolution 24 continue}#custom point 1
and an invisible point for everything you want to have in the searchable POI-
list.

[_point]
Type=0x02A01
ExtendedLabels=N
dayxpm="1 1 2 1" colormode=16
"$ c #FF"
"% c none"
"%"
[end]


0x2A01  Dining(American)
0x2A02  Dining(Asian)
0x2A03  Dining(Barbecue)
0x2A04  Dining(Chinese)
0x2A05  Dining(Deli/Bakery)
0x2A06  Dining(International)
0x2A07  Fast Food
0x2A08  Dining(Italian)
0x2A09  Dining(Mexican)
0x2A0A  Dining(Pizza)
0x2A0B  Dining(Sea Food)
0x2A0C  Dining(Steak/Grill)
0x2A0D  Dining(Bagel/Donut)
0x2A0E  Dining(Cafe/Diner)
0x2A0F  Dining(French)
0x2A10  Dining(German)
0x2A11  Dining(British Isles)

> 
> Walter, I see that advantage of using INVISIBLE linetype and VISIBLE
> overlay linetypes (line bicycle lanes, 1 way arrows to indicate 1-way
> roads, etc), but I do not know what you can do with INVISIBLE POI and
> overlay POI. What kind of custom POI can you build?

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about using different ROAD CLASS's andROAD SPEED's for one linetype.

[greg crago]

Walter, I also have setup non-routable linetypes for roundabouts to show
different road types all on top of an INVISIBLE roundabout routable
linetype 0x0c. Gerd says I should leave 0x0c and 0x08 and 0x09 alone
because the GPS expects these *_links and roundabouts to use these specific
layers.

Walter, I see that advantage of using INVISIBLE linetype and VISIBLE
overlay linetypes (line bicycle lanes, 1 way arrows to indicate 1-way
roads, etc), but I do not know what you can do with INVISIBLE POI and
overlay POI. What kind of custom POI can you build?

Greg

On Thu, Mar 3, 2016 at 12:46 PM, Walter Schlögl <
walter.schloegl-re...@aon.at> wrote:

> Hi Greg,
>
> why do you want to “free” some routeable line types?
> If it is just for different display options, you can do another trick.
> I am using 0x0c as an invisible line type just for routing purpose,
> and non-routeable overlay linetypes to display roundabouts how they should
> look like.
>
> highway=trunk & junction=roundabout[0x0c
> road_class=3 road_speed=2 resolution 24 continue with_actions]
> highway=trunk & junction=roundabout[0x10202
> resolution 17]
> highway=primary & junction=roundabout[0x0c
> road_class=3 road_speed=1 resolution 24 continue with_actions]
> highway=primary & junction=roundabout[0x10302
> resolution 17]
> highway=secondary & junction=roundabout[0x0c
> road_class=2 road_speed=1 resolution 24 continue with_actions]
> highway=secondary & junction=roundabout
> [0x10402 resolution 18]
> highway=tertiary & junction=roundabout[0x0c
> road_class=1 road_speed=1 resolution 24 continue with_actions]
> highway=tertiary & junction=roundabout[0x10502
> resolution 19]
> highway=unclassified & junction=roundabout[0x0c
> road_class=0 road_speed=1 resolution 24 continue with_actions]
> highway=unclassified & junction=roundabout[0x10602
> resolution 21]
> highway=residential & junction=roundabout[0x0c
> road_class=0 road_speed=1 resolution 24 continue with_actions]
> highway=residential & junction=roundabout[0x10702
> resolution 22]
>
> You can use the same trick for all other routing lines also.
> With a similiar trick (invisible main POI + visible overlay POIs) you can
> also club together POIs with different Icons to the same POI-List entry.
>
> Walter
>
>
> *From:* Gerd Petermann <gpetermann_muenc...@hotmail.com>
> *Sent:* Thursday, March 03, 2016 6:30 AM
> *To:* Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk>
> *Subject:* Re: [mkgmap-dev] Question about using different ROAD CLASS's
> andROAD SPEED's for one linetype.
>
>
> Hi Greg,
>
>
>
> my understanding is that Garmin treats 0x0c special to produce the "leave
> roundabout at the nth ..." hints,
>
> the same for 0x08 and 0x09 to produce the other exit hints. The
> calculation of the "nth" exit requires special logic,
>
> that's why roundabouts need a special type.
>
>
>
> Gerd
>
>
>
>
>
>
> --
> *Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk <
> mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von greg crago <
> gregcr...@gmail.com>
> *Gesendet:* Donnerstag, 3. März 2016 00:10
> *An:* Development list for mkgmap
> *Betreff:* [mkgmap-dev] Question about using different ROAD CLASS's and
> ROAD SPEED's for one linetype.
>
> I noticed that I have one linetype (0x0c) for roundabouts and it had many
> different ROAD CLASS and ROAD SPEED
>
> # Roundabouts
> junction=roundabout & (highway=trunk | highway=trunk_link) [0x2a
> resolution 18 continue]
> junction=roundabout & (highway=trunk | highway=trunk_link) [0x0c
> road_class=3 road_speed=2 resolution 18]
> junction=roundabout & (highway=primary | highway=primary_link) [0x2d
> resolution 18 continue]
> junction=roundabout & (highway=primary | highway=primary_link) [0x0c
> road_class=3 road_speed=1 resolution 18]
> junction=roundabout & (highway=secondary | highway=secondary_link) [0x2e
> resolution 20 continue]
> junction=roundabout & (highway=secondary | highway=secondary_link) [0x0c
> road_class=2 road_speed=1 resolution 20]
> junction=roundabout & (highway=tertiary | highway=tertiary_link) [0x2f
> resolution 20 continue]
> junction=roundabout & (highway=tertiary | highway=tertiary_link) [0x0c
> road_class=1 road_speed=1 resolution 20]
> junction=roundabout & (highway=unclassified | highway=reside

Re: [mkgmap-dev] Question about using different ROAD CLASS's andROAD SPEED's for one linetype.

[Walter Schlögl]

Hi Greg,

why do you want to “free” some routeable line types?
If it is just for different display options, you can do another trick.
I am using 0x0c as an invisible line type just for routing purpose,
and non-routeable overlay linetypes to display roundabouts how they should look 
like.

highway=trunk & junction=roundabout[0x0c 
road_class=3 road_speed=2 resolution 24 continue with_actions]
highway=trunk & junction=roundabout[0x10202 
resolution 17]
highway=primary & junction=roundabout[0x0c 
road_class=3 road_speed=1 resolution 24 continue with_actions]
highway=primary & junction=roundabout[0x10302 
resolution 17]
highway=secondary & junction=roundabout[0x0c 
road_class=2 road_speed=1 resolution 24 continue with_actions]
highway=secondary & junction=roundabout[0x10402 
resolution 18]
highway=tertiary & junction=roundabout[0x0c 
road_class=1 road_speed=1 resolution 24 continue with_actions]
highway=tertiary & junction=roundabout[0x10502 
resolution 19]
highway=unclassified & junction=roundabout[0x0c 
road_class=0 road_speed=1 resolution 24 continue with_actions]
highway=unclassified & junction=roundabout[0x10602 
resolution 21]
highway=residential & junction=roundabout[0x0c 
road_class=0 road_speed=1 resolution 24 continue with_actions]
highway=residential & junction=roundabout[0x10702 
resolution 22]

You can use the same trick for all other routing lines also.
With a similiar trick (invisible main POI + visible overlay POIs) you can also 
club together POIs with different Icons to the same POI-List entry.

Walter


From: Gerd Petermann 
Sent: Thursday, March 03, 2016 6:30 AM
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Question about using different ROAD CLASS's andROAD 
SPEED's for one linetype.

Hi Greg,



my understanding is that Garmin treats 0x0c special to produce the "leave 
roundabout at the nth ..." hints,

the same for 0x08 and 0x09 to produce the other exit hints. The calculation of 
the "nth" exit requires special logic,

that's why roundabouts need a special type. 




Gerd












Von: mkgmap-dev-boun...@lists.mkgmap.org.uk 
<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von greg crago 
<gregcr...@gmail.com>
Gesendet: Donnerstag, 3. März 2016 00:10
An: Development list for mkgmap
Betreff: [mkgmap-dev] Question about using different ROAD CLASS's and ROAD 
SPEED's for one linetype. 

I noticed that I have one linetype (0x0c) for roundabouts and it had many 
different ROAD CLASS and ROAD SPEED

# Roundabouts
junction=roundabout & (highway=trunk | highway=trunk_link) [0x2a resolution 18 
continue]
junction=roundabout & (highway=trunk | highway=trunk_link) [0x0c road_class=3 
road_speed=2 resolution 18]
junction=roundabout & (highway=primary | highway=primary_link) [0x2d resolution 
18 continue]
junction=roundabout & (highway=primary | highway=primary_link) [0x0c 
road_class=3 road_speed=1 resolution 18]
junction=roundabout & (highway=secondary | highway=secondary_link) [0x2e 
resolution 20 continue]
junction=roundabout & (highway=secondary | highway=secondary_link) [0x0c 
road_class=2 road_speed=1 resolution 20]
junction=roundabout & (highway=tertiary | highway=tertiary_link) [0x2f 
resolution 20 continue]
junction=roundabout & (highway=tertiary | highway=tertiary_link) [0x0c 
road_class=1 road_speed=1 resolution 20]
junction=roundabout & (highway=unclassified | highway=residential | 
highway=minor | highway=living_street) [0x25 resolution 22 continue]
junction=roundabout & (highway=unclassified | highway=residential | 
highway=minor | highway=living_street) [0x0c road_class=1 road_speed=1 
resolution 22]


I also have 2 other linetypes for HIGH SPEED RAMPS (0x09) and LOW SPEED RAMPS 
(0x08):


highway=motorway_link [0x09 road_class=4 road_speed=7 resolution 15]
highway=trunk_link [0x09 road_class=4 road_speed=5 resolution 18]

highway=primary_link  [0x08 road_class=3 road_speed=1 resolution 18]
highway=secondary_link [0x08 road_class=2 road_speed=1 resolution 19]



MY QUESTION:


Can I combine all of these different ROAD_CLASS and ROAD_SPEED together using 
0x0c and free up 2 routable linetypes? Yes, all the map elements would like the 
same.


Greg




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Question about using different ROAD CLASS's and ROAD SPEED's for one linetype.

[greg crago]

I noticed that I have one linetype (0x0c) for roundabouts and it had many
different ROAD CLASS and ROAD SPEED

# Roundabouts
junction=roundabout & (highway=trunk | highway=trunk_link) [0x2a resolution
18 continue]
junction=roundabout & (highway=trunk | highway=trunk_link) [0x0c
road_class=3 road_speed=2 resolution 18]
junction=roundabout & (highway=primary | highway=primary_link) [0x2d
resolution 18 continue]
junction=roundabout & (highway=primary | highway=primary_link) [0x0c
road_class=3 road_speed=1 resolution 18]
junction=roundabout & (highway=secondary | highway=secondary_link) [0x2e
resolution 20 continue]
junction=roundabout & (highway=secondary | highway=secondary_link) [0x0c
road_class=2 road_speed=1 resolution 20]
junction=roundabout & (highway=tertiary | highway=tertiary_link) [0x2f
resolution 20 continue]
junction=roundabout & (highway=tertiary | highway=tertiary_link) [0x0c
road_class=1 road_speed=1 resolution 20]
junction=roundabout & (highway=unclassified | highway=residential |
highway=minor | highway=living_street) [0x25 resolution 22 continue]
junction=roundabout & (highway=unclassified | highway=residential |
highway=minor | highway=living_street) [0x0c road_class=1 road_speed=1
resolution 22]


I also have 2 other linetypes for HIGH SPEED RAMPS (0x09) and LOW SPEED
RAMPS (0x08):


highway=motorway_link [0x09 road_class=4 road_speed=7 resolution 15]
highway=trunk_link [0x09 road_class=4 road_speed=5 resolution 18]

highway=primary_link  [0x08 road_class=3 road_speed=1 resolution 18]
highway=secondary_link [0x08 road_class=2 road_speed=1 resolution 19]


MY QUESTION:

Can I combine all of these different ROAD_CLASS and ROAD_SPEED together
using 0x0c and free up 2 routable linetypes? Yes, all the map elements
would like the same.

Greg
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] question on 0x02

[Steve Sgalowski]

ok i have found my problem , but now wondering is it because some things
 have changed and knoced out some of the high way = trunk commands under
0x02


#highway=trunk & ( network=e-road | int_ref=* ) [0x02 resolution 24-18
continue]
#highway=trunk [0x02 road_class=4 road_speed=5 resolution 24-18]


Stephen
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] question for tdb-file record 0x52; option in mkgmap ?

[Gerd Petermann]

Hallo Thomas,


please try --family-name=xyz.


Where did you get the binary that reports mkgmap-r3336 ?

I assume that you build your own binary, in that case please

use these two commands:

svn update

ant clean dist

Gerd


Von: mkgmap-dev-boun...@lists.mkgmap.org.uk 
<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas Morgenstern 
<webmas...@img2ms.de>
Gesendet: Samstag, 28. November 2015 15:29
An: Development list for mkgmap
Betreff: [mkgmap-dev] question for tdb-file record 0x52; option in mkgmap ?

Has  mkgmap  a option, which write's the record 0x52 in tdb-file ? My maps have 
in Mapsource all the entry 'Overview map' . But i will for example 'Kanaren' or 
any other countryname. I have testet followings option without success: 
-region-name=anywhat ;-country.name= anywhat; -description= anywhat. I use 
-index to create the tdb-file. I can use a hexeditor to change  tdb- file- 
record 0x52. But this is not a preferable way. i must recalculate a CRC 32 
checksum for record 0x54.

By the way: i found a error in the tdb-file, created with mkgmap r3650 : it 
prints in the copyright-section :Map created with mkgmap -r3336...; It 
should bee updated to ..r3650

Regards thomas
[cid:part1.04090008.03040905@img2ms.de]
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] question for tdb-file record 0x52; option in mkgmap ?

[Thomas Morgenstern]

So i have newly downloaded mkgmap-r3650 and run it again. The resulting 
tdb-file is available at : http://img2ms.de/Downloads/TopoCeuta.tdb. 
Look  self in it with hexeditor. At dezimalposition 950 you will find  
'mkgmap-r3336'. Hex-position is 0x3ac.

maybee is the problem the second run ?
regards thomas

Am 28.11.2015 um 18:36 schrieb Gerd Petermann:


Hi Thomas,


I see no way that r3650 produces the string mkgmap-r3336.

So, I guess that you are looking at an old map, which would

also explain that the different options have no effect.


ciao,

Gerd




*Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk 
<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas 
Morgenstern <webmas...@img2ms.de>

*Gesendet:* Samstag, 28. November 2015 18:08
*An:* Development list for mkgmap
*Betreff:* Re: [mkgmap-dev] question for tdb-file record 0x52; option 
in mkgmap ?
I use mkgmap r-3650 from downloadsite: 
http://www.mkgmap.org.uk/download/mkgmap.html 
-->http://www.mkgmap.org.uk/download/mkgmap-r3650.zip.

<http://www.mkgmap.org.uk/download/mkgmap.html>

mkgmap download page
Branch builds. These jar files are latest builds of recent development 
branches. They are useful if you want to quickly test a branch without 
having obtain and build it.

Weitere Informationen... <http://www.mkgmap.org.uk/download/mkgmap.html>




-family-name=Kanaren also make 'Overview Map'.
My way is:
1. in first run I generate all <123345678>.img from *.osm-pbf . for 
Europa komplett
2. a secand run : /java -Xmx5000m jar mkgmap.jar -family-id=1918 
-product-id=1 -family-name=TopoKanaren -series-name=Topo Kanaren 
-overview-mapname=TopoCeuta -code-page=1252 -mapname=Kanaren -index
.img-file/s. This creates the tdb,preview, mdx and 
_mdr.img. Works perfekt, but the only mistake is : 'Overview Map' .


result is : in mapsource ->Fläche' -->'Overview Map' and not 'Topo 
Kanaren'

Am 28.11.2015 um 17:11 schrieb Gerd Petermann:


Hallo Thomas,


please try --family-name=xyz.


Where did you get the binary that reports mkgmap-r3336 ?

I assume that you build your own binary, in that case please

use these two commands:

svn update

ant clean dist


Gerd


*Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk 
<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas 
Morgenstern <webmas...@img2ms.de>

*Gesendet:* Samstag, 28. November 2015 15:29
*An:* Development list for mkgmap
*Betreff:* [mkgmap-dev] question for tdb-file record 0x52; option in 
mkgmap ?
Has  mkgmap  a option, which write's the record 0x52 in tdb-file ? My 
maps have in Mapsource all the entry 'Overview map' . But i will for 
example 'Kanaren' or any other countryname. I have testet followings 
option without success: -region-name=anywhat ;-country.name= anywhat; 
-description= anywhat. I use -index to create the tdb-file. I can use 
a hexeditor to change  tdb- file- record 0x52. But this is not a 
preferable way. i must recalculate a CRC 32 checksum for record 0x54.


By the way: i found a error in the tdb-file, created with mkgmap 
r3650 : it prints in the copyright-section :.../.Map created with 
mkgmap -r3336/...; It should bee updated to ./.r3650/



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] question for tdb-file record 0x52; option in mkgmap ?

[Thomas Morgenstern]

Has  mkgmap  a option, which write's the record 0x52 in tdb-file ? My 
maps have in Mapsource all the entry 'Overview map' . But i will for 
example 'Kanaren' or any other countryname. I have testet followings 
option without success: -region-name=anywhat ;-country.name= anywhat; 
-description= anywhat. I use -index to create the tdb-file. I can use a 
hexeditor to change  tdb- file- record 0x52. But this is not a 
preferable way. i must recalculate a CRC 32 checksum for record 0x54.


By the way: i found a error in the tdb-file, created with mkgmap r3650 : 
it prints in the copyright-section :.../.Map created with mkgmap 
-r3336/...; It should bee updated to ./.r3650/


Regards thomas

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] question for tdb-file record 0x52; option in mkgmap ?

[Thomas Morgenstern]

I use mkgmap r-3650 from downloadsite: 
http://www.mkgmap.org.uk/download/mkgmap.html 
-->http://www.mkgmap.org.uk/download/mkgmap-r3650.zip.


-family-name=Kanaren also make 'Overview Map'.
My way is:
1. in first run I generate all <123345678>.img from *.osm-pbf . for 
Europa komplett
2. a secand run : /java -Xmx5000m jar mkgmap.jar -family-id=1918 
-product-id=1 -family-name=TopoKanaren -series-name=Topo Kanaren 
-overview-mapname=TopoCeuta -code-page=1252 -mapname=Kanaren -index
.img-file/s. This creates the tdb,preview, mdx and 
_mdr.img. Works perfekt, but the only mistake is : 'Overview Map' .


result is : in mapsource ->Fläche' -->'Overview Map' and not 'Topo Kanaren'
Am 28.11.2015 um 17:11 schrieb Gerd Petermann:


Hallo Thomas,


please try --family-name=xyz.


Where did you get the binary that reports mkgmap-r3336 ?

I assume that you build your own binary, in that case please

use these two commands:

svn update

ant clean dist


Gerd


*Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk 
<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas 
Morgenstern <webmas...@img2ms.de>

*Gesendet:* Samstag, 28. November 2015 15:29
*An:* Development list for mkgmap
*Betreff:* [mkgmap-dev] question for tdb-file record 0x52; option in 
mkgmap ?
Has  mkgmap  a option, which write's the record 0x52 in tdb-file ? My 
maps have in Mapsource all the entry 'Overview map' . But i will for 
example 'Kanaren' or any other countryname. I have testet followings 
option without success: -region-name=anywhat ;-country.name= anywhat; 
-description= anywhat. I use -index to create the tdb-file. I can use 
a hexeditor to change  tdb- file- record 0x52. But this is not a 
preferable way. i must recalculate a CRC 32 checksum for record 0x54.


By the way: i found a error in the tdb-file, created with mkgmap r3650 
: it prints in the copyright-section :.../.Map created with mkgmap 
-r3336/...; It should bee updated to ./.r3650/



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] question for tdb-file record 0x52; option in mkgmap ?

[Thomas Morgenstern]

Edit : the string mkgmap -r3336 is in the Copyrightrecord. Maybee the 
copyright is not updated? Creation-time of tbd-file is: 28.11.2015, 
19:17 Uhr GMT+1 hour


thomas
Am 28.11.2015 um 19:30 schrieb Thomas Morgenstern:
So i have newly downloaded mkgmap-r3650 and run it again. The 
resulting tdb-file is available at : 
http://img2ms.de/Downloads/TopoCeuta.tdb. Look  self in it with 
hexeditor. At dezimalposition 950 you will find  'mkgmap-r3336'. 
Hex-position is 0x3ac.

maybee is the problem the second run ?
regards thomas

Am 28.11.2015 um 18:36 schrieb Gerd Petermann:


Hi Thomas,


I see no way that r3650 produces the string mkgmap-r3336.

So, I guess that you are looking at an old map, which would

also explain that the different options have no effect.


ciao,

Gerd




*Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk 
<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas 
Morgenstern <webmas...@img2ms.de>

*Gesendet:* Samstag, 28. November 2015 18:08
*An:* Development list for mkgmap
*Betreff:* Re: [mkgmap-dev] question for tdb-file record 0x52; option 
in mkgmap ?
I use mkgmap r-3650 from downloadsite: 
http://www.mkgmap.org.uk/download/mkgmap.html 
-->http://www.mkgmap.org.uk/download/mkgmap-r3650.zip.

<http://www.mkgmap.org.uk/download/mkgmap.html>

mkgmap download page
Branch builds. These jar files are latest builds of recent 
development branches. They are useful if you want to quickly test a 
branch without having obtain and build it.

Weitere Informationen... <http://www.mkgmap.org.uk/download/mkgmap.html>




-family-name=Kanaren also make 'Overview Map'.
My way is:
1. in first run I generate all <123345678>.img from *.osm-pbf . for 
Europa komplett
2. a secand run : /java -Xmx5000m jar mkgmap.jar -family-id=1918 
-product-id=1 -family-name=TopoKanaren -series-name=Topo Kanaren 
-overview-mapname=TopoCeuta -code-page=1252 -mapname=Kanaren 
-index.img-file/s. This creates the 
tdb,preview, mdx and _mdr.img. Works perfekt, but the only mistake is 
: 'Overview Map' .


result is : in mapsource ->Fläche' -->'Overview Map' and not 'Topo 
Kanaren'

Am 28.11.2015 um 17:11 schrieb Gerd Petermann:


Hallo Thomas,


please try --family-name=xyz.


Where did you get the binary that reports mkgmap-r3336 ?

I assume that you build your own binary, in that case please

use these two commands:

svn update

ant clean dist


Gerd


*Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk 
<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas 
Morgenstern <webmas...@img2ms.de>

*Gesendet:* Samstag, 28. November 2015 15:29
*An:* Development list for mkgmap
*Betreff:* [mkgmap-dev] question for tdb-file record 0x52; option in 
mkgmap ?
Has  mkgmap  a option, which write's the record 0x52 in tdb-file ? 
My maps have in Mapsource all the entry 'Overview map' . But i will 
for example 'Kanaren' or any other countryname. I have testet 
followings option without success: -region-name=anywhat 
;-country.name= anywhat; -description= anywhat. I use -index to 
create the tdb-file. I can use a hexeditor to change  tdb- file- 
record 0x52. But this is not a preferable way. i must recalculate a 
CRC 32 checksum for record 0x54.


By the way: i found a error in the tdb-file, created with mkgmap 
r3650 : it prints in the copyright-section :.../.Map created with 
mkgmap -r3336/...; It should bee updated to ./.r3650/



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] question for tdb-file record 0x52; option in mkgmap ?

[Gerd Petermann]

Hi Thomas,


I see no way that r3650 produces the string mkgmap-r3336.

So, I guess that you are looking at an old map, which would

also explain that the different options have no effect.


ciao,

Gerd



Von: mkgmap-dev-boun...@lists.mkgmap.org.uk 
<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas Morgenstern 
<webmas...@img2ms.de>
Gesendet: Samstag, 28. November 2015 18:08
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] question for tdb-file record 0x52; option in mkgmap ?

I use mkgmap r-3650 from downloadsite: 
http://www.mkgmap.org.uk/download/mkgmap.html 
-->http://www.mkgmap.org.uk/download/mkgmap-r3650.zip.
[http://www.mkgmap.org.uk/static/img/logo.png]<http://www.mkgmap.org.uk/download/mkgmap.html>

mkgmap download page
Branch builds. These jar files are latest builds of recent development 
branches. They are useful if you want to quickly test a branch without having 
obtain and build it.
Weitere Informationen...<http://www.mkgmap.org.uk/download/mkgmap.html>




-family-name=Kanaren also make 'Overview Map'.
My way is:
1. in first run I generate all <123345678>.img from *.osm-pbf . for Europa 
komplett
2. a secand run : java -Xmx5000m jar mkgmap.jar -family-id=1918 -product-id=1 
-family-name=TopoKanaren -series-name=Topo Kanaren -overview-mapname=TopoCeuta 
-code-page=1252 -mapname=Kanaren -index.img-files. This 
creates the tdb,preview, mdx and _mdr.img. Works perfekt, but the only mistake 
is : 'Overview Map' .

result is : in mapsource ->Fläche' -->'Overview Map' and not 'Topo Kanaren'
Am 28.11.2015 um 17:11 schrieb Gerd Petermann:

Hallo Thomas,


please try --family-name=xyz.


Where did you get the binary that reports mkgmap-r3336 ?

I assume that you build your own binary, in that case please

use these two commands:

svn update

ant clean dist

Gerd


Von: 
mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>
 
<mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>
 im Auftrag von Thomas Morgenstern 
<webmas...@img2ms.de><mailto:webmas...@img2ms.de>
Gesendet: Samstag, 28. November 2015 15:29
An: Development list for mkgmap
Betreff: [mkgmap-dev] question for tdb-file record 0x52; option in mkgmap ?

Has  mkgmap  a option, which write's the record 0x52 in tdb-file ? My maps have 
in Mapsource all the entry 'Overview map' . But i will for example 'Kanaren' or 
any other countryname. I have testet followings option without success: 
-region-name=anywhat ;-country.name= anywhat; -description= anywhat. I use 
-index to create the tdb-file. I can use a hexeditor to change  tdb- file- 
record 0x52. But this is not a preferable way. i must recalculate a CRC 32 
checksum for record 0x54.

By the way: i found a error in the tdb-file, created with mkgmap r3650 : it 
prints in the copyright-section :Map created with mkgmap -r3336...; It 
should bee updated to ..r3650



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] question for tdb-file record 0x52; option in mkgmap ?

[Steve Ratcliffe]

Hi Thomas


Edit nr. 2: all sourcefiles i have uploadet to :
http://img2ms.de/Downloads/Kanaren+Ceuta.rar  Filesize ~ 14 MB. Maybee
you can reproduce the error in your IDE ?:.


The tdb-file contains the copyright messages from each of the the map
tiles, eliminating duplicates. So if the files are created with
different versions of mkgmap, or even created by a different program
altogether these messages will all be collected together in the TDB
file.

In this case 30007501 and 30007502 where created by mkgmap-r3650 and
40001173 was created by mkgmap-r3336.  At least that is what the
copyright message within those files say.

The TDB file contains several copyright blocks, including both these
versions numbers.

Anyway that is a side issue...

I think you are probably looking for --area-name which defaults to
'Overview Map'.  This is the one that is displayed in MapSource anyway.

The 0x52 record defaults to the string 'Test preview map' and has no
known use so we havn't added an option to change it.

Best wishes

..Steve


thomas

Am 28.11.2015 um 19:41 schrieb Thomas Morgenstern:

Edit : the string mkgmap -r3336 is in the Copyrightrecord. Maybee the
copyright is not updated? Creation-time of tbd-file is: 28.11.2015,
19:17 Uhr GMT+1 hour

thomas
Am 28.11.2015 um 19:30 schrieb Thomas Morgenstern:

So i have newly downloaded mkgmap-r3650 and run it again. The
resulting tdb-file is available at :
http://img2ms.de/Downloads/TopoCeuta.tdb. Look  self in it with
hexeditor. At dezimalposition 950 you will find  'mkgmap-r3336'.
Hex-position is 0x3ac.
maybee is the problem the second run ?
regards thomas

Am 28.11.2015 um 18:36 schrieb Gerd Petermann:


Hi Thomas,


I see no way that r3650 produces the string mkgmap-r3336.

So, I guess that you are looking at an old map, which would

also explain that the different options have no effect.


ciao,

Gerd




*Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk
<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas
Morgenstern <webmas...@img2ms.de>
*Gesendet:* Samstag, 28. November 2015 18:08
*An:* Development list for mkgmap
*Betreff:* Re: [mkgmap-dev] question for tdb-file record 0x52;
option in mkgmap ?
I use mkgmap r-3650 from downloadsite:
http://www.mkgmap.org.uk/download/mkgmap.html
-->http://www.mkgmap.org.uk/download/mkgmap-r3650.zip.
<http://www.mkgmap.org.uk/download/mkgmap.html>

mkgmap download page
Branch builds. These jar files are latest builds of recent
development branches. They are useful if you want to quickly test a
branch without having obtain and build it.
Weitere Informationen... <http://www.mkgmap.org.uk/download/mkgmap.html>




-family-name=Kanaren also make 'Overview Map'.
My way is:
1. in first run I generate all <123345678>.img from *.osm-pbf . for
Europa komplett
2. a secand run : /java -Xmx5000m jar mkgmap.jar -family-id=1918
-product-id=1 -family-name=TopoKanaren -series-name=Topo Kanaren
-overview-mapname=TopoCeuta -code-page=1252 -mapname=Kanaren
-index.img-file/s. This creates the
tdb,preview, mdx and _mdr.img. Works perfekt, but the only mistake
is : 'Overview Map' .

result is : in mapsource ->Fläche' -->'Overview Map' and not 'Topo
Kanaren'
Am 28.11.2015 um 17:11 schrieb Gerd Petermann:


Hallo Thomas,


please try --family-name=xyz.


Where did you get the binary that reports mkgmap-r3336 ?

I assume that you build your own binary, in that case please

use these two commands:

svn update

ant clean dist


Gerd


*Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk
<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas
Morgenstern <webmas...@img2ms.de>
*Gesendet:* Samstag, 28. November 2015 15:29
*An:* Development list for mkgmap
*Betreff:* [mkgmap-dev] question for tdb-file record 0x52; option
in mkgmap ?
Has  mkgmap  a option, which write's the record 0x52 in tdb-file ?
My maps have in Mapsource all the entry 'Overview map' . But i will
for example 'Kanaren' or any other countryname. I have testet
followings option without success: -region-name=anywhat
;-country.name= anywhat; -description= anywhat. I use -index to
create the tdb-file. I can use a hexeditor to change  tdb- file-
record 0x52. But this is not a preferable way. i must recalculate a
CRC 32 checksum for record 0x54.

By the way: i found a error in the tdb-file, created with mkgmap
r3650 : it prints in the copyright-section :.../.Map created with
mkgmap -r3336/...; It should bee updated to ./.r3650/


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev






___

Re: [mkgmap-dev] question for tdb-file record 0x52; option in mkgmap ?

[Thomas Morgenstern]

Edit nr. 2: all sourcefiles i have uploadet to : 
http://img2ms.de/Downloads/Kanaren+Ceuta.rar  Filesize ~ 14 MB. Maybee 
you can reproduce the error in your IDE ?:.


thomas

Am 28.11.2015 um 19:41 schrieb Thomas Morgenstern:
Edit : the string mkgmap -r3336 is in the Copyrightrecord. Maybee the 
copyright is not updated? Creation-time of tbd-file is: 28.11.2015, 
19:17 Uhr GMT+1 hour


thomas
Am 28.11.2015 um 19:30 schrieb Thomas Morgenstern:
So i have newly downloaded mkgmap-r3650 and run it again. The 
resulting tdb-file is available at : 
http://img2ms.de/Downloads/TopoCeuta.tdb. Look  self in it with 
hexeditor. At dezimalposition 950 you will find  'mkgmap-r3336'. 
Hex-position is 0x3ac.

maybee is the problem the second run ?
regards thomas

Am 28.11.2015 um 18:36 schrieb Gerd Petermann:


Hi Thomas,


I see no way that r3650 produces the string mkgmap-r3336.

So, I guess that you are looking at an old map, which would

also explain that the different options have no effect.


ciao,

Gerd




*Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk 
<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas 
Morgenstern <webmas...@img2ms.de>

*Gesendet:* Samstag, 28. November 2015 18:08
*An:* Development list for mkgmap
*Betreff:* Re: [mkgmap-dev] question for tdb-file record 0x52; 
option in mkgmap ?
I use mkgmap r-3650 from downloadsite: 
http://www.mkgmap.org.uk/download/mkgmap.html 
-->http://www.mkgmap.org.uk/download/mkgmap-r3650.zip.

<http://www.mkgmap.org.uk/download/mkgmap.html>

mkgmap download page
Branch builds. These jar files are latest builds of recent 
development branches. They are useful if you want to quickly test a 
branch without having obtain and build it.

Weitere Informationen... <http://www.mkgmap.org.uk/download/mkgmap.html>




-family-name=Kanaren also make 'Overview Map'.
My way is:
1. in first run I generate all <123345678>.img from *.osm-pbf . for 
Europa komplett
2. a secand run : /java -Xmx5000m jar mkgmap.jar -family-id=1918 
-product-id=1 -family-name=TopoKanaren -series-name=Topo Kanaren 
-overview-mapname=TopoCeuta -code-page=1252 -mapname=Kanaren 
-index.img-file/s. This creates the 
tdb,preview, mdx and _mdr.img. Works perfekt, but the only mistake 
is : 'Overview Map' .


result is : in mapsource ->Fläche' -->'Overview Map' and not 'Topo 
Kanaren'

Am 28.11.2015 um 17:11 schrieb Gerd Petermann:


Hallo Thomas,


please try --family-name=xyz.


Where did you get the binary that reports mkgmap-r3336 ?

I assume that you build your own binary, in that case please

use these two commands:

svn update

ant clean dist


Gerd


*Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk 
<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas 
Morgenstern <webmas...@img2ms.de>

*Gesendet:* Samstag, 28. November 2015 15:29
*An:* Development list for mkgmap
*Betreff:* [mkgmap-dev] question for tdb-file record 0x52; option 
in mkgmap ?
Has  mkgmap  a option, which write's the record 0x52 in tdb-file ? 
My maps have in Mapsource all the entry 'Overview map' . But i will 
for example 'Kanaren' or any other countryname. I have testet 
followings option without success: -region-name=anywhat 
;-country.name= anywhat; -description= anywhat. I use -index to 
create the tdb-file. I can use a hexeditor to change  tdb- file- 
record 0x52. But this is not a preferable way. i must recalculate a 
CRC 32 checksum for record 0x54.


By the way: i found a error in the tdb-file, created with mkgmap 
r3650 : it prints in the copyright-section :.../.Map created with 
mkgmap -r3336/...; It should bee updated to ./.r3650/



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev






___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] question for tdb-file record 0x52; option in mkgmap ?

[Thomas Morgenstern]

Hi Steve, the problem is solved .  With option -arae-name= Kanaren works 
all perfekt.


Thank's at all
Am 28.11.2015 um 22:40 schrieb Steve Ratcliffe:

Hi Thomas

The tdb-file contains the copyright messages from each of the the map
tiles, eliminating duplicates. So if the files are created with
different versions of mkgmap, or even created by a different program
altogether these messages will all be collected together in the TDB
file.

In this case 30007501 and 30007502 where created by mkgmap-r3650 and
40001173 was created by mkgmap-r3336.  At least that is what the
copyright message within those files say.

The TDB file contains several copyright blocks, including both these
versions numbers.

Anyway that is a side issue...

I think you are probably looking for --area-name which defaults to
'Overview Map'.  This is the one that is displayed in MapSource anyway.

The 0x52 record defaults to the string 'Test preview map' and has no
known use so we havn't added an option to change it.

Best wishes

..Steve


thomas

Am 28.11.2015 um 19:41 schrieb Thomas Morgenstern:

Edit : the string mkgmap -r3336 is in the Copyrightrecord. Maybee the
copyright is not updated? Creation-time of tbd-file is: 28.11.2015,
19:17 Uhr GMT+1 hour

thomas
Am 28.11.2015 um 19:30 schrieb Thomas Morgenstern:

So i have newly downloaded mkgmap-r3650 and run it again. The
resulting tdb-file is available at :
http://img2ms.de/Downloads/TopoCeuta.tdb. Look  self in it with
hexeditor. At dezimalposition 950 you will find 'mkgmap-r3336'.
Hex-position is 0x3ac.
maybee is the problem the second run ?
regards thomas

Am 28.11.2015 um 18:36 schrieb Gerd Petermann:


Hi Thomas,


I see no way that r3650 produces the string mkgmap-r3336.

So, I guess that you are looking at an old map, which would

also explain that the different options have no effect.


ciao,

Gerd



 


*Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk
<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas
Morgenstern <webmas...@img2ms.de>
*Gesendet:* Samstag, 28. November 2015 18:08
*An:* Development list for mkgmap
*Betreff:* Re: [mkgmap-dev] question for tdb-file record 0x52;
option in mkgmap ?
I use mkgmap r-3650 from downloadsite:
http://www.mkgmap.org.uk/download/mkgmap.html
-->http://www.mkgmap.org.uk/download/mkgmap-r3650.zip.
<http://www.mkgmap.org.uk/download/mkgmap.html>

mkgmap download page
Branch builds. These jar files are latest builds of recent
development branches. They are useful if you want to quickly test a
branch without having obtain and build it.
Weitere Informationen... 
<http://www.mkgmap.org.uk/download/mkgmap.html>





-family-name=Kanaren also make 'Overview Map'.
My way is:
1. in first run I generate all <123345678>.img from *.osm-pbf . for
Europa komplett
2. a secand run : /java -Xmx5000m jar mkgmap.jar -family-id=1918
-product-id=1 -family-name=TopoKanaren -series-name=Topo Kanaren
-overview-mapname=TopoCeuta -code-page=1252 -mapname=Kanaren
-index.img-file/s. This creates the
tdb,preview, mdx and _mdr.img. Works perfekt, but the only mistake
is : 'Overview Map' .

result is : in mapsource ->Fläche' -->'Overview Map' and not 'Topo
Kanaren'
Am 28.11.2015 um 17:11 schrieb Gerd Petermann:


Hallo Thomas,


please try --family-name=xyz.


Where did you get the binary that reports mkgmap-r3336 ?

I assume that you build your own binary, in that case please

use these two commands:

svn update

ant clean dist


Gerd

 


*Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk
<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Thomas
Morgenstern <webmas...@img2ms.de>
*Gesendet:* Samstag, 28. November 2015 15:29
*An:* Development list for mkgmap
*Betreff:* [mkgmap-dev] question for tdb-file record 0x52; option
in mkgmap ?
Has  mkgmap  a option, which write's the record 0x52 in tdb-file ?
My maps have in Mapsource all the entry 'Overview map' . But i will
for example 'Kanaren' or any other countryname. I have testet
followings option without success: -region-name=anywhat
;-country.name= anywhat; -description= anywhat. I use -index to
create the tdb-file. I can use a hexeditor to change tdb- file-
record 0x52. But this is not a preferable way. i must recalculate a
CRC 32 checksum for record 0x54.

By the way: i found a error in the tdb-file, created with mkgmap
r3650 : it prints in the copyright-section :.../.Map created with
mkgmap -r3336/...; It should bee updated to ./.r3650/


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev






___
mkgmap-d

[mkgmap-dev] question

[Steve Sgalowski]

when i use a pbf file from another source . eg osm2garmin  with extract of
australia_nz.pbf

i some how get with my list of poi , a 0x02 problem

meaning a error  occures with a routable way with a non route way .

What do i need to look for in my poi  file ?

Stephen
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] question with poi

[Steve Sgalowski]

is there a way guys , that poi's can be loaded on to highway  or all types
of roads
?

(highway=motorway_link | highway=trunk_link)  mkgmap:exit_hint=true 
mkgmap:dest_hint=true
  { name '${destination:ref|subst: =} ${destination|subst:;= |subst:/=
}' |
 '${ref|subst: =} ${destination|subst:;= |subst:/= }' |
 '${destination|subst:;= |subst:/= }' |
 'Exit ${mkgmap:exit_hint_ref} ${mkgmap:exit_hint_name}' |
 'Exit ${mkgmap:exit_hint_ref} ${mkgmap:exit_hint_exit_to}' |
 'Exit ${mkgmap:exit_hint_exit_to}' |
 'Exit ${mkgmap:exit_hint_name}' |
 'Exit ${mkgmap:exit_hint_ref}'
   }
done in the same setup , when this is done , or setup
 a new one for  poi's with say distance  from you to the point ?

Stephen
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] question about ignored no_u_turn restriction

[Ben Konrath]

Hi Gerd,

I'm just back from my vacation. I just wanted to say thanks for taking the
time figure this out.

Ben

On Sun, Aug 2, 2015 at 11:03 AM, Gerd Petermann 
gpetermann_muenc...@hotmail.com wrote:

 Hi Ben,

 it seems the tests were even more complicated than I thought,
 but in the end, today I found that I was wrong. The no_u_turn restriction
 has an effect, the warning makes no sense.
 This is what I tested:
 Switch to car routing with shortest distance (shorter time seems to
 avoid u-turns),
 and enable automatic recalculation of routes.
 Enter a target which just requires a left turn after 100m. Ignore the left
 turn,
 after a few seconds the device tells me to make a u-turn at the next
 crossing.
 (tried this two or three times with the same result)

 I've then used JOSM to add a no_u_turn restriction for this crossing ,
 created a new
 map (with a different id) and tried again. And, ta-ta, the device shows
 different
 hints for the same situation (no u-turn at this crossing).
 I thought I tried the same last time, but I must have made an error
 somewhere,
 maybe some kind of caching in my Oregon 600.

 So I've removed the check with r3626, the restriction is no longer ignored.

 Gerd

 --
 Date: Sat, 1 Aug 2015 22:11:58 +0200

 From: b...@bagu.org
 To: mkgmap-dev@lists.mkgmap.org.uk
 Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction

 Hi Gerd,

 For point 2, what makes you think that the restriction has no effect on
 Garmin routing? You said that it wasn't easy to test but did you mean that
 it's not possible to test this? If we don't know for sure or if it's too
 hard to test, changing the warning message to an informational would be
 good. You can always add a link to this thread in a comment in case we
 discover more information about the effect on the Garmin routing.

 Thanks again for your help.

 Ben

 On Wed, Jul 29, 2015 at 11:09 AM, Gerd Petermann 
 gpetermann_muenc...@hotmail.com wrote:

 Hi Ben,

 my results so far:
 1) The img format allows to store this kind of no-u-turn, mkgmap also
 doesn't seem to have a problem
 with it, I just have to comment the check.
 2) I still think that the restriction has no effect on Garmin routing

 I think I should change the message to ... no_u_turn with equal 'from' and
 'to' way and via node has no effect, is ignored
 and make it informational.

 OK?

 Gerd


 --
 Date: Tue, 28 Jul 2015 17:38:34 +0200

 From: b...@bagu.org
 To: mkgmap-dev@lists.mkgmap.org.uk
 Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction

 Hi Gerd,

 I guess I was a little to 'quick' with that example. ;-) Thanks for
 looking into this.

 Ben

 On Tue, Jul 28, 2015 at 5:22 PM, Gerd Petermann 
 gpetermann_muenc...@hotmail.com wrote:

 Hi Ben,

 okay, I did not yet think about the case that the device knows in which
 direction you are currently driving
 when it re-calculates a route. I did only consider the case that you are
 planning while standing still.
 If I remember correctly, this case will produce a message like please
 make a u-turn,
 I never saw that it tells me to make a u-turn at a specific place.

 It's not easy to test if Garmin uses this restriction (when written by
 mkgmap), I have to think
 about it.
 @Steve: Do you see these restrictions in Garmin maps?

 Gerd
 PS: Your example is not good, as Quick Avenue is a (wrong) oneway, but
 that shouldn't matter here ;-)

 --
 Date: Tue, 28 Jul 2015 16:50:30 +0200

 From: b...@bagu.org
 To: mkgmap-dev@lists.mkgmap.org.uk
 Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction

 Hi Gerd,

 In this example, if you're travelling southbound on North Harlem Avenue
 and you miss your right turn onto Quick Avenue, the GPS might suggest that
 you make a u-turn at the North Harlem Avenue / Ontario Street intersection
 so that you can double back get back to your original route. The traffic
 rule is saying that you're not allowed to make a u-turn at this
 intersection and the OSM data is capturing the traffic rule correctly.

 I've never been to this area so I can't actually test to see if the Garmin
 routing algorithm would try to do this u-turn. This is just an example that
 I'm using to try to figure if why the restriction is being ignored. I don't
 actually know the details Garmin routing algorithm but I have been routed
 on such u-turns in the past when I've missed a turn.

 Given that this is a legitimate type of 'no u-turn' restriction, if the
 Garmin map format or routing algorithm can't deal with it, there should be
 a message that says so in the warning. In this case, maybe an info message
 makes more sense - but you should probably decide how you want to present
 it since you wrote it. :-) The other side of this is that the Garmin map
 format or routing algorithm can actually handle this specific type of 'no
 u-turn' restriction, in which case it would be nice to have

Re: [mkgmap-dev] question about ignored no_u_turn restriction

[Gerd Petermann]

Hi Ben,

it seems the tests were even more complicated than I thought,
but in the end, today I found that I was wrong. The no_u_turn restriction
has an effect, the warning makes no sense.
This is what I tested:
Switch to car routing with shortest distance (shorter time seems to avoid 
u-turns),
and enable automatic recalculation of routes.
Enter a target which just requires a left turn after 100m. Ignore the left turn,
after a few seconds the device tells me to make a u-turn at the next crossing.
(tried this two or three times with the same result)

I've then used JOSM to add a no_u_turn restriction for this crossing , created 
a new
map (with a different id) and tried again. And, ta-ta, the device shows 
different 
hints for the same situation (no u-turn at this crossing). 
I thought I tried the same last time, but I must have made an error somewhere,
maybe some kind of caching in my Oregon 600.

So I've removed the check with r3626, the restriction is no longer ignored.

Gerd

Date: Sat, 1 Aug 2015 22:11:58 +0200
From: b...@bagu.org
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction

Hi Gerd,

For point 2, what makes you think that the restriction has no effect on Garmin 
routing? You said that it wasn't easy to test but did you mean that it's not 
possible to test this? If we don't know for sure or if it's too hard to test, 
changing the warning message to an informational would be good. You can always 
add a link to this thread in a comment in case we discover more information 
about the effect on the Garmin routing.

Thanks again for your help.

Ben

On Wed, Jul 29, 2015 at 11:09 AM, Gerd Petermann 
gpetermann_muenc...@hotmail.com wrote:



Hi Ben,

my results so far:
1) The img format allows to store this kind of no-u-turn, mkgmap also doesn't 
seem to have a problem
with it, I just have to comment the check.
2) I still think that the restriction has no effect on Garmin routing

I think I should change the message to ... no_u_turn with equal 'from' and 'to' 
way and via node has no effect, is ignored
and make it informational.

OK?

Gerd


Date: Tue, 28 Jul 2015 17:38:34 +0200
From: b...@bagu.org
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction

Hi Gerd,

I guess I was a little to 'quick' with that example. ;-) Thanks for looking 
into this.

Ben

On Tue, Jul 28, 2015 at 5:22 PM, Gerd Petermann 
gpetermann_muenc...@hotmail.com wrote:






Hi Ben,

okay, I did not yet think about the case that the device knows in which 
direction you are currently driving
when it re-calculates a route. I did only consider the case that you are 
planning while standing still.
If I remember correctly, this case will produce a message like please make a 
u-turn, 
I never saw that it tells me to make a u-turn at a specific place.

It's not easy to test if Garmin uses this restriction (when written by mkgmap), 
I have to think 
about it.
@Steve: Do you see these restrictions in Garmin maps?

Gerd
PS: Your example is not good, as Quick Avenue is a (wrong) oneway, but that 
shouldn't matter here ;-)

Date: Tue, 28 Jul 2015 16:50:30 +0200
From: b...@bagu.org
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction

Hi Gerd,

In this example, if you're travelling southbound on North Harlem Avenue and you 
miss your right turn onto Quick Avenue, the GPS might suggest that you make a 
u-turn at the North Harlem Avenue / Ontario Street intersection so that you can 
double back get back to your original route. The traffic rule is saying that 
you're not allowed to make a u-turn at this intersection and the OSM data is 
capturing the traffic rule correctly. 

I've never been to this area so I can't actually test to see if the Garmin 
routing algorithm would try to do this u-turn. This is just an example that I'm 
using to try to figure if why the restriction is being ignored. I don't 
actually know the details Garmin routing algorithm but I have been routed on 
such u-turns in the past when I've missed a turn.

Given that this is a legitimate type of 'no u-turn' restriction, if the Garmin 
map format or routing algorithm can't deal with it, there should be a message 
that says so in the warning. In this case, maybe an info message makes more 
sense - but you should probably decide how you want to present it since you 
wrote it. :-) The other side of this is that the Garmin map format or routing 
algorithm can actually handle this specific type of 'no u-turn' restriction, in 
which case it would be nice to have the restriction included in the maps.

Thanks for your help and all your hard work on mkgmap!

Ben

On Tue, Jul 21, 2015 at 10:44 AM, Gerd Petermann 
gpetermann_muenc...@hotmail.com wrote:



Hi Ben,

unfortunately I did not add a comment to that part of the source which would 
explain
why I coded it, but I think the reason is that the restriction has no effect

Re: [mkgmap-dev] question about ignored no_u_turn restriction

[Ben Konrath]

Hi Chris,

many Garmin devices do have an option avoid u-turns / Ausschluss
 Kehrtwenden.

 So I guess this kind of turn restriction is for the Garmin routing
 algorithm a complete other thing as normal turn-restrictions.


I think the 'avoid u-turns' option tells the device to only do u-turns when
it's the only choice - effectively a 'no u-turn' restriction at every
intersection. I assume that the routing algorithm follows the actual turn
restrictions when the 'avoid u-turns' option is disabled. But as Gerd
pointed out, he's not sure if the no u-turn restriction in my example
actually has an effect so my assumption could be wrong.

Thanks, Ben
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] question about ignored no_u_turn restriction

[Ben Konrath]

Hi Gerd,

For point 2, what makes you think that the restriction has no effect on
Garmin routing? You said that it wasn't easy to test but did you mean that
it's not possible to test this? If we don't know for sure or if it's too
hard to test, changing the warning message to an informational would be
good. You can always add a link to this thread in a comment in case we
discover more information about the effect on the Garmin routing.

Thanks again for your help.

Ben

On Wed, Jul 29, 2015 at 11:09 AM, Gerd Petermann 
gpetermann_muenc...@hotmail.com wrote:

 Hi Ben,

 my results so far:
 1) The img format allows to store this kind of no-u-turn, mkgmap also
 doesn't seem to have a problem
 with it, I just have to comment the check.
 2) I still think that the restriction has no effect on Garmin routing

 I think I should change the message to ... no_u_turn with equal 'from' and
 'to' way and via node has no effect, is ignored
 and make it informational.

 OK?

 Gerd


 --
 Date: Tue, 28 Jul 2015 17:38:34 +0200

 From: b...@bagu.org
 To: mkgmap-dev@lists.mkgmap.org.uk
 Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction

 Hi Gerd,

 I guess I was a little to 'quick' with that example. ;-) Thanks for
 looking into this.

 Ben

 On Tue, Jul 28, 2015 at 5:22 PM, Gerd Petermann 
 gpetermann_muenc...@hotmail.com wrote:

 Hi Ben,

 okay, I did not yet think about the case that the device knows in which
 direction you are currently driving
 when it re-calculates a route. I did only consider the case that you are
 planning while standing still.
 If I remember correctly, this case will produce a message like please
 make a u-turn,
 I never saw that it tells me to make a u-turn at a specific place.

 It's not easy to test if Garmin uses this restriction (when written by
 mkgmap), I have to think
 about it.
 @Steve: Do you see these restrictions in Garmin maps?

 Gerd
 PS: Your example is not good, as Quick Avenue is a (wrong) oneway, but
 that shouldn't matter here ;-)

 --
 Date: Tue, 28 Jul 2015 16:50:30 +0200

 From: b...@bagu.org
 To: mkgmap-dev@lists.mkgmap.org.uk
 Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction

 Hi Gerd,

 In this example, if you're travelling southbound on North Harlem Avenue
 and you miss your right turn onto Quick Avenue, the GPS might suggest that
 you make a u-turn at the North Harlem Avenue / Ontario Street intersection
 so that you can double back get back to your original route. The traffic
 rule is saying that you're not allowed to make a u-turn at this
 intersection and the OSM data is capturing the traffic rule correctly.

 I've never been to this area so I can't actually test to see if the Garmin
 routing algorithm would try to do this u-turn. This is just an example that
 I'm using to try to figure if why the restriction is being ignored. I don't
 actually know the details Garmin routing algorithm but I have been routed
 on such u-turns in the past when I've missed a turn.

 Given that this is a legitimate type of 'no u-turn' restriction, if the
 Garmin map format or routing algorithm can't deal with it, there should be
 a message that says so in the warning. In this case, maybe an info message
 makes more sense - but you should probably decide how you want to present
 it since you wrote it. :-) The other side of this is that the Garmin map
 format or routing algorithm can actually handle this specific type of 'no
 u-turn' restriction, in which case it would be nice to have the restriction
 included in the maps.

 Thanks for your help and all your hard work on mkgmap!

 Ben

 On Tue, Jul 21, 2015 at 10:44 AM, Gerd Petermann 
 gpetermann_muenc...@hotmail.com wrote:

 Hi Ben,

 unfortunately I did not add a comment to that part of the source which
 would explain
 why I coded it, but I think the reason is that the restriction has no
 effect on route calculation.
 I can't think of any case where the Garmin algo would route you along that
 u-turn.
 Do you have an example that proves this assumption to be wrong?

 If not, I can change the msg to say something like has no effect, or
 please suggest a better text.

 Gerd

 --
 Date: Mon, 6 Jul 2015 13:34:12 +0200

 From: b...@bagu.org
 To: mkgmap-dev@lists.mkgmap.org.uk
 Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction

 Just to follow up ... Does anybody know concretely that the Garmin format
 cannot handle and u-turn restriction with the same from and two way?

 Thanks, Ben

 On Sun, Jul 5, 2015 at 9:20 PM, Ben Konrath b...@bagu.org wrote:

 Hi Anor,

 Thanks for the tip but it seems that your suggestion breaks the OSM rule
 of manipulating the map for specific renderers (the renderer here being
 mkgmap). If the Garmin format truly doesn't support the u-turn restriction
 with the same to and from way at an intersection, we should come up with
 another solution.

 Ben

 On Sun, Jul 5, 2015

Re: [mkgmap-dev] question about ignored no_u_turn restriction

[Gerd Petermann]

Hi Ben,

my results so far:
1) The img format allows to store this kind of no-u-turn, mkgmap also doesn't 
seem to have a problem
with it, I just have to comment the check.
2) I still think that the restriction has no effect on Garmin routing

I think I should change the message to ... no_u_turn with equal 'from' and 'to' 
way and via node has no effect, is ignored
and make it informational.

OK?

Gerd


Date: Tue, 28 Jul 2015 17:38:34 +0200
From: b...@bagu.org
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction

Hi Gerd,

I guess I was a little to 'quick' with that example. ;-) Thanks for looking 
into this.

Ben

On Tue, Jul 28, 2015 at 5:22 PM, Gerd Petermann 
gpetermann_muenc...@hotmail.com wrote:






Hi Ben,

okay, I did not yet think about the case that the device knows in which 
direction you are currently driving
when it re-calculates a route. I did only consider the case that you are 
planning while standing still.
If I remember correctly, this case will produce a message like please make a 
u-turn, 
I never saw that it tells me to make a u-turn at a specific place.

It's not easy to test if Garmin uses this restriction (when written by mkgmap), 
I have to think 
about it.
@Steve: Do you see these restrictions in Garmin maps?

Gerd
PS: Your example is not good, as Quick Avenue is a (wrong) oneway, but that 
shouldn't matter here ;-)

Date: Tue, 28 Jul 2015 16:50:30 +0200
From: b...@bagu.org
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction

Hi Gerd,

In this example, if you're travelling southbound on North Harlem Avenue and you 
miss your right turn onto Quick Avenue, the GPS might suggest that you make a 
u-turn at the North Harlem Avenue / Ontario Street intersection so that you can 
double back get back to your original route. The traffic rule is saying that 
you're not allowed to make a u-turn at this intersection and the OSM data is 
capturing the traffic rule correctly. 

I've never been to this area so I can't actually test to see if the Garmin 
routing algorithm would try to do this u-turn. This is just an example that I'm 
using to try to figure if why the restriction is being ignored. I don't 
actually know the details Garmin routing algorithm but I have been routed on 
such u-turns in the past when I've missed a turn.

Given that this is a legitimate type of 'no u-turn' restriction, if the Garmin 
map format or routing algorithm can't deal with it, there should be a message 
that says so in the warning. In this case, maybe an info message makes more 
sense - but you should probably decide how you want to present it since you 
wrote it. :-) The other side of this is that the Garmin map format or routing 
algorithm can actually handle this specific type of 'no u-turn' restriction, in 
which case it would be nice to have the restriction included in the maps.

Thanks for your help and all your hard work on mkgmap!

Ben

On Tue, Jul 21, 2015 at 10:44 AM, Gerd Petermann 
gpetermann_muenc...@hotmail.com wrote:



Hi Ben,

unfortunately I did not add a comment to that part of the source which would 
explain
why I coded it, but I think the reason is that the restriction has no effect on 
route calculation.
I can't think of any case where the Garmin algo would route you along that 
u-turn.
Do you have an example that proves this assumption to be wrong?

If not, I can change the msg to say something like has no effect, or please 
suggest a better text.

Gerd

Date: Mon, 6 Jul 2015 13:34:12 +0200
From: b...@bagu.org
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction

Just to follow up ... Does anybody know concretely that the Garmin format 
cannot handle and u-turn restriction with the same from and two way?

Thanks, Ben

On Sun, Jul 5, 2015 at 9:20 PM, Ben Konrath b...@bagu.org wrote:
Hi Anor,

Thanks for the tip but it seems that your suggestion breaks the OSM rule of 
manipulating the map for specific renderers (the renderer here being mkgmap). 
If the Garmin format truly doesn't support the u-turn restriction with the same 
to and from way at an intersection, we should come up with another solution.

Ben

On Sun, Jul 5, 2015 at 4:01 PM, A. Carlos anorcar...@hotmail.com wrote:




   Ben
  
 There I draw two routes, one in each direction, since there is a false median, 
then with 2-way, it's easy for a restriction

  
 
 
 
 
 
 

___

Anor  Concórdia SC  
 
  
 
 
 
 
 
 
 


Date: Sun, 5 Jul 2015 15:53:50 +0200
From: b...@bagu.org
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction

Hi Thorsten,

Thanks for your reply. This type of restriction is probably a country specific 
thing. In Ontario Canada, you

Re: [mkgmap-dev] question about ignored no_u_turn restriction

[Ben Konrath]

Hi Gerd,

I guess I was a little to 'quick' with that example. ;-) Thanks for looking
into this.

Ben

On Tue, Jul 28, 2015 at 5:22 PM, Gerd Petermann 
gpetermann_muenc...@hotmail.com wrote:

  Hi Ben,

 okay, I did not yet think about the case that the device knows in which
 direction you are currently driving
 when it re-calculates a route. I did only consider the case that you are
 planning while standing still.
 If I remember correctly, this case will produce a message like please
 make a u-turn,
 I never saw that it tells me to make a u-turn at a specific place.

 It's not easy to test if Garmin uses this restriction (when written by
 mkgmap), I have to think
 about it.
 @Steve: Do you see these restrictions in Garmin maps?

 Gerd
 PS: Your example is not good, as Quick Avenue is a (wrong) oneway, but
 that shouldn't matter here ;-)

 --
 Date: Tue, 28 Jul 2015 16:50:30 +0200

 From: b...@bagu.org
 To: mkgmap-dev@lists.mkgmap.org.uk
 Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction

 Hi Gerd,

 In this example, if you're travelling southbound on North Harlem Avenue
 and you miss your right turn onto Quick Avenue, the GPS might suggest that
 you make a u-turn at the North Harlem Avenue / Ontario Street intersection
 so that you can double back get back to your original route. The traffic
 rule is saying that you're not allowed to make a u-turn at this
 intersection and the OSM data is capturing the traffic rule correctly.

 I've never been to this area so I can't actually test to see if the Garmin
 routing algorithm would try to do this u-turn. This is just an example that
 I'm using to try to figure if why the restriction is being ignored. I don't
 actually know the details Garmin routing algorithm but I have been routed
 on such u-turns in the past when I've missed a turn.

 Given that this is a legitimate type of 'no u-turn' restriction, if the
 Garmin map format or routing algorithm can't deal with it, there should be
 a message that says so in the warning. In this case, maybe an info message
 makes more sense - but you should probably decide how you want to present
 it since you wrote it. :-) The other side of this is that the Garmin map
 format or routing algorithm can actually handle this specific type of 'no
 u-turn' restriction, in which case it would be nice to have the restriction
 included in the maps.

 Thanks for your help and all your hard work on mkgmap!

 Ben

 On Tue, Jul 21, 2015 at 10:44 AM, Gerd Petermann 
 gpetermann_muenc...@hotmail.com wrote:

 Hi Ben,

 unfortunately I did not add a comment to that part of the source which
 would explain
 why I coded it, but I think the reason is that the restriction has no
 effect on route calculation.
 I can't think of any case where the Garmin algo would route you along that
 u-turn.
 Do you have an example that proves this assumption to be wrong?

 If not, I can change the msg to say something like has no effect, or
 please suggest a better text.

 Gerd

 --
 Date: Mon, 6 Jul 2015 13:34:12 +0200

 From: b...@bagu.org
 To: mkgmap-dev@lists.mkgmap.org.uk
 Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction

 Just to follow up ... Does anybody know concretely that the Garmin format
 cannot handle and u-turn restriction with the same from and two way?

 Thanks, Ben

 On Sun, Jul 5, 2015 at 9:20 PM, Ben Konrath b...@bagu.org wrote:

 Hi Anor,

 Thanks for the tip but it seems that your suggestion breaks the OSM rule
 of manipulating the map for specific renderers (the renderer here being
 mkgmap). If the Garmin format truly doesn't support the u-turn restriction
 with the same to and from way at an intersection, we should come up with
 another solution.

 Ben

 On Sun, Jul 5, 2015 at 4:01 PM, A. Carlos anorcar...@hotmail.com wrote:


  Ben

 There I draw two routes, one in each direction, since there is a false
 median, then with 2-way, it's easy for a restriction











 *___*

  *Anor  Co*
 *ncórdia SC *














 --
 Date: Sun, 5 Jul 2015 15:53:50 +0200
 From: b...@bagu.org
 To: mkgmap-dev@lists.mkgmap.org.uk
 Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction


 Hi Thorsten,

 Thanks for your reply. This type of restriction is probably a country
 specific thing. In Ontario Canada, you can make u-turns at intersections
 (regardless of the road is separation) if there is no sign indicating that
 you can't make the u-turn. Here's the information directly from the Ontario
 Ministry of Transportation:

 http://www.mto.gov.on.ca/english/dandv/driver/handbook/section2.6.11.shtml

 I realize that the link I sent previously is in the US but I suspect that
 it's the same policy there which is why the restriction is tagged like it
 is.

 Since

Re: [mkgmap-dev] question about ignored no_u_turn restriction

[Gerd Petermann]

Hi Ben,

okay, I did not yet think about the case that the device knows in which 
direction you are currently driving
when it re-calculates a route. I did only consider the case that you are 
planning while standing still.
If I remember correctly, this case will produce a message like please make a 
u-turn, 
I never saw that it tells me to make a u-turn at a specific place.

It's not easy to test if Garmin uses this restriction (when written by mkgmap), 
I have to think 
about it.
@Steve: Do you see these restrictions in Garmin maps?

Gerd
PS: Your example is not good, as Quick Avenue is a (wrong) oneway, but that 
shouldn't matter here ;-)

Date: Tue, 28 Jul 2015 16:50:30 +0200
From: b...@bagu.org
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction

Hi Gerd,

In this example, if you're travelling southbound on North Harlem Avenue and you 
miss your right turn onto Quick Avenue, the GPS might suggest that you make a 
u-turn at the North Harlem Avenue / Ontario Street intersection so that you can 
double back get back to your original route. The traffic rule is saying that 
you're not allowed to make a u-turn at this intersection and the OSM data is 
capturing the traffic rule correctly. 

I've never been to this area so I can't actually test to see if the Garmin 
routing algorithm would try to do this u-turn. This is just an example that I'm 
using to try to figure if why the restriction is being ignored. I don't 
actually know the details Garmin routing algorithm but I have been routed on 
such u-turns in the past when I've missed a turn.

Given that this is a legitimate type of 'no u-turn' restriction, if the Garmin 
map format or routing algorithm can't deal with it, there should be a message 
that says so in the warning. In this case, maybe an info message makes more 
sense - but you should probably decide how you want to present it since you 
wrote it. :-) The other side of this is that the Garmin map format or routing 
algorithm can actually handle this specific type of 'no u-turn' restriction, in 
which case it would be nice to have the restriction included in the maps.

Thanks for your help and all your hard work on mkgmap!

Ben

On Tue, Jul 21, 2015 at 10:44 AM, Gerd Petermann 
gpetermann_muenc...@hotmail.com wrote:



Hi Ben,

unfortunately I did not add a comment to that part of the source which would 
explain
why I coded it, but I think the reason is that the restriction has no effect on 
route calculation.
I can't think of any case where the Garmin algo would route you along that 
u-turn.
Do you have an example that proves this assumption to be wrong?

If not, I can change the msg to say something like has no effect, or please 
suggest a better text.

Gerd

Date: Mon, 6 Jul 2015 13:34:12 +0200
From: b...@bagu.org
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction

Just to follow up ... Does anybody know concretely that the Garmin format 
cannot handle and u-turn restriction with the same from and two way?

Thanks, Ben

On Sun, Jul 5, 2015 at 9:20 PM, Ben Konrath b...@bagu.org wrote:
Hi Anor,

Thanks for the tip but it seems that your suggestion breaks the OSM rule of 
manipulating the map for specific renderers (the renderer here being mkgmap). 
If the Garmin format truly doesn't support the u-turn restriction with the same 
to and from way at an intersection, we should come up with another solution.

Ben

On Sun, Jul 5, 2015 at 4:01 PM, A. Carlos anorcar...@hotmail.com wrote:




   Ben
  
 There I draw two routes, one in each direction, since there is a false median, 
then with 2-way, it's easy for a restriction

  
 
 
 
 
 
 

___

Anor  Concórdia SC  
 
  
 
 
 
 
 
 
 


Date: Sun, 5 Jul 2015 15:53:50 +0200
From: b...@bagu.org
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction

Hi Thorsten,

Thanks for your reply. This type of restriction is probably a country specific 
thing. In Ontario Canada, you can make u-turns at intersections (regardless of 
the road is separation) if there is no sign indicating that you can't make the 
u-turn. Here's the information directly from the Ontario Ministry of 
Transportation:

http://www.mto.gov.on.ca/english/dandv/driver/handbook/section2.6.11.shtml

I realize that the link I sent previously is in the US but I suspect that it's 
the same policy there which is why the restriction is tagged like it is.

Since the tagging seems to be valid, does the Garmin format support this type 
of restriction? If not then it's probably a good idea to indicate this in the 
warning message. Maybe the message should also be changed to an info message if 
there's no problem with the data. Does anybody have other insights?

Thanks, Ben

Re: [mkgmap-dev] question about ignored no_u_turn restriction

[Ben Konrath]

Hi Gerd,

In this example, if you're travelling southbound on North Harlem Avenue and
you miss your right turn onto Quick Avenue, the GPS might suggest that you
make a u-turn at the North Harlem Avenue / Ontario Street intersection so
that you can double back get back to your original route. The traffic rule
is saying that you're not allowed to make a u-turn at this intersection and
the OSM data is capturing the traffic rule correctly.

I've never been to this area so I can't actually test to see if the Garmin
routing algorithm would try to do this u-turn. This is just an example that
I'm using to try to figure if why the restriction is being ignored. I don't
actually know the details Garmin routing algorithm but I have been routed
on such u-turns in the past when I've missed a turn.

Given that this is a legitimate type of 'no u-turn' restriction, if the
Garmin map format or routing algorithm can't deal with it, there should be
a message that says so in the warning. In this case, maybe an info message
makes more sense - but you should probably decide how you want to present
it since you wrote it. :-) The other side of this is that the Garmin map
format or routing algorithm can actually handle this specific type of 'no
u-turn' restriction, in which case it would be nice to have the restriction
included in the maps.

Thanks for your help and all your hard work on mkgmap!

Ben

On Tue, Jul 21, 2015 at 10:44 AM, Gerd Petermann 
gpetermann_muenc...@hotmail.com wrote:

 Hi Ben,

 unfortunately I did not add a comment to that part of the source which
 would explain
 why I coded it, but I think the reason is that the restriction has no
 effect on route calculation.
 I can't think of any case where the Garmin algo would route you along that
 u-turn.
 Do you have an example that proves this assumption to be wrong?

 If not, I can change the msg to say something like has no effect, or
 please suggest a better text.

 Gerd

 --
 Date: Mon, 6 Jul 2015 13:34:12 +0200

 From: b...@bagu.org
 To: mkgmap-dev@lists.mkgmap.org.uk
 Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction

 Just to follow up ... Does anybody know concretely that the Garmin format
 cannot handle and u-turn restriction with the same from and two way?

 Thanks, Ben

 On Sun, Jul 5, 2015 at 9:20 PM, Ben Konrath b...@bagu.org wrote:

 Hi Anor,

 Thanks for the tip but it seems that your suggestion breaks the OSM rule
 of manipulating the map for specific renderers (the renderer here being
 mkgmap). If the Garmin format truly doesn't support the u-turn restriction
 with the same to and from way at an intersection, we should come up with
 another solution.

 Ben

 On Sun, Jul 5, 2015 at 4:01 PM, A. Carlos anorcar...@hotmail.com wrote:


  Ben

 There I draw two routes, one in each direction, since there is a false
 median, then with 2-way, it's easy for a restriction











 *___*

  *Anor  Co*
 *ncórdia SC *














 --
 Date: Sun, 5 Jul 2015 15:53:50 +0200
 From: b...@bagu.org
 To: mkgmap-dev@lists.mkgmap.org.uk
 Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction


 Hi Thorsten,

 Thanks for your reply. This type of restriction is probably a country
 specific thing. In Ontario Canada, you can make u-turns at intersections
 (regardless of the road is separation) if there is no sign indicating that
 you can't make the u-turn. Here's the information directly from the Ontario
 Ministry of Transportation:

 http://www.mto.gov.on.ca/english/dandv/driver/handbook/section2.6.11.shtml

 I realize that the link I sent previously is in the US but I suspect that
 it's the same policy there which is why the restriction is tagged like it
 is.

 Since the tagging seems to be valid, does the Garmin format support this
 type of restriction? If not then it's probably a good idea to indicate this
 in the warning message. Maybe the message should also be changed to an info
 message if there's no problem with the data. Does anybody have other
 insights?

 Thanks, Ben

 On Sun, Jul 5, 2015 at 2:47 PM, Thorsten Kukuk ku...@suse.de wrote:

 On Sun, Jul 05, Ben Konrath wrote:

  Does anybody know why this particular restriction is being ignored?

 Beside that this particular type of restrictions doesn't make
 any sense to me, I would guess the GARMIN format does not support it.

 If the to and from ways are the same, I have never seen a sign forbidding
 u-turns. Only, if you have two ways, structural seperated. But then I
 should tag the street that way and the restriction will not be ignored.

   Thorsten

 --
 Thorsten Kukuk, Senior Architect SLES  Common Code Base
 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
 GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB
 21284 (AG Nürnberg

Re: [mkgmap-dev] question about ignored no_u_turn restriction

[chris66]

Am 28.07.2015 um 17:22 schrieb Gerd Petermann:
 
 Hi Ben,
 
 okay, I did not yet think about the case that the device knows in which 
 direction you are currently driving
 when it re-calculates a route. I did only consider the case that you are 
 planning while standing still.
 If I remember correctly, this case will produce a message like please make a 
 u-turn, 
 I never saw that it tells me to make a u-turn at a specific place.

Hi,
many Garmin devices do have an option avoid u-turns / Ausschluss
Kehrtwenden.

So I guess this kind of turn restriction is for the Garmin routing
algorithm a complete other thing as normal turn-restrictions.

Chris




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about non-routable ways removed by WrongAngleFixer

[Carlos Dávila]

El 27/07/15 a las 11:26, Gerd Petermann escribió:

Hi Carlos,

these ways are removed because WrongAngleFixer finds that they are
too short, means, all points are rounded to the same Garmin Map point.
For the ids listed below this looks wrong.
I am not able to reproduce the messages with the default style.
Please let me know more details.
I have uploaded the tile containing way 183447340 to 
http://mapas.alternativaslibres.es/55114007.o5m
mkgmap command: java -Xmx2000m -enableassertions 
-Dlog.config=logging.properties -XX:StringTableSize=13 -jar 
mkgmap.jar --output-dir=../mapas/spain --max-jobs --bounds=bounds.zip 
--precomp-sea=sea.zip --route --latin1 --code-page=1252 --tdbfile 
--country-name=ESPAÑA --country-abbr=ESP --area-name=España 
--family-name=OpenStreetMap España --family-id=114 --product-id=1 
--series-name=OSM-España --overview-mapname=ESP-114 
--overview-mapnumber=55114000 --index --x-split-name-index 
--process-destination --process-exits --housenumbers 
--remove-short-arcs=0 --reduce-point-density=4 --add-pois-to-areas 
--adjust-turn-headings --report-similar-arcs --link-pois-to-ways 
--location-autofill=is_in --drive-on=right --check-roundabouts 
--check-roundabout-flares --license-file=license_ODbL.txt 
--copyright-message=OpenStreetMap contributors, ODbL. See: 
http://www.openstreetmap.org/copyright; 
--style-file=../resources/styles/ --style=mio --check-styles --verbose 
-c spain.args (change -c spain.args by the tile)

With default style that way is also removed.


Regarding the generated ids: I agree that these are not very useful.
We have the same problem at many places where mkgmap issues
warnings. I am not sure what to do with them. In this specific place
I think that program should reduce the severity to info.

Gerd

 Date: Sun, 26 Jul 2015 16:44:24 +0200
 From: cardavi...@gmail.com
 To: mkgmap-dev@lists.mkgmap.org.uk
 Subject: [mkgmap-dev] Question about non-routable ways removed by 
WrongAngleFixer


 There are several warnings in my log of the type below. I have check
 some of them and they all seem to be waterway=* ways. Why are these
 waterways (and no others) removed? Could it be avoided?
 (WrongAngleFixer): non-routable way 183447340 was removed
 (WrongAngleFixer): non-routable way 358689387 was removed
 (WrongAngleFixer): non-routable way 358689379 was removed
 There are also some warnings referring to mkgmap generated ways that
 can't be checked. These warnings seem useless. Perhaps a check to omit
 ways with id greater than a given number could be used:
 (WrongAngleFixer): non-routable way 4611686018427769516 was removed
 (WrongAngleFixer): non-routable way 4611686018427769586 was removed
 (WrongAngleFixer): non-routable way 4611686018427769437 was removed

 ___
 mkgmap-dev mailing list
 mkgmap-dev@lists.mkgmap.org.uk
 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



--
Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, 
.ppt, .pptx, .mdb, mdbx
Instale LibreOffice desde http://es.libreoffice.org/descarga/
LibreOffice es libre: se puede copiar, modificar y redistribuir libremente. 
Gratis y totalmente legal.
LibreOffice está en continuo desarrollo y no tendrá que pagar por las nuevas 
versiones.

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about non-routable ways removed by WrongAngleFixer

[Gerd Petermann]

Hi Carlos,

the server can not be reached:
http://mapas.alternativaslibres.es/55114007.o5m

Please try to upload to 
http://files.mkgmap.org.uk/

Gerd

 Date: Mon, 27 Jul 2015 14:16:23 +0200
 From: cdavi...@orangecorreo.es
 To: mkgmap-dev@lists.mkgmap.org.uk
 Subject: Re: [mkgmap-dev] Question about non-routable ways removed by 
 WrongAngleFixer
 
 El 27/07/15 a las 11:26, Gerd Petermann escribió:
  Hi Carlos,
 
  these ways are removed because WrongAngleFixer finds that they are
  too short, means, all points are rounded to the same Garmin Map point.
  For the ids listed below this looks wrong.
  I am not able to reproduce the messages with the default style.
  Please let me know more details.
 I have uploaded the tile containing way 183447340 to 
 http://mapas.alternativaslibres.es/55114007.o5m
 mkgmap command: java -Xmx2000m -enableassertions 
 -Dlog.config=logging.properties -XX:StringTableSize=13 -jar 
 mkgmap.jar --output-dir=../mapas/spain --max-jobs --bounds=bounds.zip 
 --precomp-sea=sea.zip --route --latin1 --code-page=1252 --tdbfile 
 --country-name=ESPAÑA --country-abbr=ESP --area-name=España 
 --family-name=OpenStreetMap España --family-id=114 --product-id=1 
 --series-name=OSM-España --overview-mapname=ESP-114 
 --overview-mapnumber=55114000 --index --x-split-name-index 
 --process-destination --process-exits --housenumbers 
 --remove-short-arcs=0 --reduce-point-density=4 --add-pois-to-areas 
 --adjust-turn-headings --report-similar-arcs --link-pois-to-ways 
 --location-autofill=is_in --drive-on=right --check-roundabouts 
 --check-roundabout-flares --license-file=license_ODbL.txt 
 --copyright-message=OpenStreetMap contributors, ODbL. See: 
 http://www.openstreetmap.org/copyright; 
 --style-file=../resources/styles/ --style=mio --check-styles --verbose 
 -c spain.args (change -c spain.args by the tile)
 With default style that way is also removed.
 
  Regarding the generated ids: I agree that these are not very useful.
  We have the same problem at many places where mkgmap issues
  warnings. I am not sure what to do with them. In this specific place
  I think that program should reduce the severity to info.
 
  Gerd
 
   Date: Sun, 26 Jul 2015 16:44:24 +0200
   From: cardavi...@gmail.com
   To: mkgmap-dev@lists.mkgmap.org.uk
   Subject: [mkgmap-dev] Question about non-routable ways removed by 
  WrongAngleFixer
  
   There are several warnings in my log of the type below. I have check
   some of them and they all seem to be waterway=* ways. Why are these
   waterways (and no others) removed? Could it be avoided?
   (WrongAngleFixer): non-routable way 183447340 was removed
   (WrongAngleFixer): non-routable way 358689387 was removed
   (WrongAngleFixer): non-routable way 358689379 was removed
   There are also some warnings referring to mkgmap generated ways that
   can't be checked. These warnings seem useless. Perhaps a check to omit
   ways with id greater than a given number could be used:
   (WrongAngleFixer): non-routable way 4611686018427769516 was removed
   (WrongAngleFixer): non-routable way 4611686018427769586 was removed
   (WrongAngleFixer): non-routable way 4611686018427769437 was removed
  
   ___
   mkgmap-dev mailing list
   mkgmap-dev@lists.mkgmap.org.uk
   http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
 
 
  ___
  mkgmap-dev mailing list
  mkgmap-dev@lists.mkgmap.org.uk
  http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
 
 
 -- 
 Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, 
 .ppt, .pptx, .mdb, mdbx
 Instale LibreOffice desde http://es.libreoffice.org/descarga/
 LibreOffice es libre: se puede copiar, modificar y redistribuir libremente. 
 Gratis y totalmente legal.
 LibreOffice está en continuo desarrollo y no tendrá que pagar por las nuevas 
 versiones.
 
 ___
 mkgmap-dev mailing list
 mkgmap-dev@lists.mkgmap.org.uk
 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
  ___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about non-routable ways removed by WrongAngleFixer

[Carlos Dávila]

El 27/07/15 a las 18:12, Gerd Petermann escribió:

Hi Carlos,

the server can not be reached:
http://mapas.alternativaslibres.es/55114007.o5m

Server was down this afternoon for a few hours, sorry


Please try to upload to
http://files.mkgmap.org.uk/

Done: |http://files.mkgmap.org.uk/download/272/55114007.o5m|


Gerd

 Date: Mon, 27 Jul 2015 14:16:23 +0200
 From: cdavi...@orangecorreo.es
 To: mkgmap-dev@lists.mkgmap.org.uk
 Subject: Re: [mkgmap-dev] Question about non-routable ways removed 
by WrongAngleFixer


 El 27/07/15 a las 11:26, Gerd Petermann escribió:
  Hi Carlos,
 
  these ways are removed because WrongAngleFixer finds that they are
  too short, means, all points are rounded to the same Garmin Map point.
  For the ids listed below this looks wrong.
  I am not able to reproduce the messages with the default style.
  Please let me know more details.
 I have uploaded the tile containing way 183447340 to
 http://mapas.alternativaslibres.es/55114007.o5m
 mkgmap command: java -Xmx2000m -enableassertions
 -Dlog.config=logging.properties -XX:StringTableSize=13 -jar
 mkgmap.jar --output-dir=../mapas/spain --max-jobs --bounds=bounds.zip
 --precomp-sea=sea.zip --route --latin1 --code-page=1252 --tdbfile
 --country-name=ESPAÑA --country-abbr=ESP --area-name=España
 --family-name=OpenStreetMap España --family-id=114 --product-id=1
 --series-name=OSM-España --overview-mapname=ESP-114
 --overview-mapnumber=55114000 --index --x-split-name-index
 --process-destination --process-exits --housenumbers
 --remove-short-arcs=0 --reduce-point-density=4 --add-pois-to-areas
 --adjust-turn-headings --report-similar-arcs --link-pois-to-ways
 --location-autofill=is_in --drive-on=right --check-roundabouts
 --check-roundabout-flares --license-file=license_ODbL.txt
 --copyright-message=OpenStreetMap contributors, ODbL. See:
 http://www.openstreetmap.org/copyright;
 --style-file=../resources/styles/ --style=mio --check-styles --verbose
 -c spain.args (change -c spain.args by the tile)
 With default style that way is also removed.
 
  Regarding the generated ids: I agree that these are not very useful.
  We have the same problem at many places where mkgmap issues
  warnings. I am not sure what to do with them. In this specific place
  I think that program should reduce the severity to info.
 
  Gerd
 
   Date: Sun, 26 Jul 2015 16:44:24 +0200
   From: cardavi...@gmail.com
   To: mkgmap-dev@lists.mkgmap.org.uk
   Subject: [mkgmap-dev] Question about non-routable ways removed by
  WrongAngleFixer
  
   There are several warnings in my log of the type below. I have check
   some of them and they all seem to be waterway=* ways. Why are these
   waterways (and no others) removed? Could it be avoided?
   (WrongAngleFixer): non-routable way 183447340 was removed
   (WrongAngleFixer): non-routable way 358689387 was removed
   (WrongAngleFixer): non-routable way 358689379 was removed
   There are also some warnings referring to mkgmap generated ways that
   can't be checked. These warnings seem useless. Perhaps a check 
to omit

   ways with id greater than a given number could be used:
   (WrongAngleFixer): non-routable way 4611686018427769516 was removed
   (WrongAngleFixer): non-routable way 4611686018427769586 was removed
   (WrongAngleFixer): non-routable way 4611686018427769437 was removed
  


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about non-routable ways removed by WrongAngleFixer

[Gerd Petermann]

Hi Carlos,

thanks, I was now able to reproduce the problem.
It was introduced with a change in r3180. Before this change
ways which were clipped at tile boundaries so that only
one point was left were rejected much earlier.
With r3624 I've now restored that old behaviour,
the messages from WrongAngleFixer are gone.

Gerd

 Date: Mon, 27 Jul 2015 22:25:07 +0200
 From: cdavi...@orangecorreo.es
 To: mkgmap-dev@lists.mkgmap.org.uk
 Subject: Re: [mkgmap-dev] Question about non-routable ways removed by 
 WrongAngleFixer
 
 
 El 27/07/15 a las 18:12, Gerd Petermann escribió:
  Hi Carlos,
 
  the server can not be reached:
  http://mapas.alternativaslibres.es/55114007.o5m
 Server was down this afternoon for a few hours, sorry
 
  Please try to upload to
  http://files.mkgmap.org.uk/
 Done: |http://files.mkgmap.org.uk/download/272/55114007.o5m|
 
  Gerd
 
   Date: Mon, 27 Jul 2015 14:16:23 +0200
   From: cdavi...@orangecorreo.es
   To: mkgmap-dev@lists.mkgmap.org.uk
   Subject: Re: [mkgmap-dev] Question about non-routable ways removed 
  by WrongAngleFixer
  
   El 27/07/15 a las 11:26, Gerd Petermann escribió:
Hi Carlos,
   
these ways are removed because WrongAngleFixer finds that they are
too short, means, all points are rounded to the same Garmin Map point.
For the ids listed below this looks wrong.
I am not able to reproduce the messages with the default style.
Please let me know more details.
   I have uploaded the tile containing way 183447340 to
   http://mapas.alternativaslibres.es/55114007.o5m
   mkgmap command: java -Xmx2000m -enableassertions
   -Dlog.config=logging.properties -XX:StringTableSize=13 -jar
   mkgmap.jar --output-dir=../mapas/spain --max-jobs --bounds=bounds.zip
   --precomp-sea=sea.zip --route --latin1 --code-page=1252 --tdbfile
   --country-name=ESPAÑA --country-abbr=ESP --area-name=España
   --family-name=OpenStreetMap España --family-id=114 --product-id=1
   --series-name=OSM-España --overview-mapname=ESP-114
   --overview-mapnumber=55114000 --index --x-split-name-index
   --process-destination --process-exits --housenumbers
   --remove-short-arcs=0 --reduce-point-density=4 --add-pois-to-areas
   --adjust-turn-headings --report-similar-arcs --link-pois-to-ways
   --location-autofill=is_in --drive-on=right --check-roundabouts
   --check-roundabout-flares --license-file=license_ODbL.txt
   --copyright-message=OpenStreetMap contributors, ODbL. See:
   http://www.openstreetmap.org/copyright;
   --style-file=../resources/styles/ --style=mio --check-styles --verbose
   -c spain.args (change -c spain.args by the tile)
   With default style that way is also removed.
   
Regarding the generated ids: I agree that these are not very useful.
We have the same problem at many places where mkgmap issues
warnings. I am not sure what to do with them. In this specific place
I think that program should reduce the severity to info.
   
Gerd
   
 Date: Sun, 26 Jul 2015 16:44:24 +0200
 From: cardavi...@gmail.com
 To: mkgmap-dev@lists.mkgmap.org.uk
 Subject: [mkgmap-dev] Question about non-routable ways removed by
WrongAngleFixer

 There are several warnings in my log of the type below. I have check
 some of them and they all seem to be waterway=* ways. Why are these
 waterways (and no others) removed? Could it be avoided?
 (WrongAngleFixer): non-routable way 183447340 was removed
 (WrongAngleFixer): non-routable way 358689387 was removed
 (WrongAngleFixer): non-routable way 358689379 was removed
 There are also some warnings referring to mkgmap generated ways that
 can't be checked. These warnings seem useless. Perhaps a check 
  to omit
 ways with id greater than a given number could be used:
 (WrongAngleFixer): non-routable way 4611686018427769516 was removed
 (WrongAngleFixer): non-routable way 4611686018427769586 was removed
 (WrongAngleFixer): non-routable way 4611686018427769437 was removed

 
 ___
 mkgmap-dev mailing list
 mkgmap-dev@lists.mkgmap.org.uk
 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
  ___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Question about non-routable ways removed by WrongAngleFixer

[Carlos Dávila]

There are several warnings in my log of the type below. I have check 
some of them and they all seem to be waterway=* ways. Why are these 
waterways (and no others) removed? Could it be avoided?

(WrongAngleFixer): non-routable way  183447340 was removed
(WrongAngleFixer): non-routable way  358689387 was removed
(WrongAngleFixer): non-routable way  358689379 was removed
There are also some warnings referring to mkgmap generated ways that 
can't be checked. These warnings seem useless. Perhaps a check to omit 
ways with id greater than a given number could be used:

(WrongAngleFixer): non-routable way  4611686018427769516 was removed
(WrongAngleFixer): non-routable way  4611686018427769586 was removed
(WrongAngleFixer): non-routable way  4611686018427769437 was removed

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about non-routable ways removed by WrongAngleFixer

[Gerd Petermann]

Hi Carlos,

these ways are removed because WrongAngleFixer finds that they are
too short, means, all points are rounded to the same Garmin Map point.
For the ids listed below this looks wrong.
I am not able to reproduce the messages with the default style.
Please let me know more details.

Regarding the generated ids: I agree that these are not very useful.
We have the same problem at many places where mkgmap issues
warnings. I am not sure what to do with them. In this specific place 
I think that program should reduce the severity to info.

Gerd

 Date: Sun, 26 Jul 2015 16:44:24 +0200
 From: cardavi...@gmail.com
 To: mkgmap-dev@lists.mkgmap.org.uk
 Subject: [mkgmap-dev] Question about non-routable ways removed by 
 WrongAngleFixer
 
 There are several warnings in my log of the type below. I have check 
 some of them and they all seem to be waterway=* ways. Why are these 
 waterways (and no others) removed? Could it be avoided?
 (WrongAngleFixer): non-routable way  183447340 was removed
 (WrongAngleFixer): non-routable way  358689387 was removed
 (WrongAngleFixer): non-routable way  358689379 was removed
 There are also some warnings referring to mkgmap generated ways that 
 can't be checked. These warnings seem useless. Perhaps a check to omit 
 ways with id greater than a given number could be used:
 (WrongAngleFixer): non-routable way  4611686018427769516 was removed
 (WrongAngleFixer): non-routable way  4611686018427769586 was removed
 (WrongAngleFixer): non-routable way  4611686018427769437 was removed
 
 ___
 mkgmap-dev mailing list
 mkgmap-dev@lists.mkgmap.org.uk
 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
  ___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] question about ignored no_u_turn restriction

[Gerd Petermann]

Hi Ben,

unfortunately I did not add a comment to that part of the source which would 
explain
why I coded it, but I think the reason is that the restriction has no effect on 
route calculation.
I can't think of any case where the Garmin algo would route you along that 
u-turn.
Do you have an example that proves this assumption to be wrong?

If not, I can change the msg to say something like has no effect, or please 
suggest a better text.

Gerd

Date: Mon, 6 Jul 2015 13:34:12 +0200
From: b...@bagu.org
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction

Just to follow up ... Does anybody know concretely that the Garmin format 
cannot handle and u-turn restriction with the same from and two way?

Thanks, Ben

On Sun, Jul 5, 2015 at 9:20 PM, Ben Konrath b...@bagu.org wrote:
Hi Anor,

Thanks for the tip but it seems that your suggestion breaks the OSM rule of 
manipulating the map for specific renderers (the renderer here being mkgmap). 
If the Garmin format truly doesn't support the u-turn restriction with the same 
to and from way at an intersection, we should come up with another solution.

Ben

On Sun, Jul 5, 2015 at 4:01 PM, A. Carlos anorcar...@hotmail.com wrote:




   Ben
  
 There I draw two routes, one in each direction, since there is a false median, 
then with 2-way, it's easy for a restriction

  
 
 
 
 
 
 

___

Anor  Concórdia SC  
 
  
 
 
 
 
 
 
 


Date: Sun, 5 Jul 2015 15:53:50 +0200
From: b...@bagu.org
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction

Hi Thorsten,

Thanks for your reply. This type of restriction is probably a country specific 
thing. In Ontario Canada, you can make u-turns at intersections (regardless of 
the road is separation) if there is no sign indicating that you can't make the 
u-turn. Here's the information directly from the Ontario Ministry of 
Transportation:

http://www.mto.gov.on.ca/english/dandv/driver/handbook/section2.6.11.shtml

I realize that the link I sent previously is in the US but I suspect that it's 
the same policy there which is why the restriction is tagged like it is.

Since the tagging seems to be valid, does the Garmin format support this type 
of restriction? If not then it's probably a good idea to indicate this in the 
warning message. Maybe the message should also be changed to an info message if 
there's no problem with the data. Does anybody have other insights?

Thanks, Ben

On Sun, Jul 5, 2015 at 2:47 PM, Thorsten Kukuk ku...@suse.de wrote:
On Sun, Jul 05, Ben Konrath wrote:



 Does anybody know why this particular restriction is being ignored?



Beside that this particular type of restrictions doesn't make

any sense to me, I would guess the GARMIN format does not support it.



If the to and from ways are the same, I have never seen a sign forbidding

u-turns. Only, if you have two ways, structural seperated. But then I

should tag the street that way and the restriction will not be ignored.



  Thorsten



--

Thorsten Kukuk, Senior Architect SLES  Common Code Base

SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany

GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 
(AG Nürnberg)

___

mkgmap-dev mailing list

mkgmap-dev@lists.mkgmap.org.uk

http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
  

___

mkgmap-dev mailing list

mkgmap-dev@lists.mkgmap.org.uk

http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
  ___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] question about ignored no_u_turn restriction

[Ben Konrath]

Just to follow up ... Does anybody know concretely that the Garmin format
cannot handle and u-turn restriction with the same from and two way?

Thanks, Ben

On Sun, Jul 5, 2015 at 9:20 PM, Ben Konrath b...@bagu.org wrote:

 Hi Anor,

 Thanks for the tip but it seems that your suggestion breaks the OSM rule
 of manipulating the map for specific renderers (the renderer here being
 mkgmap). If the Garmin format truly doesn't support the u-turn restriction
 with the same to and from way at an intersection, we should come up with
 another solution.

 Ben

 On Sun, Jul 5, 2015 at 4:01 PM, A. Carlos anorcar...@hotmail.com wrote:


  Ben

 There I draw two routes, one in each direction, since there is a false
 median, then with 2-way, it's easy for a restriction











 *___*

  *Anor  Co*
 *ncórdia SC *














 --
 Date: Sun, 5 Jul 2015 15:53:50 +0200
 From: b...@bagu.org
 To: mkgmap-dev@lists.mkgmap.org.uk
 Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction


 Hi Thorsten,

 Thanks for your reply. This type of restriction is probably a country
 specific thing. In Ontario Canada, you can make u-turns at intersections
 (regardless of the road is separation) if there is no sign indicating that
 you can't make the u-turn. Here's the information directly from the Ontario
 Ministry of Transportation:

 http://www.mto.gov.on.ca/english/dandv/driver/handbook/section2.6.11.shtml

 I realize that the link I sent previously is in the US but I suspect that
 it's the same policy there which is why the restriction is tagged like it
 is.

 Since the tagging seems to be valid, does the Garmin format support this
 type of restriction? If not then it's probably a good idea to indicate this
 in the warning message. Maybe the message should also be changed to an info
 message if there's no problem with the data. Does anybody have other
 insights?

 Thanks, Ben

 On Sun, Jul 5, 2015 at 2:47 PM, Thorsten Kukuk ku...@suse.de wrote:

 On Sun, Jul 05, Ben Konrath wrote:

  Does anybody know why this particular restriction is being ignored?

 Beside that this particular type of restrictions doesn't make
 any sense to me, I would guess the GARMIN format does not support it.

 If the to and from ways are the same, I have never seen a sign forbidding
 u-turns. Only, if you have two ways, structural seperated. But then I
 should tag the street that way and the restriction will not be ignored.

   Thorsten

 --
 Thorsten Kukuk, Senior Architect SLES  Common Code Base
 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
 GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB
 21284 (AG Nürnberg)
 ___
 mkgmap-dev mailing list
 mkgmap-dev@lists.mkgmap.org.uk
 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



 ___ mkgmap-dev mailing list
 mkgmap-dev@lists.mkgmap.org.uk
 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

 ___
 mkgmap-dev mailing list
 mkgmap-dev@lists.mkgmap.org.uk
 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] question about ignored no_u_turn restriction

[A. Carlos]

   Ben
  
 There I draw two routes, one in each direction, since there is a false median, 
then with 2-way, it's easy for a restriction

  
 
 
 
 
 
 

___

Anor  Concórdia SC  
 
  
 
 
 
 
 
 
 


Date: Sun, 5 Jul 2015 15:53:50 +0200
From: b...@bagu.org
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction

Hi Thorsten,

Thanks for your reply. This type of restriction is probably a country specific 
thing. In Ontario Canada, you can make u-turns at intersections (regardless of 
the road is separation) if there is no sign indicating that you can't make the 
u-turn. Here's the information directly from the Ontario Ministry of 
Transportation:

http://www.mto.gov.on.ca/english/dandv/driver/handbook/section2.6.11.shtml

I realize that the link I sent previously is in the US but I suspect that it's 
the same policy there which is why the restriction is tagged like it is.

Since the tagging seems to be valid, does the Garmin format support this type 
of restriction? If not then it's probably a good idea to indicate this in the 
warning message. Maybe the message should also be changed to an info message if 
there's no problem with the data. Does anybody have other insights?

Thanks, Ben

On Sun, Jul 5, 2015 at 2:47 PM, Thorsten Kukuk ku...@suse.de wrote:
On Sun, Jul 05, Ben Konrath wrote:



 Does anybody know why this particular restriction is being ignored?



Beside that this particular type of restrictions doesn't make

any sense to me, I would guess the GARMIN format does not support it.



If the to and from ways are the same, I have never seen a sign forbidding

u-turns. Only, if you have two ways, structural seperated. But then I

should tag the street that way and the restriction will not be ignored.



  Thorsten



--

Thorsten Kukuk, Senior Architect SLES  Common Code Base

SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany

GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 
(AG Nürnberg)

___

mkgmap-dev mailing list

mkgmap-dev@lists.mkgmap.org.uk

http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
  ___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] question about ignored no_u_turn restriction

[Thorsten Kukuk]

On Sun, Jul 05, Ben Konrath wrote:

 Does anybody know why this particular restriction is being ignored?

Beside that this particular type of restrictions doesn't make
any sense to me, I would guess the GARMIN format does not support it.

If the to and from ways are the same, I have never seen a sign forbidding
u-turns. Only, if you have two ways, structural seperated. But then I
should tag the street that way and the restriction will not be ignored.

  Thorsten

-- 
Thorsten Kukuk, Senior Architect SLES  Common Code Base
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 
(AG Nürnberg)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] question about ignored no_u_turn restriction

[Ben Konrath]

Hi Thorsten,

Thanks for your reply. This type of restriction is probably a country
specific thing. In Ontario Canada, you can make u-turns at intersections
(regardless of the road is separation) if there is no sign indicating that
you can't make the u-turn. Here's the information directly from the Ontario
Ministry of Transportation:

http://www.mto.gov.on.ca/english/dandv/driver/handbook/section2.6.11.shtml

I realize that the link I sent previously is in the US but I suspect that
it's the same policy there which is why the restriction is tagged like it
is.

Since the tagging seems to be valid, does the Garmin format support this
type of restriction? If not then it's probably a good idea to indicate this
in the warning message. Maybe the message should also be changed to an info
message if there's no problem with the data. Does anybody have other
insights?

Thanks, Ben

On Sun, Jul 5, 2015 at 2:47 PM, Thorsten Kukuk ku...@suse.de wrote:

 On Sun, Jul 05, Ben Konrath wrote:

  Does anybody know why this particular restriction is being ignored?

 Beside that this particular type of restrictions doesn't make
 any sense to me, I would guess the GARMIN format does not support it.

 If the to and from ways are the same, I have never seen a sign forbidding
 u-turns. Only, if you have two ways, structural seperated. But then I
 should tag the street that way and the restriction will not be ignored.

   Thorsten

 --
 Thorsten Kukuk, Senior Architect SLES  Common Code Base
 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
 GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB
 21284 (AG Nürnberg)
 ___
 mkgmap-dev mailing list
 mkgmap-dev@lists.mkgmap.org.uk
 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] question about ignored no_u_turn restriction

[Ben Konrath]

Hi everybody,

I recently noticed a bunch of warning messages about ignored no_u_turn
restrictions. Here's an example:

2015/07/04 18:12:50 WARNING (RestrictionRelation): 17244023.o5m: Turn
restriction (no_u_turn) http://www.openstreetmap.org/relation/4630872 (at
http://www.openstreetmap.org/?mlat=41.890540mlon=-87.805101zoom=17)
no_u_turn with equal 'from' and 'to' way and via node is ignored

Looking at the rules for restrictions and the relation itself, I can't see
what the problem is.

https://wiki.openstreetmap.org/wiki/Relation:restriction

http://www.openstreetmap.org/relation/4630872

Does anybody know why this particular restriction is being ignored?

Thanks, Ben
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] question about ignored no_u_turn restriction

[Ben Konrath]

Hi Anor,

Thanks for the tip but it seems that your suggestion breaks the OSM rule of
manipulating the map for specific renderers (the renderer here being
mkgmap). If the Garmin format truly doesn't support the u-turn restriction
with the same to and from way at an intersection, we should come up with
another solution.

Ben

On Sun, Jul 5, 2015 at 4:01 PM, A. Carlos anorcar...@hotmail.com wrote:


  Ben

 There I draw two routes, one in each direction, since there is a false
 median, then with 2-way, it's easy for a restriction











 *___*

  *Anor  Co*
 *ncórdia SC *














 --
 Date: Sun, 5 Jul 2015 15:53:50 +0200
 From: b...@bagu.org
 To: mkgmap-dev@lists.mkgmap.org.uk
 Subject: Re: [mkgmap-dev] question about ignored no_u_turn restriction


 Hi Thorsten,

 Thanks for your reply. This type of restriction is probably a country
 specific thing. In Ontario Canada, you can make u-turns at intersections
 (regardless of the road is separation) if there is no sign indicating that
 you can't make the u-turn. Here's the information directly from the Ontario
 Ministry of Transportation:

 http://www.mto.gov.on.ca/english/dandv/driver/handbook/section2.6.11.shtml

 I realize that the link I sent previously is in the US but I suspect that
 it's the same policy there which is why the restriction is tagged like it
 is.

 Since the tagging seems to be valid, does the Garmin format support this
 type of restriction? If not then it's probably a good idea to indicate this
 in the warning message. Maybe the message should also be changed to an info
 message if there's no problem with the data. Does anybody have other
 insights?

 Thanks, Ben

 On Sun, Jul 5, 2015 at 2:47 PM, Thorsten Kukuk ku...@suse.de wrote:

 On Sun, Jul 05, Ben Konrath wrote:

  Does anybody know why this particular restriction is being ignored?

 Beside that this particular type of restrictions doesn't make
 any sense to me, I would guess the GARMIN format does not support it.

 If the to and from ways are the same, I have never seen a sign forbidding
 u-turns. Only, if you have two ways, structural seperated. But then I
 should tag the street that way and the restriction will not be ignored.

   Thorsten

 --
 Thorsten Kukuk, Senior Architect SLES  Common Code Base
 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
 GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB
 21284 (AG Nürnberg)
 ___
 mkgmap-dev mailing list
 mkgmap-dev@lists.mkgmap.org.uk
 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



 ___ mkgmap-dev mailing list
 mkgmap-dev@lists.mkgmap.org.uk
 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

 ___
 mkgmap-dev mailing list
 mkgmap-dev@lists.mkgmap.org.uk
 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] question reg. exits

[Thorsten Kukuk]

Hi Gerd,

On Wed, May 20, Gerd Petermann wrote:

 How ?
 What category / sub category is it?

Ah, you are looking at the menu only. It seems there is
no menu entry for it. Since the menu entries are hardcoded
in the GPS devices and MapSource, you cannot change that.
I don't think there exists some magic flags in the map which
changes the menu.

I used search for POI in the near and search for all POI.

  Thorsten

-- 
Thorsten Kukuk, Senior Architect SLES  Common Code Base
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 
(AG Nürnberg)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] question reg. exits

[Thorsten Kukuk]

On Wed, May 20, Thorsten Kukuk wrote:

 Only exit:to (my problem here is, if you look how motorway_junction
 is tagged, that I don't know how to get access to the exit_to/destination
 tags in the style file.

More concret with an example:

https://www.openstreetmap.org/node/268575608

This node does not have any information about the destination.
So we would need the corresponding tags from the way:
https://www.openstreetmap.org/way/24710254

This tags could be:
destination/exit_to (both are equal, exit_to is used in the US)
destination:ref
destination:lanes

  Thorsten

-- 
Thorsten Kukuk, Senior Architect SLES  Common Code Base
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 
(AG Nürnberg)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] question reg. exits

[GerdP]

Hi Thorsten,

okay, got the same results. The interesting point here is that the code 
fills lists in the LBL file, but I don't extra code that would write them
to the global index as we do with cities.

Anyway, too much work for me, 
I'll concentrate on the branch for now.

Gerd



Thorsten Kukuk wrote
 Hi Gerd,
 
 On Wed, May 20, Gerd Petermann wrote:
 
 How ?
 What category / sub category is it?
 
 Ah, you are looking at the menu only. It seems there is
 no menu entry for it. Since the menu entries are hardcoded
 in the GPS devices and MapSource, you cannot change that.
 I don't think there exists some magic flags in the map which
 changes the menu.
 
 I used search for POI in the near and search for all POI.
 
   Thorsten
 
 -- 
 Thorsten Kukuk, Senior Architect SLES  Common Code Base
 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
 GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB
 21284 (AG Nürnberg)
 ___
 mkgmap-dev mailing list

 mkgmap-dev@.org

 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





--
View this message in context: 
http://gis.19327.n5.nabble.com/question-reg-exits-tp5845107p5845255.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] question reg. exits

[Gerd Petermann]

Hi all,

I just noticed that mkgmap treats POI with
 0x2000 = type  0x2800
special.
It looks for the tags 
exit:to=*  and exit:facility=* to add extra information to
the POI.
This info is shown when you click on an exit in Basecamp, 
it shows the fields Name, Description, and Overnight Parking.

The source was added with r984 in 2009 and it seems nobody noticed that
these tags don't exist in OSM anymore (or maybe they were typos)?

Or maybe that were meant to be set in the style?

Gerd


 


  ___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] question reg. exits

[Thorsten Kukuk]

Hi,

On Tue, May 19, Gerd Petermann wrote:

 Hi all,
 
 I just noticed that mkgmap treats POI with
  0x2000 = type  0x2800
 special.
 It looks for the tags 
 exit:to=*  and exit:facility=* to add extra information to
 the POI.
 This info is shown when you click on an exit in Basecamp, 
 it shows the fields Name, Description, and Overnight Parking.
 
 The source was added with r984 in 2009 and it seems nobody noticed that
 these tags don't exist in OSM anymore (or maybe they were typos)?
 
 Or maybe that were meant to be set in the style?

http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q1/001287.html

exit:facility needs to be set by the style, exit:to looks like
a proposed OSM tag never introduced.
But I admit that I don't really understand the examples in that mail...

  Thorsten

-- 
Thorsten Kukuk, Senior Architect SLES  Common Code Base
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 
(AG Nürnberg)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question on Auto-Zoom

[Andrzej Popowski]

Hi Michael,

I don't know about outdoor devices, I disable autozoom on them.

In nuvi the idea is quite simple, it uses 3-4 ranges of speed and 
remembers zoom that you have set at that speed. So you can tune autozoom 
behavior.


--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev