Carlos,
Using sun java as in machine A fixed the problem for splitter, although
mkgmap still needs a slightly higher amount of memory. May it be due to
--max-jobs?
Sure, if you have more cores available than before, --max-jobs will
process that number of maps in parallel so it will take more
Hi Carlos,
Building a map of Europe I get the following message:
Overflow of the NET1. The tile must be split so that there are fewer
road in it
Would it be possible to include tile name in the message?
Please try attached patch. If good, I will commit it.
Mark
diff --git
Hello Tony,
I got my first GPS recently, a Garmin GPSmap 60CSx, and am now trying
to create maps for it via mkgmap, but am having problems. I'm running
Debian Lenny, with mkgmap-r1600 (current version) and Sun Java 6. My
machine is 32-bit AMD with 2GB memory.
I managed OK (using an older
I recently discovered jvisualvm and have been using it to profile
mkgmap. One thing I haven't discovered yet is how to profile an
application from the start - its trivial to attach to an already
running java app using the gui but if it's already running, you could
miss some useful info. So, the
Hi Nakor,
I don't know what is causing the SEGV but have you tried using another
runtime? Perhaps, it's a problem in OpenJDK.
# Java VM: OpenJDK 64-Bit Server VM (14.0-b16 mixed mode linux-amd64 )
Mark
___
mkgmap-dev mailing list
Stylists,
Just noticed that in the UK map, points tagged natural=peak that don't
have a name are showing a name of '6140565'. I guess it's something to
do with this rule from the points file:
natural=peak {name '${name|def:}${ele|height:m=ft|def:}' } [0x6616 resolution
18]
The style language
Felix,
Ups, sorry. I don't understand why it ran through using the default
style, but it is hanging on the templates.args file which seems to be
the real culprit.
If I run mkgmap with *.osm.gz for map input, it runs through fine. If
however I use -c template.args then it gets stuck
Hi Someoneelse,
Is 6140565 the last name in the .osm file being processed at that
time? I've seen a similar effect with all unnamed natural=peak being
named YHA Ravenstor (which happened to be the last name in the file
that I was processing at the time). As to how to fix it; haven't a
Chill Felix,
Sorry, I had a syntax error here that caused mkgmap to pass when not
using template.args (and outputting a 0kb map). It's using
location-autofill=2 and my style-file which will cause mkgmap to get
stuck on kosovo (as well as on some more countries like recently Slovakia).
I
Felix,
The problem is triggered by the fact that in your style file you give
anonymous roads of the same type, the same name i.e. 'rd', 'trk',
'ucl', etc. So the map ends up containing lot's of roads with the same
names. The kosovo map contains a huge number of anonymous roads.
The code that is
Hi Clinton,
On Sun, Mar 14, 2010 at 11:29 PM, Mark Burton ma...@ordern.com wrote:
Hey, that's a really great bug, it causes anonymous peaks to be
named in honour of a bus stop!
This may be caused by the def (default value) and height filters.
I believe the statement is attempting
Steve,
It turns out that the problem is Labels that are empty but not null. All
such labels, however generated, show as whatever label was defined right
after the first empty one.
The attached patch should fix it.
That looks better, thanks.
Mark
This patch codes around the problems introduced by highway shields with
regard to the sorted roads:
1 - the sort order should now be much improved
2 - no duplicate symbols (shield version + non-shield version)
It also includes a fix to the label reading code so that labels with a
highway
v2 - remove more duplicate labels that only differ in letter case -
remove leading spaces from labels even if they start with a Garmin code.
Still something wrong with motorway names because on the UK map, only
the M74 appears in the mapsource road names - all other motorways are
missing - very
Hi Clinton, Felix,
Hi, I just got this comment yesterday via my homepage. Seemingly mkgmap in
some circumstances puts ENQ - functional characters into the name of
streets (when adding the name from a route relation).
ENQ is ASCII 0x05, which is one of the codes for highway shields.
v3 - now works harder to clean up road names for use in MDR file - not
sure if this will have a beneficial effect but it could possibly fix
the issue recently reported by Felix.
Motorways are still not showing up.
---
v2 - remove more duplicate labels that only differ in letter case -
Hi Clinton,
On Mar 18, 2010, at 22:49, Mark Burton wrote:
v3 - now works harder to clean up road names for use in MDR file
Er... this patch needs to be applied on top of the v2 patch does it not?
It just patches the MDR file, but does not contain the patches to all the
other files
v4 - found the motorways (and a load of other roads too!)
v3 - now works harder to clean up road names for use in MDR file - not
sure if this will have a beneficial effect but it could possibly fix
the issue recently reported by Felix.
Motorways are still not showing up.
---
v2
Hi Paul,
I'm curious how mkgmap handles permissive, private, and destination
access types myself.
'permissive' is considered to be the same as 'yes' and 'designated'.
'private' is considered to be the same as 'no'.
'destination' routing on a way(s) should stop the gps routing through
those
Felix,
okay searching for roads works very well now.
Good.
However the ENQ problem is
not solved for me. Using: /set ref = '${ref}'/ inside relations file for
relations that have a ref (like EV6) and then
/{ set name='${ref|highway-symbol:box:6:4} ${name}' |
Felix,
Sorry, once again, I am nonplussed by the style syntax, what does the
6:4 mean in the above?
This means 6 characters maximum, or 4 non numeric characters maximum if
I remember it correctly. Default is 7:5 if I remember correctly.
OK - thanks.
Well, the 0x2f and 0x2e
BTW - do you think this v4 patch is working well enough to commit now?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Clinton,
BTW - do you think this v4 patch is working well enough to commit now?
yes
Me too! :-)
Good and thanks for the earlier +ve report.
Unless anything untoward crops up, I shall commit it later today.
Mark
___
mkgmap-dev mailing
Folks,
You can see the additional label will only be added if it differs from the
name after the Garmin codes have been stripped from the name.
Sure, what's the point in having multiple labels the same (apart from
the shield code)?
Mark
___
Hi Paul,
Hmm, I would have thought permissive would have been the same as
destination but with preference given to permissive routes as a
tiebreaker.
The Garmin doesn't do permissive - it really only does yes or no so
the choice is one of:
permissive = yes
permissive = no
permissive is
Felix,
I'm not setting multiple labels. The display_name is the name shown for
routing instructions. If not set, the ref alone will be taken instead.
So instead of say left on A11 Westautobahn the GPS will only say left
on A11.
Hmm, for me, I still get the longer routing instruction.
v5 - now understands the 0x1b prefix code that introduces a lower case
letter (and also is used to prefix a couple of separators (0x1b and
0x1c).
I thought great, now I can prefix my road names with ^\ (aka 0x1c) and
they won't show up so readily when zoomed out. That worked as expected
but,
Felix,
The patch for the patch by Clinton, allows that display_name can be
identical to name and I find it pretty useful.
I am very slow - please spell it out for me.
How does having two labels that are the same apart from the first one
having a highway shield prefix behave any differently
Felix,
Your version 4, disallowed setting display_name and name to the same value.
Actually, display_name isn't really handled specially at all, it's just
the same as any other ref but it goes to the head of the ref queue. i.e
if you have:
name = peach
ref = banana;orange
display_name = kiwi
Hi Clinton,
Sure, what's the point in having multiple labels the same (apart from
the shield code)?
I suppose because Felix said so isn't a good argument is it? ;-)
I think that I have twigged what the issue is - I think what Felix is
possibly looking at this situation:
name =
Felix,
Your right, it would really be needed that all of the three combinations
of name and ref are searchable independently.
name
ref name
ref
All it requires is that all of the labels that are attached to a road
are read in by the MDR generating code. Where those labels got their
values
Felix,
Thanks for the explanation - I was hoping you would write English
rather than style language as I understand that about as well as I
understand German language!
Anyway, I think I have worked out what the issue is. It's because there
are trailing labels following and they get shown
v6 - don't trash first ref if it is the same as the name (sans shield)
and more refs follow
-
v5 - now understands the 0x1b prefix code that introduces a lower case
letter (and also is used to prefix a couple of separators (0x1b and
0x1c).
I thought great, now I can prefix my road
Hello Chris,
I found that I had to set the ferry road class to 3 to be able to
reliably route using them.
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Use road_class 3 for route=ferry.
Mark Burton says that this is needed for reliable routing.
That was rather quick. Let's hope I'm right.
As for evidence, here's an example route that has uses two ferries and
has no intermediate way points.
Mark
attachment: ferry
Hello Christoph,
Hello list,
I try to make Garmin maps with different layers.
http://wiki.openstreetmap.org/wiki/All_in_one_Garmin_Map
The idea is, that you can enable or disable some transparent maps that you
won't see.
For this reason I use mkgmap with different options and
Hi Felix,
On 22.03.2010 00:42, Mark Burton wrote:
v6 - don't trash first ref if it is the same as the name (sans shield)
and more refs follow
-
In principle the patch works very good.
Good.
I do get complications when using this patch in combination to Wan Mill's
Hi Steve,
Steve's been handling the MP patches, hopefully he will look at
incorporating that patch.
All of that patch (as far as I can see) was included in the r1607 patch.
Oh yes, it's already been done.
I've been so immersed in my own little world that I missed that one.
Mark
The patch to support different min sizes for lines and polys has now be
committed. I added a couple of options so that the default values (1
and 8 as per the original patch) can be changed if required.
Mark
___
mkgmap-dev mailing list
This patch squashes spaces in label strings so that High Street
becomes High Street.
Is there any reason why we would want to preserve multiple spaces?
Mark
diff --git a/src/uk/me/parabola/imgfmt/app/Label.java b/src/uk/me/parabola/imgfmt/app/Label.java
index 149205b..ec2b11a 100644
---
Hello Felix,
Could it be that the new for polygons 8 is much much bigger compared
to the old (using patch) 8???
Or that the patch was not enacted on resolution 24??
Err, why?
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Felix,
Or that the patch was not enacted on resolution 24??
Yes, that's true and looking at the code, I think that for polygons it
probably should always be done and, furthermore, should be done after
the polygon splitting so that any tiny polygons produced by the
splitting get removed. i.e.
Hi Garvan,
Can now explicitly tag boundary nodes with mkgmap:on-boundary=1.
Apologies for the beginners question, but how do I use this? In the OSM
source like this?
node id= -1 lat=11.00 lon=103.72
tag k = mkgmap:on-boundary=1 /
/node
I am assuming this is to allow us to mark
On Wed, 24 Mar 2010 14:33:15 +
Toby Speight t.m.speight...@cantab.net wrote:
When --generate-coastline=multipolygon fails, I'm left with a map that
has no distinction between land and sea. However, if I don't
use --generate-coastline, I at least get a line (from my style/lines).
Is there
601 - 644 of 644 matches
Mail list logo
