://betaplace.emaitie.de/webapps.rel
onId=47798
There are no gaps or faults within the relation as far as I can see.
I put this question and a few examples of my map also on the forum
at http://forum.openstreetmap.org/viewtopic.php?pid=59370
Thanks,
Minko
Those borderlines form part of different type of administration regions,
(countries, provinces, municipalities etc).
My question is not to understand why they are tagged like that, but how to make
them render them well into mapsource. Is there some kind of patch I can try
out, and where/how can
Thanks Steve,
So, as I understand it, I need to change the default relation style file
in order to convert those multipolygons into lines?
When I look at other osm maps from the same area (openmtbmap, radfahrers map,
computerteddy)
I dont see those connecting lines between the borderlines.
Hi all,
It looks like I managed a way to render those complex multipolygon
administrative borders correctly now.
In the relation style file, I changed administrative borders statements like
this:
# country borders
(type=boundary | type=multipolygon) boundary=administrative admin_level=2
{
names.
So I better leave it like in the default style.
Clinton Gladstone wrote:
Sun, 14 Feb 2010 04:50:22 -0800
On Feb 14, 2010, at 11:32, Minko wrote:
set mkgmap:boundary2_name='$(mkgmap:boundary2_name)/${name}' | '${name}';
Just out of interest, should the parentheses surrounding
Hi,
I don't know if this already has been discussed, but some combinations of TYP
file and overlays wont work in Mapsource.
I'm trying to put oneway, bridge and tunnel symbols on the roads by using the
layer style file.
This works fine with tunnels and bridges, but with oneway symbols I
Hi
Mapsource (6.15.7) crashes when I click to see the profiles of the route:
invalid map/setT iterator
I have the elevation contour img's in one mapset with the osm map img tiles,
combined them with mkgmap r1580 (with --show-profiles=1).
If I make one mapset with only contour lines, I see an
the elevation profile with this approach?
Cheers,
Minko
Ronny Klier wrote:
This will not work. I got the same problem in different versions of
MapSource. May be there should be an explicit warning in show-profiles
option help.
If I make one mapset with only contour lines, I see an emtpy profile
With some detours, I finally got the elevation profile working in my mapset ;-)
I dont know if it now worked because I also installed Garmin Basecamp.
First, I had all map tiles and contour img's in one mapset.
They are still there, but now I created another tdb index file
with mkgmap on all
?)
Is this possible?
Cheers, Minko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
those islands were not flooded, but now they are. So it was somehow possible,
but how?
Regards,
Minko
Marko Mäkelä wrote:
Something like this (not tested) in the relations file of your style
should do the trick:
type=multipolygon natural=water { apply role=inner { set natural=land
that the Dutch way of osm tagging is
wrong and has to be altered instead
of finding a way to solve this with mkgmap ;-)
Cheers,
Minko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi,
I've tried to put in the relation file:
type=multipolygon { apply role=inner { set inner=yes } }
And in the polygons file:
natural=water inner=yes [0x27 resolution 14]
But it seems not doing anything.
Looks like the multipolygon processing is done before it reads the
relation style
Hi,
The option --road-name-pois often creates place names that are totally wrong.
Two adjacent streets in the same district can have different place names.
I think it is better not to show the place name until this problem is solved?
Is there a way to make these POI invisible on the map?
on the map only the ref. number
of the road, like N224 (without using highway plates) and on the tooltip
label if I point it with the mouse,
streetname (ref) like Zeisterweg (N224).
Cheers, Minko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
I already found the answer to my own question, and it was easier then I thought
(highway=tertiary | highway=tertiary_link) [0x00 resolution 23-21 continue]
(highway=tertiary | highway=tertiary_link) [0x05 road_class=3 road_speed=3
resolution 24]
I only removed the routing rules in the first
I tested my TYP file again and again. Now I narrowed the problem down to
setting the extended label to invisible on some line types.
All streetnames dissappear only with routable roads (I think). If I set the
railway labels or
admin. borders to invisible, streetnames still show up (this behavior
://mijndev.openstreetmap.nl/~ligfietser/openfietsmap/Scripts/Styles/lines
for my style definitions.
Cheers, Minko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
://www.openstreetmap.org/browse/way/34132635
IF those are connected to other roads, you can make a good routing already
without a patch.
In my style file the continue statement makes sure the pedestrian roads are
rendered (as footway) as well as the area.
Minko
Marko Mäkelä wrote
An educated
Address search doesn't work either on a Nuvi 310 and Dakota 20.
Probably the same for Oregon/Colorado models.
It pops up with a question of state/province and then it finds nothing.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Felix,
-routing over areas works for me.
-about my e-mail client:
I read this list from the web at
http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/maillist.html
I'm not subscribed to individual messages because of the high volume.
I can't find a button to reply directly to the list.
resolution ..]
Cheers,
Minko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
to a
certain area within the polygon. So I wonder if it is possible to combine those
names with the pois. Any ideas?
Cheers, Minko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi,
I don't know if this is the same problem as Nop described,
but lately I found that on my map some sea areas were gone in the Netherlands:
see http://img338.imageshack.us/img338/9992/errorcoastline.jpg
On osm it looks ok:
http://www.openstreetmap.org/?lat=52.817lon=4.955zoom=10layers=B000FTF
I have found the bug with the geofabrik osm inspector:
http://tinyurl.com/3aaz6wp
Removed a duplicate coastline and now it renders fine :-)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi,
I have found out that in my case it was not caused by the splitter, but a
mistake in osm:
a coastline placed on top of another one. I removed the last one and now it
renders fine.
Werner wrote:
I used splitter and mkgmap to compile a map of Finland, based on
geofabrik- data. The map was
Hi,
In the default styles, mkgmap has some routing problems with roads that are
temporarily closed with the tag access=no For instance, this problem can
occur on cycleways which are closed to all traffic (bicycles as well) because
of road reconstructions. In the default style the handling is
Marko wrote:
I believe you would need something like this, so that you get to see the
temporarily closed ways on the map:
highway=cycleway (access!=no | access!=*) {add access = no; add bicycle =
yes; add foot = yes}
highway=cycleway access=no [0x16 road_class=0 road_speed=1 resolution
Proposal for adding natural=sand to the default mkgmap styles.
The tag natural=sand is commonly used in the Netherlands for extensive areas of
so called drift-sand (Dutch: zandverstuivingen, in osm on 300 ways/relations),
which are unique in Europe. Can be rendered the same as natural=beach,
For my openfietsmap I'm using mkgmap v. 1647 and I have no problems with routing
on those same dutch bikepaths at all, as well as a lot of other happy users of
my maps (a few hundred?)
Also on Mapsource it works ok (as long as the distances are not too long, 20km)
Valentijn wrote:
Hi Paul,
Thanks Aighes,
It now worked, splitting time was much faster (about 1 hr to extract the
europe.pbf with osmosis and another hour to split the benelux.osm file).
Cheers,
Minko
Aighes wrote:
Hi,
splitter r123 only reads osm-xml format. So you have to use in osmosis
--write-xml. I don't know
Maybe it's caused by the geofabrik extract of germany.osm because I notice the
same problems happen
for the same region (near Emden) if I use the Benelux abstract from
planet.openstreetmap.nl
For my Benelux maps I have use the europe.osm extract from geofabrik and then
split it with a wider
Hi Josef,
Do you use the bzip2 or the pbf binary format?
The pbf is smaller (3,6gb) and it doesn't take that much time to cut out
an extract for the benelux with osmosis.
Josef wrote:
As Minko I use now europe.osm and cut out a rectangular piece with
osmosis. Map is now good.
The disadvantage
which look very
pretty:
http://wiki.openstreetmap.org/wiki/User:Petrovsk/FR:My_Garmin_map_styles
http://blog.lionelmaraval.fr/post/2010/01/23/Carte-pseudo-mapnik-pour-Garmin
So any ideas to improve the layout of the mkgmap styles with a typ file would
be recommended.
Cheers,
Minko
noticed there are a few things not rendered at all in the standard style:
-landuse=grass for instance
-highway=cycleway is rendered as footway etc
I would like to hear your opinion if there should be a standard TYP file (like
mapnik)
or why not.
Minko
(1) http://blog.lionelmaraval.fr/post/2010/01/23
and translated it into German, English etc
Thanks,
Minko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I tried to split an extracted area with osmosis too. Same errors.
I suppose you need to set osmosis to --write-pbf in order to get a binary
abstract?
aighes wrote:
Hi
I know, it wont help you, but I haven't nay problems with pbf-input and
modified area.list. I think the only think I do
How about highways on dikes or dams?
http://www.openstreetmap.org/?lat=51.66033lon=3.72579zoom=16layers=M
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi,
I tried it again, splitted then europe.pbf now without osmosis and without
errors.
So i don't know what went wrong the first time.
The benelux took me now only 50 minutes (instead of many hours with the bzip2
file)
Thanks,
Minko
Ralf wrote:
I have splitted the europe pbf extract
Can nobody explain why those jagged lines occur in those roundabouts?
Is it because the grid of garmin is too rough and mkgmap makes mistakes
aligning the nodes in a circle?
I wrote:
I noticed that some roundabouts are rendered very badly, like this one:
Yes, this one for instance:
http://tile.openstreetmap.nl/?zoom=18lat=52.1696lon=5.39063layers=B00
http://img137.imageshack.us/img137/1024/rotonde2.jpg
It has nodes every 10m or so, so I think I'll recommend it to the guy who draw
that roundabout instead of every 30cm ;-)
Thanks!
Minko
On the dutch osm forum this particular roundabout has raised some questions
about how mkgmap deals with filtering those nodes. Does it calculate an avarage
position of a cluster of nodes that are (too) close to each other and group
them into one node? Is this the reason why those jagged lines
Yes, I'm using remove-short-arcs.
If I don't use it, mkgmap generates a lot of error messages. However, the
roundabouts with too many nodes remain jagged like a drunkard has mapped them
;-) If I specify remove-short-arcs with a high number (say 5 or 10) the
results gets worse.
-
Thanks Johann,
I already tried several settings of reduce-point-density, but this seems to
have no effect on the shape of the roundabout at all.
Regards,
Minko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman
Roundabouts with nodes 8m from each other are rendered fine.
But if the nodes are closer to each other mkgmap doesn't seem to translate them
very well to the lower resulution of the Garmin grid.
This not only happens to roads but other elements as well, even straight lines
are converted into
I'm having problems with splitting the latest europe.osm.pbf extracts from
geofabrik (5 6 dec). After 25 sec the splitting seems done, normally it would
take one hour. I have tried a smaller section too (Belgium.osm.pbf) but that
looks fine. I'm using Splitter 161.
Hi Maks,
I think it's a Garmin problem, the resolution of the Garmin's are not as fine
as on Mapnik.
See also this subject which is quite related to your question:
http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg07459.html
___
mkgmap-dev
Thanks, I'm following the discussion on talk-de. I just splitted
netherlands.osm.pbf (08-Dec-2010 02:40) and it seems all the relations are
gone. Lines and polygons are ok. I also mailed Frederik about this. The
splitted europe.osm.pbf (benelux area) from today showed only some pois. BTW im
could solve this but it unfortunately it
couldn't.
Is there another way to merge this coastline to the splitted osm tile?
Cheers,
Minko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
the floodblocker did his job very well. All the sea
except one tile disappeared.
Thanks for your advice, I will test it now without the floodblocker option and
with extend-sea-sectors (without no-mp).
Minko
___
mkgmap-dev mailing list
mkgmap-dev
Thanks Felix,
I tested it now with:
extend-sea-sectors,close-gaps=6000,floodblocker,fbgap=60,fbthres=200,fbratio=0.6,land-tag=natural=background
No errors and sea polygons came back, but the floodblocker blocks still too
much.
I've tried it with other fb numbers but it still gives the same
Thanks Wanmil,
Those images explained very well what exactly happens.
So what I can do is to add more coastline to the benelux osm data
to prevent that this coastline is intercepting itself.
I have to merge osm data (German coastline) to the osm data from the Benelux
extract.
How does this work
That will be great! I suppose somebody already uses this option?
Is there a German coastline available?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Wanmil,
Just letting you know I solved the floodings problem.
My tile borders stretched too far east, far beyond the extract.
By ending it more to the west, the sea disappeared :-)
I even didn't have to use a floodblocker.
Thanks for your help!
Minko
- Oorspronkelijk bericht -
Van
Hi,
Any news about this problem (which still exists)?
aighes wrote:
It seems to be an error in extract-file. Osmosis has also problems Frederik
is informed about it (talk-de) and will take a closer look to it.
aighes
--
View this message in context:
Until 2 Dec. everything went ok with splitting the binary europe extract.
Splitting took me about 1 hr on a modest laptop (windows vista). After 2
December
there were some problems with the country extracts as well, but they were
solved.
It looked like they did some changes with the
http://mijndev.openstreetmap.nl/~ligfietser/openfietsmap/Scripts/osm_bnl.args
Hope this helps,
Minko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Steve,
I removed road-name pois, but it didnt help.
Mapsource still crashes.
Does it solve the problem state/province on the newer GPS units (as well as on
the nüvi)?
Thats the reason why I use road-name-pois, to search for addresses via pois.
___
in different languages, like default_name:eng=soccerfield;
default_name:nl=voetbalveld etc
I have tried this but that didnt work. Is it possible by some kind of regular
expression?
Thanks,
Minko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
to the address search problem,
but maybe it helps.
Cheers,
Minko
- Oorspronkelijk bericht -
Van: Minko
Aan: Development list for mkgmap mkgmap-dev@lists.mkgmap.org.uk
Verzonden: Dinsdag 11 januari 2011 13:21:48
Onderwerp: Re: [mkgmap-dev] Improved street search in index branch
Hi Steve,
I
Yep, it works now, no more crashes!
Steve wrote:
@Minko: can you confirm this is your problem?
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
be the the same, and the map numbers
were higher with my maps as well.
I also found out recently that the --show-profiles=1 option works now within the
map (thought it only worked with a separate contour file map, not a combined
one).
Cheers,
Minko
- Oorspronkelijk bericht -
Van: charlie
Tested splitter-r161-3 on the latest europe.osm.pbf, it is working now, thanks!
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
,floodblocker,land-tag=natural=background
The maps can be downloaded here:
http://sites.google.com/site/openfietsmap/downloads
Regards,
Minko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
available is always better than no
typ file at
all.
Regards,
Minko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I think we also need to look what kind of definitions Mapnik is using. The
default mkgmap Garmin map should look the same, in order to prevent that some
cycleways on the Garmin are footways on mapnik.
Sorry about the tracks, better leave highway=track displayed as track, if the
track is
they are thin white lines with
line as label.
On a white/grey background almost invisible. :-(
On a nuvi 0x16 are thin grey lines. On a Dakota it's a thicker, grey dashed
line,
same as unpaved roads.
This shows once more a typ file is absolutely needed to keep up with the
changes on osm.
Regards,
Minko
Marko,
I think it's a good idea to display cycleways as 0x07 (alleys according to
garmin).
I treat pedestrian the same as footway too, because many mappers use one of
these for exactly the same roads. How about highway=service?
I suggest to display them as type 0x06. Maybe with a
Henning,
Did you try a higher overlap setting?
Maybe --overlap=6000 ?
--overlap
Nodes/ways/rels that fall outside an area will still be included if they are
within this many map units. Default is 2000
___
mkgmap-dev mailing list
Hi Valentijn,
Here is an easy fix: the performance gets worse the smaller the tiles get.
With max-nodes=150 I am able to split the Netherlands in a way that mkgmap
didnt get stuck on too many nodes, and the routing is better in comparison
with more tiles and max-nodes=100
Tested it on a
Hi Jeroen
In your lines style I see 30 lines of code to render tunnels [0x12].
You could do this with one line as a layer on top of each highway:
(tunnel=yes | tunnel=true) (railway!=subway | waterway!=*) [0x12 resolution
23 continue with_actions]
This way you don't need to specify each road
date,
(which is the series-name). The default directory and Mapsource registers
should be
kept the same mapname every time, usually this is always the family name.
Can this be changed?
Cheers,
Minko
___
mkgmap-dev mailing list
mkgmap-dev
to navigate via the osm roads, just the basemap.
This doesn't look good. Maybe it has to do with the latest revisions?
(mkgmap-r1827). I have tried this before with other mkgmap versions but never
had such problems.
Regards,
Minko
___
mkgmap-dev mailing list
After reflashing the firmware the routing problems have gone
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Jeroen wrote:
- other paths were green, now yellow
On a yellow background? Hard to see I guess ;-)
You can try to use extended line types like 0x100/00-1f 0x101/00-1f etc
Note that even with a typ file some of them will not show up on some devices,
and they are not routable. See my typ files on
is clearly on the map: not
found
Searching for a streetname: found, but often located in the wrong place.
Cheers,
Minko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Steve,
The bug that some street names where placed under the wrong place names
already existed with the option road-name-pois (didn't use this option
for my last test). Sometimes it even happens if the node with the correct place
name
is located closer than the wrong place name which is
With a Dakota or Nuvi,
Search for a address,
city Du -
Düffelward, DEU found
Enter Street:
F-Fährmannsweg-No matches found
E-Ehlenstrasse-map is shown
So it looks like when there's an umlaut
involved it is shown in the index, however
it can't locate the street on the map.
Minko
Chris
Hi,
If I use the option --make-opposite-cycleways or --make-all-cycleways,
an extra label is placed with street (cycleway). Is it possible to turn this
label off or make it invisible in the style line file and how?
Cheers,
Minko
___
mkgmap-dev mailing
PS please ignore the tag opposite-cycleway!=yes that was just a test if rule
one was applied don't use rule 2,
because I thought maybe in rule 1) if oneway is set to -1 it automatically
implies that the next rule will be executed too?
It should be:
highway=unclassified oneway=yes
Hi Jean-Marc,
Im using an areas.list-file for the Benelux, you can use this to split the
europe.osm.pbf
See areas_bnl.kml and areas_bnl.list on
http://mijndev.openstreetmap.nl/~ligfietser/openfietsmap/Scripts/
I've also made a bigger areas.list that divides the bnl in 3 sections:
north, middle
Hi Charlie,
I recently noticed that my method of leaving the mapname: etc out didn't always
work
as expected :-(
What always worked for me, was saving the contourlines files as *.mp instead of
img with
gpsmapedit. My contourlines are transparent but can have the same draw priority.
Process the
).
It will also mean that you always store the map in the same folder, because
you can keep the family name the same every time.
Cheers,
Minko
--
Steve wrote
OK, but this is a bit confusing... it needs to be
+ familyName = args.get(family-name, OSM map);
and then any other change
Found another bug in mkgmap-r1875.
If I search for adresses on a Dakota, and skipping the place name (because
often streets are assigned to the wrong place) and enter the streetname, the
street is found but it points to a place in the Atlantic Ocean south of Ghana
(lat0, lon0).
Where can I find the help file?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I've now tested r1877 but noticed almost all the forests in the Netherlands are
completely gone at resolution 18 :-(
I've tried it with and without --reduce-point-density-polygon but it seems to
have no effect.
Is there a way to set this parameter off?
Felix,
You have recently introduced so many changes I can't figure out anymore what is
causing what.
How can I change the settings of drop small polygons? It's not described in
the help files.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
.
Thanks,
Minko
Felix wrote:
Read rev 1875, and change the 8 to a smaller value. You have to do it in
source and compile mkgmap yourself of course.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap
for more languages.
The other improvements are working fine as far as I can see.
Cheers, Minko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I'm not sure but maybe the code 0x11f02 isn't supported?
I used to do the same with roundabouts but I named it 0x0c04,
in my overlays file:
0x0c04: 0x0c, 0x04
This was routing fine.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
PS
Those two lines were missing:
WriteRegStr HKLM SOFTWARE\Garmin\MapSource\Families\${REG_KEY} TYP
$INSTDIR\$x.TYP
DeleteRegValue HKLM SOFTWARE\Garmin\MapSource\Families\${REG_KEY} TYP
typfile=x.typ
___
mkgmap-dev mailing list
Hi,
I'd like to see it commited because I want the old layout of the map back.
I don't like the 'a quick and dirty approach', the map looks very ugly now at
lower zoom
levels, shapes look very distorted and forests are completely gone.
Am 08.03.2011 14:57, schrieb Minko:
Hi Johann
Thanks, Steve.
Could you also commit Nakors latest patch regarding the installer which
includes the typ file into the windows register?
I think it's quit urgent when you use a typ file (he forgot that in the patch
that was commited)
Cheers, Minko
- Oorspronkelijk bericht -
Van: svn
map I'd like to know what style definitions works best in other
surrounding countries (Germany, Belgium, Luxemburg)
Cheers, Minko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Nakor,
I suppose you need to put this installer template into a installer
subdirectory, like 'mkgmap-r1894\resources\ïnstaller\' ?
Nakor wrote:
To customize the installer script one need to create a resources directory
___
mkgmap-dev mailing list
Is that possible, different maps with the same FID and different PID?
I thought only one Family ID can be used in Mapsource.
btw, I tried to adapt the template but mkgmap can't find it, where do I have to
put installer_template.nsi?
I've tried it in a resources folder and in resources/installer
If you update map_X with FID=x with PID=1, there will be an uninstall.exe in
the folder
of map_X. How would that work with a special layer of that map_X with PID=2 ?
I had a look on your map files, but can't see an installer for the srtm layer.
Let's assume you only want to update the base layer
Thorsten, I have now tried to install your bicycle layer, but this gave several
errors
in Mapsource and the map didnt show up.
Duplicated FID, TYP file not found, productcode in registry doesnt match with
tdb file.
Looks like its not possible to use the same Family ID's on different maps.
Thanks Nakor, it worked. Maybe add this to the option help file because it's
not very clear.
Or make it possible to specify another location where the template file is
located in the --nsis option?
--nsis=..\template\template.nsi
More improvements:
If you put a /S when running the installer,
Small edit in the Dutch language string:
LangString AlreadyInstalled ${LANG_DUTCH} ${INSTALLER_NAME} is reeds
geïnstalleerd. $\n$\nKlik op `OK` om de oude versie te verwijderen of
`Annuleren` om deze update te onderbreken.
___
mkgmap-dev mailing list
1 - 100 of 835 matches
Mail list logo
