Re: [mkgmap-dev] Flooding of sea - this time inside the middle of the Alps, not related to geofabrik cutting
Felix, > The "new" flooding is solved. The big flooding in the tile of "Bremen" > in Germany still exists however (I do know that the geofabrik cut is > 100% responsible for it). There is one problem however, the land polygon > is ommitted. So background color is missing, t'would be great if not the > sea polygon be dropped (or as well) but also the land polygon be drawn.: So the 0x4b background poly isn't the same colour as the land? OK - I will generate a land poly as well - new patch will be posted in a little while Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Flooding of sea - this time inside the middle of the Alps, not related to geofabrik cutting
On 27.02.2010 10:36, Mark Burton wrote: > Felix, > > >> The "new" flooding is solved. The big flooding in the tile of "Bremen" >> in Germany still exists however (I do know that the geofabrik cut is >> 100% responsible for it). There is one problem however, the land polygon >> is ommitted. So background color is missing, t'would be great if not the >> sea polygon be dropped (or as well) but also the land polygon be drawn.: >> > So the 0x4b background poly isn't the same colour as the land? > > OK - I will generate a land poly as well - new patch will be posted in > a little while > > I don't use 0x4b in Typfile anymore. Having two polygons for one function (get rid of yellow on etrex) is slowing down GPS/Mapsource .13.x > 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] Bug report --remove-short-arcs=5 ???
Hello Garvan, > I found a generalize function in gpsmapedit that removed 10% of the > points in the file, but the national boundaries still did not display, > so I split the very long polyline up and then it compiled correctly. I don't see why that was required because we already split lines that have more than 250 points. > This experience may be worth noting for others who see long lines > disappearing with no error message when compiling in osm format. Sure, but I would rather find out why the existing line splitting didn't work satisfactorily. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Flooding of sea - this time inside the middle of the Alps, not related to geofabrik cutting
> I don't use 0x4b in Typfile anymore. Having two polygons for one
> function (get rid of yellow on etrex) is slowing down GPS/Mapsource .13.x
Fair enough - please try attached new patch that generates the land
poly.
> The big flooding in the tile of "Bremen"
> in Germany still exists however (I do know that the geofabrik cut is
> 100% responsible for it).
Given the location, I would think that the coastline reaches the edge
of the tile. In that case, this patch doesn't help. The coastline must
be broken. I assume that "close-gaps" doesn't fix the problem.diff --git a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
index f78b1f9..e94bcc6 100644
--- a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
+++ b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
@@ -115,6 +115,7 @@ public class Osm5XmlHandler extends DefaultHandler {
private boolean generateSeaUsingMP = true;
private boolean allowSeaSectors = true;
private boolean extendSeaSectors;
+ private boolean roadsReachBoundary;
private int maxCoastlineGap;
private String[] landTag = { "natural", "land" };
private final Double minimumArcLength;
@@ -618,10 +619,12 @@ public class Osm5XmlHandler extends DefaultHandler {
coordMap = null;
+ if(bbox != null && (generateSea || minimumArcLength != null))
+ makeBoundaryNodes();
+
if (generateSea)
generateSeaPolygon(shoreline);
- long start = System.currentTimeMillis();
for (Relation r : relationMap.values())
converter.convertRelation(r);
@@ -630,11 +633,8 @@ public class Osm5XmlHandler extends DefaultHandler {
nodeMap = null;
- if(minimumArcLength != null) {
- if(bbox != null)
-makeBoundaryNodes();
+ if(minimumArcLength != null)
removeShortArcsByMergingNodes(minimumArcLength);
- }
nodeIdMap = null;
@@ -691,7 +691,8 @@ public class Osm5XmlHandler extends DefaultHandler {
// highway count one
clippedPair[1].incHighwayCount();
++numBoundaryNodesAdded;
-
+ if(!roadsReachBoundary && way.getTag("highway") != null)
+ roadsReachBoundary = true;
}
else if(clippedPair[1].getOnBoundary())
++numBoundaryNodesDetected;
@@ -712,6 +713,8 @@ public class Osm5XmlHandler extends DefaultHandler {
// highway count one
clippedPair[0].incHighwayCount();
++numBoundaryNodesAdded;
+ if(!roadsReachBoundary && way.getTag("highway") != null)
+ roadsReachBoundary = true;
}
else if(clippedPair[0].getOnBoundary())
++numBoundaryNodesDetected;
@@ -1187,6 +1190,7 @@ public class Osm5XmlHandler extends DefaultHandler {
// the remaining shoreline segments should intersect the boundary
// find the intersection points and store them in a SortedMap
SortedMap hitMap = new TreeMap();
+ boolean shorelineReachesBoundary = false;
long seaId;
Way sea;
for (Way w : shoreline) {
@@ -1343,6 +1347,13 @@ public class Osm5XmlHandler extends DefaultHandler {
w.getPoints().add(w.getPoints().get(0));
log.info("adding non-island landmass, hits.size()=" + hits.size());
islands.add(w);
+ shorelineReachesBoundary = true;
+ }
+
+ if(!shorelineReachesBoundary && roadsReachBoundary) {
+ // try to avoid tiles being flooded by anti-lakes or other
+ // bogus uses of natural=coastline
+ generateSeaBackground = false;
}
List antiIslands = new ArrayList();
@@ -1451,6 +1462,23 @@ public class Osm5XmlHandler extends DefaultHandler {
if(generateSeaUsingMP)
seaRelation.addElement("outer", sea);
}
+ else {
+ // background is land
+ if(!generateSeaUsingMP) {
+// generate a land polygon so that the tile's
+// background colour will match the land colour on the
+// tiles that do contain some sea
+long landId = FakeIdGenerator.makeFakeId();
+Way land = new Way(landId);
+land.addPoint(nw);
+land.addPoint(sw);
+land.addPoint(se);
+land.addPoint(ne);
+land.addPoint(nw);
+land.addTag(landTag[0], landTag[1]);
+wayMap.put(landId, land);
+ }
+ }
if(generateSeaUsingMP) {
Area mpBbox = (bbox != null ? bbox : ((MapDetails) collector).getBounds());
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Weird turn instructions
Mark Burton escribió: > Hi Carlos, > > >> At least since version of 12/02/2010 I'm getting some weird turn >> instructions in places where they worked fine in the past . In this area >> [1] I get two of these estrange instructions when driving SE from >> "Avenida Cordel de Merinas" to SW in "Avenida Hernán Cortés". The >> sequence of instructions (both MapSource and gps) is: >> 1-Turn right at Avenida de Extremadura (OK) >> 2-Turn left at Avenida de las Delicias (wrong) >> 3-Turn right at Avenida de las Delicias (OK) >> 4-Turn right at Avenida Hernán Cortés (wrong) >> At 2 there's been no change in the data for a long time. I noticed 4 >> first time after creating a through_route relation to avoid a "keep >> left" instruction, but the problem could have been there before. >> nuvi gives another wrong "turn right" at 3.5 >> > > With that patch I posted earlier, this route is fine now in mapsource > (no spurious directions). Are you still seeing problems with that route? Yes: Turn left at 2 has disappeared, good! Now at 3 instruction is keep right, which is wrong. Turn right is still said at 4, where there's a through_route relation, so no instruction should be said (if one, it should be keep left). I have another case at [1]: 1: enter roundabout (ok) 2: take first to the right (ok) 3: turn left at Calle Osa Mayor (ok) 4: turn left at Calle Osa Mayor (wrong) [1] http://www.openstreetmap.org/?lat=39.47593&lon=-6.39121&zoom=17&layers=B000FTF <>___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Flooding of sea - this time inside the middle of the Alps, not related to geofabrik cutting
On 27.02.2010 11:06, Mark Burton wrote: I don't use 0x4b in Typfile anymore. Having two polygons for one function (get rid of yellow on etrex) is slowing down GPS/Mapsource .13.x Fair enough - please try attached new patch that generates the land poly. The big flooding in the tile of "Bremen" in Germany still exists however (I do know that the geofabrik cut is 100% responsible for it). Given the location, I would think that the coastline reaches the edge of the tile. In that case, this patch doesn't help. The coastline must be broken. I assume that "close-gaps" doesn't fix the problem. okay, patch works as expected. In both Germany and the Netherlands flooded tiles have been fixed. BTW - for the --generate-sea=polygons option, I still do think the cleanest approach would be to drop 0x4b polygon. Currently I use --transparent --generate-sea=polygons for mkgmap, and afterwards run "gmt.exe -w -n *.img" to remove transparency, as this increases map draw speed on etrex and Mapsource 6.13.x Maybe there could be more options for the --transparent command. like --transparent (current behaviour) --transparent=omit0x4b --transparent=transparentbit (include 0x4b, but set the transparent bit). Or make it two options. Like --background=0x4b (default) --background=0x?? (allows custom definition of background polygon type) --background=no (no background polygon) and --transparent=no (default) --transparent=yes (put transparent bit) ___ 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] Method copyTags(..) in Element.java
Element.java contains the following implementation of copyTags(Element
other):
/**
* Copy the tags of the other element. Only to be used internally
* by subclasses.
* @param other The other element. All its tags will be copied to this
* element.
*/
public void copyTags(Element other) {
if (other.tags != null)
tags = other.tags.copy();
}
So the copyTags does not add but replace all tags. But only if the other
element has tags. This is weird. So I think replaceTags would be a
better name and the other.tags==null case should be handled:
public void replaceTags(Element other) {
if (other.tags == null)
tags = null;
else
tags = other.tags.copy();
}
Is this ok or are there any side effects I am not aware of?
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] natural=coastline;cliff
Hi, Someone has tagged part of the UK coastline with natural=coastline;cliff and this has broken --generate-sea=polygons,no-sea-sectors,close-gaps=1000. Is this valid syntax that mkgmap should cope with? Regards, Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] natural=coastline;cliff
Hi Steve, > Someone has tagged part of the UK coastline with natural=coastline;cliff and > this has broken > --generate-sea=polygons,no-sea-sectors,close-gaps=1000. Is this valid syntax > that mkgmap should cope with? Don't know whether it's valid or not but I will put in a workaround. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] natural=coastline;cliff
On 27.02.2010 14:43, Mark Burton wrote: > Hi Steve, > > >> Someone has tagged part of the UK coastline with natural=coastline;cliff and >> this has broken >> --generate-sea=polygons,no-sea-sectors,close-gaps=1000. Is this valid syntax >> that mkgmap should cope with? >> I think we would need a functions (be it inside style-file or outside) that doubles features if ";" is present inside: highway=*; railway=* ; landuse=* ; (it should not double the object if ";" is only inside name or ref). ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Mysterious icons
Hi! My new maps show a sandwich for cafe/diner ( http://www.deltadelta.de/nmz/sandwich.png ), chopsticks for cuisine=chinese and a pizza slice for cuisine=italian. But these ar neither original Garmin waypoint icons nor are they defined in the typ file. Where do the come from? Thanks a lot in advance, Dani ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Method copyTags(..) in Element.java
On 27/02/10 13:23, WanMil wrote:
> /**
>* Copy the tags of the other element. Only to be used internally
>* by subclasses.
>* @param other The other element. All its tags will be copied to this
>* element.
>*/
> public void copyTags(Element other) {
> if (other.tags != null)
> tags = other.tags.copy();
> }
>
>
> So the copyTags does not add but replace all tags. But only if the other
> element has tags. This is weird. So I think replaceTags would be a
> better name and the other.tags==null case should be handled:
Originally it was used to copy tags from an existing element to a
newly created one, so there wasn't really much of a problem.
This is still mostly the case, except in the multipolygon code which
is no doubt why you are bringing this up :)
So yes, your changes appear fine to me as they will not affect the
original cases. Also the comment about only being used in subclasses
is wrong/out of date.
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] natural=coastline;cliff
Hi Steve,
> Someone has tagged part of the UK coastline with natural=coastline;cliff and
> this has broken
> --generate-sea=polygons,no-sea-sectors,close-gaps=1000. Is this valid syntax
> that mkgmap should cope with?
The attached patch is a quick workaround.
If possible, please test.
Cheers,
Mark
diff --git a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
index f78b1f9..7da3508 100644
--- a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
+++ b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
@@ -517,9 +517,33 @@ public class Osm5XmlHandler extends DefaultHandler {
if("motorway".equals(highway) ||
"trunk".equals(highway))
motorways.add(currentWay);
-if(generateSea && "coastline".equals(currentWay.getTag("natural"))) {
- currentWay.deleteTag("natural");
- shoreline.add(currentWay);
+if(generateSea) {
+ String natural = currentWay.getTag("natural");
+ if(natural != null) {
+ if("coastline".equals(natural)) {
+ currentWay.deleteTag("natural");
+ shoreline.add(currentWay);
+ }
+ else if(natural.contains(";")) {
+ // cope with compound tag value
+ String others = null;
+ boolean foundCoastline = false;
+ for(String n : natural.split(";")) {
+if("coastline".equals(n.trim()))
+ foundCoastline = true;
+else if(others == null)
+ others = n;
+else
+ others += ";" + n;
+ }
+ if(foundCoastline) {
+currentWay.deleteTag("natural");
+if(others != null)
+ currentWay.addTag("natural", others);
+shoreline.add(currentWay);
+ }
+ }
+ }
}
currentNodeInWay = null;
currentWayStartsWithFIXME = false;
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1585: Avoid flooding inland tiles due to bogus coastline segments.
Version 1585 was commited by markb on 2010-02-27 14:16:37 + (Sat, 27 Feb 2010) Avoid flooding inland tiles due to bogus coastline segments. When using --generate-sea=polygons, bad coastline segments (e.g. anti-lakes) can cause the entire tile to be flooded with sea. This commit suppresses the generation of the sea polygon if the coastline doesn't reach the edge of the tile but ways with "highway" tags (aka roads) do reach the edge of the tile. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] natural=coastline;cliff
Steve Brophy wrote: > Hi, > > Someone has tagged part of the UK coastline with natural=coastline;cliff > and this has broken > --generate-sea=polygons,no-sea-sectors,close-gaps=1000. Is this valid > syntax that mkgmap should cope with? > > Regards, > > Steve > > I had noticed the same problem and overcame it by using --generate-sea:close-gaps=1,no-mp (i.e. using a ridiculously high value for close-gaps) because I couldn't find an easy way of identifying the broken coastline segment. How did you find the segment tagged with cliff? Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v1] Add null handling for Element.copyTags and Element.getTagsWithPrefix
On 27/02/10 13:23, WanMil wrote:
/**
* Copy the tags of the other element. Only to be used internally
* by subclasses.
* @param other The other element. All its tags will be copied to this
* element.
*/
public void copyTags(Element other) {
if (other.tags != null)
tags = other.tags.copy();
}
So the copyTags does not add but replace all tags. But only if the other
element has tags. This is weird. So I think replaceTags would be a
better name and the other.tags==null case should be handled:
Originally it was used to copy tags from an existing element to a
newly created one, so there wasn't really much of a problem.
This is still mostly the case, except in the multipolygon code which
is no doubt why you are bringing this up :)
So yes, your changes appear fine to me as they will not affect the
original cases. Also the comment about only being used in subclasses
is wrong/out of date.
..Steve
Yeah, I use this in the multipolygon code and stumbled over it.
The patch fixes the copyTags method and adds a null check to the
getTagsWithPrefix method (which might have been bigger problem).
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/Element.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/Element.java (revision 1585)
+++ src/uk/me/parabola/mkgmap/reader/osm/Element.java (working copy)
@@ -82,13 +82,15 @@
}
/**
-* Copy the tags of the other element. Only to be used internally
-* by subclasses.
+* Copy the tags of the other element which replaces all tags of this
element.
+*
* @param other The other element. All its tags will be copied to this
* element.
*/
public void copyTags(Element other) {
- if (other.tags != null)
+ if (other.tags == null)
+ tags = null;
+ else
tags = other.tags.copy();
}
@@ -102,6 +104,9 @@
}
public Map getTagsWithPrefix(String prefix, boolean
removePrefix) {
+ if (tags == null)
+ return Collections.emptyMap();
+
return tags.getTagsWithPrefix(prefix, removePrefix);
}
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1586: The patch fixes the copyTags method and adds a null check to the getTagsWithPrefix method (which might have been bigger problem).
Version 1586 was commited by steve on 2010-02-27 15:01:55 + (Sat, 27 Feb 2010) The patch fixes the copyTags method and adds a null check to the getTagsWithPrefix method (which might have been bigger problem). WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Help required for style rule
Style gurus, I want to have a rule that matches one way trunk roads. Given that onewayness can be specified with (at least) 3 different tag values (1,yes,true) do I have to have something like the following, or can it be simplified: highway=trunk & (oneway=yes|oneway=true|oneway=1) [...] i.e. does the following mean the same? highway=trunk & oneway [...] Thanks Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Help required for style rule
On 27.02.2010 16:19, Mark Burton wrote:
> Style gurus,
>
> I want to have a rule that matches one way trunk roads. Given that
> onewayness can be specified with (at least) 3 different tag values
> (1,yes,true) do I have to have something like the following, or can it
> be simplified:
>
>
The following is like what I would propose.
> highway=trunk& (oneway=yes|oneway=true|oneway=1) [...]
>
>
Alternatively you could use
oneway=true | oneway=1 {set oneway=yes}
highway=trunk & oneway=yes [...]
What is less code to write depends on your requirements.
> i.e. does the following mean the same?
>
> highway=trunk& oneway [...]
>
> Thanks
>
> Mark
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] natural=coastline;cliff
I draw the coastline also, and noticed a gap in mapsource when zooming in. Also, it is flagged by http://coastline.openstreetmap.nl/ Steve On 27 February 2010 14:35, Charlie Ferrero wrote: > Steve Brophy wrote: > > Hi, > > > > Someone has tagged part of the UK coastline with natural=coastline;cliff > > and this has broken > > --generate-sea=polygons,no-sea-sectors,close-gaps=1000. Is this valid > > syntax that mkgmap should cope with? > > > > Regards, > > > > Steve > > > > > > I had noticed the same problem and overcame it by using > --generate-sea:close-gaps=1,no-mp (i.e. using a ridiculously high > value for close-gaps) > because I couldn't find an easy way of identifying the broken coastline > segment. How did you find the segment tagged with cliff? > > Charlie > ___ > 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] natural=coastline;cliff
Thanks Mark. Unfortunately, I don't build mkgmap, so can't test the patch. Steve On 27 February 2010 14:12, Mark Burton wrote: > > Hi Steve, > > > Someone has tagged part of the UK coastline with natural=coastline;cliff > and > > this has broken > > --generate-sea=polygons,no-sea-sectors,close-gaps=1000. Is this valid > syntax > > that mkgmap should cope with? > > The attached patch is a quick workaround. > > If possible, please test. > > Cheers, > > Mark > > ___ > 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] natural=coastline;cliff
Steve, > Thanks Mark. Unfortunately, I don't build mkgmap, so can't test the patch. OK - no problem, I expect someone will give it a go. 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] - yet more turn heading adjustment fixes
Hopefully, these changes will fix the bad routing directions we have
been seeing recently - please test and report success/failure.
diff --git a/src/uk/me/parabola/imgfmt/app/net/RouteNode.java b/src/uk/me/parabola/imgfmt/app/net/RouteNode.java
index 2b8ca79..ea6651e 100644
--- a/src/uk/me/parabola/imgfmt/app/net/RouteNode.java
+++ b/src/uk/me/parabola/imgfmt/app/net/RouteNode.java
@@ -15,6 +15,8 @@
package uk.me.parabola.imgfmt.app.net;
import java.util.ArrayList;
+import java.util.Collections;
+import java.util.Comparator;
import java.util.Iterator;
import java.util.List;
@@ -339,6 +341,29 @@ public class RouteNode implements Comparable {
return false;
}
+ private static boolean rightTurnRequired(int inHeading, int outHeading, int sideHeading) {
+ // given the headings of the incoming, outgoing and side
+ // roads, decide whether a side road is to the left or the
+ // right of the main road
+
+ // side road heading must be < inverse of incoming heading
+ int a = sideHeading - (inHeading + 180);
+ while(a < -180)
+ a += 360;
+ while(a > 180)
+ a -= 360;
+ if(a > 0)
+ return false;
+
+ // side road heading must be > outgoing heading
+ a = sideHeading - outHeading;
+ while(a < -180)
+ a += 360;
+ while(a > 180)
+ a -= 360;
+ return a > 0;
+ }
+
private static int ATH_OUTGOING = 1;
private static int ATH_INCOMING = 2;
@@ -375,7 +400,25 @@ public class RouteNode implements Comparable {
final int minDiffBetweenOutgoingAndOtherArcs = 45;
final int minDiffBetweenIncomingAndOtherArcs = 50;
- for(RouteArc inArc : incomingArcs) {
+ // list of outgoing arcs discovered at this node
+ List outgoingArcs = new ArrayList();
+
+ // sort incoming arcs by decreasing class/speed
+ List inArcs = new ArrayList(incomingArcs);
+
+ Collections.sort(inArcs, new Comparator() {
+ public int compare(RouteArc ra1, RouteArc ra2) {
+ int c1 = ra1.getRoadDef().getRoadClass();
+ int c2 = ra2.getRoadDef().getRoadClass();
+ if(c1 == c2)
+ return (ra2.getRoadDef().getRoadSpeed() -
+ ra1.getRoadDef().getRoadSpeed());
+ return c2 - c1;
+ }
+});
+
+ // look at incoming arcs in order of decreasing class/speed
+ for(RouteArc inArc : inArcs) {
if(!inArc.isForward() && inArc.getRoadDef().isOneway()) {
// ignore reverse arc if road is oneway
@@ -442,16 +485,27 @@ public class RouteNode implements Comparable {
oa.getRoadDef().getRoadSpeed() == inArcSpeed) {
if(outArc != null) {
// multiple arcs have the same road
-// class as the incoming arc so don't
-// use any of them as the outgoing arc
+// class/speed as the incoming arc so
+// don't use any of them as the
+// outgoing arc
outArc = null;
break;
}
- outArc = oa;
+ // oa has the same class/speed as inArc,
+ // now check that oa is not part of
+ // another road by matching names rather
+ // than class/speed because they could be
+ // different
+ boolean paired = false;
+ for(RouteArc z : arcs)
+if(z != oa && possiblySameRoad(z, oa))
+ paired = true;
+ if(!paired)
+outArc = oa;
}
}
if(outArc != null)
- log.info("Matched outgoing arc " + outArc.getRoadDef() + " to " + inArc.getRoadDef() + " using road class (" + inArcClass + ") and speed (" + inArcSpeed + ")");
+ log.info("Matched outgoing arc " + outArc.getRoadDef() + " to " + inArc.getRoadDef() + " using road class (" + inArcClass + ") and speed (" + inArcSpeed + ") at " + coord.toOSMURL());
}
// if we did not find the outgoing arc, give up with
@@ -460,6 +514,10 @@ public class RouteNode implements Comparable {
//log.info("Can't continue road " + inArc.getRoadDef() + " at " + coord.toOSMURL());
continue;
}
+
+// remember that this arc is an outgoing arc
+outgoingArcs.add(outArc);
+
int outHeading = outArc.getInitialHeading();
int mainHeadingDelta = outHeading - inHeading;
while(mainHeadingDelta > 180)
@@ -507,6 +565,13 @@ public class RouteNode implements Comparable {
continue;
}
+ if(outgoingArcs.contains(otherArc)) {
+ // this arc was previously matched as an
+ // outgoing arc so we don't want to change its
+ // heading now
+ continue;
+ }
+
int otherHeading = otherArc.getInitialHeading();
int outToOtherDelta = otherHeading - outHeading;
while(outToOtherDelta > 180)
@@ -520,13 +585,13 @@ public class RouteNode implements Comparable {
inToOtherDelta += 360;
int newHeading = otherHeading;
- if(outToOtherDelta > 0) {
+ if(rightTurnRequired(inHeading, outHeading, otherHeading)) {
// side road to the right
if((mask & ATH_OUTGOING) != 0 &&
- outToOtherDelta < minDiffBetweenOutgoingAndOtherArcs)
+ Math.abs(outToOtherDelta) < minDiffBetweenOutgoingAndOtherArcs)
Re: [mkgmap-dev] [PATCH v1] - yet more turn heading adjustment fixes
Mark Burton escribió: > Hopefully, these changes will fix the bad routing directions we have > been seeing recently - please test and report success/failure. Same result than with mb-side-road-direction-fix-v1.patch for both routes reported in my previous mail. No improvement. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] multipolygons: how to flag role=inner role=outer in Style file?
Hi,
I have problems rendering this kind of relation:
http://www.openstreetmap.org/browse/relation/1525
Many lakes in the Netherlands are automatically tagged (AND import) like this.
The lake is a multipolygon, where the outer border is tagged as natural=water
(role=outer)
and the inner border (for instance an island in this lake) as natural=water
(role=inner) too.
When I render this, the islands in those lakes are flooded.
Of course it would be better not to tag those inner borders at all, or use
landuse=* or natural=land
Is there a method in the style file to flag ways with role=outer and role=inner
from
the same multipolygon?
What I would like to do is something like this:
>From lake A with type=multipolygon and way A1 {natural=water & role=outer} and
>way A2 {natural=water & role=inner}
remove the tag natural=water from way A2 (or retag natural=water to
natural=land?)
Is this possible?
Cheers, Minko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] multipolygons: how to flag role=inner role=outer in Style file?
Hi Minko,
> Is there a method in the style file to flag ways with role=outer and
> role=inner from the same multipolygon?
Yes, the relations file can match on role. I have never tried writing
relations rules for multipolygons, though.
> What I would like to do is something like this:
> >From lake A with type=multipolygon and way A1 {natural=water &
> role=outer} and way A2 {natural=water & role=inner}
> remove the tag natural=water from way A2 (or retag natural=water to
> natural=land?)
>
> Is this possible?
Something like this (not tested) in the relations file of your style
should do the trick:
type=multipolygon & natural=water { apply role=inner { set natural=land
} }
This will assign natural=land to each inner member of multipolygon
relations.
As far as I understand, it is not possible to write other conditions
for the apply than role. And you cannot match role by regular
expression. In this case, you cannot add a condition that you only want
to set natural=land for those inner members that had natural=water.
I do not know when the custom multipolygon processing kicks in. It
could be that the style rules are executed after that, and it is too
late to adjust anything with style rules.
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] multipolygons: how to flag role=inner role=outer in Style file?
Thanks Marko,
The tag natural=water is not assigned to the relation (only type=multipolygon)
so this is not working.
Is it possible to write a condition for role=outer & natural=water
{ apply role=inner { set natural=land
} } ??
Here another example of that kind of relation:
http://maps.google.de/maps?f=q&hl=de&geocode=&q=http://betaplace.emaitie.de/webapps.relation-analyzer/downloadServlet/kml/1525&ie=UTF8
The red way (island) is flooded in my map (and other osm maps as well).
What I noticed is that on other maps (radfahrer, openmtb) which were made with
previous versions of mkgmap
those islands were not flooded, but now they are. So it was somehow possible,
but how?
Regards,
Minko
Marko Mäkelä wrote:
Something like this (not tested) in the relations file of your style
should do the trick:
type=multipolygon & natural=water { apply role=inner { set natural=land
} }
This will assign natural=land to each inner member of multipolygon
relations.
As far as I understand, it is not possible to write other conditions
for the apply than role. And you cannot match role by regular
expression. In this case, you cannot add a condition that you only want
to set natural=land for those inner members that had natural=water.
I do not know when the custom multipolygon processing kicks in. It
could be that the style rules are executed after that, and it is too
late to adjust anything with style rules.
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] multipolygons: how to flag role=inner role=outer in Style file?
Well then just put
natural=water & role=inner [0x.. type from land instead of water).
natural=water [0x type of water]
Previous versions were often incorrect when it came to multipolygons.
which openmtbmap version worked last?
(because current version to mkgmap svn no relevant mp changes were done).
On 27.02.2010 20:22, Minko wrote:
> Thanks Marko,
>
> The tag natural=water is not assigned to the relation (only type=multipolygon)
> so this is not working.
>
> Is it possible to write a condition for role=outer& natural=water
> { apply role=inner { set natural=land
> } } ??
>
> Here another example of that kind of relation:
> http://maps.google.de/maps?f=q&hl=de&geocode=&q=http://betaplace.emaitie.de/webapps.relation-analyzer/downloadServlet/kml/1525&ie=UTF8
>
> The red way (island) is flooded in my map (and other osm maps as well).
>
> What I noticed is that on other maps (radfahrer, openmtb) which were made
> with previous versions of mkgmap
> those islands were not flooded, but now they are. So it was somehow possible,
> but how?
>
> Regards,
> Minko
>
>
> Marko Mäkelä wrote:
>
> Something like this (not tested) in the relations file of your style
> should do the trick:
>
> type=multipolygon& natural=water { apply role=inner { set natural=land
> } }
>
> This will assign natural=land to each inner member of multipolygon
> relations.
>
> As far as I understand, it is not possible to write other conditions
> for the apply than role. And you cannot match role by regular
> expression. In this case, you cannot add a condition that you only want
> to set natural=land for those inner members that had natural=water.
>
> I do not know when the custom multipolygon processing kicks in. It
> could be that the style rules are executed after that, and it is too
> late to adjust anything with style rules.
>
> 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] multipolygons: how to flag role=inner role=outer in Style file?
27.02.2010 22.10.33, Felix Hartmann wrote: > Well then just put > natural=water & role=inner [0x.. type from land instead of water). > natural=water [0x type of water] How would that work? Wouldn't you have to set role=inner on the inner way (island) in the relations rules? What if the island contains lakes? Then, the island way would be in role=inner in the lake-with-island multipolygon and role=outer in the island-with-lake multipolygon. I think that the style language for relations should be improved. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] multipolygons: how to flag role=inner role=outer in Style file?
Hi Minko,
> The tag natural=water is not assigned to the relation (only
> type=multipolygon) so this is not working.
>
> Is it possible to write a condition for role=outer & natural=water
> { apply role=inner { set natural=land } } ??
As I wrote in my initial reply, my understanding is the only currently
available conditions to apply are role=string (not even role~regexp)
and the attributes of the relation. You cannot restrict apply based on
member type (node, way, relation) or attributes. It would be useful to
have that. I would also like to be able to sort relations before apply,
so that name or ref can be appended in a sensible order (administrative
boundaries, multiple routes sharing the same way or bus stops, etc.)
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] multipolygons: how to flag role=inner role=outer in Style file?
Felix, natural=water & role=inner in the polygons style file (if a rule like that would be possible at all?) will not be a solution, because then also lakes within (multipolygon) forests are tagged like this too and will be affected. For my case it only has to be applied on relations where both role=inner and role=outer are tagged with natural=water The last version of openmtbmap that worked correct for this relation was in december 2009 I guess. Radfahrers map of Europa from 09-01-2010 seems also working ok for this kind of relation. But maybe in my case its better to accept that the Dutch way of osm tagging is wrong and has to be altered instead of finding a way to solve this with mkgmap ;-) Cheers, Minko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] multipolygons: how to flag role=inner role=outer in Style file?
Minko, > But maybe in my case its better to accept that the Dutch way of osm > tagging is wrong and has to be altered instead of finding a way to > solve this with mkgmap ;-) I would say so. The islands should be tagged natural=land or landuse=* instead of natural=water. Nevertheless, I think that the relation style processing in mkgmap should be improved. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] multipolygons: how to flag role=inner role=outer in Style file?
I would say this tagging is simply wrong. a line with tag natural water is water. This use is against all the definitions for correct relations. any renderer not strictly overwriting way/node tags AND deleting/ignoring tags from inner members will fail. For legacy reasons relation support has worked to use a tag from the relation and override the tag on the outer way. if tag is only on the outer way use it too. inner way should have no tags at all. But can have other tags which are not related to the relation and can/should be processed independent. natural=land can be used instead but is entirely redundant a hole in the lake is by definition land. The advantage of a redundant tag is that renderer without relation knowledge can still produce correct maps. On 27 Feb 2010, at 13:06 , Minko wrote: > Felix, > natural=water & role=inner in the polygons style file (if a rule like that > would be possible at all?) will not > be a solution, because then also lakes within (multipolygon) forests are > tagged like this too and will be affected. > For my case it only has to be applied on relations where both role=inner and > role=outer are tagged with natural=water > > The last version of openmtbmap that worked correct for this relation was in > december 2009 I guess. > Radfahrers map of Europa from 09-01-2010 seems also working ok for this kind > of relation. > > But maybe in my case its better to accept that the Dutch way of osm tagging > is wrong and has to be altered instead > of finding a way to solve this with mkgmap ;-) > > Cheers, > Minko > ___ > 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] multipolygons: how to flag role=inner role=outer in Style file?
On 27.02.2010 22:06, Minko wrote: > Felix, > natural=water& role=inner in the polygons style file (if a rule like that > would be possible at all?) will not > be a solution, because then also lakes within (multipolygon) forests are > tagged like this too and will be affected. > For my case it only has to be applied on relations where both role=inner and > role=outer are tagged with natural=water > > > Stupid me, did not think much about it when writing this. Considering, I would also say Dutch mapping here is plain incorrect. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v2] - yet more turn heading adjustment fixes
v2 - further fixes
Carlos, this still gives you an extra "turn left onto Calle Osa
Mayor" and I know what's happening there but can't fix it - how
about the other problems you were seeing? better/worse?
Hopefully, these changes will fix the bad routing directions we have
been seeing recently - please test and report success/failure.
diff --git a/src/uk/me/parabola/imgfmt/app/net/RouteNode.java b/src/uk/me/parabola/imgfmt/app/net/RouteNode.java
index 2b8ca79..e86f2de 100644
--- a/src/uk/me/parabola/imgfmt/app/net/RouteNode.java
+++ b/src/uk/me/parabola/imgfmt/app/net/RouteNode.java
@@ -15,6 +15,8 @@
package uk.me.parabola.imgfmt.app.net;
import java.util.ArrayList;
+import java.util.Collections;
+import java.util.Comparator;
import java.util.Iterator;
import java.util.List;
@@ -298,6 +300,12 @@ public class RouteNode implements Comparable {
RoadDef rda = raa.getRoadDef();
RoadDef rdb = rab.getRoadDef();
+
+ if(rda.getId() == rdb.getId()) {
+ // roads have the same (OSM) id
+ return true;
+ }
+
boolean bothArcsNamed = false;
for(Label laba : rda.getLabels()) {
if(laba != null && laba.getOffset() != 0) {
@@ -339,6 +347,26 @@ public class RouteNode implements Comparable {
return false;
}
+ private static boolean rightTurnRequired(int inHeading, int outHeading, int sideHeading) {
+ // given the headings of the incoming, outgoing and side
+ // roads, decide whether a side road is to the left or the
+ // right of the main road
+
+ outHeading -= inHeading;
+ while(outHeading < -180)
+ outHeading += 360;
+ while(outHeading > 180)
+ outHeading -= 360;
+
+ sideHeading -= inHeading;
+ while(sideHeading < -180)
+ sideHeading += 360;
+ while(sideHeading > 180)
+ sideHeading -= 360;
+
+ return sideHeading > outHeading;
+ }
+
private static int ATH_OUTGOING = 1;
private static int ATH_INCOMING = 2;
@@ -375,9 +403,29 @@ public class RouteNode implements Comparable {
final int minDiffBetweenOutgoingAndOtherArcs = 45;
final int minDiffBetweenIncomingAndOtherArcs = 50;
- for(RouteArc inArc : incomingArcs) {
+ // list of outgoing arcs discovered at this node
+ List outgoingArcs = new ArrayList();
+
+ // sort incoming arcs by decreasing class/speed
+ List inArcs = new ArrayList(incomingArcs);
+
+ Collections.sort(inArcs, new Comparator() {
+ public int compare(RouteArc ra1, RouteArc ra2) {
+ int c1 = ra1.getRoadDef().getRoadClass();
+ int c2 = ra2.getRoadDef().getRoadClass();
+ if(c1 == c2)
+ return (ra2.getRoadDef().getRoadSpeed() -
+ ra1.getRoadDef().getRoadSpeed());
+ return c2 - c1;
+ }
+});
+
+ // look at incoming arcs in order of decreasing class/speed
+ for(RouteArc inArc : inArcs) {
+
+RoadDef inRoadDef = inArc.getRoadDef();
-if(!inArc.isForward() && inArc.getRoadDef().isOneway()) {
+if(!inArc.isForward() && inRoadDef.isOneway()) {
// ignore reverse arc if road is oneway
continue;
}
@@ -392,7 +440,7 @@ public class RouteNode implements Comparable {
for(RouteArc[] pair : throughRoutes) {
if(pair[0] == inArc) {
outArc = pair[1];
- log.info("Found through route from " + inArc.getRoadDef() + " to " + outArc.getRoadDef());
+ log.info("Found through route from " + inRoadDef + " to " + outArc.getRoadDef());
break;
}
}
@@ -405,7 +453,7 @@ public class RouteNode implements Comparable {
if(oa.getDest() != inArc.getSource()) {
// this arc is not going to the same node as
// inArc came from
- if(oa.getRoadDef() == inArc.getRoadDef()) {
+ if(oa.getRoadDef() == inRoadDef) {
outArc = oa;
break;
}
@@ -415,7 +463,7 @@ public class RouteNode implements Comparable {
if(outArc == null) {
// next, although the RoadDefs don't match, use
- // possiblySameRoad() to see if the road
+ // possiblySameRoad() to see if the roads' id or
// labels (names/refs) match
for(RouteArc oa : arcs) {
if(oa.getDest() != inArc.getSource()) {
@@ -430,43 +478,60 @@ public class RouteNode implements Comparable {
}
}
-if(outArc == null) {
+if(outArc == null && inRoadDef.getNumLabels() == 0) {
// last ditch attempt to find the outgoing arc -
- // try and find a single arc that has the same
- // road class and speed as the incoming arc
- int inArcClass = inArc.getRoadDef().getRoadClass();
- int inArcSpeed = inArc.getRoadDef().getRoadSpeed();
+ // try and find a single (anonymous) arc that has
+ // the same road class and speed as the incoming
+ // arc
+ int inArcClass = inRoadDef.getRoadClass();
+ int inArcSpeed = inRoadDef.getRoadSpeed();
for(RouteArc oa : arcs) {
- if(oa.getDest() != inArc.getSource() &&
+ if(oa.getRoadDef().getNumLabels() == 0 &&
+ oa.getDest() != inArc.getSource() &&
oa.getRoadDef().getRoadClass() == inArcClass &&
