Hi Gerd
I've just been experimenting and looking at shapes and rounding-to-low
-resolution can easily cause self-intersections.
It isn't just a problem with sea, or even with multipolygon hole
cutting. GPSMapEdit reports over 1000 in my test area. This number
reduces only slightly when I disable
Hi Felix
I don't think there is any way to do maths on tag values.
It should not be too difficult to implement additional variable filters
that do a simple maths op with a constant, eg:
{set population='${population|divide:"7"}'}
Ticker
On Wed, 2021-05-05 at 22:58 +0800, Felix Hartmann
else use of a division factor for values that I can think of. So
> right now only 3.28, 3.28^2, 3.28^3 and so on is possible (i did not
> actually check if it is possible to convert twice, but think so).
>
> On Fri, 7 May 2021 at 16:56, Ticker Berkin
> wrote:
> >
> (points, shapes, other lines) as well but I guess roads are the most
> important?
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 10. Mai 2021 11:51
> An: Development list for mkgmap
&g
okay, so I'll wait for your results. The v1 patch always produces
> larger files with normal maps without visual effects, so it seems to
> split more often than needed (or prohibit merging too often)
>
> Gerd
>
>
> Von: mkgmap-dev
Hi
Is it a particular problem to never merge ferry lines? If derived from
a relation, what elements is the relation using? Probably these
shouldn't be merged either.
Ticker
On Mon, 2021-05-10 at 09:57 +, Gerd Petermann wrote:
> Hi all,
>
> found another problem: In what situation should
Hi all
Maybe railway=platform shouldn't generate a routable line.
Pure duplication of (parts of) roads with identical Garmin img
attributes could be suppressed. These could come from duplication by
the style or distinct OSM ways. In the case of platform=railway, I'd
have thought it to be better
in a relation but never merge them in RoadMerger.
> Haven't looked at the details yet. There were some special cases in
> British Columbia with this.
>
> Gerd
>
> ____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet:
ou see a need for the possibility to have oneway roads which
> don't have the direction flag set?
> In trunk it will not matter reg. merging, in the branch it might
> allow more merging in the overview map.
>
> Gerd
>
> ________
> Von: mkgmap-dev
Hi Gerd and others
I'm starting a dedicated thread as previous posts are split between
various svn commits.
Looking at the current trunk code and ignore-oneway-for-lines.patch,
there are bits I don't understand or didn't expect.
This is what I hope for:
--line-types-with-direction lists the
Considering the question of hasDirection and resolution.
If the same lineType looks identical, regardless of hasDirection, then
there is no point in setting hasDirection=true as the only effect will
be to inhibit merging.
To get the look of direction at high-res and no-direction when zoomed
out,
.
Ticker
On Mon, 2021-05-17 at 11:29 +0100, Ticker Berkin wrote:
> Hi Gerd and others
>
> I'm starting a dedicated thread as previous posts are split between
> various svn commits.
>
> Looking at the current trunk code and ignore-oneway-for-lines.patch,
> there are bi
Hi Gerd
Sorry - in my mind, old versions also tried reversing if allowed.
Ticker
On Mon, 2021-05-17 at 11:13 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I do see a need for the --allow-reverse-merge option, at least for
> those styles which rely on the old behaviour that lines are not
>
Hi all
I think lines with and without direction shouldn't be merged. The only
reason, as far as I see, for having direction on lines is that they
have a different visual representation.
Ticker
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
> mkgmap:has-direction=no in the default style?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Samstag, 15. Mai 2021 20:08
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Commit r4715: rew
least the OFM style still uses this and I forgot what it is good
> for.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Samstag, 15. Mai 2021 17:38
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Commit r47
Hi all
I've been testing the effect of the DIR flag (0x40) in various ways:
GPSMapEdit: shows a direction arrow on all standard line types. It
appears not to read this flag for extended line types, but, if set
manually, show an arrow on these as well.
eTrex HCx: For all line types, including
dy said no, I agree with that.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Samstag, 15. Mai 2021 16:04
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Commit r4715: rework of options for
Assuming that the output device shows the direction on lines with
direction and doesn't on lines without:
Another example is, say, [intermittent] water using type [0x26] 0x1f.
stream/river will have a direction and canal/ditch won't.
There will be others, under the control of the Style/TYP, so I
with my own style. For me,
> Mdr11.preWriteImpl() is the most problematic part reg. OOM errors.
>
> Maybe look at the code which uses LargeListSorter.
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesende
ally
> named roads causing extreme run times.
> This depends on the style. Some styles add a name like "tr2" for each unnamed
> track with tracktype=grade2.
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag von
> Ticker
Hi Gerd
When loading precomp sea tiles, shouldn't SeaGenerator should replace
all nodes on the edges of all the precomp tiles used with nodes from a
shared coordPool. Maybe it needs to replace even more to cover the cut
lines.
Ticker
On Thu, 2021-05-20 at 14:09 +, Gerd Petermann wrote:
>
s, esp. when many small parts can be
> merged. Maybe this can be improved by sorting so that it merges from
> top to bottom.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 19. Mai 2021
gt;
> Gerd
>
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 19. Mai 2021 17:41
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Problems with sea in overview map
>
> Hi Gerd
>
s?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Samstag, 15. Mai 2021 17:47
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Commit r4715: rework of options for reverse
> merge
>
> Hi all
>
&
Hi Gerd
I hope the only case where my algo still has problems is when 2 lines
intersect the cut line at identical points and they have the same area
to that side of the line (implying they follow exactly the same path or
intersect each other). This should generate the warning:
"Lines hit
Hi Gerd
I have to design a shape that does this and think what it means. With
the extra handling needed for identical opposite lines it will be easy
to detect. Maybe possible to just chuck it.
I'm out for the rest of the day so can't do anything until tomorrow.
Ticker
On Wed, 2021-05-26 at
Hi Gerd
I think we need to step back and consider the various stages towards a
good overview map which I see as:
0/ MultiPolygons spliting (just added this after I wrote the rest)
1/ subDiv shapeMerge
2/ filter chain into the ovm_ img
3/ loading all the ovm_ img into the combiner
4/ any special
Sorry - sea.zip!
On Tue, 2021-05-25 at 12:36 +0100, Ticker Berkin wrote:
> Hi Gerd
>
> I'm getting very confused by this. When I build with my trunk (some
> filter order changes + a few others), I see a whole lot more that
> JOSM
> shows. It and your 6324001.img just show a ce
_____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 25. Mai 2021 12:51
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] special case where splitting fails without
> a log message
>
> Hi Gerd
>
> OK - I've reproduced thi
Hi Gerd
OK - I've reproduced this. Is split-failed.osm self-intersecting? I'm
not sure how to tell from Josm, but it looks like it isn't. I get the
messages from shapeSplitter because it thinks it is and then the result
is not good - as expected.
I'll investigate more.
Ticker
On Tue,
Sorry - excess stuff in patch, correct one now.
Ticker
On Tue, 2021-05-25 at 17:46 +0100, Ticker Berkin wrote:
> Hi Gerd
>
> Patch attached that I hope fixes the splitting problem.
>
> I haven't looked at your change yet, but your split-failed.osm test
> had, and needed, lots
means with "has a jitter". Maybe
> only those are problematic.
>
> Gerd
>
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 25. Mai 2021 14:00
> An: Development list for mkgmap
> B
Sorry - excess stuff in patch, correct one now.
Ticker
On Tue, 2021-05-25 at 17:46 +0100, Ticker Berkin wrote:
> Hi Gerd
>
> Patch attached that I hope fixes the splitting problem.
>
> I haven't looked at your change yet, but your split-failed.osm test
> had, and needed, lots
Hi Gerd
shapeSplitter will have problems (ie get it wrong some of the time)
where there are in/out lines to a hole that share the same cut point as
a line that is the boundary between a shape and hole; could be many
holes (or shapes) and many lines. The simple sort/dedupe I was doing
isn't
necting lines shorter,
> but I don't see yet how I can avoid to have connecting lines like
> that.
>
> Gerd
>
> ____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 1. Juni 2021 17:18
> An: Development li
Hi Gerd
I'm thinking this is a problem with high-precision points and the
coordPool
Ticker
On Wed, 2021-06-02 at 10:23 +0100, Ticker Berkin wrote:
> Hi Gerd
>
> I see what you mean. Is this with splitShaeFix_5_lowRes.patch?
> I'll investigate. Is there an OSM file I can run with?
Hi all
Outermost level should be as Gerd suggests
5 levels of overview seems excessive - what about:
overview-levels = 4:17, 5:15, 6:13
Ticker
On Tue, 2021-06-01 at 13:29 +, Gerd Petermann wrote:
> Hi all,
>
> I am not sure but I think it is a bad idea to have
> overview-levels = 4:17,
gpx
> into JOSM, fixed the duplicated points and used Shift+J (join
> overlapping areas)
>
> Gerd
>
>
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 2. Juni 2021 11:23
> An: Developmen
/ShapeSplitter.java (revision 4753)
+++ src/uk/me/parabola/util/ShapeSplitter.java (working copy)
@@ -275,11 +275,23 @@
return pointsToPath2D(outputList, countVals);
}
-/* Dec16/Jan17. Ticker Berkin. New implementation for splitting shapes.
+// Dec16/Jan17. Ticker Berkin. New implementation for splitting
Hi Gerd
I'd been doing some investigation of filters ordering (based on trunk).
I'd also done the pre-filtering of lines & shapes by minRes.
My conclusions are:
Shapes:
It is better to run SizeFilter after RemoveObsoleteFilter.
It is more efficient to run DP filter after both of these.
Lines:
Hi Gerd
This change is fine by me.
Ticker
On Sat, 2021-05-22 at 06:33 +, Gerd Petermann wrote:
> Hi devs,
>
> I think almost nobody needs the Garmin lat/lon coordinates in log or
> debug messages, the degrees are much easier to use.
> This is esp. true for debugging, so I want to change
Hi
As expected, I vote for commenting out this rule:
# Showing the coastline adds almost nothing to the visuals of the map,
so disable:
#natural=coastline [0x15 resolution 12]
Ticker
On Tue, 2021-05-18 at 07:03 +, Gerd Petermann wrote:
> Hi all,
>
> see item 15 in
with r4734?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Freitag, 21. Mai 2021 18:10
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Problems with sea in overview map
>
> Hi
Hi Gerd
Trying to use JOSM to decide if a gpx trace represents a self
-intersecting polygon is difficult. Is there a way of forcing it to
consider it closed and then check itself? Failing that, number the
points or segments somehow.
Ticker
___
sed.
> Right click on that warning allows to "zoom to problem" .
> This tells you where the first point is.
>
> In the "OSM data" preferences I've enabled "Draw segment order
> numbers on selected way"
>
> Hope this helps.
>
> Gerd
>
> _____
> Validator doesn't help much with these polygons.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 27. Mai 2021 17:06
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] special
r.osm
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 27. Mai 2021 16:47
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] special case where splitting fails without
> a log message
>
> Hi Gerd
>
> next patch al
r.osm
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 27. Mai 2021 16:47
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] special case where splitting fails without
> a log message
>
> Hi Gerd
>
> next patch al
unds good. I'm making progress with a better ShapeMerger that
> produces less jitter, but so far it still produces some.
> Will try it later..
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag,
f you need the data.
>
> Gerd
>
> ____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 27. Mai 2021 16:09
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] special case where splitting fails without
> a log message
>
>
bits individually in a
subdirectory relevant to the split line.
I've tested it on a few examples, but I'll stress-test GBR again and
check the shapes where it detects problems.
I probably need to tidy up some message levels and comments.
Ticker
On Wed, 2021-05-26 at 11:17 +0100, Ticker Berkin
And yes, it shows
> water on both sides of the connecting lines. Very simiar to the
> Garmin renderer.
> Does that help?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 27. Mai 2021 17:48
> An: Devel
Hi Gerd
The shape I'm getting in my build has a major problem with a twist
between the 2 parts. I'm having trouble reconciling it with the OSM
map. I've attached the original shape trace.
I agree that some of the messages do need tweaking, but, in this cases
there is a significant problem.
I'll
Hi Gerd
This is going to take some studying to work out the implications. Can't
do much for the next few days however, but will look carefully at the
end of the week.
Ticker
On Sun, 2021-06-06 at 14:02 +, Gerd Petermann wrote:
> Hi,
>
> the attached patch improves the overview map, but so
__
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 2. Juni 2021 16:06
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] special case where splitting fails without
> a log message
>
> Hi Gerd
>
> I've fo
Hi Gerd
I'm coming to the conclusion that water.osm is invalid.
I've attached an example part. This goes through the cut-line following
the same path in and out, and defines both shape and a hole at the same
time, which is impossible without the lines crossing.
Ticker
Hi Gerd
Some of the diags I've added to shapeSplitter might cause exceptions if
log.isDebugEnabled() and one of the sides of the split isn't required.
I didn't notice this for a while because just looking at the first part
and Main doesn't show exception traces.
The extra testing and error
ch
> version 4736 while trunk 4735 doesn't show them.
> Looks like a problem with preserving points or maybe special cases
> with ShapeSplitter...
>
> Gerd
>
>
>
> ____
> Von: mkgmap-dev im Auftrag
> von Ticker Be
em as long as ShapeSplitter can handle this. Can it?
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 24. Mai 2021 12:54
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Problems with s
Hi Gerd
Not sure about this. It is a very drastic change and might break a lot
of the element>subdiv code (esp --order-by). Many element well be too
big and have to be split again.
It ends up as a merge attempt at all lines/shapes in the tile, so it
might as well be resolution independent!
Hi Gerd / anyone else
Attempting to improve filtering by considering their optimal order, I
got much worse results at very low resolutions. The excess was lots of
1-res-unit lines (these came from the coastlines of lots of small
islands)
These lines start off sufficiently large to make it
Problems with sea in overview map
>
> Hi Ticker,
>
> you mean I should mergeShapesFirst() completely?
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 24. Mai 2021 15:57
> An: Deve
em with large white area in sea which
> seems to depend on the order in which shapes are merged. Sill trying
> to understand what goes, but at least I can reproduce it...
>
> Gerd
>
>
> ____
> Von: mkgmap-dev im Auftrag
> von Ti
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 24. Mai 2021 15:57
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Problems with sea in overview map
>
> Hi Gerd
>
> Not sure about this. It
Hi Gerd
Re. last commit: preserve all horizontal and vertical lines in shapes.
Do the cut lines go right across the outer polygon or just in from one
side to the hole? If all the way across, might this change inhibit the
merging to one side of the hole, or, if divided for some other reason
in
CleanFilters
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 24. Mai 2021 17:33
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Problems with sea in overview map
>
> Hi Gerd
>
also restructured it a bit.
Patch attached based on low-res-opt. Trunk version will be the same
(but the patch would be different)
Ticker
On Mon, 2021-05-31 at 17:12 +0100, Ticker Berkin wrote:
> Hi Gerd
>
> shapeSplitter will have problems (ie get it wrong some of the time
Hi Gerd
Do you have an example of this triangle / concave shape? Are you sure
there isn't a rotation through the connection point, resulting in
something like a figure-of-8.
Ticker
On Mon, 2021-05-31 at 07:41 +0100, svn commit wrote:
> Version mkgmap-r4749 was committed by gerd on Mon, 31 May
Hi Gerd
Is this of any relevance -
https://en.wikipedia.org/wiki/Branch_and_bound
Ticker
On Wed, 2021-06-30 at 16:08 +, Gerd Petermann wrote:
> Hi all,
>
> I've started this branch to further improve the split results.
> Splitter has two different algorithms to find good splits.
> 1)
Hi Karl
polygons near here, eg
https://www.openstreetmap.org/way/215482946
https://www.openstreetmap.org/way/215482937
look to be a bit of a mess - one shows a big spike. If you go to
40.777236,0.641794 and query features at this point, the hover previews
don't correspond very well.
Ticker
Hi Gerd
I often see other polygons becoming self-intersecting at lower
resolutions (or at least GPSMapEdit does). If the DP filter is doing
this then maybe this should be tacked first, with an alternate version
for polygons - I have no idea how this would be implemented.
Should shapeMergeFilter
.
With option --x-no-mergeshapes (and current trunk) it appears that
cutting to this island group happens twice from the left, with 1 line
continuing to the right and twice from the top, with 1 line continuing
to the bottom.
Ticker
On Sun, 2021-04-25 at 13:50 +0100, Ticker Berkin wrote:
> Hi G
Hi Gerd
I think I'm getting somewhere with this and will try and have a proper
fix in a day or so. It is related to subdivision splitting.
Ticker
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi Gerd and others
The cause for this unrendered area is as follows:
A large multipolygon (larger than the maximum size for a level 1
subdiv) exists, and is broken into some similar size pieces and some
smaller pieces to expose inners/holes. The same problem can be caused
by any polygons having
__
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 27. April 2021 13:11
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Empty rectangles in map
>
> Hi Gerd and others
>
> The cause for this unrendered area is as follows:
Hi Gerd
I'm away at moment, without full access to sources, so can't follow the
current progress with partitioning, etc.
Regarding finding a point IN (and not ON) polygon:
1/ Try bounds center.
2/ Assumed determined [counter-]clockwise from area calculation.
Pick 3 sequential points, bisect
go to the edge of the
forest triangle. Also it only shows when detail-level is set to
"highest"
Ticker
On Sun, 2021-04-25 at 11:03 +0100, Ticker Berkin wrote:
> Hi Gerd
>
> Just tried this with latest trunk and my standard environment (mainly
> --order-by-decreasing-area
&g
Hi Gerd
Is there a simple way to look at an .osm.pbf file with JOSM?
Ticker
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi
I presume this will be most use to people who generate sea-latest.zip.
I use --generate-sea=..., so using the current OSM data for the area
concerned, and, before loading onto a device, look at the overview map
with GPSMapEdit to check the sea has worked correctly.
If the country cut has
Hi Gerd
Just tried this with latest trunk and my standard environment (mainly
--order-by-decreasing-area
and get very inconsistent results.
On GPSMapEdit seems reasonable - shows forest triangle and, within, a
small area with a number of holes.
MapSource shows a white square, no forest colour
Hi Gerd & others
This is a quite common physical set-up; a highway with another, more
minor, highway/track/path leading off it with a "barrier" at the
junction, inhibiting access to the minor highway.
Often the only clear access restrictions visible on-the-ground are on
the barrier, so these are
.
> I didn't try it but I guess it could lead to routing problems if your
> start is at the end of the road.
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 4. Mai 2021 10:06
> An: Develop
onnecting
> ways which trunk doesn't connect (only with BoundaryRelation).
>
> I think it will take a one or two more weeks before this branch is
> getting stable.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
&
ould return IN/ON
> I think it happens when a ring has start /end node ON and also 2nd or
> 2nd-last node ON.
> Probably a special case created by the ShapeSplitter. Attached patch
> fixes the problem in IsInUtil.
>
> Gerd
>
>
>
_____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 27. April 2021 13:11
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Empty rectangles in map
>
> Hi Gerd and others
>
> The cause for this unrendered area is as follows:
Hi Mike / Gerd
This patch seems fine to me.
Ticker
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Happy to tweak this.
>
> Cheers,
> Mike
>
> -Original Message-
> From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
> Sent: 07 February 2021 17:36
> To: Development list for mkgmap
> Subject: Re: [mkgmap-dev] Fix Sea Patch
>
> Hi Mike and Tick
Hi all
I've re-made this set of changes, along with a few improvements that
I've gathered over the last 6 months. Following list numbering is the
same as original patch, but include some [extra] notes + new items at
the end.
Relevant threads:
Hi Gerd
I was trying to diagnose a problem with a repeating points in polylines
as reported by GPSMapEdit and found a problem in
RemoveObsoletePointsFilter where it duplicates a point.
Also in this and/or RoundCoordsFilter I've made some changes:
1/ stop the chain when polygons get too small
2/
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 23. März 2021 13:10
> An: mkgmap development
> Betreff: [mkgmap-dev] line/polygon filters fix
>
> Hi Gerd
>
> I was trying to diagnose
that relies on this?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 25. März 2021 10:47
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] line/polygon filters fix
>
> Hi Gerd
&g
d?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 23. März 2021 14:17
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] line/polygon filters fix
>
> Hi Gerd
>
> I don'
Hi Gerd
I'm revising my opinion about considering the geometry to determine
inner and outer. All the different BitSets, containsMatrix etc logic
is too complex, and if it then conflicts with the explicit definition
of the MP it just gets worse.
I'd simpify it along these lines:
split the
ight line""
>
> I commited only parts of your patch, I think the stuff regarding
> closed shapes is too confusing and the changed loop logic really
> doesn't improve robustness or readability.
> See r4619 and r4620.
>
> Gerd
>
> ___
__________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 29. März 2021 10:38
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] line/polygon filters fix
>
> Hi Gerd
>
> On a road, if there is a normal Coord, immediat
ing outer rings.
>
>
> So, I started to use already tested code where possible, e.g.
> IsInUtil. See attached patch. Run times seem similar to the existing
> code in trunk.
> Just experimental so far, but at least a lot less code...
>
> Gerd
>
> __
Hi Gerd
I think this might be the reason why you backed out the Polish
inner/outer definition changes:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2019q1/029478.html
Maybe there needs to be an option to say how multiple DATA{sameLevel}
should be handled:
a/ first outer, following inners.
b/
e" test requires lots of time for such a
> complex outer ring, and a single test will not find intersections.
>
> Have to think about the data structures but I am sure this will be
> much faster for most of the really complex MP.
>
> Gerd
>
>
>
> ___
that code?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 15. März 2021 17:15
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] tile takes very long time to generate
>
> Hi Gerd
>
> You might consider
701 - 800 of 1100 matches
Mail list logo
