Re: [mkgmap-dev] Commit: r1120: adds some options to the help file
+--enable-assertions + Turn on assertions in the code. This will make the program + more likely to abort and less likely to do the wrong thing. + Use of this option is recommended. + Surely this is either -ea or -enableassertions and the option goes to the java runtime and not to mkgmap? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v1] - styling for the power user
Are you a heavy duty styler? If so, read on:
I notice that quite a lot of postings on the list are from people who
are having problems with complex style files. This little patch won't
(directly) solve those problems but it does provide a useful capability
that could be part of a solution for those people who have complex
styling requirements and are willing to do some coding.
What the patch does is allow elements (nodes, ways) to specify their
garmin type (and a few other things) explicitly using these tags:
mkgmap:gtype the element's type (integer constant)
mkgmap:kind one of "node", "polyline", "polygon" (only polygon is used
at this time to differentiate polygons from lines).
mkgmap:minres the element's minimum resolution (needed to make element
visible)
mkgmap:maxres the element's maximum resolution (not required)
mkgmap:roadclass the element's road class (needed for roads)
mkgmap:roadspeed the element's road speed (needed for roads)
If the mkgmap:gtype tag is present, the element will not be passed
through the normal style file process at all.
So how do these tags get added to the OSM data? Well, you could just
add them with an editor but that would get boring pretty quickly so
what I would expect to see is some kind of external filter program that
reads the OSM file and outputs a new OSM file with the appropriate tags
added.
That filter program could be written in any language that has some XML
processing support.
Current issues to be sorted out are handling of the highway shields
(not currently implemented) and also this feature is not compatible with
the cycleway faking code.
All feedback welcome.
Cheers,
Mark
diff --git a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
index 2a549f8..03fdbda 100644
--- a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
+++ b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
@@ -144,6 +144,50 @@ public class StyledConverter implements OsmConverter {
lineAdder = overlayAdder;
}
+ public GType makeGTypeFromTags(Element element, int kind) {
+ String s = element.getTag("mkgmap:gtype");
+ GType gt = new GType(kind, s);
+ element.setName(element.getTag("name"));
+ s = element.getTag("mkgmap:minres");
+ if(s != null) {
+ try {
+gt.setMinResolution(Integer.decode(s));
+ }
+ catch (NumberFormatException nfe) {
+log.error("Bad value for mkgmap:minres tag: " + s);
+ }
+ }
+ s = element.getTag("mkgmap:maxres");
+ if(s != null) {
+ try {
+gt.setMaxResolution(Integer.decode(s));
+ }
+ catch (NumberFormatException nfe) {
+log.error("Bad value for mkgmap:maxres tag: " + s);
+ }
+ }
+ s = element.getTag("mkgmap:roadclass");
+ if(s != null) {
+ try {
+gt.setRoadClass(Integer.decode(s));
+ }
+ catch (NumberFormatException nfe) {
+log.error("Bad value for mkgmap:roadclass tag: " + s);
+ }
+ }
+ s = element.getTag("mkgmap:roadspeed");
+ if(s != null) {
+ try {
+gt.setRoadClass(Integer.decode(s));
+ }
+ catch (NumberFormatException nfe) {
+log.error("Bad value for mkgmap:roadspeed tag: " + s);
+ }
+ }
+
+ return gt;
+ }
+
/**
* This takes the way and works out what kind of map feature it is and makes
* the relevant call to the mapper callback.
@@ -157,13 +201,22 @@ public class StyledConverter implements OsmConverter {
if (way.getPoints().size() < 2)
return;
- preConvertRules(way);
+ GType foundType = null;
+ if(way.getTag("mkgmap:gtype") != null) {
+ if("polygon".equals(way.getTag("mkgmap:kind")))
+foundType = makeGTypeFromTags(way, GType.POLYGON);
+ else
+foundType = makeGTypeFromTags(way, GType.POLYLINE);
+ }
+ else {
+ preConvertRules(way);
- GType foundType = wayRules.resolveType(way);
- if (foundType == null)
- return;
+ foundType = wayRules.resolveType(way);
+ if (foundType == null)
+return;
- postConvertRules(way, foundType);
+ postConvertRules(way, foundType);
+ }
if (foundType.getFeatureKind() == GType.POLYLINE) {
if(foundType.isRoad())
@@ -182,13 +235,20 @@ public class StyledConverter implements OsmConverter {
* @param node The node to convert.
*/
public void convertNode(Node node) {
- preConvertRules(node);
- GType foundType = nodeRules.resolveType(node);
- if (foundType == null)
- return;
+ GType foundType = null;
+ if(node.getTag("mkgmap:gtype") != null) {
+ foundType = makeGTypeFromTags(node, GType.POINT);
+ }
+ else {
+ preConvertRules(node);
+
+ foundType = nodeRules.resolveType(node);
+ if (foundType == null)
+return;
- postConvertRules(node, foundType);
+ postConvertRules(node, foundType);
+ }
addPoint(node, foundType);
}
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v2] - styling for the power user
v2
now supports ~[0x??] syntax within name to specify highway shields
to reduce the number of tags required, you can now specify all the
values in the mkgmap:gtype tag like this example:
mkgmap:gtype="0x20,19,,1,2"
type = 0x20
minres = 19
maxres not specified
roadclass = 1
roadspeed = 2
The one tag per value scheme is still supported (for the moment at
least)
--
Are you a heavy duty styler? If so, read on:
I notice that quite a lot of postings on the list are from people who
are having problems with complex style files. This little patch won't
(directly) solve those problems but it does provide a useful capability
that could be part of a solution for those people who have complex
styling requirements and are willing to do some coding.
What the patch does is allow elements (nodes, ways) to specify their
garmin type (and a few other things) explicitly using these tags:
mkgmap:gtype the element's type (integer constant)
mkgmap:kind one of "node", "polyline", "polygon" (only polygon is used
at this time to differentiate polygons from lines).
mkgmap:minres the element's minimum resolution (needed to make element
visible)
mkgmap:maxres the element's maximum resolution (not required)
mkgmap:roadclass the element's road class (needed for roads)
mkgmap:roadspeed the element's road speed (needed for roads)
If the mkgmap:gtype tag is present, the element will not be passed
through the normal style file process at all.
So how do these tags get added to the OSM data? Well, you could just
add them with an editor but that would get boring pretty quickly so
what I would expect to see is some kind of external filter program that
reads the OSM file and outputs a new OSM file with the appropriate tags
added.
That filter program could be written in any language that has some XML
processing support.
Current issues to be sorted out are handling of the highway shields
(not currently implemented) and also this feature is not compatible with
the cycleway faking code.
All feedback welcome.
Cheers,
Mark
diff --git a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
index 2a549f8..eeab3fc 100644
--- a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
+++ b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
@@ -25,6 +25,8 @@ import java.util.Map;
import java.util.Properties;
import java.util.Set;
+import java.util.regex.Pattern;
+
import uk.me.parabola.imgfmt.app.Area;
import uk.me.parabola.imgfmt.app.Coord;
import uk.me.parabola.imgfmt.app.CoordNode;
@@ -53,6 +55,8 @@ import uk.me.parabola.mkgmap.reader.osm.Rule;
import uk.me.parabola.mkgmap.reader.osm.Style;
import uk.me.parabola.mkgmap.reader.osm.Way;
+import uk.me.parabola.mkgmap.reader.polish.PolishMapDataSource;
+
/**
* Convert from OSM to the mkgmap intermediate format using a style.
* A style is a collection of files that describe the mappings to be used
@@ -144,6 +148,86 @@ public class StyledConverter implements OsmConverter {
lineAdder = overlayAdder;
}
+ private static Pattern commaPattern = Pattern.compile(",");
+
+ public GType makeGTypeFromTags(Element element, int kind) {
+ String[] vals = commaPattern.split(element.getTag("mkgmap:gtype"));
+ String s;
+
+ element.setName(PolishMapDataSource.unescape(element.getTag("name")));
+
+ for(int i = 0; i < vals.length; ++i)
+ vals[i] = vals[i].trim();
+
+ GType gt = new GType(kind, vals[0]);
+
+ if(vals.length >= 2 && vals[1].length() > 0)
+ s = vals[1];
+ else {
+ s = element.getTag("mkgmap:minres");
+ if(s != null)
+s = s.trim();
+ }
+ if(s != null) {
+ try {
+gt.setMinResolution(Integer.decode(s));
+ }
+ catch (NumberFormatException nfe) {
+log.error("Bad value for minres: " + s);
+ }
+ }
+
+ if(vals.length >= 3 && vals[2].length() > 0)
+ s = vals[2];
+ else {
+ s = element.getTag("mkgmap:maxres");
+ if(s != null)
+s = s.trim();
+ }
+ if(s != null) {
+ try {
+gt.setMaxResolution(Integer.decode(s));
+ }
+ catch (NumberFormatException nfe) {
+log.error("Bad value for maxres tag: " + s);
+ }
+ }
+
+ if(vals.length >= 4 && vals[3].length() > 0)
+ s = vals[3];
+ else {
+ s = element.getTag("mkgmap:roadclass");
+ if(s != null)
+s = s.trim();
+ }
+ if(s != null) {
+ try {
+gt.setRoadClass(Integer.decode(s));
+ }
+ catch (NumberFormatException nfe) {
+log.error("Bad value for roadclass: " + s);
+ }
+ }
+
+ if(vals.length >= 5 && vals[4].length() > 0)
+ s = vals[4];
+ else {
+ s = element.getTag("mkgmap:roadspeed");
+ if(s != null)
+s = s.trim();
+ }
+ if(s != null) {
+ try {
+gt.setRoadClass(Integer.decode(s));
+ }
+ catch (NumberFormatException nfe) {
+log.error("Bad value for roadspeed: " + s);
+ }
+ }
+
+ return gt;
+ }
+
/**
* This takes the way and works out what kind of map feature it is and makes
* the relevant call to the mapper callback.
@@ -157,13
Re: [mkgmap-dev] [PATCH v2] - styling for the power user
Hi Felix, > Hi Mark, I still don't really understand the advantage. What it does is give you the possibility of doing all of the style processing outside of mkgmap. If mkgmap's styling support is sufficient for your needs, use that. If not, you can style your data before it gets processed by mkgmap using some other application. I don't have complex styling needs and can achieve what I want using the mkgmap style files so I am not in a great rush to write a styling application but it could easily be done. > 1. maxres, can we really specify this, I was not aware that this is > possible. I don't know if you can specify it in the style syntax but it's in the underlying code. > 2. So the only advantage is that it is shorter to tpye and that > preprocessing becomes possible? It just seemed excessive to have separate tags for each of the values when they could just be specified using a single tag. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Styling for the power user
Hi David, > The new features you added for styling is a great step for my map. The > last step is how to filter each contour line which height finishes by > 25 or 75 (I don't know how to do it with style rules). These contours > are only used for low level of details. At higher LOD, contours with a > step of 10m are displayed (to build such a layer I need cgpsmapper). Glad it's going to be useful for you. As it's a new idea and hasn't been used yet, please don't hesitate to suggest any improvements/fixes. > Thank you for your work, You're welcome. 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] - styling for the power user
Hi Torsten, > > What it does is give you the possibility of doing all of the style > > processing outside of mkgmap. If mkgmap's styling support is > > sufficient for your needs, use that. If not, you can style your data > > before it gets processed by mkgmap using some other application. > > Also with normal mkgmap you can doo preprocessing of the osm data. But > most people seem to try getting most out of the styles without an extra > processing step. Yes, that's right and from the emails we see on the list, perhaps people are now trying to do stuff that wasn't really imagined when the mkgmap style engine was designed and are, therefore, running into issues. > Right now, I don't really see, how your approach makes things easier. > Can you provide an example, how the map generation would look like with > your patch? The way I see it is: 1 - the mkgmap style engine is good for moderately complex styling. 2 - for more demanding styling, either the mkgmap style engine has to be fixed/enhanced to support whatever new demands people want to make on it, or ... 3 - we can provide some simple hooks whereby you can do the styling with some 3rd-party application (not mkgmap) as a pre-processing step. To be honest, I am surprised that people haven't taken to pre-processing the map data already. So the sequence of steps to make the map could be: 1 - split big map into tiles 2 - pre-process tiles to add style info 3 - generate .img files using mkgmap The pre-processing could be done by a dedicated program (java/c/perl/python/...) or by some form of transformation process (xslt?) or even simple text substitution (awk?) I'm not saying this is trivial to implement but if you really want to do some funky styling then it may be easier to create an external pre-processor than trying to express your requirements using the mkgmap style language. 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] - styling for the power user
Hi Thilo, > thank you for your effort, but I would go with the "the mkgmap style > engine has to be fixed/enhanced" approach. Of course you could add > preprocessing, but that is already possible now (think mp-files). By > proposing preprocessing you just divert "programming power" away from > mkgmap - everybody starts his own preprocessor instead of improving > mkgmap. This will make "decent mapmaking" for starters even more > complicated as it is now. I disagree. The patch simply provides a means for those people who have complex styling requirements to "roll their own" styling engine so they are not obliged to use whatever is built into mkgmap. The presence of the patch will not affect the development of the mkgmap styling system but by providing people with an alternative mechanism, it will encourage innovation and new thinking. One could argue that mkgmap would be better off having no styling function at all and it should focus on the core task of converting an input dataset (styled OSM) into map files (.img, etc.) > Some thoughts about styling: > What we see right now is the move from a "conversion table" to a > "macro/programming language". As you say, the style files were never > intended to be able to do the things we want them to do now. So what > can we do about that? > > We could "improve" them until they are Touring complete. But I don't > think we should. Because then we would only create another programming > language with another syntax and all the problems that arise from > that. What I propose is to keep the style files, perhaps even > *stripping* features from them (action rules, default_name). To > implement all those nifty new tricks I'd like to have a plug-in > interface in mkgmap to add my own Java routines. That could be plug-in > at compile time, no need to make it too complicated. It would be a > start to sort through all the classes and provide some documented > hooks to plug-in your own routines. Then in the style files one could > "invoke" the plug-ins that one would like to use. > > An excerpt of the lines style file might look like this: > > highway=secondary [0x04 namefinder=default_highway > filter=DouglasPeucker(keep_junctions_fixed=true) > routebuilder=default_routable(road_class=2, road_speed=3) resolution 20] > natural=coastline [0x15 namefinder=fixed(name='coastline') > filter=DouglasPeucker resolution 12] > > By selecting the namefinder, the filter, the routebuilder etc. one has > complete control about how the data is processed. The routines could > accept parameters in parantheses behind their name for added > flexibility. Some (standard) routines are supplied, but it should be > easy to add your own. By having a defined interface it gets easier to > interchange improvements - currently the patches need often quite some > work to get them to compile all together. > > By partitioning the work between routines each one can be relatively > simple. So for example one namefinder routine could just be > responsible to find a name for a highway. Another one could be > responsible to generate a name for a POI for a building that has > address information. > > This will also mostly eliminate the need for action rules. As I think > the action rules code is - say - quite complex, this might remove one > area of "oddities". > > By keeping the style files and out-sourcing the complex programming > into Java plug-in-routines the style programming stays simple for the > users that only change the style files themselves, but power-users can > still program everything they like in plain Java. As the plug-in > routines can be selected from the style files, the regular-users can > also benefit from the work of the power-users, even if they can't > program in Java themselves. > > Any thoughts about that? Well it's not what I would do. 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] - styling for the power user
Hi Marko, > Hi Mark, Thilo, list, > > > The problem here is that in the end you cannot separate the styling > > from the map conversion process. When I started using mkgmap I also > > used preprocessing. But then I found that my preprocessor had to > > duplicate a lot of the functionality of mkgmap to "do it right". For > > example finding all the ways that belong to a relation. It was much > > easier to patch mkgmap to get the same results, because all that > > information is already accessible there. But of course one could argue > > if this "convenience" is a reason in itself not to separate styling > > and map conversion. > > For what it is worth, I agree with Thilo here. The Unix philosophy of > combining simple tools is preferrable when it works, but OSM is huge, and > all of the graph has to be kept in memory during the processing. Command > pipelines and scripts work nicely when working with simple text files, when > linear access to the data is enough. But I wouldn't want to load and dump > large volumes of data even more times than currently (bzip2 decompression, > splitter, mkgmap). I agree, performance could be an issue although not a show-stopper due to the cheapness of multi-core CPUs and RAM. > The mkgmap:* would be great for quick prototyping or for those who prefer > preprocessing or prefer to work with their favourite scripting language > instead of Java. This brings about a question of dependences and > coordination. > If people start writing preprocessor scripts in their favourite languages, > suddenly you might need a host of runtime environments (Perl, Python, Ruby, > ...) with all sorts of libraries, in addition to the current Java dependences. Exactly, give people a choice. As to the runtime requirements, what is required to be installed depends on whatever technology is used to implement the styling filter but unless it's seriously esoteric, you wouldn't expect it to be a problem. These days, most of the common languages are available for all of the major platforms at the click of a button. > Can we have the best of both worlds? The best preprocessing transformations > would eventually be ported to mkgmap plugins that would be linked to mkgmap > style rules. Examples of such plugins include plugins for naming objects > and for filtering or duplicating objects (lines or points, e.g., refactoring > the current code of duplicating cycleways or transforming areas into POIs). > We can start small; I'd be happy with the naming plugin framework for now. Of course. I am not for one moment suggesting that development of the mkgmap styling engine (MSE) should be limited. As you suggest, (with the patch) it would be possible to prototype and develop styling schemes outside of mkgmap. If successful, those schemes could then be incorporated into the MSE. Remember, the zero-style patch only disables the MSE for elements that have a mkgmap:gtype tag, so all other elements that don't have that tag will still be styled by the MSE. This allows "selective styling" by an external program that could be useful for testing styling regimes without having to implement them in a prototype form within mkgmap. So, unless there are compelling reasons not to incorporate the patch, I will commit it before too long as I believe in the long-run it will prove to be useful. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v3] - styling for the power user
v3
Now only has 1 tag (mkgmap:gtype) to specify everything.
tag has the format 'kind,code,minres,maxres,roadclass,roadspeed'
Where kind is 1 for node, 2 for polyline and 3 for polygon.
kind, code and minres are all required to be present, the other values
can be ommitted.
Note, this format has changed since v2.
v2
now supports ~[0x??] syntax within name to specify highway shields
to reduce the number of tags required, you can now specify all the
values in the mkgmap:gtype tag like this example:
mkgmap:gtype="0x20,19,,1,2"
type = 0x20
minres = 19
maxres not specified
roadclass = 1
roadspeed = 2
The one tag per value scheme is still supported (for the moment at
least)
--
Are you a heavy duty styler? If so, read on:
I notice that quite a lot of postings on the list are from people who
are having problems with complex style files. This little patch won't
(directly) solve those problems but it does provide a useful capability
that could be part of a solution for those people who have complex
styling requirements and are willing to do some coding.
What the patch does is allow elements (nodes, ways) to specify their
garmin type (and a few other things) explicitly using these tags:
mkgmap:gtype the element's type (integer constant)
mkgmap:kind one of "node", "polyline", "polygon" (only polygon is used
at this time to differentiate polygons from lines).
mkgmap:minres the element's minimum resolution (needed to make element
visible)
mkgmap:maxres the element's maximum resolution (not required)
mkgmap:roadclass the element's road class (needed for roads)
mkgmap:roadspeed the element's road speed (needed for roads)
If the mkgmap:gtype tag is present, the element will not be passed
through the normal style file process at all.
So how do these tags get added to the OSM data? Well, you could just
add them with an editor but that would get boring pretty quickly so
what I would expect to see is some kind of external filter program that
reads the OSM file and outputs a new OSM file with the appropriate tags
added.
That filter program could be written in any language that has some XML
processing support.
Current issues to be sorted out are handling of the highway shields
(not currently implemented) and also this feature is not compatible with
the cycleway faking code.
All feedback welcome.
Cheers,
Mark
diff --git a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
index 2a549f8..87d 100644
--- a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
+++ b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
@@ -25,6 +25,8 @@ import java.util.Map;
import java.util.Properties;
import java.util.Set;
+import java.util.regex.Pattern;
+
import uk.me.parabola.imgfmt.app.Area;
import uk.me.parabola.imgfmt.app.Coord;
import uk.me.parabola.imgfmt.app.CoordNode;
@@ -53,6 +55,8 @@ import uk.me.parabola.mkgmap.reader.osm.Rule;
import uk.me.parabola.mkgmap.reader.osm.Style;
import uk.me.parabola.mkgmap.reader.osm.Way;
+import uk.me.parabola.mkgmap.reader.polish.PolishMapDataSource;
+
/**
* Convert from OSM to the mkgmap intermediate format using a style.
* A style is a collection of files that describe the mappings to be used
@@ -144,6 +148,85 @@ public class StyledConverter implements OsmConverter {
lineAdder = overlayAdder;
}
+ private static Pattern commaPattern = Pattern.compile(",");
+
+ public GType makeGTypeFromTags(Element element) {
+ String[] vals = commaPattern.split(element.getTag("mkgmap:gtype"));
+
+ if(vals.length < 3) {
+ log.error("OSM element " + element.getId() + " has bad mkgmap:gtype value (should be 'kind,code,minres,[maxres],[roadclass],[roadspeed])");
+ log.error(" where kind is " + GType.POINT + "=point, " + GType.POLYLINE + "=polyline, " + GType.POLYGON + "=polygon");
+ return null;
+ }
+
+ element.setName(PolishMapDataSource.unescape(element.getTag("name")));
+
+ for(int i = 0; i < vals.length; ++i)
+ vals[i] = vals[i].trim();
+
+ int kind = 0;
+ try {
+ kind = Integer.decode(vals[0]);
+ }
+ catch (NumberFormatException nfe) {
+ log.error("OSM element " + element.getId() + " has bad value for kind: " + vals[0]);
+ return null;
+ }
+
+ if(kind != GType.POINT &&
+ kind != GType.POLYLINE &&
+ kind != GType.POLYGON) {
+ log.error("OSM element " + element.getId() + " has bad value for kind, is " + kind + " but should be " + GType.POINT + ", " + GType.POLYLINE + " or " + GType.POLYGON);
+ return null;
+ }
+
+ try {
+ Integer.decode(vals[1]);
+ }
+ catch (NumberFormatException nfe) {
+ log.error("OSM element " + element.getId() + " has bad value for type: " + vals[1]);
+ return null;
+ }
+
+ GType gt = new GType(kind, vals[1]);
+
+ try {
+ gt.setMinResolution(Integer.decode(vals[2]));
+ }
+ catch (NumberFormatException nfe) {
+ log.error("OSM element " + element.getId() + " has bad value for minres:
Re: [mkgmap-dev] [PATCH v2] - styling for the power user
Hi Garvan, Thanks for the feedback. > I tested this patch today, and it worked as advertised. Thanks for your > work. Good. > I have a suggestion. > > Would it be better to use > > instead of > > > I know nothing about osm format, other that what I observed, but the > latter syntax looks the more obvious to me. If you try this (as I did > until in my first try), you will get a NullPointerException. Yes, the first syntax is correct, my blurb used the wrong syntax. > I think the long format , with seperate tags, is redundant. It's most > likely that people using this syntax will be using a preprocessor of > some kind, and I doubt if many preprocessors were written between > version 1 and version 2 of your patch. I agree, I have now issued v3 which now only has the one tag 'mkgmap:gtype'. The kind (node, line, area) is now specified as the first value in the list. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v2] - Add support for marine (aka extended) types
v2
Space optimisation - no longer outputs per-subdivision 13-byte record if
the map contains no elements that have an extended type.
---
Ahoy there shipmates,
This patch is a first stab at providing support for the 3-byte extended
types that are used on marine maps.
Extended types are specified as a 6 digit hex number. The first two
digits are always 01. An example type is 0x010200 (point type Buoy).
Points, lines and polygons can all be given extended types.
The cGPSMapper user manual lists all of the types.
Note that routable ways cannot have an extended type. If you try to
give a road an extended type, it will converted into a line.
At this time, the various extra attributes that can be assigned to the
marine entities (depth, colour, light colour/flash, etc.) are not
handled but I have made some progress in understanding their encoding
so at least some of these could be supported in the future. Obviously,
the OSM data would need to be enriched to specify the required
attributes.
It now works well enough to warrant testing on more map data but I
am expecting that there will be problems given the extent of the patch
and the nature of what it's doing.
Please test if you can and report success/failure/etc.
Cheers,
Mark
diff --git a/src/uk/me/parabola/imgfmt/app/trergn/LinePreparer.java b/src/uk/me/parabola/imgfmt/app/trergn/LinePreparer.java
index c99e807..eb5d520 100644
--- a/src/uk/me/parabola/imgfmt/app/trergn/LinePreparer.java
+++ b/src/uk/me/parabola/imgfmt/app/trergn/LinePreparer.java
@@ -32,6 +32,7 @@ class LinePreparer {
private final Polyline polyline;
private boolean extraBit;
+ private boolean extTypeLine;
private boolean xSameSign;
private boolean xSignNegative; // Set if all negative
@@ -55,6 +56,8 @@ class LinePreparer {
extraBit = true;
}
+ extTypeLine = line.hasExtendedType();
+
polyline = line;
calcLatLong();
calcDeltas();
@@ -105,6 +108,10 @@ class LinePreparer {
log.debug("y same is", ySameSign, "sign is", ySignNegative);
}
+ if(extTypeLine) {
+ bw.put1(false); // no extra bits required
+ }
+
// first extra bit always appears to be false
// refers to the start point?
if (extraBit)
diff --git a/src/uk/me/parabola/imgfmt/app/trergn/MapObject.java b/src/uk/me/parabola/imgfmt/app/trergn/MapObject.java
index 9a3c017..07933cd 100644
--- a/src/uk/me/parabola/imgfmt/app/trergn/MapObject.java
+++ b/src/uk/me/parabola/imgfmt/app/trergn/MapObject.java
@@ -19,9 +19,14 @@ package uk.me.parabola.imgfmt.app.trergn;
import uk.me.parabola.imgfmt.app.Label;
import uk.me.parabola.imgfmt.app.ImgFileWriter;
+import uk.me.parabola.mkgmap.general.MapElement;
+
import java.util.ArrayList;
import java.util.List;
+import java.io.OutputStream;
+import java.io.IOException;
+
/**
* An object that appears in a map. One of point, polyline, polygon or indexed
* point.
@@ -57,6 +62,8 @@ public abstract class MapObject {
*/
public abstract void write(ImgFileWriter file);
+ public abstract void write(OutputStream stream) throws IOException;
+
int getDeltaLat() {
return deltaLat;
}
@@ -83,6 +90,10 @@ public abstract class MapObject {
this.type = type;
}
+ public boolean hasExtendedType() {
+ return MapElement.hasExtendedType(type);
+ }
+
/**
* Set an ordinary unshifted latitude. It will be calculated
* relative to the subdivision.
diff --git a/src/uk/me/parabola/imgfmt/app/trergn/Overview.java b/src/uk/me/parabola/imgfmt/app/trergn/Overview.java
index 2f164b5..29f949d 100644
--- a/src/uk/me/parabola/imgfmt/app/trergn/Overview.java
+++ b/src/uk/me/parabola/imgfmt/app/trergn/Overview.java
@@ -33,6 +33,7 @@ public abstract class Overview implements Comparable {
public static final int SHAPE_KIND = 3;
private final int kind; // The kind of overview; point, line etc.
+ private final char extType;
private final char type;
private final char subType;
private final int minResolution;
@@ -43,6 +44,7 @@ public abstract class Overview implements Comparable {
protected Overview(int kind, int fullType, int minres) {
this.kind = kind;
+ this.extType = (char)((fullType >> 16) & 0xff);
this.type = (char) (fullType >> 8 & 0xff);
this.subType = (char) (fullType & 0xff);
this.minResolution = minres;
@@ -54,10 +56,18 @@ public abstract class Overview implements Comparable {
}
public void write(ImgFileWriter file) {
- file.put((byte) (type & 0xff));
- file.put((byte) maxLevel);
- if (size > 2)
- file.put((byte) (subType & 0xff));
+ if(extType != 0) {
+ file.put((byte)type);
+ file.put((byte)maxLevel);
+ file.put((byte)subType);
+ file.put((byte)0);
+ }
+ else {
+ file.put((byte) (type & 0xff));
+ file.put((byte) maxLevel);
+ if (size > 2)
+file.put((byte) (subType & 0xff));
+ }
}
/**
@@ -83,7 +93,10 @@ public abstract class Overview implements Comparable {
return false;
Overview ov = (Overview) obj;
- return ov.kind == kind && ov.typ
Re: [mkgmap-dev] Routing with the default style
Hello Nop, > I am just having my first look at creating a routable map. It appears > that the default style completely disregards the access tags access=no, > vehicle=no, motorvehicle=no and motorcar=no. Naturally I'd like to > exclude these from routing, but there seem to be no rules evaluating > them in the default style. Is this really the case or are those tags > somehow hardcoded in mkgmap? The tags "vehicle" and "motorvehicle" are not recognised so you will need to add style rules to convert them to one of the access tags that are recognised which are: access (applies to everything) bicycle foot hgv motorcar motorcycle (same as motorcar) psv taxi emergency delivery goods (same as delivery) Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option --remove-short-arcs
Hi Steve, > Is there any problem with this option, such that you might not want > to use it? I am not aware of any problem. > As I understand it, if you do not give it then routing will not work, > as we know (or believe) that all routing arcs have to be more than 5.4m. I believe that the mimimum distance will depend on lat/lon because the real constraint is that the source and target nodes must not have the same coordinates (resolution being 360 deg / 2^24) > If that is so, then we should just set the required behaviour whenever > the route option is given. Why don't we do that but still provide an option to turn off the short arc removal (which should never need to be used but may be useful when tracking down problems). > I realize that there might be other approaches, eg we could stretch arcs > instead of removing them, but if removing them is our current best > approach, lets make it the default. It seems to be working well enough at the moment. Shall I change the code to remove the --remove-short-arcs option and, instead, enable that function if --route is specified and (the new) --keep-short-arcs option is not specified? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option --remove-short-arcs
Hi Felix, > Mark Burton wrote: > > Hi Steve, > > > > > >> Is there any problem with this option, such that you might not want > >> to use it? > >> > > > > I am not aware of any problem. > > > > > >> As I understand it, if you do not give it then routing will not work, > >> as we know (or believe) that all routing arcs have to be more than 5.4m. > >> > > > > I believe that the mimimum distance will depend on lat/lon because the > > real constraint is that the source and target nodes must not have the > > same coordinates (resolution being 360 deg / 2^24) > > > > > >> If that is so, then we should just set the required behaviour whenever > >> the route option is given. > >> > > > > Why don't we do that but still provide an option to turn off the > > short arc removal (which should never need to be used but may be useful > > when tracking down problems). > > > > > >> I realize that there might be other approaches, eg we could stretch arcs > >> instead of removing them, but if removing them is our current best > >> approach, lets make it the default. > >> > > > > It seems to be working well enough at the moment. > > > > Shall I change the code to remove the --remove-short-arcs option and, > > instead, enable that function if --route is specified and > > (the new) --keep-short-arcs option is not specified? > > > > Cheers, > > > > Mark > > > Yes, but we should be clear about the distance needed. I used =3 because > without specifying it, I had some route calculation working, that > without specifying did not work. If there is really 5.4m then the > default should go for 5.4 -- or just leave the option as it is right now > but use it by default except if say --remove-short-arcs=no is given... Ahh, I forgot about that aspect. At this time, if you don't specify a length with the --remove-short-arcs option, it only removes zero-length arcs. I think that is the most sensible behaviour because we know that zero-length arcs are bad for routing. The fact that some maps require a minimum arc length to be specified should be investigated some more to see what the issue is. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option --remove-short-arcs
Hi Felix, > Until we have those patches, I am a bit sceptical about dropping the > support to specify the arc length. I am not suggesting that we drop the ability to specify the min arc length but I do think it's reasonable for it to default to zero rather than some length like 3 or 5 (at least until we really understand what's going on). I propose: If --route is specified but --remove-short-arcs is not, we enable the short arc removal for zero length arcs. If --remove-short-arcs=num is specified then we remove arcs <= num. If --remove-short-arcs=no is specified, we don't do any short arc removal even if --route is specified. How's that sound? 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 v1] - Add support for marine (aka extended) types
Hi Clinton, > On Tue, Aug 4, 2009 at 10:40 PM, Mark Burton wrote: > > > > Ahoy there shipmates, > > > > This patch is a first stab at providing support for the 3-byte extended > > types that are used on marine maps. > > I tested this, and found that it works fine, both on my eTrex and in > Roadtrip for Mac OS X. Excellent. > FYI, I did not have to switch to marine mode or anything else to get > the symbols to display. (Although some of the symbols didn't look > that nice, but I assume they're there for utility and not aesthetics.) > So far, I have just tried this with a few types: a lateral buoy symbol > and a pier line type. On my eTrex, you can choose between various marine icon sets (Garmin, NOAA, International) and there is also an option to have "marine colors". > It would probably be nice to get this committed, so more people can > experiment with the additional possibilities this can offer. As it's fairly unlikely to break maps that don't use any extended types it's probably safe to commit. > > At this time, the various extra attributes that can be assigned to the > > marine entities (depth, colour, light colour/flash, etc.) are not > > handled but I have made some progress in understanding their encoding > > so at least some of these could be supported in the future. Obviously, > > the OSM data would need to be enriched to specify the required > > attributes. > > There appears to be significant progress in adding this type of data > to OSM. Since the proposed tags attempt to conform to international > standards, it should be fairly easy to match these to Garmin types: > > http://wiki.openstreetmap.org/wiki/Proposed_features/marine-tagging The author of the OpenSeaMap effort says that there are now two proposed schemes for tagging marine entities. As far as mkgmap is concerned it doesn't really make much difference what the tags are but it would be nice if there was just one tag set to transform rather than 2. However, I do intend to continue work on this soon. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option --remove-short-arcs
Hi Greg, > That sounds fine, but I don't see why --remove-short-arcs should not be > the default even when routing is not enabled. I can see the point that > it is not strictly needed, but aren't repeated points in a way > non-sensical anyway? I prefer not to mess with the map data unless absolutely necessary or explicitly called for by the user. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option --remove-short-arcs
Hi Steve, > On 12/08/09 11:23, Mark Burton wrote: > > I believe that the mimimum distance will depend on lat/lon because the > > real constraint is that the source and target nodes must not have the > > same coordinates (resolution being 360 deg / 2^24) > > Are you sure that is the real constraint? Nope. > The 5.4m value is widely known and used by everyone else in > the Garmin map making communities, so it sees unwise to ignore > it. > > So OK, we do not know where this number comes from. The best > speculation was from Alex who notes that it is close (within 10%) > of the minimum length that can be encoded into RouteArc.lenth > Since the conversion factor from meters/feet is empirically > determined, it could be incorrect by a few percent anyway. Well, I don't mind. Would you like the default min arc length be 5.4m rather than 0? Easily done. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option --remove-short-arcs
It could be like this: --remove-short-arcs (a) --remove-short-arcs=MinLength (b) --remove-short-arcs=no(c) If routing is enabled, arcs shorter than 5.4m will be removed to avoid routing problems. This behaviour can be modified with this option. It has three variants: (a) turn on short arc removal even if routing is not enabled. (b) explicitly specify the minimum arc length (no 'm' suffix). (c) completely disable short arc removal. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option --remove-short-arcs [PATCH v1]
What we want is that the result of RouteArc.convertMeters() is
not less than 1. So with the values it has at the moment that requires
a min arc length of 4.878 metres. If we set the default to 5m, we
should be chuckling.
It could look like the attached patch.
diff --git a/resources/help/en/options b/resources/help/en/options
index 9bbfad7..ceb1921 100644
--- a/resources/help/en/options
+++ b/resources/help/en/options
@@ -182,11 +182,15 @@ Miscellaneous options:
in which they appear in the OSM input. Without this option,
the order in which the elements are processed is not defined.
---remove-short-arcs[=MinLength]
- Merge nodes to remove short arcs that can cause routing
- problems. If MinLength is specified (in metres), arcs shorter
- than that length will be removed. If a length is not
- specified, only zero-length arcs will be removed.
+--remove-short-arcs (a)
+--remove-short-arcs=MinLength (b)
+--remove-short-arcs=no(c)
+ If routing is enabled, arcs shorter than 5m will be removed
+ to avoid routing problems. This behaviour can be modified with
+ this option. It has three variants:
+ (a) turn on short arc removal even if routing is not enabled.
+ (b) explicitly specify the minimum arc length (no 'm' suffix).
+ (c) completely disable short arc removal.
--road-name-pois[=GarminCode]
Generate a POI for each named road. By default, the POIs'
diff --git a/src/uk/me/parabola/imgfmt/app/net/RouteArc.java b/src/uk/me/parabola/imgfmt/app/net/RouteArc.java
index 1a0968d..b268b17 100644
--- a/src/uk/me/parabola/imgfmt/app/net/RouteArc.java
+++ b/src/uk/me/parabola/imgfmt/app/net/RouteArc.java
@@ -184,7 +184,7 @@ public class RouteArc {
return b;
}
- private static int convertMeters(double l) {
+ public static int convertMeters(double l) {
// XXX: really a constant factor?
// this factor derived by looking at a variety
// of arcs in an IMG of Berlin; 1/4 of
diff --git a/src/uk/me/parabola/mkgmap/general/RoadNetwork.java b/src/uk/me/parabola/mkgmap/general/RoadNetwork.java
index 0c45d68..82f7488 100644
--- a/src/uk/me/parabola/mkgmap/general/RoadNetwork.java
+++ b/src/uk/me/parabola/mkgmap/general/RoadNetwork.java
@@ -105,7 +105,7 @@ public class RoadNetwork {
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) {
+else if(RouteArc.convertMeters(arcLength) == 0) {
log.error("Road " + road.getRoadDef().getName() + " (OSM id " + road.getRoadDef().getId() + ") contains zero length arc");
log.error(" " + co.toOSMURL());
}
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 e350483..025573c 100644
--- a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
+++ b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
@@ -107,8 +107,13 @@ class Osm5XmlHandler extends DefaultHandler {
ignoreBounds = props.getProperty("ignore-osm-bounds", false);
routing = props.containsKey("route");
String rsa = props.getProperty("remove-short-arcs", null);
- if(rsa != null)
- minimumArcLength = (rsa.length() > 0)? Double.parseDouble(rsa) : 0.0;
+ final double DEFAULT_MIN_ARC_LENGTH = 5;
+ if("no".equals(rsa))
+ minimumArcLength = null;
+ else if(rsa != null)
+ minimumArcLength = (rsa.length() > 0)? Double.parseDouble(rsa) : DEFAULT_MIN_ARC_LENGTH;
+ else if(routing)
+ minimumArcLength = DEFAULT_MIN_ARC_LENGTH;
else
minimumArcLength = null;
frigRoundabouts = props.getProperty("frig-roundabouts");
@@ -500,6 +505,7 @@ class Osm5XmlHandler extends DefaultHandler {
Map arcCounts = new IdentityHashMap();
int numWaysDeleted = 0;
int numNodesMerged = 0;
+ log.info("Removing short arcs (min arc length = " + minArcLength + "m)");
log.info("Removing short arcs - counting arcs");
for(Way w : wayMap.values()) {
List points = w.getPoints();
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option --remove-short-arcs [PATCH v1]
Hi Steve, > OK and how about we take the opportunity to check out convertToMeters() The numbers it uses at the moment suggest that the Garmin wants the arc length in unit of 16 feet. > Could anyone that has a route that they know or can measure the exact > length of and compare to the length given by mapsource with an mkgmap > generated map post their results to the list or to me. I did a very quick check and the results were plausible but further checks would certainly be a good idea. Cheers, mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v2] - min arc length fixes
v2 of this patch not only enables remove-short-arcs by default when
routing is in use (as previously discussed on ML) but it also fixes some
problems in the way splitting code.
I would be grateful if people could test this patch because it could
possibly cure some routing failures.
Cheers,
Mark
diff --git a/resources/help/en/options b/resources/help/en/options
index 9bbfad7..ceb1921 100644
--- a/resources/help/en/options
+++ b/resources/help/en/options
@@ -182,11 +182,15 @@ Miscellaneous options:
in which they appear in the OSM input. Without this option,
the order in which the elements are processed is not defined.
---remove-short-arcs[=MinLength]
- Merge nodes to remove short arcs that can cause routing
- problems. If MinLength is specified (in metres), arcs shorter
- than that length will be removed. If a length is not
- specified, only zero-length arcs will be removed.
+--remove-short-arcs (a)
+--remove-short-arcs=MinLength (b)
+--remove-short-arcs=no(c)
+ If routing is enabled, arcs shorter than 5m will be removed
+ to avoid routing problems. This behaviour can be modified with
+ this option. It has three variants:
+ (a) turn on short arc removal even if routing is not enabled.
+ (b) explicitly specify the minimum arc length (no 'm' suffix).
+ (c) completely disable short arc removal.
--road-name-pois[=GarminCode]
Generate a POI for each named road. By default, the POIs'
diff --git a/src/uk/me/parabola/imgfmt/app/Coord.java b/src/uk/me/parabola/imgfmt/app/Coord.java
index 5462602..3e47df7 100644
--- a/src/uk/me/parabola/imgfmt/app/Coord.java
+++ b/src/uk/me/parabola/imgfmt/app/Coord.java
@@ -20,6 +20,7 @@ import java.util.Formatter;
import java.util.Locale;
import uk.me.parabola.imgfmt.Utils;
+import uk.me.parabola.imgfmt.app.net.RouteArc;
/**
* A point coordinate in unshifted map-units.
@@ -101,6 +102,11 @@ public class Coord implements Comparable {
return latitude == other.latitude && longitude == other.longitude;
}
+ public boolean tooCloseTo(Coord other) {
+ return ((latitude == other.latitude && longitude == other.longitude) ||
+!RouteArc.goodArcLength(quickDistance(other)));
+ }
+
/**
* Distance to other point in meters.
*/
diff --git a/src/uk/me/parabola/imgfmt/app/net/RouteArc.java b/src/uk/me/parabola/imgfmt/app/net/RouteArc.java
index 1a0968d..ae2bf8b 100644
--- a/src/uk/me/parabola/imgfmt/app/net/RouteArc.java
+++ b/src/uk/me/parabola/imgfmt/app/net/RouteArc.java
@@ -193,6 +193,12 @@ public class RouteArc {
return (int) (l * factor);
}
+
+ public static boolean goodArcLength(double len) {
+ int l = convertMeters(len);
+ return l > 0 && l < (1 << 14);
+ }
+
public void write(ImgFileWriter writer) {
offset = writer.position();
if(log.isDebugEnabled())
diff --git a/src/uk/me/parabola/mkgmap/general/RoadNetwork.java b/src/uk/me/parabola/mkgmap/general/RoadNetwork.java
index 0c45d68..f76b4b1 100644
--- a/src/uk/me/parabola/mkgmap/general/RoadNetwork.java
+++ b/src/uk/me/parabola/mkgmap/general/RoadNetwork.java
@@ -105,8 +105,8 @@ public class RoadNetwork {
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");
+else if(!RouteArc.goodArcLength(arcLength)) {
+ log.error("Road " + road.getRoadDef().getName() + " (OSM id " + road.getRoadDef().getId() + ") contains a bad arc of length " + String.format("%.2f", arcLength) + "m");
log.error(" " + co.toOSMURL());
}
diff --git a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
index 2a549f8..19beb66 100644
--- a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
+++ b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
@@ -468,9 +468,9 @@ public class StyledConverter implements OsmConverter {
// now split the way at the next point to
// limit the region that has restricted
// access
- if(!p.equals(p1) &&
+ if(!p.tooCloseTo(p1) &&
((i + 2) == points.size() ||
-!p1.equals(points.get(i + 2 {
+!p1.tooCloseTo(points.get(i + 2 {
Way tail = splitWayAt(way, i + 1);
// recursively process tail of way
addRoad(tail, gt);
@@ -531,8 +531,8 @@ public class StyledConverter implements OsmConverter {
// first point in the way
if(p1 instanceof CoordPOI &&
i > 0 &&
- !p.equals(points.get(i - 1)) &&
- !p.equals(p1)) {
+ !p.tooCloseTo(points.get(i - 1)) &&
+ !p.tooCloseTo(p1)) {
Way tail = splitWayAt(way, i);
// recursively process tail of road
addRoad(tail, gt);
@@ -622,7 +622,7 @@ public class
Re: [mkgmap-dev] Garmin Device Routing Options
Hi Chris, > In the Garmin GPSR (mine is a Etrex Legend HCX) there are several > options for routing. How are they mapped to mkgmap/OSM features? > > Here my guesses: > > Calculate Routes for: > > Car -> motorcar or motorcycle > Truck -> hgv (?) yes > Bus -> psv (?) yes > Emergency (???) emergency > Taxi -> taxi yes > Delivery -> psv (?) yes > Pedestrian -> foot yes > Bicycle -> bicycle yes > > Avoid: > > Toll Roads -> toll=yes not sure if this works > Highways -> (road classes 3&4 ??) has some effect > Unpaved Roads -> (??) > Carpool Lanes -> (??) these don't work 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] - min arc length fixes
Hi Valentijn, Thanks for the feedback. I can see where the problem is occuring. Wherever you have a node that is within the minimum arc length from a tile boundary you will get an error message. The question is: Is the routing actually broken at those locations? 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] - min arc length fixes
> At Wed, Aug 12, 2009 at 10:37:14PM +0200, Valentijn Sessink wrote: > > > The question is: Is the routing actually broken at those locations? > > Will check. Tomorrow. > > Actually, while thinking about it: I'm not sure what to test. Should I check > one of the sites that has a SEVERE message? Does your patch specifically > target these locations? Do you expect routing not to work at these locations > without your patch? And does "not work" mean that there's a road, but you > won't get a route over it? Like the infamous tunnel you couldn't get > through, even if it were an 80 meters journey? That sort of problem? The patch should actually reduce the number of short arcs. The remaining arcs that it is now complaining about were there already, the new patch hasn't created them, it's just now detecting them! So, I would like to know if those ways it is griping about are routable or not. If possible, please test a few to see if you can route over them. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v3] - min arc length fixes
v3
This patch is getting serious!
To reduce the number of short arcs that are being generated at tile
boundaries, this now clips the ways before the short arc removal is
done. However, it isn't a perfect solution because some map data is
very hard to deal with:
a - If a way crosses a tile boundary right in the corner such that both
ends are clipped and the resulting sub-way is less than 5m long, it
will fail to fix that. A possible workaround could be to introduce
extra points to elongate the arc.
b - a much more common problem is where a way forks very close to a
tile boundary and more than one of the connected ways cross the
boundary so you end up with several boundary nodes that should be
merged to remove the short arc(s) but they can't be moved as they are
boundary nodes! I believe that this could be fixed by not merging the
forking node but, instead, moving it away from the boundary such that
the ways connected to it that do cross the boundary are not less than
5m long! Alternatively, adding extra points to elongate the
forking arcs could be done.
With this patch, I processed a 14 tile map of the Netherlands and it
produced 21 of these short arc errors (all due to forks close to the
tile boundaries). I then tested the routing at 5 of these positions
(using mapsource) and only 1 of the 5 showed any sign of breakage, the
other 4 all routed happily in all directions. The one that was broken
was a junction of three ways and one pair of the ways had no
connectivity but the others were ok.
On the upside, the patch removed 147 short arcs introduced by the
clipping.
So more work is required here to fix the corner cases (ha ha) but please
test this patch anyway as I expect it to have problems due to the big
change it has introduced.
As usual, all feedback is appreciated.
v2 of this patch not only enables remove-short-arcs by default when
routing is in use (as previously discussed on ML) but it also fixes some
problems in the way splitting code.
I would be grateful if people could test this patch because it could
possibly cure some routing failures.
Cheers,
Mark
diff --git a/resources/help/en/options b/resources/help/en/options
index 9bbfad7..ceb1921 100644
--- a/resources/help/en/options
+++ b/resources/help/en/options
@@ -182,11 +182,15 @@ Miscellaneous options:
in which they appear in the OSM input. Without this option,
the order in which the elements are processed is not defined.
---remove-short-arcs[=MinLength]
- Merge nodes to remove short arcs that can cause routing
- problems. If MinLength is specified (in metres), arcs shorter
- than that length will be removed. If a length is not
- specified, only zero-length arcs will be removed.
+--remove-short-arcs (a)
+--remove-short-arcs=MinLength (b)
+--remove-short-arcs=no(c)
+ If routing is enabled, arcs shorter than 5m will be removed
+ to avoid routing problems. This behaviour can be modified with
+ this option. It has three variants:
+ (a) turn on short arc removal even if routing is not enabled.
+ (b) explicitly specify the minimum arc length (no 'm' suffix).
+ (c) completely disable short arc removal.
--road-name-pois[=GarminCode]
Generate a POI for each named road. By default, the POIs'
diff --git a/src/uk/me/parabola/imgfmt/app/Coord.java b/src/uk/me/parabola/imgfmt/app/Coord.java
index 5462602..3e47df7 100644
--- a/src/uk/me/parabola/imgfmt/app/Coord.java
+++ b/src/uk/me/parabola/imgfmt/app/Coord.java
@@ -20,6 +20,7 @@ import java.util.Formatter;
import java.util.Locale;
import uk.me.parabola.imgfmt.Utils;
+import uk.me.parabola.imgfmt.app.net.RouteArc;
/**
* A point coordinate in unshifted map-units.
@@ -101,6 +102,11 @@ public class Coord implements Comparable {
return latitude == other.latitude && longitude == other.longitude;
}
+ public boolean tooCloseTo(Coord other) {
+ return ((latitude == other.latitude && longitude == other.longitude) ||
+!RouteArc.goodArcLength(quickDistance(other)));
+ }
+
/**
* Distance to other point in meters.
*/
diff --git a/src/uk/me/parabola/imgfmt/app/net/RouteArc.java b/src/uk/me/parabola/imgfmt/app/net/RouteArc.java
index 1a0968d..ae2bf8b 100644
--- a/src/uk/me/parabola/imgfmt/app/net/RouteArc.java
+++ b/src/uk/me/parabola/imgfmt/app/net/RouteArc.java
@@ -193,6 +193,12 @@ public class RouteArc {
return (int) (l * factor);
}
+
+ public static boolean goodArcLength(double len) {
+ int l = convertMeters(len);
+ return l > 0 && l < (1 << 14);
+ }
+
public void write(ImgFileWriter writer) {
offset = writer.position();
if(log.isDebugEnabled())
diff --git a/src/uk/me/parabola/mkgmap/general/RoadNetwork.java b/src/uk/me/parabola/mkgmap/general/RoadNetwork.java
index 0c45d68..f76b4b1 100644
--- a/src/uk/me/parabola/mkgmap/general/RoadNetwork.java
+++ b/src/uk/me/parabola/mkgmap/general/RoadNetwork.java
@@ -105,8 +105,8 @@ public class RoadNetwork {
log.error("Road " + road.getRoadDef().getName() + " (O
Re: [mkgmap-dev] [PATCH v2] - min arc length fixes
Hi Valentijn, Thanks for the feedback. I have now posted a new patch that should fix the majority of the short arcs introduced by the clipping. It's not perfect but (I hope) a step in the right direction. My own testing shows that the presence of a short arc does not guarantee that the routing will be borken at that point but it can be. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] inverse oneways
Hi Chris, > is mkgmap able to handle inverse oneways (oneway=-1) correctly > (routing opposite to the ways direction) ? Yes, that has been implemented. 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] - min arc length fixes
Blast, just discovered that clipping all ways before doing short arc removal breaks polygons that straddle tile boundaries. The problem is that at the time the clipping is done, it is not known whether the way is a line or a polygon. Oh well, back to square one. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v4] - min arc length fixes
v4
I have gone back to the original ordering of doing short arc removal
before clipping as the previous version of this patch badly broke
polygons
As for arcs whose length is less 5m, I am not convinced they are
actually a problem as far as routing is concerned as my tests show that
mapsource can happily route through zero length arcs that occur at tile
boundaries.
It would be good if people who have been obliged to use a minimum arc
length of > 0 would provide examples of where the routing is broken.
i.e. without using this patch, find an example which doesn't route when
--remove-short-arcs is specified but will route when
--remove-short-arcs=5 is specified.
What is still an issue and was discussed a while ago is the problem
where routing will fail (or produce a big diversion) when routing out
of one tile into another and then back to a destination in the first
tile. That never seems to work, short arcs or not.
v3
This patch is getting serious!
To reduce the number of short arcs that are being generated at tile
boundaries, this now clips the ways before the short arc removal is
done. However, it isn't a perfect solution because some map data is
very hard to deal with:
a - If a way crosses a tile boundary right in the corner such that both
ends are clipped and the resulting sub-way is less than 5m long, it
will fail to fix that. A possible workaround could be to introduce
extra points to elongate the arc.
b - a much more common problem is where a way forks very close to a
tile boundary and more than one of the connected ways cross the
boundary so you end up with several boundary nodes that should be
merged to remove the short arc(s) but they can't be moved as they are
boundary nodes! I believe that this could be fixed by not merging the
forking node but, instead, moving it away from the boundary such that
the ways connected to it that do cross the boundary are not less than
5m long! Alternatively, adding extra points to elongate the
forking arcs could be done.
With this patch, I processed a 14 tile map of the Netherlands and it
produced 21 of these short arc errors (all due to forks close to the
tile boundaries). I then tested the routing at 5 of these positions
(using mapsource) and only 1 of the 5 showed any sign of breakage, the
other 4 all routed happily in all directions. The one that was broken
was a junction of three ways and one pair of the ways had no
connectivity but the others were ok.
On the upside, the patch removed 147 short arcs introduced by the
clipping.
So more work is required here to fix the corner cases (ha ha) but please
test this patch anyway as I expect it to have problems due to the big
change it has introduced.
As usual, all feedback is appreciated.
v2 of this patch not only enables remove-short-arcs by default when
routing is in use (as previously discussed on ML) but it also fixes some
problems in the way splitting code.
I would be grateful if people could test this patch because it could
possibly cure some routing failures.
Cheers,
Mark
diff --git a/resources/help/en/options b/resources/help/en/options
index 9bbfad7..ceb1921 100644
--- a/resources/help/en/options
+++ b/resources/help/en/options
@@ -182,11 +182,15 @@ Miscellaneous options:
in which they appear in the OSM input. Without this option,
the order in which the elements are processed is not defined.
---remove-short-arcs[=MinLength]
- Merge nodes to remove short arcs that can cause routing
- problems. If MinLength is specified (in metres), arcs shorter
- than that length will be removed. If a length is not
- specified, only zero-length arcs will be removed.
+--remove-short-arcs (a)
+--remove-short-arcs=MinLength (b)
+--remove-short-arcs=no(c)
+ If routing is enabled, arcs shorter than 5m will be removed
+ to avoid routing problems. This behaviour can be modified with
+ this option. It has three variants:
+ (a) turn on short arc removal even if routing is not enabled.
+ (b) explicitly specify the minimum arc length (no 'm' suffix).
+ (c) completely disable short arc removal.
--road-name-pois[=GarminCode]
Generate a POI for each named road. By default, the POIs'
diff --git a/src/uk/me/parabola/imgfmt/app/Coord.java b/src/uk/me/parabola/imgfmt/app/Coord.java
index 5462602..3e47df7 100644
--- a/src/uk/me/parabola/imgfmt/app/Coord.java
+++ b/src/uk/me/parabola/imgfmt/app/Coord.java
@@ -20,6 +20,7 @@ import java.util.Formatter;
import java.util.Locale;
import uk.me.parabola.imgfmt.Utils;
+import uk.me.parabola.imgfmt.app.net.RouteArc;
/**
* A point coordinate in unshifted map-units.
@@ -101,6 +102,11 @@ public class Coord implements Comparable {
return latitude == other.latitude && longitude == other.longitude;
}
+ public boolean tooCloseTo(Coord other) {
+ return ((latitude == other.latitude && longitude == other.longitude) ||
+!RouteArc.goodArcLength(quickDistance(other)));
+ }
+
/**
* Distance to ot
[mkgmap-dev] Inter-tile routing failures - not all our fault?
There is a particular failure of inter-tile routing that we have seen quite often which is that it fails to find a route when the source and destination are in the same tile and the only (sensible) route is via another tile. (If a sub-optimal route that only uses the source tile is available that will get used.) Well, I naturally assumed that this was caused by mkgmap doing something wrong but I'm not so sure now because I have been looking at the free nz mapset that is generated using cgpsmapper and that exhibits exactly the same behaviour as our maps do in this respect. So, either the bug is in mapsource (and all Garmin GPS units?) or mkgmap and cgpsmapper are both getting it wrong in the same way. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Routing with the default style
Hi Chris, > > The tags "vehicle" and "motorvehicle" are not recognised so you will > > need to add style rules to convert them to one of the access tags that > > are recognised which are: > > > > access (applies to everything) > > bicycle > > foot > > hgv > > motorcar > > motorcycle (same as motorcar) > > psv > > taxi > > emergency > > delivery > > goods (same as delivery) > > Good morning, Mark, > > and is mkgmap able to handle combinations of these access tags > correctly, so for example if a road is tagged as > > access=no > foot=yes > emergency=yes > > then routing is possible only for foot and emergency ? That should work as expected. > > And what I just tried out on my Etrex: > > motorcar=no is not impliying taxi=no (although a taxi is also a motorcar). I believe you can do that using the style file by adding taxi=no when motorcar=no is found. > This makes it easy to tweak a style that uses taxi for > a special routing (e.g. race-bicycles). I would expect that others have already tried that. Perhaps someone can report on that? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Inter-tile routing failures - not all our fault?
Hi Chris, > When I get a chance in the next couple of days, I'll have a play around with > some of the official Garmin maps and see if they can be made to exhibit the > same problem. If so then the limitation is most likely in the routing > algorithm > in MapSource and/or on the device. If that's the case then we should probably > start thinking of it as a 'feature' rather than a bug... That would be extremely useful. The bug can easily be reproduced by finding a road on tile A that forks on one side of a boundary and both of the forkees? cross the boundary to tile B. You then try and route between the ways on tile B. Sometimes it works OK and sometimes not. Another example is simply where a road goes across a tile boundary and then back to the original tile. I found a great example on the NL map where a road snaked across a boundary about 4 times and mapsource would route happily from any point on the road on tile A to any point on tile B but would not route back to tile A again. It was like this: \| 1 | \ | \ | \| |\ | \ | \ | 2 | / | / |/ /| / | / | 3 | \ | \ | \| |\ | \ | \ | 4 | / | / |/ /| / | / | 5 | Routing from 1 or 3 or 5 to 2 or 4 was fine but 1 to 3 or 5 failed. I realise that there are huge gaps in our knowledge of the Garmin data formats but this strikes me as being more likely to be a problem in the router rather than the data itself. My thinking here is that as the crossing points are not broken when considered individually and all of them can be routed across, that is strong evidence that there is nothing wrong with them. I mean, what are we looking for? a special bit or value that says that a tile (or way or node) can be routed through as described above? That would be perverse in the extreme (OK, I know we're dealing with Garmin here so, I guess, that anything is possible). Also, if we're missing some vital piece of data, you wouldn't expect it to work at all, but it does work, say 50% of the time or better. So, at this time, I can't imagine what we could be doing wrong to cause this but I can easily imagine how a routing algorithm could have problems when faced with non-trivial boundary crossings. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Inter-tile routing failures - not all our fault?
Using a recent GB tiled map on my eTrex, I have found that it performs differently (better?) to mapsource with regard to the problem of not routing across a boundary and back to the source tile. An example route I tried used a road that snaked across a boundary. Mapsource failed miserably in the manner previously described. The eTrex faired better in that it could manage to route across the boundary and back again for at least one crossing pair but when I tried to cross and back again for the second time, it took a really long time to calculate the route and the result was very silly. On another example route, that crossed the boundary to a fork and then crossed back to the original tile, mapsource failed but the eTrex was quite happy. So I remain far from convinced that the problem is due to buggy map data generated by mkgmap. However, it may be that we have to generate map data that is in some way "more sympathetic" to the needs of the Garmin routing engines. 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] - min arc length fixes
I slurped most of I95 into josm and it's a bit of a mess. For example, The Northbound carriageway is disconnected at node 73082202 and just below that is a section of link road that's pointing in the wrong direction. Various spurious ways are lying around not connected to anything like they are left over from some previous version I did, however, manage to route over 50 km in both directions using mapsource so it can't be completely broken! Perhaps, the mappers should put some effort into cleaning up/validating the data? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Inter-tile routing failures - not all our fault?
Hi Chris, > Sorry to say I too have tried to find a problem with the Garmin maps and > failed. No matter what combination of tile crossings, it always seems to do > the right thing. I probably tried 20-30 combinations of routes across various > tile borders. Is that a big enough sample size to see the problem or shall I > keep trying? Is that using mapsource and if so, what version is that? > I've attached one example where everything looks good despite multiple > crossings. The picture was corrupted, I could not see 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] Inter-tile routing failures - not all our fault?
Hi Chris, > Sorry to say I too have tried to find a problem with the Garmin maps and > failed. No matter what combination of tile crossings, it always seems to do > the right thing. I probably tried 20-30 combinations of routes across various > tile borders. Is that a big enough sample size to see the problem or shall I > keep trying? No, along with AS's report I think that it's fairly conclusive that the Garmin maps don't suffer from this problem. So either they are providing extra info, or the info we are providing (and cgpsmapper too) is duff in some way. I haven't the faintest clue what could be the issue here so until we get some hint as to what the problem could be, I'm ignoring it. I simply don't have spare time to dream up possible reasons why this problem exists. 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 v1] Merge similar lines and ways
Hi Thilo, > The attached will merge lines that are similar* after styling. It is > activated by the switch "--merge-lines". > > As there are less way fragments, the Douglas-Peucker filter will work > better and the routing should improve somewhat, because the ways will > be longer and the routing algorithm won't give up too soon. The size > of the resulting map is reduced a little bit as well. > > The patch is based on code published by Johann Gail on this mailing > list. > Will this cause a problem with ways that have been split on purpose because they are longer than the maximum allowed arc length? 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 v1] Merge similar lines and ways
Thilo, > Am 15.08.2009 um 13:04 schrieb Mark Burton: > > > Will this cause a problem with ways that have been split on purpose > > because they are longer than the maximum allowed arc length? > > No, not at all. The reason is that the merging of the ways is done > before they are split again if necessary. The net effect is still a > size reduction of the map (with the style I'm using). I hope that I > also got everything else right: relations, turn-restrictions, etc. > Please test and complain ;). Note that the argument "--merge-lines" is > needed for the merging to take place. > > The more detailed the OSM data becomes, the more the merging will be > helpful. The main reason are the route relations. Here in my hometown > all the bus routes are mapped and of course they go all over the > place. Each time a bus route enters or leaves a street, the street has > to be chopped up. Add to that a lot of cycle routes, hiking routes > etc. and you see that the street gets chopped up into tiny bits. > Depending on the map you try to create, you will ignore most of those > relations and they will make no difference, so all those tiny bits > have the same attributes. Merging them again will reduce the number of > ways. This at least reduces the size of the map slightly and probably > also helps routing and improves the drawing speed somewhat. I understand the potential benefits of this patch. However, looking at the code it seems to me that the merging happens after StyledConverter.addRoad() is called and that is where the way lengths are limited. So you either have to do the merging earlier, or you need to add a constraint to limit the length of the merged way. Actually, there are several constraints in StyledConverter: // limit arc lengths to what can currently be handled by RouteArc private final int MAX_ARC_LENGTH = 25000; private final int MAX_POINTS_IN_WAY = 200; private final int MAX_NODES_IN_WAY = 16; 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 v1] Merge similar lines and ways
Hi Chris, > Are all these patches which are announced on the list as > [PATCH vx] included in the mkgmap-latest? > > If not - where can I download the patched versions? No, it's up to the individual developer to "mix and match" whatever patches they wish to try. They have to be applied to trunk. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Make --add-pois-to-areas default?
Hi Hanno, > I just noted with a garmin map from kleineisel.de that my local supermarket > is > not listed. > > The reason is that it's an area, not a point. I think this is caused by not > applying --add-pois-to-areas (?) > > I think it's reasonable to make this option the default and only disable it > by > request. It should be the common case that one wants pois generated also if > they are areas. > > Should I make a patch for that? Personally, I prefer mkgmap to not add stuff to the map unless I ask it to do that. I think it's better to request that something extra gets added rather than requesting that the extra stuff is removed. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Does anyone have a genuine garmin routable map tile that is unlocked?
Not a basemap, but a real routable tile. It doesn't matter what area it is for. If so, can you please zip it up and send to me or otherwise make it available to download. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Garmin Device Routing Options
Hi Chris, > After doing some tests on my Etrex Legend HCX I believe that something > is mixed up. > > On my device delivery/Lieferwagen(garmin) is mapped to emergency(osm). > > Bug on Garmin or bug in mkgmap ? You're right, the emergency and delivery access bits are swapped. Here's what I said in commit 965: Assign new values for bits that block emergency and delivery access. I am pretty sure that these two access bits go into the top two bits of the net pointer - I am not so sure that I have them the right way around - we need to check with an example map that has one of them set and the other clear to confirm the ordering. Guess I forgot to check if they were the right way around! Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Garmin Device Routing Options
Hi Mario, > Shouldn't there be a subtle difference between Delivery and Truck? > As I understand it, Truck should allow routing THROUGH an area, whereas > Delivery should also allow routing INTO an area. > Each allowing or denying routing conforming to the UK motoring > restriction 'HGV - Access only'. > I can think of many instances where hgvs are only allowed into a road > network if they are delivering or gaining access to a property, but not > if they're driving through. The Garmin access restrictions as we understand them are not as flexible as the OSM tags. No through routing only works for cars, i.e. you can have motorcar=destination but the more general case access=destination or other specific cases like hgv=destination don't work. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Garmin Device Routing Options
Hi Chris, > Do I understand correct that the garmin maps have a flag for > motorcar=destination which is different from motorcar= no ? Yes, motorcar=no bars car traffic from a way but motorcar=destination only bars car traffic if the destination is not that way (or a connected way that also has destination only routing, (I think that's how it works!)) Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Progressing patches
I have 3 patches currently out for evaluation: mb-min-arc-length-v4.patch various tweaks related to short arcs including making remove-short-arcs enabled by default with a min arc length of 5m - could effect any map that has routing mb-extended-types-v2.patch Support the 3-byte marine/extended types - should (if not buggy) have no bad effects on maps that don't use those types. mb-zero-style-v3.patch allows styling to be done by external program - no effect on maps that don't use this feature Naturally, I believe them all to be completely sound and worthy of inclusion in mkgmap. Shall I commit them? or is more testing/discussion required? No hurry here, just seeing what people think. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Progressing patches
Hi Garvan, Thanks for the feedback, much appreciated. Cheers, Mark On Mon, 17 Aug 2009 08:58:04 +0700 garvan.m...@online.com.kh wrote: > Quoting Mark Burton : > > > > > I have 3 patches currently out for evaluation: > > > > mb-min-arc-length-v4.patch > > various tweaks related to short arcs including making > > remove-short-arcs enabled by default with a min arc length of 5m - > > could effect any map that has routing > > From reading posts on the list, I am not convinced everything is > known about what the minimum length should be. If your patch still > allows for users to test and experiment with different min lengths > then I would commit it. I use a length greater than 5m, but I edit the > map data by hand. I must test to see how my hand edits differ from the > automatic adjustments. > > > > > mb-extended-types-v2.patch > > Support the 3-byte marine/extended types - should (if not buggy) have > > no bad effects on maps that don't use those types. > > I did not try this patch, but from others reports it sounds good. > > > > > mb-zero-style-v3.patch > > allows styling to be done by external program - no effect on maps > > that don't use this feature > > > > I tested this and it worked nicely. Its useful for me when converting > from mp to osm format. I would commit it. > > > Naturally, I believe them all to be completely sound and worthy of > > inclusion in mkgmap. > > > > Shall I commit them? or is more testing/discussion required? > > > > No hurry here, just seeing what people think. > > > > Cheers, > > > > Mark > > ___ > > mkgmap-dev mailing list > > mkgmap-dev@lists.mkgmap.org.uk > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] R: Progressing patches
Hi Marco, > Hi Mark, I did not follow very well last discussions. I agree in enabling > remove-short-arcs by default, but with no min length (i.e. min lenght=0). > > Could you please explain why arcs shorter than 5m should be collapsed? Arc lengths appear to be encoded in units of 16 feet. That is equal to approx 4.8m. i.e. an arc that is less than 4.8m is encoded as length 0. So if we want all arcs to have a non-zero length, they must be at least 4.8 metres, rounding up to an integer gives 5m. Personally, I am not convinced that having zero length arcs really makes a difference. However, some people report that the minimum length needs to be greater than 0 otherwise routing is broken in some places. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] scrambled roads in netherland
Hi Chris, > Does the error messages mean that the tile is simply too big and > I have to split into smaller tiles ? Yes, I think that is the case. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] scrambled roads in netherland
Hi Chris, > Ok, and when not using assertions (-ea) then there should > be at least a warning message. Agreed. Feel free to submit a patch. However, I would not dream of running mkgmap at any time without assertions enabled. Only a true optimist would do that. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v1] - fix boundary node lat
I discovered that the latitude value in the boundary nodes (NOD3) table
should have 180 degrees added to it (aka 0x80) to make it
consistent with Garmin maps.
The fact that we can route between (our) tiles without this mod shows
that it doesn't really matter but we may as well be as authentic as
possible.
So, tiddly patch attached, please test it with regard to inter-tile
routing. I am not expecting anything to change.
Cheers,
Mark
diff --git a/src/uk/me/parabola/imgfmt/app/net/RouteNode.java b/src/uk/me/parabola/imgfmt/app/net/RouteNode.java
index 942e201..7d44497 100644
--- a/src/uk/me/parabola/imgfmt/app/net/RouteNode.java
+++ b/src/uk/me/parabola/imgfmt/app/net/RouteNode.java
@@ -194,7 +194,7 @@ public class RouteNode implements Comparable {
assert isBoundary() : "trying to write nod3 for non-boundary node";
writer.put3(coord.getLongitude());
- writer.put3(coord.getLatitude());
+ writer.put3(coord.getLatitude() + 0x80); // + 180 degrees
writer.put3(offsetNod1);
}
___
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 boundary node lat
Hi Clinton, > I tested this patch (briefly), and as expected, did not notice any difference. Thanks for bothering to do that - I think it's harmless so unless I get any -ve reports today it will get committed. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1140: Added support for extended types.
Hi Felix, > I did not look into the patch, but does it mean that I could use in my > style-file the following: > [0x01234 resolution 22]? > > And then off course add a definition for this type in my typfile. > > Or is there more that needs to be changed? Actually, my knowledge of extended types is limited. The attached file lists some extended codes. It may not be a complete listing, perhaps more are supported? Note that there are codes allocated for custom points, lines, and areas. Perhaps you can use those? Cheers, Mark ;GPSmapper element types list ; ;RGN10 & RGN20 types-all types are two bytes, first byte is a major type byte, second byte is a subtype. ; ;WARNING-RGN10 can use both bytes, RGN20 can use only the first byte, so if we want-create a Dinning point on map, using RGN10 we can define if it has-be an Asian(0x2a02) or Chinese(0x2a04) but using RGN20 element we can only define it as a Dinning area(0x2a)-no subtype is allowed! ; ;THIS FILE IS USED BY GPSMAPPER.EXE FILE! ;YOU CAN MODIFY THIS FILE (ie. translate)-but keep the format of a single line consistent! ;between hex type (0x) and name of element you must use TAB as separator! ; ;Hexadecimal Type Name ; ;*** ;* RGN10 & RGN20 * ;*** ; [RGN10/20 types] 0x0100-0x0500 City name(Point, fat, big) 0x0600-0x0A00 City name(Point, big) 0x0B00 City name (Point, small) 0x0C00 City name (Point, small) 0x0D00 City name (Point, small) 0x0E00-0x1100 City name(Point, big) 0x1200 Marine info 0x1400-0x153F Region name (no Point, big) 0x1E00-0x1E3F Region name (no Point, middle) 0x210F Exit(Service) 0x2000-0x203F Exit 0x2100-0x213F Exit(with facilities) 0x2200-0x223F Exit(Restroom) 0x2300-0x233F Exit(Convenience Store) 0x2400-0x243F Exit(Weight Station) 0x2500-0x253F Exit(Tollbooth Booth) 0x2600-0x263F Exit(Information) 0x2700-0x273F Exit 0x2800-0x283F Region name (no Point, small) 0x2A00 Dining(Other) 0x2A01 Dining(American) 0x2A02 Dining(Asian) 0x2A03 Dining(Barbecue) 0x2A04 Dining(Chinese) 0x2A05 Dining(Deli/Bakery) 0x2A06 Dining(International) 0x2A07 Fast Food 0x2A08 Dining(Italian) 0x2A09 Dining(Mexican) 0x2A0A Dining(Pizza) 0x2A0B Dining(Sea Food) 0x2A0C Dining(Steak/Grill) 0x2A0D Dining(Bagel/Donut) 0x2A0E Dining(Cafe/Diner) 0x2A0F Dining(French) 0x2A10 Dining(German) 0x2A11 Dining(British Isles) 0x2B00 Hotel(Other) 0x2B01 Hotel/Motel 0x2B02 Bed & Breakfast inn 0x2B03 Camping/RV-Park 0x2B04 Resort 0x2C01 Amusement Park 0x2C02 Museum/History 0x2C03 Libraries 0x2C04 Land Mark 0x2C05 School 0x2C06 Park 0x2C07 Zoo 0x2C08 Sportpark, Stadium,(point) 0x2C09 Fair, Conference(point) 0x2C0A Vine restaurant(point) 0x2C0B Place of Worship 0x2C0C Hot Spring 0x2D01 Theater 0x2D02 Bar 0x2D03 Cinema 0x2D04 Casino 0x2D05 Golf 0x2D06 Skiing Center 0x2D07 Bowling 0x2D08 Ice/Sporting 0x2D09 Swimming 0x2D0A Sports(point) 0x2D0B Sailing Airport 0x2E01 Department Store 0x2E02 Grocery 0x2E03 General Merchandiser 0x2E04 Shopping Center 0x2E05 Pharmacy 0x2E06 Convenience 0x2E07 Apparel 0x2E08 House and Garden 0x2E09 Home Furnishing 0x2E0a Special Retail 0x2E0b Computer/Software 0x2F00 generic service 0x2F01 Fuel/Gas 0x2F02 Car Rental 0x2F03 Car Repair 0x2F04 Airport 0x2F05 Post Office 0x2F06 Bank 0x2F07 Car Dealer(point) 0x2F08 Bus Station 0x2F09 Marina 0x2F0A Wrecker Service 0x2F0B Parking 0x2F0C Restroom 0x2F0D Automobile Club 0x2F0E Car Wash 0x2F0F Garmin Dealer 0x2F10 Personal Service 0x2F11 Business Service 0x2F12 Communication 0x2F13 Repair Service 0x2F14 Social Service 0x2F15 Utility 0x2F16 Truck Stop 0x3000 generic emergency/government 0x3001 Police Station 0x3002 Hospital 0x3003 Public Office 0x3004 Justice 0x3005 Concert hall(point) 0x3006 Border Station(point) 0x4000-0x403F Golf 0x4100-0x413F Fish 0x4200-0x423F Wreck 0x4300-0x433F Marina 0x4400-0x443F Gas 0x4500-0x453F Restaurant 0x4600-0x463F Bar 0x4700-0x473F Boat Ramp 0x4800-0x483F Camping 0x4900-0x493F Park 0x4A00-0x4A3F Picnic Area 0x4B00-0x4B3F Hospital 0x4C00-0x4C3F Information 0x4D00-0x4D3F Parking 0x4E00-0x4E3F Restroom 0x4F00-0x4F3F Shower 0x5000-0x503F Drinking Water 0x5100-0x513F Telephone 0x5200-0x523F Scenic Area 0x5300-0x533F Skiing 0x5400-0x543F Swimming 0x5500-0x553F Dam 0x5700-0x573F Danger Area 0x5800-0x583F restricted Area 0x5900 Generic Airport 0x5901 Large Airport 0x5902 Medium Airport 0x5903 Small Airport 0x5904 Heliport 0x5905-0x593F Airport 0x5D00-0x5D3F Daymark,Green Square 0x5E00-0x5E3F Daymark,Red Triangle 0x6200 Depth with point in feet one decimal place 0x6300 Height without point in feet no decimal place 0x6400 Manmade Feature 0x6401 Bridge 0x6402
Re: [mkgmap-dev] Commit: r1140: Added support for extended types.
> That list is in my eyes just crap when it comes to extended types, as > any of those lines / points / polygons will only be shown if defined in > typfile, and many others if defined too. I only don't know whether there > are any regions that will not be shown, or only shown in Mapsource. My etrex shows at least some of them. > I don't think any 3-byte POI is shown in search, but maybe wrong on this You're wrong because some of the marine pois show up. I don't use a typfile (so just guessing) but why can't you use one to define whatever is needed for stuff with extended types? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] multiple garmin elements from one osm element
On Wed, 19 Aug 2009 23:18:02 +0200
Felix Hartmann wrote:
> Could you or someone try to modify this patch so that it compiles
> against mkgmap 1140.
Try attached.
Not been tested, so please verify it works as expected.
Cheers,
Mark
diff --git a/src/uk/me/parabola/mkgmap/osmstyle/ActionRule.java b/src/uk/me/parabola/mkgmap/osmstyle/ActionRule.java
index bf00c85..91bdbee 100644
--- a/src/uk/me/parabola/mkgmap/osmstyle/ActionRule.java
+++ b/src/uk/me/parabola/mkgmap/osmstyle/ActionRule.java
@@ -52,7 +52,7 @@ public class ActionRule implements Rule {
this.type = null;
}
- public GType resolveType(Element el) {
+ public GType resolveType(Element el, GType pre) {
if (expression == null || expression.eval(el)) {
for (Action a : actions)
a.perform(el);
diff --git a/src/uk/me/parabola/mkgmap/osmstyle/ExpressionRule.java b/src/uk/me/parabola/mkgmap/osmstyle/ExpressionRule.java
index cbbb913..b7b5248 100644
--- a/src/uk/me/parabola/mkgmap/osmstyle/ExpressionRule.java
+++ b/src/uk/me/parabola/mkgmap/osmstyle/ExpressionRule.java
@@ -28,22 +28,22 @@ import uk.me.parabola.mkgmap.reader.osm.Rule;
* @author Steve Ratcliffe
*/
public class ExpressionRule implements Rule {
- private final Op exression;
+ private final Op expression;
private final GType gtype;
- public ExpressionRule(Op exression, GType gtype) {
- this.exression = exression;
+ public ExpressionRule(Op expression, GType gtype) {
+ this.expression = expression;
this.gtype = gtype;
}
- public GType resolveType(Element el) {
- if (exression.eval(el))
+ public GType resolveType(Element el, GType pre) {
+ if (expression.eval(el))
return gtype;
return null;
}
public String toString() {
- return exression.toString() + ' ' + gtype;
+ return expression.toString() + ' ' + gtype;
}
}
diff --git a/src/uk/me/parabola/mkgmap/osmstyle/FixedRule.java b/src/uk/me/parabola/mkgmap/osmstyle/FixedRule.java
index 836547d..315c4ad 100644
--- a/src/uk/me/parabola/mkgmap/osmstyle/FixedRule.java
+++ b/src/uk/me/parabola/mkgmap/osmstyle/FixedRule.java
@@ -32,7 +32,7 @@ public class FixedRule implements Rule {
this.gtype = gtype;
}
- public GType resolveType(Element el) {
+ public GType resolveType(Element el, GType pre) {
return gtype;
}
diff --git a/src/uk/me/parabola/mkgmap/osmstyle/RuleSet.java b/src/uk/me/parabola/mkgmap/osmstyle/RuleSet.java
index e93539e..33ce15e 100644
--- a/src/uk/me/parabola/mkgmap/osmstyle/RuleSet.java
+++ b/src/uk/me/parabola/mkgmap/osmstyle/RuleSet.java
@@ -63,14 +63,14 @@ public class RuleSet implements Rule {
return rules.entrySet();
}
- public GType resolveType(Element el) {
+ public GType resolveType(Element el, GType pre) {
GType foundType = null;
for (String tagKey : el) {
Rule rule = rules.get(tagKey);
if (rule != null) {
-GType type = rule.resolveType(el);
+GType type = rule.resolveType(el, pre);
if (type != null) {
- if (foundType == null || type.isBetterPriority(foundType)) {
+ if ((foundType == null || type.isBetterPriority(foundType)) && (pre == null || pre.isBetterPriority(type))) {
foundType = type;
}
}
diff --git a/src/uk/me/parabola/mkgmap/osmstyle/SequenceRule.java b/src/uk/me/parabola/mkgmap/osmstyle/SequenceRule.java
index 6b46871..72b5a59 100644
--- a/src/uk/me/parabola/mkgmap/osmstyle/SequenceRule.java
+++ b/src/uk/me/parabola/mkgmap/osmstyle/SequenceRule.java
@@ -34,9 +34,9 @@ import uk.me.parabola.mkgmap.reader.osm.Rule;
public class SequenceRule implements Rule, Iterable {
private final List ruleList = new ArrayList();
- public GType resolveType(Element el) {
+ public GType resolveType(Element el, GType pre) {
for (Rule r : ruleList) {
- GType type = r.resolveType(el);
+ GType type = r.resolveType(el, pre);
if (type != null)
return type;
}
diff --git a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
index 8ae3b94..ca81ccd 100644
--- a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
+++ b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
@@ -245,26 +245,36 @@ public class StyledConverter implements OsmConverter {
foundType = makeGTypeFromTags(way);
if(foundType == null)
return;
+ if (foundType.getFeatureKind() == GType.POLYLINE) {
+if(foundType.isRoad())
+ addRoad(way, foundType);
+else
+ addLine(way, foundType);
+ }
+ else
+addShape(way, foundType);
}
else {
preConvertRules(way);
- foundType = wayRules.resolveType(way);
- if (foundType == null)
-return;
- postConvertRules(way, foundType);
- }
+ do {
+foundType = wayRules.resolveType(way, foundType);
+if (foundType == null)
+ return;
+
+postConvertRules(way, foundType);
- if (foundType.getFeatureKind() == GType.POLYLINE) {
- if(foundType.isRoad() &&
- !MapElement.hasExtendedType(foundType.getType()))
-addRoad(way, foundType);
- else
-addL
Re: [mkgmap-dev] Commit: r1140: -- breaks overlays and relations file?
Hi Felix, > Could some other people please try out whether the overlays and > relations file still work with 1140? > > I have currently the problem that no more routes are visible when > compiling maps with 1140. Also overlays file seems to have stopped working. Are you using a stock 1140 or do you have other patches applied? I can't think how the extended type stuff could affect overlays or relations. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1140: -- breaks overlays and relations file?
Hi Felix, Is this still a problem or did it get better? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1140: -- breaks overlays and relations file?
Felix, > No I'm still unable to get routes and overlays to show up on the map. > > either using 1140 with multiple elements patch (no other patches), nor with > clean svn version. That's sad. I don't know what you mean by routes or overlays so I can't imagine what the problem is. If you could supply more info about what you are doing, perhaps it will become clear. Is it a styling issue? Related to types? Give me a clue. Is anyone else seeing issues with 1140? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1140: -- breaks overlays and relations file?
Hi Felix, > Overlays. I mean the overlays file in the style-files. Before 1139 if you > had a line in your lines file saysing for example: > highway=footway & highway=cycleway [0x123 resolution 20] you could now > define in the overlays file 0x123: 0x2a, 0x0c > and both 0x2a and 0x0c were included in the map at the same place. So if > your footway looks like 0x0x0x (with 0 being transparent in typfile, and x > being a color) and cycleway y0y0y0 (with y being another color), the result > would be both footway and cycleway rendered as yxyxyx. > > routes... ups sorry should have said relations. Anything written to the > relations file is not enacted anymore. Thanks for spelling this out for me. I'm such an airhead that I didn't even know these features existed! I have looked at the overlay stuff and still can't see why the extended type code should break it so, at the moment, it remains a mystery. I shall keep thinking about 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] Commit: r1140: -- breaks overlays and relations file?
Hi Steve, > Mark, great work on implementing the extended types. Thanks, still more goodies to come as I have now moved on to the encoding of various xtype attributes (depth/height, various colours, buoy/light types, etc.) Making good progress. > As for this problem, I don't see it. With a simple style that > only includes one line type with overlays it works just fine. Same > with relations. > > Also looking at the code change, there is nothing that appears to > touch that area of the styling at all. Yes, I can't see how the xtype stuff could have broken those features. > Felix, I don't mind looking into it, but I will need a lot more > information including the complete style, an input file that doesn't > work and an example of a road that doesn't work in the new version. It would be great if you could help there. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v1] - support for extended type attributes
Yo Landlubbers, Here's the first cut at encoding support for extended type attributes. This is mostly concerned with marine entities like (wreck depths, buoy types, light types, colours, etc.) As there is quite a lot of it and I haven't sussed it all out yet, I thought it would make sense to post patches as I go along so that people can try it out and find the bugs sooner rather than later. The attribute values are supplied as special tags with a mkgmap:xt- prefix. So, for example, mkgmap:xt-depth=40.6m specifies the depth of something (in metres). This first tranche supports: Point types 0x0102xx (buoys/beacons) can have: mkgmap:xt-foundation-colour (a colour name from list FC below) mkgmap:xt-light-colour (a colour name from list LC below) mkgmap:xt-light-type (a type name from list LT below) mkgmap:xt-period (optional period in secs (not limited to integer) Point types 0x0103xx (entities with depth/height) and 0x0104xx (obstructions) mkgmap:xt-depth (a depth with optional units (ft or m) default is m) mkgmap:xt-height (alias for, and mutually exclusive to, xt-depth) mkgmap:xt-position (an optional position from list P below) These attributes are turned into a sequence of bytes that are embodied in the map object. For testing purposes you can also specify those bytes explicitly as a sequence of hex digits using the mkgmap:xt-extra-bytes tag but you won't want to use that unless you are working on attribute value encoding (like me!) Next up will be lights which I understand how to encode except for multiple lights and angles - still working on that. Then will come lines and areas. All feedback welcome. BTW a good source of info is the cgpsmapper manual which is readily available on the net. It has a chapter on marine types. - List FC "red", "green", "yellow", "white", "black", "black-yellow", "white-red", "black-red", "white-green", "red-yellow", "red-green", "orange", "black-yellow-black", "yellow-black", "yellow-black-yellow", "red-white", "green-red-green", "red-green-red", "black-red-black", "yellow-red-yellow", "green-red", "black-white", "white-orange", "orange-white", "green-white" List LC "unlit", "red", "green", "white", There is possibly some more light colours but I don't yet know how to encode them so we should stick with these for the moment. List LT "fixed", "isophase", "flashing", "group flashing", "composite group flashing", "occulting", "group occulting", "composite group occulting", "long flashing", "group long flashing", "morse", "quick", "group quick", "group quick and long flashing", "interrupted quick", "very quick", "group very quick", "group very quick and long flashing", "interrupted very quick", "ultra quick", "interrupted ultra quick", "fixed and occulting", "fixed and group occulting", "fixed and isophase", "fixed and flashing", "fixed and group flashing", "fixed and long flashing", "alternating", "alternating occulting", "alternating flashing", "alternating group flashing" The morse type takes a letter argument but I don't know how to encode that yet. List P "unknown", "doubtful", "existence doubtful", "approximate", "reported" diff --git a/src/uk/me/parabola/imgfmt/app/trergn/ExtTypeAttributes.java b/src/uk/me/parabola/imgfmt/app/trergn/ExtTypeAttributes.java new file mode 100644 index 000..aadde77 --- /dev/null +++ b/src/uk/me/parabola/imgfmt/app/trergn/ExtTypeAttributes.java
[mkgmap-dev] [PATCH v2] - support for extended type attributes
v2 - moving swiftly on. Added support for lights and reworked a few things. mkgmap:xt-foundation-colour is now just mkgmap:xt-colour mkgmap:xt-light-colour has been replaced with mkgmap:xt-light (more on this below) mkgmap:xt-light-type is now just mkgmap:xt-type Light colour, range (in nm) and angle is now specified with the mkgmap:xt-light tag - the values are just separated with commas, and only the colour is required for simple lights. All angles are in degrees. So, for example: mkgmap:xt-light=red (a red light) mkgmap:xt-light=red,5 (... visible at up to 5 nm) mkgmap:xt-light=red,5,172 (... sector starts at 172 degrees) The sector start angle only makes sense if you have multiple lights defined (separate light defs with one of /;:) - for example: mkgmap:xt-light=red,5,172/green,5,230/unlit,,300 you can add a text note, international designator or local designator to a buoy or light with: mkgmap:xt-note=hello world mkgmap:xt-int-desig=ABC mkgmap:xt-local-desig=XYZ These show up in the POI properties window in mapsource. There is also: mkgmap:xt-height-above-foundation (a height) mkgmap:xt-height-above-datum (a height) mkgmap:xt-leading-angle (an angle) you can now specify multiple period values to give a flash sequence but, unfortunately, it only encodes 2 values at the moment, the encoding for more than 2 values is yet to be discovered. The full range of light colours is now supported: "unlit", "red", "green", "white", "blue", "yellow", "violet", "amber" So, lights, buoys, obstructions are now fairly well catered for so it's probably time to look at lines and areas. Yo Landlubbers, Here's the first cut at encoding support for extended type attributes. This is mostly concerned with marine entities like (wreck depths, buoy types, light types, colours, etc.) As there is quite a lot of it and I haven't sussed it all out yet, I thought it would make sense to post patches as I go along so that people can try it out and find the bugs sooner rather than later. The attribute values are supplied as special tags with a mkgmap:xt- prefix. So, for example, mkgmap:xt-depth=40.6m specifies the depth of something (in metres). This first tranche supports: Point types 0x0102xx (buoys/beacons) can have: mkgmap:xt-foundation-colour (a colour name from list FC below) mkgmap:xt-light-colour (a colour name from list LC below) mkgmap:xt-light-type (a type name from list LT below) mkgmap:xt-period (optional period in secs (not limited to integer) Point types 0x0103xx (entities with depth/height) and 0x0104xx (obstructions) mkgmap:xt-depth (a depth with optional units (ft or m) default is m) mkgmap:xt-height (alias for, and mutually exclusive to, xt-depth) mkgmap:xt-position (an optional position from list P below) These attributes are turned into a sequence of bytes that are embodied in the map object. For testing purposes you can also specify those bytes explicitly as a sequence of hex digits using the mkgmap:xt-extra-bytes tag but you won't want to use that unless you are working on attribute value encoding (like me!) Next up will be lights which I understand how to encode except for multiple lights and angles - still working on that. Then will come lines and areas. All feedback welcome. BTW a good source of info is the cgpsmapper manual which is readily available on the net. It has a chapter on marine types. - List FC "red", "green", "yellow", "white", "black", "black-yellow", "white-red", "black-red", "white-green", "red-yellow", "red-green", "orange", "black-yellow-black", "yellow-black", "yellow-black-yellow", "red-white", "green-red-green", "red-green-red", "black-red-black", "yellow-red-yellow", "green-red", "black-white", "white-orange", "orange-white", "green-white" List LC "unlit", "red", "green", "white", There is possibly some more light colours but I don't yet know how to encode them so we should stick with these for the moment. List LT "fixed", "isophase", "flashing", "group flashing", "composite group flashing",
Re: [mkgmap-dev] zero length arc
Hi, > GRAVE (RoadNetwork): Road null (OSM id 36913306) contains zero length arc > GRAVE (RoadNetwork): > http://www.openstreetmap.org/?lat=44.33355&lon=9.34585&zoom=17 ... > Is it just a message to tell me that mkgmap has removed the zero length > arc or a problem ? Thanks. Francois No, it's saying that there is a short arc still there. Whether it is a problem or not depends on whether it causes a problem! Sorry to be obscure but it's not always the case that when we get that message it really is a problem. OSM is down at the moment so I can't look at that data. I will when it comes back again. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] zero length arc
Hi Francois, That zero length arc is occurring at a roundabout that has about 12 points and a diameter of approx 1m. Silly data! Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v3] - support for extended type attributes
v3 - more tweaks to lights + lines & areas "morse" light type now takes the morse letter to flash, e.g. "morse A" lights can be tagged as having a "racon" (you'll have to google it like I did!) by setting mkgmap:xt-racon to yes. Depth areas (type 0x0103xx) can have the depth attribute and lines 0x010105 to 0x010107 (contour, overhead cable, bridge) can have height. There is a new mkgmap:xt-style attribute that takes a 16 bit value. The bottom 4 bits specify a colour and bits 8-14 specify a line style. See the cgpsmapper manual for the supported colours and styles. As an example, a value of 0x3004 means red line like this +++ This can be used on lines with types 0x0104xx, 0x0105xx and 0x0106xx. You can also use the xt-style (colour part only) attribute on points of type 0x010500 which are labels with coloured text. The point's name tag is shown on the map in the colour you specify. Could be useful. There's still a bit more that could be done on on the light flash sequence encoding but as it's rather unlikely that anyone will every want to use that, I'm not bothering for the moment. So, the job is pretty much done. As usual, all feedback is welcome. -- v2 - moving swiftly on. Added support for lights and reworked a few things. mkgmap:xt-foundation-colour is now just mkgmap:xt-colour mkgmap:xt-light-colour has been replaced with mkgmap:xt-light (more on this below) mkgmap:xt-light-type is now just mkgmap:xt-type Light colour, range (in nm) and angle is now specified with the mkgmap:xt-light tag - the values are just separated with commas, and only the colour is required for simple lights. All angles are in degrees. So, for example: mkgmap:xt-light=red (a red light) mkgmap:xt-light=red,5 (... visible at up to 5 nm) mkgmap:xt-light=red,5,172 (... sector starts at 172 degrees) The sector start angle only makes sense if you have multiple lights defined (separate light defs with one of /;:) - for example: mkgmap:xt-light=red,5,172/green,5,230/unlit,,300 you can add a text note, international designator or local designator to a buoy or light with: mkgmap:xt-note=hello world mkgmap:xt-int-desig=ABC mkgmap:xt-local-desig=XYZ These show up in the POI properties window in mapsource. There is also: mkgmap:xt-height-above-foundation (a height) mkgmap:xt-height-above-datum (a height) mkgmap:xt-leading-angle (an angle) you can now specify multiple period values to give a flash sequence but, unfortunately, it only encodes 2 values at the moment, the encoding for more than 2 values is yet to be discovered. The full range of light colours is now supported: "unlit", "red", "green", "white", "blue", "yellow", "violet", "amber" So, lights, buoys, obstructions are now fairly well catered for so it's probably time to look at lines and areas. Yo Landlubbers, Here's the first cut at encoding support for extended type attributes. This is mostly concerned with marine entities like (wreck depths, buoy types, light types, colours, etc.) As there is quite a lot of it and I haven't sussed it all out yet, I thought it would make sense to post patches as I go along so that people can try it out and find the bugs sooner rather than later. The attribute values are supplied as special tags with a mkgmap:xt- prefix. So, for example, mkgmap:xt-depth=40.6m specifies the depth of something (in metres). This first tranche supports: Point types 0x0102xx (buoys/beacons) can have: mkgmap:xt-foundation-colour (a colour name from list FC below) mkgmap:xt-light-colour (a colour name from list LC below) mkgmap:xt-light-type (a type name from list LT below) mkgmap:xt-period (optional period in secs (not limited to integer) Point types 0x0103xx (entities with depth/height) and 0x0104xx (obstructions) mkgmap:xt-depth (a depth with optional units (ft or m) default is m) mkgmap:xt-height (alias for, and mutually exclusive to, xt-depth) mkgmap:xt-position (an optional position from list P below) These attributes are turned into a sequence of bytes that are embodied in the map object. For testing purposes you can also specify those bytes explicitly as a sequence of hex digits using the mkgmap:xt-extra-bytes tag but you won't want to use that unless you are working on attribute value encoding (like me!) Next up will be lights which I understand how to encode except for multiple lights and angles - still working on that. Then will come lines and areas. All feedback welcome. BTW a good source of info is the cgpsmapper manual which is readily available on the net. It has a chapter on marine types. - List FC "red", "green", "yellow", "white", "black", "black-yellow", "white-red",
Re: [mkgmap-dev] mkgmap build process: how to apply patches
Hi Torsten, > I am trying to attend the mkgmap devellopment, but I have still some > trouble with the build process, partly because I am also not familiar > with the Linux environment. You don't have to use Linux. I do but other people use Windows or Macs. > As a start I installed Suse Linux and the Eclipse IDE. > > First step was downloading the source package from the mkgmap download > page, extracting this package into a folder, creating an ANT-project in > Eclipse and finally building mkgmap. Ok, this worked. > > Second step was using kdesvn and retrieving the sources from svn-trunk > via subversion instead of downloading the source package. On this > working copy I was again able to build mkgmap via an ANT-Eclipse-Project. > > But I haven't figured out yet, how to integrate a patch provided via > this list into my build process. Can anybody give me some advise, how to > use the patches? Patches can be applied using the "patch utility". The trick with patches is making the filenames that are in the patch, match the files in the current working directory (and below). In the simplest case, you can say (on the Linux command line) patch < patchfile. But often, it will complain that it can't find the patch and then you have to either change into a lower subdirectory, and/or use the -p option to patch to tell it to strip prefix directories from the patch filenames. E.g. patch -p1 < patchfile. I always make a new branch before I apply a patch someone has posted because then if it all goes wrong it doesn't affect my master branch or any of my development branches. If the patch is good, I can always merge it into other branches later. I don't use svn but git which makes all this branching/merging stuff stress free. E.g. git branch test-branch (make a new branch based on current branch) git checkout test-branch (check out new branch) patch -p1 < some-patch (apply the patch) test/edit/commit/etc. (frig around with patch till satisfied it's good) git checkout master (go back to master branch) git merge test-branch(merge in the test branch to master) I don't know about svn but git makes it very easy to have any number of branches which you can switch between in an instant and merge together. Also it's (generally) trivial to maintain development branches that can be "rebased" on top of the latest master branch so that as the master gets updated with new commits, you can update your development branches to incorporated those commits without losing the branch structure. And, of course, you have the full development history available all the time. I digress. 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] - support for extended type attributes
v4 - no functional change, just reworked slightly to improve efficiency. I've tested this stuff with noddy examples but as I don't expect anyone is in a great rush to use it big time, we will have to wait to see what issues emerge (from the deep?) Anyway, as all of this code should have no effect on map elements without extended types, I reckon it should be safe to commit. So unless anyone has any problems with that, I shall commit it later this week and then at least it's there for people to dabble with. If you do try it out, please report results. --- v3 - more tweaks to lights + lines & areas "morse" light type now takes the morse letter to flash, e.g. "morse A" lights can be tagged as having a "racon" (you'll have to google it like I did!) by setting mkgmap:xt-racon to yes. Depth areas (type 0x0103xx) can have the depth attribute and lines 0x010105 to 0x010107 (contour, overhead cable, bridge) can have height. There is a new mkgmap:xt-style attribute that takes a 16 bit value. The bottom 4 bits specify a colour and bits 8-14 specify a line style. See the cgpsmapper manual for the supported colours and styles. As an example, a value of 0x3004 means red line like this +++ This can be used on lines with types 0x0104xx, 0x0105xx and 0x0106xx. You can also use the xt-style (colour part only) attribute on points of type 0x010500 which are labels with coloured text. The point's name tag is shown on the map in the colour you specify. Could be useful. There's still a bit more that could be done on on the light flash sequence encoding but as it's rather unlikely that anyone will every want to use that, I'm not bothering for the moment. So, the job is pretty much done. As usual, all feedback is welcome. -- v2 - moving swiftly on. Added support for lights and reworked a few things. mkgmap:xt-foundation-colour is now just mkgmap:xt-colour mkgmap:xt-light-colour has been replaced with mkgmap:xt-light (more on this below) mkgmap:xt-light-type is now just mkgmap:xt-type Light colour, range (in nm) and angle is now specified with the mkgmap:xt-light tag - the values are just separated with commas, and only the colour is required for simple lights. All angles are in degrees. So, for example: mkgmap:xt-light=red (a red light) mkgmap:xt-light=red,5 (... visible at up to 5 nm) mkgmap:xt-light=red,5,172 (... sector starts at 172 degrees) The sector start angle only makes sense if you have multiple lights defined (separate light defs with one of /;:) - for example: mkgmap:xt-light=red,5,172/green,5,230/unlit,,300 you can add a text note, international designator or local designator to a buoy or light with: mkgmap:xt-note=hello world mkgmap:xt-int-desig=ABC mkgmap:xt-local-desig=XYZ These show up in the POI properties window in mapsource. There is also: mkgmap:xt-height-above-foundation (a height) mkgmap:xt-height-above-datum (a height) mkgmap:xt-leading-angle (an angle) you can now specify multiple period values to give a flash sequence but, unfortunately, it only encodes 2 values at the moment, the encoding for more than 2 values is yet to be discovered. The full range of light colours is now supported: "unlit", "red", "green", "white", "blue", "yellow", "violet", "amber" So, lights, buoys, obstructions are now fairly well catered for so it's probably time to look at lines and areas. Yo Landlubbers, Here's the first cut at encoding support for extended type attributes. This is mostly concerned with marine entities like (wreck depths, buoy types, light types, colours, etc.) As there is quite a lot of it and I haven't sussed it all out yet, I thought it would make sense to post patches as I go along so that people can try it out and find the bugs sooner rather than later. The attribute values are supplied as special tags with a mkgmap:xt- prefix. So, for example, mkgmap:xt-depth=40.6m specifies the depth of something (in metres). This first tranche supports: Point types 0x0102xx (buoys/beacons) can have: mkgmap:xt-foundation-colour (a colour name from list FC below) mkgmap:xt-light-colour (a colour name from list LC below) mkgmap:xt-light-type (a type name from list LT below) mkgmap:xt-period (optional period in secs (not limited to integer) Point types 0x0103xx (entities with depth/height) and 0x0104xx (obstructions) mkgmap:xt-depth (a depth with optional units (ft or m) default is m) mkgmap:xt-height (alias for, and mutually exclusive to, xt-depth) mkgmap:xt-position (an optional position from list P below) These attributes are turned into a sequence of bytes that are embodied in the map object. For testing purposes you can also specify those bytes explicitly as a sequence of hex digits using the mkgmap:xt-extra-bytes tag but you won't want to use that unless you are working on attribute value encoding (like me
Re: [mkgmap-dev] About buoys and lighthouses
Hi David, > It may be a surprise but colored lighthouses and morse code worked on > Etrex Vista HCx before you added extended types. I used only style rules > to obtain this map (see the capture). Yes, there's already some marine widgets in the non-extended types. But if you want the really funky lights (multiple colours/ranges/sectors, etc) then you need the extended jobs. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v1] - add support for turn restriction 'except' tag
As per OSM Wiki, it expects vehicle classes to be separated with ';'
Works in mapsource, not tried on a real GPS.
Doesn't appear to work for either pedestrians or emergency vehicles.
diff --git a/src/uk/me/parabola/imgfmt/app/net/RouteRestriction.java b/src/uk/me/parabola/imgfmt/app/net/RouteRestriction.java
index ee51bad..ba5691b 100644
--- a/src/uk/me/parabola/imgfmt/app/net/RouteRestriction.java
+++ b/src/uk/me/parabola/imgfmt/app/net/RouteRestriction.java
@@ -56,16 +56,27 @@ public class RouteRestriction {
// last restriction in a node
private boolean last;
+ // mask that specifies which vehicle types the restriction doesn't apply to
+ private final byte exceptMask;
+
+ public final static byte EXCEPT_CAR = 0x01;
+ public final static byte EXCEPT_BUS = 0x02;
+ public final static byte EXCEPT_TAXI = 0x04;
+ public final static byte EXCEPT_DELIVERY = 0x10;
+ public final static byte EXCEPT_BICYCLE = 0x20;
+ public final static byte EXCEPT_TRUCK= 0x40;
+
/**
* Create a route restriction.
*
* @param from The inverse arc of "from" arc.
* @param to The "to" arc.
*/
- public RouteRestriction(RouteArc from, RouteArc to) {
+ public RouteRestriction(RouteArc from, RouteArc to, byte exceptMask) {
assert from.getSource().equals(to.getSource()) : "arcs in restriction don't meet";
this.from = from;
this.to = to;
+ this.exceptMask = exceptMask;
}
private int calcOffset(RouteNode node, int tableOffset) {
@@ -82,7 +93,16 @@ public class RouteRestriction {
* @param tableOffset The offset in NOD 1 of the tables area.
*/
public void write(ImgFileWriter writer, int tableOffset) {
- writer.put3(HEADER);
+ int header = HEADER;
+
+ if(exceptMask != 0)
+ header |= 0x0800;
+
+ writer.put3(header);
+
+ if(exceptMask != 0)
+ writer.put(exceptMask);
+
int[] offsets = new int[3];
if (from.isInternal())
@@ -125,7 +145,10 @@ public class RouteRestriction {
* Size in bytes of the Table C entry.
*/
public int getSize() {
- return SIZE;
+ int size = SIZE;
+ if(exceptMask != 0)
+ ++size;
+ return size;
}
public void setOffsetC(int offsetC) {
diff --git a/src/uk/me/parabola/mkgmap/general/RoadNetwork.java b/src/uk/me/parabola/mkgmap/general/RoadNetwork.java
index 0c45d68..8506381 100644
--- a/src/uk/me/parabola/mkgmap/general/RoadNetwork.java
+++ b/src/uk/me/parabola/mkgmap/general/RoadNetwork.java
@@ -182,7 +182,7 @@ public class RoadNetwork {
return boundary;
}
- public void addRestriction(CoordNode fromNode, CoordNode toNode, CoordNode viaNode) {
+ public void addRestriction(CoordNode fromNode, CoordNode toNode, CoordNode viaNode, byte exceptMask) {
RouteNode fn = nodes.get(fromNode.getId());
RouteNode tn = nodes.get(toNode.getId());
RouteNode vn = nodes.get(viaNode.getId());
@@ -197,7 +197,7 @@ public class RoadNetwork {
assert fa != null : "can't locate arc from 'via' node to 'from' node";
assert ta != null : "can't locate arc from 'via' node to 'to' node";
- vn.addRestriction(new RouteRestriction(fa, ta));
+ vn.addRestriction(new RouteRestriction(fa, ta, exceptMask));
}
}
diff --git a/src/uk/me/parabola/mkgmap/reader/osm/RestrictionRelation.java b/src/uk/me/parabola/mkgmap/reader/osm/RestrictionRelation.java
index e00f677..6fafaa2 100644
--- a/src/uk/me/parabola/mkgmap/reader/osm/RestrictionRelation.java
+++ b/src/uk/me/parabola/mkgmap/reader/osm/RestrictionRelation.java
@@ -7,6 +7,7 @@ import java.util.Map;
import uk.me.parabola.imgfmt.app.Coord;
import uk.me.parabola.imgfmt.app.CoordNode;
+import uk.me.parabola.imgfmt.app.net.RouteRestriction;
import uk.me.parabola.log.Logger;
import uk.me.parabola.mkgmap.general.RoadNetwork;
@@ -28,6 +29,7 @@ public class RestrictionRelation extends Relation {
private CoordNode toNode;
private CoordNode viaNode;
private final List otherNodes = new ArrayList();
+ private byte exceptMask;
private final String messagePrefix;
/**
@@ -105,7 +107,6 @@ public class RestrictionRelation extends Relation {
restriction = getTag("restriction");
String[] unsupportedTags = {
- "except",
"day_on",
"day_off",
"hour_on",
@@ -115,6 +116,29 @@ public class RestrictionRelation extends Relation {
log.warn(messagePrefix + "ignoring unsupported '" + unsupportedTag + "' tag");
}
}
+
+ String except = getTag("except");
+ if(except == null)
+ except = getTag("exception"); // be nice
+ if(except != null) {
+ for(String e : except.split(";")) {
+e = e.trim();
+if(e.equals("motorcar") || e.equals("motorcycle"))
+ exceptMask |= RouteRestriction.EXCEPT_CAR;
+else if(e.equals("psv") || e.equals("bus"))
+ exceptMask |= RouteRestriction.EXCEPT_BUS;
+else if(e.equals("taxi"))
+ exceptMask |= RouteRestriction.EXCEPT_TAXI;
+else if(e.equals("delivery") || e.equals("goods"))
+ exceptMask |= RouteRestriction.EXCEPT_DELIVERY;
+else if(e.equals("bicycle"))
+ exceptMask |=
Re: [mkgmap-dev] Garmin Edge 705 bug in bicycle routing
Just a thought, is it related to the zoom level of the cycleway as set in the style file? What happens if you make the cycleway have the same zoom level as the road next to it? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] extended types and java buffer overflow
Hi Felix, > Using the same style-file as before but changing many streets from 0x?? > into 0xe10?? I needed to reduce by 70-75% the maxnodes settings of the > map so that it compiles without error. What error do you get? Please post the message. > Is there possibly a bug or is it normal that using extended types forces > you to use much smaller tiles? > Anyone already using the extended types and also seeing this problem? We're charting new territory here (ho ho), so anything is possible. > For some countries I needed to reduce maxnodes via splitter to 150.000 > so that they compile fine. Even Denmark ran well on 400.000 before. I am > a bit buffled about this. > > Overlays and Relations work fine now, I had forgotten about some patches > that I was using previously and stopped by upgrading to 1140. Good. Using extended types should not change the number of nodes or arcs but it does create extra data structures. So, please give more info about the error, it might just be a bug in the new code. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] extended types and java buffer overflow
Looks like the extended type stuff has triggered an ancient bug.
Please try attached patch and see if you can process bigger maps again.
diff --git a/src/uk/me/parabola/imgfmt/app/BufferedImgFileWriter.java b/src/uk/me/parabola/imgfmt/app/BufferedImgFileWriter.java
index 37d5509..b1d6fb2 100644
--- a/src/uk/me/parabola/imgfmt/app/BufferedImgFileWriter.java
+++ b/src/uk/me/parabola/imgfmt/app/BufferedImgFileWriter.java
@@ -175,8 +175,10 @@ public class BufferedImgFileWriter implements ImgFileWriter {
* @param length The amount of data.
*/
private void ensureSize(int length) {
- if (buf.position() +length > bufferSize - GUARD_SIZE) {
- bufferSize += GROW_SIZE;
+ int needed = buf.position() + length;
+ if (needed > (bufferSize - GUARD_SIZE)) {
+ while(needed > (bufferSize - GUARD_SIZE))
+bufferSize += GROW_SIZE;
if (bufferSize > 0xff) {
// Previous message was confusing people, although it is difficult to come
// up with something that is strictly true in all situations.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1146: Version 5 of the generate sea patch.
I notice that isClosed() uses equals() (the points have the same coords) but I think it should use == (the points are the same object). ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1146: Version 5 of the generate sea patch.
Furthermore, should isClosed() require the way to have at least 3 points? Otherwise, the enclosed area is going to be very thin! ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Possible maxspeed patch
Hi Mark, Thanks for the contribution - it sounds like a good idea. One thought, how about using words and not numbers, words are easier to interpret when you come back to them 3 months (5 minutes?) later. So you could have something like: ignore-maxspeeds (same meaning as now for compatibility but we could retire it in the future) but then have a new option that gives the flexibility you want: maxspeed=ignore(use speed defined in roadclass) maxspeed=heed (use maxspeed if defined, roadclass otherwise) maxspeed=lowest(use lowest of those speeds) maxspeed=highest (use highest of those speeds - why not?) Cheers, Mark -- > Here is a possible patch for maxspeed. > > Around here lots of roads have been tagged with their speed limit (which > is 60mph). However, these are unclassified roads and you are unlikely to > get above 40mph. At the moment the default behaviour of mkgmap is set > overide the style file for these roads and set the road class > appropriate to 60mph, which is too fast. > > I could turn on ignore-maxspeeds which would fix these roads but in turn > that would result in the trunk roads in town getting too high a speed. > > The patch attempts to overcome this by offerring an extra option for > ignore-maxspeed, so the options become > > [Default] - Use maxspeed if it exists, otherwise Road Class from the style > > "ignore-maxspeeds" - Use road class from the style file > "ignore-maxspeeds:0" - Use road class from the style file > "ignore-maxspeeds:1" - Use maxspeed from the style file > "ignore-maxspeeds:2" - Use the lower of road class and maxspeed > > Effectively option 2 solves my problem. The other numbered options are > there to reproduce existing behaviour using a number. The non-numbered > option is to keep compatiblity with existing code. > > > Note: > - This is the first patch I've done so I might have gone about it > completely the wrong way. If so I'm sorry and please give me some hints > - It is also the first Java code I've ever edited so I might have done > something wrong! All I can say is that it worked for me ! ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Possible maxspeed patch
Mark, > I'll change it. The original intention was to avoid creating another > option (as I'd seen some comment about "yet another option"). But I'm > happy to go down that route. Personally, i'd rather see a new option added than an old option obscured! Also, if we introduce a new option to provide what you want and it is still compatible with the current functionality, we can retire the old option after a while. If we decide to do that, we can make the old option print a warning along the lines of "this option will self destruct in 7 seconds". Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v5] - support for extended type attributes
v5 - added support for facility (point type 0x010903) and also now catches and reports exceptions incurred during processing of attributes. A facility point can have a mkgmap:xt-facilities attribute which is a bitmask made from these values: 0x01 boat ramp 0x02 drinking water 0x04 restrooms 0x08 picnic area 0x10 campground 0x20 marina 0x40 fuel 0x80 marine supply 0x000100 bait and tackle 0x000200 groceries 0x000400 restaurant 0x000800 water/electric hook-up 0x001000 boat/motor rental 0x002000 guide service 0x004000 lodging 0x008000 dump station 0x01 handicap accessible v4 - no functional change, just reworked slightly to improve efficiency. I've tested this stuff with noddy examples but as I don't expect anyone is in a great rush to use it big time, we will have to wait to see what issues emerge (from the deep?) Anyway, as all of this code should have no effect on map elements without extended types, I reckon it should be safe to commit. So unless anyone has any problems with that, I shall commit it later this week and then at least it's there for people to dabble with. If you do try it out, please report results. --- v3 - more tweaks to lights + lines & areas "morse" light type now takes the morse letter to flash, e.g. "morse A" lights can be tagged as having a "racon" (you'll have to google it like I did!) by setting mkgmap:xt-racon to yes. Depth areas (type 0x0103xx) can have the depth attribute and lines 0x010105 to 0x010107 (contour, overhead cable, bridge) can have height. There is a new mkgmap:xt-style attribute that takes a 16 bit value. The bottom 4 bits specify a colour and bits 8-14 specify a line style. See the cgpsmapper manual for the supported colours and styles. As an example, a value of 0x3004 means red line like this +++ This can be used on lines with types 0x0104xx, 0x0105xx and 0x0106xx. You can also use the xt-style (colour part only) attribute on points of type 0x010500 which are labels with coloured text. The point's name tag is shown on the map in the colour you specify. Could be useful. There's still a bit more that could be done on on the light flash sequence encoding but as it's rather unlikely that anyone will every want to use that, I'm not bothering for the moment. So, the job is pretty much done. As usual, all feedback is welcome. -- v2 - moving swiftly on. Added support for lights and reworked a few things. mkgmap:xt-foundation-colour is now just mkgmap:xt-colour mkgmap:xt-light-colour has been replaced with mkgmap:xt-light (more on this below) mkgmap:xt-light-type is now just mkgmap:xt-type Light colour, range (in nm) and angle is now specified with the mkgmap:xt-light tag - the values are just separated with commas, and only the colour is required for simple lights. All angles are in degrees. So, for example: mkgmap:xt-light=red (a red light) mkgmap:xt-light=red,5 (... visible at up to 5 nm) mkgmap:xt-light=red,5,172 (... sector starts at 172 degrees) The sector start angle only makes sense if you have multiple lights defined (separate light defs with one of /;:) - for example: mkgmap:xt-light=red,5,172/green,5,230/unlit,,300 you can add a text note, international designator or local designator to a buoy or light with: mkgmap:xt-note=hello world mkgmap:xt-int-desig=ABC mkgmap:xt-local-desig=XYZ These show up in the POI properties window in mapsource. There is also: mkgmap:xt-height-above-foundation (a height) mkgmap:xt-height-above-datum (a height) mkgmap:xt-leading-angle (an angle) you can now specify multiple period values to give a flash sequence but, unfortunately, it only encodes 2 values at the moment, the encoding for more than 2 values is yet to be discovered. The full range of light colours is now supported: "unlit", "red", "green", "white", "blue", "yellow", "violet", "amber" So, lights, buoys, obstructions are now fairly well catered for so it's probably time to look at lines and areas. Yo Landlubbers, Here's the first cut at encoding support for extended type attributes. This is mostly concerned with marine entities like (wreck depths, buoy types, light types, colours, etc.) As there is quite a lot of it and I haven't sussed it all out yet, I thought it would make sense to post patches as I go along so that people can try it out and find the bugs sooner rather than later. The attribute values are supplied as special tags with a mkgmap:xt- prefix. So, for example, mkgmap:xt-depth=40.6m specifies the depth of something (in metres). This first tranche supports: Point types 0x0102xx (buoys/beacons) can have: mkgmap:xt-foundation-colour (a colour name from list FC below) mkgmap:xt-light-colour (a colour name from list LC below)
Re: [mkgmap-dev] [PATCH] stop/continue scheme extended to style-rules without conversion
Hi Torsten, > And please let me know, whether the attached patch is usable, since this > is my first generated patch. I simply asked svn for the differences > between my local copy and the head version. I haven't tried the patch but a quick look shows that it attempts to add some stuff that is already in the trunk so that patch will not apply without grumbling. Are you sure your patch is generated against the current trunk? 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] stop/continue scheme extended to style-rules without conversion
Spotted the problem, some of the patch is relative to 1143 and some of it relative to 1148. Don't know how you managed that. Perhaps an svn wizard can help. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] stop/continue scheme extended to style-rules without conversion
> Ok, I tried a different button in svn and now got a patch relative 1143 > only. Is this one better usable? Yes, it applies to 1148 OK and builds OK. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v5] - min arc length fixes
v5 in case people are still using this patch, i have reissued it without the stuff that is now in commit 1152. if you are using this patch and think it should also be committed - please say - it didn't seem conclusive that is was useful when we last discussed it - v4 I have gone back to the original ordering of doing short arc removal before clipping as the previous version of this patch badly broke polygons As for arcs whose length is less 5m, I am not convinced they are actually a problem as far as routing is concerned as my tests show that mapsource can happily route through zero length arcs that occur at tile boundaries. It would be good if people who have been obliged to use a minimum arc length of > 0 would provide examples of where the routing is broken. i.e. without using this patch, find an example which doesn't route when --remove-short-arcs is specified but will route when --remove-short-arcs=5 is specified. What is still an issue and was discussed a while ago is the problem where routing will fail (or produce a big diversion) when routing out of one tile into another and then back to a destination in the first tile. That never seems to work, short arcs or not. v3 This patch is getting serious! To reduce the number of short arcs that are being generated at tile boundaries, this now clips the ways before the short arc removal is done. However, it isn't a perfect solution because some map data is very hard to deal with: a - If a way crosses a tile boundary right in the corner such that both ends are clipped and the resulting sub-way is less than 5m long, it will fail to fix that. A possible workaround could be to introduce extra points to elongate the arc. b - a much more common problem is where a way forks very close to a tile boundary and more than one of the connected ways cross the boundary so you end up with several boundary nodes that should be merged to remove the short arc(s) but they can't be moved as they are boundary nodes! I believe that this could be fixed by not merging the forking node but, instead, moving it away from the boundary such that the ways connected to it that do cross the boundary are not less than 5m long! Alternatively, adding extra points to elongate the forking arcs could be done. With this patch, I processed a 14 tile map of the Netherlands and it produced 21 of these short arc errors (all due to forks close to the tile boundaries). I then tested the routing at 5 of these positions (using mapsource) and only 1 of the 5 showed any sign of breakage, the other 4 all routed happily in all directions. The one that was broken was a junction of three ways and one pair of the ways had no connectivity but the others were ok. On the upside, the patch removed 147 short arcs introduced by the clipping. So more work is required here to fix the corner cases (ha ha) but please test this patch anyway as I expect it to have problems due to the big change it has introduced. As usual, all feedback is appreciated. v2 of this patch not only enables remove-short-arcs by default when routing is in use (as previously discussed on ML) but it also fixes some problems in the way splitting code. I would be grateful if people could test this patch because it could possibly cure some routing failures. Cheers, Mark diff --git a/resources/help/en/options b/resources/help/en/options index caa2d3e..b99d74b 100644 --- a/resources/help/en/options +++ b/resources/help/en/options @@ -187,11 +187,15 @@ Miscellaneous options: in which they appear in the OSM input. Without this option, the order in which the elements are processed is not defined. ---remove-short-arcs[=MinLength] - Merge nodes to remove short arcs that can cause routing - problems. If MinLength is specified (in metres), arcs shorter - than that length will be removed. If a length is not - specified, only zero-length arcs will be removed. +--remove-short-arcs (a) +--remove-short-arcs=MinLength (b) +--remove-short-arcs=no(c) + If routing is enabled, arcs shorter than 5m will be removed + to avoid routing problems. This behaviour can be modified with + this option. It has three variants: + (a) turn on short arc removal even if routing is not enabled. + (b) explicitly specify the minimum arc length (no 'm' suffix). + (c) completely disable short arc removal. --road-name-pois[=GarminCode] Generate a POI for each named road. By default, the POIs' diff --git a/src/uk/me/parabola/imgfmt/app/Coord.java b/src/uk/me/parabola/imgfmt/app/Coord.java index 5462602..3e47df7 100644 --- a/src/uk/me/parabola/imgfmt/app/Coord.java +++ b/src/uk/me/parabola/imgfmt/app/Coord.java @@ -20,6 +20,7 @@ import java.util.Formatter; import java.util.Locale; import uk.me.parabola.imgfmt.Utils; +import uk.me.parabola.imgfmt.app.net.RouteArc; /** * A point coordinate in unshifted map-units. @@ -101,6 +102,11 @@ public class Coord implements Comp
Re: [mkgmap-dev] [PATCH v5] - min arc length fixes
Hi, > If I understand you correctly, your v4 patch is in svn now, so if I run > into strange routing, I should report and/or check if v5 performs any > better? No, only a portion of the v4 patch has been committed because it's a useful fix to have independently of whether the rest of the patch is worthwhile. The v5 patch is like the v4 patch but should apply to 1152. > (In fact, I mainly run into perfectly working routing, my Garmin even > told me a *better* route for a track I'm riding every day for 1,5 years > now :) Very good. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --make-all-cycleways oddity
Hi Valentijn, > First, a remark. Since the oneway=yes/cycleway=opposite roads have > "(cycleway)" attached to their names, a GPS unit will randomly show > either the regular name, or the (cycleway) name. Which isn't too bad for > testing, I'd suggest you leave it this way until we're set and done with > it, because now you can see *why* a certain road is accessible or > inaccessible (i.e. it tells you where you're driving). Namely, here's > one occasion where it came in handy: Yes, that could be considered a "feature". > Yesterday I drove by car to one of those "cycleway=opposite" ways and to > my surprise, my Garmin told me to turn right to "Hembrugstraat > (cycleway)". I'm absolutely sure that the unit was set to "car" and not > bike. So is there a bug in the opposite-way-code? (Or is this the > strange idea of a Garmin that you can route the wrong way for some > meters??) I had another Garmin unit with me with a regular Garmin map, > that showed the right route; also, the route is nothing special, just > about this: > http://www.yournavigation.org/?flat=52.392997&flon=4.871082&tlat=52.391864&tlon=4.87679&v=motorcar&fast=1&layer=mapnik > > Any ideas? (I'll recheck the routing later on, to see if this will also > happen with positions further away in one-way-streets). I think that (at least with mapsource) the routing restrictions are considered "advisory" at times rather than absolute prohibitions. If you start a route close to a road that has a synthesised cycleway I can quite believe that the gps would "grab" the cycleway instead of the road. If it routes down the cycleway from another way and a road is also available at the same point, that's not good. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1140: Added support for extended types.
Hi Gert, > Hi, guys > first time with a prebuild version r1152 i tried to use this extended > type in an overlay. > Unfortunately i got an error message from mkgmap.( i can provide it if > needed but i guess it doesn't). > Input file was in polish-format. > Could it be that the polish format reader of mkgamp doesn't support the > description for extended types like > "Type=0x10500" Or "Type=0x010500" ? > Immediately replacing this with a standard type, mkgmap compiles my > mp-file without any complains. > > In case off... please could you implememt the extended type stuff and > anything else missing in the mkgmaps mp-file reader. I will look at adding the extended type support into the mp-file reader. I have to admit that my focus is always on the osm file stuff because I don't use mp files. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1140: Added support for extended types.
Hi Gert, I just took a quick look at the code and I can't see why extended types are not acceptable in mp files. Please post the error message you got. The extended type attributes are not yet supported for mp files but I will look at implementing that. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --make-all-cycleways oddity
Hi V, Yes, using mapsource, if the cycleway=opposite tag is present it will route a car into the last segment of Hembrugstraat using the cycleway but if the destination is not the last segment of that road or the cycleway tag is not present, it will route the car correctly. Experimentally, I split the last segment of that way to introduce a new new node and it behaved similarly i.e. it would route correctly right up to the last segment but when the dest was in the last segment it routed "arse about face" (as we say). Not at all sure where the problem is here - quite plausibly a bug in the Garmin routing engine. If so, perhaps we can work around 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] address search problem due to required "State" value
Hi Maning, > Several problems with Search by Address in Garmin Mobile XT reported > by some of my users. > > " - unable to search for road names via Address Search option using > Where to?" -> "Addresses" > -Step 1 0f 5 in Address Search requires entry of "State", no state is > listed and no matches found if the "Spell" option is used > -unable to proceed with the following Address Search steps because of > the said bug" > > In the Philippines and surely in other countries, we don't have "State". This is a known issue. Until the global index stuff is implemented I don't think it will be fixed. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] make-cycleways
Hi, > While looking into the make-cycleway-code, I notice that a simple tag > with "cycleway=lane" (or equivalent) would be enough to make a cycleway. > However, if there's no access restriction for cyclists, there's no real > need to build an extra way here - or is there? You have a point. Of course, an access restriction could be added later by the style rules but that's pretty unlikely? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] gui for areas.list ?
> > 3,295898,45,791016 > > Looks like a decimal point vs. comma problem. new Formatter(Locale.ENGLISH).format(...) ? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --make-all-cycleways oddity
Valentijn, > I've tried a couple of different methods to build opposite-cycleways, > namely forbid all motoring traffic, make a real cycleway, but all of > them make the Garmin turn to the last part of the oneway Hembrugstraat. > So I conclude it's a Garmin issue. I'm sure we could come up with all > sorts of nasty tricks to work around it, but I'd suggest we leave it > this way. OK, thanks for investigating that. For my own part, I tried pruning the last segment from the synthesised cycleway and, as expected, it stopped the bad behaviour in that the car routing never tried to do the right turn. However, as expected, it broke the cycle routing through the last segment. So I agree, we should leave it as is for the moment. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1153: Fix error reporting.
On Fri, 28 Aug 2009 14:11:41 +0100 (BST) svn commit wrote: > > Version 1153 was commited by steve on 2009-08-28 14:11:41 +0100 (Fri, 28 Aug > 2009) > > Fix error reporting. > > Normal errors that are detected by mkgmap should just be printed but since > multithreading was added, all errors dump out a stack trace. > Also unwrap any concurrent execution exception, so the actual problem > is at the top. > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev Arguably, this doesn't fix the error reporting at all. It just changes its "composition". No longer does it helpfully tell the user that specifying --keep-going would enable processing to continue (when multiple maps are being processed). Instead, it tells them it's continuing because the option has been given (which they knew anyway because they specified it!) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1140: Added support for extended types.
Gert, > >I just took a quick look at the code and I can't see why extended types > >are not acceptable in mp files. Please post the error message you got. > > Ok. here it is. > > D:\GPS\mkgmap-r1152>java -Xmx512m -jar mkgmap.jar -c wkr_options.txt *.mp > SCHWERWIEGEND (Main): java.util.concurrent.ExecutionException: > java.lang.NullPointerException > java.util.concurrent.ExecutionException: java.lang.NullPointerException Just committed a fix for this. You should be able to use extended types in mp files now. I shall work on the extended type attributes so that they are usable from mp files using the syntax described in the cgpsmapper documentation. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1140: Added support for extended types.
Hi Gert, > Thanks for this very fast help. You're welcome. > Though i'm able to build a version from svn, i will wait for the snapshot for > testing it. OK. > >I shall work on the extended type attributes so that they are usable > >from mp files using the syntax described in the cgpsmapper > >documentation. I have now done this but as you may not want to use them anyway, it's probably best if I just commit that stuff and if it turns out to have any issues, we can fix them later. But if you want to test a patch before it's committed, I can easily issue one. > Accidentally i just read it : do you still need a unlocked routable tile like > Metroguide? No, thanks. 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 v5] - min arc length fixes
Hi Garvan, > I spent some time testing short arcs and managed to find some routing > problems where mapsource will route in one direction but not in the > reverse direction. This looks like a mapsource bug to me, so I am > curious if it is seen with all versions of mapsource, or even if others > can reproduce it. I tested with version 6.13.7 of mapsource, and builds > 1143, 1155 and 1155 with the v5 patch of mkgmap. > > The test map is tiny, so you may have trouble finding it unless you use > the gdb file. Its someplace over Malaysia (N1 19.785 E103 28.403). Note > that the coordinates were very carefully chosen to select the maximum > length arc that demonstrated this problem. The length of the short-arc > shown in gpsmapedit is 5.4 m. Using 1155, routing in either direction using the points in route_error.gdb, it routed the short direction. When you load route_error.gdb into mapsource it does show the route going the long way but if i then ask it to recalculate the route it goes the short way. This is for car routing either shortest distance or quickest time. Mapsource 6.15.6 So, it appears to work Ok for me. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --make-all-cycleways oddity
Valentijn, > I was thinking: are the oneway street and the fake route interconnected > automatically? I know they share the nodes, is that the same as being > able to skip between them? > > I.e. is it: > > | | > +--++-++ a street > +--++-++ a street (cycleway) > | | > > ... or > > | | > +--..-+. a street > +--..-+. a street (cycleway) > | | > Effectively, it's the later. Although the cycleway and the road share the same points, unless a point is already a routing node because some other way shares the point, it will not be made into a routing node. You don't want the former because you would create many unwanted routeing nodes. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1140: Added support for extended types.
Hi Gert, > I just run a small test. > r1155 you commited now seems to work fine with polish format datafiles and > extended Garmin types. Good. > Upcoming commited version of extended types + attributes i will test after it > is available. I shall commit that stuff soon as although it probably isn't perfect, any bugs there should not break anything else (and can be fixed as they surface) Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1157: Added support for extended type attributes in mp files.
Hi Gert, > i just build mkgmap out of svn trunk and test it with a single > marine/ext poi in an mp-file. > It works. Good. > But i discovered that neither the flashing nor the morsing works in > Mapsource or in my 60csx . I guess these functions are only avaiable > with special marine gps of Garmin. No, they should certainly be visible in mapsource (I am using 6.15.6). My etrex also does show marine stuff. So if you are using a recent mapsource and stuff isn't showing up, perhaps I have made a mistake and something needs fixing? The morse and flash info only shows up in mapsource if you look at the POI properties dialog. > A nice enhancement is the "note=" or "mkgmap:xt-note". I got up to 200 > signs in this container displayed on my 60csx. OK. > This is more as double of what you can normally put in "StreetDesc=" of > a POI.(sorry i don't know the tag in osm. In Mapedit you can write it in > the objekt properties=>Address=>Street and in the mp-file it is the > "StreetDesc=" entry). Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1157: Added support for extended type attributes in mp files.
Hi Gert, On Sun, 30 Aug 2009 17:00:33 +0200 Gert Münzel wrote: > Hi, Mark > > >>/ But i discovered that neither the flashing nor the morsing works in > />>/ Mapsource or in my 60csx . I guess these functions are only avaiable > />>/ with special marine gps of Garmin. > /Sorry, my statement was not clear. > I meant that i don't see any flashing or morsing (flashing or beeping) in GPS > or MS. > > >No, they should certainly be visible in mapsource (I am using 6.15.6). > >My etrex also does show marine stuff. So if you are using a recent > >mapsource and stuff isn't showing up, perhaps I have made a mistake and > >something needs fixing? > > They are visible in MS and in my 60csx too, so mkgmap works fine. Good. > >The morse and flash info only shows up in mapsource if you look at the > >POI properties dialog. > > Yeah i've already seen this like the note. > But as i mentioned above, i thought, that may be their would be really a > flashing light visible. > But may be this works only with special Garmin marine Gps or it is a > missunderstanding by myself of cgpsmapper manual. > My interpretation of e.g. page 40 cgpsmapper manual Ver 2.4.5 > "If the value is a letter, then the light type is set to 0x0b(Morse code) and > letter is used as a Morse code letter." > was, that then the light is flashing in GPS and/or MS with this code and not > "only" an information written in the poi properties > section. My understanding is that the flash info and the morse letter will be displayed by mapsource/gps when you query the POIs properties. It just tells you the info, it doesn't actually flash (or beep). Shame really, that would be very entertaining! Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Can you set background colour in a TYP file?
Hi, Just playing around with TYP files and wondered if it is possible to change the "Garmin yellow" background to anything else using a TYP file? If not, is there any other way of doing that? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Can you set background colour in a TYP file?
Hi Felix, > yes, simply set background polygon 0x4b to a color (if using maptk watch > out to set one pixel to something else, because usually if you go for a > single color only maptk will put second color transparent and > performance sucks, this is a bug in maptk, the online typfile editor is > fine in this regard). > I like white (best contrast). > Black would be good only for maps used primarily at night, because you > might save battery power, but readability is in my eyes still better > with white. Thanks for the quick response. I tried doing that using http://ati.land.cz/gps/typdecomp/editor.cgi but it doesn't make any difference. What drawing level and color mode should I be using? The other stuff in the TYP file (all line defs) appears to work fine. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
