to preparse the style and the typ file
to autocreate a whitelist file.
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
,
supermarkets, pharmacies, that's all things I want so see SOMETIMES
while I go hiking but I am also happy if I can switch them off.
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
and what I have to consider are very welcome!!
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
the MultiPolygonRelation class does support one outer ring
only. This must be changed so that the MultiPolygonRelation class can
create multiple polygons in the garmin format. I do not fully understand
how the Garmin map is assembled from the mkgmap map format, so any hint
is appreciated.
WanMil
Aside from that, the multipolygon code already does duplicate the way
before removing the tags from the original. Duplicating it again can't
be the right solution.
Only the outer way is duplicated. Inner ways seems to be kept but all
tags are removed.
WanMil
:-).
* I don't know if my synthetic ids are generated well. I think there
should be one synthetic generator for whole mkgmap?
Have a happy new year (with the multipolygons case fixed :-)))
WanMil
package uk.me.parabola.mkgmap.reader.osm;
import java.awt.Polygon;
import java.awt.geom.Line2D;
import
line).
Next thing to do is to bugfix the PolygonSplitter.
Comments are welcome!
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
published MultiPolygonRelation.java
by WanMil - I'm not using the multipolyn branch but only the file plus
the new patch by WanMil).
That's good news! The mp branch differs only by the
MultiPolygonRelation.java so there should be no difference between your
test and the mp branch.
WanMil
I have added some javadoc.
Could someone please commit or deny the patch. It is open for a long
time, no one has complained about it and I think it's a useful enhancement.
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
is also contained in the style files
and in future a better patch should automatically compile this
information from the style files.
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
the java.awt.Area class that is also used in the
PolygonSplitter. I hope this will achieve the requirements.
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
of the processed OSM file.
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Am 09.01.2010 00:05, schrieb Johann Gail:
Changes:
* Polygons with inner polygons are now divided into several polygons.
It's much faster and the PolygonSplitter cannot destroy them any more.
Hello WanMil,
this change could have some other side effects. (As observed and
described
Am 09.01.2010 11:25, schrieb Ralf Kleineisel:
On 01/09/2010 10:08 AM, WanMil wrote:
Another idea is to add some specific tags by the mulitpolygon algorithm
that link to the other pieces of the formerly big forrest. This could be
evaluated by the SizeFilter?
Another idea (don't know
. Only some
puddles.
mp: lake Neusiedel is filled with water. Only some parts in the south
are empty and some of the southern islands are inverted and flodded with
water. This can be easily fixed in mulitpolygon code.
WanMil
___
mkgmap-dev mailing list
Is there any mkgmap tag yet to avoid this? (like mkgmap:noaddpoitoarea=yes)
WanMil
AFAIK the POI searches work only with the actual POIs that are generated, not
the polygons. So this should be no big problem. You should make sure though
that the --add-pois-to-areas option doesn't generate
Ralf Kleineisel schrieb:
On 01/09/2010 10:08 AM, WanMil wrote:
Another idea is to add some specific tags by the mulitpolygon algorithm
that link to the other pieces of the formerly big forrest. This could be
evaluated by the SizeFilter?
Another idea (don't know if this is possible
to be tested.
At the moment I will try to finish the mp code where it is. This should
improve the situation very much compared to the current trunk.
After that we can start to move the splitting code to the filter chain
which sounds like a good idea.
WanMil
possibility to get the more or less exact bounding shape of
an OSM dump? Otherwise I don't see any chance to close polygons reasonable.
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
and 474857142)
that lie next to but in the bounding box are not contained in the tile?
The described behaviour of the tile splitter makes it complicated to
implement a reasonable behaviour of the mulitpolygon code on the borders
of the tiles.
WanMil
gpx xmlns=http://www.topografix.com/GPX/1
.
3rd: The relation handling is ok. Include them if one or more nodes/ways
are contained in the tile.
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
are bounding box complete plus first nodes outside the
bounding box.
Anyhow I was impressed how fast the splitter worked on my lame old
computer. That's good work!
WanMil
gpx xmlns=http://www.topografix.com/GPX/1/1;
xmlns:gpxx=http://www.garmin.com/xmlschemas/GpxExtensions/v3;
xmlns:gpxtpx=http
The attached patch changes the OSM-URL (toOSMURL()) so that a small
needle is shown at the location of the Coord.
The current OSMUrl has no clear indication of the real location of the
Coord.
WanMil
Index: src/uk/me/parabola/imgfmt/app/Coord.java
(I haven't search the code
base yet). The class ensures that an id is used only once.
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
Uups, I sent the wrong patch. I renamed one method of the new
FakeIdGenerator in this patch (makeFakeId instead of getFakeId).
WanMil
The Osm5XmlHandler creates fake ids for automatically generated
elements. The attached patch sources this out to the new FakeIdGenerator
which can also be used
).
To all: please check this patch and post all problems.
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/FakeIdGenerator.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/FakeIdGenerator.java (revision 0)
+++ src/uk/me/parabola
The attached patch contains a merge from the mp branch and fixes lots of
multipolygon issues.
I have also added some more javadoc and code comments, renamed methods
and variables and removed not very useful logging statements.
The mp branch is no longer needed.
WanMil
Index: src/uk/me
Am 16.01.2010 22:31, schrieb Mark Burton:
Hi WanMil,
The attached patch contains a merge from the mp branch and fixes lots of
multipolygon issues.
I have also added some more javadoc and code comments, renamed methods
and variables and removed not very useful logging statements.
The mp
WanMil,
I will try to reproduce your errors and to improve the error messages.
I wasn't complaining about the quality of the messages, merely telling
you that they were happening.
You should complain :-) Logging fake ids does not help anyone to have a
look on the OSM data. The warnings
not share any lines and points with any of the inner areas.
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
(revision 1484
Hi WanMil,
W The attached way 39612875 is still missing two nodes 474857138 and
W 474857142.
I've just taken a look at this. Those two nodes don't appear in the
austria.osm
file at all, so it's not too surprising they're not in the splitter output
either :)
Regards,
Chris
Oh, so
Hi WanMil,
The v3 patch is working well with the Baltic map. The main land masses
are there and I haven't yet spotted any missing islands.
One issue, the boundaries of the tiles are visible on the land at all
zoom levels (see visible-tile-boundaries.png). The boundaries are not
visible
WanMil,
Good news - I don't think it's your problem. I disabled the sea
generation completely and the lines on the tile edges are still there.
Haven't a clue what's causing them (and I don't care because they don't
show up when I use generate-sea=polygons).
One issue that I don't think
the over-large sea background when
generateSeaUsingMP is true?
Attached patch (against the mp branch) solves this.
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
===
--- src/uk/me/parabola/mkgmap/reader/osm
Hi Steve,
On 18/01/10 18:05, WanMil wrote:
Attached patch (against the mp branch) solves this.
OK thanks, applied.
Is everyone happy that this is now a big improvement over trunk?
It's performed well when processing the Baltic map.
One thought, and I may be completely wrong here
for which this rule does not match.
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
the calculation. I expect a minimum speedup of
factor two.
So if you don't want to be a kind of test candidate please throw it
away. Otherwise feel free to compile Norway with it. I am curious about
the results.
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
should be the ultimate acid test for multipolygon handling.
acid test is great! Finland will be my next favourite test cancidate.
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
be extended by the possibility to
define the exact borders of the OSM dump. The osmosis tool could then
add the boundary used to extract the OSM dump to the dump. This solves
99% of the problems originated by inexact dumps and unknown boundaries.
WanMil
Am 20.01.2010 10:42, schrieb Chris-Hein Lunkhusen:
WanMil schrieb:
This is caused by the new mp code. The methods contains(JoinedWay,
JoinedWay) and createContainsMatrix(..) are not optimal for large and
lots of polygons (both apply to Norway).
And what about the realy large boundary MPs
-January/000452.html
Hopefully the osmosis people support our requirements. Then a lot of
discussions and guess how to close an unclosed polygon algorithms are
superfluous.
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http
link to original OSM ways so mp should not be the reason.
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Attached patch can be summarized very easy:
* Major speedup for mp code
Please test and commit if no problems arise.
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
===
--- src/uk/me/parabola/mkgmap
in
problems that still exist.
Can you give a relation id which makes problems?
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
WanMil wrote:
What do you mean with tagging the 'inner' of a multipolygon? I have
reimplemented the whole mulitpoylgon code so I am very interested in
problems that still exist.
Can you give a relation id which makes problems?
I'm using r1505 on an Oregon 300 using the latest firm/software
the outer.
What you say makes me think that whenever the splitter splits an inner
polygon it's going to cause trouble because it splits outers/inners
along the same line so they will always intersect then.
Whaddyathink WanMil?
Mark
Two things to remember:
It is the point of view to say
Am 25.01.2010 23:03, schrieb WanMil:
Hi Adrian,
I don't think these warnings are bogus. Mkgmap definitely has problems
with multipolygons. The Languedoc-Roussillon extract (southern France)
from Geofabrik provokes about a hundred of these warnings. But I believe
that the intersected ways
): createMatrix for 2
polygons took 0 ms
2010/01/26 18:46:45 FEIN (MultiPolygonRelation): Containsmatrix
2010/01/26 18:46:45 FEIN (MultiPolygonRelation): {1}
2010/01/26 18:46:45 FEIN (MultiPolygonRelation): {}
WanMil
___
mkgmap-dev mailing list
mkgmap-dev
The warning message can be upgraded to error messages again if the
multipolygon code has improved its tile bounds handling.
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
===
--- src/uk/me/parabola/mkgmap
ways that are used in
multipolygons.
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
(revision 1533)
+++ src/uk/me/parabola
Marko,
On Thu, Jan 28, 2010 at 08:56:42PM +0100, WanMil wrote:
Current mp implementation does not remove polygon tags from unclosed
ways. I have observed that the unclosed polygons sometimes are closed in
a later step of mkgmap. This causes flooding of areas around seas.
Finnland
, I have seen this also in some previous runs.
Tomorrow I will compile finnland with my GPX analysis. This stores all
ways processed by the multipolyon code as GPX files which is very good
for analysis. I think then I can say more where the problems are.
WanMil
Hi Marko,
Hi WanMil, Mark, all,
I analyzed all the multipolygon errors and warnings I got for today's
finland.osm.bz2 from Geofabrik, without --generate-sea.
that's great!!
Most of them can apparently be blamed on missing boundary information.
I wrote the relation IDs an explanations
The mp code warns if a polygon intersects itself.
This has a drawback to performance by ~10% in log level WARN is turned
on. With log level ERROR the check is not performed.
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
/63240005.osm.gz: Way 4611686018427388496 intersects itself.
2010/01/31 10:10:31 WARNUNG (MultiPolygonRelation):
data/63240005.osm.gz: The way is composed of
2010/01/31 10:10:31 WARNUNG (MultiPolygonRelation):
data/63240005.osm.gz: - http://www.openstreetmap.org/browse/way/31753632
WanMil
Am 31.01.2010 10:18, schrieb WanMil:
+ log.warn(Way, w.getId(), intersects
itself.);
+ log.warn(The way is composed of);
+ logWayURLs(Level.WARNING, -, w);
Sorry, I do not seem to be getting any output from
Attached patch fixes a problem with the log.log(Level, Object...)
method. Logging messages were logged only if the logging level was set
to INFO or lower no matter which logging level was provided as parameter.
WanMil
Index: src/uk/me/parabola/log/Logger.java
probability that inner/outer roles are
exchanged or that the inner polygon does not belong to the multipolygon.
* Remove polygon tags from unclosed ways because sometimes they are
closed later in mkgmap.
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
Hi WanMil,
can you please investigate this:
2010/02/01 09:05:31 WARNING (MultiPolygonRelation): 63240001.osm.gz: Polygon
4611686018427388326 intersects itself.
2010/02/01 09:05:32 WARNING (MultiPolygonRelation): 63240001.osm.gz: The
polygon is composed of
2010/02/01 09:05:32 WARNING
code must be
changed. At the moment I don't have a good and performant algorithm to
do that, so I cannot say for sure if that's possible or not.
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo
be left untagged, unless they describe something in their
own right.). If these multipolygons are dropped the tag information of
the multipolygon is lost.
I propose to revert this commit unless there are hard reasons for it.
WanMil
___
mkgmap-dev mailing
On Thu, Feb 04, 2010 at 08:50:49PM +0100, WanMil wrote:
I have doubts if that's a good idea.
If multipolygons are splitted by splitter it is possible that some
polygons are dropped because they are not inside the tile bounds.
This makes it possible that the outer ring survives only
Sorry that I cannot give you a simple solution but as long as things are
complicated their solutions also tend to be complicated. Maybe Mark can
give you more information as he has done some work on the generate-sea-code.
WanMil
___
mkgmap-dev mailing list
from the Osm5XmlHandler.
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
(revision 1563)
+++ src/uk/me/parabola/mkgmap/reader/osm/xml
Hello Thilo,
Hello WanMil,
if I understand your post correctly the problem is with the osmosis software
and it's not likely to be fixed soon.
There are two problems:
1st: osmosis does not provide the boundary shape used to split the dump
file. So mkgmap cannot differ if there is no data
surrounds the
bounding box.
Ouch... This check is missing.
Attached patch does not remove ways that completely contain the bounding
box.
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
===
--- src/uk
The patch enables the multipolygon code to handle overlapping lines of
polygons.
Please test it and give feedback to me.
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
===
--- src/uk/me/parabola
Hello Wanmil,
I tried your patch and it did not work for me. As Steve pointed out the
problem, I commented all the code of the patched removeWaysOutsideBox()
and the sea multipolygon is generated as expected. I don't know if it is
linked but there are still some artefacts which appear
minimum memory requirement
for mkgmap. This patch should lower it.
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/Tags.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/Tags.java (revision 1566)
+++ src/uk/me/parabola/mkgmap
Hello Wanmil,
I tried your patch and it did not work for me. As Steve pointed out the
problem, I commented all the code of the patched removeWaysOutsideBox()
and the sea multipolygon is generated as expected. I don't know if it is
linked but there are still some artefacts which appear
.
This is the key.equals(highway) part:
if((val.equals(motorway_junction) ||
val.equals(services))
key.equals(highway))
{
exits.add(currentNode);
currentNode.addTag(osm:id, + currentElementId);
}
It might be fixed by changing it to highway.equals(key).
WanMil
and which fixes the problem. I think it will be
committed within the next days.
The deformations do not look good. I think the problem is that mkgmap
rounds the exact OSM coordinates to lower resolution garmin coordinates.
WanMil
___
mkgmap-dev mailing list
with mkgmap:mp_boundary=yes. This tag could be
evaluated in the style definition so the style could differ between the
polygons created by the mp code and the lines not touched by mp code.
What do you think? (I am not an expert of the style processing)
WanMil
multipolygon
code.
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
question: Did you patch the source code? Patching does not
work with the binary distribution. You must patch the source code and
recompile mkgmap.
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo
On Thu, Feb 11, 2010 at 07:59:01PM +0100, WanMil wrote:
The Osm5XMLHandler sometimes throw a NullPointerException in line 397.
This is the key.equals(highway) part:
if((val.equals(motorway_junction) ||
val.equals(services))
key.equals(highway))
{
exits.add(currentNode
Am 12.02.2010 21:57, schrieb Carlos Dávila:
WanMil escribió:
I'll test it and give feedback
Thanks! That will speed up the commit.
I'm not very fit with patches. I tried |patch -p 1
mp_linesoverlapping_v1.patch| within mkgmap root directory, but it
didn't work
|Hunk #1 FAILED at 38.
Hunk
On 02/13/2010 05:08 PM, Charlie Ferrero wrote:
I'm relieved to hear it's not just me. Maybe it depends on the GPS unit?
My screenshot is from an eTrex Legend HCx.
I see the same effect on an Oregon (Firmware 3.6).
WanMil
___
mkgmap-dev mailing
Am 14.02.2010 01:11, schrieb Carlos Dávila:
WanMil escribió:
Am 13.02.2010 17:56, schrieb Carlos Dávila:
WanMil escribió:
I have attached a patch for revision 1568. Hopefully this will
work...?!?
WanMil
I reply off list because of the size of the attachments.
Your patch seems to drop
had forgotten how it worked somewhat, but looking at the code
it should work in the way you want: the name tag is replaced by the
first matching tag in the list that exists before processing the way.
..Steve
The default style gives an example with name_tag. So this should be
corrected.
WanMil
Hi WanMil,
I downloaded the finland OSM dump from geofabrik from today (Feb
15th).
I used splitter v105 and the areas.list file from
http://www.polkupyoraily.net/osm/ to get three tiles.
Then I tried that patch:
* I got no warning for mp 404644
* I got only one unknown reason warning
Compared to v3 (posted by Carlos in thread Wrong multipolygon
warnings) some unused debug messages have been removed.
The patch enables the multipolygon code to process multipolygons with
overlapping lines.
WanMil
Marko, Steve,
I didn't get any negative feedback. Could you please commit
Hi WanMil,
I didn't get any negative feedback. Could you please commit this
patch?
You did get some feedback from me, but it is not that critical. I
committed the patch in trunk r1575.
Thank you for your ongoing efforts,
Marko
Yeah, but it was not too *negative* ;-)
Thanks
).
Question to all: Which issues must be fixed before releasing another
stable version?
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil and others,
Some time ago, there was discussion that the MultiPolygon code in
mkgmap should tag the lines that it generates when splitting
multipolygons to polygons.
I think that there is a genuine need to split large multipolygons to
smaller multipolygons in the OSM data too
=water, mkgmap:mp_created=yes
Polygon B1 - landuse=grass, mkgmap:mp_created=yes
Maybe you could play a bit with this and post any new ideas how to
improve the tag handling in the mp code.
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
me if I am wrong: As long as
you don't enable the sea generation multipolygon processing should not
take too much time(?)
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
there are no large multipolygons the performance stays quite the
same.
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
(revision
.
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
(revision 1584)
+++ src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
Hi WanMil,
Have you looked at merging adjacent multipolygons?
There was some controversy on the Finnish forumhttp://
forum.openstreetmap.org/viewforum.php?id=15 but I was not alone with
the opinion that lakes should be defined as multipolygons, no matter
how complex
how much performance this will cost.
* Any other ideas?
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil,
So in the end what does it mean? The artificial cut will be handled
as one segment of the outer polygon and will therefore be tagged with
the multipolygon tags. This is the same as happens with all inner
cuts by the mp code.
That is not a big deal with artificially split natural
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
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
. There should
be some more improvements in cutting.
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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
Index: src/uk/me/parabola/mkgmap/reader/osm
WanMil schrieb:
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)
But neither mapnik nor osmarender show the inner
in the mkgmap logfile?
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Tue, Mar 2, 2010 at 1:12 PM, Torsten Leistikowde_m...@gmx.de wrote:
WanMil schrieb am 02.03.2010 18:48:
The patch supports the complete multipolygon specification. And
additionally it is tolerant towards incorrect (but reasonable)
multipolygons.
So why should mkgmap be restrictive
The patch closes all ways having both endpoints on the same side outside
the bounding box. In this case it is not necessary to check if closing
the way intersects the way itself.
This fixes most (but not all) of the outstanding tile splitter problems.
WanMil
Index: src/uk/me/parabola/mkgmap
1 - 100 of 1391 matches
Mail list logo
