[mkgmap-dev] Default Style - dead conditions?

[nwillink]

Hi Ticker 

Looking at you style file I noticed that there might be an issue  with the
following

(In fact it is found in the default style)

145 highway=motorway [0x01 road_class=4 road_speed=7 resolution 15]
277 (highway=motorway | highway=trunk)  & ref=*{name
'${ref|highway-symbol:hbox}'; addlabel '${name}'}

Under which condition will  highway=motorway be TRUE in line 277

Are we missing a 'continue' ? 
ie

highway=motorway [0x01 road_class=4 road_speed=7 resolution 15 continue]

(Same applies for primary& secondary)
 
155 highway=primary [0x03 road_class=3 road_speed=4 resolution 19]
278 highway=primary  & ref=*{name '${ref|highway-symbol:box}' ; addlabel
'${name}'}
 
161 highway=secondary [0x04 road_class=2 road_speed=3 resolution 20]
279 (highway=secondary | highway=tertiary) & ref=*{name
'${ref|highway-symbol:oval}'; addlabel '${name}'}

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

[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] is_in example?

[nwillink]

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

[nwillink]

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

[nwillink]

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

Re: [mkgmap-dev] Bold text of a point

[nwillink]

Hi

Garmin does not support bold fonts, the nearest you get to 'bold' is 'large'
(I'm sure you are aware of the available range of font styles).

In Basecamp 0x1500 offers quite a large font but then its specifically used
for cities.

In Basecampo 0x6215 has its text capitalised, but it's not bold.

You can resort to trickey by scanning in a label onto a wide poi.

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] 'loose' gates

[nwillink]

Hi All

Does anyone know a way of detecting gates and for that matter any barrier
not linked to a highway?

My area is strewn with farm gates which are not joined to any highway ; from
the a routing point of view they are totally are irrelevant and purely
aesthetic.

Also, there might be barriers which look connected to a highway but are not
and so have slipped through the net.

As points are parsed before lines I suppose there is no way of doing this,
and yet when parsing a highway, mkgmap must know if a line contains a
barrier.

Thanks

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

Re: [mkgmap-dev] extended & routable types at different resolutions

[nwillink]

Thanks Felix
 
Never knew that !

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] extended & routable types at different resolutions

[nwillink]

Hi All

I noticed default style uses extended types for roundabouts  with a matching
routable line. However
extended lines are plotted starting at a lower resolution, ie

Resolution 24
junction=roundabout & (highway=trunk | highway=trunk_link) [0x0c
road_class=4 road_speed=2 resolution 24 continue]
Resoiution 18
junction=roundabout & (highway=trunk | highway=trunk_link) [0x10801
resolution 18]

In this case it does not seem to matter if 0x0c starts at resolution 24
rather than 18, or does it?

Can we presume that all  routable lines only require resolution 24 , ie

a) highway=motorway [0x100 resolution 16-20 continue] # thinnest  line
b) highway=motorway [0x101 resolution 21-23 continue] # thinner line
c) highway=motorway [0x01 road_class=4 road_speed=7 resolution 24] # default
line

Will this affect routing across tiles ?

At the moment I'm adding a transparent routable line to  a & b ie

a) highway=motorway [0x100 resolution 16-20 continue] # thinnest  line
 highway=motorway [0x17  road_class=4 road_speed=7 resolution 16-20
continue] 
b) highway=motorway [0x101 resolution 21-23 continue] # thinner line
 highway=motorway [0x17 road_class=4 road_speed=7 resolution 21-23 continue] 

Any ideas?

Thanks

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] unusual if-then results

[nwillink]

Hi All

I'm getting curious results using a conditional statement.

I insert the following in polygons (default style) at the end ,just before
:

if (area=yes & landuse!=residential) then
landuse=* {set name= '$(landuse)';}
(landuse=*|waterway=*|amenity=*|natural=*|leisure=*) {echotags "mopping up
area"} [0x10910 resolution 24 continue]
end

I use the Ireland & Northern Ireland pbf from Geofabrik

The echotags list includes some puzzling entries

1) some entries (see below) do not include 'area=yes', ie landuse=religious
& landuse=plant_nursery
2) it also includes landuse=residential despite having specified
'landuse!=residential' in my 'if statement'

Regards

Nick

This is part of my echotags list 

File:d:\temp\ireland-and-northern-ireland-latest.osm.pbf

* mopping up area *
Way 194526400 
landuse=religious
 mkgmap:cache_area_size=242.848


* mopping up area *
Way 456431379 
area=yes
 landuse=flowerbed
 mkgmap:cache_area_size=35.741
 mkgmap:if:1=true
 name=flowerbed


* mopping up area *
Way 452524709 
landuse=plant_nursery
 mkgmap:cache_area_size=4250.272


* mopping up area *
Way 465641413 
landuse=religious
 mkgmap:cache_area_size=614.697
 mkgmap:residential=yes


* mopping up area *
Way generated from 456431378 
area=yes
 landuse=flowerbed
 mkgmap:cache_area_size=64.662
 mkgmap:if:1=true
 mkgmap:mp_created=true
 mkgmap:stylefilter=polygon
 name=flowerbed
 
 * mopping up area *
Way 465641413 
landuse=religious
 mkgmap:cache_area_size=614.697
 mkgmap:residential=yes





--
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] Possible If then bug

[nwillink]

Hi

I've noticed some unexpected behaviour when using 'if then'

Today, in osm, a polygon can have multiple 'land describing' tags  ie
landuse=grass & natural=wood or landuse=forest and natural=heath etc

To ensure both get parsed I use the following:

if (landuse=* & natural=*) then
# parse natural ; use continue ; delete natural
natural=wood {echotags "wood & transparency"}[0x1101c resolution 18 continue
] #50
# add more natural=
# at end of list delete natural so it doesn't get plotted lower down
natural=* {delete natural}
# continue parsing landuse
end
This works well, however ...

The following url contains one natural=wood and area=yes (sic)
https://www.openstreetmap.org/export#map=17/50.69541/-3.53819

There is no mention of a landuse  and yet this wood gets included asif it
has a  landuse= something tag

Is this because of the area tag?

r
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] Openstreetmap URL

[nwillink]

Hi Gert

Just a minor observation

SEVERE (StyledConverter):args\16620002.o5m: Found multiple points with equal
coords as CoordPOI at
http://www.openstreetmap.org/?mlat=50.764580&mlon=-3.427609&zoom=17

Perhaps all openstreetmap urls included in an error message should precede
with https not http?

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] Address Searches on new GPSmap66S

[nwillink]

Hi All

Just say that the latest GPSmap66S gives a 'Cannot find address'  when
searching for an address!

Oddly, it lists any address you have entered, ie it finds the names of
streets and towns/cities even the numbers of an address but annoyingly
refuses to locate them on the map.

Checking the manual it says:

'You can use optional City Navigator maps to search for addresses.'

mmm

So it only works with City Navigator maps , a sign of things to come?

Apart from that , mkgmap's custom maps work !

r

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] Beaches as a polygon

[nwillink]

Hi


I noticed that the default style only renders Beaches as a point not a
polygon.

Beaches as a polygon  may be unimportant to many but I feel that without
them maps are very misleading and incomplete -

see picture

http://files.mkgmap.org.uk/download/437/beach.jpg

 (left default style , right with beach)

Garmin deems them important as they are included as an option in their kmtf
files for their City Navigator maps and nuvis etc.

Given the fact that only a very limited number of polygons are used in a
kmtf file, the beach inclusion seems quite significant.

They use 0x10C06 in City Navigator.

Just a suggestion

r.


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] Failing to get size

[nwillink]

Hi Gerd

I'm now getting these msgs 

SEVERE (HGTReader): failed to get size for file N41W126.hgt from
E:\Dem\NorthAmerica\N41W126.hgt.zip

It seems to apply to zipped hgt files.

How important is it to know file sizes? ie is there a need for such a
message?

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] args input-file path issue

[nwillink]

Hi Gerd

Have come across this problem with input-file path names when creating and
args file:

It seems to be due to the spaces in feb  1 2018

The following creates errors:

input-file:F:\mp5\backup\feb 1 2018\args\40526979.osm.pbf

This doesn't work either (using quotes)
input-file:"F:\mp5\backup\feb 1 2018\args\40526979.osm.pbf"

nor  (using shortpaths for the whole filename)

input-file:F:\mp5\backup\FEB120~1\405269~2.PBF

This does works:

input-file:F:\mp5\backup\FEB120~1\40526979.osm.pbf


r
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] missing link

[nwillink]

@Steve

Hi Steve

Just to say that clicking on 'mkgmap' gives me a 404 :

http://files.mkgmap.org.uk/

r

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] Error when not using dem-poly

[nwillink]

Hi Gerd

I'm using latest r4036

I'm applying what you suggested to Minko to avoid contours been given a dem.

In my dem.args I have

dem=e:\dem\europe\
overview-dem-dist=88 
dem-dists=3312,13248,26512,53024

and get the following error:

Number of MapFailedExceptions: 0
Exception in thread "main" java.lang.NullPointerException
at
uk.me.parabola.mkgmap.reader.hgt.HGTConverter.getElevation(HGTConvert
er.java:89)
at
uk.me.parabola.mkgmap.reader.hgt.HGTConverter.getHeights(HGTConverter
.java:287)
at
uk.me.parabola.imgfmt.app.dem.DEMSection.calcTiles(DEMSection.java:10
5)
at
uk.me.parabola.imgfmt.app.dem.DEMSection.(DEMSection.java:78)
at uk.me.parabola.imgfmt.app.dem.DEMFile.calc(DEMFile.java:60)
at
uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:340)
at
uk.me.parabola.mkgmap.combiners.OverviewBuilder.writeOverviewMap(Over
viewBuilder.java:191)
at
uk.me.parabola.mkgmap.combiners.OverviewBuilder.onFinish(OverviewBuil
der.java:103)
at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:617)
at
uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.ja
va:128)
at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:136)
at uk.me.parabola.mkgmap.main.Main.main(Main.java:107)

1) When I add dem-poly=areas.poly the error disappears.

2) I also don't get the error if I replace -c dem-args with
--dem=e:\dem\europe\ --overview-dem-dist=88 
--dem-dists=3312,13248,26512,53024

3) This only seems to affect certain pbfs.

file:  http://files.mkgmap.org.uk/download/385/12345678.osm.pbf

r
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] sea hgt files

[nwillink]

Hi Gerd

I think there is still an issue when --x-dem searches for sea hgt files
which by design don't exist . After splitting the UK with maxnodes at 16
and selecting the far south west (Cornwall) tile I get an error - see below.

Its looking for  N49W008.hgt which is just sea.
Would it be possible to ignore a .hgt if it doesn't exist or use Frank's
dummyvalues idea?

r
Nick



java.lang.RuntimeException: failed to open E:\Dem\europe/N49W008.hgt
at
uk.me.parabola.mkgmap.reader.hgt.HGTReader.(HGTReader.java:45)
at
uk.me.parabola.mkgmap.reader.hgt.HGTConverter.(HGTConverter.jav
a:43)
at
uk.me.parabola.imgfmt.app.dem.DEMSection.(DEMSection.java:51)
at uk.me.parabola.imgfmt.app.dem.DEMFile.calc(DEMFile.java:44)
at
uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:284)
at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:107)
at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:69)
at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:263)
at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:259)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.FileNotFoundException: E:\Dem\europe\N49W008.hgt (The
system
cannot find the file specified)
at java.io.FileInputStream.open0(Native Method)
at java.io.FileInputStream.open(Unknown Source)
at java.io.FileInputStream.(Unknown Source)
at java.io.FileInputStream.(Unknown Source)
at
uk.me.parabola.mkgmap.reader.hgt.HGTReader.(HGTReader.java:38)



--
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] dem not showing

[nwillink]

Hi Gerd

I've come across an issue with mkgmap-dem-tdb-r4013

It involves N51E000.hgt but perhaps any xxxE000.hgt

It seems to create an empty dem - 

I came across the problem after splitting the UK - even with max nodes
800,000

I used this pbf :

http://files.mkgmap.org.uk/download/376/maidstone.pbf

Interestingly , Frank's program creates the correct DEM.

r

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] BuildDEMFile problem

[nwillink]

@ Frank

I think I've come across a problem with the DEM subfile not being read by
Basecamp.

I've come across this whilst creating a map of the south east coast of the
UK - the same may apply to Calais

When I split the UK it does not show the dem files of Dover area - 

I created a small map.osm which may point to the problem  
http://www.pinns.co.uk/errs/map.zip   

DEM files are created but ignored by Basecamp

Any ideas?

r

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] hgt2osm questions

[nwillink]

@ Frank

What a great tool for creating contour lines!

1) I'm having some success with your other great program,osm2hgt , however I
fail to merge two or more  .hgt files into a single osm .

Am I doing something wrong?

C:\Users\Owner\Desktop>E:\hgt2osm.exe --HgtPath=E:\Dem\All_UK_HGT_Data\
--Lat=49
 --Lon=-3  --Outfile=e:\dev1.osm --Mergefile=e:\devonall2.osm
C:\Users\Owner\Desktop>E:\hgt2osm.exe --HgtPath=E:\Dem\All_UK_HGT_Data\
--Lat=49
 --Lon=-4  --Outfile=e:\dev2.osm --Mergefile=e:\devonall2.osm

devonall2.osm doesn't seem to have merged both files.

2) I'm having to enter longitude data into --Lat and latitude into --Lon .
Any reason why?

3) It hangs   when there is no data , ie 

Hgt2Osm, 26.4.2017, FSofT
64 Bit-OS: ja
Programmodus 64 Bit: ja
MinorDistance:   20
MediumFactor:5
MajorFactor: 5
HGT-Verzeichnis: E:\Dem\All_UK_HGT_Data\
Mergefile:   e:\devonall2.osm
OutputOverwrite: False
Höhenkorrektur:  -0.5
MinVerticePoints:3
MinBoundingbox:  0.0005
Douglas-Peucker: 0.04
1. OSM-ID:   -1
mit OSMBound:False
mit OSMBounds:   True
mit OSMTimestamp:True
mit OSMVersion:  1
mit OSMVisible:  False
max. Punktanzahl je Weg: 500
mit 'contour_ext'-Tag:   True
==> Lese Ausgangsdaten 49° -4° ...
Daten übernehmen ...
Startzeit: 17:13:29
8 Threads
übernehme 1201x1201 Werte für neue Matrix 1201x1201
ungültige Originalwerte: 0 (0.00%)
berechne alle Strecken für Höhenlinien in 144 Rechtecken mit je 4
Dreiecken
...

Laufzeit: 00:00:00
führe alle Strecken je Höhenebene eindeutig in einer Liste zusammen ...

Laufzeit: 00:00:00
0 Höhenebenen von 2147483647 bis -2147483648 mit insgesamt 0 Strecken
gebildet .
..




--
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] How to install maps with DEM onto a GPS

[nwillink]

Hi All

I offer one possible solution for installing a DEM map on a GPS using
Garmin's Mapinstall.
Its not ideal but it works once you take account of the following:

After much frustration, I think I have resolved the problem with Mapinstall.

It seems that Mapinstall ,more often than not,  detects an issue with one of
the files created using mkgmap's -gmapi option.
 I have not tried to work out which one but I can say that ,so far, all
gmaps created using Javawa Mapconverter have formed a successful basis for
uploading dem maps to a gps device.

1) Create your Mapsource/Basecamp map using mkgmap 
Ignore the gmap if created by mkgmap
drag your mapfolder onto Javawa's mapconcerter to create a new gmap - place
this in c:\programdata\garmin\maps


2) I use Franks excellent program to create & add dem files

3) I add DEM file sizes to the .tdb file - I have presumed that all dem file
sizes require a maximum of 4 bytes - I have not encountered files which
require 5 bytes - please let me know if is a DEM file which needs 5 byte.

4) I have not had to add or replace separate bytes in the tdb file to make
it work apart from setting the DEM flag

5) If some maps have no dem then no dem height or ref to a DEM is added to
the tdb 

6) I now use Mapinstall and upload map to my GPS.

This is one solution which now seems to work.

As this is rather long winded, you don't really want to do this each time
you update a map!

 Perhaps we need to look at ways of  creating 'empty' maps with just DEM as
a separate gmapsupp.

examples on Oregon:

Greece :

 

 

 










--
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] a new DEM-File Option

[nwillink]

Hi Frank  

Your superb program works a real treat - What an amazing feat to have more
or less deciphered the DEM sub file . I can now give the whole of the UK a
proper DEM look!

Thanks Gerd for providing us with a script as I would have been completely
lost despite the help file.

Unfortunately I too get this odd comment about mapset approx (42mb) but only
27.8 gig available !

At the moment , I'n not too fussed as DEM files tend to darken the GPS
display , in my opinion.

I tried setting different flags in the tdb but to no avail ! 

I suspect there is a length block issue in the DEM file itself which is
ignored by Basecamp & Mapsource and only used when creating a gmapsupp.

thanks again

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

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

[nwillink]

Hi Gerd

In the UK , frequently public footpaths are linked to someone's driveway - I
have to say it's often quite 'daunting' to walk up someone's drive in order
to continue along a public footpath.

r

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] default style:pier

[nwillink]

Hi
Just an observation :

The default style adds a footway to all piers.

(man_made=pier | man_made=piste:halfpipe) & area!=yes
{add highway=footway; name '${ref} ${name}' | '${ref}' | '${name}' }

I can see why ,particularly with large wide piers like Brighton Pier.
Such piers are relatively rare.

 Unfortunately , the pier tag is too general and can also include a place
for mooring (mooring=yes).

These 'mooring piers' are most commonly not open to the general public ,
their entrance being barred by a gate. 
In an ideal world such piers should have an access restriction.

When I visited Falmouth this summer I thought I was able to walk along all
the piers mapped ; unfortunately, I couldn't.

When I create my 'walking maps' I only add a footway when area=yes or the
pier includes  route=hiking etc relation.
Take Torquay harbour : it looks as if you can do a nice stroll along all
these 'piers'; in reality access is private.

I'm not sure what to do about this other than adding access tags to each
pier.






--
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] How to identify beginning and end of a route?

[nwillink]

Hi Gerd

Brilliant , many thanks !

I use 0x6412 which Garmin has earmarked for its 'trails' .

Great stuff!

Nick


On 18/08/2017 13:35, Gerd Petermann [via GIS] wrote:
> Hi Nick,
>
> not sure what result you need, but this rule in relations sets the tag 
> route_node
> and you can evaluate it in the points file
>
> type=route & (route=bicycle | route = hiking | route=foot)
> {
> apply role=start {
> add route_node=start
> }
> apply role=end {
> add route_node=end
> }
> }
>
> Does that help?
> Gerd
> ____
> Von: mkgmap-dev <[hidden email] 
> > im Auftrag von 
> nwillink <[hidden email] 
> >
> Gesendet: Freitag, 18. August 2017 11:00:21
> An: [hidden email] 
> Betreff: [mkgmap-dev] How to identify beginning and end of a route?
>
> Hi
>
> I read the following:
>
> Matching member roles by regular expression
> Currently, apply role=value is for fixed strings.
>
> I'm not quite sure what 'fixed strings ' means but perhaps it means 
> that the
> unique properties of individual members of a relation cannot be parsed.
>
>
> This is a shame as it would be great to mark the start and end of 
>  cycling /
> hiking routes.
>
> In osm we can mark the start of a route using role="start" ,ie
>
>  
>   
>   
>   
>   
>   
>   
>   
>  
>
> However, I've not been able to capture this node.
>
> I wonder if anyone has an answer?
>
> r
>
> Nick
>
>
>
>
>
>
> -- 
> View this message in context: 
> http://gis.19327.n8.nabble.com/How-to-identify-beginning-and-end-of-a-route-tp5900869.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> ___
> mkgmap-dev mailing list
> [hidden email] 
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> [hidden email] 
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://gis.19327.n8.nabble.com/How-to-identify-beginning-and-end-of-a-route-tp5900869p5900883.html
>  
>
> To unsubscribe from How to identify beginning and end of a route?, 
> click here 
> <http://gis.19327.n8.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5900869&code=b3NtQHBpbm5zLmNvLnVrfDU5MDA4Njl8MTM1NTM3MTE1MQ==>.
> NAML 
> <http://gis.19327.n8.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>  
>





--
View this message in context: 
http://gis.19327.n8.nabble.com/How-to-identify-beginning-and-end-of-a-route-tp5900869p5900892.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] How to identify beginning and end of a route?

[nwillink]

Hi

I read the following:

Matching member roles by regular expression
Currently, apply role=value is for fixed strings.

I'm not quite sure what 'fixed strings ' means but perhaps it means that the
unique properties of individual members of a relation cannot be parsed.


This is a shame as it would be great to mark the start and end of  cycling /
hiking routes.

In osm we can mark the start of a route using role="start" ,ie

 
  
  
  
  
  
  
  
 

However, I've not been able to capture this node.

I wonder if anyone has an answer?

r

Nick






--
View this message in context: 
http://gis.19327.n8.nabble.com/How-to-identify-beginning-and-end-of-a-route-tp5900869.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] NSI error

[nwillink]

Hi Gerd

Many thanks

Great it works !

r

Nick



--
View this message in context: 
http://gis.19327.n8.nabble.com/NSI-error-tp5900070p5900083.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] NSI error

[nwillink]

Thanks Gerd

Yes, I used --overview-mapname="Topo Devon 2017".

I'm afraid I'm no good with patches but will check it out later.

r

Nick



--
View this message in context: 
http://gis.19327.n8.nabble.com/NSI-error-tp5900070p5900075.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] NSI error

[nwillink]

Am using nsi script generated by mkgmap and have noticed that

it doesn't seem to like spaces in a  mapname

ie 

!define MAPNAME "Topo Devon 2017"

the error in red when running the script :

macro "MUI_Page_Licence" requires 1 parameter(s)  passed 3

Presumably it refers to the 3 words separated by a space.

I can't simply change the mapname to "Topo-Devon-2017" as  it  expects some
of the files to be
named in this way as well.

I just wondered if anyone else has found a way around it?

r

Nick




--
View this message in context: 
http://gis.19327.n8.nabble.com/NSI-error-tp5900070.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] Any option to include POIs as ways?

[nwillink]

One way is to extract the barriers your self (perhaps use GPSMapEdit) and
create a line or circle and save it as a separate mp or osm.

I would experiment with barriers near you and judge how effective such lines
would be.

r

Nick 



--
View this message in context: 
http://gis.19327.n8.nabble.com/Any-option-to-include-POIs-as-ways-tp5899742p5899773.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] amenity=restaurant and search index

[nwillink]

Hi Gerd

2a13 is Dining African

r

Nick



--
View this message in context: 
http://gis.19327.n8.nabble.com/amenity-restaurant-and-search-index-tp5895969p5895971.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] TYP decompiler for linux?

[nwillink]

Try TYPviewer at https://sites.google.com/site/sherco40/


On 15/03/2017 12:11, harri-2 [via GIS] wrote:
> So far I've found a bunch of links that are not working and Typwiz 5,
> which is a bit expensive to buy for a single task.
>
> Any pointers to ones I could give a try?
>
> -- 
>
> On 03/15/2017 12:03 PM, Thorsten Kukuk wrote:
>
> > On Tue, Mar 14, Harri Suomalainen wrote:
> >
> >> Is there any tool to decompile typ files in Linux (or some online 
> tool) ? I
> >> seem to find only tools that work on windows. Unfortunately I have no
> >> windows machine available.
> >
> > Most of the TYP file editors for Windows work fine with wine on Linux.
> >
> >   Thorsten
> >
> ___
> mkgmap-dev mailing list
> [hidden email] 
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://gis.19327.n8.nabble.com/Commit-r3842-Improve-ResidentialHook-BoundaryQuadTree-suppress-misleading-warnings-about-overlappings-tp5892891p5893197.html
>  
>
> To unsubscribe from Commit r3842: Improve ResidentialHook / 
> BoundaryQuadTree: suppress misleading warnings about overlapping 
> admin_level=11 boundaries, click here 
> .
> NAML 
> 
>  
>





--
View this message in context: 
http://gis.19327.n8.nabble.com/Commit-r3842-Improve-ResidentialHook-BoundaryQuadTree-suppress-misleading-warnings-about-overlappings-tp5892891p5893206.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] type file and resolutions

[nwillink]

Hi Mike

A TYP file operates independent of any resolution - the current file
structure does not allow for icons to be visible at specific levels although
I must admit that sounds a good idea and it wouldn't add much to the length
of the TYP file itself.

r

Nick



--
View this message in context: 
http://gis.19327.n8.nabble.com/type-file-and-resolutions-tp5893135p5893162.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] Is any mapper using custom Icons, not displaying labels, but still allows GPS to search by labels?

[nwillink]

You can set the icon's extended label to 'nolabel' in your TYP file.

r

Nick



--
View this message in context: 
http://gis.19327.n8.nabble.com/Is-any-mapper-using-custom-Icons-not-displaying-labels-but-still-allows-GPS-to-search-by-labels-tp5893152p5893156.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] Commit r3842: Improve ResidentialHook / BoundaryQuadTree: suppress misleading warnings about overlapping admin_level=11 boundaries

[nwillink]

For me, this has been a much welcomed addition to mkgmap. Thanks Gerd



--
View this message in context: 
http://gis.19327.n8.nabble.com/Commit-r3842-Improve-ResidentialHook-BoundaryQuadTree-suppress-misleading-warnings-about-overlappings-tp5892891p5892909.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] [Patch v1] nwe special tag mkgmap:residential

[nwillink]

Hi Gerd

I've for the time being abandoned the admin_level idea but I'm sure its 
possible - around my area most levels are admin_level 10

I have had various thoughts

1) Some buildings may be more important than others, ie pubs ;) so I've 
been tinkering with excluding them from the residential list -


2) In many ways using a TYP file its very useful to be able to 
distinguish between residential (faint no outline) and non residential 
buildings ( darker with outline)

3) Buildings in industrial / educational areas are still shown, but that 
is not a problem ; I can see a possible use for mkgmap:industrial / 
mkgmap:leisure etc but that may be over the top.

4) Exeter is 'plagued' with buildings and the residential rule seems to 
have excluded them all !

r

Nick


On 05/03/2017 17:00, Gerd Petermann [via GIS] wrote:
> I'd also like to know if it you have an idea how to improve the 
> usability in case that it doesn't work ;-)
>
> Gerd
>
> 
> Von: mkgmap-dev <[hidden email] 
> > im Auftrag von 
> nwillink <[hidden email] 
> >
> Gesendet: Sonntag, 5. März 2017 12:53:04
> An: [hidden email] 
> Betreff: Re: [mkgmap-dev] [Patch v1] nwe special tag mkgmap:residential
>
> Hi Gerd
>
> Thanks for the suggestion - will let you know when successful
>
>
> r
>
>
> Nick
>
> On 05/03/2017 11:43, Gerd Petermann [via GIS] wrote:
> Hi Nick,
>
> maybe you can check mkgmap:admin_level9..11 to decide if an element is 
> in a village?
>
> Gerd
> 
> Von: mkgmap-dev <[hidden 
> email]> im Auftrag von 
> nwillink <[hidden email]>
> Gesendet: Sonntag, 5. März 2017 11:46:56
> An: [hidden email]
> Betreff: Re: [mkgmap-dev] [Patch v1] nwe special tag mkgmap:residential
>
> Ok Gerd
>
> I didn't realise that , no wonder I'm having problems
>
> Thanks for looking into that.
>
> On 05/03/2017 10:44, Gerd Petermann [via GIS] wrote:
> Nick, sorry, I don't get it.
>
> With the patch the value in the new tag mkgmap:residential is 
> evaluated before any style rule is used.
> I see no way for you to pass the information from a node or way with 
> place=village to another element with building=*
>
> Gerd
> 
> Von: mkgmap-dev <[hidden 
> email]> im Auftrag von 
> nwillink <[hidden email]>
> Gesendet: Sonntag, 5. März 2017 11:32:14
> An: [hidden email]
> Betreff: Re: [mkgmap-dev] [Patch v1] nwe special tag mkgmap:residential
>
> Gerd, that is a good point
>
> It was just a thought that since points are parsed first one could 
> perhaps  set a  flag  when place=village is true
>
> then
>
> mkgmap:residiential=* & village=true . --> show buildings
>
>
> So I was not thinking of mkgmap specifically
>
> On 05/03/2017 10:08, Gerd Petermann [via GIS] wrote:
> Please explain what you meant with
> "Perhaps with some coding you could make exceptions for buildings in
> villages/hamlets..."
>
> Would that be code in mkgmap or in your style?
> Gerd
> 
> Von: mkgmap-dev <[hidden 
> email]> im Auftrag von 
> nwillink <[hidden email]>
> Gesendet: Sonntag, 5. März 2017 11:03:56
> An: [hidden email]
> Betreff: Re: [mkgmap-dev] [Patch v1] nwe special tag mkgmap:residential
>
> Ok Thanks
>
> On 05/03/2017 09:34, Gerd Petermann [via GIS] wrote:
> Hi Nick,
>
> hmm, not sure what you want to point out.
> The tag mkgmap:residential may be set to other values than "yes", e.g.
> ways located in
> https://www.openstreetmap.org/way/454954092
> should have mkgmap:residential=Bahnhofsviertel
>
> Gerd
> 
> Von: mkgmap-dev <[hidden 
> email]> im Auftrag von 
> nwillink <[hidden email]>
> Gesendet: Sonntag, 5. März 2017 10:27:03
> An: [hidden email]
> Betreff: Re: [mkgmap-dev] [Patch v1] nwe special tag mkgmap:residential
>
> Thanks Gerd
>
> Works a treat although in my style I had to use
>
> building=* & mkgmap:residential=yes {delete building}
>
> in both polygons and lines (outlines).
>
> Your efforts provide an addiitional  bonus in that you may just want 
> to show
> just the faint outlines of buildings.
>
> Perhaps with some coding you could make exceptions for buildings in
> villages/hamlets...
>
> Nick
>
>
>
>
>
> -- 
> View this message in context: 
> http://gis.19327.n8.nabble.com/Patch-v1-nwe-special-tag-mkgmap-residential-tp5892342p5892424.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> 

Re: [mkgmap-dev] [Patch v1] nwe special tag mkgmap:residential

[nwillink]

Hi Gerd

Thanks for the suggestion - will let you know when successful


r


Nick


On 05/03/2017 11:43, Gerd Petermann [via GIS] wrote:
> Hi Nick,
>
> maybe you can check mkgmap:admin_level9..11 to decide if an element is 
> in a village?
>
> Gerd
> 
> Von: mkgmap-dev <[hidden email] 
> > im Auftrag von 
> nwillink <[hidden email] 
> >
> Gesendet: Sonntag, 5. März 2017 11:46:56
> An: [hidden email] 
> Betreff: Re: [mkgmap-dev] [Patch v1] nwe special tag mkgmap:residential
>
> Ok Gerd
>
> I didn't realise that , no wonder I'm having problems
>
> Thanks for looking into that.
>
> On 05/03/2017 10:44, Gerd Petermann [via GIS] wrote:
> Nick, sorry, I don't get it.
>
> With the patch the value in the new tag mkgmap:residential is 
> evaluated before any style rule is used.
> I see no way for you to pass the information from a node or way with 
> place=village to another element with building=*
>
> Gerd
> 
> Von: mkgmap-dev <[hidden 
> email]> im Auftrag von 
> nwillink <[hidden email]>
> Gesendet: Sonntag, 5. März 2017 11:32:14
> An: [hidden email]
> Betreff: Re: [mkgmap-dev] [Patch v1] nwe special tag mkgmap:residential
>
> Gerd, that is a good point
>
> It was just a thought that since points are parsed first one could 
> perhaps  set a  flag  when place=village is true
>
> then
>
> mkgmap:residiential=* & village=true . --> show buildings
>
>
> So I was not thinking of mkgmap specifically
>
> On 05/03/2017 10:08, Gerd Petermann [via GIS] wrote:
> Please explain what you meant with
> "Perhaps with some coding you could make exceptions for buildings in
> villages/hamlets..."
>
> Would that be code in mkgmap or in your style?
> Gerd
> 
> Von: mkgmap-dev <[hidden 
> email]> im Auftrag von 
> nwillink <[hidden email]>
> Gesendet: Sonntag, 5. März 2017 11:03:56
> An: [hidden email]
> Betreff: Re: [mkgmap-dev] [Patch v1] nwe special tag mkgmap:residential
>
> Ok Thanks
>
> On 05/03/2017 09:34, Gerd Petermann [via GIS] wrote:
> Hi Nick,
>
> hmm, not sure what you want to point out.
> The tag mkgmap:residential may be set to other values than "yes", e.g.
> ways located in
> https://www.openstreetmap.org/way/454954092
> should have mkgmap:residential=Bahnhofsviertel
>
> Gerd
> 
> Von: mkgmap-dev <[hidden 
> email]> im Auftrag von 
> nwillink <[hidden email]>
> Gesendet: Sonntag, 5. März 2017 10:27:03
> An: [hidden email]
> Betreff: Re: [mkgmap-dev] [Patch v1] nwe special tag mkgmap:residential
>
> Thanks Gerd
>
> Works a treat although in my style I had to use
>
> building=* & mkgmap:residential=yes {delete building}
>
> in both polygons and lines (outlines).
>
> Your efforts provide an addiitional  bonus in that you may just want 
> to show
> just the faint outlines of buildings.
>
> Perhaps with some coding you could make exceptions for buildings in
> villages/hamlets...
>
> Nick
>
>
>
>
>
> -- 
> View this message in context: 
> http://gis.19327.n8.nabble.com/Patch-v1-nwe-special-tag-mkgmap-residential-tp5892342p5892424.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> ___
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://gis.19327.n8.nabble.com/Patch-v1-nwe-special-tag-mkgmap-residential-tp5892342p5892425.html
> To unsubscribe from [Patch v1] nwe special tag mkgmap:residential, 
> click here.
> NAML<http://gis.19327.n8.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>  
>
>
>
> 
> View this message in context: Re: [Patch v1] nwe special tag 
> mkgmap:residential<http://gis.19327.n8.nabble.com/Patch-v1-nwe-special-tag-mkgmap-residential-tp5892342p5892426.html>
>  
>
> Sent from the Mkgmap Development mailing list 
>

Re: [mkgmap-dev] [Patch v1] nwe special tag mkgmap:residential

[nwillink]

Ok Gerd

I didn't realise that , no wonder I'm having problems

Thanks for looking into that.


On 05/03/2017 10:44, Gerd Petermann [via GIS] wrote:
> Nick, sorry, I don't get it.
>
> With the patch the value in the new tag mkgmap:residential is 
> evaluated before any style rule is used.
> I see no way for you to pass the information from a node or way with 
> place=village to another element with building=*
>
> Gerd
> 
> Von: mkgmap-dev <[hidden email] 
> > im Auftrag von 
> nwillink <[hidden email] 
> >
> Gesendet: Sonntag, 5. März 2017 11:32:14
> An: [hidden email] 
> Betreff: Re: [mkgmap-dev] [Patch v1] nwe special tag mkgmap:residential
>
> Gerd, that is a good point
>
> It was just a thought that since points are parsed first one could 
> perhaps  set a  flag  when place=village is true
>
> then
>
> mkgmap:residiential=* & village=true . --> show buildings
>
>
> So I was not thinking of mkgmap specifically
>
> On 05/03/2017 10:08, Gerd Petermann [via GIS] wrote:
> Please explain what you meant with
> "Perhaps with some coding you could make exceptions for buildings in
> villages/hamlets..."
>
> Would that be code in mkgmap or in your style?
> Gerd
> 
> Von: mkgmap-dev <[hidden 
> email]> im Auftrag von 
> nwillink <[hidden email]>
> Gesendet: Sonntag, 5. März 2017 11:03:56
> An: [hidden email]
> Betreff: Re: [mkgmap-dev] [Patch v1] nwe special tag mkgmap:residential
>
> Ok Thanks
>
> On 05/03/2017 09:34, Gerd Petermann [via GIS] wrote:
> Hi Nick,
>
> hmm, not sure what you want to point out.
> The tag mkgmap:residential may be set to other values than "yes", e.g.
> ways located in
> https://www.openstreetmap.org/way/454954092
> should have mkgmap:residential=Bahnhofsviertel
>
> Gerd
> 
> Von: mkgmap-dev <[hidden 
> email]> im Auftrag von 
> nwillink <[hidden email]>
> Gesendet: Sonntag, 5. März 2017 10:27:03
> An: [hidden email]
> Betreff: Re: [mkgmap-dev] [Patch v1] nwe special tag mkgmap:residential
>
> Thanks Gerd
>
> Works a treat although in my style I had to use
>
> building=* & mkgmap:residential=yes {delete building}
>
> in both polygons and lines (outlines).
>
> Your efforts provide an addiitional  bonus in that you may just want 
> to show
> just the faint outlines of buildings.
>
> Perhaps with some coding you could make exceptions for buildings in
> villages/hamlets...
>
> Nick
>
>
>
>
>
> -- 
> View this message in context: 
> http://gis.19327.n8.nabble.com/Patch-v1-nwe-special-tag-mkgmap-residential-tp5892342p5892424.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> ___
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://gis.19327.n8.nabble.com/Patch-v1-nwe-special-tag-mkgmap-residential-tp5892342p5892425.html
> To unsubscribe from [Patch v1] nwe special tag mkgmap:residential, 
> click here.
> NAML<http://gis.19327.n8.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>  
>
>
>
> 
> View this message in context: Re: [Patch v1] nwe special tag 
> mkgmap:residential<http://gis.19327.n8.nabble.com/Patch-v1-nwe-special-tag-mkgmap-residential-tp5892342p5892426.html>
>  
>
> Sent from the Mkgmap Development mailing list 
> archive<http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html> 
> at Nabble.com.
> ___
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://gis.19327.n8.nabble.com/Patch-v1-nwe-special-tag-mkgmap-residential-tp5892342p5892427.html
> To unsubscribe from [Patch v1] nwe special tag mkgmap:residential, 
> click here.
&g

Re: [mkgmap-dev] [Patch v1] nwe special tag mkgmap:residential

[nwillink]

Gerd, that is a good point

It was just a thought that since points are parsed first one could 
perhaps  set a  flag  when place=village is true

then

mkgmap:residiential=* & village=true . --> show buildings


So I was not thinking of mkgmap specifically


On 05/03/2017 10:08, Gerd Petermann [via GIS] wrote:
> Please explain what you meant with
> "Perhaps with some coding you could make exceptions for buildings in
> villages/hamlets..."
>
> Would that be code in mkgmap or in your style?
> Gerd
> 
> Von: mkgmap-dev <[hidden email] 
> > im Auftrag von 
> nwillink <[hidden email] 
> >
> Gesendet: Sonntag, 5. März 2017 11:03:56
> An: [hidden email] 
> Betreff: Re: [mkgmap-dev] [Patch v1] nwe special tag mkgmap:residential
>
> Ok Thanks
>
> On 05/03/2017 09:34, Gerd Petermann [via GIS] wrote:
> Hi Nick,
>
> hmm, not sure what you want to point out.
> The tag mkgmap:residential may be set to other values than "yes", e.g.
> ways located in
> https://www.openstreetmap.org/way/454954092
> should have mkgmap:residential=Bahnhofsviertel
>
> Gerd
> 
> Von: mkgmap-dev <[hidden 
> email]> im Auftrag von 
> nwillink <[hidden email]>
> Gesendet: Sonntag, 5. März 2017 10:27:03
> An: [hidden email]
> Betreff: Re: [mkgmap-dev] [Patch v1] nwe special tag mkgmap:residential
>
> Thanks Gerd
>
> Works a treat although in my style I had to use
>
> building=* & mkgmap:residential=yes {delete building}
>
> in both polygons and lines (outlines).
>
> Your efforts provide an addiitional  bonus in that you may just want 
> to show
> just the faint outlines of buildings.
>
> Perhaps with some coding you could make exceptions for buildings in
> villages/hamlets...
>
> Nick
>
>
>
>
>
> -- 
> View this message in context: 
> http://gis.19327.n8.nabble.com/Patch-v1-nwe-special-tag-mkgmap-residential-tp5892342p5892424.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> ___
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://gis.19327.n8.nabble.com/Patch-v1-nwe-special-tag-mkgmap-residential-tp5892342p5892425.html
> To unsubscribe from [Patch v1] nwe special tag mkgmap:residential, 
> click here.
> NAML<http://gis.19327.n8.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>  
>
>
>
> 
> View this message in context: Re: [Patch v1] nwe special tag 
> mkgmap:residential<http://gis.19327.n8.nabble.com/Patch-v1-nwe-special-tag-mkgmap-residential-tp5892342p5892426.html>
>  
>
> Sent from the Mkgmap Development mailing list 
> archive<http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html> 
> at Nabble.com.
> ___
> mkgmap-dev mailing list
> [hidden email] 
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://gis.19327.n8.nabble.com/Patch-v1-nwe-special-tag-mkgmap-residential-tp5892342p5892427.html
>  
>
> To unsubscribe from [Patch v1] nwe special tag mkgmap:residential, 
> click here 
> <http://gis.19327.n8.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5892342&code=b3NtQHBpbm5zLmNvLnVrfDU4OTIzNDJ8MTM1NTM3MTE1MQ==>.
> NAML 
> <http://gis.19327.n8.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>  
>





--
View this message in context: 
http://gis.19327.n8.nabble.com/Patch-v1-nwe-special-tag-mkgmap-residential-tp5892342p5892429.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] [Patch v1] nwe special tag mkgmap:residential

[nwillink]

Ok Thanks


On 05/03/2017 09:34, Gerd Petermann [via GIS] wrote:
> Hi Nick,
>
> hmm, not sure what you want to point out.
> The tag mkgmap:residential may be set to other values than "yes", e.g.
> ways located in
> https://www.openstreetmap.org/way/454954092
> should have mkgmap:residential=Bahnhofsviertel
>
> Gerd
> 
> Von: mkgmap-dev <[hidden email] 
> > im Auftrag von 
> nwillink <[hidden email] 
> >
> Gesendet: Sonntag, 5. März 2017 10:27:03
> An: [hidden email] 
> Betreff: Re: [mkgmap-dev] [Patch v1] nwe special tag mkgmap:residential
>
> Thanks Gerd
>
> Works a treat although in my style I had to use
>
> building=* & mkgmap:residential=yes {delete building}
>
> in both polygons and lines (outlines).
>
> Your efforts provide an addiitional  bonus in that you may just want 
> to show
> just the faint outlines of buildings.
>
> Perhaps with some coding you could make exceptions for buildings in
> villages/hamlets...
>
> Nick
>
>
>
>
>
> -- 
> View this message in context: 
> http://gis.19327.n8.nabble.com/Patch-v1-nwe-special-tag-mkgmap-residential-tp5892342p5892424.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> ___
> mkgmap-dev mailing list
> [hidden email] 
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> [hidden email] 
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://gis.19327.n8.nabble.com/Patch-v1-nwe-special-tag-mkgmap-residential-tp5892342p5892425.html
>  
>
> To unsubscribe from [Patch v1] nwe special tag mkgmap:residential, 
> click here 
> <http://gis.19327.n8.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5892342&code=b3NtQHBpbm5zLmNvLnVrfDU4OTIzNDJ8MTM1NTM3MTE1MQ==>.
> NAML 
> <http://gis.19327.n8.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>  
>





--
View this message in context: 
http://gis.19327.n8.nabble.com/Patch-v1-nwe-special-tag-mkgmap-residential-tp5892342p5892426.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] [Patch v1] nwe special tag mkgmap:residential

[nwillink]

Thanks Gerd

Works a treat although in my style I had to use

building=* & mkgmap:residential=yes {delete building}

in both polygons and lines (outlines).

Your efforts provide an addiitional  bonus in that you may just want to show
just the faint outlines of buildings.

Perhaps with some coding you could make exceptions for buildings in
villages/hamlets...

Nick





--
View this message in context: 
http://gis.19327.n8.nabble.com/Patch-v1-nwe-special-tag-mkgmap-residential-tp5892342p5892424.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] construction as industry?

[nwillink]

Hi Gert

OK I get you.

I hadn't realised that the default style has to be TYP independent.

Yes, without a TYP Garmin doesn't  display the suggested  0x27 on Mapsource.

r

Nick



--
View this message in context: 
http://gis.19327.n8.nabble.com/construction-as-industry-tp5890573p5891040.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] is_in filter

[nwillink]

r Carlos

In my case with Oregons and GPS64  I also rename the gmapsupp.img to defined
the main label.



--
View this message in context: 
http://gis.19327.n8.nabble.com/is-in-filter-tp5890564p5890836.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] is_in filter

[nwillink]

For years now I have been keeping all buildings as a separate transparent
gmapsup /img  giving it a higher priority/draworder then my normal maps - It
has speeded up my daily runs without loss of detail - same could be done for
rivers/streams etc.
As a bonus I can ,if I wanted to, switch off/on buildings on my device, bit
like contours.
I update my buildings.img when necessary.

This is not an answer to the initial problem but it works

r

Nick



--
View this message in context: 
http://gis.19327.n8.nabble.com/is-in-filter-tp5890564p5890793.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] construction as industry?

[nwillink]

Hi Gert

I fully agree with you :

The following are mere suggestions but taken from the mapnik.typ which takes
into account Garmin's reserved   type numbers  and seem  not clash with
known type numbers.

quarry : 0x12
power=station | power=sub_station:0x25
commercial: 0x26
construction:0x27
landfill : 0x2a

hth
Nick





--
View this message in context: 
http://gis.19327.n8.nabble.com/construction-as-industry-tp5890573p5890643.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] construction as industry?

[nwillink]

Hi

I just realised that in the default polygon style  construction, whether its
residential or industrial , is always defined as industrial 0x0c.

I understand the' logic' , in that there are many 'mobile' industries
constructing residential or industrial buildings.

In my city there are numerous large construction sites, all of them
constructing residential housing.
If I were unknown to the city and plan a route through an industrial area I
would expect to find  the following  :

a) industrial blocks / units / working businesses
b) roads entering and crossing industrial areas  safe from
barriers,fencing,cones,mud-sweepers,grumpiness or foremen etc

Personally I would provide a separate polygon , ie 0x27 perhaps

Just a thought.

Nick




--
View this message in context: 
http://gis.19327.n8.nabble.com/construction-as-industry-tp5890573.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] metres to fee issue with mp contour files

[nwillink]

Thanks Carlos;  I haven't but will try it out when I have more time


On 09/11/2016 22:01, Carlos Dávila-2 [via GIS] wrote:
> El 09/11/16 a las 22:50, nwillink escribió:
>
> > Hi Gerd
> >
> > I realise this has been discussed before but I certainly have been
> > unable to convert m to ft in contour mps created by Groundtruth.
> >
> > It seems mkgmap ignores *Elevation=m* and presumes numerical data, ie
> > label=50 refers to feet by default.
> >
> > As a result Basecamp /always / treats the resulting img as 
> containing feet
> > data which when converted to metric is never rounded off to the 
> nearest 10.
> >
> > An example of a contour mp containic metric data can be found  here
> > <http://www.pinns.co.uk/osm/bits/12345678.mp>
> >
> > Its not urgent as I can use srtm2osm which works fine although it's 
> slower.
> >
> > Thanks
> >
> > Nick
> Have you tried phyghtmap?
> ___
> mkgmap-dev mailing list
> [hidden email] 
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://gis.19327.n8.nabble.com/metres-to-feet-issue-with-mp-contour-files-tp5885681p5885682.html
>  
>
> To unsubscribe from metres to feet issue with mp contour files, click 
> here 
> <http://gis.19327.n8.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5885681&code=b3NtQHBpbm5zLmNvLnVrfDU4ODU2ODF8MTM1NTM3MTE1MQ==>.
> NAML 
> <http://gis.19327.n8.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>  
>





--
View this message in context: 
http://gis.19327.n8.nabble.com/metres-to-feet-issue-with-mp-contour-files-tp5885681p5885683.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] metres to fee issue with mp contour files

[nwillink]

Hi Gerd

I realise this has been discussed before but I certainly have been
unable to convert m to ft in contour mps created by Groundtruth.

It seems mkgmap ignores *Elevation=m* and presumes numerical data, ie
label=50 refers to feet by default.

As a result Basecamp /always / treats the resulting img as containing feet
data which when converted to metric is never rounded off to the nearest 10.

An example of a contour mp containic metric data can be found  here
  

Its not urgent as I can use srtm2osm which works fine although it's slower.

Thanks

Nick





--
View this message in context: 
http://gis.19327.n8.nabble.com/metres-to-fee-issue-with-mp-contour-files-tp5885681.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] Spurious points & Basecamp blank tiles

[nwillink]

This is not a mkgmap error but clearly points to a type number Basecamp
objects to.
 

Perhaps your 0x30 in lines?



--
View this message in context: 
http://gis.19327.n8.nabble.com/Spurious-points-Basecamp-blank-tiles-tp5885434p5885528.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] patch to write polygons in decreasing order

[nwillink]

Having examined a 'blue' map more closely the polygon type structure is more
complicated:

My blue map of the Southwest coast of England  only uses extended types: ie

Here are some of the polygons:

0x10104 base map similar to 0x4a or 0x4b (Interestingly I can't detect any
4a or 4b)

0x10101 = land

0x10301 = intertidal (green)

0x10302 0x10304 -0x10305 depth areas (shades of blue)

0x10409 Danger Area

0x10507 tidal area 

etc

As stated earlier TYP files have no effect on colour nor draworder.
I looks like the imgs contain (GMP) tiles and in this respect are similar to
Garmin GB Discoverer maps etc



--
View this message in context: 
http://gis.19327.n8.nabble.com/patch-to-write-polygons-in-decreasing-order-tp5884038p5885110.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] patch to write polygons in decreasing order

[nwillink]

OK

Point taken.

There is a mystery about some if not most TOPO TYP files containing
draworders which are not linked to polygon . 

Either they are left overs, which is very unusual, or they imply another
purpose as yet undefined - the word container was used to describe such
draworders but its unclear what they are grouping.



--
View this message in context: 
http://gis.19327.n8.nabble.com/patch-to-write-polygons-in-decreasing-order-tp5884038p5884816.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] patch to write polygons in decreasing order

[nwillink]

Just an observation.

To me it only makes sense to order polygons if the user is not using a TYP
file.

TYP files effectively attribute a draworder to different types of polygons.

Sorting polygons into size will work if the user has plotted two polygons of
the same type, ie buildings on top of buildings - which is very unusual to
say the least

It is true that some 'old' non NT Garmin TOPO maps came with a TYP file
which did not give polygons a draworder - indeed, you could quickly mess up
the layers by giving one or two polygons a draworder.



--
View this message in context: 
http://gis.19327.n8.nabble.com/patch-to-write-polygons-in-decreasing-order-tp5884038p5884813.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] inner sections of a multipolygon

[nwillink]

Thanks Gerd

Never knew this !



--
View this message in context: 
http://gis.19327.n5.nabble.com/inner-sections-of-a-multipolygon-tp5879576p5879594.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] inner sections of a multipolygon

[nwillink]

Hi Gary

Have a look at Enabling Debugging

http://wiki.openstreetmap.org/wiki/Mkgmap/dev

Nick


On 01/08/2016 12:51, Gary Bamford [via GIS] wrote:
>
> what is it then ?
>
>
> Regards
>
>
> Gary
>
>
>
> 
> *From:* mkgmap-dev <[hidden email] 
> > on behalf of 
> nwillink <[hidden email] >
> *Sent:* 01 August 2016 11:44
> *To:* [hidden email] 
> *Subject:* Re: [mkgmap-dev] inner sections of a multipolygon
>
> Hi Gerd
>
>
> I found it !
>
>
> Many thanks
>
>
> On 01/08/2016 12:35, Gerd Petermann [via GIS] wrote:
>>
>> Hi Nick,
>>
>>
>> I think mkgmp can write a lot of messages for wrong multipolygons
>>
>> into the log. You have to activate logging to see them.
>>
>>
>> Gerd
>>
>> 
>> *Von:* mkgmap-dev <[hidden email] 
>> > im Auftrag von 
>> nwillink <[hidden email] 
>> >
>> *Gesendet:* Montag, 1. August 2016 13:26:52
>> *An:* [hidden email] 
>> *Betreff:* Re: [mkgmap-dev] inner sections of a multipolygon
>> Thanks Thomas for your detailed reply.
>>
>> Would be very useful to have such polygons reported.
>>
>> Nick
>>
>>
>>
>> --
>> View this message in context: 
>> http://gis.19327.n5.nabble.com/inner-sections-of-a-multipolygon-tp5879576p5879581.html
>> Sent from the Mkgmap Development mailing list archive at Nabble.com.
>> ___
>> mkgmap-dev mailing list
>> [hidden email] 
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>> ___
>> mkgmap-dev mailing list
>> [hidden email] 
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>> 
>> If you reply to this email, your message will be added to the 
>> discussion below:
>> http://gis.19327.n5.nabble.com/inner-sections-of-a-multipolygon-tp5879576p5879584.html
>>  
>>
>> To unsubscribe from inner sections of a multipolygon, click here.
>> NAML 
>> <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>  
>>
>
>
> 
> View this message in context: Re: inner sections of a multipolygon 
> <http://gis.19327.n5.nabble.com/inner-sections-of-a-multipolygon-tp5879576p5879587.html>
> Sent from the Mkgmap Development mailing list archive 
> <http://gis.19327.n5.nabble.com/Mkgmap-Development-f5324443.html> at 
> Nabble.com.
>
> ___
> mkgmap-dev mailing list
> [hidden email] 
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://gis.19327.n5.nabble.com/inner-sections-of-a-multipolygon-tp5879576p5879591.html
>  
>
> To unsubscribe from inner sections of a multipolygon, click here 
> <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5879576&code=b3NtQHBpbm5zLmNvLnVrfDU4Nzk1NzZ8MTM1NTM3MTE1MQ==>.
> NAML 
> <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>  
>





--
View this message in context: 
http://gis.19327.n5.nabble.com/inner-sections-of-a-multipolygon-tp5879576p5879593.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] inner sections of a multipolygon

[nwillink]

Hi Gerd


I found it !


Many thanks


On 01/08/2016 12:35, Gerd Petermann [via GIS] wrote:
>
> Hi Nick,
>
>
> I think mkgmp can write a lot of messages for wrong multipolygons
>
> into the log. You have to activate logging to see them.
>
>
> Gerd
>
> 
> *Von:* mkgmap-dev <[hidden email] 
> > im Auftrag von 
> nwillink <[hidden email] >
> *Gesendet:* Montag, 1. August 2016 13:26:52
> *An:* [hidden email] 
> *Betreff:* Re: [mkgmap-dev] inner sections of a multipolygon
> Thanks Thomas for your detailed reply.
>
> Would be very useful to have such polygons reported.
>
> Nick
>
>
>
> --
> View this message in context: 
> http://gis.19327.n5.nabble.com/inner-sections-of-a-multipolygon-tp5879576p5879581.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> ___
> mkgmap-dev mailing list
> [hidden email] 
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
> ___
> mkgmap-dev mailing list
> [hidden email] 
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://gis.19327.n5.nabble.com/inner-sections-of-a-multipolygon-tp5879576p5879584.html
>  
>
> To unsubscribe from inner sections of a multipolygon, click here 
> <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5879576&code=b3NtQHBpbm5zLmNvLnVrfDU4Nzk1NzZ8MTM1NTM3MTE1MQ==>.
> NAML 
> <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>  
>





--
View this message in context: 
http://gis.19327.n5.nabble.com/inner-sections-of-a-multipolygon-tp5879576p5879587.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] inner sections of a multipolygon

[nwillink]

Hi Gerd

Could you give me a hint as to how I can activate logging?


Thanks for your quick answer

Nick
On 01/08/2016 12:35, Gerd Petermann [via GIS] wrote:
>
> Hi Nick,
>
>
> I think mkgmp can write a lot of messages for wrong multipolygons
>
> into the log. You have to activate logging to see them.
>
>
> Gerd
>
> 
> *Von:* mkgmap-dev <[hidden email] 
> > im Auftrag von 
> nwillink <[hidden email] >
> *Gesendet:* Montag, 1. August 2016 13:26:52
> *An:* [hidden email] 
> *Betreff:* Re: [mkgmap-dev] inner sections of a multipolygon
> Thanks Thomas for your detailed reply.
>
> Would be very useful to have such polygons reported.
>
> Nick
>
>
>
> --
> View this message in context: 
> http://gis.19327.n5.nabble.com/inner-sections-of-a-multipolygon-tp5879576p5879581.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> ___
> mkgmap-dev mailing list
> [hidden email] 
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
> ___
> mkgmap-dev mailing list
> [hidden email] 
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://gis.19327.n5.nabble.com/inner-sections-of-a-multipolygon-tp5879576p5879584.html
>  
>
> To unsubscribe from inner sections of a multipolygon, click here 
> <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5879576&code=b3NtQHBpbm5zLmNvLnVrfDU4Nzk1NzZ8MTM1NTM3MTE1MQ==>.
> NAML 
> <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>  
>





--
View this message in context: 
http://gis.19327.n5.nabble.com/inner-sections-of-a-multipolygon-tp5879576p5879585.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] inner sections of a multipolygon

[nwillink]

Thanks Thomas for your detailed reply.

Would be very useful to have such polygons reported.

Nick



--
View this message in context: 
http://gis.19327.n5.nabble.com/inner-sections-of-a-multipolygon-tp5879576p5879581.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] inner sections of a multipolygon

[nwillink]

Hi

Is there any reason why mkgmap only creates the inner sections of a
multipolygon 

if the tags of the outer polygon get transferred to the relation.

ie 

Once you add a multipolygon relation to say an existing forest and making it
outer, any inner sections created don't show up unless :

the landuse=forest gets removed from the polygon and added to the relation.

The problem seems to me that some/many multipolygons have been created by
those not using mkgmap.

Just an observation ; perhaps this has been discussed before.

Nick



--
View this message in context: 
http://gis.19327.n5.nabble.com/inner-sections-of-a-multipolygon-tp5879576.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] Problems with routing on Etrek 20 with latest firmware

[nwillink]

2) "Route calculation error"; 

3) "The route does not match the available maps. Cannot follow the roads 
precisely. Do you want to recalculate the the route?" Choosing [Yes] 
gives "Route calculation error. Maps do not have routable roads in this 
area." 

I ALWAYS  get this on my Oregon 450 and GPS64 when I have updated my map.

ie 

1) I have previously routed from A to B using map M1
2) I update my gmapsupp to map M2
3) I switch on and select Recent Finds (or something like that) and click on
the route which I created with map M1

I narrowed down the problem to the fact that map M1 and M2 have different
map IDs and for reasons unknown but time will tell routes are linked to a
specific map.

I can still use the shortcut but have to move my cursor  to a slightly
different place and press GO.




--
View this message in context: 
http://gis.19327.n5.nabble.com/Problems-with-routing-on-Etrek-20-with-latest-firmware-tp5879373p5879388.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] Tool to dump index?

[nwillink]

Hi ThorstenI've noticed that pois are only searchable in mapsource if they
appear in the mdr.img file.The categories are directly linked to the
occurence of a poi type in the mdr subfile.This may not be what you are
looking for but I'm examining the mdr structure myself and have written a
small binary tool to extract the pois ( not addresses); it only reads NT and
non NT mdr.img files.  http://www.pinns.co.uk/osm/bits/mdr_pois.zip
  Interestingly,a) TOPOs only
seem to include pois with 1400+ rangeb) There is another byte attached to
each indexed poi  - mkgmap seems to set it to 0 - No idea what it does but I
have seen values 1-16 elsewhere.Nick



--
View this message in context: 
http://gis.19327.n5.nabble.com/Tool-to-dump-index-tp5877646p5878725.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] [Patch v1] improve LinePreparer to reduce img size

[nwillink]

Hi Gerd

Many thanks for this brilliant and indeed crystal clear explanation!

I now understand when the trick is no longer feasible.

Ever considered producing  a supplement to Mechalas' great achievement?I'm
sure there
is a great demand for it.

Will now do some testing.

Thanks again

Nick



--
View this message in context: 
http://gis.19327.n5.nabble.com/Patch-v1-improve-LinePreparer-to-reduce-img-size-tp5878545p5878624.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] [Patch v1] improve LinePreparer to reduce img size

[nwillink]

Many thanks for that Gerd

I hope this makes it a bit clearer? 

The adjective 'crystal' does not immediately spring to mind but I understand
what
you are getting at.

Presumably the patch now checks every line for the need to apply the trick.




--
View this message in context: 
http://gis.19327.n5.nabble.com/Patch-v1-improve-LinePreparer-to-reduce-img-size-tp5878545p5878569.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] [Patch v1] improve LinePreparer to reduce img size

[nwillink]

Hi Gerd

What an amazing achievement!

I noticed that cgpsmapper and MapTK already use this 'trick' for rivers etc 
but not mkgmap - this actually made it easier to unravel mkgmap's lines.

As a matter of interest how long does a delta need to be for it to be
treated as a special case?

r

Nick



--
View this message in context: 
http://gis.19327.n5.nabble.com/Patch-v1-improve-LinePreparer-to-reduce-img-size-tp5878545p5878561.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] osmc:symbol

[nwillink]

I'm not aware of any documentation about layering POIs but perhaps consider
these points

a) TYP files can not define a POIs draworder, unlike polygons.

b) There is no guaranteed way of ensuring POI1 always has a higher order
than POI2 - this depends on your Garmin device

However, there is still room for experimentation:

osmc symbols define a foreground and background, ie

background: blue

foreground: yellow diamond

For the level approach to work the background can't be solid but only a
frame with a transparent centre and

all foreground symbols need to fit inside the frame and have the same
dimensions as a background poi

# catch all osmc:symbols and split them into background and foregrounds

#plot backgrounds first

background=blue {0 x  1200a resolution 24 continue) # must use continue

#plot foregrounds last

foreground= yellow_diamond  [0 x  1201a resolution 24)

etc

The level approach is probably best suited for spurious symbols like
arches,wheels or hikers



--
View this message in context: 
http://gis.19327.n5.nabble.com/Re-osmc-symbol-tp5875693p5875742.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] osmc:symbol

[nwillink]

Garmin's img format (unfortunately) only caters for highway shields.

You would therefore be asking mkgmap to generate a TYP file for any osmc
symbols it encounters.

In theory, this should not be a problem but you would still have to merge it
with your own TYP file and deal with any conflict of type numbers - again,
this could be possible.

I've had to create a style file which caters for most eventualities , both
in POIs and Lines.

You could reduce the number of pois by using a layering system with pois
plotted on top of each other using transparency.

Interestingly,  Waymarked Trail Hiking
   has had to make
some compromises when generating its symbols.






--
View this message in context: 
http://gis.19327.n5.nabble.com/Re-osmc-symbol-tp5875693p5875717.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] How do I transform the name of all Ways?

[nwillink]

You may also like to read 

How to replace Road with Rd , Street with St etc

from

Tricks with mkgmap Styles 3.pdf

on 

http://www.pinns.co.uk/osm/styleideas.html



--
View this message in context: 
http://gis.19327.n5.nabble.com/How-do-I-transform-the-name-of-all-Ways-tp5875326p5875336.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] Map Background Colour

[nwillink]

Following on from what Popej wrote, 
set 4b to 1 or 0 and the rest to values higher than 1



--
View this message in context: 
http://gis.19327.n5.nabble.com/Map-Background-Colour-tp5872127p5872161.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] Typ Files

[nwillink]

 The TYP carriage return  only works for elements which haven't been named in
a style sheet.

This is because a TYP file's text gets ignored if an element points to a
label in the LBL. 

I also suspect that carriage return characters cannot be inserted when
naming elements,due to the way mkgmaps' labels are parsed -  although Steve
should know.

So, unless you create your own 'maps' (not based on osm) ,assign a unique
type number to your polygon & add your label with carriage returns to the
TYP file, I don't think it will work.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Typ-Files-tp5871142p5871365.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] Typ Files

[nwillink]

Hi

A very good question and had to check it myself.

The answer is yes ... but Basecamp & Mapsource respond differently.

You can , it seems,  insert a carriage return but the tooltiptext (bubble)
in Basecamp will only be one line
which means the rest of the text will appear below . Interestingly, it
automatically places the first letter in Ucase and the rest in lower case.

Mapsource no problem.

This begs the question : will it work on your Garmin device?
TYP_with_carriage-return.zip
  




--
View this message in context: 
http://gis.19327.n5.nabble.com/Typ-Files-tp5871142p5871343.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] Oneway 1 or -1 BUG?

[nwillink]

Hi Gerd

Many thanks

You are right,  have just checked: mkgmap cleverly parses oneway=-1 and
oneway=1 correctly.
ie I can use the same type for both!
'Logically', it is not what you expect.

r

Nick



--
View this message in context: 
http://gis.19327.n5.nabble.com/Oneway-1-or-1-BUG-tp5869847p5869862.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] Oneway 1 or -1 BUG?

[nwillink]

I have a suspicion that mkgmap quite understandably (!) parses oneway=-1 as
oneway=yes and oneway=1 as reverse (ie arrows reversed) .

However, for some unknown reason , osm defines oneway=-1 as meaning 'reverse
arrows' and uses oneway=1 to mean 'oneway=yes'.

In other words, mkgmap , when parsing lines,creates the opposite effect to
what is implied in osm.

This matters when you create a separate line  types for each condition.

Not a problem , just a small observation.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Oneway-1-or-1-BUG-tp5869847.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] Oneway arrows

[nwillink]

Ligfietser is correct about non bitmap lines generally having superior
draworder to bitmap lines.
Again, the behaviour of lines is determined by your device ,not Mapsource or
Bascemap.

One sure way of getting arrows to appear in the center is by creating
a) a  bmp line for oneway=yes etc
b) an invisible BUT  routable line for the same stretch.

say residential:

0x6 (make invisible and routable) and add continue
if no one way (oneway!=*)   then 0x10600 (residential) 
if one way (oneway=* & oneway!=no )   then 0x10601 (residential withy arrow
in middle) 



--
View this message in context: 
http://gis.19327.n5.nabble.com/Oneway-arrows-tp5869090p5869321.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] Anyone determine which linetypes are NOT visable in BaseCamp?

[nwillink]

When lines etc in a TYP file are not rendered correctly in Basecamp/Mapsource
then

if some lines in the TYP file are shown correctly but others not, part of
the TYP file is corrupt.

If none of them are shown correctly, the FID and PID do not match those used
by the IMGs /gemapsupp.
This happens when you try to replace a TYP file without checking and
matching the FIDs etc.





--
View this message in context: 
http://gis.19327.n5.nabble.com/Anyone-determine-which-linetypes-are-NOT-visable-in-BaseCamp-tp5868446p5868767.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] don't route through highway=construction

[nwillink]

I would personally assign highway=construction a non routable type, ie
0x10100
This works for me



--
View this message in context: 
http://gis.19327.n5.nabble.com/don-t-route-through-highway-construction-tp5856734p5856776.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] custom typ files

[nwillink]

mapuploader3 has a tool that creates TYP files from any style



--
View this message in context: 
http://gis.19327.n5.nabble.com/custom-typ-files-tp5855127p5855128.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] GUI for POI Search TYPES

[nwillink]

Hi Gert

It makes sense

Nick

On 07/06/2015 15:07, GerdP [via GIS] wrote:
> Hi all,
>
> With r3614 I've updated the built-in generator to my current knowledge 
> about
> valid types.
>
> Simple usage:
> java -jar mkgmap.jar --tdbfile test-map:all-elements
> java -jar mkgmap.jar --index --gmapsupp test-map:all-elements
>
> Further options:
>  * Instructions for use:  If you run this program with the environment
>  * variables BASE_LAT and BASE_LONG set to something just SW of where you
>  * are then the map generated will be located near where you are. 
>  Otherwise
>  * the default location is at (51.7, 0.24).
>
> @Nick:
> Sorry, I forgot about this feature in mkgmap. I think it does
> now all that we need. Do you agree?
>
> Gerd
>
> GerdP wrote
> Hi all,
>
> nwillink wrote
> 2) Why there's a dependency on mkgmap r3612 ?
>
> It will work with previous mkgmaps but not 100% - I'm not
> quite sure
> what the issue was
>
> the problem was that mkgmap uses the rounded Garmin coordinates
> to calculate the tile boundaries, but later used high precision
> coordinates
> to test if the POI is within the boundary. With r3612 the tile
> boundary
> is enlarged by one unit when the high-prec value max was rounded
> down.
>
> Gerd
>
>
>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://gis.19327.n5.nabble.com/GUI-for-POI-Search-TYPES-tp5847360p5847443.html
>  
>
> To unsubscribe from GUI for POI Search TYPES, click here 
> <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5847360&code=b3NtQHBpbm5zLmNvLnVrfDU4NDczNjB8MTM1NTM3MTE1MQ==>.
> NAML 
> <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>  
>



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus




--
View this message in context: 
http://gis.19327.n5.nabble.com/GUI-for-POI-Search-TYPES-tp5847360p5847451.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] GUI for POI Search TYPES

[nwillink]

Hi Paco

1)

It does not create an osm file but an mp file.
a) The program creates an img displaying ALL types and subtypes. The 
default style only uses a small number of pois
It is meant to quickly test your device for any pois indexed or not and 
under which Garmin category

ie

When loading it onto your device you can find out

a) which types numbers correspond to which Garmin category
b) which other pois fall into the same Garmin category
c) which new categories suddenlyt appear on your device !, ie Book 
stores etc
d) which pois on your device are not indexed - Minko recently mentioned 
0x2b05 for camp_site not being shown on some devices

  It helps you when you want to show say different icons for different 
fuel operators AND make them searchable

2) Why there's a dependency on mkgmap r3612 ?

It will work with previous mkgmaps but not 100% - I'm not quite sure 
what the issue was

HTH

Nick

On 07/06/2015 09:40, Paco Tyson [via GIS] wrote:
> Hi everyone,
>
> I can't run this software and I'm wondering what it does exactly.
> I understand that it creates an OSM file of a grid of all POI types in 
> a specified range. Then you can run mkgmap to generate a Garmin map 
> from this source file.
>
> If that's true,
> 1) mkgmap.jar produces a map of all POIs in a grid pattern when called 
> without any argument. How does POI-tester compares to that ?
> 2) Why there's a dependency on mkgmap r3612 ?
>
>
> Thanks,
> Paco
> ___
> mkgmap-dev mailing list
> [hidden email] 
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://gis.19327.n5.nabble.com/GUI-for-POI-Search-TYPES-tp5847360p5847419.html
>  
>
> To unsubscribe from GUI for POI Search TYPES, click here 
> .
> NAML 
> 
>  
>



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus




--
View this message in context: 
http://gis.19327.n5.nabble.com/GUI-for-POI-Search-TYPES-tp5847360p5847426.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] GUI for POI Search TYPES

[nwillink]

Hi Bernd

Thanks for that
Because of this tool I realised my doctors are under Other --> Personal 
services

NUVI CN NAV maps have 11014 (2f14) as social and medical services

Nick

On 07/06/2015 08:24, Bernd Weigelt [via GIS] wrote:
> Hi Nick
>
>
> Thank you for long time missed tools.
>
> It's very interessting to see. how much hidden POI groups are 
> implemented on
> the different devices. Five kind of bar/nightclub on a Oregon 650, but no
> special category for dentists or other doctors ;-)
>
>
> Bernd
>
>
>
> Am Samstag, 6. Juni 2015, 22:26:43 schrieb nwillink:
>
> > Hi Gerd
> >
> > I realised I used 3602 not 3612 so now its working ; many thanks for
> > burning the midnight oil!
> > Have rewritten webpage as well.
> >
> > best regards
> >
> > Nick
> >
> >
> > ---
> > This email has been checked for viruses by Avast antivirus software.
> > https://www.avast.com/antivirus
> >
> >
> >
> >
> >
> > --
> > View this message in context:
> > 
> http://gis.19327.n5.nabble.com/GUI-for-POI-Search-TYPES-tp5847360p5847407.h
> > tml Sent from the Mkgmap Development mailing list archive at 
> Nabble.com.
>
> -- 
> amarok2 now playing:
>
>
>
>
> ___
> mkgmap-dev mailing list
> [hidden email] 
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://gis.19327.n5.nabble.com/GUI-for-POI-Search-TYPES-tp5847360p5847411.html
>  
>
> To unsubscribe from GUI for POI Search TYPES, click here 
> <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5847360&code=b3NtQHBpbm5zLmNvLnVrfDU4NDczNjB8MTM1NTM3MTE1MQ==>.
> NAML 
> <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>  
>



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus




--
View this message in context: 
http://gis.19327.n5.nabble.com/GUI-for-POI-Search-TYPES-tp5847360p5847417.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] GUI for POI Search TYPES

[nwillink]

Hi Henning

Thanks for that will correct that.

Nick

On 07/06/2015 08:58, osm-8 [via GIS] wrote:
> Hi Nick,
>
> thanks for the useful tool! Just a hint to your web-page. There is a
> blank to much in the command line for Basecamp between -- and tdbfile.
>
> Henning
>
> ___
> mkgmap-dev mailing list
> [hidden email] 
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://gis.19327.n5.nabble.com/GUI-for-POI-Search-TYPES-tp5847360p5847415.html
>  
>
> To unsubscribe from GUI for POI Search TYPES, click here 
> .
> NAML 
> 
>  
>



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus




--
View this message in context: 
http://gis.19327.n5.nabble.com/GUI-for-POI-Search-TYPES-tp5847360p5847416.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] GUI for POI Search TYPES

[nwillink]

Hi Gerd

I realised I used 3602 not 3612 so now its working ; many thanks for 
burning the midnight oil!
Have rewritten webpage as well.

best regards

Nick


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus





--
View this message in context: 
http://gis.19327.n5.nabble.com/GUI-for-POI-Search-TYPES-tp5847360p5847407.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] GUI for POI Search TYPES

[nwillink]

Hi Gerd

Strange, but I'm glad its working for you

I use
java -Xmx1024m -ea -jar C:\A_UPL2~1\MKGMAP~1\MK0360~1\mkgmap.jar 
--tdbfile K:\a_poit\pois.mp
pause

Couldn't remember how to uploads to mkggmap site so put pois.mp on

www.pinns.co.uk/osm/bits/pois.zip

Nick

On 06/06/2015 21:34, GerdP [via GIS] wrote:
> Hi Nick,
>
> The program works for me.
>
> Please let me know your options in POI Tester
> and send a link to your *.mp file.
>
> Gerd
>
> nwillink wrote
> Hi Gerd
>
> I'm afraid not ; have just tried latest mkgmap and still get the
> border
> pois with
>
> SEVERE (MapArea): K:\A_POIT~1\pois.mp: Point with type 0x2a00 at
> http://www.openstreetmap.org/?mlat=50.024300&mlon=9.976801&zoom=17 is
> outside of the map area centred on
> http://www.openstreetmap.org/?mlat=49.801090&mlon=10.588803&zoom=17
> width = 57042 height = 20803 resolution = 24
>
> Strangely , it always  refers to zoom=17 eventhough this was not
> specified in the mp file.
>
> Nick
>
> On 06/06/2015 20:19, GerdP [via GIS] wrote:
> > Hi Nick,
> >
> > I think the problem in mkgmap is fixed with r3612.
> >
> > Gerd
> >
> > > Date: Sat, 6 Jun 2015 10:35:08 -0700
> >
> > > From: [hidden email]
> 
> > > To: [hidden email]
> 
> > > Subject: Re: [mkgmap-dev] GUI for POI Search TYPES
> > >
> > > Hi Gerd
> > >
> > > Did not check for decimal commas ; latest 1.01 resolves this,
> I hope
> > ,though
> > > I have no idea
> > > if it involves a higher asci .
> > >
> > > However, I find this still does not resolve the problem. ( even
> > replacing
> > > the , with a .)
> > >
> > >
> > > r
> > >
> > > Nick
> > >
> > >
> > >
> > > --
> > > View this message in context:
> >
> 
> http://gis.19327.n5.nabble.com/GUI-for-POI-Search-TYPES-tp5847360p5847364.html
> > > Sent from the Mkgmap Development mailing list archive at
> Nabble.com.
> > > ___
> > > mkgmap-dev mailing list
> > > [hidden email] 
> > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >
> > ___
> > mkgmap-dev mailing list
> > [hidden email] 
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >
> >
> 
>
> > If you reply to this email, your message will be added to the
> > discussion below:
> >
> 
> http://gis.19327.n5.nabble.com/GUI-for-POI-Search-TYPES-tp5847360p5847374.html
>
> >
> > To unsubscribe from GUI for POI Search TYPES, click here
> >
> 
> <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5847360&code=b3NtQHBpbm5zLmNvLnVrfDU4NDczNjB8MTM1NTM3MTE1MQ==>
> 
> <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5847360&code=b3NtQHBpbm5zLmNvLnVrfDU4NDczNjB8MTM1NTM3MTE1MQ==%3E>.
>
> > NAML
> >
> 
> <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
> 
> <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml%3E>
>
> >
>
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://gis.19327.n5.nabble.com/GUI-for-POI-Search-TYPES-tp5847360p5847378.html
>  
>
> To unsubscribe from GUI for POI Se

Re: [mkgmap-dev] GUI for POI Search TYPES

[nwillink]

Hi Gerd

I'm afraid not ; have just tried latest mkgmap and still get the border 
pois with

SEVERE (MapArea): K:\A_POIT~1\pois.mp: Point with type 0x2a00 at 
http://www.openstreetmap.org/?mlat=50.024300&mlon=9.976801&zoom=17 is 
outside of the map area centred on 
http://www.openstreetmap.org/?mlat=49.801090&mlon=10.588803&zoom=17 
width = 57042 height = 20803 resolution = 24

Strangely , it always  refers to zoom=17 eventhough this was not 
specified in the mp file.

Nick

On 06/06/2015 20:19, GerdP [via GIS] wrote:
> Hi Nick,
>
> I think the problem in mkgmap is fixed with r3612.
>
> Gerd
>
> > Date: Sat, 6 Jun 2015 10:35:08 -0700
>
> > From: [hidden email] 
> > To: [hidden email] 
> > Subject: Re: [mkgmap-dev] GUI for POI Search TYPES
> >
> > Hi Gerd
> >
> > Did not check for decimal commas ; latest 1.01 resolves this, I hope 
> ,though
> > I have no idea
> > if it involves a higher asci .
> >
> > However, I find this still does not resolve the problem. ( even 
> replacing
> > the , with a .)
> >
> >
> > r
> >
> > Nick
> >
> >
> >
> > --
> > View this message in context: 
> http://gis.19327.n5.nabble.com/GUI-for-POI-Search-TYPES-tp5847360p5847364.html
> > Sent from the Mkgmap Development mailing list archive at Nabble.com.
> > ___
> > mkgmap-dev mailing list
> > [hidden email] 
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
> ___
> mkgmap-dev mailing list
> [hidden email] 
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://gis.19327.n5.nabble.com/GUI-for-POI-Search-TYPES-tp5847360p5847374.html
>  
>
> To unsubscribe from GUI for POI Search TYPES, click here 
> .
> NAML 
> 
>  
>



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus




--
View this message in context: 
http://gis.19327.n5.nabble.com/GUI-for-POI-Search-TYPES-tp5847360p5847377.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] GUI for POI Search TYPES

[nwillink]

Hi Gerd

Did not check for decimal commas ; latest 1.01 resolves this, I hope ,though
I have no idea
if it involves a higher asci .

However, I find this still does not resolve the problem. ( even replacing
the , with a .)


r

Nick



--
View this message in context: 
http://gis.19327.n5.nabble.com/GUI-for-POI-Search-TYPES-tp5847360p5847364.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] GUI for POI Search TYPES

[nwillink]

Thanks Gerd

Will ckeck

On 06/06/2015 18:21, GerdP [via GIS] wrote:
> Hi Nick,
>
> thanks a lot. Please check:
> The format of the DATA lines in our test data is
> Data0=(51.5256523,-0.0998416)
>
> while your program creates
> Data0=(52,0243.001,7,9768.001)
>
> I think this is the reason for the problem.
> I guess you have to set a locale?
>
> Gerd
>
> > Date: Sat, 6 Jun 2015 10:06:18 -0700
>
> > From: [hidden email] 
> > To: [hidden email] 
> > Subject: [mkgmap-dev] GUI for POI Search TYPES
> >
> > Hi Gerd
> >
> > As promised have uploaded a simple no frills program that creates a 
> mp file
> > from a given range of POI types.
> >
> > I have encountered a problem with the mp parser not correctly 
> including the
> > POIs that lie on the border, so to speak, of the block of pois . I tried
> > many a ruse to overcome the SEVERE outside map warning , then in the end
> > tried it on cgpsmapper and it created the map correctly without 
> chopping of
> > some of the pois.
> >
> > You will see what I mean when you tst the program.
> >
> > www.pinns.co.uk/osm/poi_tester.html
> >
> > best
> >
> > Nick
> >
> >
> >
> >
> >
> > --
> > View this message in context: 
> http://gis.19327.n5.nabble.com/GUI-for-POI-Search-TYPES-tp5847360.html
> > Sent from the Mkgmap Development mailing list archive at Nabble.com.
> > ___
> > mkgmap-dev mailing list
> > [hidden email] 
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
> ___
> mkgmap-dev mailing list
> [hidden email] 
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://gis.19327.n5.nabble.com/GUI-for-POI-Search-TYPES-tp5847360p5847361.html
>  
>
> To unsubscribe from GUI for POI Search TYPES, click here 
> .
> NAML 
> 
>  
>



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus




--
View this message in context: 
http://gis.19327.n5.nabble.com/GUI-for-POI-Search-TYPES-tp5847360p5847362.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] GUI for POI Search TYPES

[nwillink]

Hi Gerd

As promised have uploaded a simple no frills program that creates a mp file
from a given range of POI types.

I have encountered a problem with the mp parser not correctly including the
POIs that lie on the border, so to speak, of the block of pois . I tried
many a ruse to overcome the SEVERE outside map warning  , then in the end
tried it on cgpsmapper and it created the map correctly without chopping of
some of the pois.

You will see what I mean when you tst the program.

www.pinns.co.uk/osm/poi_tester.html

best

Nick





--
View this message in context: 
http://gis.19327.n5.nabble.com/GUI-for-POI-Search-TYPES-tp5847360.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] POIs without POI-search

[nwillink]

Hi Gerd

Will do this gladly. 
Will have to extract the code from another program and create a separate GUI
so the user can specify the range - should be ready tomorrow.

r

Nick



--
View this message in context: 
http://gis.19327.n5.nabble.com/POIs-without-POI-search-tp5847187p5847266.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] POIs without POI-search

[nwillink]

I've been able to find out which POIs on my Oregon 450 and 600 are searchable
and which are not using the following method:

1) Create a 'fictitious' mp file with POIs ranging from say 2a00 to 7F00 and
an another one from 11500 to 14400
2) Use the type number as labels

3) Have the coordinates fairly close together so it can be scanned easily in
Basecamp etc as well.

4) use mkgmap to parse the files and dump on device.

You will notice the search differences between your device and say Basecamp
You will also discover  new search categories, ie Book Store.
You also discover which types as yet not used by Garmin



 



--
View this message in context: 
http://gis.19327.n5.nabble.com/POIs-without-POI-search-tp5847187p5847264.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] mkgmap & 2 TYP files?

[nwillink]

Thanks Gerd

Will have a try

Happy Easter !

Nick

On 04/04/2015 19:00, GerdP [via GIS] wrote:
> Hi Nick,
>
> maybe that works as well, can't try it now. If not, use two steps. The 
> two step
> variant is possibly faster, as it requires less memory.
>
> Gerd
>
> nwillink wrote
> Hi Gerd
>
> How does  it know which TYP file applies to which option?
>
> -index typ1.typ  --gmapsupp typ2.typ
>
> does this work?
>
> Nick
>
> On 04/04/2015 18:52, GerdP [via GIS] wrote:
> > Hi Nick,
> >
> > I see no reason why this would not work. AFAIK the TYP file is only
> > copied
> > into the gmapsupp.
> >
> > Gerd
> >
> > nwillink wrote
> > Hi Gerd
> >
> > Yes, you can do that , but both gmapsupp and the imgs use
> ONE and the
> > same typ file
> >
> > You can't specify one TYP file for gmapsupp and another for the
> > imgs in
> > the same run , or can you?
> >
> >
> >
> > On 04/04/2015 18:33, GerdP [via GIS] wrote:
> > > Hi Nick,
> > >
> > > maybe I don't understand the problem, but I think you can
> > compile the
> > > tiles
> > > once to create the gmapsupp and use
> > > java -jar mkgmap --nsis --index  ... *.img xyz.TYP
> > > for the Basecamp version.
> > >
> > > Gerd
> > >
> > > nwillink wrote
> > > Perhaps I'm the only person who uses 2 typ files for the
> > same map:
> > >
> > > one  for Basecamp/Mapsource ,another for my gps device
> > >
> > > I always seem to be compromising my colour palette and
> line
> > widths
> > > to accommodate my device and yet I'm always creating my
> > routes on
> > > Basecamp.
> > >
> > > So, at present, I'm having to compile the osm twice,
> once for
> > > Basecamp and once for my Oregon.
> > >
> > > I wonder if it were possible to include a new option, ie
> > > --gmapsupp_typ=
> > >
> > > I've tried replacing the TYP file within the gmapsupp
> but there
> > > are so many entries to alter.
> > >
> > > Any thoughts?
> > >
> > > Nick
> > >
> > >
> > >
> > >
> >
> 
>
> >
> > > If you reply to this email, your message will be added to the
> > > discussion below:
> > >
> >
> http://gis.19327.n5.nabble.com/mkgmap-2-TYP-files-tp5839762p5839763.html
> > > To unsubscribe from mkgmap & 2 TYP files?, click here
> > >
> >
> 
> <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5839762&code=b3NtQHBpbm5zLmNvLnVrfDU4Mzk3NjJ8MTM1NTM3MTE1MQ==>
> 
> <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5839762&code=b3NtQHBpbm5zLmNvLnVrfDU4Mzk3NjJ8MTM1NTM3MTE1MQ==%3E>
> >
> 
> <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5839762&code=b3NtQHBpbm5zLmNvLnVrfDU4Mzk3NjJ8MTM1NTM3MTE1MQ==%3E>
> 
> <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5839762&code=b3NtQHBpbm5zLmNvLnVrfDU4Mzk3NjJ8MTM1NTM3MTE1MQ==%3E%3E>.
>
> >
> > > NAML
> > >
> >
> 
> <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
> 
> <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace

Re: [mkgmap-dev] mkgmap & 2 TYP files?

[nwillink]

Hi Gerd

How does  it know which TYP file applies to which option?

-index typ1.typ  --gmapsupp typ2.typ

does this work?

Nick

On 04/04/2015 18:52, GerdP [via GIS] wrote:
> Hi Nick,
>
> I see no reason why this would not work. AFAIK the TYP file is only 
> copied
> into the gmapsupp.
>
> Gerd
>
> nwillink wrote
> Hi Gerd
>
> Yes, you can do that , but both gmapsupp and the imgs use ONE and the
> same typ file
>
> You can't specify one TYP file for gmapsupp and another for the
> imgs in
> the same run , or can you?
>
>
>
> On 04/04/2015 18:33, GerdP [via GIS] wrote:
> > Hi Nick,
> >
> > maybe I don't understand the problem, but I think you can
> compile the
> > tiles
> > once to create the gmapsupp and use
> > java -jar mkgmap --nsis --index  ... *.img xyz.TYP
> > for the Basecamp version.
> >
> > Gerd
> >
> > nwillink wrote
> > Perhaps I'm the only person who uses 2 typ files for the
> same map:
> >
> > one  for Basecamp/Mapsource ,another for my gps device
> >
> > I always seem to be compromising my colour palette and line
> widths
> > to accommodate my device and yet I'm always creating my
> routes on
> > Basecamp.
> >
> > So, at present, I'm having to compile the osm twice, once for
> > Basecamp and once for my Oregon.
> >
> > I wonder if it were possible to include a new option, ie
> > --gmapsupp_typ=
> >
> > I've tried replacing the TYP file within the gmapsupp but there
> > are so many entries to alter.
> >
> > Any thoughts?
> >
> > Nick
> >
> >
> >
> >
> 
>
> > If you reply to this email, your message will be added to the
> > discussion below:
> >
> http://gis.19327.n5.nabble.com/mkgmap-2-TYP-files-tp5839762p5839763.html
> > To unsubscribe from mkgmap & 2 TYP files?, click here
> >
> 
> <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5839762&code=b3NtQHBpbm5zLmNvLnVrfDU4Mzk3NjJ8MTM1NTM3MTE1MQ==>
> 
> <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5839762&code=b3NtQHBpbm5zLmNvLnVrfDU4Mzk3NjJ8MTM1NTM3MTE1MQ==%3E>.
>
> > NAML
> >
> 
> <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
> 
> <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml%3E>
>
> >
>
>
>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://gis.19327.n5.nabble.com/mkgmap-2-TYP-files-tp5839762p5839766.html
> To unsubscribe from mkgmap & 2 TYP files?, click here 
> <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5839762&code=b3NtQHBpbm5zLmNvLnVrfDU4Mzk3NjJ8MTM1NTM3MTE1MQ==>.
> NAML 
> <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>  
>





--
View this message in context: 
http://gis.19327.n5.nabble.com/mkgmap-2-TYP-files-tp5839762p5839767.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] mkgmap & 2 TYP files?

[nwillink]

Hi Gerd

Yes, you can do that , but both gmapsupp and the imgs use ONE and the 
same typ file

You can't specify one TYP file for gmapsupp and another for the imgs in 
the same run , or can you?



On 04/04/2015 18:33, GerdP [via GIS] wrote:
> Hi Nick,
>
> maybe I don't understand the problem, but I think you can compile the 
> tiles
> once to create the gmapsupp and use
> java -jar mkgmap --nsis --index  ... *.img xyz.TYP
> for the Basecamp version.
>
> Gerd
>
> nwillink wrote
> Perhaps I'm the only person who uses 2 typ files for the same map:
>
> one  for Basecamp/Mapsource ,another for my gps device
>
> I always seem to be compromising my colour palette and line widths
> to accommodate my device and yet I'm always creating my routes on
> Basecamp.
>
> So, at present, I'm having to compile the osm twice, once for
> Basecamp and once for my Oregon.
>
> I wonder if it were possible to include a new option, ie
> --gmapsupp_typ=
>
> I've tried replacing the TYP file within the gmapsupp but there
> are so many entries to alter.
>
> Any thoughts?
>
> Nick
>
>
>
> 
> If you reply to this email, your message will be added to the 
> discussion below:
> http://gis.19327.n5.nabble.com/mkgmap-2-TYP-files-tp5839762p5839763.html
> To unsubscribe from mkgmap & 2 TYP files?, click here 
> <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5839762&code=b3NtQHBpbm5zLmNvLnVrfDU4Mzk3NjJ8MTM1NTM3MTE1MQ==>.
> NAML 
> <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>  
>





--
View this message in context: 
http://gis.19327.n5.nabble.com/mkgmap-2-TYP-files-tp5839762p5839765.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] mkgmap & 2 TYP files?

[nwillink]

Perhaps I'm the only person who uses 2 typ files for the same map:

one  for Basecamp/Mapsource ,another for my gps device

I always seem to be compromising my colour palette and line widths to
accommodate my device and yet I'm always creating my routes on Basecamp.

So, at present, I'm having to compile the osm twice, once for Basecamp and
once for my Oregon.

I wonder if it were possible to include a new option, ie --gmapsupp_typ=

I've tried replacing the TYP file within the gmapsupp but there are so many
entries to alter.

Any thoughts?

Nick





--
View this message in context: 
http://gis.19327.n5.nabble.com/mkgmap-2-TYP-files-tp5839762.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] "Building" POI are not searchable resource

[nwillink]

Hi Alexandre,

I know what you mean.

It may be that there is something not quite right.

r

Nick



--
View this message in context: 
http://gis.19327.n5.nabble.com/Building-POI-are-not-searchable-resource-tp5837552p5837678.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] "Building" POI are not searchable resource

[nwillink]

Hi Alexandre,

No ,they are searchable but the results depend on your location and whether
they are within reach.
I have found that many with subtypes >&12 are not searchable.
I have created fictitious maps blasting them with POIs to check on their
searchability and compared the results with many topo typ files

r

Nick



--
View this message in context: 
http://gis.19327.n5.nabble.com/Building-POI-are-not-searchable-resource-tp5837552p5837612.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] "Building" POI are not searchable resource

[nwillink]

I'm not so sure mkgmap creates unusual search results, as the behaviour you
describe applies in my experience to TOPO maps as well.

6402  like all 6400+ falls under 'man made' - the way they 'appear' differs
depending on whether you are using Mapsource,Basecamp or say the Oregon -
the more recent gps devices feature categories not even listed in Basecamp.

Often Mapsource gives more results than Basecamp - they are not limited to a
particular region BUT its categories are more limited.

r

Nick




--
View this message in context: 
http://gis.19327.n5.nabble.com/Building-POI-are-not-searchable-resource-tp5837552p5837573.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] How to search for the Second City Name

[nwillink]

Hi Carlos

I think this is a Garmin issue, as, when searching for cities in Basecamp
etc, the results always start from the first letter you key in - for cities,
I can see the sense of that.



--
View this message in context: 
http://gis.19327.n5.nabble.com/How-to-search-for-the-Second-City-Name-tp5837192p5837223.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] Distorted lines

[nwillink]

Hi Gerd

Sounds painful ; I like the analogy!



--
View this message in context: 
http://gis.19327.n5.nabble.com/Distorted-lines-tp5831842p5831903.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] Distorted lines

[nwillink]

I know this has been discussed a lot and it is annoying to see these
distortions but having seen Garmin's  City Navigator maps with the same
problem, I fear there isn't much more we can expect of mkgmap...?



--
View this message in context: 
http://gis.19327.n5.nabble.com/Distorted-lines-tp5831842p5831896.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] FW: echo improvements for elements with fake ids

[nwillink]

Superb !
Now all the way id's appear! next to the 'large' numbers



--
View this message in context: 
http://gis.19327.n5.nabble.com/echo-improvements-for-elements-with-fake-ids-tp5830557p5830607.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