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}'
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
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
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
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
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.
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
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
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]
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
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
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?
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
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
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.
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
@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
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
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
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
@ 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
@ 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=
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
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
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
__
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.
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
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
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
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
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
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
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
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
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:
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
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
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
___
> 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
>
>
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
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
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:
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
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
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.
___
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
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
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
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
>
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
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
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
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
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
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
---
> *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 !
>
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
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
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.
___
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
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
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
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
--
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.
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
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
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
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
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.
__
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
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,
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
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
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
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
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.
_
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
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
>
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
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
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
>
>
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
: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
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
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
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
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
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
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
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
>
>
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
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
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
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.
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
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
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
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
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
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 - 100 of 174 matches
Mail list logo