[mkgmap-dev] Default Style - dead conditions?

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}'

[mkgmap-dev] Resolutions...

Hi Can anyone tell me what exactly the '-' in after resolutions means. I plotted a church resolution 21-23 only to find it does not include resolution 23. Somewhere I read that only the resolutions between the numbers are plotted. If that is the case what does 23-24 mean ? What resolution is

[mkgmap-dev] is_in example?

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,resident

[mkgmap-dev] Garmin Lines Visibility

Hi All Following from Jorics' response to Gerd have done some more research regarding lines on Basecamp: *Lines with non extended types* it seems that the highest line type is 0x3F Strangely Mapsource shows a repeat of lines 0 to 3F starting from 0x40 This looks like mkgmap allows such types

[mkgmap-dev] mapids beyond the limit

Hi Gerd For testing purposes I have created an arg file with mapids starting from (8 digits) and incrementing them to 10009 (9 digits) It created all the tiles (imgs) - I don't think it gave me a warning about most imgs having a nine digital mapid. After I installed the map ont

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

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.

[mkgmap-dev] 'loose' gates

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 w

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

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

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]

[mkgmap-dev] unusual if-then results

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

[mkgmap-dev] Possible If then bug

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 natura

[mkgmap-dev] Openstreetmap URL

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?

[mkgmap-dev] Address Searches on new GPSmap66S

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 ma

[mkgmap-dev] Beaches as a polygon

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

[mkgmap-dev] Failing to get size

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.

[mkgmap-dev] args input-file path issue

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\backu

[mkgmap-dev] missing link

@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

[mkgmap-dev] Error when not using dem-poly

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 "ma

[mkgmap-dev] sea hgt files

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 pos

[mkgmap-dev] dem not showing

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

[mkgmap-dev] BuildDEMFile problem

@ 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

[mkgmap-dev] hgt2osm questions

@ 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=

[mkgmap-dev] How to install maps with DEM onto a GPS

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, detect

Re: [mkgmap-dev] a new DEM-File Option

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

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

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

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.

Re: [mkgmap-dev] How to identify beginning and end of a route?

gt; ____ > 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 ro

[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 woul

Re: [mkgmap-dev] NSI error

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-de

Re: [mkgmap-dev] NSI error

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 Nab

[mkgmap-dev] NSI error

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

Re: [mkgmap-dev] Any option to include POIs as ways?

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.co

Re: [mkgmap-dev] amenity=restaurant and search index

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 mai

Re: [mkgmap-dev] TYP decompiler for linux?

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

Re: [mkgmap-dev] type file and resolutions

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:

Re: [mkgmap-dev] Is any mapper using custom Icons, not displaying labels, but still allows GPS to search by labels?

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 m

Re: [mkgmap-dev] Commit r3842: Improve ResidentialHook / BoundaryQuadTree: suppress misleading warnings about overlapping admin_level=11 boundaries

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 mai

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

u 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är

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

___ > 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 > >

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

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 <[h

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

p-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

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

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 y

Re: [mkgmap-dev] construction as industry?

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

Re: [mkgmap-dev] is_in filter

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

Re: [mkgmap-dev] is_in filter

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 bui

Re: [mkgmap-dev] construction as industry?

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 landfi

[mkgmap-dev] construction as industry?

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

Re: [mkgmap-dev] metres to fee issue with mp contour files

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 >

[mkgmap-dev] metres to fee issue with mp contour files

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 resultin

Re: [mkgmap-dev] Spurious points & Basecamp blank tiles

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

Re: [mkgmap-dev] patch to write polygons in decreasing order

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 = lan

Re: [mkgmap-dev] patch to write polygons in decreasing order

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 un

Re: [mkgmap-dev] patch to write polygons in decreasing order

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 bui

Re: [mkgmap-dev] inner sections of a multipolygon

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 mkg

Re: [mkgmap-dev] inner sections of a multipolygon

--- > *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 ! >

Re: [mkgmap-dev] inner sections of a multipolygon

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

Re: [mkgmap-dev] inner sections of a multipolygon

tivate 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:* [h

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] inner sections of a multipolygon

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 l

Re: [mkgmap-dev] Problems with routing on Etrek 20 with latest firmware

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 G

Re: [mkgmap-dev] Tool to dump index?

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 bin

Re: [mkgmap-dev] [Patch v1] improve LinePreparer to reduce img size

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

Re: [mkgmap-dev] [Patch v1] improve LinePreparer to reduce img size

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.

Re: [mkgmap-dev] [Patch v1] improve LinePreparer to reduce img size

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

Re: [mkgmap-dev] osmc:symbol

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

Re: [mkgmap-dev] osmc:symbol

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 ty

Re: [mkgmap-dev] How do I transform the name of all Ways?

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 Sen

Re: [mkgmap-dev] Map Background Colour

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. __

Re: [mkgmap-dev] Typ Files

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' l

Re: [mkgmap-dev] Typ Files

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,

Re: [mkgmap-dev] Oneway 1 or -1 BUG?

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-tp5869847p586

[mkgmap-dev] Oneway 1 or -1 BUG?

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

Re: [mkgmap-dev] Oneway arrows

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 inv

Re: [mkgmap-dev] Anyone determine which linetypes are NOT visable in BaseCamp?

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 w

Re: [mkgmap-dev] don't route through highway=construction

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. _

Re: [mkgmap-dev] custom typ files

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 m

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

ou 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 >

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

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

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

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

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

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

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

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 contex

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

: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

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

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/?mla

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.co

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

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 p

[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 SEV

Re: [mkgmap-dev] POIs without POI-search

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

Re: [mkgmap-dev] POIs without POI-search

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 fair

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

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

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

psupp. > > 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

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

nd 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 fo

[mkgmap-dev] mkgmap & 2 TYP files?

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 c

Re: [mkgmap-dev] "Building" POI are not searchable resource

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.

Re: [mkgmap-dev] "Building" POI are not searchable resource

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 t

Re: [mkgmap-dev] "Building" POI are not searchable resource

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

Re: [mkgmap-dev] How to search for the Second City Name

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-t

Re: [mkgmap-dev] Distorted lines

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 mkgma

Re: [mkgmap-dev] Distorted lines

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-tp583184

Re: [mkgmap-dev] FW: echo improvements for elements with fake ids

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.

  1   2   >