Re: [mkgmap-dev] transparent overlays breaks address-index on GPS
Hi, Felix, Felix Hartmann wrotes on Thu Mar 4 20:51:53 GMT 2010 > Will test this out later. You could use my batchfiles > (create_mapsource_installationfiles_with_mkgmap) which create joined > maps with address index) instead. That definitely works. Very strange > nonetheless, but there are simply some bugs in the address index anyhow > - else it would work better. > Yes, i believe that this works( though i not tested it yet), because i forgot to mention that only if the area which is covered by the transparent overlay has smaller bounds, the index doesn't work (for this area). So if i move my cursor on the GPS out of the bounds of the transparent map, the index works but afaik it seems( i think it's already mentioned in the list anywhere), that the index only works for one area = tile. May be this is related to this breaking of the index. By contrast Garmins Metroguide isn't affected from the same overlay even if the covered area of the Metroguide is smaller. OT: Another difference i observed which is OT but related to the index is the apperance of the fields in the address search part of my GPS(60csx). mtbopenmap de shows : 1. Housenumber 2. Street 3. City Metroguide instead shows 1. country/Region 2. City 3. Housenumber 4. Street There really seems a problem in the whole Region/country->city->street chain. For example as i already mentioned in an other post there are entries in the index, where informations are missing or wrong. If the cityname e.g. in the index entry is different from those of the city where the street belongs to( KOELN instead of KOLN), it never could be found if you enter the cities name. The location-autofill function you mentioned is only needed because of the missing or caotic address informations in the OSM data. And imo this function partially doesn't work as it is described in the code (locator.java) and creates sometimes unwanted results. cheers Gert ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] How to change a style file
Someoneelse (li...@mail.atownsend.org.uk) wrote: > Daniela Duerbeck wrote: >> Or better: Which POI should I give to a pub that it can be found in food >> and drink? > > Personally, in a style file I use: > amenity=pub [0x2a11 resolution 20] > > which translates as "British Restaurant". This works for me in England > but obviously may not be ideal for you... > > The "garmin_feature_list.csv" in the resources folder has a list of > other food-and-drink options. There's a page in the wiki somewhere that > describes what appears as what on various Garmin devices, but I can > never find anything on there. I think you mean this page: http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/POI_Types Unfortunately it's a) a bit unwieldy; and b) incomplete If someone could tell me how to complete the "Filed under category" column without tediously having to look through every category for a given POI, I might spend some time adding to it. -- 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] Reduce number of cuts in multipolygon processing
Hi WanMil
As Felix said, the lesscuts patch and the closewaysoutbox patches
conflict. I've attached the patch from applying 'lesscuts' to r1594,
resolving in favour of lesscuts where there was a conflict.
I'll commit that if there are no problems, but could you let me know
what can be done about the mp closeway patch. The code is so completely
different between the two patches that I wouldn't like to guess what to
do (if anything).
..Steve
Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java (revision 1594)
+++ src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java (working copy)
@@ -7,15 +7,19 @@
import java.util.ArrayList;
import java.util.Arrays;
import java.util.BitSet;
+import java.util.Collection;
import java.util.Collections;
+import java.util.Comparator;
import java.util.HashMap;
import java.util.HashSet;
import java.util.Iterator;
+import java.util.LinkedList;
import java.util.List;
import java.util.ListIterator;
import java.util.Map;
import java.util.Queue;
import java.util.Set;
+import java.util.TreeSet;
import java.util.concurrent.LinkedBlockingQueue;
import java.util.logging.Level;
@@ -639,15 +643,20 @@
|| hasPolygonTags(currentPolygon.polygon);
if (processPolygon) {
-
-List innerWays = new ArrayList(holes.size());
+List singularOuterPolygons;
+if (holes.isEmpty()) {
+ singularOuterPolygons = Collections
+ .singletonList((Way) new JoinedWay(currentPolygon.polygon));
+} else {
+ List innerWays = new ArrayList(holes.size());
for (PolygonStatus polygonHoleStatus : holes) {
innerWays.add(polygonHoleStatus.polygon);
+ }
+
+ singularOuterPolygons = cutOutInnerPolygons(currentPolygon.polygon,
+ innerWays);
}
-
-List singularOuterPolygons = cutOutInnerPolygons(
- currentPolygon.polygon, innerWays);
-
+
if (currentPolygon.polygon.getOriginalWays().size() == 1) {
// the original way was a closed polygon which
// has been replaced by the new cutted polygon
@@ -689,14 +698,15 @@
runIntersectionCheck(unfinishedPolygons);
runWrongInnerPolygonCheck(unfinishedPolygons, innerPolygons);
- // we have at least one ring that could not be processed
+ // we have at least one polygon that could not be processed
// Probably we have intersecting or overlapping polygons
// one possible reason is if the relation overlaps the tile
// bounds
// => issue a warning
List lostWays = getWaysFromPolygonList(unfinishedPolygons);
for (JoinedWay w : lostWays) {
-log.warn("Polygon", w, "is not processed due to an unknown reason.");
+log.warn("Polygon", w.getId(),
+ "is not processed due to an unknown reason.");
logWayURLs(Level.WARNING, "-", w);
}
}
@@ -704,8 +714,7 @@
cleanup();
}
-
- private void runIntersectionCheck(BitSet unfinishedRings) {
+ private void runIntersectionCheck(BitSet unfinishedPolys) {
if (intersectingPolygons.isEmpty()) {
// nothing to do
return;
@@ -716,7 +725,7 @@
boolean oneOufOfBbox = false;
for (JoinedWay polygon : intersectingPolygons) {
int pi = polygons.indexOf(polygon);
- unfinishedRings.clear(pi);
+ unfinishedPolys.clear(pi);
boolean outOfBbox = false;
for (Coord c : polygon.getPoints()) {
@@ -736,7 +745,7 @@
private void runWrongInnerPolygonCheck(BitSet unfinishedPolygons,
BitSet innerPolygons) {
- // find all unfinished inner rings that are not contained by any
+ // find all unfinished inner polygons that are not contained by any
BitSet wrongInnerPolygons = findOutmostPolygons(unfinishedPolygons, innerPolygons);
if (log.isDebugEnabled()) {
log.debug("unfinished", unfinishedPolygons);
@@ -782,6 +791,47 @@
polygons = null;
}
+ private CutPoint calcNextCutPoint(AreaCutData areaData) {
+ if (areaData.innerAreas == null || areaData.innerAreas.isEmpty()) {
+ return null;
+ }
+
+ if (areaData.innerAreas.size() == 1) {
+ // make it short if there is only one inner area
+ Rectangle outerBounds = areaData.outerArea.getBounds();
+ CoordinateAxis axis = (outerBounds.width < outerBounds.height ? CoordinateAxis.LONGITUDE : CoordinateAxis.LATITUDE);
+ CutPoint oneCutPoint = new CutPoint(axis);
+ oneCutPoint.addArea(areaData.innerAreas.get(0));
+ return oneCutPoint;
+ }
+
+ ArrayList innerStart = new ArrayList(
+areaData.innerAreas);
+
+ ArrayList bestCutPoints = new ArrayList(CoordinateAxis.values().length);
+
+ for (CoordinateAxis axis : CoordinateAxis.values()) {
+ CutPoint bestCutPoint = new CutPoint(axis);
+ CutPoint currentCutPoint = new CutPoint(axis);
+
+ Collections.sort(innerStart, (axis == CoordinateAxis.LONGITUDE ? COMP_LONG_START: COMP_LAT_START));
+
+ Iterator startIter = innerStart.iterator();
+ while (startIter.hasNext()) {
+Area nextStart
Re: [mkgmap-dev] [PATCH] Reduce the resolution of natural=coastline
Hi Felix, On Thu, Mar 04, 2010 at 04:50:34PM +0100, Felix Hartmann wrote: > It would be better to have more aggressive dp-filter instead. As I > wrote a while back, the increase of the dp filter in low resolutions > has to be much higher. Currently a level of 10 is very good, but too > strong for resolutions 23-21 and a bit too strong for 20. Better compared to what? Currently, all other water features are at resolution 18, while natural=coastline is at resolution=12. Resolution 12 means that all lakes that are mapped as natural=coastline will show up and seriously slow down the map drawing at wide zoom. It is just plain illogical that some water features disappear but others do not. It could be nice to have presets for resolutions in the style file, so that you could say 'resolution water' in all map features and define 'water' as 18, for instance. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index in gmapsupp
Nakor wrote: > Hello, > > I know that mkgmap does not include the index in the gmapsupp file. If > you want this you have to use MapSource to build the gmapsupp. > > Is there any plan for mkgmap to support this? What are the technical > limitations that prevents it to do it? > > Thanks, > > N. It does save the index file in the gmapsupp. I also had some problems making it working. I found the answer somewhere on the internet. what I do now is to run mkgmap twice. In the first run it generates the routable maps. In the second run it combines them in a gmapsupp and builds the index. This way I can search for an address and let my garmin route me to it. Simon ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] mkgmap hangs on this type of way
I have noticed for the last 2 weeks the mkgmap was hanging but nothing in a the change log jumped out as someting that may have caused it. After some debugging I have tracked it down to ways like: http://www.openstreetmap.org/browse/way/29416921 The debug log shows it stops when it hits one of these, I fixed a few by splitting the way and remove the roundabout tag from the incoming way. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] Reduce the resolution of natural=coastline
Well for me any lake marked with natural=coastline is plain wrong. Just people mapping for the renderers. A better solution would be, to simply have higher limits of how big a polygon needs to be at a certain resolution. As well as the DP filter aggressiveness, at resolutions lower than 20, we would need more aggressive dropping of small polygons. Dropping coastline already at 18, is superstrange if one is using --generate-sea=polygons. Everything is features we already have, they are just not yet dependant on resolution. Reducing sea to 18 from 16 is just a crutch (if the goal is to have faster map redraw) in comparison to more aggressive DP filter and larger minimum polygon size at lower resolutions. It's especially on resolutions 13-16 where ocean helps orientation and will be even more important once we have a non empty basemap for Mapsource. On 05.03.2010 12:10, Marko Mäkelä wrote: > Hi Felix, > > On Thu, Mar 04, 2010 at 04:50:34PM +0100, Felix Hartmann wrote: > >> It would be better to have more aggressive dp-filter instead. As I >> wrote a while back, the increase of the dp filter in low resolutions >> has to be much higher. Currently a level of 10 is very good, but too >> strong for resolutions 23-21 and a bit too strong for 20. >> > Better compared to what? Currently, all other water features are at > resolution 18, while natural=coastline is at resolution=12. Resolution 12 > means that all lakes that are mapped as natural=coastline will show up > and seriously slow down the map drawing at wide zoom. It is just plain > illogical that some water features disappear but others do not. > > It could be nice to have presets for resolutions in the style file, so > that you could say 'resolution water' in all map features and define > 'water' as 18, for instance. > > 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] [PATCH] Reduce the resolution of natural=coastline
On Fri, Mar 05, 2010 at 12:16:46PM +0100, Felix Hartmann wrote: > Well for me any lake marked with natural=coastline is plain wrong. Just > people mapping for the renderers. Yes, but some controversy arised when I converted Saimaa (the biggest lake of Finland) to a number of multipolygons. It was simply too big (thousands of ways) for a single multipolygon, and even as it is now, Osmarender and OpenCycleMap are having trouble, especially around Kuopio. > A better solution would be, to simply have higher limits of how big a > polygon needs to be at a certain resolution. As well as the DP filter > aggressiveness, at resolutions lower than 20, we would need more > aggressive dropping of small polygons. > Dropping coastline already at 18, is superstrange if one is using > --generate-sea=polygons. Agreed, it would be nice to see all big lakes at resolution 12. Could tuning the DP filter help realize that? Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap hangs on this type of way
Hi, > I have noticed for the last 2 weeks the mkgmap was hanging but nothing > in a the change log jumped out as someting that may have caused it. > After some debugging I have tracked it down to ways like: > http://www.openstreetmap.org/browse/way/29416921 > The debug log shows it stops when it hits one of these, I fixed a few > by splitting the way and remove the roundabout tag from the incoming > way. That roundabout isn't right because it has a tail! Nonetheless, mkgmap should not hang because of that so I will be committing a fix soon. Thanks for the report. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap hangs on this type of way
On 05.03.2010 13:12, Mark Burton wrote: > Hi, > > >> I have noticed for the last 2 weeks the mkgmap was hanging but nothing >> in a the change log jumped out as someting that may have caused it. >> After some debugging I have tracked it down to ways like: >> http://www.openstreetmap.org/browse/way/29416921 >> The debug log shows it stops when it hits one of these, I fixed a few >> by splitting the way and remove the roundabout tag from the incoming >> way. >> > That roundabout isn't right because it has a tail! Nonetheless, > mkgmap should not hang because of that so I will be committing a > fix soon. > > Thanks for the report. > > Mark > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > I had two more maps where mkgmap hang. a) Kosovo - map itself b) South America on index/tdb creation ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1595: Avoid infinite loops when following roundabout arcs.
Version 1595 was commited by markb on 2010-03-05 12:29:18 + (Fri, 05 Mar 2010) Avoid infinite loops when following roundabout arcs. The code worked OK for well formed roundabouts but could hang when the roundabout had a "tail". Now, it should not hang no matter how weird the roundabout is. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] mkgmap gets stuck on Kosovo
When I try to compile Kosovo from Geofabrik, with my style: https://svn.origo.ethz.ch/openmtbmap/ it gets stuck infinitely. Default style passes without problem. I know it's not the style that broken (compiles clean on every geofabrik country but South-America where it gets stuck too, however on index creation), but something only rendered using the style that triggers the bug. mkgmap does not output any error message, simply gets stuck. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Index in gmapsupp
Can you give more Infos or perhaps your script ? Thx 2010/3/4, Simon Siemonsma : > Nakor wrote: > > > Hello, > > > > I know that mkgmap does not include the index in the gmapsupp file. > If > > you want this you have to use MapSource to build the gmapsupp. > > > > Is there any plan for mkgmap to support this? What are the technical > > limitations that prevents it to do it? > > > > Thanks, > > > > N. > > It does save the index file in the gmapsupp. > I also had some problems making it working. > I found the answer somewhere on the internet. > what I do now is to run mkgmap twice. > In the first run it generates the routable maps. > In the second run it combines them in a gmapsupp and builds the index. > This way I can search for an address and let my garmin route me to it. > > Simon > > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > -- Wikipedia -- http://tools.wikimedia.de/~flacus/IWLC/ OSM -- http://osm.flacus.de/ ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap gets stuck on Kosovo
Felix, > When I try to compile Kosovo from Geofabrik, with my style: > https://svn.origo.ethz.ch/openmtbmap/ > it gets stuck infinitely. Default style passes without problem. > > I know it's not the style that broken (compiles clean on every geofabrik > country but South-America where it gets stuck too, however on index > creation), but something only rendered using the style that triggers the > bug. mkgmap does not output any error message, simply gets stuck. Add this to your Java options (next to the -ea): -agentlib:hprof=cpu=samples,depth=20,interval=1 then let mkgmap run for a while and interrupt it and you should get a java.hprof.txt file - please send it to me. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1596: Stop loops in ways being trashed by the short arc removal process.
Version 1596 was commited by markb on 2010-03-05 19:40:42 + (Fri, 05 Mar 2010) Stop loops in ways being trashed by the short arc removal process. Previously, when two (directly connected) nodes were merged because they were so close as to be indistinguishable all the points between them were trashed. That's OK for ways that go directly from one node to the other but if the way formed a loop (e.g. a contour line), removing all the points was the wrong thing to do. So now, nodes are not merged (and the points between them are not trashed) if the length of the arc between the nodes is greater than the minimum arc length. Also, reduced code nesting through the use of more "continue" statements. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v3] Reduce number of cuts in multipolygon processing
Hi WanMil
As Felix said, the lesscuts patch and the closewaysoutbox patches
conflict. I've attached the patch from applying 'lesscuts' to r1594,
resolving in favour of lesscuts where there was a conflict.
I'll commit that if there are no problems, but could you let me know
what can be done about the mp closeway patch. The code is so completely
different between the two patches that I wouldn't like to guess what to
do (if anything).
..Steve
Hi Steve,
v3 of the patch is taken from r1596.
I have slightly modified it compared to v2. Just some minor improvements
and the merging to the patches that have been already committed.
Summary: Reduce number of cuts in multipolygon processing
Reduces the number of cuts performed by multipolygon processing by
combining the cut of several polygons in one cut instead of n cuts.
This speeds up the processing for multipolygons consisting of lots polygons.
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
(revision 1596)
+++ src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
(working copy)
@@ -7,15 +7,19 @@
import java.util.ArrayList;
import java.util.Arrays;
import java.util.BitSet;
+import java.util.Collection;
import java.util.Collections;
+import java.util.Comparator;
import java.util.HashMap;
import java.util.HashSet;
import java.util.Iterator;
+import java.util.LinkedList;
import java.util.List;
import java.util.ListIterator;
import java.util.Map;
import java.util.Queue;
import java.util.Set;
+import java.util.TreeSet;
import java.util.concurrent.LinkedBlockingQueue;
import java.util.logging.Level;
@@ -41,7 +45,8 @@
private Set intersectingPolygons;
private final uk.me.parabola.imgfmt.app.Area bbox;
-
+ private Area bboxArea;
+
/**
* A point that has a lower or equal squared distance from
* a line is treated as if it lies one the line.
@@ -423,10 +428,7 @@
if (remove) {
// check if the polygon contains the complete
bounding box
- Rectangle bboxRect = new
Rectangle(bbox.getMinLat(), bbox
- .getMinLong(), bbox.getMaxLat()
- bbox.getMinLat(),
- bbox.getMaxLong() -
bbox.getMinLong());
- if (w.getBounds().contains(bboxRect)) {
+ if
(w.getBounds().contains(bboxArea.getBounds())) {
remove = false;
}
}
@@ -527,6 +529,11 @@
}
}
+ // create an Area for the bbox to clip the polygons
+ bboxArea = new Area(new Rectangle(bbox.getMinLong(), bbox
+ .getMinLat(), bbox.getMaxLong() - bbox.getMinLong(),
+ bbox.getMaxLat() - bbox.getMinLat()));
+
polygons = joinWays(allWays);
closeWays(polygons);
removeUnclosedWays(polygons);
@@ -639,15 +646,20 @@
||
hasPolygonTags(currentPolygon.polygon);
if (processPolygon) {
+ List singularOuterPolygons;
+ if (holes.isEmpty()) {
+ singularOuterPolygons = Collections
+ .singletonList((Way)
new JoinedWay(currentPolygon.polygon));
+ } else {
+ List innerWays = new
ArrayList(holes.size());
+ for (PolygonStatus polygonHoleStatus :
holes) {
+
innerWays.add(polygonHoleStatus.polygon);
+ }
- List innerWays = new
ArrayList(holes.size());
- for (PolygonStatus polygonHoleStatus : holes) {
-
innerWays.add(polygonHoleStatus.polygon);
+ singularOuterPolygons =
cutOutInnerPolygons(currentPolygon.polygon,
+ innerWays);
}
-
- List singularOuterPolygons =
cutOutInnerPolygons(
- currentPolygon.polygon, innerWays);
-
+
if
(currentPolygon.polygon.getOriginalWays().size() == 1) {
// the original way was a closed
polygon which
// has been replaced by the new cutted
Re: [mkgmap-dev] [PATCH v1] Multipolygon: Allow nested inner polygons
> I have found that some multipolygons use nested inner polygons. > Example: > * A forest (outer) with a lake (inner) that has an island (inner) which > is not a forest. (example: > http://www.openstreetmap.org/browse/relation/331402) > > By definition of the multipolygon relation > (http://wiki.openstreetmap.org/wiki/Relation:multipolygon) one has to > create two mps. But I see that it is a nice simplification lots of > mappers are using. > > Attached patch handles this situation. > The inner and outer roles are now used as follows: > * the outmost polygon must have role=outer (or role=) > * all outmost polygons with role=inner are not used (a warning is issued) > * all inside polygons with role=inner use their own tagging > * all inside polygons with role=outer use the mp tagging if available or > their own tagging if the mp is not tagged > * all inside polygons with role= are categorized automatically as > outer/inner depending on the nest level > * all inside polygons with role=outer without a direct ambient inner > polygon are dropped with a warning message (outer in outer polygon) > > Most of the renderers do not support inner in inner polygons but I think > it is a very reasonable extension of the multipolygon handling. > > This patch also improves the error messages. I haven't seen any more > "are not processed due to an unknown reason" messages and I look forward > that the community will also not be able to generate any more ... ;-) > > WanMil > There have been different opinions about this patch. There is one controversal point: Should mkgmap allow nested inner polygons? From my point of view: YES. Because it does not harm in any way. The nested inner polygons I analysed were all reasonable. Ok, they are not 100% compliant to the specification but this is common to lots of others things in (anarchic) OSM. At the moment I see two possible changes: 1. Issue a warning for any nested inner polygon but process it anyhow. 2. Reject nested inner polygons (and issue a warning). What a pity but they are not 100% compliant. Please let me know what's the opinion of mkgmap community and committers because I want the improvements of error messages to be committed. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] Multipolygon: Allow nested inner polygons
> There have been different opinions about this patch. > > There is one controversal point: > Should mkgmap allow nested inner polygons? > > From my point of view: YES. Because it does not harm in any way. The > nested inner polygons I analysed were all reasonable. Ok, they are not > 100% compliant to the specification but this is common to lots of others > things in (anarchic) OSM. > > At the moment I see two possible changes: > 1. Issue a warning for any nested inner polygon but process it anyhow. > 2. Reject nested inner polygons (and issue a warning). What a pity but > they are not 100% compliant. > > Please let me know what's the opinion of mkgmap community and committers > because I want the improvements of error messages to be committed. > > WanMil > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > If it is not difficult to implement (also for others) then I would propose integration. If however we knew that mapnik could not implement it without major rewrites, then I would not push it forward as long as it is not at least accepted tagging for a larger minority. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1595: Avoid infinite loops when following roundabout arcs.
Fixed my problem, thanks On Fri, Mar 5, 2010 at 11:29 PM, svn commit wrote: > > Version 1595 was commited by markb on 2010-03-05 12:29:18 + (Fri, 05 Mar > 2010) > > Avoid infinite loops when following roundabout arcs. > > The code worked OK for well formed roundabouts but could hang when the > roundabout had a "tail". Now, it should not hang no matter how weird the > roundabout is. > ___ > 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] Commit: r1597: Add landuse=wood (documented on wiki).
Version 1597 was commited by marko on 2010-03-05 21:47:08 + (Fri, 05 Mar 2010) Add landuse=wood (documented on wiki). It is similar to natural=wood and landuse=forest. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
