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 s
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 li
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,
> 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 examp
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 tile
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 ma
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 d
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 new
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 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,
- man_made=embankme
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
attribute,
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
used.
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 mkgmap:has-
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 lo
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 di
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 non-
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 quite
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 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,
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
___
mk
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
https://www.mkgmap.org.uk/m
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
___
m
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 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
mkgmap-dev@lists.mkgmap.
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 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,
Andr
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,
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 | highway=tertiary_li
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 mai
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. Actua
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 do
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 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" is
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
mkgmap-dev@lists.m
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. Se
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 a
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 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 "numbers"
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,
Andrzej
Hi Steve,
this is a great news!
I have compiled map of Europe. It looks good and search works correctly
in Mapsource. I haven't tested thoroughly but I have tried address
search and city search in several languages.
Search index for Europe is about 420MB.
When compiling I got some messages,
Hi,
Garmin is changing something in their map locking system. I think this
is connected with Unicode maps. Please check if original Garmin maps
work with these device, for example Winter Activity Map:
http://www.garmin.com/uk/maps/onthetrail#apps
And please report any problem to Garmin suppor
Hi Bernhard,
On PC index is a file with name *_mdr.img, you can remove this file form
registry (probably together with *.mdx).
In a gmapsupp.img index is a subfile with name *.mdr. You can split img
to subfiles, delete *.mdr and then merge subfiles back.
Better Garmin devices have option t
Hi Nick,
MPS record 0x46 ('F') contains family name and FID/PID values.
Record 0x50 ('P') contains FID/PID values and some flags. 'P' could mean
"Product".
Since Mapsource an MapInstall add both records I would do the same, but
maybe 'P' is not obligatory. Or it is some depreciated form?
Th
Hi,
Bernhard wrote:
> thanks for your hints. Unfortunately, it did not work.
I'm quite sure this is the way to remove search index from a map. Maybe
I misunderstood your problem?
Felix wrote:
> I'm not sure if there is an index for POI as well
There is index for selected POIs. I think outdoo
Hi Nick,
my maps for fenix watches are quite specific. I filter data first and
then split with a small number of nodes. I have tripped on this problem
with my maps and then tried to find a simple example for generic data.
Spliter r395 can be used as a temporary solution, but I think there is a
Hi Gerd,
I have looked at your example file in QGIS and Global Mapper and they
show distance like JOSM. I don't know why there is so big difference. My
guess is that it could be caused by spherical versus ellipsoidal model
of the Earth. Maybe you could test algorithms based on Vincenty's
form
Hi Gerd,
> JOSM doesn't display the so called great circle
It's a bit disappointing that QGIS and Global Mapper don't use great
circles either. Probably for faster redraw.
Global Mapper can use great circle for distance tool. Drawing all lines
with this tool I can estimate distance to about
Hi Gerd,
> I use MapSource 6.16.3 and it doesn't show the great circle line
> when I open the attached gpx file.
I can't see your attachment.
Mapsoruce draws great circle for direct routes (select "Use Direct
Routes" in Preferences). I have marked waypoints for LAX an JFK and then
created a r
Hi Gerd,
> Reg. Precision:
> "Correct" results are an illusion.
I don't know what exactly the problem is, so my idea was more generic. I
mean that program speed is only a secondary requirements, I wouldn't
hesitate to use a suitable algorithm even if it makes program slower.
> I am now going
Hi Gerd,
I would prefer regular shape over equal size.
It doesn't matter much, when you use map as a whole, but when you try to
select a part of a map only, then regular tiles help to select required
area.
I would like to get another option in splitter - a maximum size of a
tile set in degr
Hi Gerd,
I have searched a bit and my conclusion is that almost no software use
geodesics (big circle) to connect points. The general idea is, that
shape of a line between points is undefined. Software simply draws
straight line in current projection. It is up to creator of input data
to supp
Hi,
once upon a time I asked for similar feature too. I support Felix with
this request.
Unicode would be a perfect solution for maps, unfortunately I'm afraid
Garmin has made Unicode unavailable for 3-rd party compilers. As I
understand, new Garmin devices require Unicode maps to be digital
Hi Bernhard,
Garmin has 2 version of routing algorithm, older and newer. Older is
used by Mapsource, older nuvi, probably by outdoor devices. Newer
algorithm is used by BaseCamp and last 2-3 generations of nuvi.
Newer algorithm is designed for speed of calculation rather than quality
of resu
Hi,
I would like to split Germany data into 5 tiles. I have added contour
lines and sea area to OSM data but this probably is not important.
My file has about 200M of nodes. If I split with max-nodes 50M, then I
get about 50 tiles, which is wrong.
If I split with num-tiles=5 then bounding p
Hi Carlos,
this was my first idea, I thought that I had missed a "0'. With 500M
max-nodes I get 46 tiles.
I tried max-tiles=4 and splitter failed, no solution.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http:
Hi Gerd,
splitter is a good tool and I'm trying to use it for other purposes than
preparing data for mkgmap. In this case I was trying to compile maps for
Locus. That's why I find unusual problems ;)
It's low priority, I think that using some kind of bounding box or poly
for --num-tiles coul
Hi,
there is other reason to put more detailed condition first. With your
rules for secondary highways, all secondary highways which aren't
tunnels are analyzed till the end of style, quite probably triggering
some catch-all condition like this one form default style:
highway=* & highway!=pr
Hi Enrico,
with your latest rules, secondary highway with tunnel finishes
processing of this object. Try this:
highway=secondary & ( network=e-road | int_ref=* ) [0x04 resolution
18-19 continue]
highway=secondary & tunnel=yes [0x11 resolution 22 continue]
highway=secondary [0x04 road_class=
Hi Enrico,
> I believe this was my intention: up to res 21 I'd like the line to
> appear as 0x04, from resolution 22 it should appear as 0x11 if a
> tunnel, otherwise 0x04 - no further processing is needed. Could you
> pls let me know why the reasoning is not correct?
This is correct. I have ass
Hi,
> I fear the meanings of the --country-xxx options are not well
> documented.
I have once tried to find what are they for but failed. I would suggest
to not use --country-xxx or --region-xxx in command line options. I
think the real definitions are inside style, see include/address file:
Hi Gerd,
I have applied your patch against r414, I hope correctly. I can see this
message:
Exact map coverage read from input file(s) is
(46.7038893699646,-20.071227550506592) to
(60.539002418518066,28.109700679779053)
Exact map coverage after applying bounding box of polygon-file is
(47.2654
Hi Gerd,
I have done some tests, compiling maps with cGPSmapper and using
different TRESIZE value. Then I have measured redraw time of the map in
device.
I think you can observe some effects when decompiling a map with
GPSMapEdit. You can find, that long roads are split with additional
node
Hi,
I have decompiled some tiles of my map with GPSMapEdit. I have found
some points, that shouldn't be there. Points have types, that I never
have used, like for example 0x16401 and some are placed outside of tile
area. This could be an error in mkgmap or GPSMapEdit, I can't tell.
I think p
Hi Gerd,
thanks for checking, I think you are right. GPSMapEdit has no support
for marine objects and I'm using some on my map. Probably there are
problems with decoding features for marine objects.
--
Best regards,
Andrzej
___
mkgmap-dev mailing li
Hi Gerd,
I'm trying to get similar map with mkgmap and cgpsmapper, which isn't
easy, since processing is different. I have compiled some examples of
maps for fenix and tested them in a watch. I haven't noticed differences
between both versions. In both cases redraw took about 5-6 seconds.
No
Hi Gerd,
I have prepared a tile in a way you have suggested. See files here:
http://files.mkgmap.org.uk/download/224/test.7z
Archive include following maps:
29483019.img - map compiled by mkgmap with mkgm-test.bat
29483018.img - map recompiled by cGPSmapper with TreSize=511
29483017.img - map re
Hi Gerd,
I test maps at my current location, which is near the center of Gdańsk,
so it is rather dense map here. This 50% difference was in redraw time
from nuvi menu "Dispaly Map" to fully rendered map. It was about 4
seconds for mkgmap and faster cgpsmapper and about 6 seconds for slower
ve
Hi Gerd,
I have compiled the same map with your patch, file is here:
http://files.mkgmap.org.uk/download/225/29483020.7z
Map is a bit smaller and really has less subdivisions, see comparison:
fist compilation 29483019.img
level 4: resolution 17, subdivisions1
level 3: resolution 18, subdivis
Hi Gerd,
your second patch doesn't work for me. When compiling I get multiple
warnings like this:
SEVERE (MapArea): 29483021.osm.pbf: Point with type 0x2d02 at
http://www.openstreetmap.org/?mlat=54.594173&mlon=18.815332&zoom=17 is
outside of the map area centred on
http://www.openstreetmap.or
Hi Gerd,
patch v3 is working. I have done some speed test on nuvi but conclusions
aren't clear. My feeling is that your original settings is a bit slower
than standard mkgmap. I have tried some values and settled to:
LARGE_OBJECT_DIM = 8192;
int wantedSize = MAX_RGN_SIZE / 4;
This seems to b
Hi Gerd,
my suggestion is to use following priority:
1. If there is option --check-roundabouts then use roundabouts to define
drive-on setting.
2. Use option dirve-on-left/drive-on-right.
3. Use value from LocatorConfig.xml.
4. Set drive-on-right.
When using --check-roundabouts, count "dol" an
Hi Gerd,
I have assumed, that option --check-roundabout gets a new algorithm, the
one that you have described. I would prefer that use of "dol/dor"
counting was controlled by user and option --check-roundabouts looks
prefect for this purpose.
I think that flags in IMG should be consistent, t
Hi Gerd,
> I am not sure if you understand what check-roundabouts is doing.
> It determines whether a roundabout is clockwise or not
> and changes the order if it doesn't match.
I haven't thought about correcting roundabouts. So maybe better leave it
as option to rebuild wrong roundabouts but u
Hi Colin,
> How can we make the behaviour deterministic where the map area
> covers both?
There is no good solution in this case. Gerd is trying to find which
choice would be better, since we are forced to set drive direction for
whole tile.
The proper solution would be to divide tiles at co
Hi Gerd,
> Yes, would be interesting to know how Garmin solves this problem
> e.g. in Africa. I don't know how many roundabouts they have which
> are likely to fall into a mixed area.
Garmin divides tiles at borders, look for example at City Navigator.
cGPSmapper can do this too, you define sha
Hi Gerd,
try this free map of Poland:
http://ump.waw.pl/update/4809.zip
Unpack it and run install_UMP-topo.bat, this will install map for
MapSource. Look at the shape of the tiles at Polish border.
I think there could be some easy solutions for splitter. For example use
existing areas li
Hi,
I can't find references in mkgmap code to relation associatedStreet. Is
it supported?
http://wiki.openstreetmap.org/wiki/Relation:associatedStreet
This relation bounds houses to streets. I think it should be used by
mkgmap to add housenumbers to streets. Relation can't be described in
st
Hi Gerd,
The current algo searches for the closest street
Doesn't mkgmap verify street names of an address and a way? The problem
is that relation can be created *instead of* putting addr:street to node
or building.
See real examples and look at "house" members:
http://www.openstreetmap.or
Hi,
> did you already compile using the patched versions of mkgmap
> and splitter?
No, I have tested before seeing your patch. Patched mkgmap creates
addresses correctly, thanks!
I agree that many of associatedStreet relations are bad, without streets
or without houses. Probably because rela
Hi Gerd,
sorry, somehow I forgot about this patch. I have tested it now and it
works correctly. See attached picture with tiles without patch - big
area - and with patch - correct area around bounding poly.
--
Best regards,
Andrzej
___
mkgmap-dev ma
Hi Gerd,
isn't it a direct fit for Garmin format?
I don't know details, but I assume that cgpsmapper format is very
straight description of internal structure of img. My understanding is
that if you assign house numbers to two consecutive junctions, then GPS
will interpolate addresses between
Hi WanMil,
> up to now mkgmap collects all elements (pois and polygons) tagged
> with addr:housenumber and mkgmap:street (which need to be set by the
> style). The elements are afterwards assigned to the nearby street
> with the same name.
Maybe you could convert a way with addr:interpolate into
Hi Gerd,
I publish some maps of Africa, like East Africa or South Africa. These
are parts of the world, where people drive on left. My default is
drive-on-left, but maps include some small parts with drive on right too.
I'm afraid drive-on=detect could fail for my maps, for example if a tile
Hi,
> do you think that we should count all routable ways?
Maybe this could be better?
But my problem is that your algorithm prefer dirve-on-right. If I use
drive-on=detect, then drive-on-right is selected when detect fails
(regardless of detect algorithm). In my opinion, this should be
conf
Hi Gerd,
> I found another tag that we don't use:
> addr:place
> This is used frequently, but I don't know if the img format
> supports it?
addr:place is used instead of addr:street - some addresses don't contain
street name but name of village instead. I don't think there is
possibility to a
Hi Gerd,
I have compiled Europe with your mkgmap and all seems to be ok. I have
used option drive-on=detect,right and then checked flags in TRE. All
flags are as expected.
One note, this message is probably a typo:
internal error: was that is used in valid restriction relation was
removed,
Hi,
I have decided to try simple solution for this problem. I have modified
addStreet() procedure in file imgfmt\app\mdr\MDRFile.java. While I don't
know all ramification of this change, search seems to work as expected,
see attached picture form Mapsource.
Attached patch is created half-man
Hi,
> I hope this will be committed soon
Me too, but I don't feel experienced enough to commit patches. I hope
developers could review this idea and include it in the code.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap
Hi,
the problem is, that mkgmap creates search index basing on full street
label. This is not the way people use street names. Usually we use
shortened name, for example instead of "Allée Benjamin Franklin" or "Rue
Benjamin Franklin" we remember simple "Franklin". With current version
of inde
Hi Steve,
I have looked at "mixed-index" branch. I see I have repeated your idea,
only in a more crude way.
IMHO you could release this version without optimization for popular
words. This should be already usable.
I would add some ideas. For example you could split label not only on
space
Hi Steve,
I have tested mixed-index branch and it doesn't work for me. Mkgmap
creates bigger index file but search work the same in Mapsource, no
results when searching for partial label. I'm not able to find the
reason. I think function writeSectData doesn't save partial labels, but
I can't
Hi Steve,
what is the reason for using "dirty names" for sorting? You have this
comment in code:
// We sort on the dirty name (ie with the Garmin shield codes) although
those codes do not
// affect the sort order. The string for mdr15 does not include the
shield codes.
I have tried to swap "
Hi Steve,
> This is because it shouldn't make much difference: if A sorts
> before B then A will also sort before B and A will
> sort before B.
But there are more codes, like separation code, which can be placed in
the middle of the label. Or maybe they aren't available in mkgmap? I
have never
Hi,
I have made some minor changes to mixed-index branch, patch is attached.
Like I said before, I think this is workable solution. See pictures from
Mapsource and nuvi.
I have created jar for tests:
http://files.mkgmap.org.uk/download/239/mkgmap.jar
The only feature I have added is a break
Hi,
I don't know details about MDR format but what is bothering me is the
dual format of labels used in creating index. Label can be in Garmin
format, with special codes for shields and some separators, or with
"clean" format, where special codes are removed or replaced by space.
What is unc
Hi Gerd,
Even if I'm not helpful in coding, I'm interested in results of your work.
> most elements are in and around the Czech Republic
There are some valid addresses without streets in Poland too. Rules for
addressing could depend on country.
Adding a name to unnamed roads is usable withou
Hi Gerd,
I like this addition to style, but I can't estimate, how many roads
would get names. I think there are some regions, where streets in a city
lack names. It could be wrong to force names to multiple streets in a
dense urban area. Probably this addition should be used with care and
may
Hi,
> seems to work well with --latin1, but --unicode still doesn't work.
I have assumed, that name offset in MDR7 is in bytes, not in characters.
Attached is a patch for mixed-index branch, which recalculate offset.
It seems to work in Mapsource, both cp1250 and UTF-8, but please check
on y
Hi,
> Selection list is not sorted and some streets are repeated in it
My next experiment to remove repeated streets, patch attached.
And here mkgmap for tests:
http://files.mkgmap.org.uk/download/240/mkgmap.jar
--
Best regards,
Andrzej
--- src/uk/me/parabola/imgfmt/app/mdr/Mdr7.java 2014-12-1
Hi Steve,
> How does this remove repeated streets?
Your code for removing duplicates checks for both: name and partial
name, so I have expanded search key to include both. Seems to help,
probably because of cases, when partial name and offset is the same but
full name is different.
--
Best
101 - 200 of 743 matches
Mail list logo
