Hi Steve,
I don't expect fully working Unicode search yet. But for a map with
multiple countries there is no good solution.
I tried to catch the string, which caused problem. I got '??', when
displayed on console. Probably display procedure does replacement too
and my java understanding is t
Hi,
to make mkgmap finish my map, I have added following line in in file
Sort.java, function setCodepage:
encoder.onMalformedInput(CodingErrorAction.REPLACE);
This has suppressed error, but I have no idea, if result is usable.
--
Best regards,
Andrzej
__
Hi,
I think problem appears at the final stage of creating index, I already
have all tiles compiled and overview map created.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinf
Hi,
this is the message which I get when compiling Asia map:
character encoding failed unexpectedly
There is no other hint, I can't guess which tile gives an error. After
this message mkgmap ends execution. I use current mkgmap r3145. My
options include:
code-page=65001
name-tag-list=nam
Hi Gerd,
IMO it should goes like that:
- Each duplication of a road should duplicate restrictions.
- Any modification of access flags for original or duplicated roads
should be performed accordingly on restrictions.
- Redundant restrictions should be removed, this can happen because of
changes
Hi Gerd,
patch v9 corrected missing cycleways with bicycle:oneway.
I haven't found any other problems with v9, I hope this patch is ready
to release. I appreciate your work, thanks!
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lis
Hi Marko,
> Should we introduce a new type of keys (global keys) that are not
> associated with any OSM object?
This would be handy for conditional interpreting of style.
> java -jar mkgmap.jar --add-default-way-tag=name=unknown
Or maybe that way:
mkgmap.jar --style-option=default_name=unkno
Hi Gerd,
mkgmap:highest-resolution-only works for me.
But I have noticed another problem. Please see this road in the sample I
have attached for v6 testing:
http://www.openstreetmap.org/way/258440157
mkgmap doesn't create opposite cycleway for this road. The same goes for
trunk, patch v6 and
Hi Gerd,
here my idea:
1. Allow for nested conditions in style. For example current lines:
mkgmap:country=NLD & mkgmap:region!=* ...
mkgmap:country=NLD & mkgmap:city!=* ...
could be rewritten as:
mkgmap:country=NLD {
do {
mkgmap:region!=* ...
mkgmap:city!=* ...
}
}
2. Allow for
Hi Gerd,
patch v7 solves problem with second cycleway, support for
make-opposite-cycleways seems to be correct too.
> The artificial cycleways have the tag mkgmap:synthesised=yes
I can't guess how to use it. Could you provide an example?
--
Best regards,
Andrzej
_
Hi Minko,
I know it could be done, it just needs some work and testing. But I
don't expect it will be substantially better then
make-opposite-cycleway, so I have given up.
One question: could the opposite cycleway be limited to layer 0? I don't
see any advantages to extend it to lower resolu
Hi Gerd,
probably patch v6 makes opposite-cycleway obligatory, I get them without
any option.
I have tried simplified version of ligfietser declarations for style and
current mkgmap r3129. This has created a cycleway before original road
with all the problems like in v5. Additionally there
Hi Gerd,
I have tested a bit patch v6 and it seems to be OK.
What is the order of roads if cycleway is created as a duplicate in
style? Will it be the same as order of declaration in style or reversed?
Using style gives possibility to change road type. This is another
factor, which maybe cou
Hi Gerd,
I see, in your example v4 gives worst bicycle route. But it is not a
weird routing, only not the fastest route.
> - for car routing also works, except for the small problem that
> you describe.
I wouldn't say it is a small problem. Any car route to or from an
address, which happened
Hi Gerd,
see my previous comments to v4 patch. I haven't found any problems. I
have downloaded your gdb example and for me routing was correct. There
is a small detour in one route, since it starts on one-way road. But
maybe I miss some other problems?
I agree with you that we can't avoid pr
Hi Gerd,
so actually what problems are solved when mkgmap creates the cycleway first?
IMO the only difference will be at cases like in my example. "Cycleway
first" makes problem for car routing while "original first" makes
problem for bicycle routing. I would prefer proper car routing.
--
Be
Hi Gerd,
I observe problem in MapSoruce and BaseCamp. See attached picture, there
is a route for a car on a cycleway. Second route shows proper result for
a car.
--
Best regards,
Andrzej
<>___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
h
Hi Gerd,
now problem is reversed, cycleway is always found first. If I set
routing for a car, and then I start a route form a point on road with
cycleway, then route uses opposite cycleway. I think previous version
was more safe.
--
Best regards,
Andrzej
___
Hi Gerd,
> maybe the order is important, but if that is the case,
> we would have the same problem for cars if I change the order.
Yes, it is device which should resolve this problem. Maybe Garmin never
put 2 ways at the same place?
> It would be interesting to know how Garmin maps look
> lik
Hi Gerd,
> It seems that both MapSource and Basecamp have problems to find
> the cycle way.
There are 2 roads at the same place. Maybe img is created that way, that
original road is always found first?
I have observed similar problems. Then I have tested routes, which
starts in a node. This
Hi Gerd,
> we are not talking about routable ways here, just
> lines at rather low resolutions.
I think you could simply disable merging at lower resolution, since ways
are already merged at layer 0. But if you want to get additional merging
then still processing angle would be beneficial.
>
Hi Gerd,
> The LineMergeFilter doesn't care about direction and merges
> the two lines.
In my opinion roads that create acute angle shouldn't be merged unless
node has only 2 ways attached. I think processing of angle is essential
for a good merging, see old discussion:
http://www.mkgmap.org.
Hi Marko,
> The action would be placed in the 'polygons' file
I like your idea. Generally speaking, a complex object like a way or
polygon could have actions similar to actions currently supported for
relations.
--
Best regards,
Andrzej
___
mkgmap-
Hi Marko,
> If we think of a building, the shape of its outline is one
> feature, and the location of the main entrance is another.
These object aren't tagged the same way, are they? It isn't a simple
case, where information is duplicated. There will be many ways to
interpret and use this info
Hi Michał,
> But I have similar situation here:
> http://www.openstreetmap.org/#map=17/52.18345/21.00293
This part of Domaniewska street doesn't exist in OSM data anymore. Weird.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.m
Hi Bret,
> So looks like somewhere on the line the logic in mkgmap was
> strengthen to pick up what would be a logic error by having POI
> in polygons.
When you put a definition in "polygons" file, then mkgmap creates a
polygon from this definition. I assume that poi was what you needed, so
mo
Hi,
> It would probably be better to create a grid of subdivisions and cut
> the roads at nodes near the boundary so that there is a lot less
> overlapping. I've no idea how much, if any, difference it would make
> though, and it would entail a fairly substantial re-write.
Do you still consider
Hi Gerd,
I remember that thread, in my opinion counting roundabouts would be the
best solution. Roundabout is the only object, where I have noticed
influence of flags in TRE.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgm
Hi Marko,
> For example, a parking facility or a building could be tagged both
> as a point at the entrance, and as an area.
This is against OSM good practice, see recommendations:
http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element
I guess, that it's not easy to reliable detect dup
Hi Gerd,
> BTW: Way 176844915 was already removed.
Community at work. I'm not a mapper, but I have put a notice there and
someone corrected.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.u
Hi Michał,
> Consider this road:
> http://www.openstreetmap.org/#map=16/52.0071/20.2446
There seems to be a bug in OSM data there, there are 2 ways overlaid, see:
http://www.openstreetmap.org/way/176844915#map=15/52.0021/20.2465
http://www.openstreetmap.org/way/260842529#map=15/52.0022/20.2465
Hi Gerd,
> the problem is that one tile can contain different settings
Isn't it exactly the same for ZIP flag?
Actually most tiles don't contain different settings. I'm creating map
of Europe where a few tiles for over thousand have mixed settings. So
definitely preconfigured setting for coun
Hi Gerd,
I have tried v3 and I haven't found any problems yet. Shape of roads is
correct, opposite cycleways are created, long distance routing works in
BaseCamp.
I wasn't able to create bicycle route on opposite cycleway in BaseCamp
but it works in Mapsource.
I have noticed one unexpected
Hi Gerd,
no I haven't tried v3 yet, my comments were about v2. I will look at v3.
Side note: simplification, that you are using, is quite light. It is
good, but sometimes I would prefer more simplification to get lower size
of a map. An option would be handy. Or maybe reduce-point-density and
Hi Gerd,
I think GPSMapEdit adds a node for each point that belongs to multiple
roads. I have forgotten about this peculiarity.
You are right, img without cycleways contains the same points as img
made with patch v2. I assume patch is correct.
--
Best regards,
Andrzej
_
Hi Gerd,
patch v2 behaves like v1 with preserve-element-order. My comment from
other thread is still valid.
--
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 is a bit better with --preserve-element-order but still not a
complete solution. I have uploaded bigger sample from Paris:
http://files.mkgmap.org.uk/download/186/29467175.osm.pbf
Please look at node:
http://www.openstreetmap.org/node/2650495625
--
Best regards,
Andrzej
__
Hi Gerd,
please try again my sample from yesterday but observe second node:
http://www.openstreetmap.org/node/2650495573
Maybe your patch is valid only for first cycleway but then it goes out
of sync?
--
Best regards,
Andrzej
___
mkgmap-dev mailing
Hi Gerd,
I'm afraid you have damaged make-opposite-cycleway with this release.
Now with this option mkgmap creates a cycleway but original way is missing.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.m
Hi Gerd,
release r3117 seems to be correct, thanks!
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd,
> Attached is a patch for the 2nd approach.
Unfortunately it doesn't solve the problem. See for example this node in
previously provided sample:
http://www.openstreetmap.org/node/2650495573
If I use whole tile from my map, then even the node, which is removed in
sample, still remai
Hi Gerd,
> I see no hardcoded handling of highway=crossing.
My bad, wrong guess and wrong thread.
Problem is due to option make-opposite-cycleway. When used, way gets
additional nodes, which accidentally happen to be crossing. Without
crossing tag, mkgmap behave the same.
See attached sampl
Hi Gerd,
is there any hard-coded processing of points "highway=crossing"? I can
get ride of deformation of roads at these points. I have tried:
highway=crossing {delete highway}
and compilation without link-pois-to-ways option. I use mkgmap r3116, I
always get roads like on attached picture.
Hi Gerd,
> Does anybody have a valid mp file that contains 4 node restrictions
here is attached a small sample with a restriction, this example comes
from http://ump.waw.pl/en/index.html
If you'd like to test a real piece of mp source, I have uploaded full
region form UMP, it include img com
Hi,
one note more: very often U-Turn restriction is defined as 4-points
ABCA, which creates a closed loop. I'm not sure if this would be a
special case for mkgmap.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
h
Hi Marko,
> Anyway, the problem is that the U-turn restriction is ABCD
> (A=from,B=via,C=via,D=to) while BCD (B=from,C=via,D=to) would suffice.
BCD restriction would be interpreted as turn-left restriction for cars
coming from other road, which in most cases would be wrong. There is no
shortcu
Hi,
cgpsmapper supports restrictions defined as 4 nodes and 3 roads. This is
needed for most U-turn restriction, essential for roads with separated
lanes.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www
Hi Gerd,
I have compiled map of Europe, which behaves correctly in BaseCamp. I
can't see problems with car routing. I haven't tested in GPS, but I'm
optimistic.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http
Hi Gerd,
> please try the attached patch.
You make me learn java ;)
Yes, this is the right correction.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd,
> done for the branch.
Thanks!
Style included in example\styles works correctly. Embedded default style
works partially, mkgmap:region is set correctly but substitution for
"województwo" doesn't work. It looks like internal style lost UTF-8
encoding.
"Województwo" means voivodesh
Hi Gerd,
> (highway=trunk | highway=trunk_link)
Yes, I have done exactly the same.
I would like to see another change in default style, file "address".
Maybe you could add this line before default mkgmap:region processing:
mkgmap:country=POL & mkgmap:region!=* & mkgmap:admin_level4=* { set
Hi Gerd,
the reason of all this problems at Polish road 6 is a roundabout created
as primary_link:
http://www.openstreetmap.org/way/185413048
Sorry for waisting your time. The solution is to add links to roundabout
block definition.
--
Best regards,
Andrzej
_
Hi Gerd,
> If I comment the roundabout block in the lines file
See my first mail, I have tested roundabouts. Commenting the roundabout
block clears problem, but if you instead change objects 0x0c into some
other road, then problem remains.
More precisely, I think route is correct, when roun
Hi Gerd,
I have tested routing with trunk r3093 and nod127 r3095. I have used
default style, car/motorcycle routing, fastest route. I can confirm,
that both version show a detour on Polish road 6. It seems to depend on
many factor so it is difficult to isolate a meaningful example.
Some noti
Hi Gerd,
> For both trunk and branch, I see a big detour depending on
> the start point, so something is weird with road 6.
I'm afraid it could be quite difficult to get good routing in Poland
with default style. especially in BaseCamp. That's because our road
network miss highways and Garmin
Hi Gerd,
> Please report also the settings and version of the Garmin program you
> are using.
Sorry, not a good testing. Screen shots are form Mapsource with
settings: car/motorcycle, shorter distance, avoid unpaved roads and
ferries. I thought it was faster time.
> you can use option --ve
Hi Gerd,
I have tested your branch a bit. I have noticed some weird routing, see
pictures at:
http://files.mkgmap.org.uk/download/183/nod-routingi.7z
There is unexpected detour for longer route, you can see it on
nod-long.png. On trunk r3087 the some route is correct.
I have replaced rounda
Hi Gerd,
> I think the branch is ready as it is.
I agree. I would use your branch anyway, except for that problem with
transliteration and search. I hope Steve could merge his correction too.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgm
Hi Gerd,
I have tested long distance routing with mkgmap-sort-r3067 too. BaseCamp
can create long routes, but they aren't the same as in high precision
branch. Similarly like in previous comparisons, I can't tell which
results are better.
I really appreciate smaller size of img created with
Hi Gerd,
> think you meant r316 and r314
Yes, sorry for mistake.
> Try to use a higher max-areas value to avoid the multiple passes
I tested max-areas at the time, when I had problems with PC crashing and
I left this option at default value. Now I have checked, that splitter
r317 can process
Hi Gerd,
splitter r306 crashes, while r304 does the same task correctly. See log:
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 552
at
uk.me.parabola.splitter.SplitProcessor.addToWorkingQueue(SplitProcessor.java:364)
at
uk.me.parabola.splitter.SplitProce
Hi Gerd,
I have done some comparison between trunk r3057 and high-precision
r3065. Routing is very similar. I have found some examples, where
calculated route was a bit different, but both versions have looked correct.
I have found one example, where BaseCamp hasn't been able to calculate
s
Hi Gerd,
> The correct solution that I have in mind requires a big
> change in data structures, so I'd like to postpone that
> because I want to merge the branch to trunk first.
I could guess it. Great you don't give up :)
--
Best regards,
Andrzej
___
Hi Gerd,
> Are you also satisfied with the results?
Sure, thanks. Railways look good.
I'm a bit worried about inconsistency. See this building:
http://www.openstreetmap.org/way/256598227
I have attached screenshot building-mkgmap.png. On my map this building
is drawn as an outline and a polyg
Hi Gerd,
> The message "non-routable way xyz was removed" is now
> only printed if the original way has different points in map units,
> and now it is just a warning.
no more error or warning messages with r3063.
--
Best regards,
Andrzej
___
mkgmap-de
Hi,
I have found, that mkgmap creates 2 objects, first is roundabout created
according to the way, second is a highway ramp, probably created because
of redundant relation. Depending on sample size, first or second object
is visible in GPSMapEdit, but both exist and map content is the same.
Hi Gerd,
> sorry, the 10% smaller size is also not intended, I thought you
> compared with trunk.
I have compared with trunk, 3057 is current release.
> The way 101876024 is an extremely small building, but you seem to map
> it as a line?
Yes, I'm trying to create a light map for car navigatio
Hi Gerd,
> I've added the code to optimize non-routable ways in r3059.
> Your example looks much better now.
That was fast. Result is much better, thanks!
Can we fine-tune effect using option --reduce-point-density?
Some observation:
Map size seems to be nearly 10% less, compared to latest re
Hi Gerd,
> This relation also has the tag
> junction=roundabout
> Therefor the MultipolygonRelation code removes the tag
> from the way.
> I am not sure if this is just wrong data or also wrong
> handling in mkgmap.
I can confirm, that removing relations 1999551-2 resolves problem.
I don't know
Hi WanMil,
default style and only --route added, see details in attached archive.
I have tried some earlier releases, up to 2926, with similar results.
And I haven't seen "junction=roundabout" in echotags, even when rondo
has been created.
--
Best regards,
Andrzej
___
Hi,
I have found some rondos on map, which are drawn as a highway ramp.
After examining sources I have concluded that this is a bug, junction
tag is lost by mkgmap.
This is source object in OSM data:
http://www.openstreetmap.org/way/148247399
user='przemas75' visible='true' version='13' ch
Hi,
now includes are moved to finalize section at the end of the file. To
search for country code you have to include "address" file before your
search.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.m
Hi Minko,
> if I use --transparent in combination with some lines that are also
> present in the overview map levels, they are visible at lower zoom too
This is probably only problem of Mapsource, you see overview map because
detailed map is transparent. I get similar results when using cgpsmap
Hi Gerd,
> 2) "no_u_turn" restrictions were not added
> if from-way and to-way are equal. They are evaluated to be valid,
> but I don't know if they really make sense?
GPSMapEdit adds these restrictions when splitting a map. I think they
aren't important but maybe adding a node in a middle of t
Hi Klaus,
> I was informed by an user, that the Freizeitkarte maps are by default
> in marine mode.
As far as I know Freizeitkarte maps are standard topo, not marine.
> Has someone information which bit is set in this case and what
> the default set by mkgmap is?
mkgmap writes in TRE header at
Hi Gerd,
>> This object should create 2 separate lines, I think mkgmap connects
>> them, which is wrong.
> yes, it connects them and writes an error message. Can you
> give an example ? I did not find a hint in the version 2.5 docu
> for cgpsmapper.
Neither I can find. This could be unintended f
Hi Gerd,
> As the comment says, this polygon is not closed. The trunk version
> ignores this error and creates a shape.
> Is this intended?
Yes, this is standard for polish format. Cgpsmapper would probably
complain if you close a polygon.
I think there are still some basic problems with mkg
Hi Gerd,
> Please check also the corresponding docu.
Ok, my fault, thanks.
I finally got it working, using statement "set mkgmap:road-speed=-0".
Will this trick work in future?
Manual says: mkgmap:road-speed, example: +1
Actually if I use "set mkgmap:road-speed=+1", mkgmap crashes. Example
Hi Gerd,
> I've committed r2979 with the roadspeed-v1.patch.
I confirm, that now speeds look correctly. I don't think that using
maxspeed for road speed is a good solution but processing is done
correctly. Thanks Gerd.
> It fixes the reported problem, at least MapSource calculates
> a reason
Hi Gerd,
> If the way has a mkgmap:road-speed tag, the value is
> evaluated.
I'm not sure what you mean by mkgmap:road-speed, I was referring to
roads_speed=N form object definition.
I have attached here simple source data with 3 primary ways. When
compiling with r2979, default style and --x
Hi Gerd,
> I'd like to finish the work on the high-prec-coord branch first,
> so my motivation is low. this really a useful feature?
Thanks for your work. I agree this is low priority. I'm publishing maps
of Africa and Asia using 23-bit resolution to make reasonably small
mapsets. Would be nic
Hi Gerd,
here simple example with 23-bit level 0, where Mapsource crashes.
test3-l.osm.pbf - small data with highways only,
route23.gpx - route which makes Mapsource crash.
I create map executing mkgmap like that:
java -jar mkgmap.jar --route --levels=0:23,1:22,2:20,3:18 test3-l.osm.pbf
--
Bes
Hi Gerd,
> You can use the switch --x-no-mergeroads
Thanks, this switch works, i get separated ways.
mkgmap:road-speed-max doesn't work.
Echotag shows mkgmap:road-speed-max=3 but in img I get value 4 as
defined with road_speed=4.
--
Best regards,
Andrzej
Hi,
sorry for multiple reports, but nothing seems to work for me today.
I'm trying to apply speed restriction as mkgmap:road-speed-max,
something like this:
maxspeed=* & maxspeedkmh() <= 60 { set mkgmap:road-speed-max = 3 }
I can verify with echotest, that this tag is correctly applied, but t
Hi WanMil,
> I can confirm that way 227105752 seems to get a wrong road speed when
> using your sample data. ("seems" because that's what GMapEdit tells
> me - there is no guarantee that there isn't a bug in GMapEdit)
As I have written i have done simulation in nuvi and this has confirmed
that
Hi WanMil
> you can find a rather complete documentation of all mkgmap:* tags in
> the mkgmap style documentation
Thanks, this was the first place where I have looked, I don't know how
could I miss it.
> osmid()=227105752 & highway=* { echotags "Wrong roadspeed?" }
It is nice debugging facil
Hi,
I have observed weird road speeds when using current mkgmap r2977. See
this way:
http://www.openstreetmap.org/way/227105752
It has no maxspeed tag. It should be rendered as primary road, speed
class 4. This is what I get, if I disable including "roadspeed" file
from default style.
With
Hi Gerd,
> Do you get them with the same sample? I don't.
I have problems with other map, it could be unrelated but message form
Mapsource is similar, the same MPL_MAP module. I will try to prepare
some sample.
--
Best regards,
Andrzej
___
mkgmap-
Hi Gerd,
> with r2977 this problem seems to be fixed
I can confirm that it fixes routing on my map with 24-bit level 0. I
still get similar crashes when using 23-bit for level 0.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.
Hi Mira,
I have responded on OSM forum. It looks like a bug in your style but in
my opinion mkgmap should detect and report it. Problematic line in style
looks like:
... [0x1 resolution continue with_actions]
Missing value of resolution should give a warning and if default value
is take
Hi Gerd,
> I think that means that my file doesn't help much to learn
> what format we should write. I am not even
> sure if it is really routable, it's just my only one
> that contains a NOD file.
There are many free samples of Garmin maps, that you can use for tests.
For example:
http://www.
Hi Gerd,
> My question was how you decide that mkgmap failed.
IMHO mkgmap failed if any requested file hasn't been created. Would be
nice to have an error message at the end. Even running manual
compilation I sometimes miss that kind of error.
--
Best regards,
Andrzej
___
Hi Mira,
> As you see some piers are missing:
...
> Also some shapes are malformed
These piers are like 3m wide, it is at the limits of resolution for
Garmin maps. There is no easy solution for this problems.
You can for example add piers as a polyline, this could show the missing
ones.
Pr
Hi Gerd,
> since r2435 mkgmap always creates copies of the list with the point
> references, so that reversing of one copy doesn't influence the other
> copies.
So if copy is reversed too, then not because of routable roads merging
but maybe because it is merged in a separate action too? Then s
Hi,
> Maybe we need a tag like mkgmap:reversible=no
Isn't a bigger problem there?
The situation is that single OSM way creates multiple Garmin ways. This
could be done by copying OSM way or by referencing OSM way for new
Garmin object. Both variants can cause problems.
If there is a copy, t
Hi,
using ref tag for name is programmed in default style, see file
inc\name. I think you can correct it in file points, moving line
"include inc\name" after definitions for tag "place".
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-de
Hi,
technically this map has routing, only roads aren't connected at
junctions. Routing works on very short distances, between crossroads.
There is another free map from Garmin based on OSM - Recreational Map of
Africa:
http://www.garmin.co.za/garmin_maps.php
http://www.garminftp.co.za/downl
Hi Gerd,
> 1) merge polygons with equal types etc. like in merge-lines algo,
> so that e.g. buildings that share walls are combined to one polygon >
> (without creating holes).
I would expect that many buildings have address tag which would make
merging not advisable.
How merging would coop
Hi,
WanMil wrote:
> attached patch forwards the "guessed" drive-on-left value in a thread
> safe way to the NOD header by using a ThreadLocal variable. This is a
> small code change.
> Anyhow this makes only sense if you think that the guess algorithm is
> ok.
Shouldn't it be a TRE header? Or
Hi,
> In the device version of the index, there are not even any
> strings in the index, it points directly to the labels in the map.
There is a list of names shortened to 4-characters, isn't it simplified
list for search?
I'm using CP 65001 with option --name-tag-list=name:en,name. This way
601 - 700 of 743 matches
Mail list logo
