[mkgmap-dev] [PATCH v3] make DP filter avoid removing points located at nodes
v3 - hopefully, now works again after being broken by the round coords
filter.
-
v2 - based on r1402.
---
Hi Felix,
Please try the attached patch. I've tested it inasmuch that it doesn't
blow up but whether it actually does the right thing when you have a
routable and non-routable way from the same set of points, I don't know.
Cheers,
Mark
diff --git a/src/uk/me/parabola/imgfmt/app/Coord.java b/src/uk/me/parabola/imgfmt/app/Coord.java
index 335284d..788f058 100644
--- a/src/uk/me/parabola/imgfmt/app/Coord.java
+++ b/src/uk/me/parabola/imgfmt/app/Coord.java
@@ -39,6 +39,7 @@ public class Coord implements Comparable {
private final int longitude;
private byte highwayCount; // number of highways that use this point
private boolean onBoundary; // true if point lies on a boundary
+ private boolean locatedAtNode; // true if point is located at a routing node
/**
* Construct from co-ordinates that are already in map-units.
@@ -90,6 +91,14 @@ public class Coord implements Comparable {
this.onBoundary = onBoundary;
}
+ public boolean locatedAtNode() {
+ return locatedAtNode;
+ }
+
+ public void locatedAtNode(boolean locatedAtNode) {
+ this.locatedAtNode = locatedAtNode;
+ }
+
public int hashCode() {
return latitude+longitude;
}
diff --git a/src/uk/me/parabola/imgfmt/app/CoordNode.java b/src/uk/me/parabola/imgfmt/app/CoordNode.java
index ebcfd58..1207e55 100644
--- a/src/uk/me/parabola/imgfmt/app/CoordNode.java
+++ b/src/uk/me/parabola/imgfmt/app/CoordNode.java
@@ -24,8 +24,6 @@ package uk.me.parabola.imgfmt.app;
*/
public class CoordNode extends Coord {
private final long id;
- //private int roadCount;
- private final boolean boundary;
/**
* Construct from co-ordinates that are already in map-units.
@@ -38,14 +36,11 @@ public class CoordNode extends Coord {
public CoordNode(int latitude, int longitude, long id, boolean boundary) {
super(latitude, longitude);
this.id = id;
- this.boundary = boundary;
+ setOnBoundary(boundary);
+ locatedAtNode(true);
}
public long getId() {
return id;
}
-
- public boolean isBoundary() {
- return boundary;
- }
}
diff --git a/src/uk/me/parabola/imgfmt/app/net/RouteNode.java b/src/uk/me/parabola/imgfmt/app/net/RouteNode.java
index b8ffdcc..4ea1e03 100644
--- a/src/uk/me/parabola/imgfmt/app/net/RouteNode.java
+++ b/src/uk/me/parabola/imgfmt/app/net/RouteNode.java
@@ -80,7 +80,7 @@ public class RouteNode implements Comparable {
public RouteNode(Coord coord) {
this.coord = (CoordNode) coord;
nodeId = nodeCount++; // XXX: take coord.getId() instead?
- setBoundary(this.coord.isBoundary());
+ setBoundary(this.coord.getOnBoundary());
}
private boolean haveLargeOffsets() {
diff --git a/src/uk/me/parabola/mkgmap/filters/DouglasPeuckerFilter.java b/src/uk/me/parabola/mkgmap/filters/DouglasPeuckerFilter.java
index 9a9c141..513bf2f 100644
--- a/src/uk/me/parabola/mkgmap/filters/DouglasPeuckerFilter.java
+++ b/src/uk/me/parabola/mkgmap/filters/DouglasPeuckerFilter.java
@@ -79,7 +79,7 @@ public class DouglasPeuckerFilter implements MapFilter {
// If a node in the line use the douglas peucker algorithm for upper segment
// TODO: Should consider only nodes connected to roads visible at current resolution.
- if (p instanceof CoordNode) {
+ if (p.locatedAtNode()) {
douglasPeucker(coords, i, endIndex, maxErrorDistance);
endIndex = i;
}
diff --git a/src/uk/me/parabola/mkgmap/filters/RoundCoordsFilter.java b/src/uk/me/parabola/mkgmap/filters/RoundCoordsFilter.java
index 2cdb95b..c5d4223 100644
--- a/src/uk/me/parabola/mkgmap/filters/RoundCoordsFilter.java
+++ b/src/uk/me/parabola/mkgmap/filters/RoundCoordsFilter.java
@@ -53,7 +53,7 @@ public class RoundCoordsFilter implements MapFilter {
int lon = (p.getLongitude() + half) & mask;
Coord newP;
if(p instanceof CoordNode)
- newP = new CoordNode(lat, lon, ((CoordNode)p).getId(), ((CoordNode)p).isBoundary());
+ newP = new CoordNode(lat, lon, ((CoordNode)p).getId(), p.getOnBoundary());
else
newP = new Coord(lat, lon);
// only add the new point if it has different
@@ -65,6 +65,14 @@ public class RoundCoordsFilter implements MapFilter {
newPoints.add(newP);
lastP = newP;
}
+else if(newP.locatedAtNode()) {
+ // this point is not going to be used because it
+ // has the same (rounded) coordinates as the last
+ // node but it has been marked as being located at
+ // a node so transfer that property to the
+ // previous point so that it's not lost
+ lastP.locatedAtNode(true);
+}
}
if(newPoints.size() > 1) {
newLine.setPoints(newPoints);
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 549b1bf..158118d 100644
--- a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
+++ b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
@@ -
Re: [mkgmap-dev] Style-file repository?
I have made custom styles and typ for my OSM Philippine maps and would be happy to share them and learn from others as well. Some shots: http://epsg4253.wordpress.com/2009/09/12/new-osm-ph-garmin-map-release-sept-200909/ http://epsg4253.wordpress.com/2009/11/14/new-osm-ph-garmin-map-release-nov-2009/ All icons from my minimal.typ are public domain. On Fri, Nov 27, 2009 at 8:17 AM, Greg Troxel wrote: > > Marko Mäkelä writes: > >> I think that the default style should still be maintained. There is some >> value in having sensible defaults. I do see value in other styles and >> hacks, such as distinguishing different types of paths by drawing multiple >> lines per way or repurposing taxi/delivery/emergency flags for custom >> bicycle routing, but I would keep the default style bare-bones. > > Agreed. The default is close to that - what a 'normal' user would want. > >> I must say that I have not played with other styles than the default. >> Is it possible to include the definitions of another style by reference >> and override them? That would allow improvements in the default style >> to be automatically applied to other styles. In that way, custom styles >> would be easier to maintain and understand, as they would not copy large >> amounts of definitions from other styles. > > At least mostly, maybe totally. See resources/styles/noname. > >> Agreed. But I think that we should have the files in an editable format >> (a text file that is converted to binary TYP by a simple program) and the >> origin and the copyright information of every icon has to be clearly >> documented. > > There seems to be perl code to run as cgi that does text/typ, so it > should be possible to turn this into something that can checked in and > part of the build, or of mkgmap. > > > Long term, it would be cool to have a design for a joint style file and > TYP file that maps OSM objects to codepoints beyond what base garmin can > do and then makes those codepoints show up sensibly with a TYP file. > This is currently beyond what I grasp. > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > -- cheers, maning -- "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] patch (V8) for simplifying ways and reducing img size
I wanted to apply it but I get "The chunk size did not match the number of added/removed lines!" Is there possibly something wrong with Patch V8? Johann Gail wrote: Patch V8 updated to r1404. - do not merge lines at resolution 24, as the dp filter is disabled. With this change there should be no longer routing problems. --- Patch V7 is now based on the R1041 (and the SizeFilter.patch) - removing of the -- suppress-dead-end-nodes option, as it causes problems with routing. - code cleanup, introduction of new classes. --- Patch V4 now supports three options. Its build on top of r972. With all three options used, it will reduce the four bavaria tiles from 58MB to 46MB. Drawing at low zoom levels gets speed up significantly at my etrex. This will not be the last version of the patch. I'm working further on it, but have no idea, how fast work will progress. The options are as follows: +--reduce-point-density=num +Simplifies the ways with the douglas peucker algorithm. +num is the maximal allowed error distance, by which the resulting +way may differ from the original one. +This distance gets shifted with lower zoom levels. +Recommended setting is 10, this should lead to only small differences +(Default is 2.6, which should lead to invisible changes) + +-- suppress-dead-end-nodes +Do not generate nodes at the end of an dead end way. +Decrease file size and should speed up routing slightly. +May possibly cause errors, but not seen any one at the moment. + +--merge-lines +Try to merge lines. This helps the simplify filter to straighten out +longer chunks at lower zoom levels. Decreases file size more. +Increases paint speed at low zoom levels . ___ 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] Style-file repository?
Marko Mäkelä writes: > I think that the default style should still be maintained. There is some > value in having sensible defaults. I do see value in other styles and > hacks, such as distinguishing different types of paths by drawing multiple > lines per way or repurposing taxi/delivery/emergency flags for custom > bicycle routing, but I would keep the default style bare-bones. Agreed. The default is close to that - what a 'normal' user would want. > I must say that I have not played with other styles than the default. > Is it possible to include the definitions of another style by reference > and override them? That would allow improvements in the default style > to be automatically applied to other styles. In that way, custom styles > would be easier to maintain and understand, as they would not copy large > amounts of definitions from other styles. At least mostly, maybe totally. See resources/styles/noname. > Agreed. But I think that we should have the files in an editable format > (a text file that is converted to binary TYP by a simple program) and the > origin and the copyright information of every icon has to be clearly > documented. There seems to be perl code to run as cgi that does text/typ, so it should be possible to turn this into something that can checked in and part of the build, or of mkgmap. Long term, it would be cool to have a design for a joint style file and TYP file that maps OSM objects to codepoints beyond what base garmin can do and then makes those codepoints show up sensibly with a TYP file. This is currently beyond what I grasp. pgpXSp97sGoWN.pgp Description: PGP signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] make DP filter avoid removing points located at nodes
Mark Burton wrote: Hi Johann, I have now looked into the code and must say, I don't understand why it works. Previous for each node was created a CoordNode. Now instead a flag is set. I see the difference: The flag is copied, the class obviously not. But I didn't find the place, where this copy occurs. Could you point my nose to the file and line number, where the line is duplicated? The only place I found is in the round coord filter class (line 55), where it is handled correctly. So why your patch works as expected and the original solution not?? As I said in a previous posting on this topic: mb> Whenever a routable way gets split to limit the number of points or mb> nodes it makes a new list of points so any changes to the points in the mb> new list will not be visible in the original list. So, wherever you see splitWay() that's where the "copying" occurs. I have another idea of solving this problem. Instead of do a new Coord or CoordNode call coord.copy(). The function could be overwritten in the CoordNode class to return a CoordNode object. (BTW. This should be done in the CoordPOI class too). So a copied line should contain afterwards the same types as the original. Doesn't the suggested patch do the job? (Felix, you reported it wasn't working, is that still the case?) Well since introducing the round-cords it is not working for me anymore. nothing changed here. Actually, I'm not keen on the CoordNode thing at all but it works well enough to not warrant spending effort on it while there is so much other stuff to be fixed. 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
Re: [mkgmap-dev] [Ghost road]
Hi Stéphane > Actually I'm working on a project for a little island. > When I convert the .osm file in .img, I get a little road in the .img > that doesn't appear on the .osm. > I'm in trouble... Someone has an idea ? It might be a ghost road but we're not psychic, you need to tell us more. How about the OSM URL of the road and some info about the options you are using, etc. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] DP Filter and areas at Resolution=24
> One idea for rounding at that level: > > Most annoying is that rectangles that are buildings aren't rectangles anymore > after rounding. As the OSM data in itself probably isn't accurate at the 2 m > level perhaps we could do "tweak" the coordinates so that rectangles stay > rectangles (I know, the projection has an influence as well)? This would make > the maps much better looking. > > Any thoughts about that? > > Just thinking about it: For lines the rounding is simply done by setting the coord to the nearest garmin unit by distance. For polygons (and maybe even for lines) not the nearest garmin unit should be choosen, but the garmin unit, which has the smallest changes to the angle. So the least influence to the outline should be achieved. An possible algorithm could be: foreach point in the polygon do: calculate the real angle (with unrounded coords!) round coordinates to the upper left garmin unit, calculate angle a1 round coordinates to the lower left garmin unit, calculate angle a2 round coordinates to the upper right garmin unit, calculate angle a3 round coordinates to the lower right garmin unit, calculate angle a4 choose the coordinate with the least difference to the real angle. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [Ghost road]
Hi folks, Actually I'm working on a project for a little island. When I convert the .osm file in .img, I get a little road in the .img that doesn't appear on the .osm. I'm in trouble... Someone has an idea ? thx Steph. Mark Burton a écrit : > Hi Clinton, > > >> I (casually) tested this patch on a Nuvi 255w today: I did not notice any >> harm done to the routing at least. Since I don't have a standard set of >> tests, I can't report if the patch has made any improvements. >> > > Thanks for trying it. Unless any -ve reports appear in the next day or > so, I think it's safe to commit. > > 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
Re: [mkgmap-dev] weird: file missing when # of files > 10?
Hi Valentijn, > Now I'm stumped. Would anyone know what's going on here? I thought of a > race condition and removed the --max-jobs option, but that makes no > difference. I think you're right. It's a race between the stuff in CommandArgsReader that updates mapname and the map making code in Main, etc. I believe the fundamental problem is that the value of the mapname option gets read in the work thread which is asynchronous to the command args processing stuff that is updating the value of mapname (and other stuff probably). This will happen even if when only a single thread is in use (it's still asynchronous). Nasty, I will work on a fix - stay tuned. 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] Fix Nuvi routing regression (rebloat Table A)
Hi Clinton, > I (casually) tested this patch on a Nuvi 255w today: I did not notice any > harm done to the routing at least. Since I don't have a standard set of > tests, I can't report if the patch has made any improvements. Thanks for trying it. Unless any -ve reports appear in the next day or so, I think it's safe to commit. 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] make DP filter avoid removing points located at nodes
Johann, On Thu, 26 Nov 2009 23:53:58 +0100 Johann Gail wrote: > > > As I said in a previous posting on this topic: > > > > mb> Whenever a routable way gets split to limit the number of points or > > mb> nodes it makes a new list of points so any changes to the points in the > > mb> new list will not be visible in the original list. > > > > So, wherever you see splitWay() that's where the "copying" occurs. > > > > > Maybe it is too late in the evening for me to understand the problem. > In the splitWay() the line is splitted. Yes, a new list is > generated. But the points inside it are moved from one list to another. > There is no new Coord(). So a CoordNode stays a CoordNode. Yes, it would stay a CoordNode if it was a CoordNode at the time the line was split. But, Coord->CoordNode transformation happens after all the splitting has occurred. So at the time the lines are split, all Coords are Coords! 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] make DP filter avoid removing points located at nodes
> As I said in a previous posting on this topic: > > mb> Whenever a routable way gets split to limit the number of points or > mb> nodes it makes a new list of points so any changes to the points in the > mb> new list will not be visible in the original list. > > So, wherever you see splitWay() that's where the "copying" occurs. > > Maybe it is too late in the evening for me to understand the problem. In the splitWay() the line is splitted. Yes, a new list is generated. But the points inside it are moved from one list to another. There is no new Coord(). So a CoordNode stays a CoordNode. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] DP Filter and areas at Resolution=24
One idea for rounding at that level: Most annoying is that rectangles that are buildings aren't rectangles anymore after rounding. As the OSM data in itself probably isn't accurate at the 2 m level perhaps we could do "tweak" the coordinates so that rectangles stay rectangles (I know, the projection has an influence as well)? This would make the maps much better looking. Any thoughts about that? Regards Thilo Am 26.11.2009 um 11:47 schrieb Johann Gail: > > > Felix Hartmann schrieb: >> >> >> Mark Burton wrote: >>> Hi Felix, >>> >>> Could the DP Filter not remove any points at resolution=24? >>> >>> It doesn't do anything at that res. > At the moment it does nothing, but I'm not sure, if it SHOULD do > something at this level, as there may be well some points to delete. >>> >>> Yes, the reason is that the coordinates round to approx the nearest 2m. >>> We can't do anything about that, it's what Garmin support. >>> >> okay I see. So the only real solution would be to have intelligent >> filters moving the nodes to nearest 2m in such a way that there is >> minimal loss of detail. Probably pretty CPU intensive and a lot of work. >> So we have to live with it, in most places there is no real loss of >> information anyhow. > I have thought of some ways to merge the rounding filter and the dp > filter for this reason. Mabe the dp filter should take into account the > distance to rounded coordinates, not the real one. Or maybe it would be > better to insert the rounding filter AFTER the dp filter. It may be > possible to achive a little improvement, but I doubt it. > The main reason is the limitation of resolution to 2m. > > Regards, > Johann > ___ > 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] [PATCH v2] Fix Nuvi routing regression (rebloat Table A)
On Nov 26, 2009, at 1:08, Mark Burton wrote: > v2 - now does nothing more (or less) than revert commits 1228 and 1373. I (casually) tested this patch on a Nuvi 255w today: I did not notice any harm done to the routing at least. Since I don't have a standard set of tests, I can't report if the patch has made any improvements. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Map end user documentation?
On Nov 26, 2009, at 11:45, Marko Mäkelä wrote: > I translated http://www.polkupyoraily.net/osm/ into English and German. > Any suggestions for improvement are welcome, as are and any translations > for minority languages spoken in Finland: se, sv, et, ru at least. Thanks for providing this. I'll take a more detailed look at the information later. I did notice, however, that in the English translation, the last paragraph is in German. ;-) Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] make DP filter avoid removing points located at nodes
Hi Johann, > I have now looked into the code and must say, I don't understand why it > works. Previous for each node was created a CoordNode. Now instead a > flag is set. I see the difference: The flag is copied, the class > obviously not. > But I didn't find the place, where this copy occurs. Could you point my > nose to the file and line number, where the line is duplicated? The only > place I found is in the round coord filter class (line 55), where it is > handled correctly. > So why your patch works as expected and the original solution not?? As I said in a previous posting on this topic: mb> Whenever a routable way gets split to limit the number of points or mb> nodes it makes a new list of points so any changes to the points in the mb> new list will not be visible in the original list. So, wherever you see splitWay() that's where the "copying" occurs. > I have another idea of solving this problem. > Instead of do a new Coord or CoordNode call coord.copy(). The function > could be overwritten in the CoordNode class to return a CoordNode > object. (BTW. This should be done in the CoordPOI class too). So a > copied line should contain afterwards the same types as the original. Doesn't the suggested patch do the job? (Felix, you reported it wasn't working, is that still the case?) Actually, I'm not keen on the CoordNode thing at all but it works well enough to not warrant spending effort on it while there is so much other stuff to 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] [PATCH] patch (V8) for simplifying ways and reducing img size
Patch V8 updated to r1404.
- do not merge lines at resolution 24, as the dp filter is disabled.
With this change there should be no longer routing problems.
---
Patch V7 is now based on the R1041 (and the SizeFilter.patch)
- removing of the -- suppress-dead-end-nodes option, as it causes
problems with routing.
- code cleanup, introduction of new classes.
---
Patch V4 now supports three options.
Its build on top of r972. With all three options used, it will reduce
the four bavaria tiles from 58MB to 46MB. Drawing at low zoom levels
gets speed up significantly at my etrex.
This will not be the last version of the patch. I'm working further on
it, but have no idea, how fast work will progress.
The options are as follows:
+--reduce-point-density=num
+Simplifies the ways with the douglas peucker algorithm.
+num is the maximal allowed error distance, by which the resulting
+way may differ from the original one.
+This distance gets shifted with lower zoom levels.
+Recommended setting is 10, this should lead to only small differences
+(Default is 2.6, which should lead to invisible changes)
+
+-- suppress-dead-end-nodes
+Do not generate nodes at the end of an dead end way.
+Decrease file size and should speed up routing slightly.
+May possibly cause errors, but not seen any one at the moment.
+
+--merge-lines
+Try to merge lines. This helps the simplify filter to straighten out
+longer chunks at lower zoom levels. Decreases file size more.
+Increases paint speed at low zoom levels
.
Index: src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
===
--- src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (Revision 1404)
+++ src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (Arbeitskopie)
@@ -55,6 +55,7 @@
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.util.EnhancedProperties;
import uk.me.parabola.mkgmap.reader.polish.PolishMapDataSource;
/**
@@ -143,7 +144,7 @@
}
};
- public StyledConverter(Style style, MapCollector collector, Properties props) {
+ public StyledConverter(Style style, MapCollector collector, EnhancedProperties props) {
this.collector = collector;
nameTagList = style.getNameTagList();
Index: src/uk/me/parabola/mkgmap/build/MapBuilder.java
===
--- src/uk/me/parabola/mkgmap/build/MapBuilder.java (Revision 1404)
+++ src/uk/me/parabola/mkgmap/build/MapBuilder.java (Arbeitskopie)
@@ -57,6 +57,7 @@
import uk.me.parabola.mkgmap.filters.DouglasPeuckerFilter;
import uk.me.parabola.mkgmap.filters.FilterConfig;
import uk.me.parabola.mkgmap.filters.LineSplitterFilter;
+import uk.me.parabola.mkgmap.filters.LineMergeFilter;
import uk.me.parabola.mkgmap.filters.MapFilter;
import uk.me.parabola.mkgmap.filters.MapFilterChain;
import uk.me.parabola.mkgmap.filters.PolygonSplitterFilter;
@@ -107,6 +108,10 @@
private String countryAbbr = "ABC";
private String regionName;
private String regionAbbr;
+
+ private double reducePointError;
+ private boolean mergeLines;
+
private int locationAutofillLevel;
private boolean poiAddresses = true;
private int poiDisplayFlags;
@@ -126,6 +131,8 @@
countryAbbr = props.getProperty("country-abbr", countryAbbr);
regionName = props.getProperty("region-name", null);
regionAbbr = props.getProperty("region-abbr", null);
+ reducePointError = props.getProperty("reduce-point-density", 2.6);
+ mergeLines = props.containsKey("merge-lines");
makePOIIndex = props.getProperty("make-poi-index", false);
@@ -866,11 +873,19 @@
FilterConfig config = new FilterConfig();
config.setResolution(res);
+
+ //TODO: Maybe this is the wrong place to do merging.
+ // Maybe more efficient if merging before creating subdivisions.
+ if (mergeLines && res < 24) {
+ LineMergeFilter merger = new LineMergeFilter();
+ lines = merger.merge(lines);
+ }
+
LayerFilterChain filters = new LayerFilterChain(config);
if (enableLineCleanFilters && (res < 24)) {
filters.addFilter(new RoundCoordsFilter());
filters.addFilter(new SizeFilter());
- filters.addFilter(new DouglasPeuckerFilter(FILTER_DISTANCE));
+ filters.addFilter(new DouglasPeuckerFilter(reducePointError));
}
filters.addFilter(new LineSplitterFilter());
filters.addFilter(new RemoveEmpty());
@@ -909,7 +924,7 @@
filters.addFilter(new SizeFilter());
//DouglasPeucker behaves at the moment not really optimal at low zooms, but acceptable.
//Is there an similar algorithm for polygons?
- filters.addFilter(new DouglasPeuckerFilter(FILTER_DISTANCE));
+ filters.addFilter(new DouglasPeuckerFilter(reducePointError));
}
filters
Re: [mkgmap-dev] [PATCH v1] make DP filter avoid removing points located at nodes
>>> So in my opinion the error is in the copy function of the line. If a >>> line contains CoordNodes, than also the copy should contain >>> CoordNodes. Can you point me to the code, where the lines gets >>> duplicated? >>> >> >> Whenever a routable way gets split to limit the number of points or >> nodes it makes a new list of points so any changes to the points in the >> new list will not be visible in the original list. >> > Yes, its true that changes in the copy will not be visible in the > original. But this is not my point. My point is: If the original line > contains CoordNodes (instead of Nodes) then the copy should also > contain CoordNodes. > I think, this will complicate the split/copy functions in some ways, > so maybe your solution is the easier way. I have now looked into the code and must say, I don't understand why it works. Previous for each node was created a CoordNode. Now instead a flag is set. I see the difference: The flag is copied, the class obviously not. But I didn't find the place, where this copy occurs. Could you point my nose to the file and line number, where the line is duplicated? The only place I found is in the round coord filter class (line 55), where it is handled correctly. So why your patch works as expected and the original solution not?? I have another idea of solving this problem. Instead of do a new Coord or CoordNode call coord.copy(). The function could be overwritten in the CoordNode class to return a CoordNode object. (BTW. This should be done in the CoordPOI class too). So a copied line should contain afterwards the same types as the original. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] weird: file missing when # of files > 10?
Hi list, I wrote about this before: my first map in the mapset, 63240001.img, is missing. I tracked this down to revision r1363 (which is a merge from the mapset branch) and today even further tracked it down to revision 1323 within the (deleted) mapset branch. However, I can't find any clues in r1323 as to what causes this. Further experiments showed even weirder results: as I compile my maps from a template.args file, it showed that having 63240001-63240009 in there would give me the correct map; having a 10th file in there made the first one missing. (Currently, while compiling the Netherlands, my template.args file has 14 entries. Any number above 9 makes the first one disappear). And indeed, when I duplicated the first file like so: mapname: input-file: 63240001.osm.gz mapname: 63240001 input-file: 63240001.osm.gz mapname: 63240002 [...] ... the map would be correct (with the void probably missing, and 63240001 included). Now I'm stumped. Would anyone know what's going on here? I thought of a race condition and removed the --max-jobs option, but that makes no difference. Best regards, Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Log-File for mkgmap-processing
On Thu, Nov 26, 2009 at 01:56:53PM +0100, Jan Tappenbeck wrote: > hi marko! > > that is the think i search but. > > when i used > > java -Xmx1024M -ea -Dlog.config=logging.properties -jar > D:\DATEN\JAN\openstreetmap\mkgmap-GarminKartenGenerieren2009\mkgmap.jar > --style-file=D:\DATEN\JAN\openstreetmap\mkgmap_st. > > i get following message: > "Failed to open logging config file logging.properties" Did you download the file http://www.polkupyoraily.net/osm/files/logging.properties to the current directory? > and where i had to put ".level=FINE " To the file logging.properties that you were supposed to download. :-) Best regards, Marko > !!! i used windows vista It should make no difference in this case. Best regards, Marko > > regards Jan :-) > > > Marko Mäkelä schrieb: > > On Thu, Nov 26, 2009 at 01:17:11PM +0100, Jan Tappenbeck wrote: > >> is there a possiblity to get a log-report for the steps of > >> mkgmap-processing ??? > >> > >> the result is empty so i want to find the reason. > > > > I am not sure if this is what you mean, but at > > http://www.polkupyoraily.net/osm/ > > you can find a logging.properties file that enables some > > printout to the file mkgmap.log.0 when you invoke mkgmap like this: > > > > java -ea -Dlog.config=logging.properties -jar mkgmap.jar > > > > You may want to set the default level to .level=FINE to see everything. > > That logging.properties file is based on something that was posted on > > this list earlier. > > > > Best regards, > > > > Marko > > ___ > 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] Log-File for mkgmap-processing
hi marko! that is the think i search but. when i used java -Xmx1024M -ea -Dlog.config=logging.properties -jar D:\DATEN\JAN\openstreetmap\mkgmap-GarminKartenGenerieren2009\mkgmap.jar --style-file=D:\DATEN\JAN\openstreetmap\mkgmap_st. i get following message: "Failed to open logging config file logging.properties" and where i had to put ".level=FINE " !!! i used windows vista regards Jan :-) Marko Mäkelä schrieb: > On Thu, Nov 26, 2009 at 01:17:11PM +0100, Jan Tappenbeck wrote: >> is there a possiblity to get a log-report for the steps of >> mkgmap-processing ??? >> >> the result is empty so i want to find the reason. > > I am not sure if this is what you mean, but at > http://www.polkupyoraily.net/osm/ > you can find a logging.properties file that enables some > printout to the file mkgmap.log.0 when you invoke mkgmap like this: > > java -ea -Dlog.config=logging.properties -jar mkgmap.jar > > You may want to set the default level to .level=FINE to see everything. > That logging.properties file is based on something that was posted on > this list earlier. > > Best regards, > > Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] Fix Nuvi routing regression (rebloat Table A)
Hi Mark, > > My Edge 705 calculates a 22.7 km route to Pasila railway station > > just fine, except that it now seems to favor smaller roads with more > > intersections. What do you think, would it be worthwhile to have > > some middle ground for Table A? Not one entry per arc nor one entry > > per way, but an entry per a configureable number or distance of arcs, > > perhaps? > > Not sure about that but I do think that this warrants some more work to > try and understand exactly what the constraint is. It's interesting > that it doesn't appear to have any effect on mapsource (or the etrex, > as far as I can tell). I don't favour making it configurable because > then the map makers would need to say what units their maps are > compatible with. Far simpler to take the hit on map size (and possibly > routing performance) until we know what's really happening. I did not really mean user-configurable but a compile-time parameter, similar to MAX_ARC_LENGTH. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Log-File for mkgmap-processing
On Thu, Nov 26, 2009 at 01:17:11PM +0100, Jan Tappenbeck wrote: > is there a possiblity to get a log-report for the steps of > mkgmap-processing ??? > > the result is empty so i want to find the reason. I am not sure if this is what you mean, but at http://www.polkupyoraily.net/osm/ you can find a logging.properties file that enables some printout to the file mkgmap.log.0 when you invoke mkgmap like this: java -ea -Dlog.config=logging.properties -jar mkgmap.jar You may want to set the default level to .level=FINE to see everything. That logging.properties file is based on something that was posted on this list earlier. Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Log-File for mkgmap-processing
hi ! is there a possiblity to get a log-report for the steps of mkgmap-processing ??? the result is empty so i want to find the reason. regards Jan :-) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Style-file repository?
On Thu, Nov 26, 2009 at 11:05:01AM +, char...@cferrero.net wrote: > Quoting Marko Mäkelä : > > > The attached patch replaces the + in the names of shelter-equipped > > bus/tram/train stops with * when lit=yes. When travelling by foot or > > bicycle during dark time of a day, it can be helpful to find the nearest > > lit shelter for a break. > > > > Best regards, > > > > Marko > > > Marko (and list), > > A while back we discussed creating a style repository for mkgmap, > where we can put our own individual style files (there must be a fair > few between regular users now). Rather than apply your patches to the > default style, perhaps we could kick-start the style repository? I think that the default style should still be maintained. There is some value in having sensible defaults. I do see value in other styles and hacks, such as distinguishing different types of paths by drawing multiple lines per way or repurposing taxi/delivery/emergency flags for custom bicycle routing, but I would keep the default style bare-bones. I must say that I have not played with other styles than the default. Is it possible to include the definitions of another style by reference and override them? That would allow improvements in the default style to be automatically applied to other styles. In that way, custom styles would be easier to maintain and understand, as they would not copy large amounts of definitions from other styles. A while back, when I emailed Steve directly to ask him to apply my shelter=yes/no to +/- patch, he asked if I would like to maintain the default style. I said yes, but I guess that Steve has been busy with other things. > We could also add a TYP file repository. I've found it inordinately > hard to find any sort of systematic directory of TYP files online (and > what I have found, tends mostly to be on Czech web-pages, for some > reason). Agreed. But I think that we should have the files in an editable format (a text file that is converted to binary TYP by a simple program) and the origin and the copyright information of every icon has to be clearly documented. Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Style-file repository?
Quoting Marko Mäkelä : > The attached patch replaces the + in the names of shelter-equipped > bus/tram/train stops with * when lit=yes. When travelling by foot or > bicycle during dark time of a day, it can be helpful to find the nearest > lit shelter for a break. > > Best regards, > > Marko > Marko (and list), A while back we discussed creating a style repository for mkgmap, where we can put our own individual style files (there must be a fair few between regular users now). Rather than apply your patches to the default style, perhaps we could kick-start the style repository? We could also add a TYP file repository. I've found it inordinately hard to find any sort of systematic directory of TYP files online (and what I have found, tends mostly to be on Czech web-pages, for some reason). -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] Fix Nuvi routing regression (rebloat Table A)
Hi Marko, Thanks for the report. > My Edge 705 calculates a 22.7 km route to Pasila railway station > just fine, except that it now seems to favor smaller roads with more > intersections. What do you think, would it be worthwhile to have > some middle ground for Table A? Not one entry per arc nor one entry > per way, but an entry per a configureable number or distance of arcs, > perhaps? Not sure about that but I do think that this warrants some more work to try and understand exactly what the constraint is. It's interesting that it doesn't appear to have any effect on mapsource (or the etrex, as far as I can tell). I don't favour making it configurable because then the map makers would need to say what units their maps are compatible with. Far simpler to take the hit on map size (and possibly routing performance) until we know what's really happening. > > I will ask the Nüvi user to try out the same map. Thanks, I reckon it will be OK for them now. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] DP Filter and areas at Resolution=24
Felix Hartmann schrieb: > > > Mark Burton wrote: >> Hi Felix, >> >> >>> Could the DP Filter not remove any points at resolution=24? >>> >> >> It doesn't do anything at that res. At the moment it does nothing, but I'm not sure, if it SHOULD do something at this level, as there may be well some points to delete. >> >> Yes, the reason is that the coordinates round to approx the nearest 2m. >> We can't do anything about that, it's what Garmin support. >> > okay I see. So the only real solution would be to have intelligent > filters moving the nodes to nearest 2m in such a way that there is > minimal loss of detail. Probably pretty CPU intensive and a lot of work. > So we have to live with it, in most places there is no real loss of > information anyhow. I have thought of some ways to merge the rounding filter and the dp filter for this reason. Mabe the dp filter should take into account the distance to rounded coordinates, not the real one. Or maybe it would be better to insert the rounding filter AFTER the dp filter. It may be possible to achive a little improvement, but I doubt it. The main reason is the limitation of resolution to 2m. Regards, Johann ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Map end user documentation?
On Sun, Nov 22, 2009 at 12:00:05AM +0200, Marko Mäkelä wrote: > I was thinking that these */+/- codes can be cryptic for map users. Is > there already some map user documentation for mkgmap-generated maps? Where > should it live? In the OSM wiki or on the mkgmap server? The master copy > could live in the mkgmap source repository (so that it would be updated > in sync with the default style), but I think that it would be good to have > a browseable copy somewhere else. I translated http://www.polkupyoraily.net/osm/ into English and German. Any suggestions for improvement are welcome, as are and any translations for minority languages spoken in Finland: se, sv, et, ru at least. I also composed a table of some slightly funny POI menu positions. Funnily, the German menu for amenity=recycling says Versorgung, the opposite of Entsorgung (disposal). Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] Fix Nuvi routing regression (rebloat Table A)
Hi Mark, On Thu, Nov 26, 2009 at 12:08:03AM +, Mark Burton wrote: > PS - Marko, please try this and see if the routing problems you were > experiencing still occur. Also, please try it on your Nuvi user and see > if their problems go away. My Edge 705 calculates a 22.7 km route to Pasila railway station just fine, except that it now seems to favor smaller roads with more intersections. What do you think, would it be worthwhile to have some middle ground for Table A? Not one entry per arc nor one entry per way, but an entry per a configureable number or distance of arcs, perhaps? I will ask the Nüvi user to try out the same map. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] DP Filter and areas at Resolution=24
Mark Burton wrote: Hi Felix, Could the DP Filter not remove any points at resolution=24? It doesn't do anything at that res. Or is there another reason why many small polygons like buildings get mashed? Yes, the reason is that the coordinates round to approx the nearest 2m. We can't do anything about that, it's what Garmin support. okay I see. So the only real solution would be to have intelligent filters moving the nodes to nearest 2m in such a way that there is minimal loss of detail. Probably pretty CPU intensive and a lot of work. So we have to live with it, in most places there is no real loss of information anyhow. In most cases there are not even any reductions in points needed to draw the areas. Agreed. 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
Re: [mkgmap-dev] DP Filter and areas at Resolution=24
Hi Felix, > Could the DP Filter not remove any points at resolution=24? It doesn't do anything at that res. > Or is there another reason why many small polygons like buildings get > mashed? Yes, the reason is that the coordinates round to approx the nearest 2m. We can't do anything about that, it's what Garmin support. > In most cases there are not even any reductions in points needed to draw > the areas. Agreed. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] DP Filter and areas at Resolution=24
Could the DP Filter not remove any points at resolution=24? Or is there another reason why many small polygons like buildings get mashed? In most cases there are not even any reductions in points needed to draw the areas. mkgmap: vs mapnik: ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
