Hi,
I'm trying to compile a map of USA using North America extract form
Geofabrik. I use splitter r427 with bounding polygon, something like that:
splitter --polygon-file=usa.poly ... north-america-latest.osm.pbf
The result is that I get errors in mkgmap:
SEVERE (MapFailedException):
Hi Greg,
> It might be nice if we could ABBREVIATE road names
> in the Default style
Your example works only for English and isn't suitable for universal
style, because it can damage valid names in other languages.
You can add conditions like mkgmap:country=USA but then it could all
became
Hi Gerd,
> 3) When the housenumber functions add new nodes to the road to
> improve the address search, these nodes may be > 1m away from
> the overlay line.
Maybe do not add nodes? Or limit these nodes to cases with random numbering?
I guess GPS finds position of an address as an
Hi Walter,
> since Garmin does not support Unicode,
> I have to use at least different codepages for Europe.
I use CP1252 for Europe and English/international names whenever
possible. I think it is the best compromise, especially because some
devices do not support required code pages, like
Hi Gerd,
I guess you already got very complicated code ;)
I'm not perfectionist, I would accept some errors in processing. For
example address placing precision could be in range 20-50m. If there is
a node in this range, I would try use it for multiple addresses.
I'm afraid that inserting a
Hi Walter,
> At the moment I am looking for a solution for 2 very big parts,
> which are in total bigger than 4 GB.
There is no problem with big maps, just do it. All tools support them -
splitter, mkgamp, BaseCamp + Mapinstall and current GPS. I create map of
Europe, which is about 11GB, it
Hi Arndt,
> BC shows not only the gmapsupp, the BaseMap from the Oregon
> is shown too.
BaseCamp shows only single map plus gobal map from PC. But detailed map
should hide global map. If you see them both, then maybe your map has
transparency flag set?
--
Best regards,
Andrzej
Hi,
I guess Garmin img format allows for many non-standard solutions, but I
would be afraid to implement them into standard compilation. It could
lead to unexpected problems, difficult to trace. My last experience with
using routable lines as no-routable objects for addressing is following:
Hi Gerd,
> I am not sure what you did and what "routing doesn't work" means
> in this case.
My map was similar to the experiments, that you have analyzed here:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2015q2/023244.html
Only I have added relatively small number of non-routable lines with
Hi Gerd,
> The patch implements a way to have a line
> with a routable type that appears in NET but not in NOD.
> In other words, the NET file doesn't contain a pointer into NOD.
I only express concern, that it could break routing, because it looks
like a quite non-standard approach.
--
Best
Hi Gerd,
I would go for a) - only correcting source text form OSM.
I think correct style shouldn't create wrong lables. And author of style
could use double spaces intentionally, in which case there would be
needed an option to disable second correction and proper explanation in
manual. IMHO
Hi Gerd,
I think you can perform standard cleaning for each name or label,
removing leading, trailing and duplicate spaces. Maybe there are even
more similar corrections, which could be applied.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
Hi Gerd,
> I think 1st I wanted to point out that the "mop up" rule
> should be removed, it is likely to produce wrong routing.
I doubt it could make a really bad routing, it is nearly the lowest
category of road anyway. As a result IMHO it goes to personal
preferences, whether to use it. Do
Hi Gerd,
> Most of these ways are areas, but don't have the area=yes tag.
> I am not sure why the "mop up" rule would ignore them when the
> area=yes tag exists.
I'm not sure if I understand your problem, so following are my
observations only.
Area described as a highway could be a
Hi Bernd,
I agree, shield with a name doesn't work well on nuvis. I prefer to use
only street name without reference number. Reference could be added as
secondary label for address search or as a first label on upper layers
of a map.
I'm not sure if problem with nuvi is important enough to
Hi Dave,
when you search for all POIs, then GPS look for all POI that are near
your current position. It doesn't use index for that kind of search, so
you can't exclude POIs selectively. You would have to remove them form map.
You can try to search for a category of POIs or search by name to
Hi Carlos,
the best solution would be to correct errors in OSM data. Polish mappers
got a site, which shows all addresses, that needs to be corrected. Maybe
you can ask Spanish community to do something similar?
See:
http://v3.mrowka.org/adresy/#7/52.298/19.199
--
Best regards,
Andrzej
Hi Gerd,
The tag mkgmap:road-speed-max=* is only evaluated
by mkgmap when the tag mkgmap:road-speed=*.
If mkgmap:road-speed is not set, the value in
mkgmap:road-speed-max is completely ignored.
My early proposition for limiting speed looked like this:
... { set mkgmap:road-speed='-0'; set
Hi Bernd,
Maybe if i try to '+0'
My guess is that simple +0 is a number while '+0' is a string, and
probably mkgmap:road-speed expect a string. So I suggest to try:
mkgmap:road-speed='+0'
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
Hi Gerd,
I think the advantage of my version is that it doesn't override
an existing mkgmap:road-speed=* tag.
Yes, I have noticed. Maybe that kind of action would be simpler:
... { add mkgmap:road-speed='-0'; set mkgmap:road-speed-max = 2 }
I think that making mkgmap:road-speed-max
Hi Felix,
Another possibility would be to decrease the road speed at the
turn/intersection by 1 or 2 levels - then have the turn/intersection.
At road-speed 0 or 1 it is already much better - and the overall time
for the way will decrease! (if you have 10meters in and out of the
turn with
Hi Alexandre,
You can search for street Rua Porto Alegre to see the problem
what data are you using for compilation? I have tried to find this place
on OSM, I think this is actually Rua Manaus in OSM, with no house numbers:
http://www.openstreetmap.org/way/93121424
--
Best regards,
Andrzej
Hi Alexandre,
I confirm, that there is no address on your map with current mkgmap.
Data seems to be OK, so lets wait for Gerd opinion.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi Felix
isn't it device problem? It happens to me form time to time, I have
always assumed, that device remembers all map-id (tile id) ever used and
sometimes gets no memory for a new one. Device reset cures this problem.
Maybe you have changed range of map id for some maps and this caused
Hi Gert,
map on PC and gmpasupp.img, both include subfile *_mdr.img, which
contains search index. They are similar but not the same. MapInstall and
Mapsource convert file form PC to format needed in gmapsupp. Mkgmap can
create both versions.
--
Best regards,
Andrzej
Hi Gerd,
Hmm, splitter keeps most mp-relations complete, we only
exclude some boundary relations.
I see. But maybe potential increase wouldn't be that big, if you add
boundaries?
Or maybe you can preserve only some levels of boundaries?
Or you can use boundary data form --bounds option?
Hi Gerd,
When you use --add-pois-to-areas mkgmap will generate
a POI based on the existing data, and this POI will have the
tag place=city (for the example), so for each tile we calculate
different coordinates for the city POI.
Not only cites but all polygons can get duplicate POIs.
Hi Steve,
I don't understand this. If you have no --levels option then the
default should be used, which has a maximum of 4.
Looks like there is no defaults now, or maybe only level 0 gets a
default resolution.
What do you think that the message text should be?
Maybe something like
Hi,
I have defined a rule in style like this:
highway=path [0x16 road_class=0 road_speed=0 level 0]
When I compile map with --levels=0:24, then I get paths correctly.
When I use option --levels=0:23, then paths are missing.
I would expect paths on level 0 regardless of resolution.
--
Best
Hi,
I think problem is with initial conversion levels - resolution.
I thought, that levels in style are depreciated, but Steve's suggestion
works, I get correct results when using proper levels inside options file.
If I delete levels form style, then command line values still aren't
used.
Hi Gerd,
I'm satisfied with current solution. I think the problem arise from
micro-mapping, where many linear features get area shape. Since we
usually have both approaches, line and area, we needn't to converted
area to lines.
Some idea how to check area: find any nodes, where routable
Hi Gerd,
The apply tells mkgmap to add the tag area=yes to the members,
and I think that's what you want.
This was my first thought too, but:
Note that the members of the
mp-relation are not the members of the original OSM relation, they
are the artifical ways.
Apply adds tags to
Hi Gerd,
I agree that it looks strange,
but it works when you use apply like this:
type=multipolygon highway=* { apply { set area=yes; } }
As I understand apply deals with relation's members, which aren't
highways at all. I have already tried apply but this is simply wrong
approach.
Hi All,
I have stuck at following problem:
There is relation 4764899:
type=multipolygon
highway=footway
Line 336969927 as inner
Line 336969921 as outer
This is an area, probably it should include tag area=yes, but actually
it doesn't. Mkgmap creates a new polyline from multipolygon
Hi Gerd,
If any element processed later has a name like ABC street or abc
Street which we consider as a street name, we will use Abc Street
again.
I'm not sure what for are used names from this table. I don't think that
case could be important for comparison of street names. But I would
Hi Gerd,
2) A road may be the border or very close to the border of a city.
Houses on the left side are in city A, houses on the other side are
in city B. I think in this case we should add the road twice to the
map so that address search works.
A road at the border of 2 cities can have 2
Hi Gerd,
I see that discussion has gone further, do you still need example of a
map from cgpsmapper?
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd,
It doesn't require much code to generate the pseudo roads,
so maybe it is something for a special option.
Would be nice, if you preserve this code. Maybe even for all addresses,
not only for addr:place? But actually I can extract addresses form OSM
sources, parse them, convert to
Hi Gerd,
If you have to buildings on the same side of the road
so that distance between the houses is smaller than
the distance to the road, MapSource will select the pseudo
road.
I confirm, this doesn't work in Mapsource. Probably there is some
influence of NET on routing. Isn't it NET,
Hi Gerd,
I think this is plausible, the routing algo searches for the closest
road and tries to build a route to the other house, but that fails
because it finds the pseudo roads which are not routable (2 and 3) or
not connected to the road network (4).
This is not how Mapsource usually
Hi Thorsten,
I don't know about Mapsource, but this is how the Garmin GPSMap 62s
behaves. It is looking for the nearest road, whatever this is, and
tries to route from that. If this nearest road is not connected,
you will get a routing error.
I know about this. There is some distance range
Hi Gerd,
that's why I asked for samples this morning
Sorry, I missed your request. Maybe because I don't manipulate maps ;)
This is a straight compilation by cgpsmapper, where I add short
non-routable road for each city in mp source. I have quoted example in
previous mail.
I can try to
Hi Gerd,
problem is interesting, I gladly investigate.
I can confirm, that there is maximum distance off road, where Mapsource
still finds routing on road. Could be like 100-150m.
I have created a single example of map with point addressing. It consist
of 2 routable roads and 4 non-routable
Hi Gerd,
routing doesn't work
when I use the addresses as waypoints for the route :-(
I'm not sure what are you doing. I think Garmin can calculate a route
through any points, regardless if they are on road or not. When using
address point outside road, it calculate route to the nearest
Hi Gerd,
see attached picture from cgpsmapper map. I get this route in Mapsource
this way:
I start new route from Edit menu.
I add 2 points using search address function.
I click at recalculate button in route window.
The only difference that I notice is that my addresses uses a non-zero
Hi Gerd,
I have to find out how to add MapRoads to NET without adding
them to NOD without messing up the pointers.
Maybe you could check if road have defined road_class? My guess is that
road_class is needed in NOD but not in NET.
--
Best regards,
Andrzej
Hi Gerd,
If fear when I add invisible and roads and don't add them to the
routing network routing to such an address will not work.
It works for me. I create routable map with cgpsmapper, where I add
objects like this for each city:
[POLYLINE]
Type=0x13
Label=DOBRZEWINO
CityName=DOBRZEWINO
Hi Gerd,
I'm trying to minimize map size and I feel, that trim can help a bit.
Probably I'm wrong, these are empty parts anyway. Thanks for advices.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi Carlos and Gerd,
I tried once bounding poly in phyghtmap and it didn't worked for me. I
don't remember what was wrong. No problems with osmosis.
Now I need some solution for trim. I get usable split with polygon-file
in splitter, but I'd like to remove empty areas. Is trim in splitter
Hi Gerd,
I don't want to see the ref when I am searching for an address.
If possible, I want to see it and be able to search for it
when searching for a road.
When creating search index, shield could be separated from street name
and both elements added to search index independently.
It
Hi Gerd,
there are two problems. First is if we should add road reference to road
name. Second problem is conditional - if we add a reference, then should
it be searchable?
On my map I don't add reference to name. I put reference in second label
if name exist and in first label if it
Hi Gerd,
I tried to combine the previous versions to one that looks plausible
to me, see attachment.
Looks good to me.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi,
I agree that we can remove the extra lines to delete maxspeed.
Roadspeed is included at finalize stage. Most processing of highways and
railways is done before it. Deleting of maxspeed at this stage shouldn't
have any negative impact for default style.
The cautious solution would be to
Hi Michael,
I don't know about outdoor devices, I disable autozoom on them.
In nuvi the idea is quite simple, it uses 3-4 ranges of speed and
remembers zoom that you have set at that speed. So you can tune autozoom
behavior.
--
Best regards,
Andrzej
Hi Gerd,
I think these two rules
maxspeed~'.*:urban' { set maxspeed=50 }
maxspeed~'.*:rural' { set maxspeed=90 }
make it impossible that these 4 rules will ever fire:
maxspeed=AT:rural { set maxspeed=100 }
maxspeed=DE:rural { set
Hi Bernd,
maybe this rule works as you expected, but it is a catch all, i don't
like them ;-)
Right, catch all doesn't look safe. Probably would be better to change
maxspeedkmh()!=* to maxspeedkmh()120.
I think setting mkgmap:road-speed-class is only needed for the
highest value,
Hi Bernd,
first question, what should this rule do?
maxspeed=* maxspeedkmh()!=* { delete maxspeed }
This rule deletes tag maxspeed if we can't assign a numeric value to it.
the last rules should be
maxspeed up to 120 kmh
maxspeed=* mkgmap:road-speed-max!=* maxspeedkmh() = 120
{ set
Hi,
one of threads reminded me about roadspeed include in default style.
As far as I understand, Garmin maps made by mkgmap contain average road
speed, which can be used for calculation of arrival time.
Include roadspeed deals with speed limits and convert them into value,
which is then
Hi Bernd,
No didn't work. only the description of the last layer is visible
on the device, see the attached screenshot 106.jpg
Are you creating multiple maps from single template.img?
Template.args include mapname, which overwrites definition, that you
give as mkgmap option. This results in
Hi Bernd
you can't get something like
bonn_20150503_1700_basemap oder bonn_20150503_1700_fixme,
only the description you set in template.args
I'm not sure if I understand your problem, since solution looks simple
form me - add required description after template.args, like:
... mkgmap.jar
Hi Gerd,
How should we handle missing information?
You can't guess if there is no house with missing number or there is one
but not mapped in OSM data. So none solution would cover all cases. I
would take the solution, which looks better in your code ;)
What do you think about implementing
Hi Gerd,
The question is if the users prefers to see that we are guessing
or not.
I think that general rule should be to create maps faithful to input
data. But in this case I'm not against relaxing the rule, if this
simplify map a bit.
Is is possible to have roads in NET and index etc.
Hi Gerd,
I see no reason why we should not add the overview map
to the gmapsupp if that is what the user wants
and the device is working fine with it.
There is no need to add overview to gmapsupp. It can be copied as a
separate file to GPS with the same result. Or user can merge overview
map
Hi Ralf,
Is this possible on gps units which support only one map file?
It is possible on all current outdoor GPS and nuvis but probably not on
eTrex Legend HCx. You would have to merge img. It can be done with
mkgmap or GMapTool.
--
Best regards,
Andrzej
Hi Dave,
Garmin format as used in img allows only for equivalent of oneway=1.
Mkgmap have to reverse line direction in case of oneway=-1. So you need
only one pattern in TYP file, with arrows pointing form left to right.
Actually it means arrows pointing from start of a line towards its end.
Hi Ralf,
- When I enable the basemap I see my map in zoom levels 8km and below.
From 12 km and above I see the basemap.
- When I disable the basemap I see my detailed map tiles in zoom levels
120km and below. It shows way too much detail and it takes very long to
draw the map.
That's how map
Hi Ralf,
What is the advantage of using more map tile levels instead of putting
them into the overview map?
This is a standard design, supported by mkgmap and Garmin tools. Yours
is not, so you have to do some additional work. Isn't it the reason, for
which you have started this thread?
Hi Ralf,
Without the overview map in the gmapsupp.img my eTrex Legend HCx
displays only the yellow background and the tile borders (no map) on
all zoom levels down to 50 km. From 30 km onwards it displays the map
tiles.
You probably have deleted or disabled in menu Garmin basemap. Please
Hi,
in my opinion stopwords sholud be dependent on country code and should
be defined in style or in definition of local parameters, the same way
like zip code before street name.
Style would be preferred, since definitions can be included in default
style, where contribute many people.
Hi,
What about multi-lingual countries such as Belgium or Switzerland?
Good remark. I think we can set mkgmap:stopwords directly too, without
defining intermediate variable for language.
These definitions would be evaluated per each object, we could change
stopwords when using for example
Hi,
I can't imagine someone wanting all the languages in the map at the
same time. Can the Garmin format even handle that?
City Navigator maps support multiple languages. Street names change,
when you change language settings in GPS. For example, if you use
German, then street name is
Hi Gerd,
Or do you see a simple way to limit the
iteration to a part of the way near the wanted point?
I have looked at algorithm here:
http://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm
It looks simple, it calculates error to grid at each step by adding a
value representing ascent
Hi Gerd,
looking at Kompakte Variante i think that for each calculated point
(x,y) this is true:
err = (x - xS +1)*dy + (y - yS +1)*dx
where xS and yS are start coordinates - initial value for x0, y0.
If you find arbitrary intermediate point on the line and round its
position to nearest
Hi Gerd,
I guess it is about small distances, this part of makeBetweenPoint():
// distances are rather small, we can use flat earth approximation
int lat30 = (int) (getHighPrecLat() + dLat30 * fraction);
int lon30 = (int) (getHighPrecLon() + dLon30 * fraction);
return makeHighPrecCoord(lat30,
Hi Gerd,
one more notice - for splitting very short lines could be better to
calculate intermediate point using grid coordinates of line instead of
high precision like in makeBetweenPoint().
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
Hi Gerd,
I have attached picture with 2 lines split around middle point. Upper
line is about 50m, lower 500m. Both have delta_lat equal to 1 grid step.
I don't think that splitting make big problem here.
If you allow for 10m of offset for splitting point, then Bresenham's
algorithm has to
Hi Jürgen,
any news about my test file?
Garmin has released new update for some models of echoMAP:
http://www8.garmin.com/support/download_details.jsp?id=4749
I'm trying to download this update:
http://www8.garmin.com/support/download_details.jsp?id=4763
but link to exe is broken. Maybe you
Hi,
see this post:
http://www.boote-forum.de/showpost.php?p=3760543postcount=42
It seems that version 4.0 of firmware was affected and bug remains after
upgrade from 4.0 to 4.2. But when upgrading form 3.40 to 4.20 directly,
OSM maps work correctly.
--
Best regards
Hi Jürgen,
Achim (the guy with the Echomap) cannot test it within the next two
weeks. But I asked him not to forget to test it, anyway. I am also
curious about the test maps even though we meanwhile have a solution
for the problem.
Would be interesting to know which maps works. But I rather
Hi Greg,
I was reacting to the notion that fixing the railway station
rendering didn't belong in the default style.
I hope I have never suggested it? I have voiced some opinions about
purpose of default style but not about this particular bug. I have no
doubts that it should be corrected in
Hi Gerd,
... [0x14 resolution 22]
I suggest to add a comment, that most devices display object 0x14 only
on layer 0 (or resolution 24? I'm not sure) and it can be invisible at
resolution 22.
This could prevent some surprises.
--
Best regards,
Andrzej
Hi Jürgen,
I would gladly investigate problem but have no affected device. I will
wait patiently, thanks.
My map works in HomePort, but I haven't prepared gmapsupp.img for this.
You can correct img with gmaptool, like in this example:
http://www.gmaptool.eu/en/content/map-visible-basecamp
Hi Jürgen,
could you please test this map:
http://files.mkgmap.org.uk/download/251/gmapsupp-marine.7z
This a map from OSM data but recompiled with cgpsmapper. It uses
different parameters in TRE than maps from waterways.cz.
--
Best regards,
Andrzej
Hi Enrico,
Garmin maps have limited resolution, about 2.4m. One can't draw
precisely a line, which length is near to this resolution.
You can try to assign the same Garmin object type to all these segments,
then probably mkgmap will be able to merge them and smooth.
--
Best regards,
Hi Max,
I like your idea, but application in style doesn't look good for me.
Wouldn't your rule add a superfluous comma, if name repeats?
What I really would like to have, are conditional statements inside
apply{} block. This could be used not only to parse name, but for
example to examine
Hi Max,
from your explanation I get, that presence of a tag value is tested
after processing with your filter. If this is the case, then there is no
problem with comma.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
Hi,
I have never tested gmapsupp.img created by mkgmap. I have used
MapInstall to create gmapsupp from map installed on PC and it worked
well enough for me.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi Walter,
The last commands in polygons file are
natural=sea[0x32 resolution 14]
natural=land [0x4b resolution 14]
Don't use object 0x4b in style, mkgmap should create it automatically.
Use lowest priority for 0x4b in style or define only color without
giving a priority to polygon
Hi Walter,
some clarifications: object 0x4b is a special kind of polygon, it is
used as a map background and covers whole map area. You should not use
it in style, because it is created by mkgmap (except for transparent
maps). You can use polygon 0x4b in TYP to change background color of a
Hi Walter,
I have tried with linetype 0x1901, but I could not address it neither
as 0x1901 nor as 0x11901.
I think there is no subtypes for line 0x19. Line 0x1901 is probably
created as 0x19 (or 0x1900). You can use lines from 0x01 to 0x2b and
then from 0x10001 up. Try for example 11901.
Hi Gerd,
3) or stop with an error message that tells the user
that it is not possible to split with the used resolution
Seems to be the best solution. Let user decide how to proceed.
You could include some advices in final message, but the choice of
solution depends on user requirements,
Hi Gerd,
we are not interested in the exact solution
See example from QGIS plugin, function centroids(self):
https://github.com/zsiki/realcentroid/blob/master/realcentroid.py
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
Hi Gerd,
when using --add-pois-to-areas I would prefer to get a point inside a
polygon. See some ideas here:
http://mathoverflow.net/questions/56655/get-a-point-inside-a-polygon
But I accept average as a simple practical solution, in most cases point
will be inside.
--
Best regards,
Hi Mike,
add for mkgmap option --show-profiles=1
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Mike
option --show-profiles sets a flag in TDB file, which is a part of
installation for PC. I'm not aware of any similar flag in img for device.
Original topo maps from Garmin include DEM data, which are used for
computing profiles. This could be the reason, why BaseCamp doesn't
support
Hi Gerd,
I think your calculations are OK for small distances.
You could check latitude spread and switch to more complex calculations,
similarly like you have for distance() function.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
Hi,
I have made 3 simple corrections for reader of Polish mp format.
Proposed patch is included.
1. Line RouteParam= have most parameters optional, oneway and toll
too. Mkgmap should use defaults, when parameters are missing. Probably
there should be syntax check added, but I don't know how
Hi Gerd,
what about a simple solution, that could be used for tests?
I mean to add a support for bounding poly to mkgmap as an input option,
for example:
--bounding-poly=12345678.poly
With this option mkgmap could define tile area as a common area of a
polygon and bounding box inside osm
Hi Gerd,
there are some tasks, which splitter could automatize. But I'm more
interested in getting a working map than optimizing workflow. That's why
I ask to start with mkgmap ;)
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
Hi Steve,
it is a good news, thanks.
Meanwhile I have done some tests with trailing flags, which suggest that
this is not used by Mapsource. Regardless of what I have done, search in
Mapsource remained the same. Or maybe I haven't found a good test.
--
Best regards,
Andrzej
401 - 500 of 709 matches
Mail list logo
