be interesting 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
rants, accommodation,
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
ap so any
hints where I can start 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
oes not remove the
mulitpolygon connections between outer and inner rings.
3. Up to now 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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
> 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
fix (hopefully :-).
* 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
the green 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/MultiPolygonRel
to the first 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
ease the maxEntries variable in findCpa. The
current value 50 seems to be too low. Set it much higher might
reduce the number of intersects calls. But this also depends on the
geometry of the polygons.
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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
t) tag only its
useless to parse all other parameters.
You are right that this information is also contained in the style files
and in future a better patch should automatically compile this
information from the style files.
WanMil
___
mkgmap-d
th lots of points.
* It should work with the current PolygonSplitter. This is achieved by
creating simple polygons.
At the moment I am using your idea of simple polygons and try a new
implementation using the java.awt.Area class that is also used in the
PolygonSplitter. I hope this will achieve
dback!!
WanMil
Note: The code is not ready for the trunk. Some documentation and better
method naming will be applied in one of the next patch.
Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
===
--- src/uk/me/par
Lake Neusidel in Austria is divided by the country border to Hungary.
Therefore I suppose it is not completely contained in the OSM file. At
the moment the algorithm is very strict with discarding non closed ways.
This has to be addressed in one of the next versions.
WanMil
> Well speed se
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
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?
t;lake Neusiedel" is completely empty. No water at all. 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
__
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 optio
>
>
> 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
be easy to extract this part of it.
>
Extracting this part should not be the problem. But I cannot say
anything about performance. This has 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.
Afte
e any 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
39612875 (point 474857138 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
http://www.topogra
me (and others)
to calculate the intersection point with the bounding box.
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
I think it would improve the splitter files if the overlap is removed
and the ways 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
http://www.topografix.com/GPX/
e which is constructed with two overlapping lines connecting the
outer polygon with the inner hole then the overlapping lines are removed
and the inner hole is handled as independent polygon.
I don't know if that's a problem.
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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
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
ebug statements).
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
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 n
>
> 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
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
Sorry, I forgot to include one class in the last patch so that it did
not compile.
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
> 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
>
> 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
> It's interesting that the line is not visible in the sea polygons.
>
My workaround was based on the assumption that all polygons created by
the mp code will be clipped to the bounding box later (by the style
code). Can you confirm that?
___
mkgmap-d
>
> 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 w
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 wh
at its half. For some islands this is true but there are
several islands and lines 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
se I think it's the tile splitter.
The splitter puts only parts of the ways that crosses the tile bounds to
the resulting tile file. The handling for these incomplete mp ways on
the tile border is on the list which must be implemented next.
By the way: did you see that lake with the old mp c
y speeds up 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/Multi
thousands of lakes and
> islands 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.
It is completely cut away in the Geofabrik dump.
So what has to be done to solve the problem?
1. Inform the geofabrik people that they may increase their boundaries.
maybe they could include the three or twelf-mile-zone around a country?
2. The format of an OSM dump should be extended by the possibi
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).
>
>
ts.openstreetmap.org/pipermail/osmosis-dev/2010-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 mai
g is. But I can say something about the
mp code.
The mp code should not modify any original way from OSM. The posted
warnings 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
Attached patch has better formatting and some other 'nitpicked' (Marko
you are totally right!) improvements.
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
===
--- src/uk/me/parabola/mkgmap/
ted the whole mulitpoylgon code so I am very interested 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
e an obvious straight edge which is
>> spurious, and areas where the inside and outside of the polygon have
>> swapped over.
>
> The new MP code has a problem with inner polygons that touch the outer.
>
> What you say makes me think that whenever the splitter splits an inne
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 hun
5 FEIN (MultiPolygonRelation): check polygon 1
2010/01/26 18:46:45 FEIN (MultiPolygonRelation): 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):
Am 26.01.2010 20:00, schrieb Marko Mäkelä:
> Hi WanMil,
>
> thank you for having a look.
>
> On Tue, Jan 26, 2010 at 07:05:39PM +0100, WanMil wrote:
>>> On Mon, Jan 25, 2010 at 09:39:56PM +, Adrian wrote:
>>>> I don't think these warnings are bogus.
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.
from the ways.
Another solution could be that ways get an "used by mp" tag so that
other steps in mkgmap don't try to autoclose these ways. This would give
a chance to option 2.
What do you think? Any ideas about good solutions for the tagg
ellow=1 and blue=0.
>
Yeah, 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
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.
&
ion
(http://wiki.openstreetmap.org/wiki/Relation:multipolygon) that multiple
outer polygons are allowed. And from my point of view it doesn't harm
anything.
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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
ts 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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Am 31.01.2010 10:18, schrieb WanMil:
>
>>> + log.warn("Way", w.getId(), "intersects
>>> itself.");
>>> + log.warn("The way is composed of");
>>> +
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
or not but
in the end they exist. To detect overlapping lines the mp 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 m
elation. The outer
way(s) should 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
> 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 t
"waterway").
This keeps all line tags (like highway) so the original still make use
of their line-tagging.
If the multipolygon contains any of the polygon tags, then all tags of
the multipolygon are copied to the resulting polygons (additionally to
the merge of tags)
WanMil
gmap style file
* Your mkgmap parameters
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
_
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
ultipolygon
code of mkgmap.
If there is no good reason I don't want to change that.
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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 diff
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
gt; 10%.
Please test this patch against your well known tiles. It would be
perfect if someone has a tile and knows its minimum memory requirement
for mkgmap. This patch should lower it.
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/Tags.java
=
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 appe
key.equals("highway"))
{
exits.add(currentNode);
currentNode.addTag("osm:id", "" + currentElementId);
}
It might be fixed by changing it to "highway".equals(key).
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev/2010q1/007086.html) which
is not yet committed 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
__
lar ways. Additionally the polygons created by the multipolygon
code could be tagged 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
gle polygon type.
So what you see are the cutting lines created by the mkgmap multipolygon
code.
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
oundary polygon and additionally the
polygons created by the multipolygon code contain ALL tags (boundary=...
admin-level=... name=...). But the polygons created by the mp code are
additionally tagged with mkgmap:mp_boundary=yes.
I don't mind how the tag handling should be. Maybe the sty
Am 12.02.2010 20:06, schrieb Carlos Dávila:
> WanMil escribió:
>>> Compiling Spain I get several warnings similar to the one below, that
>>> point to data that are correct (or it seems to me).
>>>
>>> |2010/02/12 09:26:39 ADVERTENCIA (MultiPolygonRelat
21 FAILED at 1462.
> 21 out of 21 hunks FAILED|
> Can you give me some hint?
I am also no expert for patching. I use the Eclipse patch so I don't
know any parameters.
One basic question: Did you patch the source code? Patching does not
work with the binary distribution. You must patch
> 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") ||
>>
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
> 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
__
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
Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRel
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...?!?
>>>>
>&
e default style gives an example with name_tag. So this should be
corrected.
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> Hi WanMil,
>
>> 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.
>
> F
> 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
> 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'
> 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,
>
> Mar
1 - 100 of 1561 matches
Mail list logo
