Hi Diego,
> I create different tiles setting the Splitter to 1.600.000, then I add
> clipped contours and DEM with Mkgmap.
Does your map have layers, like tiles with mapping data and tiles with
contours only?
If yes, then maybe MapInstall can't select tiles correctly.
--
Best regards,
Hi Gerd,
> The doc shows that you can have up to three cities, and I've no idea
> how to decide which numbers belong to which city.
I guess the reasonable solution is to split "CityName" and assign all
numbers to all cities.
I have tested a bit my map and found that with 2 cities in
Hi Gerd,
> I thought that mkgmap can handle roads with multiple cities but you
> seem to be right that this only works when the cities are encoded with
> the house numbers.
Actually in mp format you can encode void house numbers with 2 cities.
Doesn't it work in mkgmap? I mean statement like:
Hi Daniel,
> How can this "lists of tiles" be generated?
I'm doing it with Qgis and some scripts. General idea is to import tiles
created by splitter as a layer to Qgis, add region attributes to tiles
and export result as a csv file. Then I use awk script on csv to extract
IDs of tiles with
Hi Daniel,
there should be no problems with routing, because a route should switch
maps at the country border. See mkgmap option
--add-boundary-nodes-at-admin-boundaries.
If you don't like tiles without full content, then use bigger extract
and smaller poly file as an option for splitter.
Hi Thomas,
osmium tool executable can be downloaded by conda:
https://conda.io/projects/conda/en/latest/user-guide/install/windows.html
https://anaconda.org/conda-forge/osmium-tool
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
Hi Ticker,
I hope that I understand style parsing correctly now. Thanks for advice.
> Not sure what you mean.
I'm a programmer. I have some preconception about conditional statement,
logical operators etc. Situation, where rules for condition "tag=value"
are different than for "tag!=value"
Hi Ticker!
> I don't get a crash
Maybe there are other factors? I'm using AMD Ryzen, Windows 10, OpejJDK
18.0.1 (just have updated, 17.02 worked the same). I can create a set
which cause crash, if you are interested. Right, it should be
mkgmap:option:test, but I get a crash in both cases.
Hi Gerd,
> On the other hand you already found the work around
Kind of blind search for solution. I have implemented some kind of
processing in style, where I need temporary variables. Now I have a long
sequence, where i only use operator "=" for variables, since "!="
doesn't work :)
> I
Hi Gerd,
thanks for explanations.
> the option --make-opposite-cycleways is implemented like this
Somehow I imagined, that opposite cycleway is magically added at a final
step, when the main road is already prepared by style. Your way is more
flexible, but needs more diligence in style.
Hi Ralf,
I had similar style: overlay line first, roundabout next. I can't repeat
the problem, maybe it was my fault.
Now I'm using transparent graphics for 0x0c, so it looks correct
regardless of order.
--
Best regards,
Andrzej
___
mkgmap-dev
Hi,
I have tweaked my maps recently and tripped on some problems. Nothing
serious, but a bit troublesome.
First I noticed, that tweak for better looking roundabouts not always
works. In default style there is something like that:
junction=roundabout & (highway=tertiary |
Hi Nop,
simply make links to existing files. For Windows this is command
"mklink", for linux it is "ln".
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Karl,
there is no common definition for objects types on Garmin map, see
https://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/POI_Types
Mapsource and some devices treat POI 0x6401 as a bridge, so I think it
is a good choice. But I prefer to use a line for a bridge.
--
Best regards,
Hi,
65001 is exactly Unicode UTF-8, that we are talking about. It doesn't
work for me.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Marek,
I have tested on 66st firmware 7.20. Unicode maps compiled with mkgmap
are rejected, the same message as you have found on issue 26 - "Cannot
authenticate maps".
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
Hi Felix,
I guess the idea is that Garmin holds certificates and only offers
signing services for money. Or doesn't offer at all.
Well, maps aren't encrypted, so you could hack firmware in your GPS to
disable verification.
--
Best regards,
Andrzej
Hi,
I think different models of GPS react differently. Most common is that
new devices require digital signature for Unicode maps. Maps with CP1252
usually work. At least handheld GPS, more problems could be with nuvi.
--
Best regards,
Andrzej
___
Hi Felix,
I really don't know java. As far as it looks like "C", I can tweak a
simple code, but it's not enough to make any bigger change.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi,
actually gmaptool doesn't split and merge img, when replacing typ. It
overwrites old data with a new one. If new typ is longer then the old
one, gmaptool has to search for free sectors in img or increase img size.
--
Best regards,
Andrzej
___
Hi Gerd,
Josm's algorithm removes some spikes, which probably aren't common for
real data and layer 0 of img. So differences aren't big. But maybe for
lower resolution it could be better, especially for polygons.
Wouldn't it be faster?
--
Best regards,
Andrzej
Hi Felix,
then what about proposed:
> For line--types-with-direction it would be best to give a resolution
> limit for each type, so if resolution is lower than associated lines
> can be reversed.
Does it means, that you accept wrong direction at lower resolution?
--
Best regards,
Andrzej
Hi Felix!
> If the main road is merged but the direction dependant road not - then
> at lower resolutions the DP filter will create a mess
But direction dependent road are merged, aren't they?
> And because I have lots of overview - E.g. oneway arrows, oneway
> streets are loads, there is
Hi Felix,
why don't make it simple?
Routable roads with oneway=-1 have to be reversed.
Non-routable lines with oneway=-1 have to be reversed if has-direction
is present.
If has-direction is present, road is not reversible for merging at all
layers.
I don't understand your suggestion for
Hi Gerd,
I understand, that mkgmap:has-direction=no takes priority over list and
that oneway is independent of has-direction.
> Next RoadMerger merges roads. It will not reverse roads with oneway
> flag true or direction flag true and it will not merge roads which
> have different oneway or
Hi all,
reading the discussion, I think it would be good to separate 2 cases:
- routable roads with one-way attribute,
- all lines which have direction.
As for routing, I would assume, that all problems are resolved
automatically and correctly by mkgmap. Routing is only valid at level 0.
On
Hi Gerd,
here example of lines, that shouldn't be merged:
https://www.openstreetmap.org/way/481106241
https://www.openstreetmap.org/way/481106244
https://www.openstreetmap.org/way/481106242
I have tested with mkgmap-low-res-opt-r4711 and it works correctly.
Lines are not merged with
Hi Gerd,
it is clear, but I was thinking about something else, about merging
lines with reversed points. If mkgmap performs that kind of merging,
there should be an option to block reversing for a particular object
type. I got impression, that mkgmap:has-direction is a flag, that can be
Hi Gerd,
I don't know particulars about direction flag, that is written into img.
Maybe it gives some kind of protection against drawing a line in revers
direction? Would be nice to test, if it were possible.
Anyway, for me problem is about reversing a line by mkgmap. I think that
Hi all,
I didn't know about mkgmap:has-direction. Good to see there is
possibility to protect direction of the line. Please note, there are
lines, which aren't roads but really have directions. Some example:
- waterway=river, stream, maybe canal, ditch too,
- natural=cliff,
-
Hi,
some more experiments, see attached patch. I have tried to optimize
rounding of coordinates for lowest distance to line. This is not good
for polygons, because can creates gaps between adjacent polygons.
--
Best regards,
Andrzej
Index: src/uk/me/parabola/mkgmap/build/MapBuilder.java
Hi Gerd,
I don't observe any significant differences in compilation. But to make
it more optimized, we can put SizeFilter before DouglasPeuckerFilter. I
have attached a second patch here.
There is a difference in results. See pictures with DouglasPeuckerFilter
after RoundCoordsFilter and
Hi,
maybe 10m contours are too dense for this area?
Please try attached patch. I have moved D-P simplification before
rounding of coordination. This should preserve shape of the line a bit
better. I'm not sure if this is a safe modification, but it seems to works.
I haven't found, where is
Hi Oliver,
that's an interesting subject, you are working on. You probably know
this free map, I think this is an example of required minimum:
http://static.garmin.com/shared/aus/HTML/_pages/isle-of-man.html
--
Best regards,
Andrzej
___
mkgmap-dev
Hi Karl,
> But how about creating indices (--net, --index, --split-name-index,
> --road-name-config=filename)?
--net is about putting address data into *.img tiles, so this is your
step 2. Others are about creating index file *_mdr.img, this is done in
step 3.
> How about using the same
Hi Karl,
> I tried makling a map using the same draworder
> Type=0x050,2
> Type=0x051,2
> plus using the option --order-by-decreasing-area
This is some kind of trick, not a general solution. There is no
guarantee, that GPS will follow the order of objects in img.
And I'm sure you can find
Hi Karl,
> Square is probably "Rynek" in Polish but given the other mappings
"Plac" should be as good.
I guess "plac" is better word for a typ file, since it is a general term
describing a public area inside a city. "Rynek" has more precise meaning
in Polish, it is market square or the main
Hi Karl,
about Polish:
type=0x25
String7=0x15,Plac
type=0x4b
String7=0x15,Tło
(Tle = wrong form/declination)
For waterfall and canal Polish is OK, but other languages looks like
"water" instead.
--
Best regards,
Andrzej
___
mkgmap-dev mailing
Hi Felix,
> Right now for scripting I can only see how to create gmapsupp part
> files without address search.
Doesn't mkgmap combine *.img with correct index? I mean you can get like
1000 of tiles after compiling a big area, but you can combine first 500
and next 500 separately.
I'm doing
Hi Carlos,
splitting could be useful, when you'd like to create img in one step.
Other option is to install map on PC and then use MapInstall to create
img. MapInstall does splitting for big maps.
--
Best regards,
Andrzej
___
mkgmap-dev mailing
Hi Gerd,
I see, not a simple problem. While the idea is nice, the actual
implementation looks problematic. Maybe better remove the message or
replace it with some general advice?
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
Hi,
I recently have noticed the following suggestion in mkgmap output:
"To reduce the run time, consider increasing the amnount of memory
available for use by mkgmap by using the Java -Xmx flag to set the
memory to more than 196700 MB, providing this is less than the amount of
physical
Hi Gerd,
yes, it can be commited, I haven't noticed any problems.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Mike,
> I think that if a copyright file is provided, this should override any
> existing copyright messages from any input files
It looks like current processing of copyright-file is to override any
previously defined copyright. This is acceptable, only needs a clear
explanation in
Hi Gerd,
I was looking at wrong places. Actually there is a copyright line from
mp header.
After patching, option "copyright-file" overrides mp header. Without
"copyright-file" reappears value from mp. I'm not sure, maybe there
should be both copyrights present? Dropping a copyright doesn't
Hi Gerd,
good to see, that optimizations are active.
I set both variants: copyright in mp and in copyright-file, but img
contains empty string. I think mp header is not processed at all, at
least I haven't found any procedure for it.
On the other side, license-file works correctly.
--
Best
Hi,
I'm curious, what processing is active, when source data is in mp
format. Particularly, which mkgmap options are active?
For example, do these options have any use:
no-lower-case
reduce-point-density
reduce-point-density-polygon
merge-lines
min-size-polygon
polygon-size-limits
Hi Gerd,
your solution for polish reader is OK, thanks.
As for other readers, mkgmap should have some handling/protection for
the use of 4A and 4B in style. I haven't noticed any (I can be wrong),
so maybe is better to ban both these types for now.
--
Best regrads,
Andrzej
Hi Gerd,
preview compiled with r4436 works correctly.
You probably can relax the check for all readers. Polygon 0x4A needs
some extra care, when mkgmap creates its own preview map, but I don't
think it is dangerous in a detailed tile.
--
Best regards,
Andrzej
Hi,
I'm trying to edit and compile preview map in mp format. Unfortunately
mkgmap forces a restriction:
SEVERE (MapFailedException): img\Topo.mp: (thrown in
PolishMapDataSource.checkType()) invalid type 0x4a for POLYGON
I'm not sure, why this restriction exist. Is there any problem to
Hi Gerd,
thanks for updating mkgmap.
I think the idea behind background is to provide an arbitrary shape for
trimming tile area. CGPSmapper doesn't execute trim on mp files, so the
meaning of background is lost.
--
Best regards,
Andrzej
___
Hi Gerd,
yes, when I compile my map, I get only object 4b at layer 0. I use
simple definition of background:
[POLYGON]
Type=0x4b
Background=Y
Data0=...
[END]
This works for cGPSmapper, but not for mkgmap. I could add EndLevel=5 to
all my sources, but it was easier to recompile mkgmap, to
Hi,
the following quote from cGPSmapper describes peculiarities of command
"Background=Y":
If there is only one object set as the background, then the
EndLevel is automatically set to 9.
If there is no background object, or more than one, then the
EndLevel is not changed.
As I understand,
Hi Gerd,
just after expressing hope for good work of resolution, I got following
error in r4420:
Error in style: Error: Cannot use type [0x2f17 resolution 24] with level
0 at resolution 23 in style file points, line 270
It is again something, that I have used for a long time. My
Hi Gerd,
thanks!
I never cared about levels in style, I have always used options.
My guess is, that levels doesn't need much control, only there should be
foolproof conversion from levels to resolution. I expect, that objects
defined with resolution are processed correctly.
--
Best
Hi Gerd,
maybe the problem depends not only on levels. I have uploaded simplified
version of a set for creating my map. You can examine, what is going on.
http://files.mkgmap.org.uk/detail/460
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
Hi Gerd,
tested again, the error really appeared somewhere after v4323. And I'm
compiling the same map since 2014, this is the modification date on my
scrips and style.
See for example this changelog:
http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4345
Looks like changes
Hi Gerd,
probably some other changes made this error to appear. I have checked
that v4323 compiles my map, while v4386 reports error.
I'm not sure about the purpose of the patched function, but I'm afraid
there could be problems with following example:
options: levels=0:24,1:22
style:
Hi All,
since something is wrong with downloads on mkgmap site, I have compiled
version 4419. I guess this is the latest official release. Now with some
old maps I get a new error:
Error in style: Error: Level number too large, max=0
I guess this is a conflict between arguments:
levels=0:24
Hi Gerd,
for GMapTool to set first flag, all tiles should include DEM.
I'm afraid, that mapset with mixed tiles - with and without DEM - is not
standard for Garmin. It might be impossible to invent a proper way to
handle that configuration.
Some years ago I did a number of tests and chose
Hi,
there are 2 consecutive bytes in TDB file. Let's name them "fist" and
"second".
Current processing of mkgmap is:
Option --show-profiles=0|1 sets byte "first" to 0 or 1.
Byte "second" is always 0.
Processing of cgpsmapper is:
Byte "first" is always 0.
Option HeightProfile=N|Y sets byte
Hi Gerd,
I think the hasDem flag comes from mkgmap sources. I still can trace it
in changelogs:
http://www.mkgmap.org.uk/websvn/diff.php?repname=mkgmap=%2Ftrunk%2Fsrc%2Fuk%2Fme%2Fparabola%2Ftdbfmt%2FHeaderBlock.java=4093=4093
--
Best regards,
Andrzej
Hi,
just have realized, that option --show-profiles could remain at default
0 even when DEM are processed.
Kalle, please make sure, that you include --show-profiles=1 in mkgmap
options.
I think the default for --show-profiles could be dependent on DEM
presence. Would make less hassle.
Hi Kalle,
I have downloaded your map - KK_MiFra_DEM.gmap.7z. It really doesn't
support height profiles. The reason is that an appropriate flag in TDB
is missing. I have patched your tdb file, please replace it on your PC
and try again.
Question for Gerd: how it is possible to create a map
Hi,
see example of natural=bay, which can give problems:
https://www.openstreetmap.org/relation/9408222
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd,
I use TypViewer for creating typ files and I don't know XPM details. But
looking at TypViewer output, I guess that transparent pixels are defined
with color like that:
" c none"
where space ' ' is used for marking pixels.
Changing draw order instead of transparent graphics could
Hi Gerd,
natural=bay is not a water but a name for an area. It can cover islands too:
https://wiki.openstreetmap.org/wiki/Tag:natural=bay
IMHO transparent polygon is a good solution.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
Hi,
here is a small patch to correct a typo.
--
Best regards,
Andrzej
Index: trunk/src/uk/me/parabola/mkgmap/reader/polish/PolishMapDataSource.java
===
--- trunk/src/uk/me/parabola/mkgmap/reader/polish/PolishMapDataSource.java
Hi Gerd,
thanks for explanation. Not a big problem, so let it be.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi,
I want to create 2 lines on a map from a single highway object. I have
noticed recently, that sometimes these 2 lines are misaligned. I guess
this is because of different simplification.
Is it a new problem (maybe extra points for house numbers)? Or maybe
there was never guarantee to
Hi Gerd,
point 0x28 is a label or region name without an icon. Do any Garmin's
map include 0x28 in search index?
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker,
> I don't agree with --recommended because this file will often required
> some tweaking and eventually become the basis of the new users
> building environment.
I don't see problems with tweaking --recommended option. Mkgmap allows
for repeated options and process the last one.
Hi Gerd,
maybe treat it like default style, which is kind of build in? For
example, when invoking mkgmap with an option --recommended, mkgmap could
include all options from default config.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
Hi Gerd,
I have extracted objects, that are problematic on my map, see attached file.
Both roads trigger error messages, when I compile my whole map:
SEVERE (RoadDef): D:\Emapa\Popej\_Topo-360\zrodla\8011.mp: internal
error? The nodeCount doesn't match value calculated by RoadNetWork:
Hi Gerd,
overview is my fault. I have used wrong options. I set 3 layers of DEM,
while overview map has only 1 layer of data. That kind of setup is not
supported by Garmin. I have corrected it and now overview map is OK.
I got 2 errors "The nodeCount doesn't match value calculated by
Hi Gerd,
I have complied a big map from mp sources (about 3.8GB in 50 files) in
one go. Map is usable, routable, with index search and DEM. It is quite
impressive, thanks!
The problems I have noticed:
- Overview map is not accepted by Mapsource and Basecamp. It looks ok,
but it includes
Hi Gerd,
doesn't mkgmap support multiple points restrictions from OSM data?
Anyway, removing 4-point restriction prevents mkgmap from crashing, but
errors still remains:
SEVERE (RoadNetwork): 8001.mp: 1 can't locate arc from 'via' node 1
to 'to' node 171 on way 431744
SEVERE
Hi Gerd,
I have tried to compile some more complicated mp. First problem is, that
restriction placed on the beginning of the file give multiple warnings,
like:
SEVERE (RoadNetwork): 8001.mp: 1 can't locate arc from 'via' node 1
to 'to' node 171 on way 431744
SEVERE (RoadNetwork):
Hi Gerd,
I would rather have mkgmap compatible with real compiler than manual,
but in this particular case, both options are reasonable.
I'm using the latest version of cGPSmapper 100d. The earliest version I
have is 74 from 2004. It behaves the same.
--
Best regards,
Andrzej
Hi Gerd,
I have compiled this example. cGPSmapper doesn't work like in quoted
description. When EndLevel is present, cGPSmapper uses only lowest DATA
and ignore any other. See description of EndLevel, this one is true:
Endlevel=# - The coordinates in the lowest numbered Data# line apply
up
Hi Gerd,
I think GPSMapEdit does it correctly. Each line should be extended up to
EndLevel, so it means that first line should be present on levels 0-2
and second on levels 1-2.
Multiple DATA in a statement is not a typical case. I think these
statements are created usually by GPSMapEdit. I
Hi Gerd,
I think I have written about these problems some time ago. There is
similar problem for polylines, which contains multiple DATA statement.
Each DATA is a separate line in mp format, but mkgmap connects them
together, which is wrong:
SEVERE (PolishMapDataSource): 29483016.mp: Line
Hi,
I'm against changing defaults for existing options.
I'm in the first group of users, I have scripts with options. A change
of defaults would probably require to change options in my scripts. I'm
afraid I wouldn't catch changes in mkgmap and in many cases I would get
a faulty map without
Hi Gerd,
we can use any formula to assign mapid. If this formula would be widely
accepted, there wouldn't be much conflicts between maps created by
different developers.
If we use the original Garmin's formula, then we would avoid conflicts
with many existing Garmin's maps too. The only
Hi Gerd,
yes, I got the formula after examining numerous Garmin's maps. I know,
that City Navigator is different, my guess is that next CN map gets next
free mapid. I'm not sure about marine maps and other new maps from Garmin.
It looks like the formula is easy to support up to FID 45744.
Hi,
basically map ID should be unique for all tiles, regardless of FID. If
you load 2 tiles with the same map ID to a GPS, it will silently ignore
one of these tiles. Most probably GPS assume, that these are the same
tiles and there is no reason to process both.
Search index contains map
Hi Brad,
there are many factors:
- Style for mkgmap, used for compiling. It defines maximum level of an
object and the content of a label. Some markers in label can hide a part
of a label, depending on zoom level.
- TYP file attached to mapset. It defines graphics of an object, size
and
Hi Gerd,
> are in fact copies of the original way members of the MP and those are
> typically not closed
I see 3 possible solutions:
1. Convert multipolygon ways to a proper, continuous outline.
2. Return is_closed() as true, when mkgmap:mp_created is true.
3. Add info to documentation, that
Hi Gerd,
I think it would be better to have something like apply_first_way. See
for example these relations, where first member is a point:
https://www.openstreetmap.org/relation/1699620
https://www.openstreetmap.org/relation/254686
--
Best regards,
Andrzej
Hi Ticker,
> Is this logic general enough to move into the default style?
This is a solution for my maps and I have tried to make it universal.
There could be other propositions, for example some people could prefer
name of the road over ref number or include name into shield (but it
doesn't
Hi Andreas,
> The problem is that most other relations dont have members with role
> „Start“
I see, that I have repeated an answer already given, sorry.
The main problem is, that many relation aren't quite clean. For example,
segments aren't in order or relation could be not a single line but
Hi,
for some time mkgmap allows for code like this:
type=route & route=mtb
{
apply role=start {
set ...
}
apply role=stop {
set ...
}
}
I'm not sure about "role=stop", it is described as a bus stop, but maybe
for cycle route it has a different meaning.
--
Best regard,
Hi Ticker,
I guess variables like mkgmap:us_interstate come from my style. I use
them for shields with road reference numbers. There are dedicated
shields for US maps and standard shields for other countries. These
variables allows to create single style for both cases.
This is an example
Hi Gerd,
I'll try to do some tests with mp, when I find some time. I wasn't
aware, that mkgmap accept background with this format.
Does mkgmap process statement "background=Y"? I wonder if background
object in img has any distinctive attributes.
--
Best regards,
Andrzej
Hi Gerd,
yes, I think that we could use irregular background without trimming
other objects. At least for some testing.
I'm not sure, what would be the easiest way to implement it. Maybe add
background polygon as explicit data in input source and include
processing for it in the style?
--
Hi Gerd,
I'm not sure if there should be any cutting of objects. My guess is,
that only background polygon is essential. Maybe would be enough to
simply discard objects, which are fully outside of background?
All this needs some testing.
--
Best regards,
Andrzej
Hi Joris,
>From which perspective are you talking?
Well, from my perspective. I would consider your typ for maps, that I
publish, but I wont, unless you provide a clear license.
> For me personal drawing simple single collored 16 x16 bitmap pixel
> icons is free for the community.
I
Hi Gerd,
Probably the solution is to use background polygon trimmed by
country/region area. I think GPS look for background at current position
to determine which map to use for a search. Some GPS allow to select
map, but mostly it goes automatically, GPS selects a map and then
doesn't look
Hi Joris,
> I volunteer in maintaining a default typ for mkgmap
This is very interesting, thanks!
I think you should clearly state the license for your work. Especially
because it include graphics art, which is quite heavy topic, when
dealing with copyrights.
--
Best regards,
Andrzej
Hi Steve,
> Are the ones above 0x1f different though? Or is it just ignoring the
> top bits?
When a typ file is attached, then icons are repeated, icon for subtyp
0x00 is the same as for subtyp 0x20. I can't create icon for subtyp
greater than 0x1F in TYPViewr, is there a limit in typ
1 - 100 of 709 matches
Mail list logo
