Re: [mkgmap-dev] Commit: r1620: Can now explicitly tag boundary nodes with mkgmap:on-boundary=1.
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 external nodes that connect to external nodes in other tiles - is this correct? This would be fun to experiment with, splitting tiles in gpsmapedit, converting them to osm format and then compiling. It's me that should apologise for committing that addition with no explanation. It explicitly says that a given point is a boundary node. Of course, it only makes sense to do that for routable ways. Boundary nodes are normally created automatically when a routable way is clipped at the tile's boundary. This lets you create a boundary node anywhere. It's used like this: tag k='mkgmap:on-boundary' v='1' / So, you were nearly right. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Generate coastline - can we keep the coastline way?
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 any good reason why generating coastline prevents the line
rules from being applied to the coastline ways?
It's not a problem when I actually get sea tiles, but it's a serious
nuisance when small islands have completely disappeared!
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Perhaps this does what you want?
diff --git a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
index 0b150ef..8d40da2 100644
--- a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
+++ b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
@@ -531,8 +531,9 @@ public class Osm5XmlHandler extends DefaultHandler {
String natural =
currentWay.getTag(natural);
if(natural != null) {
if(coastline.equals(natural))
{
-
currentWay.deleteTag(natural);
-
shoreline.add(currentWay);
+ Way w =
currentWay.copy();
+ w.deleteTag(natural);
+ shoreline.add(w);
}
else if(natural.contains(;)) {
// cope with compound
tag value
@@ -547,10 +548,11 @@ public class Osm5XmlHandler extends DefaultHandler {
others
+= ; + n;
}
if(foundCoastline) {
-
currentWay.deleteTag(natural);
+ Way w =
currentWay.copy();
+
w.deleteTag(natural);
if(others !=
null)
-
currentWay.addTag(natural, others);
-
shoreline.add(currentWay);
+
w.addTag(natural, others);
+
shoreline.add(w);
}
}
}
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Minimum size patch installed
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 mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v1] squash spaces in labels
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
--- a/src/uk/me/parabola/imgfmt/app/Label.java
+++ b/src/uk/me/parabola/imgfmt/app/Label.java
@@ -69,6 +69,12 @@ public class Label implements ComparableLabel {
return s.trim();
}
+ public static String squashSpaces(String s) {
+ if(s == null)
+ return null;
+ return s.replaceAll(\\s\\s+, );
+ }
+
/**
* The offset of this label in the LBL file. The first byte of this file
* is zero and an offset of zero means that the label has a zero length/is
diff --git a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
index de58e11..da365b0 100644
--- a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
+++ b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
@@ -30,6 +30,7 @@ import uk.me.parabola.imgfmt.app.Area;
import uk.me.parabola.imgfmt.app.Coord;
import uk.me.parabola.imgfmt.app.CoordNode;
import uk.me.parabola.imgfmt.app.Exit;
+import uk.me.parabola.imgfmt.app.Label;
import uk.me.parabola.imgfmt.app.net.NODHeader;
import uk.me.parabola.imgfmt.app.trergn.ExtTypeAttributes;
import uk.me.parabola.log.Logger;
@@ -550,22 +551,22 @@ public class StyledConverter implements OsmConverter {
}
private String combineRefs(Element element) {
- String ref = element.getTag(ref);
- String int_ref = element.getTag(int_ref);
+ String ref = Label.squashSpaces(element.getTag(ref));
+ String int_ref = Label.squashSpaces(element.getTag(int_ref));
if(int_ref != null) {
if(ref == null)
ref = int_ref;
else
ref += ; + int_ref;
}
- String nat_ref = element.getTag(nat_ref);
+ String nat_ref = Label.squashSpaces(element.getTag(nat_ref));
if(nat_ref != null) {
if(ref == null)
ref = nat_ref;
else
ref += ; + nat_ref;
}
- String reg_ref = element.getTag(reg_ref);
+ String reg_ref = Label.squashSpaces(element.getTag(reg_ref));
if(reg_ref != null) {
if(ref == null)
ref = reg_ref;
@@ -577,13 +578,13 @@ public class StyledConverter implements OsmConverter {
}
private void elementSetup(MapElement ms, GType gt, Element element) {
- String name = element.getName();
+ String name = Label.squashSpaces(element.getName());
String refs = combineRefs(element);
// Insert display_name as first ref.
// This causes display_name to be displayed in routing
// directions, instead of only the ref.
- String displayName = element.getTag(display_name);
+ String displayName = Label.squashSpaces(element.getTag(display_name));
if (displayName != null) {
// substitute '/' for ';' in display_name to avoid it
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1621: Add --min-line-size and --min-polygon-size options.
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 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1621: Add --min-line-size and --min-polygon-size options.
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. it should look like this, perhaps:
diff --git a/src/uk/me/parabola/mkgmap/build/MapBuilder.java
b/src/uk/me/parabola/mkgmap/build/MapBuilder.java
index c2593c6..28098ee 100644
--- a/src/uk/me/parabola/mkgmap/build/MapBuilder.java
+++ b/src/uk/me/parabola/mkgmap/build/MapBuilder.java
@@ -930,13 +930,13 @@ public class MapBuilder implements Configurable {
if (enableLineCleanFilters (res 24)) {
filters.addFilter(new
PreserveHorizontalAndVerticalLinesFilter());
filters.addFilter(new RoundCoordsFilter());
- filters.addFilter(new SizeFilter(minPolygonSize));
//DouglasPeucker behaves at the moment not really
optimal at low zooms, but acceptable.
//Is there an similar algorithm for polygons?
if(reducePointError 0)
filters.addFilter(new
DouglasPeuckerFilter(reducePointError));
}
filters.addFilter(new PolygonSplitterFilter());
+ filters.addFilter(new SizeFilter(minPolygonSize));
filters.addFilter(new RemoveEmpty());
filters.addFilter(new ShapeAddFilter(div, map));
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] debugging ferries
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
Re: [mkgmap-dev] Commit: r1609: Use road_class 3 for route=ferry.
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-routing.png___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] process same input data with mkgmap with different styles at the same time
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 stylefiles multiple times on the same input data: java -ea -jar mkgmap.jar [options1] --style-file=style1 input_data java -ea -jar mkgmap.jar [options2] --style-file=style2 input_data java -ea -jar mkgmap.jar [options3] --style-file=style3 input_data ... This works good, but is not with so good performance as it could be. The input data are gzipped osm-tiles of europe and everytime mkgmap runs it has to decompress and parse the same stuff. The cleverst solution I could imagine is to start mkgmap once and give it different options at the same time for different threads for example: java -ea -jar mkgmap.jar [options1] --style-file=style1 --outputdir=dir1 [options2] --style-file=style2 --outputdir=dir2 [options3] --style-file=style3 --outputdir=dir3 input_data The question is: How difficult is it to implement in mkgmap? I looked at the source code but didn't understand enough to implement it. In germany we would say I looked at the code like a pig at a clockwork. ;) That's a great phrase! But to answer your question. I think it would be a lot of work to do what you are suggesting and really not the best solution. If I was trying to do what you are doing I would simply de-compress the input once (disk space is cheap) and then run separate mkgmap sessions as before. You could also pre-process the XML to filter out all of the crap tags that you are not interested in. That would speed up the processing by mkgmap. I think a problem is that at the moment the order of commandline args doesn't matter but then it would be important which option belongs to which thread. Maybe another solution could be to build a cache - like the tilesplittercache, where mkgmap can store the parsed input_data. Another mkgmap instance could use this cache instead of the input data. Maybe this solution would be more easy to implement or am I wrong? So something like: java -ea -jar mkgmap.jar [options1] --style-file=style1 --write-cache=cachdir input_data java -ea -jar mkgmap.jar [options2] --style-file=style2 --read-cache=cachdir java -ea -jar mkgmap.jar [options3] --style-file=style3 --read-cache=cachdir What do you think about that ideas? Btw: Can I specify an output directory for mkgmap or is it everytime the actual directory? Thanks! Christoph Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v6] - Code around highway shield crap when sorting labels
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 mp_lesscuts_v4.patch. Isn't that patch already in the trunk? It would be great if the following patches could be added to trunk, for me they all work very well: empty_labels.patch This is also in trunk now. mp_lesscuts_v4.patch (causes some problems in combination with above patch v6) mp_rolehandling_v3.patch sizeFilter.patch (previously called drop_small_polygons.patch) Don't know the status of those patches. java.lang.NullPointerException at uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.closeWays(MultiPolygonRelation.java:327) at uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.processElements(MultiPolygonRelation.java:538) Actually, if you look at the code, that NPE should be impossible to achieve. Something very odd is happening - can you try again using a clean build (ant clean; ant) Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] rolehandling patch
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v4] - Code around highway shield crap when sorting labels
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}' |
'${ref|highway-symbol:box:6:4}'; add display_name='${name}'}/
inside lines file, causes mkgmap to create these havoc names.
Sorry, once again, I am nonplussed by the style syntax, what does the
6:4 mean in the above?
If read with mapedit name looks like this:
~[0x2f]EV6 ~[0x2e]EV6 DONAURADWEG
inside Mapsource it looks like this:
EV6 | EV6 DONAURADWEG
Clearly mkgmap has some problem here. There is nowhere at all where I
ask [0x2f] or [0x2e] to be included into the name. Furthermore is
neither 0x2f nor 0x2e the type of the road.
Well, the 0x2f and 0x2e are the 6-bit encodings of the Oval and Box
shields so at least one of those matches what your doing above but I
can't see how the Oval code is getting in there. Do you have some other
rule that adds an Oval shield?
So I wonder if the problem is that your ending up with a highway shield
code embedded in the name rather than being a prefix. Perhaps, it
can only cope with prefix shields.
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v4] - Code around highway shield crap when sorting labels
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 are the 6-bit encodings of the Oval and Box
shields so at least one of those matches what your doing above but I
can't see how the Oval code is getting in there. Do you have some other
rule that adds an Oval shield?
No, the full rules for the highway shields are as follows (I don't think
there is a bug inside on my part):
( extremecarver=mr | route=mtb ) ref=* {
set name='${ref|hig2f4b | 01 38 00| 3 byte stream
hway-symbol:hbox:6:4} ${name}' |
'${ref|highway-symbol:hbox:6:4}'; add display_name='${name}'}
extremecarver5=bike ref=* extremecarver!=mr route!=mtb
{ set name='${ref|highway-symbol:box:6:4} ${name}' |
'${ref|highway-symbol:box:6:4}'; add display_name='${name}'}
highway=* ref=* extremcaver5!=bike extremecarver!=mr route!=mtb
{ set name='${ref|highway-symbol:oval:6:4} ${name}' |
'${ref|highway-symbol:oval:6:4}'; add display_name='${name}'}
Yes, you do have another rule that adds an oval shield (the last one
above). So what's happening is that two of the rules are matching and
you are getting both a box and an oval shield added to the name - and
that's badness.
So I wonder if the problem is that your ending up with a highway shield
code embedded in the name rather than being a prefix. Perhaps, it
can only cope with prefix shields.
I don't understand what you mean with /being a prefix/.
What I mean is that the highway shield code has to prefix (go at the
front) of the name and not be embedded within the name string.
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v4] - Code around highway shield crap when sorting labels
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
Re: [mkgmap-dev] [PATCH v4] - Code around highway shield crap when sorting labels
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 list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] setting display_name to name
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] map detects barriers like gate as passable by motor vehicle when it is only restricted to pedestrians
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 ignored Yonks ago I decided that permissive was more like yes than no so that's how it is treated in mkgmap. Does it still route down a no or private if there's not any other option? I think that's the case but I haven't checked for a long time. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] setting display_name to name
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. For example, if the first label is B5395 (with a highway shield prefix) and the second label (set through display_name) is Oldhall Street (B5395), then the routing instructions is: Turn right onto Oldhall Street (B5395) 2.5 km 1.5 km 0:02:16 0:03:44 46° trueN53.02019 W2.76553 The patch we're currently evaluating hasn't changed that behaviour. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v5] - Code around highway shield crap when sorting labels
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, unfortunately, it broke the address search stuff so the bottom
line is that you can't use the separators as a prefix (sob).
Also, for those of you wondering why the display names and other refs
are not showing up in the mapsource address search - it's because the
MDR building code only reads the first label for a road and ignores any
others. Shame that. I don't think there's a good reason why it couldn't
read the other labels, it's just doesn't do that at the moment. BTW -
the basic address search on the etrex and Nuvi still sees those
alternative road labels.
So, those people who are tracking this patch series, please test and if
it doesn't bite your arse, I will commit it soonish
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 - 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 odd.
---
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 shield prefix are read in correctly when generating the MDR
file.
For me, in mapsource, road search for roads with highway shields now
works apart from motorways which don't seem to searchable - perhaps
that's deliberate on Garmin's part?
All feedback appreciated.
Mark
diff --git a/src/uk/me/parabola/imgfmt/app/Label.java b/src/uk/me/parabola/imgfmt/app/Label.java
index c7ca3a3..149205b 100644
--- a/src/uk/me/parabola/imgfmt/app/Label.java
+++ b/src/uk/me/parabola/imgfmt/app/Label.java
@@ -56,6 +56,19 @@ public class Label implements ComparableLabel {
return text;
}
+ public String getTextSansGarminCodes() {
+ return stripGarminCodes(text);
+ }
+
+ public static String stripGarminCodes(String s) {
+ if(s == null)
+ return null;
+ s = s.replaceAll([\u0001-\u0006\u001b-\u001c], ); // remove highway shields and thin separators
+ s = s.replaceAll([\u001d-\u001f], ); // replace fat separators with spaces
+ // a leading separator would have turned into a space so trim it
+ return s.trim();
+ }
+
/**
* The offset of this label in the LBL file. The first byte of this file
* is zero and an offset of zero means that the label has a zero length/is
diff --git a/src/uk/me/parabola/imgfmt/app/labelenc/BaseEncoder.java b/src/uk/me/parabola/imgfmt/app/labelenc/BaseEncoder.java
index 0dc8390..fd06368 100644
--- a/src/uk/me/parabola/imgfmt/app/labelenc/BaseEncoder.java
+++ b/src/uk/me/parabola/imgfmt/app/labelenc/BaseEncoder.java
@@ -65,7 +65,7 @@ public class BaseEncoder {
return new EncodedText(out, out.length);
}
- protected boolean isUpperCase() {
+ public boolean isUpperCase() {
return upperCase;
}
diff --git a/src/uk/me/parabola/imgfmt/app/labelenc/Format6Decoder.java b/src/uk/me/parabola/imgfmt/app/labelenc/Format6Decoder.java
index 079ef4c..f4547cd 100644
--- a/src/uk/me/parabola/imgfmt/app/labelenc/Format6Decoder.java
+++ b/src/uk/me/parabola/imgfmt/app/labelenc/Format6Decoder.java
@@ -11,6 +11,7 @@ public class Format6Decoder implements CharacterDecoder {
private boolean needReset;
private boolean symbol;
+ private boolean lowerCaseOrSeparator;
private int store;
private int nbits;
@@ -77,20 +78,40 @@ public class Format6Decoder implements CharacterDecoder {
if (symbol) {
symbol = false;
c = Format6Encoder.SYMBOLS.charAt(b);
- } else {
+ }
+ else if(lowerCaseOrSeparator) {
+ lowerCaseOrSeparator = false;
+ if(b == 0x2b || b == 0x2c) {
+c = (char)(b - 0x10); // thin separator
+ }
+ else if(Character.isLetter(b)) {
+// lower case letter
+c = Character.toLowerCase(Format6Encoder.LETTERS.charAt(b));
+ }
+ else {
+// not a letter so just use as is (could be a digit)
+c = Format6Encoder.LETTERS.charAt(b);
+ }
+ }
+ else {
switch(b) {
case 0x1B:
-// perhaps this is next-char lower case?
+// next char is lower case or a separator
+lowerCaseOrSeparator = true;
return;
+
case 0x1C:
// next char is symbol
symbol = true;
return;
+
case 0x1D:
case 0x1E:
case 0x1F:
-// these define abbreviations; fall
Re: [mkgmap-dev] setting display_name to name
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 from just having the first label on its own? I don't understand the benefit. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] setting display_name to name
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 the labels get output in this order: peach kiwi banana orange ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] setting display_name to name
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 = shieldcarp ref = shark display_name = carp But with my patch the labels output are: shieldcarp shark And so shark will be used in the routing instructions when he wants carp. OK - if that's what the issue is, I am going to change the code to only trash the ref if it's the only ref (and the same as the name sans shields) but if there is multiple refs then none of them will get trashed. I will post a v6 patch tonight Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v5] - Code around highway shield crap when sorting labels
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 from initially (name, ref, display_name, int_ref, ...) is irrelevant as far as the MDR is concerned. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] setting display_name to name
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 instead of the display name. I will post a v6 patch tonight that should fix that. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v6] - Code around highway shield crap when sorting labels
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 names with ^\ (aka 0x1c) and
they won't show up so readily when zoomed out. That worked as expected
but, unfortunately, it broke the address search stuff so the bottom
line is that you can't use the separators as a prefix (sob).
Also, for those of you wondering why the display names and other refs
are not showing up in the mapsource address search - it's because the
MDR building code only reads the first label for a road and ignores any
others. Shame that. I don't think there's a good reason why it couldn't
read the other labels, it's just doesn't do that at the moment. BTW -
the basic address search on the etrex and Nuvi still sees those
alternative road labels.
So, those people who are tracking this patch series, please test and if
it doesn't bite your arse, I will commit it soonish
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 - 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 odd.
---
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 shield prefix are read in correctly when generating the MDR
file.
For me, in mapsource, road search for roads with highway shields now
works apart from motorways which don't seem to searchable - perhaps
that's deliberate on Garmin's part?
All feedback appreciated.
Mark
diff --git a/src/uk/me/parabola/imgfmt/app/Label.java b/src/uk/me/parabola/imgfmt/app/Label.java
index c7ca3a3..149205b 100644
--- a/src/uk/me/parabola/imgfmt/app/Label.java
+++ b/src/uk/me/parabola/imgfmt/app/Label.java
@@ -56,6 +56,19 @@ public class Label implements ComparableLabel {
return text;
}
+ public String getTextSansGarminCodes() {
+ return stripGarminCodes(text);
+ }
+
+ public static String stripGarminCodes(String s) {
+ if(s == null)
+ return null;
+ s = s.replaceAll([\u0001-\u0006\u001b-\u001c], ); // remove highway shields and thin separators
+ s = s.replaceAll([\u001d-\u001f], ); // replace fat separators with spaces
+ // a leading separator would have turned into a space so trim it
+ return s.trim();
+ }
+
/**
* The offset of this label in the LBL file. The first byte of this file
* is zero and an offset of zero means that the label has a zero length/is
diff --git a/src/uk/me/parabola/imgfmt/app/labelenc/BaseEncoder.java b/src/uk/me/parabola/imgfmt/app/labelenc/BaseEncoder.java
index 0dc8390..fd06368 100644
--- a/src/uk/me/parabola/imgfmt/app/labelenc/BaseEncoder.java
+++ b/src/uk/me/parabola/imgfmt/app/labelenc/BaseEncoder.java
@@ -65,7 +65,7 @@ public class BaseEncoder {
return new EncodedText(out, out.length);
}
- protected boolean isUpperCase() {
+ public boolean isUpperCase() {
return upperCase;
}
diff --git a/src/uk/me/parabola/imgfmt/app/labelenc/Format6Decoder.java b/src/uk/me/parabola/imgfmt/app/labelenc/Format6Decoder.java
index 079ef4c..f4547cd 100644
--- a/src/uk/me/parabola/imgfmt/app/labelenc/Format6Decoder.java
+++ b/src/uk/me/parabola/imgfmt/app/labelenc/Format6Decoder.java
@@ -11,6 +11,7 @@ public class Format6Decoder implements CharacterDecoder {
private boolean needReset;
private boolean symbol;
+ private boolean lowerCaseOrSeparator;
private int store;
private int nbits;
@@ -77,20 +78,40 @@ public class Format6Decoder implements CharacterDecoder {
if (symbol) {
symbol = false;
c = Format6Encoder.SYMBOLS.charAt(b);
- } else {
+ }
+ else if(lowerCaseOrSeparator) {
+ lowerCaseOrSeparator = false;
+ if(b == 0x2b || b == 0x2c) {
+c = (char)(b - 0x10); // thin separator
+ }
+ else if(Character.isLetter(b)) {
+// lower case letter
+c = Character.toLowerCase(Format6Encoder.LETTERS.charAt(b));
+ }
+ else {
+// not a letter so just use as is (could be a digit)
+c = Format6Encoder.LETTERS.charAt(b);
+ }
+ }
+ else {
switch(b) {
case 0x1B:
-// perhaps this is next-char lower case?
+// next char is lower case or a separator
+lowerCaseOrSeparator = true;
return;
+
case 0x1C:
// next char is symbol
symbol = true;
Re: [mkgmap-dev] map detects barriers like gate as passable by motor vehicle when it is only restricted to pedestrians
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 ways unless the destination is within those ways or there is no other route to the destination. Note that destination routing only seems to have an effect on motorcar/motorbike routing - it doesn't appear to effect the other vehicle types. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v1] - Code around highway shield crap when sorting labels
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 shield prefix are read in correctly when generating the MDR
file.
For me, in mapsource, road search for roads with highway shields now
works apart from motorways which don't seem to searchable - perhaps
that's deliberate on Garmin's part?
All feedback appreciated.
Mark
diff --git a/src/uk/me/parabola/imgfmt/app/Label.java b/src/uk/me/parabola/imgfmt/app/Label.java
index c7ca3a3..bbf7549 100644
--- a/src/uk/me/parabola/imgfmt/app/Label.java
+++ b/src/uk/me/parabola/imgfmt/app/Label.java
@@ -56,6 +56,16 @@ public class Label implements ComparableLabel {
return text;
}
+ public String getTextSansGarminCodes() {
+ return stripGarminCodes(text);
+ }
+
+ public static String stripGarminCodes(String s) {
+ if(s == null)
+ return null;
+ return s.replaceAll([\u0001-\u0006\u001b-\u001f],);
+ }
+
/**
* The offset of this label in the LBL file. The first byte of this file
* is zero and an offset of zero means that the label has a zero length/is
diff --git a/src/uk/me/parabola/imgfmt/app/labelenc/Format6Encoder.java b/src/uk/me/parabola/imgfmt/app/labelenc/Format6Encoder.java
index ec226a1..d1a267d 100644
--- a/src/uk/me/parabola/imgfmt/app/labelenc/Format6Encoder.java
+++ b/src/uk/me/parabola/imgfmt/app/labelenc/Format6Encoder.java
@@ -41,7 +41,7 @@ public class Format6Encoder extends BaseEncoder implements CharacterEncoder {
public static final String LETTERS =
ABCDEFGHIJKLMNO + // 0x00-0x0F
PQRSTUVWXYZxx+ // 0x10-0x1F
- 0123456789xx; // 0x20-0x2F
+ 0123456789\u0001\u0002\u0003\u0004\u0005\u0006; // 0x20-0x2F
public static final String SYMBOLS =
@!\#$%'()*+,-./ + // 0x00-0x0F
diff --git a/src/uk/me/parabola/imgfmt/app/lbl/City.java b/src/uk/me/parabola/imgfmt/app/lbl/City.java
index 4fc7939..2ae6389 100644
--- a/src/uk/me/parabola/imgfmt/app/lbl/City.java
+++ b/src/uk/me/parabola/imgfmt/app/lbl/City.java
@@ -118,7 +118,7 @@ public class City implements ComparableCity {
if(label != null)
result += label.getText();
if (subdivision != null)
- result += subdivision.getNumber() + / + pointIndex;
+ result += + subdivision.getNumber() + / + pointIndex;
if(country != null)
result += in country + (0 + country.getIndex());
if(region != null)
diff --git a/src/uk/me/parabola/imgfmt/app/net/NETFile.java b/src/uk/me/parabola/imgfmt/app/net/NETFile.java
index 82f220b..e7abf26 100644
--- a/src/uk/me/parabola/imgfmt/app/net/NETFile.java
+++ b/src/uk/me/parabola/imgfmt/app/net/NETFile.java
@@ -18,8 +18,11 @@ package uk.me.parabola.imgfmt.app.net;
import java.util.ArrayList;
import java.util.Collections;
+import java.util.Comparator;
+import java.util.HashMap;
import java.util.LinkedList;
import java.util.List;
+import java.util.Map;
import uk.me.parabola.imgfmt.Utils;
import uk.me.parabola.imgfmt.app.BufferedImgFileWriter;
@@ -61,23 +64,44 @@ public class NETFile extends ImgFile {
public void writePost(ImgFileWriter rgn, boolean sortRoads) {
ListSortableLabel, RoadDef sortedRoads = new ArrayListSortableLabel, RoadDef(roads.size());
+ // cleanedLabels holds cleaned up versions of the Label
+ // strings that are used when sorting the road names - the
+ // hope is that retrieving the String from the Map is faster than
+ // cleaning the Label text for each comparison in the sort
+ final MapLabel, String cleanedLabels = new HashMapLabel, String();
for (RoadDef rd : roads) {
rd.writeRgnOffsets(rgn);
if(sortRoads) {
Label[] l = rd.getLabels();
-for(int i = 0; i l.length l[i] != null; ++i)
- if(l[i].getLength() != 0)
+for(int i = 0; i l.length l[i] != null; ++i) {
+ if(l[i].getLength() != 0) {
+ cleanedLabels.put(l[i], l[i].getTextSansGarminCodes());
+ // System.err.println(Road + rd + has label + l[i]);
sortedRoads.add(new SortableLabel, RoadDef(l[i], rd));
+ }
+}
}
}
if(sortedRoads.size() 0) {
- Collections.sort(sortedRoads);
+ Collections.sort(sortedRoads, new ComparatorSortableLabel, RoadDef() {
+ public int compare(SortableLabel, RoadDef a, SortableLabel, RoadDef b) {
+ // sort using cleaned versions of the labels
+ int diff = cleanedLabels.get(a.getKey()).compareToIgnoreCase(cleanedLabels.get(b.getKey()));
+ if(diff != 0)
+ return diff;
+ // the labels were the same, sort on the
+ // RoadDefs
+ return a.getValue().compareTo(b.getValue());
+ }
+});
sortedRoads = simplifySortedRoads(new LinkedListSortableLabel, RoadDef(sortedRoads));
ImgFileWriter writer = netHeader.makeSortedRoadWriter(getWriter());
- for(SortableLabel, RoadDef srd : sortedRoads)
+ for(SortableLabel, RoadDef srd : sortedRoads) {
+
[mkgmap-dev] [PATCH v2] - Code around highway shield crap when sorting labels
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 odd.
---
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 shield prefix are read in correctly when generating the MDR
file.
For me, in mapsource, road search for roads with highway shields now
works apart from motorways which don't seem to searchable - perhaps
that's deliberate on Garmin's part?
All feedback appreciated.
Mark
diff --git a/src/uk/me/parabola/imgfmt/app/Label.java b/src/uk/me/parabola/imgfmt/app/Label.java
index c7ca3a3..bbf7549 100644
--- a/src/uk/me/parabola/imgfmt/app/Label.java
+++ b/src/uk/me/parabola/imgfmt/app/Label.java
@@ -56,6 +56,16 @@ public class Label implements ComparableLabel {
return text;
}
+ public String getTextSansGarminCodes() {
+ return stripGarminCodes(text);
+ }
+
+ public static String stripGarminCodes(String s) {
+ if(s == null)
+ return null;
+ return s.replaceAll([\u0001-\u0006\u001b-\u001f],);
+ }
+
/**
* The offset of this label in the LBL file. The first byte of this file
* is zero and an offset of zero means that the label has a zero length/is
diff --git a/src/uk/me/parabola/imgfmt/app/labelenc/BaseEncoder.java b/src/uk/me/parabola/imgfmt/app/labelenc/BaseEncoder.java
index 0dc8390..fd06368 100644
--- a/src/uk/me/parabola/imgfmt/app/labelenc/BaseEncoder.java
+++ b/src/uk/me/parabola/imgfmt/app/labelenc/BaseEncoder.java
@@ -65,7 +65,7 @@ public class BaseEncoder {
return new EncodedText(out, out.length);
}
- protected boolean isUpperCase() {
+ public boolean isUpperCase() {
return upperCase;
}
diff --git a/src/uk/me/parabola/imgfmt/app/labelenc/Format6Encoder.java b/src/uk/me/parabola/imgfmt/app/labelenc/Format6Encoder.java
index ec226a1..d1a267d 100644
--- a/src/uk/me/parabola/imgfmt/app/labelenc/Format6Encoder.java
+++ b/src/uk/me/parabola/imgfmt/app/labelenc/Format6Encoder.java
@@ -41,7 +41,7 @@ public class Format6Encoder extends BaseEncoder implements CharacterEncoder {
public static final String LETTERS =
ABCDEFGHIJKLMNO + // 0x00-0x0F
PQRSTUVWXYZxx+ // 0x10-0x1F
- 0123456789xx; // 0x20-0x2F
+ 0123456789\u0001\u0002\u0003\u0004\u0005\u0006; // 0x20-0x2F
public static final String SYMBOLS =
@!\#$%'()*+,-./ + // 0x00-0x0F
diff --git a/src/uk/me/parabola/imgfmt/app/lbl/City.java b/src/uk/me/parabola/imgfmt/app/lbl/City.java
index 4fc7939..2ae6389 100644
--- a/src/uk/me/parabola/imgfmt/app/lbl/City.java
+++ b/src/uk/me/parabola/imgfmt/app/lbl/City.java
@@ -118,7 +118,7 @@ public class City implements ComparableCity {
if(label != null)
result += label.getText();
if (subdivision != null)
- result += subdivision.getNumber() + / + pointIndex;
+ result += + subdivision.getNumber() + / + pointIndex;
if(country != null)
result += in country + (0 + country.getIndex());
if(region != null)
diff --git a/src/uk/me/parabola/imgfmt/app/lbl/LBLFile.java b/src/uk/me/parabola/imgfmt/app/lbl/LBLFile.java
index 4d88bab..a2422ea 100644
--- a/src/uk/me/parabola/imgfmt/app/lbl/LBLFile.java
+++ b/src/uk/me/parabola/imgfmt/app/lbl/LBLFile.java
@@ -17,6 +17,7 @@
package uk.me.parabola.imgfmt.app.lbl;
import java.util.HashMap;
+import java.util.Locale;
import java.util.Map;
import uk.me.parabola.imgfmt.Utils;
@@ -27,6 +28,7 @@ import uk.me.parabola.imgfmt.app.Label;
import uk.me.parabola.imgfmt.app.labelenc.BaseEncoder;
import uk.me.parabola.imgfmt.app.labelenc.CharacterEncoder;
import uk.me.parabola.imgfmt.app.labelenc.CodeFunctions;
+import uk.me.parabola.imgfmt.app.labelenc.Format6Encoder;
import uk.me.parabola.imgfmt.app.trergn.Subdivision;
import uk.me.parabola.imgfmt.fs.ImgChannel;
import uk.me.parabola.log.Logger;
@@ -107,6 +109,13 @@ public class LBLFile extends ImgFile {
* @return A reference to the created label.
*/
public Label newLabel(String text) {
+ // if required, fold case now so that labelCache doesn't
+ // contain multiple labels that only differ in letter case
+ if(text != null
+ (textEncoder instanceof Format6Encoder ||
+ textEncoder instanceof BaseEncoder
+ ((BaseEncoder)textEncoder).isUpperCase()))
+ text = text.toUpperCase(Locale.ENGLISH);
Label l = labelCache.get(text);
if (l == null) {
l = new Label(text);
diff --git a/src/uk/me/parabola/imgfmt/app/net/NETFile.java b/src/uk/me/parabola/imgfmt/app/net/NETFile.java
index 82f220b..e7abf26 100644
--- a/src/uk/me/parabola/imgfmt/app/net/NETFile.java
+++ b/src/uk/me/parabola/imgfmt/app/net/NETFile.java
@@ -18,8 +18,11 @@ package
Re: [mkgmap-dev] Broken Routes based on mkgmap map due to functional characters inside name
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. Perhaps Mark's patch to code around this crap would also help here? As it stands, probably not, but having recently become a little knowledgeable about this stuff I can guess what's happening. So I will make a new patch that could possibly help with this issue. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v3] - Code around highway shield crap when sorting labels
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 -
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 odd.
---
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 shield prefix are read in correctly when generating the MDR
file.
For me, in mapsource, road search for roads with highway shields now
works apart from motorways which don't seem to searchable - perhaps
that's deliberate on Garmin's part?
All feedback appreciated.
Mark
diff --git a/src/uk/me/parabola/imgfmt/app/mdr/MDRFile.java b/src/uk/me/parabola/imgfmt/app/mdr/MDRFile.java
index bcb1867..7b2cff8 100644
--- a/src/uk/me/parabola/imgfmt/app/mdr/MDRFile.java
+++ b/src/uk/me/parabola/imgfmt/app/mdr/MDRFile.java
@@ -148,11 +148,7 @@ public class MDRFile extends ImgFile {
* @return The name as it will go into the index.
*/
private String cleanUpName(String name) {
- // TODO Currently just drop an initial shield, but more to do
- if (name.charAt(0) ' ')
- return name.substring(1);
-
- return name;
+ return Label.stripGarminCodes(name);
}
public void write() {
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v3] - Code around highway shield crap when sorting labels
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 from the v2 patch. Did you perhaps forget to include the v2 stuff? Silly me, that's exactly what happened. I'm still working on why the motorways are mostly missing and maybe will have another patch sometime so I will issue an update later. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v4] - Code around highway shield crap when sorting labels
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 - 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 odd.
---
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 shield prefix are read in correctly when generating the MDR
file.
For me, in mapsource, road search for roads with highway shields now
works apart from motorways which don't seem to searchable - perhaps
that's deliberate on Garmin's part?
All feedback appreciated.
Mark
diff --git a/src/uk/me/parabola/imgfmt/app/Label.java b/src/uk/me/parabola/imgfmt/app/Label.java
index c7ca3a3..bbf7549 100644
--- a/src/uk/me/parabola/imgfmt/app/Label.java
+++ b/src/uk/me/parabola/imgfmt/app/Label.java
@@ -56,6 +56,16 @@ public class Label implements ComparableLabel {
return text;
}
+ public String getTextSansGarminCodes() {
+ return stripGarminCodes(text);
+ }
+
+ public static String stripGarminCodes(String s) {
+ if(s == null)
+ return null;
+ return s.replaceAll([\u0001-\u0006\u001b-\u001f],);
+ }
+
/**
* The offset of this label in the LBL file. The first byte of this file
* is zero and an offset of zero means that the label has a zero length/is
diff --git a/src/uk/me/parabola/imgfmt/app/labelenc/BaseEncoder.java b/src/uk/me/parabola/imgfmt/app/labelenc/BaseEncoder.java
index 0dc8390..fd06368 100644
--- a/src/uk/me/parabola/imgfmt/app/labelenc/BaseEncoder.java
+++ b/src/uk/me/parabola/imgfmt/app/labelenc/BaseEncoder.java
@@ -65,7 +65,7 @@ public class BaseEncoder {
return new EncodedText(out, out.length);
}
- protected boolean isUpperCase() {
+ public boolean isUpperCase() {
return upperCase;
}
diff --git a/src/uk/me/parabola/imgfmt/app/labelenc/Format6Encoder.java b/src/uk/me/parabola/imgfmt/app/labelenc/Format6Encoder.java
index ec226a1..d1a267d 100644
--- a/src/uk/me/parabola/imgfmt/app/labelenc/Format6Encoder.java
+++ b/src/uk/me/parabola/imgfmt/app/labelenc/Format6Encoder.java
@@ -41,7 +41,7 @@ public class Format6Encoder extends BaseEncoder implements CharacterEncoder {
public static final String LETTERS =
ABCDEFGHIJKLMNO + // 0x00-0x0F
PQRSTUVWXYZxx+ // 0x10-0x1F
- 0123456789xx; // 0x20-0x2F
+ 0123456789\u0001\u0002\u0003\u0004\u0005\u0006; // 0x20-0x2F
public static final String SYMBOLS =
@!\#$%'()*+,-./ + // 0x00-0x0F
diff --git a/src/uk/me/parabola/imgfmt/app/lbl/City.java b/src/uk/me/parabola/imgfmt/app/lbl/City.java
index 4fc7939..2ae6389 100644
--- a/src/uk/me/parabola/imgfmt/app/lbl/City.java
+++ b/src/uk/me/parabola/imgfmt/app/lbl/City.java
@@ -118,7 +118,7 @@ public class City implements ComparableCity {
if(label != null)
result += label.getText();
if (subdivision != null)
- result += subdivision.getNumber() + / + pointIndex;
+ result += + subdivision.getNumber() + / + pointIndex;
if(country != null)
result += in country + (0 + country.getIndex());
if(region != null)
diff --git a/src/uk/me/parabola/imgfmt/app/lbl/LBLFile.java b/src/uk/me/parabola/imgfmt/app/lbl/LBLFile.java
index 4d88bab..a2422ea 100644
--- a/src/uk/me/parabola/imgfmt/app/lbl/LBLFile.java
+++ b/src/uk/me/parabola/imgfmt/app/lbl/LBLFile.java
@@ -17,6 +17,7 @@
package uk.me.parabola.imgfmt.app.lbl;
import java.util.HashMap;
+import java.util.Locale;
import java.util.Map;
import uk.me.parabola.imgfmt.Utils;
@@ -27,6 +28,7 @@ import uk.me.parabola.imgfmt.app.Label;
import uk.me.parabola.imgfmt.app.labelenc.BaseEncoder;
import uk.me.parabola.imgfmt.app.labelenc.CharacterEncoder;
import uk.me.parabola.imgfmt.app.labelenc.CodeFunctions;
+import uk.me.parabola.imgfmt.app.labelenc.Format6Encoder;
import uk.me.parabola.imgfmt.app.trergn.Subdivision;
import uk.me.parabola.imgfmt.fs.ImgChannel;
import uk.me.parabola.log.Logger;
@@ -107,6 +109,13 @@ public class LBLFile extends ImgFile {
* @return A reference to the created label.
*/
public Label newLabel(String text) {
+ // if required, fold case now so that labelCache doesn't
+ // contain multiple labels that only differ in letter case
+ if(text != null
+ (textEncoder instanceof Format6Encoder ||
+ textEncoder instanceof BaseEncoder
+ ((BaseEncoder)textEncoder).isUpperCase()))
+ text = text.toUpperCase(Locale.ENGLISH);
Label l = labelCache.get(text);
if (l == null) {
l = new
Re: [mkgmap-dev] Why are all the un-named peaks called '6140565'?
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 the following:
1. ${name|def:} use either the 'name' value, or as default '' (empty string).
2. ${ele|height:m=ft|def:} Convert the elevation in meters to feet.
If no 'ele' value is present, use an empty string.
I have a feeling that the empty string part may be misinterpreted
right now. It could be that the last value found is instead used.
The relevant files are below, if you want to debug:
DefaultFilter.java - called for the 'def' filter.
HeightFilter.java - called for the 'height' filter (a subclass of
ConvertFilter.java)
ValueBuilder.java - instantiates the filter classes. This would be a
good place to start.
Thanks for the info - I started to nose around in that area but haven't
got far - I shall take another look this evening.
One thing that struck me was (somewhere in that code) I saw where
it was testing to see if a passed in String value was null but it
didn't test if it was zero-length. So, like you above, I wonder if the
empty default value is causing problems.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Why are all the un-named peaks called '6140565'?
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Java issue with mkgmap
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 mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Why are all the un-named peaks called '6140565'?
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 is completely beyond me, what's it doing?
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap gets stuck on Kosovo - is related to -c template.args
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 infinitely. I have attached the problem causing template.args to this mail. Maybe something is wrong with it??? (it is supposed to compile tile 6322.osm.gz). It only happens on a very few countries. (I run splitter.jar with following commandline: java -Xmx4050m -Xmx4500M splitter.jar --mapid=6322 --max-nodes=130 kosovo.osm) I tried your template.args file, it didn't get stuck, finished in less than 2 mins. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Why are all the un-named peaks called '6140565'?
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 clue... That's interesting to learn. In this case, 6140565 does appear as a tag value: node id='27424899' lat='55.8449129' lon='-4.4298279' tag k='highway' v='bus_stop'/ tag k='nat_ref' v='6140565'/ /node Hey, that's a really great bug, it causes anonymous peaks to be named in honour of a bus stop! Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap gets stuck on Kosovo - is related to -c template.args
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 am looking at that now. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap gets stuck on Kosovo - is related to -c template.args
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 getting stuck is trying to find all of the roads that have the same name and are associated with the same city and are connected to each other. Perhaps, and this is a guess, the autofill=2 option increases the number of roads that have the same city such that it becomes computationally, very expensive to work out which roads are connected to each other. It may well finish if you wait long enough! Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap gives java error
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 mkgmap version) to convert and upload a few small city maps (Dublin, Barcelona, etc.) but can't manage (using either mkgmap version) a bigger map, all of Ireland, which I got from Geofabrik (http://download.geofabrik.de/osm/). The .osm file is 318MB in size. When I run mkgmap (with no options) I get an error, which starts as follows: java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOfRange(Arrays.java:3209) at java.lang.String.init(String.java:216) at com.sun.org.apache.xerces.internal.xni.XMLString.toString(XMLString.java:185) at com.sun.org.apache.xerces.internal.util.XMLAttributesImpl.getValue(XMLAttributesImpl.java:537) at com.sun.org.apache.xerces.internal.xinclude.XIncludeHandler.processAttributes(XIncludeHandler.java:2030) at com.sun.org.apache.xerces.internal.xinclude.XIncludeHandler.startElement(XIncludeHandler.java:907) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:400) I then used splitter (current version) to split the map file, which resulted in a single file being produced, 142MB after unpacking (less than half the size of the original!?), and submitted that to mkgmap, but it bombed out again (though with a different error). Can anybody suggest what I might need to do to get it working? Sounds like you need to specify a suitable value for the splitter's --max-nodes option so that it creates multiple output files rather than just one (i.e. it really does split the map!) I prefer small tiles so I normally use --max-nodes=60 Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v1] - sleep-on-startup
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 attached patch is a little kludge that
lets you start mkgmap but then it immediately pauses for a little while
(long enough to attach jvisualvm to it and turn on the profiling, etc.)
before it gets down to work.
To use this, just add -Dsleep-on-startup=30 or similar to your Java
args.
Can anyone think of a better way of achieving the same goal?
Mark
diff --git a/src/uk/me/parabola/mkgmap/main/Main.java b/src/uk/me/parabola/mkgmap/main/Main.java
index 8e9a389..a304c46 100644
--- a/src/uk/me/parabola/mkgmap/main/Main.java
+++ b/src/uk/me/parabola/mkgmap/main/Main.java
@@ -88,6 +88,18 @@ public class Main implements ArgumentProcessor {
*/
public static void main(String[] args) {
+ try {
+ int delayPeriod = Integer.decode(System.getProperty(sleep-on-startup, 0));
+ if(delayPeriod 0) {
+System.err.println(Sleeping for + delayPeriod + seconds...);
+Thread.sleep(delayPeriod * 1000);
+System.err.println(Wake up, time for work!);
+ }
+ }
+ catch(Exception e) {
+ // relax
+ }
+
// Temporary test for version 1.6. During a transition period we are
// compiling with target 1.5 so that it will run with 1.5 long enough
// to give an error message.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Improvement of error message
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 a/src/uk/me/parabola/imgfmt/app/net/RoadDef.java b/src/uk/me/parabola/imgfmt/app/net/RoadDef.java
index 0b4f12d..9972c08 100644
--- a/src/uk/me/parabola/imgfmt/app/net/RoadDef.java
+++ b/src/uk/me/parabola/imgfmt/app/net/RoadDef.java
@@ -336,7 +336,7 @@ public class RoadDef implements Comparable {
*/
void writeRgnOffsets(ImgFileWriter rgn) {
if (offsetNet1 = 0x40)
- throw new ExitException(Overflow of the NET1. The tile must be split so that there are fewer road in it);
+ throw new ExitException(Overflow of the NET1. The tile ( + log.threadTag() + ) must be split so that there are fewer roads in it);
for (Offset off : rgnOffsets) {
rgn.position(off.getPosition());
diff --git a/src/uk/me/parabola/log/Logger.java b/src/uk/me/parabola/log/Logger.java
index 7b341d3..eddee6e 100644
--- a/src/uk/me/parabola/log/Logger.java
+++ b/src/uk/me/parabola/log/Logger.java
@@ -237,4 +237,8 @@ public class Logger {
public void threadTag(String tag) {
threadTags.set(tag);
}
+
+ public String threadTag() {
+ return threadTags.get();
+ }
}
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Gap in the street and unusual routing
Hi Daniela, Hi! One street shoes a gap that does not seem to be in the osm data: http://www.deltadelta.de/nmz/sc21.png vs. http://www.openstreetmap.org/?lat=48.08617lon=11.50167zoom=17layers=B000FTF I tried to navigate to the Bad Forstenrieder Park. Since one can not pass this gap, the route went to Drygalski Allee, Herterichstr, then right and then to the grade3 path through the farmland. But I used car/motorcycle. What have I to put i which file so that routing goes not across unpaved tracks? TIA, Dani P.S: mkgmap 1597 Hmm, can't explain that - see attached pic showing mapsource routing through that junction - mkgmap version 1598, current OSM data. Cheers, Mark attachment: stablistrasse.png___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter OutOfMemoryError
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 memory. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap hangs on this type of way
Hi, I have noticed for the last 2 weeks the mkgmap was hanging but nothing in a the change log jumped out as someting that may have caused it. After some debugging I have tracked it down to ways like: http://www.openstreetmap.org/browse/way/29416921 The debug log shows it stops when it hits one of these, I fixed a few by splitting the way and remove the roundabout tag from the incoming way. That roundabout isn't right because it has a tail! Nonetheless, mkgmap should not hang because of that so I will be committing a fix soon. Thanks for the report. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] - when removing short arcs, don't zap looped ways whose ends almost touch
As this patch fixes the problem that Garvan reported and no one has reported that it has broken anything I will commit it in a day or so unless any -ve reports come in. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] MP: Close ways with both endpoints outside the bounding box
Hi WanMil, I give a very big GO for commit to this patch :-) I am not familiar with the MP code so it would be better if someone who is familiar with it commits it rather than me as I prefer to only commit stuff that I understand! Hope you don't have to wait to long. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] MapTk Updated + Nuvi POI code question
Those people using MapTk will be interested to know that a new version has just been released (2.7.2) - among other things, it fixes the problems with multiple lines/POIs that have extended types. Also, does anyone know if any of the extended type POI codes do not show a little dot in the middle of the icon on the Nuvi? Why do Garmin do that? Are they assholes? Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] MP: Close ways with both endpoints outside the bounding box
Felix, Mapsource 6.13.x never routes above more than 1 border however Sadly, that's true for our maps. But it will happily route over multiple tiles that have been created with cgpsmapper. I can take the tiles from the NZ opengps map set and generate an overview map with mkgmap and give it and the tiles to mapsource and it loves them, route anywhere Sir, no problem! I live in hope that one day the problem will be solved (I am still working on it as a background task). Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Bug report --remove-short-arcs=5 ???
Hi Garvan, Thanks for persevering with this issue. Your latest example has brought me enlightenment! I will work on a solution this evening. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] routable tiles with visible seas
Hi Nick, Unfortunately, those tiles are not routable as mkgmap --routes only seems to work with a default style. Routing should work with any style as long as the roads are given sensible garmin types/resolutions. There certainly shouldn't be any interaction between routing and sea generation. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v1] - when removing short arcs, don't zap looped ways whose ends almost touch
The short arc removal code was removing (non-short) arcs when their ends
were close enough to be considered the same point.
Now it just leaves them be.
Please test this patch if possible because I have reworked the short
arc removal code (and some badness could have crept in).
You will probably find some (loopy) ways appearing in your maps that
were not there before because they were being trashed.
Garvan, can you try this patch or shall I send you a mkgmap.jar?
Mark
diff --git a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
index fdeb2a8..d4ac861 100644
--- a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
+++ b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
@@ -829,113 +829,139 @@ public class Osm5XmlHandler extends DefaultHandler {
previousPoint = p;
anotherPassRequired = true;
}
- if (i 0) {
- // this is not the first point in the way
- if (p == previousPoint) {
- log.info( Way + way.getTag(name) + ( + way.toBrowseURL() + ) has consecutive identical points at + p.toOSMURL() + - deleting the second point);
- points.remove(i);
- // hack alert! rewind the loop index
- --i;
- anotherPassRequired = true;
- continue;
+ if(i == 0) {
+ // first point in way is a node so preserve
+ // it to ensure it won't be filtered out later
+ p.preserved(true);
+ continue;
+ }
+
+ // this is not the first point in the way
+ if (p == previousPoint) {
+ log.info( Way + way.getTag(name) + ( + way.toBrowseURL() + ) has consecutive identical points at + p.toOSMURL() + - deleting the second point);
+ points.remove(i);
+ // hack alert! rewind the loop index
+ --i;
+ anotherPassRequired = true;
+ continue;
+ }
+ arcLength += p.distance(previousPoint);
+ previousPoint = p;
+ Coord previousNode = points.get(previousNodeIndex);
+
+ // this point is a node if it has an arc count
+ Integer arcCount = arcCounts.get(p);
+ if(arcCount == null)
+ continue;
+
+ // it's a node so make the point preserved so
+ // that it won't get filtered out later
+ p.preserved(true);
+
+ if(p == previousNode) {
+ // this node is the same point object as the
+ // previous node - leave it and it will be
+ // handled later by the road loop splitter
+ previousNodeIndex = i;
+ arcLength = 0;
+ continue;
+ }
+
+ boolean mergeNodes = false;
+
+ if(p.equals(previousNode)) {
+ // nodes have identical coordinates but we
+ // only want to merge them if the arc length
+ // is small to avoid trashing loops
+ // (e.g. contours)
+ if(arcLength == 0 || arcLength minArcLength)
+ mergeNodes = true;
+ else if(complainedAbout.get(way) == null) {
+ log.info( Way + way.getTag(name) + ( + way.toBrowseURL() + ) has consecutive nodes with the same coordinates ( + p.toOSMURL() + ) but I am leaving them unmerged because the arc between them is + (int)(arcLength * 10) / 10.0 + m long);
+ complainedAbout.put(way, way);
}
- arcLength += p.distance(previousPoint);
- previousPoint = p;
- Coord previousNode = points.get(previousNodeIndex);
- // this point is a node if it has an arc count
- Integer arcCount = arcCounts.get(p);
- if (arcCount != null) {
- // make the point preserved so that it
- // won't get filtered out later
- p.preserved(true);
- // merge this node to previous node if the
- // two points have identical coordinates
- // or are closer than the minimum distance
- // allowed but they are not the same point
- // object
- if(p != previousNode
- (p.equals(previousNode) ||
-(minArcLength 0
- minArcLength arcLength))) {
-if(previousNode.getOnBoundary() p.getOnBoundary()) {
- if(p.equals(previousNode)) {
- // the previous node has
- // identical coordinates to
- // the current node so it can
- // be replaced but to avoid
- // the assertion above we need
- // to forget that it is on the
- // boundary
- previousNode.setOnBoundary(false);
- }
- else {
- // both the previous node and
- // this node are on the
- // boundary and they don't
- // have identical coordinates
- if(complainedAbout.get(way) == null) {
- log.warn( Way + way.getTag(name) + ( + way.toBrowseURL() + ) has short arc ( + String.format(%.2f, arcLength) + m) at + p.toOSMURL() + - but it can't be removed because both ends of the arc are boundary nodes!);
- complainedAbout.put(way, way);
- }
- break; // give up with this way
- }
-}
-String thisNodeId = (p.getOnBoundary())? 'boundary node' : +
[mkgmap-dev] MapTk typ problem
Hi Felix, You will be interested to learn that the problem I mentioned recently regarding my polylines not taking the style from the MapTk generated style file is due to a bug in MapTk - I contacted the author about it and he got back to me today saying it's a bug, I'm working on it. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] routable tiles with visible seas
Hi Nick, I'm not so sure I understand - is there something wrong with my typ file if it generates seas without flooding at any zoom level? I appreciate having to readup on creating routable styles. If you are using --generate-sea=polygons (or no-mp, means the same) you need to define a land type in your polygons style file, similar to this: natural=land [0x010100 resolution 12] I have used 0x010100 for the type but other people have used other codes. You also need to have an entry in the typ file for that polygon type specifying a draw priority that is above the sea polygons otherwise you won't get any visible land. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] - when removing short arcs, don't zap looped ways whose ends almost touch
Felix, I still have too many turn right / turn left even though the direction is straight on (like 10° direction change on same road). Please provide an example of that (snapshot of route in mapsource + OSM URL so I can grab the data). Thanks ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] MP: Close ways with both endpoints outside the bounding box
Felix, Well at some other points it did not want to route over 2 tile borders, seems not to be perfect yet - but the greatest step into the right direction so far when it comes to inter tile routing. Hmm, I'm sure that WanMil's patch does something good but I can't see how it can affect the inter-tile routing. Something changed in your map to allow the routing to improve, perhaps it's just a coincidence that it occurred when you had that patch installed? Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Etrex sea floods tile unless well zoomed out
I just noticed on my etrex that tiles that touch the coastline are flooded when zoomed in less than about 30Km. Neither mapsource or the nuvi show the same problem with the same map (this is with --generate-sea=polygons). When zoomed out, the coastline looks fine. Anyone else seen this? got a fix? Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Etrex sea floods tile unless well zoomed out
OK - I think I found what was wrong. I recently removed the 0x4b poly from the TYP file and that was the only poly on level 1. What I didn't realise is that all the polys on higher levels then got shifted down one level so that the sea poly was now on level 1 (I guess the etrex does something funky with polys at level 1). Fortunately, I could revert the commit that removed the 0x4b poly from the TYP file and so I didn't have to tediously change the levels of all the polys again. Hurrah for version control software! Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Etrex sea floods tile unless well zoomed out
Hi Felix, Many thanks for taking the time to respond - I believe the problem was caused by me removing the 0x4b poly from the TYP file (see last post). Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Etrex sea floods tile unless well zoomed out
Felix, Doesn't sound right to me. There is no need for 0x4b at all (my maps do not contain 0x4b). The only thing that I could imagine that happenend based on your above description is that both sea and land were at the same level, or that the polygon for land was not correctly set. Try using maptk for Typfiles, ati.land makes too many errors. There is definitely neither a need to have 0x4b inside typfile, or map. Sea and land were not at the same level but I wonder if because the sea poly ended up on level 1 when I removed the 0x4b poly, it had some odd effect. So, tell me, do you have any polys at a higher priority than your sea poly or is the sea poly on level 1? Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Etrex sea floods tile unless well zoomed out
Felix, Well according to maptk, sea is the only poly on DP level 0 (maptk counts from 0), while land is on 1, and all other polygons are on 2 or higher. Maptk makes no automatic adjustions to the levels, so if were to remove sea at 0, then all other polys would stay at their DP level. The sourcecode for my typfiles is available (like my styles) here: https://svn.origo.ethz.ch/openmtbmap Really bin ati.land if you don't want to have a lot of trouble and things going wrong. ati.land sucks regarding to extended types, and makes some more mistakes. If you feed my typfiles into ati.land, they come out completely crashed. OK - thanks again for the wisdom. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Etrex sea floods tile unless well zoomed out
Felix, Just another thought. Are you using single color or pattern for land? Try using a pattern for land (set both colors the same, or for maptk set just one pixel to a different color). Using single color instead of pattern, does definitely sometimes lead to problems. Garmin modern tpyfiles use patterns for all polys. OK - noted. You will be pleased to know that I have taken your advice and started looking at using MapTk to generate the typ file. I can generate a file but, weirdly, mapsource is ignoring my polyline styles. The couple of POIs I have and the polygons appear to be working OK, it's just the polylines it is ignoring. The file isn't huge so I have attached it to this email, please take a quick look at the polylines in case there is something obvious I am doing wrong. BTW - I can edit those polyline styles in MapTk and they look just as they should. Mark # Project file [Project] Product=OSM Map FamilyID=909 Version=0 Compile=0 Index=0 Style=1 IMGpath=/home/markb/OSM [END] # POIs [POI] Type=0x11500 String=4,Lights Color=1,0x00 Color=2,0xff Color=3,0xf0bf03 Color=4,0x00ff00 Line=0000 Line=01122110 Line=1111 Line=1221 Line=1111 Line=11122111 Line=11133111 Line=1111 Line=1331 Line=1111 Line=11133111 Line=11144111 Line=1111 Line=1441 Line=1111 Line=01144110 Line=0000 [END] [POI] Type=0x11501 Color=1,0xebf9f3 Color=2,0x66aed9 Color=3,0x1082c1 Color=4,0x1682c5 Color=5,0xeef9f3 Color=6,0x1f88c8 Color=7,0x0070c7 Color=8,0xe9f3fa Line=01234200 Line=5660 Line=2772 Line=4774 Line=4774 Line=2772 Line=0660 Line=00234280 [END] [POI] Type=0x11502 String=4,Camera Color=0,0xfdfe02 Color=1,0xf0fd0e Color=2,0xfdfe04 Color=4,0xfcfe07 Color=6,0xfdfd05 Color=7,0xf0fd0c Line=000112214100 Line=0067 Line=0000 Line=0008 Line=00080800 Line=00080800 Line=00080800 Line=0008 Line=0000 Line= Line= [END] # Polylines [Polyline] Type=0x01 Linewidth=3 Color=0,0xff [END] [Polyline] Type=0x02 Linewidth=3 Color=0,0x00ff00 [END] [Polyline] Type=0x03 Linewidth=3 Color=0,0xff [END] [Polyline] Type=0x04 Linewidth=2 Color=0,0xff8000 [END] [Polyline] Type=0x05 Linewidth=2 Color=0,0x00 [END] [Polyline] Type=0x06 Linewidth=2 Color=0,0x606060 [END] [Polyline] Type=0x08 Linewidth=2 Color=0,0x606060 [END] [Polyline] Type=0x09 Linewidth=2 Color=0,0x606060 [END] [Polyline] Type=0x0b Linewidth=2 Color=0,0x606060 [END] [Polyline] Type=0x0c Linewidth=2 Color=0,0x606060 [END] [Polyline] Type=0x10 Color=0,0x00 Line=00110011001100110011001100110011 [END] [Polyline] Type=0x13 String=0,NPE Color=0,0x00ff00 Color=1,0xff Line= Line= [END] [Polyline] Type=0x14 Color=0,0x00 Line=0111011101110111 Line= Line=0111011101110111 [END] [Polyline] Type=0x15 Linewidth=1 Color=0,0xff [END] [Polyline] Type=0x16 Color=0,0x008000 Line=0011001100110011 [END] [Polyline] Type=0x1c Color=0,0xff Line=00110011001100110011001100110011 [END] [Polyline] Type=0x1d Color=0,0x00ff00 Line=00110011001100110011001100110011 [END] [Polyline] Type=0x27 Linewidth=2 Color=0,0x0080ff [END] [Polyline] Type=0x29 Linewidth=1 Color=0,0x808080 [END] [Polyline] Type=0x10107 String=0,Bridge Color=0,0x804000 Line= Line= Line= Line= Line= [END] [Polyline] Type=0x10e00 String=0,Tunnel Color=0,0x00 Line= Line= Line= Line= Line= [END] # Polygons [Polygon] Type=0x02 DrawOrder=3 [END] [Polygon] Type=0x04 DrawOrder=3 Color=0,0x404000 Line=01100110 Line=10011001 Line=110110011011 Line=111001100111 Line=01100110 Line=10011001 Line=110110011011 Line=111001100111 Line=111001100111 Line=110110011011 Line=10011001 Line=01100110 Line=111001100111 Line=110110011011 Line=10011001 Line=01100110 Line=01100110 Line=10011001 Line=110110011011 Line=111001100111 Line=01100110 Line=10011001 Line=110110011011 Line=111001100111 Line=111001100111 Line=110110011011
Re: [mkgmap-dev] natural=coastline;cliff
Hi Felix, Patch works for UK. Good, me too - I have committed it. However I think we should rather have this done generally for ;. Quite possibly, but that requires more thought/effort and what we need right now is a quick fix to make the coastline work again so we will have to make do with my effort for the moment. When a better solution comes along, we can take out this code and it will have served its purpose. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] bug in road-name-pois
Hello Minko, The option --road-name-pois often creates place names that are totally wrong. Two adjacent streets in the same district can have different place names. I think it is better not to show the place name until this problem is solved? Is there a way to make these POI invisible on the map? The maker of the map can use any POI type code and some show as blobs on the map and some do not. It also depends on which GPS model you are using. If the place names are unreliable, it would be better not to use the road-name-pois option. It should be redundant now anyway if the roadname search works OK. I originally implemented the road-name-pois option as a workaround for the lack of road searching capability. Other people worked on the location code that decides the place names - it sounds like it's that code that's being odd, not the road-name-poi feature, itself. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] - yet more turn heading adjustment fixes
Carlos, It seems you know my city better than me ;-) I wish I did, I'm sure the weather would be a lot nicer there than it is here! The closest I have been to your city is looking at it with josm. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Flooding of sea - this time inside the middle of the Alps, not related to geofabrik cutting
Felix, The new flooding is solved. The big flooding in the tile of Bremen in Germany still exists however (I do know that the geofabrik cut is 100% responsible for it). There is one problem however, the land polygon is ommitted. So background color is missing, t'would be great if not the sea polygon be dropped (or as well) but also the land polygon be drawn.: So the 0x4b background poly isn't the same colour as the land? OK - I will generate a land poly as well - new patch will be posted in a little while Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Bug report --remove-short-arcs=5 ???
Hello Garvan, I found a generalize function in gpsmapedit that removed 10% of the points in the file, but the national boundaries still did not display, so I split the very long polyline up and then it compiled correctly. I don't see why that was required because we already split lines that have more than 250 points. This experience may be worth noting for others who see long lines disappearing with no error message when compiling in osm format. Sure, but I would rather find out why the existing line splitting didn't work satisfactorily. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Flooding of sea - this time inside the middle of the Alps, not related to geofabrik cutting
I don't use 0x4b in Typfile anymore. Having two polygons for one
function (get rid of yellow on etrex) is slowing down GPS/Mapsource .13.x
Fair enough - please try attached new patch that generates the land
poly.
The big flooding in the tile of Bremen
in Germany still exists however (I do know that the geofabrik cut is
100% responsible for it).
Given the location, I would think that the coastline reaches the edge
of the tile. In that case, this patch doesn't help. The coastline must
be broken. I assume that close-gaps doesn't fix the problem.diff --git a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
index f78b1f9..e94bcc6 100644
--- a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
+++ b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
@@ -115,6 +115,7 @@ public class Osm5XmlHandler extends DefaultHandler {
private boolean generateSeaUsingMP = true;
private boolean allowSeaSectors = true;
private boolean extendSeaSectors;
+ private boolean roadsReachBoundary;
private int maxCoastlineGap;
private String[] landTag = { natural, land };
private final Double minimumArcLength;
@@ -618,10 +619,12 @@ public class Osm5XmlHandler extends DefaultHandler {
coordMap = null;
+ if(bbox != null (generateSea || minimumArcLength != null))
+ makeBoundaryNodes();
+
if (generateSea)
generateSeaPolygon(shoreline);
- long start = System.currentTimeMillis();
for (Relation r : relationMap.values())
converter.convertRelation(r);
@@ -630,11 +633,8 @@ public class Osm5XmlHandler extends DefaultHandler {
nodeMap = null;
- if(minimumArcLength != null) {
- if(bbox != null)
-makeBoundaryNodes();
+ if(minimumArcLength != null)
removeShortArcsByMergingNodes(minimumArcLength);
- }
nodeIdMap = null;
@@ -691,7 +691,8 @@ public class Osm5XmlHandler extends DefaultHandler {
// highway count one
clippedPair[1].incHighwayCount();
++numBoundaryNodesAdded;
-
+ if(!roadsReachBoundary way.getTag(highway) != null)
+ roadsReachBoundary = true;
}
else if(clippedPair[1].getOnBoundary())
++numBoundaryNodesDetected;
@@ -712,6 +713,8 @@ public class Osm5XmlHandler extends DefaultHandler {
// highway count one
clippedPair[0].incHighwayCount();
++numBoundaryNodesAdded;
+ if(!roadsReachBoundary way.getTag(highway) != null)
+ roadsReachBoundary = true;
}
else if(clippedPair[0].getOnBoundary())
++numBoundaryNodesDetected;
@@ -1187,6 +1190,7 @@ public class Osm5XmlHandler extends DefaultHandler {
// the remaining shoreline segments should intersect the boundary
// find the intersection points and store them in a SortedMap
SortedMapEdgeHit, Way hitMap = new TreeMapEdgeHit, Way();
+ boolean shorelineReachesBoundary = false;
long seaId;
Way sea;
for (Way w : shoreline) {
@@ -1343,6 +1347,13 @@ public class Osm5XmlHandler extends DefaultHandler {
w.getPoints().add(w.getPoints().get(0));
log.info(adding non-island landmass, hits.size()= + hits.size());
islands.add(w);
+ shorelineReachesBoundary = true;
+ }
+
+ if(!shorelineReachesBoundary roadsReachBoundary) {
+ // try to avoid tiles being flooded by anti-lakes or other
+ // bogus uses of natural=coastline
+ generateSeaBackground = false;
}
ListWay antiIslands = new ArrayListWay();
@@ -1451,6 +1462,23 @@ public class Osm5XmlHandler extends DefaultHandler {
if(generateSeaUsingMP)
seaRelation.addElement(outer, sea);
}
+ else {
+ // background is land
+ if(!generateSeaUsingMP) {
+// generate a land polygon so that the tile's
+// background colour will match the land colour on the
+// tiles that do contain some sea
+long landId = FakeIdGenerator.makeFakeId();
+Way land = new Way(landId);
+land.addPoint(nw);
+land.addPoint(sw);
+land.addPoint(se);
+land.addPoint(ne);
+land.addPoint(nw);
+land.addTag(landTag[0], landTag[1]);
+wayMap.put(landId, land);
+ }
+ }
if(generateSeaUsingMP) {
Area mpBbox = (bbox != null ? bbox : ((MapDetails) collector).getBounds());
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] natural=coastline;cliff
Hi Steve, Someone has tagged part of the UK coastline with natural=coastline;cliff and this has broken --generate-sea=polygons,no-sea-sectors,close-gaps=1000. Is this valid syntax that mkgmap should cope with? Don't know whether it's valid or not but I will put in a workaround. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] natural=coastline;cliff
Hi Steve,
Someone has tagged part of the UK coastline with natural=coastline;cliff and
this has broken
--generate-sea=polygons,no-sea-sectors,close-gaps=1000. Is this valid syntax
that mkgmap should cope with?
The attached patch is a quick workaround.
If possible, please test.
Cheers,
Mark
diff --git a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
index f78b1f9..7da3508 100644
--- a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
+++ b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
@@ -517,9 +517,33 @@ public class Osm5XmlHandler extends DefaultHandler {
if(motorway.equals(highway) ||
trunk.equals(highway))
motorways.add(currentWay);
-if(generateSea coastline.equals(currentWay.getTag(natural))) {
- currentWay.deleteTag(natural);
- shoreline.add(currentWay);
+if(generateSea) {
+ String natural = currentWay.getTag(natural);
+ if(natural != null) {
+ if(coastline.equals(natural)) {
+ currentWay.deleteTag(natural);
+ shoreline.add(currentWay);
+ }
+ else if(natural.contains(;)) {
+ // cope with compound tag value
+ String others = null;
+ boolean foundCoastline = false;
+ for(String n : natural.split(;)) {
+if(coastline.equals(n.trim()))
+ foundCoastline = true;
+else if(others == null)
+ others = n;
+else
+ others += ; + n;
+ }
+ if(foundCoastline) {
+currentWay.deleteTag(natural);
+if(others != null)
+ currentWay.addTag(natural, others);
+shoreline.add(currentWay);
+ }
+ }
+ }
}
currentNodeInWay = null;
currentWayStartsWithFIXME = false;
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Help required for style rule
Style gurus, I want to have a rule that matches one way trunk roads. Given that onewayness can be specified with (at least) 3 different tag values (1,yes,true) do I have to have something like the following, or can it be simplified: highway=trunk (oneway=yes|oneway=true|oneway=1) [...] i.e. does the following mean the same? highway=trunk oneway [...] Thanks Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v2] - yet more turn heading adjustment fixes
v2 - further fixes
Carlos, this still gives you an extra turn left onto Calle Osa
Mayor and I know what's happening there but can't fix it - how
about the other problems you were seeing? better/worse?
Hopefully, these changes will fix the bad routing directions we have
been seeing recently - please test and report success/failure.
diff --git a/src/uk/me/parabola/imgfmt/app/net/RouteNode.java b/src/uk/me/parabola/imgfmt/app/net/RouteNode.java
index 2b8ca79..e86f2de 100644
--- a/src/uk/me/parabola/imgfmt/app/net/RouteNode.java
+++ b/src/uk/me/parabola/imgfmt/app/net/RouteNode.java
@@ -15,6 +15,8 @@
package uk.me.parabola.imgfmt.app.net;
import java.util.ArrayList;
+import java.util.Collections;
+import java.util.Comparator;
import java.util.Iterator;
import java.util.List;
@@ -298,6 +300,12 @@ public class RouteNode implements ComparableRouteNode {
RoadDef rda = raa.getRoadDef();
RoadDef rdb = rab.getRoadDef();
+
+ if(rda.getId() == rdb.getId()) {
+ // roads have the same (OSM) id
+ return true;
+ }
+
boolean bothArcsNamed = false;
for(Label laba : rda.getLabels()) {
if(laba != null laba.getOffset() != 0) {
@@ -339,6 +347,26 @@ public class RouteNode implements ComparableRouteNode {
return false;
}
+ private static boolean rightTurnRequired(int inHeading, int outHeading, int sideHeading) {
+ // given the headings of the incoming, outgoing and side
+ // roads, decide whether a side road is to the left or the
+ // right of the main road
+
+ outHeading -= inHeading;
+ while(outHeading -180)
+ outHeading += 360;
+ while(outHeading 180)
+ outHeading -= 360;
+
+ sideHeading -= inHeading;
+ while(sideHeading -180)
+ sideHeading += 360;
+ while(sideHeading 180)
+ sideHeading -= 360;
+
+ return sideHeading outHeading;
+ }
+
private static int ATH_OUTGOING = 1;
private static int ATH_INCOMING = 2;
@@ -375,9 +403,29 @@ public class RouteNode implements ComparableRouteNode {
final int minDiffBetweenOutgoingAndOtherArcs = 45;
final int minDiffBetweenIncomingAndOtherArcs = 50;
- for(RouteArc inArc : incomingArcs) {
+ // list of outgoing arcs discovered at this node
+ ListRouteArc outgoingArcs = new ArrayListRouteArc();
+
+ // sort incoming arcs by decreasing class/speed
+ ListRouteArc inArcs = new ArrayListRouteArc(incomingArcs);
+
+ Collections.sort(inArcs, new ComparatorRouteArc() {
+ public int compare(RouteArc ra1, RouteArc ra2) {
+ int c1 = ra1.getRoadDef().getRoadClass();
+ int c2 = ra2.getRoadDef().getRoadClass();
+ if(c1 == c2)
+ return (ra2.getRoadDef().getRoadSpeed() -
+ ra1.getRoadDef().getRoadSpeed());
+ return c2 - c1;
+ }
+});
+
+ // look at incoming arcs in order of decreasing class/speed
+ for(RouteArc inArc : inArcs) {
+
+RoadDef inRoadDef = inArc.getRoadDef();
-if(!inArc.isForward() inArc.getRoadDef().isOneway()) {
+if(!inArc.isForward() inRoadDef.isOneway()) {
// ignore reverse arc if road is oneway
continue;
}
@@ -392,7 +440,7 @@ public class RouteNode implements ComparableRouteNode {
for(RouteArc[] pair : throughRoutes) {
if(pair[0] == inArc) {
outArc = pair[1];
- log.info(Found through route from + inArc.getRoadDef() + to + outArc.getRoadDef());
+ log.info(Found through route from + inRoadDef + to + outArc.getRoadDef());
break;
}
}
@@ -405,7 +453,7 @@ public class RouteNode implements ComparableRouteNode {
if(oa.getDest() != inArc.getSource()) {
// this arc is not going to the same node as
// inArc came from
- if(oa.getRoadDef() == inArc.getRoadDef()) {
+ if(oa.getRoadDef() == inRoadDef) {
outArc = oa;
break;
}
@@ -415,7 +463,7 @@ public class RouteNode implements ComparableRouteNode {
if(outArc == null) {
// next, although the RoadDefs don't match, use
- // possiblySameRoad() to see if the road
+ // possiblySameRoad() to see if the roads' id or
// labels (names/refs) match
for(RouteArc oa : arcs) {
if(oa.getDest() != inArc.getSource()) {
@@ -430,43 +478,60 @@ public class RouteNode implements ComparableRouteNode {
}
}
-if(outArc == null) {
+if(outArc == null inRoadDef.getNumLabels() == 0) {
// last ditch attempt to find the outgoing arc -
- // try and find a single arc that has the same
- // road class and speed as the incoming arc
- int inArcClass = inArc.getRoadDef().getRoadClass();
- int inArcSpeed = inArc.getRoadDef().getRoadSpeed();
+ // try and find a single (anonymous) arc that has
+ // the same road class and speed as the incoming
+ // arc
+ int inArcClass = inRoadDef.getRoadClass();
+ int inArcSpeed = inRoadDef.getRoadSpeed();
for(RouteArc oa : arcs) {
- if(oa.getDest() != inArc.getSource()
+ if(oa.getRoadDef().getNumLabels() == 0
+ oa.getDest() !=
Re: [mkgmap-dev] Flooding of sea - this time inside the middle of the Alps, not related to geofabrik cutting
It could be that tile contains a lake tagged natural=coastline but it's the wrong direction, i.e. it's an anti-lake! ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v1] fix for weird turn directions regression
Hopefully fixes the recent regression which caused incorrect turn
directions to be issued (most likely to occur when entering roundabouts
that have flares).
Actually, the bug was there before but it was being masked by some other
code that recently got removed so the bug then popped to the surface!
Please test.
Mark
diff --git a/src/uk/me/parabola/imgfmt/app/net/RouteNode.java b/src/uk/me/parabola/imgfmt/app/net/RouteNode.java
index 2b8ca79..5a55740 100644
--- a/src/uk/me/parabola/imgfmt/app/net/RouteNode.java
+++ b/src/uk/me/parabola/imgfmt/app/net/RouteNode.java
@@ -339,6 +339,24 @@ public class RouteNode implements ComparableRouteNode {
return false;
}
+ private static boolean rightTurnRequired(int inHeading, int outHeading, int sideHeading) {
+ // decide whether a side road is to the left of the right
+ // given the headings of the incoming, outgoing and side roads
+ int a = sideHeading - (inHeading + 180);
+ while(a -180)
+ a += 360;
+ while(a 180)
+ a -= 360;
+ if(a 0)
+ return false;
+ a = sideHeading - outHeading;
+ while(a -180)
+ a += 360;
+ while(a 180)
+ a -= 360;
+ return a 0;
+ }
+
private static int ATH_OUTGOING = 1;
private static int ATH_INCOMING = 2;
@@ -520,13 +538,13 @@ public class RouteNode implements ComparableRouteNode {
inToOtherDelta += 360;
int newHeading = otherHeading;
- if(outToOtherDelta 0) {
+ if(rightTurnRequired(inHeading, outHeading, otherHeading)) {
// side road to the right
if((mask ATH_OUTGOING) != 0
- outToOtherDelta minDiffBetweenOutgoingAndOtherArcs)
+ Math.abs(outToOtherDelta) minDiffBetweenOutgoingAndOtherArcs)
newHeading = outHeading + minDiffBetweenOutgoingAndOtherArcs;
if((mask ATH_INCOMING) != 0
- inToOtherDelta minDiffBetweenIncomingAndOtherArcs) {
+ Math.abs(inToOtherDelta) minDiffBetweenIncomingAndOtherArcs) {
int nh = inHeading + minDiffBetweenIncomingAndOtherArcs;
if(nh newHeading)
newHeading = nh;
@@ -535,13 +553,13 @@ public class RouteNode implements ComparableRouteNode {
if(newHeading 180)
newHeading -= 360;
}
- else if(outToOtherDelta 0) {
+ else {
// side road to the left
if((mask ATH_OUTGOING) != 0
- outToOtherDelta -minDiffBetweenOutgoingAndOtherArcs)
+ Math.abs(outToOtherDelta) minDiffBetweenOutgoingAndOtherArcs)
newHeading = outHeading - minDiffBetweenOutgoingAndOtherArcs;
if((mask ATH_INCOMING) != 0
- inToOtherDelta -minDiffBetweenIncomingAndOtherArcs) {
+ Math.abs(inToOtherDelta) minDiffBetweenIncomingAndOtherArcs) {
int nh = inHeading - minDiffBetweenIncomingAndOtherArcs;
if(nh newHeading)
newHeading = nh;
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] fix for weird turn directions regression
Hi Carlos, I'm sorry, I tested the wrong map (too much things at the same time). I have seen some improvements, but not all weird instructions have disappeared. I'll report more details after testing some more. OK - I will work on it again this evening. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Flooding of sea - this time inside the middle of the Alps, not related to geofabrik cutting
Felix, I looked for an anti-lake, but could not find one... I think ultimately we would need some check against flooding. Easiest maybe would be if there are more than 30 forest polygons inside water (without natural=land) and if so, then assume tile is flooded and put land into the whole tile. Much better to miss some sea, then to have flooding. Agreed, sanity checking the sea areas (do they contain roads/cities) would make sense because at the moment it only needs a tile to contain a single way tagged natural=coastline and it is likely to get flooded. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] 1point roads with highway shield for POI
Felix, It would be great to have the possibility to put a one point road (there has to be some code to make sure it's not munged by the dp-filter) with a highway shield. I don't think you can have a one point road but I don't see why you can't have a very short two point road (say, 2.5m between the points). You would not want them to be connected to the normal road network. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Weird turn instructions
Hi Carlos, At least since version of 12/02/2010 I'm getting some weird turn instructions in places where they worked fine in the past . In this area [1] I get two of these estrange instructions when driving SE from Avenida Cordel de Merinas to SW in Avenida Hernán Cortés. The sequence of instructions (both MapSource and gps) is: 1-Turn right at Avenida de Extremadura (OK) 2-Turn left at Avenida de las Delicias (wrong) 3-Turn right at Avenida de las Delicias (OK) 4-Turn right at Avenida Hernán Cortés (wrong) At 2 there's been no change in the data for a long time. I noticed 4 first time after creating a through_route relation to avoid a keep left instruction, but the problem could have been there before. nuvi gives another wrong turn right at 3.5 With that patch I posted earlier, this route is fine now in mapsource (no spurious directions). Are you still seeing problems with that route? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Weird turn instructions
Hi Nakor, Would it be because of that regression that whendriving that route ( http://maps.cloudmade.com/?lat=42.560106lng=-83.18043zoom=17directions=42.561639094255526,-83.1770396232605,42.558565013969705,-83.18168520927429travel=carstyleId=1opened_tab=1) the only instruction you get is Turn right in Golfview Dr? I don't think so - I just tried with and without that fix and mapsource told me the same in both cases: 1. WBigBeaverRd0 m 0:00:00 N42.56177 W83.17316 2. Get on W Big Beaver Rd and drive west 0 m 0 m 0:00:00 0:00:00 90° trueN42.56177 W83.17316 3. Turn left onto Lakeview Dr ramp 586 m 586 m 0:00:50 0:00:50 268° true N42.56155 W83.18030 4. Turn right onto Golfview Dr 969 m 383 m 0:01:04 0:01:54 177° true N42.55870 W83.18120 Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Flooding of sea - this time inside the middle of the Alps, not related to geofabrik cutting
Felix, I looked for an anti-lake, but could not find one... So that tile contains no ways with natural=coastline? Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Flooding of sea - this time inside the middle of the Alps, not related to geofabrik cutting
Well it probably does, but it must be tiny. Will recheck with gpsmapedit later - in Mapsource I could not find it. grep is your friend. However, I'm just working on a patch to try and avoid the flooding - stay tuned. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Flooding of sea - this time inside the middle of the Alps, not related to geofabrik cutting
Hi Felix,
Please try the attached patch, hopefully it will stop the flooding.
Mark
diff --git a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
index f78b1f9..f7aba49 100644
--- a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
+++ b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
@@ -115,6 +115,7 @@ public class Osm5XmlHandler extends DefaultHandler {
private boolean generateSeaUsingMP = true;
private boolean allowSeaSectors = true;
private boolean extendSeaSectors;
+ private boolean roadsReachBoundary;
private int maxCoastlineGap;
private String[] landTag = { natural, land };
private final Double minimumArcLength;
@@ -618,10 +619,12 @@ public class Osm5XmlHandler extends DefaultHandler {
coordMap = null;
+ if(bbox != null (generateSea || minimumArcLength != null))
+ makeBoundaryNodes();
+
if (generateSea)
generateSeaPolygon(shoreline);
- long start = System.currentTimeMillis();
for (Relation r : relationMap.values())
converter.convertRelation(r);
@@ -630,11 +633,8 @@ public class Osm5XmlHandler extends DefaultHandler {
nodeMap = null;
- if(minimumArcLength != null) {
- if(bbox != null)
-makeBoundaryNodes();
+ if(minimumArcLength != null)
removeShortArcsByMergingNodes(minimumArcLength);
- }
nodeIdMap = null;
@@ -691,7 +691,8 @@ public class Osm5XmlHandler extends DefaultHandler {
// highway count one
clippedPair[1].incHighwayCount();
++numBoundaryNodesAdded;
-
+ if(!roadsReachBoundary way.getTag(highway) != null)
+ roadsReachBoundary = true;
}
else if(clippedPair[1].getOnBoundary())
++numBoundaryNodesDetected;
@@ -712,6 +713,8 @@ public class Osm5XmlHandler extends DefaultHandler {
// highway count one
clippedPair[0].incHighwayCount();
++numBoundaryNodesAdded;
+ if(!roadsReachBoundary way.getTag(highway) != null)
+ roadsReachBoundary = true;
}
else if(clippedPair[0].getOnBoundary())
++numBoundaryNodesDetected;
@@ -1187,6 +1190,7 @@ public class Osm5XmlHandler extends DefaultHandler {
// the remaining shoreline segments should intersect the boundary
// find the intersection points and store them in a SortedMap
SortedMapEdgeHit, Way hitMap = new TreeMapEdgeHit, Way();
+ boolean shorelineReachesBoundary = false;
long seaId;
Way sea;
for (Way w : shoreline) {
@@ -1343,6 +1347,13 @@ public class Osm5XmlHandler extends DefaultHandler {
w.getPoints().add(w.getPoints().get(0));
log.info(adding non-island landmass, hits.size()= + hits.size());
islands.add(w);
+ shorelineReachesBoundary = true;
+ }
+
+ if(!shorelineReachesBoundary roadsReachBoundary) {
+ // try to avoid tiles being flooded by anti-lakes or other
+ // bogus uses of natural=coastline
+ generateSeaBackground = false;
}
ListWay antiIslands = new ArrayListWay();
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] Reduce number of cuts in multipolygon processing
Marko, If nobody opposes, I will commit the patch. Fine, but why not hang on for a while and give people a chance to try it out and report back before it gets committed. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] Reduce number of cuts in multipolygon processing
Hello Marko, Sure, it is a non-trivial change to the algorithm. What about one week? If I forget, WanMil please remind me. :-) My rule of thumb for committing non-trivial changes goes along the lines of: if you receive negative reports, either fix the patch or convince the reporter the're doing something wrong! if you receive positive reports, commit the patch when you feel confident that it's received a reasonable amount of testing - the more positive reports you receive, the greater the likelyhood that's it's going to be OK and you can commit sooner rather than later. if you receive no reports, either badger people to try it out or just commit the patch anyway and if it breaks everything that's their fault for not helping with the testing. Something like that. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Weird turn instructions
Hi Carlos, At least since version of 12/02/2010 I'm getting some weird turn instructions in places where they worked fine in the past . In this area [1] I get two of these estrange instructions when driving SE from Avenida Cordel de Merinas to SW in Avenida Hernán Cortés. The sequence of instructions (both MapSource and gps) is: 1-Turn right at Avenida de Extremadura (OK) 2-Turn left at Avenida de las Delicias (wrong) 3-Turn right at Avenida de las Delicias (OK) 4-Turn right at Avenida Hernán Cortés (wrong) At 2 there's been no change in the data for a long time. I noticed 4 first time after creating a through_route relation to avoid a keep left instruction, but the problem could have been there before. nuvi gives another wrong turn right at 3.5 [1] http://www.informationfreeway.org/?lat=39.482090468611915lon=-6.371916898255968zoom=17layers=BF000F Yes, there is a recently introduced regression. I know which commit introduced it but haven't had time to investigate fully. I hope to have a fix real soon. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Strange roundabout flare road warning
Hello Marko, I tried to fix this by adding oneway=yes to the flare roads, but it did not fix the issue. Other warnings that I fixed yesterday are gone, so my dump should be fine. 2010/02/23 09:51:40 WARNING (RouteNode): 63240004.osm.gz: Outgoing roundabout flare road (http://www.openstreetmap.org/browse/way/50982726) points in wrong direction? http://www.openstreetmap.org/?mlat=67.78665mlon=24.81923zoom=17 Any ideas what might be wrong? Yes, it's a bug in the flare check code. I have seen the same problem in a few places in the UK map. I shall look into it. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v1] flare road checking bug fixes
The good news is that this should now no longer falsely complain about
a flare road being the wrong direction when that flare road pair are
the only roads connected to a given roundabout.
The bad news is that it will now find more bad flare roads than it did
before - and you thought you had fixed them all!
diff --git a/src/uk/me/parabola/imgfmt/app/net/RouteNode.java b/src/uk/me/parabola/imgfmt/app/net/RouteNode.java
index c01f7a9..f33496b 100644
--- a/src/uk/me/parabola/imgfmt/app/net/RouteNode.java
+++ b/src/uk/me/parabola/imgfmt/app/net/RouteNode.java
@@ -602,6 +602,31 @@ public class RouteNode implements ComparableRouteNode {
}
}
+ // determine distance between two nodes on a roundabout
+ private int roundaboutSegmentLength(final RouteNode n1, final RouteNode n2) {
+ ListRouteNode seen = new ArrayListRouteNode();
+ int len = 0;
+ RouteNode n = n1;
+ for(;;) {
+ seen.add(n);
+ for(RouteArc a : n.arcs) {
+if(a.isForward()
+ a.getRoadDef().isRoundabout()
+ !a.getRoadDef().isSynthesised()) {
+ len += a.getLength();
+ n = a.getDest();
+ if(n == n2)
+ return len;
+ break;
+}
+ }
+ if(seen.contains(n)) {
+// looped around without finding n2 - weird
+return Integer.MAX_VALUE;
+ }
+ }
+ }
+
// sanity check roundabout flare roads - the flare roads connect a
// two-way road to a roundabout using short one-way segments so
// the resulting sub-junction looks like a triangle with two
@@ -614,12 +639,54 @@ public class RouteNode implements ComparableRouteNode {
// roundabout
if(!r.isForward() || !r.getRoadDef().isRoundabout() || r.getRoadDef().isSynthesised())
continue;
- // now try and find the two arcs that make up the
- // triangular flare connected to both ends of r
+ // follow the arc to find the first node that connects the
+ // roundabout to a non-roundabout segment
RouteNode nb = r.getDest();
+ for(;;) {
+boolean connectsToNonRoundaboutSegment = false;
+RouteArc nextRoundaboutArc = null;
+for(RouteArc nba : nb.arcs) {
+ if(!nba.getRoadDef().isSynthesised()) {
+ if(nba.getRoadDef().isRoundabout()) {
+ if(nba.isForward())
+nextRoundaboutArc = nba;
+ }
+ else
+ connectsToNonRoundaboutSegment = true;
+ }
+}
+
+if(nb == this) {
+ // looped back to start - give up
+ if(!connectsToNonRoundaboutSegment) {
+ // FIXME - stop this warning griping about
+ // roundabouts whose ways are tagged
+ // highway=construction
+
+ // log.warn(Roundabout + r.getRoadDef() + is not connected to any ways at + coord.toOSMURL());
+ }
+ nb = null;
+ break;
+}
+
+if(connectsToNonRoundaboutSegment || nextRoundaboutArc == null)
+ break;
+
+nb = nextRoundaboutArc.getDest();
+ }
+
+ if(nb == null) {
+// something weird about this roundabout, forget it
+continue;
+ }
+
+ // now try and find the two arcs that make up the
+ // triangular flare connected to both ends of the
+ // roundabout segment
for(RouteArc fa : arcs) {
if(!fa.getRoadDef().doFlareCheck())
continue;
+
for(RouteArc fb : nb.arcs) {
if(!fb.getRoadDef().doFlareCheck())
continue;
@@ -627,32 +694,24 @@ public class RouteNode implements ComparableRouteNode {
// found the 3rd point of the triangle that
// should be connecting the two flare roads
- // first, special test for roundabouts that
- // have a single flare and no other
- // connections - only check the flare for the
- // shorter of the two roundabout segments
-
- boolean isShortest = true;
- for(RouteArc rb : nb.arcs) {
- if(rb.getDest() == this
- rb.isForward()
- rb.getRoadDef().isRoundabout()) {
-isShortest = r.getLength() rb.getLength();
-break;
- }
- }
+ // first, special test required to cope with
+ // roundabouts that have a single flare and no
+ // other connections - only check the flare
+ // for the shorter of the two roundabout
+ // segments
- if(!isShortest)
+ if(roundaboutSegmentLength(this, nb) =
+ roundaboutSegmentLength(nb, this))
continue;
if(maxFlareLengthRatio 0) {
// if both of the flare roads are much
- // longer than the length of r, they are
- // probably not flare roads at all but
- // just two roads that meet up - so ignore
- // them
- final int maxFlareLength = r.getLength() * maxFlareLengthRatio;
- if(r.getLength() 0
+ // longer than the length of the
+ // roundabout segment, they are probably
+ // not flare roads at all but just two
+ // roads that meet up - so ignore them
+ final int maxFlareLength = roundaboutSegmentLength(this, nb) * maxFlareLengthRatio;
+ if(maxFlareLength 0
fa.getLength() maxFlareLength
fb.getLength() maxFlareLength) {
Re: [mkgmap-dev] Bug report --remove-short-arcs=5 ???
Hello Garvan, http://dl.dropbox.com/u/4900023/cambodia.osm If you zip up that file to save my bandwidth, I will take a look at it. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Bug report --remove-short-arcs=5 ???
Well, I looked at it but learnt nothing. I just get an empty map, no lines, no diagnostics, nothing at all. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Bug report --remove-short-arcs=5 ???
If you zoom in I think the contours and provincial boundaries will show up, but at full zoom nothing shows because the national boundaries are missing. I am not sure exactly when they should show in mapsource, but gpsmapedit tells me they are not in the img file at all. OK, I think what's happening here is that the file contains a lot of points that are so close together that the remove-short-arc process just throws them away and then throws the ways away because they contain less than 2 points. If you look at the diagnostics you get lots of lines like: 2010/02/23 14:49:04 INFO (Osm5XmlHandler): cambodia.osm: Way 200 (http://www.openstreetmap.org/browse/way/-2475) has consecutive nodes with the same coordinates (http://www.openstreetmap.org/?mlat=11.78333mlon=103.63197zoom=17) - merging node -187534 into -187526 2010/02/23 14:49:04 INFO (Osm5XmlHandler): cambodia.osm: Way 200 (http://www.openstreetmap.org/browse/way/-2478) has consecutive nodes with the same coordinates (http://www.openstreetmap.org/?mlat=11.78236mlon=103.65167zoom=17) - merging node -187581 into -187573 2010/02/23 14:49:04 INFO (Osm5XmlHandler): cambodia.osm: Way 700 (http://www.openstreetmap.org/browse/way/-2477) has consecutive nodes with the same coordinates (http://www.openstreetmap.org/?mlat=11.78327mlon=103.34835zoom=17) - merging node -187572 into -187564 and then later you get: 2010/02/23 14:49:09 INFO (Osm5XmlHandler): cambodia.osm: Way 100 (http://www.openstreetmap.org/browse/way/-11092) has less than 2 points - deleting it 2010/02/23 14:49:09 INFO (Osm5XmlHandler): cambodia.osm: Way 200 (http://www.openstreetmap.org/browse/way/-11091) has less than 2 points - deleting it 2010/02/23 14:49:09 INFO (Osm5XmlHandler): cambodia.osm: Way 100 (http://www.openstreetmap.org/browse/way/-11094) has less than 2 points - deleting it Can you reduce the number of points in the ways? Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] flare road checking bug fixes
Marko, Thanks for the report. In other words, please commit the patch. Good, I will do that. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] motor_vehicle
Hello Marko,
+ new AccessMapping(motor_vehicle, RoadNetwork.NO_CAR),
That's not enough because if motor_vehicle=no, you also want stop
psv/taxi/emergency/hgv.
It's more like:
String mv = way.getTag(motor_vehicle);
if(accessExplicitlyDenied(mv)) {
way.addTag(motorcar, no);
// and so on for the other motor vehicle types
}
else if(accessExplicitlyAllowed(mv)) {
way.addTag(motorcar, yes);
// ...
}
That will get the Java to do what some people have been doing in the
style file.
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] access restrictions and routing
Hello Torsten,
highway=* mkgmap_routing=foot {set motor_vehicle=no} [0x09 road_class=1
road=speed=1 resolution 22]
motor_vehicle is not understood by mkgmap - how about:
{set access=no; set foot=yes}
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] heed the through_route relation when adjusting turn headings
Hi Clinton, On Feb 12, 2010, at 12:46, Mark Burton wrote: Is through route documented in the OSM Wiki? I was unable to find any information on this. Not yet, but it should be. I was rather hoping that some kind person would add a page to the Wiki describing it. So about adding this to the Wiki: is there any other information about the through_route relation type, except what has appeared in this mailing list? No, I discussed it with a few people on the OSM IRC channel but other than that, I believe our mailing list knows as much about it as anyone. Is the node with role junction now obsolete, or simply optional? The node is required but it doesn't have to have a role. The requirements are that the relation has two members that are ways that meet at the specified node. None of them need to have roles. It was originally suggested that the node had role junction but I don't see why that is required. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] motor_vehicle
Hi Marko, motor_vehicle is not understood by mkgmap Actually, why not? If my memory serves right, mkgmap understands motorcar and motorcycle (and maps them to the same access bit), but why not motor_vehicle? For example in my understanding, tractors are covered by motor_vehicle but not motorcar or motorcycle. The road sign for banning motor vehicles does ban tractors too. Well, no good reason, actually. It's just never been done. Consider it an omission. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v3] heed the through_route relation when adjusting turn headings
Hi Steve, Unless you know better, I'd say it was time or nearly time to merge that branch back to trunk. Agreed. The only slightly odd behaviour for me is at: http://www.openstreetmap.org/?mlat=51.612512mlon=-3.961642zoom=18layers=B000FTF ..where, if I approach on the southern stub from the traffic lights on Oystermouth Rd (A4067) I'd expect to be told turn right onto the oneway section of B4290. But I get no announcement. That northeasterly-bound section of B4290 isn't a single way because of bus-route issues, but I made a through_route relation to span across the junction just in case. It made no difference. But as a left turn isn't actually allowed there, perhaps the GPS doesn't bother to tell you to turn right as it knows you can't turn left? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Add way link to contains zero length arc output
Hi, Unless you have another patch that modifies the toOSMUR() function to print a /browse/way/* link in addition to the bbox link it currently prints that doesn't give me the info I need. The idea was to not have to copy/paste the ID that was printed into a manually constructed URL that I'd have to make. Hmm, bit confused now as the RoadDef toString() class does (should) include the browse blurb when processing OSM input. Are you using MP input? If so, you must call the showOSMBrowseURL() for the RoadDef. I didn't do that before because when using MP input, it's not obvious that the road id is an OSM when processing MP input. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Add way link to contains zero length arc output
Hello Ævar,
Please try this version, it should now print the browse URL whether the
road is from OSM input or MP input.
Mark
diff --git a/src/uk/me/parabola/imgfmt/app/net/RoadDef.java b/src/uk/me/parabola/imgfmt/app/net/RoadDef.java
index de87495..1dc1e8a 100644
--- a/src/uk/me/parabola/imgfmt/app/net/RoadDef.java
+++ b/src/uk/me/parabola/imgfmt/app/net/RoadDef.java
@@ -70,18 +70,10 @@ public class RoadDef implements Comparable {
this.name = name;
}
- public void showOSMBrowseURL() {
- showBrowseURL = true;
- }
-
// for diagnostic purposes
public String toString() {
- String browseURL;
- if(showBrowseURL)
- browseURL = http://www.openstreetmap.org/browse/way/; + id;
- else
- browseURL = + id;
-
+ // assumes id is an OSM id
+ String browseURL = http://www.openstreetmap.org/browse/way/; + id;
if(name != null)
return ( + name + , + browseURL + );
else
@@ -128,7 +120,6 @@ public class RoadDef implements Comparable {
private boolean synthesised;
private boolean flareCheck;
private boolean deadEndCheck;
- private boolean showBrowseURL;
private SetString messageIssued;
/**
diff --git a/src/uk/me/parabola/mkgmap/general/MapRoad.java b/src/uk/me/parabola/mkgmap/general/MapRoad.java
index 3703ad2..a955827 100644
--- a/src/uk/me/parabola/mkgmap/general/MapRoad.java
+++ b/src/uk/me/parabola/mkgmap/general/MapRoad.java
@@ -80,10 +80,6 @@ public class MapRoad extends MapLine {
this.roadDef.ferry(f);
}
- public void showOSMBrowseURL() {
- this.roadDef.showOSMBrowseURL();
- }
-
public void setSynthesised(boolean s) {
this.roadDef.setSynthesised(s);
}
diff --git a/src/uk/me/parabola/mkgmap/general/RoadNetwork.java b/src/uk/me/parabola/mkgmap/general/RoadNetwork.java
index 6be2d0c..e6bb4e4 100644
--- a/src/uk/me/parabola/mkgmap/general/RoadNetwork.java
+++ b/src/uk/me/parabola/mkgmap/general/RoadNetwork.java
@@ -133,14 +133,11 @@ public class RoadNetwork {
RouteNode node1 = getNode(lastId, lastCoord);
RouteNode node2 = getNode(id, co);
-if(node1 == node2) {
- log.error(Road + road.getRoadDef().getName() + (OSM id + road.getRoadDef().getId() + ) contains consecutive identical nodes - routing will be broken);
- log.error( + co.toOSMURL());
-}
-else if(arcLength == 0) {
- log.error(Road + road.getRoadDef().getName() + (OSM id + road.getRoadDef().getId() + ) contains zero length arc);
- log.error( + co.toOSMURL());
-}
+if(node1 == node2)
+ log.error(Road + road.getRoadDef() + contains consecutive identical nodes at + co.toOSMURL() + - routing will be broken);
+else if(arcLength == 0)
+ log.error(Road + road.getRoadDef() + contains zero length arc at + co.toOSMURL());
+
Coord bearingPoint = coordList.get(lastIndex + 1);
if(lastCoord.equals(bearingPoint)) {
diff --git a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
index 784f238..b39a7a6 100644
--- a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
+++ b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
@@ -1304,7 +1304,6 @@ public class StyledConverter implements OsmConverter {
line.setPoints(points);
MapRoad road = new MapRoad(way.getId(), line);
- road.showOSMBrowseURL();
boolean doFlareCheck = true;
if(roundabout.equals(way.getTag(junction))) {
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v3] heed the through_route relation when adjusting turn headings
Hi Steve,
If that comes up today, I can test it tonight. Thanks in advance.
A v4 patch was posted yesterday, here it is again.
Cheers,
Mark
diff --git a/src/uk/me/parabola/imgfmt/app/net/RoadDef.java b/src/uk/me/parabola/imgfmt/app/net/RoadDef.java
index de87495..e6a187e 100644
--- a/src/uk/me/parabola/imgfmt/app/net/RoadDef.java
+++ b/src/uk/me/parabola/imgfmt/app/net/RoadDef.java
@@ -555,6 +555,10 @@ public class RoadDef implements Comparable {
nod2Flags |= (speed 1);
}
+ public int getRoadSpeed() {
+ return tabAInfo 7;
+ }
+
public void setOneway() {
tabAInfo |= TABA_FLAG_ONEWAY;
netFlags |= NET_FLAG_ONEWAY;
diff --git a/src/uk/me/parabola/imgfmt/app/net/RouteNode.java b/src/uk/me/parabola/imgfmt/app/net/RouteNode.java
index 45d6010..c01f7a9 100644
--- a/src/uk/me/parabola/imgfmt/app/net/RouteNode.java
+++ b/src/uk/me/parabola/imgfmt/app/net/RouteNode.java
@@ -67,6 +67,7 @@ public class RouteNode implements ComparableRouteNode {
private final CoordNode coord;
private char latOff;
private char lonOff;
+ private ListRouteArc[] throughRoutes;
// this is for setting destination class on arcs
// we're taking the maximum of roads this node is
@@ -295,18 +296,8 @@ public class RouteNode implements ComparableRouteNode {
private static boolean possiblySameRoad(RouteArc raa, RouteArc rab) {
- if(raa == rab) {
- // the arcs are the same object
- return true;
- }
-
RoadDef rda = raa.getRoadDef();
RoadDef rdb = rab.getRoadDef();
- if(rda == rdb) {
- // the arcs share the same RoadDef
- return true;
- }
-
boolean bothArcsNamed = false;
for(Label laba : rda.getLabels()) {
if(laba != null laba.getOffset() != 0) {
@@ -395,17 +386,74 @@ public class RouteNode implements ComparableRouteNode {
// determine the outgoing arc that is likely to be the
// same road as the incoming arc
RouteArc outArc = null;
-for(RouteArc oa : arcs) {
- if(oa.getDest() != inArc.getSource()) {
- // this arc is not going to the same node as
- // inArc came from
- if((oa.isForward() || !oa.getRoadDef().isOneway())
- possiblySameRoad(inArc, oa)) {
- outArc = oa;
+
+if(throughRoutes != null) {
+ // through_route relations have the highest precedence
+ for(RouteArc[] pair : throughRoutes) {
+ if(pair[0] == inArc) {
+ outArc = pair[1];
+ log.info(Found through route from + inArc.getRoadDef() + to + outArc.getRoadDef());
break;
}
}
}
+
+if(outArc == null) {
+ // next, if oa has the same RoadDef as inArc, it's
+ // definitely the same road
+ for(RouteArc oa : arcs) {
+ if(oa.getDest() != inArc.getSource()) {
+ // this arc is not going to the same node as
+ // inArc came from
+ if(oa.getRoadDef() == inArc.getRoadDef()) {
+outArc = oa;
+break;
+ }
+ }
+ }
+}
+
+if(outArc == null) {
+ // next, although the RoadDefs don't match, use
+ // possiblySameRoad() to see if the road
+ // labels (names/refs) match
+ for(RouteArc oa : arcs) {
+ if(oa.getDest() != inArc.getSource()) {
+ // this arc is not going to the same node as
+ // inArc came from
+ if((oa.isForward() || !oa.getRoadDef().isOneway())
+ possiblySameRoad(inArc, oa)) {
+outArc = oa;
+break;
+ }
+ }
+ }
+}
+
+if(outArc == null) {
+ // last ditch attempt to find the outgoing arc -
+ // try and find a single arc that has the same
+ // road class and speed as the incoming arc
+ int inArcClass = inArc.getRoadDef().getRoadClass();
+ int inArcSpeed = inArc.getRoadDef().getRoadSpeed();
+ for(RouteArc oa : arcs) {
+ if(oa.getDest() != inArc.getSource()
+ oa.getRoadDef().getRoadClass() == inArcClass
+ oa.getRoadDef().getRoadSpeed() == inArcSpeed) {
+ if(outArc != null) {
+// multiple arcs have the same road
+// class as the incoming arc so don't
+// use any of them as the outgoing arc
+outArc = null;
+break;
+ }
+ outArc = oa;
+ }
+ }
+ if(outArc != null)
+ log.info(Matched outgoing arc + outArc.getRoadDef() + to + inArc.getRoadDef() + using road class ( + inArcClass + ) and speed ( + inArcSpeed + ));
+}
+
// if we did not find the outgoing arc, give up with
// this incoming arc
if(outArc == null) {
@@ -449,12 +497,6 @@ public class RouteNode implements ComparableRouteNode {
continue;
}
- if(possiblySameRoad(inArc, otherArc) ||
- possiblySameRoad(outArc, otherArc)) {
- // not obviously a different road so give up
- continue;
- }
-
if(inArc.getRoadDef().isLinkRoad()
otherArc.getRoadDef().isLinkRoad()) {
// it's a link road leaving a link road so
@@ -483,9 +525,12 @@ public class RouteNode implements ComparableRouteNode {
if((mask ATH_OUTGOING) != 0
