Re: [mkgmap-dev] Poiisble bug with ~ and numbers

[Pinns UK]

Hi Gerd

Thanks again

.* did the trick !

Nick

A 'happy train spotter'


On 10/07/2020 08:48, Gerd Petermann wrote:

Hi Nick,

not sure if you need the ^, but .* instead of *. is the more important change.

Gerd


Von: mkgmap-dev  im Auftrag von Pinns UK 

Gesendet: Freitag, 10. Juli 2020 09:46
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Poiisble bug with ~ and numbers

Hi Gerd

Many thanks for coming back so soon !

Never realised I neede d

^1

Nick

On 10/07/2020 08:43, Gerd Petermann wrote:

Hi Nick,

'1*.' means 0 or more '1' at the beginning. You probably want something like 
'^1.*'  (string starting with 1 followed by 0 or more other characters)

Gerd


Von: mkgmap-dev  im Auftrag von Pinns UK 

Gesendet: Freitag, 10. Juli 2020 09:26
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Poiisble bug with ~ and numbers

Hi All

I'm trying to assign an icon to platform numbers in my TYP file - my
Fenix doesn't show highway:symbols

This works fine if platforms are labelled 1,2,3 etc

To avoid too many icons I want to reduce 1a,1b to 1  and 2a,2b to 2 etc
using

ref ~'1*.'  [0x etc]

ref ~'2*.' [0x etc]

This works for stations with number+letter platforms (ie Norwich)

However, where stations are just numbers without letters, all
platforms(ie 1,2,3,4) are labelled 1 depending on the order of my ref ~ ie

if ref ~'1*.' is the first line in my code all platforms are labbelled 1
 if ref ~'2*.' is the first line in my code a;; of them are labelled 2

It seems ~ may not work as expected with numbers , or my code is wrong.

Any ideas?

Nick


___
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] Poiisble bug with ~ and numbers

[Pinns UK]

Hi Gerd

Many thanks for coming back so soon !

Never realised I neede d

^1

Nick

On 10/07/2020 08:43, Gerd Petermann wrote:

Hi Nick,

'1*.' means 0 or more '1' at the beginning. You probably want something like 
'^1.*'  (string starting with 1 followed by 0 or more other characters)

Gerd


Von: mkgmap-dev  im Auftrag von Pinns UK 

Gesendet: Freitag, 10. Juli 2020 09:26
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Poiisble bug with ~ and numbers

Hi All

   I'm trying to assign an icon to platform numbers in my TYP file - my
Fenix doesn't show highway:symbols

This works fine if platforms are labelled 1,2,3 etc

To avoid too many icons I want to reduce 1a,1b to 1  and 2a,2b to 2 etc
using

ref ~'1*.'  [0x etc]

ref ~'2*.' [0x etc]

This works for stations with number+letter platforms (ie Norwich)

However, where stations are just numbers without letters, all
platforms(ie 1,2,3,4) are labelled 1 depending on the order of my ref ~ ie

if ref ~'1*.' is the first line in my code all platforms are labbelled 1
if ref ~'2*.' is the first line in my code a;; of them are labelled 2

It seems ~ may not work as expected with numbers , or my code is wrong.

Any ideas?

Nick


___
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] Poiisble bug with ~ and numbers

[Pinns UK]

Hi All

 I'm trying to assign an icon to platform numbers in my TYP file - my 
Fenix doesn't show highway:symbols


This works fine if platforms are labelled 1,2,3 etc

To avoid too many icons I want to reduce 1a,1b to 1  and 2a,2b to 2 etc 
using


ref ~'1*.'  [0x etc]

ref ~'2*.' [0x etc]

This works for stations with number+letter platforms (ie Norwich)

However, where stations are just numbers without letters, all 
platforms(ie 1,2,3,4) are labelled 1 depending on the order of my ref ~ ie


if ref ~'1*.' is the first line in my code all platforms are labbelled 1 
  if ref ~'2*.' is the first line in my code a;; of them are labelled 2


It seems ~ may not work as expected with numbers , or my code is wrong.

Any ideas?

Nick


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

Re: [mkgmap-dev] Routing problem on Garmin Oregon/edge with default style (and other styles)

[Pinns UK]

@ Joris

I have r4359

https://pinns.co.uk/osm/bts/mkgmap-r4359.zip

On 27/06/2020 11:54, Joris Bo wrote:


Hi

Is there a online repository of compiled mkgmap versions?

I found an answer form Gerd that ‘you can create one form svn, but I 
don’t have those skills.


I am looking for versions between

r4323 (29-10-2019)  still ok

r4386 (8-12-2019)    problem persist

@Felix Yes, I always used the most recent default style also with the 
older mkgmap versions for the tes.


Kind regards

Joris

*Van:* mkgmap-dev  *Namens 
*jan meisters

*Verzonden:* zaterdag 27 juni 2020 11:42
*Aan:* Development list for mkgmap 
*Onderwerp:* Re: [mkgmap-dev] Routing problem on Garmin Oregon/edge 
with default style (and other styles)


Tested on Oregon 450 without crash: runs until destination.

Map used is from 04/2020, created with mkgmap-r4479 using my own (pure 
cycle) style.


Therefore routing still set to bicycle (fastest / avoid unaved), but 
as well no crash with ATV.


Nevertheless, here Calle Castillo de Ponferrada isn`t pink while 
simulation, but Calle Castillo de Alarcón is.


Am 26.06.2020 um 14:39 schrieb Felix Hartmann
mailto:extremecar...@gmail.com>>:

https://www.openstreetmap.org/way/2786/history#map=15/40.4752/-3.9411


Trying to route along this route crashes the GPS device - not sure
what i going on here. In demo mode - just set location to:
https://www.openstreetmap.org/way/2786/history#map=18/40.48063/-3.94040

and route to:

https://www.openstreetmap.org/way/2786/history#map=19/40.46711/-3.94385


(Calle Castillo de Ponferrada)

 The route will first be normal pink, however as soon as it goes
onto the Calle Castillo de Alarcón

it will keep on routing - but the pink colour is gone. Then after
maybe half of the road it stops routing and asks to recalculate
(which will be in a loop if you click yes).

map produced with.

start /low /b /wait java -jar -XX:+AggressiveHeap
-XX:StringTableSize=103 -Xms15000M -Xmx29000M
C:\openmtbmap\mkgmap.jar --max-jobs=8 --order-by-decreasing-area
--code-page=1252 --add-boundary-nodes-at-admin-boundaries  --nsis
--index --levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18"
--overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12"
--add-pois-to-areas

--pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance
--reduce-point-density=3.4 --reduce-point-density-polygon=6
--add-boundary-nodes-at-admin-boundaries=2
--poi-excl-index=0x6405,0x4316,0x2f00 --cycle-map
--check-roundabout-flares --ignore-fixme-values --housenumbers
--road-name-config=C:\openmtbmap\openmtbmap_svn\roadNameConfig.txt
--split-name-index --link-pois-to-ways --ignore-turn-restrictions
--polygon-size-limits="24:16, 23:14, 22:12, 21:11, 20:10, 19:9,
18:8, 17:7, 16:6, 15:5, 14:4, 13:3, 12:2, 11:0, 10:0"
--description=omtb_es --show-profiles=1
 --location-autofill=bounds,is_in,nearest  --route
--country-abbr=es --country-name=spain --mapname=6413
--family-id=6413 --product-id=1
--series-name=omtb_spain_26.06.2020
--family-name=mtb_es_26.06.2020 --tdbfile
--overview-mapname=mapsetc --keep-going
--area-name="spain_26.06.2020_omtb"
D:\openmtbmap\maps\64130028.osm.pbf 1>NUL 2>NUL

Routing setup on device as:

ATV/Off Road Driving

Minimize Distance

No Avoidances

but I think this does not matter.

I have uploaded the broken tile/map here:

https://openmtbmap.org/maps.7z

the osm.pbf for that tile is:

https://openmtbmap.org/64130028.osm.pbf

I have no real clue what is happening here. If you set
highway=residential from road_class=0 / road_speed=2 to say 1 / 1
crash is even earlier.

I cannot find anything special looking at the road with
GPSMapedit. Garmin Edge devices supposedly crash too - not sure
about other devices.

Felix

___
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] Routing problem on Garmin Oregon/edge with default style (and other styles)

[Pinns UK]

One suggestion perhaps is to save the area as a mp and use cgpsmapper to 
create the map?



On 26/06/2020 16:49, Felix Hartmann wrote:

It's fine in Basecamp and mapsource.

On Fri, 26 Jun 2020, 18:40 Ticker Berkin > wrote:


Hi Joris & Felix

Can you test this in both Basecamp and Mapsource. I have found problem
areas recently where Mapsource and my old eTrex have no routing
problems but Basecamp does.

Ticker


___
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] PolishMapDataSource.checkType()) invalid type 0x5400 for POLYGON

[Pinns UK]

For your information

0x54 appears as transparent in a TYP file used in

the latest Garmin Cycle Map EU 2020

r

Nick

On 22/05/2020 11:22, Vadim wrote:

Hi Thomas!

Yes, I am sure. I am using cGPSmapper v0100d.
(
https://web.archive.org/web/20160414230419/http://www.cgpsmapper.com/download2/FreeSetup.exe
).
Works well with MP-files.
But this version of cGPSmapper has another bug: it does not understand the
FULL record of non marine types (for example, 0x02800) in TYP files. There
were no errors during compilation, just the wrong TYP file was generated
with a bad section [_drowOrder].

Example:
(.txt source)
[_drawOrder]
Type=0x02800,1
Type=0x02900,2
Type=0x02A00,3
Type=0x02B00,3
Type=0x02C00,4
Type=0x02D00,5
Type=0x02E00,6
Type=0x02F00,6
Type=0x03000,7
Type=0x03100,8
[end]

(compilation result of cGPSmapper):
[_drawOrder]
Type=0x000,2
Type=0x000,3
Type=0x000,4
Type=0x000,5
Type=0x000,6
Type=0x000,7
Type=0x000,8
Type=0x000,9
[End]

The same results with Type=0x2800,1 and Type=0x002800,1 :(

Even GpsMapEdit does not work correctly with a full/long TYPE record
(Type=0x02800 or Type=0x10f00) in polish MP-files.

Incidentally, the equivalence of the full record (Type=0x10f00) and split
(Type=0f/Subtype=00/Marine=Y) described in the "cGPSmapper manual" (page 19)

PS: MkGmap works fine with Type=0x02800,1 in TYP-fifes.


22 may 2020, 8:13 +03:00 от Thomas Morgenstern :
Are you sure, that cgpsmapper works with 0x54 ?. The installationpacket,
comes with cgpsmapper V99, includes file RGNtyp.txt. This listed in
section RGN 80 as highest Typ 0x53. After that comes the Extended types,
beginning with 0x01010 ...Type 0x54 is definitivly not listed in the
original cgpsmapper-list .
   thomas



--
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] [Fwd: Re: Suggestions for roadNameConfig.txt]

[Pinns UK]

Hi Ticker

I agree that at times the effect is strange, particularly with short 
road names


I have instead created my own list and only apply the abbreviation if 
the road name is over a certain length.


So Oak street does not become Oak St which looks very odd

Unfortunately I could not find a 'len' command to establish the length 
of a string - is there one?


Instead I have to check if a road name has a character at a certain 
position in the string.


r

Nick

On 16/04/2020 12:09, Ticker Berkin wrote:

Hi Gerd

I did think about this, but --road-names-config is optional and behaves
as the documentation suggests and this patch includes a reasonably
complete list of suffixes for the UK and useful comments.

I tried it on my device and didn't like the effect and so don't use it,
Others might like it.

I've fixed Boulevard.

Ticker

On Thu, 2020-04-16 at 09:04 +, Gerd Petermann wrote:

Hi Ticker,

did you consider disabling this feature for the UK? It looks wrong to
me to have such a long list of rather meaningful names.

BTW: Boulivard is probably a typo?

Gerd


Von: mkgmap-dev  im Auftrag
von Ticker Berkin 
Gesendet: Donnerstag, 16. April 2020 10:35
An: mkgmap development
Betreff: [mkgmap-dev] [Fwd: Re:  Suggestions for roadNameConfig.txt]

Hi Gerd

Could you consider this change to roadNameConfig.txt for GBR

I've attached an updated version based current trunk.o1

Thank you
Ticker

 Forwarded Message 
From: Ticker Berkin 
Reply-to: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Suggestions for roadNameConfig.txt
Date: Thu, 23 Jan 2020 16:56:17 +

Hi Gerd

I've just been going through some old mails/patches.

I think the updated contents of roadNameConfig.txt is correct and
better than the previous version.

The fact that it doesn't work consistently across devices and, on
some,
is misleading shouldn't stop the file being available as an example
in
the distribution.

The user has the choice about how to use it and it contains some
comments and a link relating to these problems.

I've attached an updated patch with UTF-8 encoding markers, a
different
section for UK road names and improved some comments.

This file has always been read by mkgmap as UTF-8. The function of
the
markers is to make editors aware of this; it contains characters
outside the 7-bit ascii range.

Ticker

On Mon, 2019-12-16 at 11:30 +, Gerd Petermann wrote:

Hi Ticker,

reg. search: You are probably right, address search works very
different on the Garmin devices. On the Oregon, I have several
dialogs, first to chose country, next to chose city or "all", next
to
type house number, last one asking for road name. In this dialog
there is no autocompletion, I just have to type characters.
Sometimes
the device switches automatically to a result list while I am
typing,
sometimes it doesn't. When I press OK I get a list of matching
roads.
So, for the Oregon it works fine. Maybe it doesn't for those
devices
with auto-completion. Cannot test this right now. I tried it once
with a Nüvi and it seemed to work well, but I don't own one.

Reg. combination of   --road-name-config and --split-name-index:
Yes,
this gives confusing results. Not sure if it worked better in the
past.
I tried with Essex extract:
java -jar d:\mkgmap\dist\mkgmap.jar --bounds=f:\osm\bounds.zip -
-gmapi --net --index  --road-name
-config=d:\mkgmap\resources\roadNameConfig.txt --gmapsupp --split
-name-index f:\dwnload\temp\essex-latest.osm.pbf


According to Mapsource a search for "Mace" without giving a city
name
should list "John Mace Road", "Mace Avenue", "Mace Court", and
"Mace
Walk", maybe in a different order.
Without your patch I  get a list showing "Mace Road", "Mace
Avenue",
and "Mace Walk", so "Mace Court" is missing and when I select "Mace
Road" the device shows the "John Mace Road".
With your patch this gets worse: The list shows only "Mace Road",
when I select that entry I get a new list containing
",Thurrock","Braintree,Essex","Chelmsford,Essex", and "Colchester,
Essex". Each of them points to just one of the expected roads.

Results look much better when I specify a city name.
Result also looks very different without the --split-name-option.
I have to do more tests, I think it worked better in the past.
Maybe
sorting is broken.

Gerd

___
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] Resolutions...

[Pinns UK]

Hi Gerd

Thanks for your reply

Yes, I noticed that level 2-4 is allowed as well.

Just going back  to an earlier problem,

using the default levels

levels = 0:24, 1:22, 2:20, 3:18

overview-levels = 4:17, 5:16, 6:15, 7:14, 8:12

a) I'm still a bit unclear about what happens if a resolution

a) slots in between two levels , ie resolution 19 will between levels 2 
and 3


Will if always get rounded down or does it depend on the nearest level

ie

levels = 0:24, 1:22, 2:20, 3:15

resolution 17 will be plotted as level 3 ?

resolution 19 will be plotted as level 2 ?

B) the default style's lowest resolution is 10 in Polygons

and yet its is lower than level 8 in which case its rounded up to level 8

or does it automatically get assgined a new undeclared level 9?

Just realised 4b must get hard coded to the lowest level (0 ?)

Regards

Nick


On 13/03/2020 13:43, Gerd Petermann wrote:

Hi Nick,
a)
natural=wood [0x50 level 2-4 ]
is allowed.
b)
a level larger than specified in levels gives an error message. For your 
example I'd expect
Error in style: Error: Level number too large, max=5
Not sure if that makes sense. For your example I would have expected that
area_city=*   [0x03 level 6 continue]
is treated like
area_city=*   [0x03 level 0-5 continue]

Gerd


Von: Pinns UK 
Gesendet: Mittwoch, 11. März 2020 09:01
An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: AW: [mkgmap-dev] Resolutions...

Hi Gerd

Thanks that's clear.

I'm just experimenting with the default style rather than my own which
is entirely geared towards hiking.

I can see there is some advantage using levels:

a)  you get a clearer picture of which elements get plotted at which
zoom level

b) you only have to change the resolutions in the options file to test
the zooming effects.

btw

a) Can you use the '--' in levels?

ie

natural=wood [0x50 level 2-4 ]

b) I have seen an options file which contains levels 0 --> 5

However in the style itself there is mention of a level 6 eventhough
it's not defined in tghe options file

ie

area_city=*   [0x03 level 6 continue]

Is that 'allowed' ?

Regards

Nick

On 11/03/2020 06:56, Gerd Petermann wrote:

Hi Nick,

The behaviour changed in the past, but I think if the style produces an object 
for a max resolution X and no level covers exactly this resolution the max 
resolution is decremented to the next lower value covered by a level. If there 
is no such level the object is not added to the map.

natural=coastline [0x15 resolution 12]
is equal to
natural=coastline [0x15 resolution 12-24]

Not sure what you mean with
"I remember in the past it was said the levels are better than resolutions"
Do you suggest to change the default style to use level instead of resolution?

Gerd


Von: mkgmap-dev  im Auftrag von Pinns UK 

Gesendet: Dienstag, 10. März 2020 18:30
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Resolutions...

Hi Gerd

Just to be a nuisance:

If there is no level beyond level 3 in the default style, ie 4,12

then all resolutions <18  contained in the default style (and there are
quite a few!)  only get plotted at level 3?

ie the lowest lines are a boundary  anda coastline , both at res 12

Do they only get plotted at level 3 , ie resolution 3

I remember in the past it was said the levels are better than resolutions

R

Nick

On 10/03/2020 13:46, Pinns UK wrote:

Thanks Gerd

r

Nick

On 10/03/2020 12:51, Gerd Petermann wrote:

Hi Nick,

the meaning of these statements depends on the levels option. With
the options in default style
levels = 0:24, 1:22, 2:20, 3:18
the resolution 23 and 22 are at level 1, so resolution  23 is
actually rounded down to 22.

Gerd


Von: mkgmap-dev  im Auftrag
von nwillink 
Gesendet: Dienstag, 10. März 2020 13:39
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Resolutions...

Hi

Can anyone tell me what exactly the '-' in after resolutions means.

I plotted a church resolution 21-23  only to find it does not include
resolution 23.

Somewhere I read that only the resolutions between the numbers are
plotted.

If that is the case what does 23-24 mean ? What resolution is there
between
23 and 24

What happens with resolution 23-23 ?

Does 23-24 mean only level 23
Is 24-23 different from 23-24?

The manual does not seem to tackle this issue.

btw

Have noticed that Basecamp/Mapsource only plots 0x2c poi range at
level 24

So the following might never occur in some GPS devices is except at
resolution 24

0x2c02 [resolution 21 ]

This seems to affect :

viewpoints,churches,castles, schools,amusement parks etc

Regards

Nick





--
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/lis

Re: [mkgmap-dev] Resolutions...

[Pinns UK]

Hi Gerd

Thanks that's clear.

I'm just experimenting with the default style rather than my own which 
is entirely geared towards hiking.


I can see there is some advantage using levels:

a)  you get a clearer picture of which elements get plotted at which 
zoom level


b) you only have to change the resolutions in the options file to test 
the zooming effects.


btw

a) Can you use the '--' in levels?

ie

natural=wood [0x50 level 2-4 ]

b) I have seen an options file which contains levels 0 --> 5

However in the style itself there is mention of a level 6 eventhough 
it's not defined in tghe options file


ie

area_city=*   [0x03 level 6 continue]

Is that 'allowed' ?

Regards

Nick

On 11/03/2020 06:56, Gerd Petermann wrote:

Hi Nick,

The behaviour changed in the past, but I think if the style produces an object 
for a max resolution X and no level covers exactly this resolution the max 
resolution is decremented to the next lower value covered by a level. If there 
is no such level the object is not added to the map.

natural=coastline [0x15 resolution 12]
is equal to
natural=coastline [0x15 resolution 12-24]

Not sure what you mean with
"I remember in the past it was said the levels are better than resolutions"
Do you suggest to change the default style to use level instead of resolution?

Gerd


Von: mkgmap-dev  im Auftrag von Pinns UK 

Gesendet: Dienstag, 10. März 2020 18:30
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Resolutions...

Hi Gerd

Just to be a nuisance:

If there is no level beyond level 3 in the default style, ie 4,12

then all resolutions <18  contained in the default style (and there are
quite a few!)  only get plotted at level 3?

ie the lowest lines are a boundary  anda coastline , both at res 12

Do they only get plotted at level 3 , ie resolution 3

I remember in the past it was said the levels are better than resolutions

R

Nick

On 10/03/2020 13:46, Pinns UK wrote:

Thanks Gerd

r

Nick

On 10/03/2020 12:51, Gerd Petermann wrote:

Hi Nick,

the meaning of these statements depends on the levels option. With
the options in default style
levels = 0:24, 1:22, 2:20, 3:18
the resolution 23 and 22 are at level 1, so resolution  23 is
actually rounded down to 22.

Gerd


Von: mkgmap-dev  im Auftrag
von nwillink 
Gesendet: Dienstag, 10. März 2020 13:39
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Resolutions...

Hi

Can anyone tell me what exactly the '-' in after resolutions means.

I plotted a church resolution 21-23  only to find it does not include
resolution 23.

Somewhere I read that only the resolutions between the numbers are
plotted.

If that is the case what does 23-24 mean ? What resolution is there
between
23 and 24

What happens with resolution 23-23 ?

Does 23-24 mean only level 23
Is 24-23 different from 23-24?

The manual does not seem to tackle this issue.

btw

Have noticed that Basecamp/Mapsource only plots 0x2c poi range at
level 24

So the following might never occur in some GPS devices is except at
resolution 24

0x2c02 [resolution 21 ]

This seems to affect :

viewpoints,churches,castles, schools,amusement parks etc

Regards

Nick





--
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 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] Resolutions...

[Pinns UK]

Hi Jan

Thanks for that; hadn't realised it applies to the 29 -32 range

Yes, have also resorted to double entries but am using extended type 
number 0x12c02 with a continue


Nick

On 10/03/2020 13:31, jan meisters wrote:

Hi Nick,

pois from 0x2900 to 0x311f are only visible on resolution „24+".
Means you have to „overzoom“ deeper into resolution 24 to see them.

This behaviour is not related to mkgmap, it seems to be a limitiation by Garmin 
to avoid cluttering of maps with these pois, as they contain most indexed items 
like shops, restaurants, etc. Only exception are airports on 0x2f04.

To have these pois appearing earlier I haven´t found another solution yet than to 
"double“ wanted pois.
In your example:
church=* [0x3202 resolution 23 continue]
church=* [0x2c02 resolution 24]

Disadvantage: Basecamp (4.6.3/Mac) not only shows the pois on wanted 
resolution, but also lists these doubles in search („All Pois“ only)
On device (at least my Oregon450) the range 0x3200-0x330f doesn´t appear in 
searches, but is visible as expected.

Jan



Am 10.03.2020 um 13:39 schrieb nwillink :

Hi

Can anyone tell me what exactly the '-' in after resolutions means.

I plotted a church resolution 21-23  only to find it does not include
resolution 23.

Somewhere I read that only the resolutions between the numbers are plotted.

If that is the case what does 23-24 mean ? What resolution is there between
23 and 24

What happens with resolution 23-23 ?

Does 23-24 mean only level 23
Is 24-23 different from 23-24?

The manual does not seem to tackle this issue.

btw

Have noticed that Basecamp/Mapsource only plots 0x2c poi range at level 24

So the following might never occur in some GPS devices is except at
resolution 24

0x2c02 [resolution 21 ]

This seems to affect :

viewpoints,churches,castles, schools,amusement parks etc

Regards

Nick





--
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 mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Resolutions...

[Pinns UK]

Thanks Gerd

r

Nick

On 10/03/2020 12:51, Gerd Petermann wrote:

Hi Nick,

the meaning of these statements depends on the levels option. With the options 
in default style
levels = 0:24, 1:22, 2:20, 3:18
the resolution 23 and 22 are at level 1, so resolution  23 is actually rounded 
down to 22.

Gerd


Von: mkgmap-dev  im Auftrag von nwillink 

Gesendet: Dienstag, 10. März 2020 13:39
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Resolutions...

Hi

Can anyone tell me what exactly the '-' in after resolutions means.

I plotted a church resolution 21-23  only to find it does not include
resolution 23.

Somewhere I read that only the resolutions between the numbers are plotted.

If that is the case what does 23-24 mean ? What resolution is there between
23 and 24

What happens with resolution 23-23 ?

Does 23-24 mean only level 23
Is 24-23 different from 23-24?

The manual does not seem to tackle this issue.

btw

Have noticed that Basecamp/Mapsource only plots 0x2c poi range at level 24

So the following might never occur in some GPS devices is except at
resolution 24

0x2c02 [resolution 21 ]

This seems to affect :

viewpoints,churches,castles, schools,amusement parks etc

Regards

Nick





--
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 mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] is_in example?

[Pinns UK]

Hi Ticker

Thanks

I used mkgmap-r4462

Nick

On 05/03/2020 18:36, Ticker Berkin wrote:

Hi Nick

It hasn't been merged into the main trunk yet. You need to download the
latest Branch build: mkgmap-is-in-r.zip

Ticker

On Thu, 2020-03-05 at 11:03 -0700, nwillink wrote:

Hi

Can anyone tell me how to use the revised is_in function as I'm just
getting
the following errors.



Error in style: Error: (points:521): Expecting ) instead saw landuse

I can't seem to find any practical  examples :(


With an older version this works:

barrier=gate &  is_in(landuse,residential,all)=true  {delete barrier}

I tried

barrier=gate &  is_in(landuse,residential,in_or_on)=true  {delete
barrier}

But again , I get the same error.

Perhaps , the function still hush-hush ;)

Regards

Nick




--
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 mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Tagging restaurants and categories

[Pinns UK]

Multiple tags seem to occur more frequently in OSM , particularly in 
polygons and to a lesser extent in lines. Luxembourg is a good example.


I've had to adapt my style to ensure woods were plotted when combined 
with another tag.


ie

*Polygons*

combining natural , landuse , leisure etc

natural=wood & landuse=grass

leisure & natural / landuse

leisure=nature_reserve and landuse=forest

*Lines*

waterway=stream & boundary=administrative

I'm not sure how the default style deals with this  and perhaps it 
doesn't matter.


regards

Nick

On 03/03/2020 08:12, Ticker Berkin wrote:

Hi all

It relatively easy for a style to generate multiple POI for the same
point, in this case one "Fast Food" and one "Bagel/Donut".

The default style doesn't do this, but it makes a choice about which is
shown in this and similar cases, carefully commented to show how to get
the other:

# Have the following 2 lines here rather than after cuisine=... so
that, for amenity=fast_food, cuisine is ignored
amenity=fast_food & cuisine=* {add name='${cuisine|subst:"_=> "}'}
 [0x2a07 resolution 24]
amenity=fast_food [0x2a07 resolution 24]

...

cuisine=bagel | cuisine=donut
 [0x2a0d resolution 24]

...

Have the following 2 lines here rather than before cuisine=... so that,
for amenity=fast_food, cuisine is respected
#amenity=fast_food & cuisine=* {add name='${cuisine|subst:"_=> "}'}
 [0x2a07 resolution 24]
#amenity=fast_food [0x2a07 resolution 24]

Ticker


___
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] errors in typ file

[Pinns UK]

Hi Arndt

I suspect it's

FontStyle=NoLabel (invisible)

which should be

FontStyle=NoLabel

Regards

Nick

On 15/02/2020 07:44, Arndt Röhrig wrote:
FontStyle=NoLabel (invisible) 

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

Re: [mkgmap-dev] Garmin Lines Visibility

[Pinns UK]

Personally I have not come across line types > 130 although I have seen 
135 as a poi in a city navigator map


On 04/02/2020 13:18, Gerd Petermann wrote:

Hi Nick,

not sure about the limit of extended types. 0x1f for the lowest byte, but 
mkgmap doesn't seem to limit the higher byte. So maybe 1ff1f.
I think I'll add code to perform the same type checks for *.mp files as for 
style files.

Gerd


Von: mkgmap-dev  im Auftrag von Pinns UK 

Gesendet: Dienstag, 4. Februar 2020 11:48
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Garmin Lines Visibility

Hi Gerd

Yes, I used a mp file - no error message was shown

I presume extended line types have a maximum of 13F1f?

Regards

Nick

On 04/02/2020 10:44, Gerd Petermann wrote:

Hi Nick,

yes, 0x3f is also coded as limit in mkgmap. It complains when you use a higher 
line type like 0x57 in the style:
Error: invalid type 0x57 for POLYLINE in style file lines, line 121

Maybe it doesn't complain with polish (*.mp) input?

Gerd


Von: mkgmap-dev  im Auftrag von nwillink 

Gesendet: Dienstag, 4. Februar 2020 11:29
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Garmin Lines Visibility

Hi All

Following from Jorics' response to Gerd  have done some more research
regarding lines on Basecamp:

*Lines with non extended types*

it seems that the highest line type is 0x3F

Strangely Mapsource shows a repeat of lines 0 to 3F starting from 0x40
This looks like  mkgmap allows such types but Garmin seems to set a 'flag'
of some kind and regards 0x40 as 0x0 etc

Not Visible : 0x17 , 0x 2c , 0x30 - 0x3F

Not customisable Labels: 0x20 - 0x22

*Extended Lines*

Not Visible : 0x10200 - 102FF ,
1080e ,
0812 - 1081f,
   10b05-10b1f ,
  12e00 -anything higher



No Labels : 0x10906 - 1091f , 10b02-10b04

<http://gis.19327.n8.nabble.com/file/t339487/lines.jpg>




--
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 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] Garmin Lines Visibility

[Pinns UK]

Hi Gerd

Yes, I used a mp file - no error message was shown

I presume extended line types have a maximum of 13F1f?

Regards

Nick

On 04/02/2020 10:44, Gerd Petermann wrote:

Hi Nick,

yes, 0x3f is also coded as limit in mkgmap. It complains when you use a higher 
line type like 0x57 in the style:
Error: invalid type 0x57 for POLYLINE in style file lines, line 121

Maybe it doesn't complain with polish (*.mp) input?

Gerd


Von: mkgmap-dev  im Auftrag von nwillink 

Gesendet: Dienstag, 4. Februar 2020 11:29
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Garmin Lines Visibility

Hi All

Following from Jorics' response to Gerd  have done some more research
regarding lines on Basecamp:

*Lines with non extended types*

it seems that the highest line type is 0x3F

Strangely Mapsource shows a repeat of lines 0 to 3F starting from 0x40
This looks like  mkgmap allows such types but Garmin seems to set a 'flag'
of some kind and regards 0x40 as 0x0 etc

Not Visible : 0x17 , 0x 2c , 0x30 - 0x3F

Not customisable Labels: 0x20 - 0x22

*Extended Lines*

Not Visible : 0x10200 - 102FF ,
   1080e ,
   0812 - 1081f,
  10b05-10b1f ,
 12e00 -anything higher



No Labels : 0x10906 - 1091f , 10b02-10b04






--
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 mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mapnik typ file and barrier=wall

[Pinns UK]

Hi Gerd

Yes looks like it and it seems for Mapsource as well

Nick

On 02/02/2020 08:51, Gerd Petermann wrote:

Hi TYP experts,

it seems that line type 0x17 (barrier=wall) is not visible in Basecamp?

Gerd


___
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] Branch is_in ready for a first test

[Pinns UK]

Hi Gerd

Yes I did

It must have defaulted to 'any'

Nick

On 09/01/2020 14:58, Gerd Petermann wrote:

Hi Nick,

did you really use some? The code expects either "any" or "all", but doesn't 
yet check this.

Gerd

________
Von: Pinns UK 
Gesendet: Donnerstag, 9. Januar 2020 15:55
An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: AW: AW: AW: AW: [mkgmap-dev] Branch is_in ready for a first test

Hi Gerd

I had to replace 'all' with 'some'  as it very cleverly picked out some
small stretches of stream uniquely confined to a wood but it looked odd
just to highlight these small waterways.

'some' doesn't do a bad job !

Nick

On 09/01/2020 14:30, Gerd Petermann wrote:

Hi Nick,

river in wood polygon is probably a "good" worse case scenario for performance 
tests ;-)
Don't know how it is today, but a few years ago Japan was full of very complex 
wood MP (> 30.000 nodes) and long waterways...
I have no idea yet how that will perform...

Gerd

________
Von: Pinns UK 
Gesendet: Donnerstag, 9. Januar 2020 15:24
An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: AW: AW: AW: [mkgmap-dev] Branch is_in ready for a first test

Hi Gerd

Yes indeed, and also make streams etc  lighter, so it opens up a host of
new possibilities.

Many thanks again for all your ( and Ticker's) hard work!

Nick

On 09/01/2020 14:21, Gerd Petermann wrote:

Hi Nick,

thanks for the quick feedback :)

Interesting use case. Did not even think about this. Means you create overlay 
lines with different types for the routable way?

Gerd

________
Von: Pinns UK 
Gesendet: Donnerstag, 9. Januar 2020 15:07
An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: AW: AW: [mkgmap-dev] Branch is_in ready for a first test

Hi Gerd

It works a treat !

Am using it with natural=wood/scrub which now enables me to make the
colour of footpaths lighter and easier to see on a gps

r

Nick

On 09/01/2020 13:57, Gerd Petermann wrote:

Hi Nick,

yes, no extra option needed.

Gerd

________
Von: Pinns UK 
Gesendet: Donnerstag, 9. Januar 2020 14:56
An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: AW: [mkgmap-dev] Branch is_in ready for a first test

Thanks Gerd

That works

So no extra --is-in  options required?

r

Nick

On 09/01/2020 13:53, Gerd Petermann wrote:

highway=* & bicycle!=* & is_in(landuse,cemetery,all)=true {add bicycle=dismount}

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

Re: [mkgmap-dev] Branch is_in ready for a first test

[Pinns UK]

Hi Gerd

I had to replace 'all' with 'some'  as it very cleverly picked out some 
small stretches of stream uniquely confined to a wood but it looked odd 
just to highlight these small waterways.


'some' doesn't do a bad job !

Nick

On 09/01/2020 14:30, Gerd Petermann wrote:

Hi Nick,

river in wood polygon is probably a "good" worse case scenario for performance 
tests ;-)
Don't know how it is today, but a few years ago Japan was full of very complex 
wood MP (> 30.000 nodes) and long waterways...
I have no idea yet how that will perform...

Gerd

____
Von: Pinns UK 
Gesendet: Donnerstag, 9. Januar 2020 15:24
An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: AW: AW: AW: [mkgmap-dev] Branch is_in ready for a first test

Hi Gerd

Yes indeed, and also make streams etc  lighter, so it opens up a host of
new possibilities.

Many thanks again for all your ( and Ticker's) hard work!

Nick

On 09/01/2020 14:21, Gerd Petermann wrote:

Hi Nick,

thanks for the quick feedback :)

Interesting use case. Did not even think about this. Means you create overlay 
lines with different types for the routable way?

Gerd

____
Von: Pinns UK 
Gesendet: Donnerstag, 9. Januar 2020 15:07
An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: AW: AW: [mkgmap-dev] Branch is_in ready for a first test

Hi Gerd

It works a treat !

Am using it with natural=wood/scrub which now enables me to make the
colour of footpaths lighter and easier to see on a gps

r

Nick

On 09/01/2020 13:57, Gerd Petermann wrote:

Hi Nick,

yes, no extra option needed.

Gerd

____
Von: Pinns UK 
Gesendet: Donnerstag, 9. Januar 2020 14:56
An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: AW: [mkgmap-dev] Branch is_in ready for a first test

Thanks Gerd

That works

So no extra --is-in  options required?

r

Nick

On 09/01/2020 13:53, Gerd Petermann wrote:

highway=* & bicycle!=* & is_in(landuse,cemetery,all)=true {add bicycle=dismount}

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

Re: [mkgmap-dev] Branch is_in ready for a first test

[Pinns UK]

Hi Gerd

Yes indeed, and also make streams etc  lighter, so it opens up a host of 
new possibilities.


Many thanks again for all your ( and Ticker's) hard work!

Nick

On 09/01/2020 14:21, Gerd Petermann wrote:

Hi Nick,

thanks for the quick feedback :)

Interesting use case. Did not even think about this. Means you create overlay 
lines with different types for the routable way?

Gerd


Von: Pinns UK 
Gesendet: Donnerstag, 9. Januar 2020 15:07
An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: AW: AW: [mkgmap-dev] Branch is_in ready for a first test

Hi Gerd

It works a treat !

Am using it with natural=wood/scrub which now enables me to make the
colour of footpaths lighter and easier to see on a gps

r

Nick

On 09/01/2020 13:57, Gerd Petermann wrote:

Hi Nick,

yes, no extra option needed.

Gerd


Von: Pinns UK 
Gesendet: Donnerstag, 9. Januar 2020 14:56
An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: AW: [mkgmap-dev] Branch is_in ready for a first test

Thanks Gerd

That works

So no extra --is-in  options required?

r

Nick

On 09/01/2020 13:53, Gerd Petermann wrote:

highway=* & bicycle!=* & is_in(landuse,cemetery,all)=true {add bicycle=dismount}

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

Re: [mkgmap-dev] Branch is_in ready for a first test

[Pinns UK]

Thanks Gerd

That works

So no extra --is-in  options required?

r

Nick

On 09/01/2020 13:53, Gerd Petermann wrote:

highway=* & bicycle!=* & is_in(landuse,cemetery,all)=true {add bicycle=dismount}

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

Re: [mkgmap-dev] Commit r4397: implement and document new option --is-in-landuse=value[, value...]

[Pinns UK]

Hi Gerd

That would be very useful

r

Nick

On 17/12/2019 11:15, Gerd Petermann wrote:

Hi Nick,

OK, I already expected this when I asked if landuse is enough...
I'll add code to support all polygons and see how to document it. I guess it 
should be no problem when I revert the changes in r4397.

Gerd


Von: mkgmap-dev  im Auftrag von Pinns UK 

Gesendet: Dienstag, 17. Dezember 2019 11:53
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Commit r4397: implement and document new option 
--is-in-landuse=value[, value...]

Hi Gerd,

Oops, I forgot to look at the documentation!

Personally , I think it is such a useful option which will open up a host of 
new possibilities when/if you are able to extend this to include all polygons.

Again, thanks for all your hard work!

Nick

On 17/12/2019 09:42, Pinns UK wrote:

Hi Gerd

I've been able to change footpaths on (some?)  amenity graveyards to paths by 
just setting the lu:cemetery to yes

I first tried :

amenity=grave_yard {set landuse=cemetry;echotags"change2landuse"}

   mkgmap:lu:cemetery=*  & highway=footway  {set highway=path}


however this did not work , ie footpaths on cemeteries didn't change to paths  
and the echotags didn't show any :lu:cemetery

then I tried

  amenity=grave_yard {set mkgmap:lu:cemetery=yes}

   mkgmap:lu:cemetery=*  & highway=footway  {set highway=path}

  This seems to work for some (?)  graveyards (Haven't checked this on 2 
graveyards only)

My question is ,does mkgmap check if highways cross a polygon   as soon as it 
parses mkgmap:lu:cemetery=*  & highway=footway

or are the checks done before 'Lines' are parsed?

If the user can set the value then what ,if any ,are the effects - ie

natural=wood { set mkgmap:lu:cemetery=yes}

  If this works then Arndt seems to have a point?

r

Nick


Does mkgmap check if graveyard

On 15/12/2019 12:28, Arndt Röhrig wrote:
is-in-landuse, nice function!

with this new option i set acces=no for bicycles when the way is within a cemetary. 
(& no tag say, that bicycle is ok)

There are still a few polys where that could be used. amenity=grave_yard, 
amenity=hospital, leisure=pitch 

maybe its better to name the option is-in-polygone:polygone=value

Arndt



svn commit < s...@mkgmap.org.uk<mailto:s...@mkgmap.org.uk>> hat am 15. Dezember 
2019 um 10:05 geschrieben:


Version mkgmap-r4397 was committed by gerd on Sun, 15 Dec 2019

implement and document new option --is-in-landuse=value[,value...]
- svn rename ResidentialHook.java to LanduseHook.java
- remove support for undocumented option --residential-hook=false
- warn if style uses mkgmap:residential which was replaced by 
mkgmap:lu:residential


http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4397
___
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
On 15/12/2019 09:05, svn commit wrote:

Version mkgmap-r4397 was committed by gerd on Sun, 15 Dec 2019

implement and document new option --is-in-landuse=value[,value...]
- svn rename ResidentialHook.java to LanduseHook.java
- remove support for undocumented option --residential-hook=false
- warn if style uses mkgmap:residential which was replaced by 
mkgmap:lu:residential


http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4397
___
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<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] Commit r4397: implement and document new option --is-in-landuse=value[, value...]

[Pinns UK]

Hi Gerd,

Oops, I forgot to look at the documentation!

Personally , I think it is such a useful option which will open up a 
host of new possibilities when/if you are able to extend this to include 
all polygons.


Again, thanks for all your hard work!

Nick

On 17/12/2019 09:42, Pinns UK wrote:


Hi Gerd

I've been able to change footpaths on (some?)  amenity graveyards to 
paths by just setting the lu:cemetery to yes


I first tried :

amenity=grave_yard {set landuse=cemetry;echotags"change2landuse"}

  mkgmap:lu:cemetery=*  & highway=footway  {set highway=path}


however this did not work , ie footpaths on cemeteries didn't change 
to paths  and the echotags didn't show any :lu:cemetery


then I tried

 amenity=grave_yard {set mkgmap:lu:cemetery=yes}

  mkgmap:lu:cemetery=*  & highway=footway  {set highway=path}

 This seems to work for some (?)  graveyards (Haven't checked this on 
2 graveyards only)


My question is ,does mkgmap check if highways cross a polygon as soon 
as it parses mkgmap:lu:cemetery=*  & highway=footway


or are the checks done before 'Lines' are parsed?

If the user can set the value then what ,if any ,are the effects - ie

natural=wood { set mkgmap:lu:cemetery=yes}

 If this works then Arndt seems to have a point?

r

Nick


Does mkgmap check if graveyard

On 15/12/2019 12:28, Arndt Röhrig wrote:
is-in-landuse, nice function!

with this new option i set acces=no for bicycles when the way is 
within a cemetary. (& no tag say, that bicycle is ok)


There are still a few polys where that could be used. 
amenity=grave_yard, amenity=hospital, leisure=pitch 


maybe its better to name the option is-in-polygone:polygone=value

Arndt



svn commit < s...@mkgmap.org.uk <mailto:s...@mkgmap.org.uk>> hat am 15. 
Dezember 2019 um 10:05 geschrieben:



Version mkgmap-r4397 was committed by gerd on Sun, 15 Dec 2019

implement and document new option --is-in-landuse=value[,value...]
- svn rename ResidentialHook.java to LanduseHook.java
- remove support for undocumented option --residential-hook=false
- warn if style uses mkgmap:residential which was replaced by 
mkgmap:lu:residential



http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4397
___
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

On 15/12/2019 09:05, svn commit wrote:

Version mkgmap-r4397 was committed by gerd on Sun, 15 Dec 2019

implement and document new option --is-in-landuse=value[,value...]
- svn rename ResidentialHook.java to LanduseHook.java
- remove support for undocumented option --residential-hook=false
- warn if style uses mkgmap:residential which was replaced by 
mkgmap:lu:residential


http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4397
___
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] Commit r4397: implement and document new option --is-in-landuse=value[, value...]

[Pinns UK]

Hi Gerd

I've been able to change footpaths on (some?)  amenity graveyards to 
paths by just setting the lu:cemetery to yes


I first tried :

amenity=grave_yard {set landuse=cemetry;echotags"change2landuse"}

  mkgmap:lu:cemetery=*  & highway=footway  {set highway=path}


however this did not work , ie footpaths on cemeteries didn't change to 
paths  and the echotags didn't show any :lu:cemetery


then I tried

 amenity=grave_yard {set mkgmap:lu:cemetery=yes}

  mkgmap:lu:cemetery=*  & highway=footway  {set highway=path}

 This seems to work for some (?)  graveyards (Haven't checked this on 2 
graveyards only)


My question is ,does mkgmap check if highways cross a polygon as soon as 
it parses mkgmap:lu:cemetery=*  & highway=footway


or are the checks done before 'Lines' are parsed?

If the user can set the value then what ,if any ,are the effects - ie

natural=wood { set mkgmap:lu:cemetery=yes}

 If this works then Arndt seems to have a point?

r

Nick


Does mkgmap check if graveyard

On 15/12/2019 12:28, Arndt Röhrig wrote:
is-in-landuse, nice function!

with this new option i set acces=no for bicycles when the way is within 
a cemetary. (& no tag say, that bicycle is ok)


There are still a few polys where that could be used. 
amenity=grave_yard, amenity=hospital, leisure=pitch 


maybe its better to name the option is-in-polygone:polygone=value

Arndt



svn commit < s...@mkgmap.org.uk > hat am 15. 
Dezember 2019 um 10:05 geschrieben:



Version mkgmap-r4397 was committed by gerd on Sun, 15 Dec 2019

implement and document new option --is-in-landuse=value[,value...]
- svn rename ResidentialHook.java to LanduseHook.java
- remove support for undocumented option --residential-hook=false
- warn if style uses mkgmap:residential which was replaced by 
mkgmap:lu:residential



http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4397
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk 
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

On 15/12/2019 09:05, svn commit wrote:

Version mkgmap-r4397 was committed by gerd on Sun, 15 Dec 2019

implement and document new option --is-in-landuse=value[,value...]
- svn rename ResidentialHook.java to LanduseHook.java
- remove support for undocumented option --residential-hook=false
- warn if style uses mkgmap:residential which was replaced by 
mkgmap:lu:residential


http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4397
___
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] New branch for default typ file

[Pinns UK]

Hi Gerd

The reason for suggesting unicode is that it caters for all languages, 
not just  those specified by 1252 or 1250 or 1251


However,   anyone not used to or bothered about codepages, will benefit 
from a mapnik.txt where the characters are 1252 compliant.


 I now have all my maps using cp 65001 as  Basecamp/ (mapsource?) 
automatically selects the appropriate  language depending on the user's 
Region settings.


Nick




On 14/12/2019 15:11, Gerd Petermann wrote:

Hi all,

when the source for the typ file specifies a codePage which is different from 
the one used on the command line we see a warning
WARNING: SortCode in TYP txt file different from command line setting

As an unexperienced user I would try to get rid of such a warning, maybe 
causing more trouble than needed.
A comment in the source says "This is just a warning, not a definite problem"

In (1) Nick suggested to use unicode in the typ file, so I wonder in what 
situation this warning is needed?

Gerd
(1) 
http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-special-chars-tp5932059p5932168.html


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Samstag, 14. Dezember 2019 15:21
An: Ticker Berkin; Development list for mkgmap
Betreff: Re: [mkgmap-dev] New branch for default typ file

Hi Ticker & Joris

I'd also prefer to maintain it as txt file, else I'd prefer to remove the file 
and add a simple hint were to find Joris files.

@Ticker:
The problem mentioned here is still there.
http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-special-chars-tp5932059p5932172.html
I'll try to code a fix now.

Gerd


Von: mkgmap-dev  im Auftrag von Ticker Berkin 

Gesendet: Samstag, 14. Dezember 2019 10:41
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] New branch for default typ file

Hi Joris & Gerd

Great to see the typ-files now in trunk and all the work in updating
mapnik.txt to the current default style. Next week I plan to go through
"20191209 mapnik update.pdf" and comment on it and possible changes to
the default style.

Some other questions however:

How do you see mapnik.txt now being maintained; will it be as as simple
.txt file with patches being supplied in the same way as other source
files, or will it be regenerated from your translation spreadsheet and
other sources? I'd prefer the simple text file approach, but this might
allow changes into the file which make it incompatible with the tools
Joris uses to enhance it.

It is currently in UTF8 format, with an appropriate BOM at the start of
the file. I don't know how the java input libraries determine the
conversion rules to internal unicode, but this file should be
consistent with all the others that contain characters outside the
simple ansi 7-bit range (roadNameConfig.txt, default/inc/address)

It contains the statement:

CodePage=65001

This is saying the output should be unicode, but the output should be
the same as the associated map.

Also the FID should be removed.

Regards
Ticker

On Tue, 2019-12-10 at 09:59 +, Gerd Petermann wrote:

Hi Joris,

the file mapnik.txt says "Based on mkgmap default style version:
r4262"
Is it the right file?

reg. line type 0x0b: highway=motorway_link & (mkgmap:exit_hint=true |
mkgmap:dest_hint=*)
I want to look at the DestinationHook. If I got that right it should
be OK to have a zero-length road with that type to get the wanted
destination hint. In that case we don't have to care about rendering.

Gerd


Von: Joris Bo 
Gesendet: Montag, 9. Dezember 2019 20:45
An: Development list for mkgmap; Gerd Petermann
Betreff: RE: [mkgmap-dev] New branch for default typ file

Hi All,

I don't think any changes needed in mkgmap itself. When the draworder
of bay is lower then water it will display correctly.
See attached new typ-file for correct usage.
Even better (but this is a change in default style): don't use
natural = bay in polygons but only in points for displaying as name.

Today I spent some time testing and repairing.

The mapnik.txt in branch mkgmap-default-typ-r4268 was pretty old and
also did not have the translations of all the languages anymore. It
also lost draworder of a lot of polygons which made the bay-problem
occur.

I did a complete recheck of the most recent default-style in: mkgmap
-r4386.zip and changed de typ-file accordingly.

I downloaded a full europe-latest from geofabrik today, builded it as
a big full europa map with the default style of r4386  and with
mkgmap r4386.jar No errors occured.

I think it’s up to date again but some review and comments are always
welcome.

See typ-file in attachement,

Kind regards,
Joris





-Oorspronkelijk bericht-
Van: mkgmap-dev  Namens Pinns
UK
Verzonden: maandag 9 december 2019 18:31
Aan: Gerd Petermann ;
mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: Re: [mkgmap-dev

Re: [mkgmap-dev] New branch for default typ file

[Pinns UK]

Hi Gerd

Yes, you can do that with a draw level 1 higher than sea.

Draw orders are defined at the beginning of a (txt) typ file just before 
the polygons


using the following format

Type=0x type number , draworder

It is good practice to sort the draworders , as that is how they appear 
in a typ file


[_drawOrder]
Type=0x03,1
Type=0x28,1
Type=0x54,1
Type=0x01,2
Type=0x09,2
 Type=0x4E,2
 Type=0x10F1C,2
etc etc
[end]
I have no idea what the draworder for sea is , but just make it one higher

On 09/12/2019 16:41, Gerd Petermann wrote:

Hi Nick,

I don't want to cut out islands from bay polygons, I thought about a proper typ for 0x3d 
which somehow marks "calmer water"
and a draw order that puts this above water and below any land type polygon.
Is that possible?

Gerd


Von: Pinns UK 
Gesendet: Montag, 9. Dezember 2019 16:17
An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: AW: AW: [mkgmap-dev] New branch for default typ file

Hi Gerd

Yes, I suppose so

On 09/12/2019 15:14, Gerd Petermann wrote:

Hi Nick,

my understanding is that you always have another water polygon, either ocean or 
natural=water.

Gerd


Von: Pinns UK 
Gesendet: Montag, 9. Dezember 2019 16:04
An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: AW: [mkgmap-dev] New branch for default typ file

Hi Gerd

In case of 2) you need 2 polygons for doing each job; one showing
'water' and the other one not

Ideally,mkgmap checks if islands are in a 'bay' area

In my area we have lots of natural=bays ; fortunately they do not
include islands

On 09/12/2019 14:51, Gerd Petermann wrote:

Hi,

thanks for the help.
I see two ways to handle the a polygon with natural=bay:
1) in ponts style with natural=bay & name=*  []
2) in polygons (as it is now) with natural=bay [0x3d resolution 18]

In case of 1) we just need option add-pois-to-areas
In case of 2) we would want to render the water area covered by the bay polygon 
different, but not anything on the land or on islands. Would that be possible?

Gerd




Von: mkgmap-dev  im Auftrag von Pinns UK 

Gesendet: Montag, 9. Dezember 2019 15:42
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] New branch for default typ file

Andrzej is correct about how transparency is defined

Garmin regards all polygons with transparency  as bitmaps and therefore
require 2 colours.

The Bitmap need to be shown below the xpm

If a polygon is completely transparent then a second 'dummy' colour is
still needed

Xpm="32 32 2 1"
"0 c none"
"1 c #C8C8C8"
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
;12345678901234567890123456789012
[end]

On 09/12/2019 14:19, Andrzej Popowski wrote:

Hi Gerd,

I use TypViewer for creating typ files and I don't know XPM details.
But looking at TypViewer output, I guess that transparent pixels are
defined with color like that:

"  c none"

where space ' ' is used for marking pixels.

Changing draw order instead of transparent graphics could be a
solution too, but I'm not sure if covered polygon label would remain
visible. And without label, there is not much use of this object.


___
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] New branch for default typ file

[Pinns UK]

Hi Gerd

Yes, I suppose so

On 09/12/2019 15:14, Gerd Petermann wrote:

Hi Nick,

my understanding is that you always have another water polygon, either ocean or 
natural=water.

Gerd


Von: Pinns UK 
Gesendet: Montag, 9. Dezember 2019 16:04
An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: AW: [mkgmap-dev] New branch for default typ file

Hi Gerd

In case of 2) you need 2 polygons for doing each job; one showing
'water' and the other one not

Ideally,mkgmap checks if islands are in a 'bay' area

In my area we have lots of natural=bays ; fortunately they do not
include islands

On 09/12/2019 14:51, Gerd Petermann wrote:

Hi,

thanks for the help.
I see two ways to handle the a polygon with natural=bay:
1) in ponts style with natural=bay & name=*  []
2) in polygons (as it is now) with natural=bay [0x3d resolution 18]

In case of 1) we just need option add-pois-to-areas
In case of 2) we would want to render the water area covered by the bay polygon 
different, but not anything on the land or on islands. Would that be possible?

Gerd




Von: mkgmap-dev  im Auftrag von Pinns UK 

Gesendet: Montag, 9. Dezember 2019 15:42
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] New branch for default typ file

Andrzej is correct about how transparency is defined

Garmin regards all polygons with transparency  as bitmaps and therefore
require 2 colours.

The Bitmap need to be shown below the xpm

If a polygon is completely transparent then a second 'dummy' colour is
still needed

Xpm="32 32 2 1"
"0 c none"
"1 c #C8C8C8"
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
;12345678901234567890123456789012
[end]

On 09/12/2019 14:19, Andrzej Popowski wrote:

Hi Gerd,

I use TypViewer for creating typ files and I don't know XPM details.
But looking at TypViewer output, I guess that transparent pixels are
defined with color like that:

"  c none"

where space ' ' is used for marking pixels.

Changing draw order instead of transparent graphics could be a
solution too, but I'm not sure if covered polygon label would remain
visible. And without label, there is not much use of this object.


___
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] New branch for default typ file

[Pinns UK]

Hi Gerd

In case of 2) you need 2 polygons for doing each job; one showing 
'water' and the other one not


Ideally,    mkgmap checks if islands are in a 'bay' area

In my area we have lots of natural=bays ; fortunately they do not 
include islands


On 09/12/2019 14:51, Gerd Petermann wrote:

Hi,

thanks for the help.
I see two ways to handle the a polygon with natural=bay:
1) in ponts style with natural=bay & name=*  []
2) in polygons (as it is now) with natural=bay [0x3d resolution 18]

In case of 1) we just need option add-pois-to-areas
In case of 2) we would want to render the water area covered by the bay polygon 
different, but not anything on the land or on islands. Would that be possible?

Gerd




Von: mkgmap-dev  im Auftrag von Pinns UK 

Gesendet: Montag, 9. Dezember 2019 15:42
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] New branch for default typ file

Andrzej is correct about how transparency is defined

Garmin regards all polygons with transparency  as bitmaps and therefore
require 2 colours.

The Bitmap need to be shown below the xpm

If a polygon is completely transparent then a second 'dummy' colour is
still needed

Xpm="32 32 2 1"
"0 c none"
"1 c #C8C8C8"
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
;12345678901234567890123456789012
[end]

On 09/12/2019 14:19, Andrzej Popowski wrote:

Hi Gerd,

I use TypViewer for creating typ files and I don't know XPM details.
But looking at TypViewer output, I guess that transparent pixels are
defined with color like that:

"  c none"

where space ' ' is used for marking pixels.

Changing draw order instead of transparent graphics could be a
solution too, but I'm not sure if covered polygon label would remain
visible. And without label, there is not much use of this object.


___
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] New branch for default typ file

[Pinns UK]

Andrzej is correct about how transparency is defined

Garmin regards all polygons with transparency  as bitmaps and therefore 
require 2 colours.


The Bitmap need to be shown below the xpm

If a polygon is completely transparent then a second 'dummy' colour is  
still needed


Xpm="32 32 2 1"
"0 c none"
"1 c #C8C8C8"
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
;12345678901234567890123456789012
[end]

On 09/12/2019 14:19, Andrzej Popowski wrote:

Hi Gerd,

I use TypViewer for creating typ files and I don't know XPM details. 
But looking at TypViewer output, I guess that transparent pixels are 
defined with color like that:


"  c none"

where space ' ' is used for marking pixels.

Changing draw order instead of transparent graphics could be a 
solution too, but I'm not sure if covered polygon label would remain 
visible. And without label, there is not much use of this object.



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

Re: [mkgmap-dev] space before name

[Pinns UK]

Hi Gerd

Enrico asked me for a way to ensure labels are not physically attached 
to a poi when viewed in Mapsource or Basecamp.


Aesthetically it seems not to conform to the way labels are shown on 
most maps -' ICON label' rather than 'ICONlabel'


r

Nick

On 08/12/2019 09:45, Gerd Petermann wrote:

Hi Nick,

the option --x-keep-blanks is not limited to POI names, it is about any value 
label given with mkgmap:label:1 .. mkgmap:label:4.
I have no idea what problems you and Enrico are trying to solve, but a solution 
in the TYP file is probably much better.

Gerd


Von: Pinns UK 
Gesendet: Sonntag, 8. Dezember 2019 10:32
An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: AW: AW: [mkgmap-dev] space before name

Hi Gerd

In take your point - you wouldn't put spaces in front of place names ;
it seems more pleasing to the eye  to have names of ,say, pubs  detached
from the poi . I haven't investigated how it affects searches and
personally am not too concerned when it comes to amenities. In a typ
file you can put white spaces to the right of a poi with a single pixel
on the far right in another colour - not ideal

On 08/12/2019 08:49, Gerd Petermann wrote:

Hi Nick,

my understanding is that there should be absolutely no difference between 1 or 
5 or 32 leading spaces with the unpatched version.
I did not try how leading spaces are treated when doing address search or POI 
search with names. In my eyes it is a bad idea to add blanks,
I'd prefer to also remove leading and trailing blanks. I just don't know why 
WanMil removed the corresponding code and I am too lazy to find out ;)

Gerd


Von: Pinns UK 
Gesendet: Sonntag, 8. Dezember 2019 09:17
An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: AW: [mkgmap-dev] space before name

Hi Gerd

I'm sorry ; I  have no idea what the code refers to but does seem a good
idea to have an option where the number of

spaces in front of a label are not halved/reduced.Like Enrico, I've had
to add about 32 spaces before I could notice any difference - this has
been resolved using the mkgmap you prepared for Enrico.

hth

Nick


On 08/12/2019 08:06, Gerd Petermann wrote:

Hi Nick,

please explain. I still don't fully understand the code in method 
Label.squashSpaces(). It replaces sequences of so called white space characters 
by a single blank.
A whitespace character "\s" is defined here:
https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html

When you say "that would be an excellent idea" I wonder if I should better 
remove the call of Label.squashSpaces() instead of adding a new option.

Gerd


Von: mkgmap-dev  im Auftrag von Pinns UK 

Gesendet: Sonntag, 8. Dezember 2019 08:55
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] space before name

Hi Gerd

I think this would be an excellent  idea as surrounding icons with
transparent spaces in a TYP file  does not do the trick - Garmin simply
ignores them .

Also, interestingly, Garmin (Basecamp) does not support chr$(9) (TABS) -
have tested this in a TYP file (it accepts chr$(10) )

r

Nick

On 08/12/2019 07:10, Gerd Petermann wrote:

Hi Enrico,

I think about adding a new undocumented option --x-keep-blanks
I have not yet understood why we replace duplicated blanks but not all leading 
and trailing blanks.
This was changed in the mergeroads branch with r2827:
http://www.mkgmap.org.uk/websvn/comp.php?repname=mkgmap[]=%2Fbranches%2Fmergeroads%2Fsrc%2Fuk%2Fme%2Fparabola@2817[]=%2Fbranches%2Fmergeroads%2Fsrc%2Fuk%2Fme%2Fparabola@2827

Gerd


Von: mkgmap-dev  im Auftrag von demon_box 

Gesendet: Sonntag, 8. Dezember 2019 07:23
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] space before name

Hi Gerd, the new releases of the mkgmap will have this feature embedded?
Thanks.

--enrico




--
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 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] space before name

[Pinns UK]

Hi Gerd

In take your point - you wouldn't put spaces in front of place names ; 
it seems more pleasing to the eye  to have names of ,say, pubs  detached 
from the poi . I haven't investigated how it affects searches and 
personally am not too concerned when it comes to amenities. In a typ 
file you can put white spaces to the right of a poi with a single pixel 
on the far right in another colour - not ideal


On 08/12/2019 08:49, Gerd Petermann wrote:

Hi Nick,

my understanding is that there should be absolutely no difference between 1 or 
5 or 32 leading spaces with the unpatched version.
I did not try how leading spaces are treated when doing address search or POI 
search with names. In my eyes it is a bad idea to add blanks,
I'd prefer to also remove leading and trailing blanks. I just don't know why 
WanMil removed the corresponding code and I am too lazy to find out ;)

Gerd


Von: Pinns UK 
Gesendet: Sonntag, 8. Dezember 2019 09:17
An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: AW: [mkgmap-dev] space before name

Hi Gerd

I'm sorry ; I  have no idea what the code refers to but does seem a good
idea to have an option where the number of

spaces in front of a label are not halved/reduced.Like Enrico, I've had
to add about 32 spaces before I could notice any difference - this has
been resolved using the mkgmap you prepared for Enrico.

hth

Nick


On 08/12/2019 08:06, Gerd Petermann wrote:

Hi Nick,

please explain. I still don't fully understand the code in method 
Label.squashSpaces(). It replaces sequences of so called white space characters 
by a single blank.
A whitespace character "\s" is defined here:
https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html

When you say "that would be an excellent idea" I wonder if I should better 
remove the call of Label.squashSpaces() instead of adding a new option.

Gerd


Von: mkgmap-dev  im Auftrag von Pinns UK 

Gesendet: Sonntag, 8. Dezember 2019 08:55
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] space before name

Hi Gerd

I think this would be an excellent  idea as surrounding icons with
transparent spaces in a TYP file  does not do the trick - Garmin simply
ignores them .

Also, interestingly, Garmin (Basecamp) does not support chr$(9) (TABS) -
have tested this in a TYP file (it accepts chr$(10) )

r

Nick

On 08/12/2019 07:10, Gerd Petermann wrote:

Hi Enrico,

I think about adding a new undocumented option --x-keep-blanks
I have not yet understood why we replace duplicated blanks but not all leading 
and trailing blanks.
This was changed in the mergeroads branch with r2827:
http://www.mkgmap.org.uk/websvn/comp.php?repname=mkgmap[]=%2Fbranches%2Fmergeroads%2Fsrc%2Fuk%2Fme%2Fparabola@2817[]=%2Fbranches%2Fmergeroads%2Fsrc%2Fuk%2Fme%2Fparabola@2827

Gerd


Von: mkgmap-dev  im Auftrag von demon_box 

Gesendet: Sonntag, 8. Dezember 2019 07:23
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] space before name

Hi Gerd, the new releases of the mkgmap will have this feature embedded?
Thanks.

--enrico




--
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 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] space before name

[Pinns UK]

Hi Gerd

I'm sorry ; I  have no idea what the code refers to but does seem a good 
idea to have an option where the number of


spaces in front of a label are not halved/reduced.Like Enrico, I've had 
to add about 32 spaces before I could notice any difference - this has 
been resolved using the mkgmap you prepared for Enrico.


hth

Nick


On 08/12/2019 08:06, Gerd Petermann wrote:

Hi Nick,

please explain. I still don't fully understand the code in method 
Label.squashSpaces(). It replaces sequences of so called white space characters 
by a single blank.
A whitespace character "\s" is defined here:
https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html

When you say "that would be an excellent idea" I wonder if I should better 
remove the call of Label.squashSpaces() instead of adding a new option.

Gerd


Von: mkgmap-dev  im Auftrag von Pinns UK 

Gesendet: Sonntag, 8. Dezember 2019 08:55
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] space before name

Hi Gerd

I think this would be an excellent  idea as surrounding icons with
transparent spaces in a TYP file  does not do the trick - Garmin simply
ignores them .

Also, interestingly, Garmin (Basecamp) does not support chr$(9) (TABS) -
have tested this in a TYP file (it accepts chr$(10) )

r

Nick

On 08/12/2019 07:10, Gerd Petermann wrote:

Hi Enrico,

I think about adding a new undocumented option --x-keep-blanks
I have not yet understood why we replace duplicated blanks but not all leading 
and trailing blanks.
This was changed in the mergeroads branch with r2827:
http://www.mkgmap.org.uk/websvn/comp.php?repname=mkgmap[]=%2Fbranches%2Fmergeroads%2Fsrc%2Fuk%2Fme%2Fparabola@2817[]=%2Fbranches%2Fmergeroads%2Fsrc%2Fuk%2Fme%2Fparabola@2827

Gerd


Von: mkgmap-dev  im Auftrag von demon_box 

Gesendet: Sonntag, 8. Dezember 2019 07:23
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] space before name

Hi Gerd, the new releases of the mkgmap will have this feature embedded?
Thanks.

--enrico




--
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 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] space before name

[Pinns UK]

Hi Gerd

I think this would be an excellent  idea as surrounding icons with 
transparent spaces in a TYP file  does not do the trick - Garmin simply 
ignores them .


Also, interestingly, Garmin (Basecamp) does not support chr$(9) (TABS) - 
have tested this in a TYP file (it accepts chr$(10) )


r

Nick

On 08/12/2019 07:10, Gerd Petermann wrote:

Hi Enrico,

I think about adding a new undocumented option --x-keep-blanks
I have not yet understood why we replace duplicated blanks but not all leading 
and trailing blanks.
This was changed in the mergeroads branch with r2827:
http://www.mkgmap.org.uk/websvn/comp.php?repname=mkgmap[]=%2Fbranches%2Fmergeroads%2Fsrc%2Fuk%2Fme%2Fparabola@2817[]=%2Fbranches%2Fmergeroads%2Fsrc%2Fuk%2Fme%2Fparabola@2827

Gerd


Von: mkgmap-dev  im Auftrag von demon_box 

Gesendet: Sonntag, 8. Dezember 2019 07:23
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] space before name

Hi Gerd, the new releases of the mkgmap will have this feature embedded?
Thanks.

--enrico




--
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 mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] documentation of new option in branch

[Pinns UK]

Thanks Gerd

On 04/11/2019 15:37, Gerd Petermann wrote:

Hi Nick,

as always the information is written with the logger (1). You have to activate 
logging at info level with
uk.me.parabola.imgfmt.app.net.RoadNetwork.level=INFO

(1) https://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging

Using a negative value for NUM means that mkgmap doesn't calculate the islands 
at all, using
0 means that it only reports the islands. If you want to remove islands you can 
start with a value like
500. The default is 0.

Gerd


Von: mkgmap-dev  im Auftrag von Pinns UK 

Gesendet: Montag, 4. November 2019 16:29
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] documentation of new option in branch

Hi Gerd

Thanks for all you work with regards routing islands!

a) Is there a way of finding out how many .if any. routing islands were found 
given a certain length?

b)  if NUM is negative is there any point in adding 
--check-routing-island-len=NUM

Nick



On 04/11/2019 13:58, Gerd Petermann wrote:

Hi all,

I think the work on the branch is almost done.
Attached is a patch to add documentation for the new option.
Please help to improve it:

--check-routing-island-len=NUM
 Routing islands are small road networks which are not connected to 
other
 roads. Typical case is a footway that is not connected to the main road
 network. These islands can cause problems if you try to calculate a 
route
 and Garmin selects a point on the island as a start. It will fail to
 calulate the route even if a major road is only a few steps away.
 When calculating the NOD data mkgmap detects the islands. The option
 --check-routing-island-len=NUM can be used to tell mkgmap that islands 
with
 a total length below NUM meters should not be written to NOD. The 
effect is
 that the corresponding roads are visible as usual but they are not
 routable.
 A negative value for NUM means that mkgmap skips the island check.

ciao
Gerd



___
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] documentation of new option in branch

[Pinns UK]

Hi Gerd

Thanks for all you work with regards routing islands!

a) Is there a way of finding out how many .if any. routing islands were 
found given a certain length?


b)  if NUM is negative is there any point in adding 
--check-routing-island-len=NUM


Nick

 


On 04/11/2019 13:58, Gerd Petermann wrote:

Hi all,

I think the work on the branch is almost done.
Attached is a patch to add documentation for the new option.
Please help to improve it:

--check-routing-island-len=NUM
Routing islands are small road networks which are not connected to other
roads. Typical case is a footway that is not connected to the main road
network. These islands can cause problems if you try to calculate a 
route
and Garmin selects a point on the island as a start. It will fail to
calulate the route even if a major road is only a few steps away.
When calculating the NOD data mkgmap detects the islands. The option
--check-routing-island-len=NUM can be used to tell mkgmap that islands 
with
a total length below NUM meters should not be written to NOD. The 
effect is
that the corresponding roads are visible as usual but they are not
routable.
A negative value for NUM means that mkgmap skips the island check.

ciao
Gerd

___
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] mapids beyond the limit

[Pinns UK]

Hi Gerd

Thanks a lot; will test it when the .jar file is available.

I haven't investigated if the FIDs and PIDs also need to be checked for 
an invalid input.


Nick

On 01/11/2019 21:18, Gerd Petermann wrote:

Hi Nick,

reg. --mapname=:

The attached patch stops mkgmap before computing any tile when it calculates  
an invalid mapid for any tile.

I tested special cases like
java -jar mkgmap.jar d:\osm\9.osm d:\osm\sample.osm
or
java -jar mkgmap.jar d:\osm\sample.osm --mapname= second.osm third.osm

Time started: Fri Nov 01 22:14:42 CET 2019
Cannot calculate mapid for third.osm
Number of ExitExceptions: 1
Time finished: Fri Nov 01 22:14:42 CET 2019
Total time taken: 88 ms

I hope that's what you proposed?

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Freitag, 1. November 2019 12:42
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] mapids beyond the limit

Hi Nick,

NET3 is just a list of offsets into NET in a particular order. The problem is 
not the order itself but the de-duplication that happens before.
My current understanding is that the list should contain all roads which have 
numbers or more than one city. This is not always the case.

BTW: I found this only because I was surprised that the NET and NOT file 
written for resolution 23 with the brannch version (1) was almost the same 
compared to that written with resolution 24. After some thinking I wondered why 
it was exactly equal ;)

Gerd
(1) http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4335


Von: mkgmap-dev  im Auftrag von Pinns UK 

Gesendet: Freitag, 1. November 2019 12:11
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] mapids beyond the limit

Hi Gerd

No rush

What you are finding out about NET3 is really fascinating. Hope you are
able to uncover how identical treet names are linked to their coordinates.

Nick

On 01/11/2019 08:42, Gerd Petermann wrote:

Hi Nick,

okay, I'll have a look later. I am now working on problems with the address 
search in trunk version. I've noticed that some house numbers are not found in 
Mapsource,  reason are missing entries in NET3. So far I've learned that NET3 
must contain all roads with numbers. There is also an issue with equally named 
roads in different cities, but I am not yet sure if I can fix those.

Gerd


Von: mkgmap-dev  im Auftrag von nwillink 

Gesendet: Donnerstag, 31. Oktober 2019 19:38
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] mapids beyond the limit

Hi Gerd

For testing purposes I have created an arg file with mapids starting from

  (8 digits)

and incrementing them to

10009 (9 digits)

It created  all the tiles (imgs) - I don't think it gave me a warning about
most imgs having a nine digital mapid.

After I installed the map onto Basecamp , Basecamp reported an error and
refused to load.

I'm sure this has never been an issue with anyone using mkgmap, but it might
be useful to check the validity of mapids when tiles are created ?

Regards

Nick





--
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 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] mapids beyond the limit

[Pinns UK]

Hi Gerd

No rush

What you are finding out about NET3 is really fascinating. Hope you are 
able to uncover how identical treet names are linked to their coordinates.


Nick

On 01/11/2019 08:42, Gerd Petermann wrote:

Hi Nick,

okay, I'll have a look later. I am now working on problems with the address 
search in trunk version. I've noticed that some house numbers are not found in 
Mapsource,  reason are missing entries in NET3. So far I've learned that NET3 
must contain all roads with numbers. There is also an issue with equally named 
roads in different cities, but I am not yet sure if I can fix those.

Gerd


Von: mkgmap-dev  im Auftrag von nwillink 

Gesendet: Donnerstag, 31. Oktober 2019 19:38
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] mapids beyond the limit

Hi Gerd

For testing purposes I have created an arg file with mapids starting from

  (8 digits)

and incrementing them to

10009 (9 digits)

It created  all the tiles (imgs) - I don't think it gave me a warning about
most imgs having a nine digital mapid.

After I installed the map onto Basecamp , Basecamp reported an error and
refused to load.

I'm sure this has never been an issue with anyone using mkgmap, but it might
be useful to check the validity of mapids when tiles are created ?

Regards

Nick





--
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 mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] crude routing of my gpsmap 276Cx

[Pinns UK]

Hi

The Tertiary road has an incline of -12 degrees.

Perhaps it's avoiding steep hills?

Regards

Nick
On 24/09/2019 20:58, DD8KQ wrote:

Hi

may be that somebody has an idea why the routing of my gpsmap 276Cx is
so crude. I'm using almost the standard style to build my own garmin
maps. And as the example is mostly in the vicinity of my hometown,i had
not experienced this error before, as i need not a gps in my home area.
If you look at picture 20190924_173131.jpg this is a routing i would
expect to the destination, short and fast. If you look at
20190924_173229.jpg, the destination is only a few meters away from the
first one, the routing is nearly three times more than before with the
same settings on my device. I would appreciate any advice what to change
or any hint where i can look for why this could happen.

Btw, if i change the setting to use bicycle routing, the device will use
for both destinations the expected way

--

#

 Viele Grüße und 73 de Manfred Haiduk, DD8KQ
 e-mail mhai...@t-online.de dd...@gmx.de

#


___
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