Hi Gerd
I think the extra testing should be removed and the logic should work
on the assumption of correct data; just emitting warning/errors when
problems are found during the normal processing.
It also has extra complexity due to early versions of the splitter not
keeping relations/polygons com
be mkgmap can simply ignore incomplete MP after logging a warning.
>
> Gerd
>
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Samstag, 13. März 2021 12:21
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] tile takes very long time to generate
&
Hi
I think this is more an interpretation of what a Bay means and it being
an inner of a relation isn't relevant. Islands shouldn't be cut-out of
Bays with a MP relation. It is expected that they are rendered as
transparent rather than blue and mapnik.txt does this.
There was a thread about this
Hi Gerd
Some possible test cases:
Looking at the problems my code is detecting, the complicated cases are
when possible polygons share 2 or more end-points with other possibles;
for instance:
http://www.openstreetmap.org/relation/5329106
adjacent buildings, touching each other, are mapped as a
Hi Gerd
You might consider the some of the ideas here as improvements to the
initial parts of MP processing.
This is a patch based on trunk rather than the new branch. It isn't
structured as for final usage, rather for minimising the spread of
changes, working in parallel with the existing code s
Hi all
I think it is time that that the floodblocker logic is removed.
I doubt if anyone uses it.
The recommended way to have sea is to use --precomp-sea and
floodblocker is irrelevant to this.
Using the coastline data from the normal OSM input, the common sea
problems are in tiles that extend
ocessing?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Mike Baggaley
> Gesendet: Mittwoch, 17. März 2021 15:18
> An: 'Ticker Berkin'; 'mkgmap development'
> Betreff: Re: [mkgmap-dev] Removal of floodblocker
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/ k
de fails.
>
> 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
int is preserved?
>
> 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
&g
lies 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
>
nts on strictly straight 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
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 polyg
the rules for touching 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/ ou
Hi Gerd
Wouldn't it be more efficient to choose a point within a each polygon
and then use IsInUtils.isPointInShape and the relative areas to test if
this polygon is in others. The point could be the centre of the
polygon, after checking isPointInShape == IN on itself, and, if not,
make do with th
etry calculations like insideness or outsideness: Allows to
> remove a lot of complex code but might be slower in some cases.
>
> Hi Ticker,
>
> yes, that's what I plan to do. Right now I try to understand what is
> done with the data in collection intersectingPolygons.
>
I meant intersecting polygons
Ticker
On Thu, 2021-04-01 at 12:08 +0100, Ticker Berkin wrote:
> Hi Gerd
>
> I agree that calcContains should be changed as you suggest.
>
> My view otherwise is that the code should be as simple as possible
> for
> "correct" cas
Hi Gerd
2 more thoughts:
For elements from Polish input, set a distinct role. This can be
spotted early and either the order rule or direction rule can be
applied (they are closed, so the area/direction can be calculated
immediately). This then allowed OSM data with a blank role to be
handled as
_________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 1. April 2021 14:14
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4622: - use IsInUtil
> to do geometry calculations like insideness
w you used 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 migh
Hi Gerd
Problem is that IdentityHashMap is the ideal solution, but ordering
behaviour depends on internal java object handles. A solution to this
stability issue would be to rotate joinedWays.originalWays so, say, the
one with the lowest ID is first, doing this just before the full point
-list is
Hi Gerd
If starting with unsigned deltas in polyline encoding, and attempting
to reduce the length by testing reduced x/yBase values, there isn't any
point in testing Base-1, as the normal number of bits will be the same
(added sign bit) and there will be some overflows.
Patch attached to change
hich will never find a better
> encoding?
>
> Gerd
>
> ____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 8. April 2021 13:58
> An: mkgmap development
> Betreff: [mkgmap-dev] Polyline base optimisation
>
s
> calculated but I still think that your version is even more
> confusing.
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 8. April 2021 17:34
> An: Development list for mkgmap
> Betreff
____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 8. April 2021 18:03
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Polyline base optimisation
>
> Hi Gerd
>
> It needs to know if there are deltas < 0, deltas > 0, an
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 a
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 prob
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
7;t 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-decreasi
ea logic.
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 w
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
https://www.mkgmap.org.uk/mailman/listinfo/mkg
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 t
etimes returns
> ON when it should 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 a
is sometimes erronously connecting
> 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 Auf
_____
> 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
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 th
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
ters or so.
> 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
&
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 wrote:
much
> 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:
>
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 m
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 Ro
jects
> (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 mkgm
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-
route 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
>
Hi Gerd
Since downloading loading britain-and-ireland-latest.osm.pbf I had been
unable to build a gmapsupp because of running out of heap (my hardware
is 32 bit, -Xmx1540M is largest value allowed)
My problem is mainly because I have 1731146 cities (along with 1046096
streets)
Looking at Mdr5 pr
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 10. Mai 2021 23:05
> An: mkgmap development
> Betreff: [mkgmap-dev] MDR building out-of-memory
>
> Hi Gerd
>
> Since downloading loadi
Hi Gerd
Here is updated version of patch.
Changes from last:
Uses your cache code for region and country (in 2 places). For British
Isles, there are 190 regions and 7 countries, so I don't think the
extra memory will be a problem and there should be some performance
benefit.
Delays allocating c
; files which was created 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 Ti
mprove run time, it is used to
> deduplicate and thus reduce memory. Maybe it would be better to use a
> smaller chunk size and no cache.
> No idea why I didn't use
> merged = new ArrayList<>(len);
>
> Gerd
>
> ________
> Vo
Hi Eric
you could try:
mkgmap:mp_role=inner & osmId()=...
but I suspect it won't work. generally inners are just cut out of
outers and have no representation. The ways that make them will be
there, but, having no tags, are dropped before style processing.
Ticker
On Wed, 2021-05-12 at 11:00
ers of equally
> 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
&g
Hi
Various thoughts:
The 0x40 polyLine direction flag probably has no effect on modern
Garmin devices. As Gerd says, GPSMapEdit puts an arrow on lines if it
is set. In my notes from testing all line types, I found some cases
where an eTrex put compass bearings (N/NE/E/...) on some line types
wher
Hi
My understanding: No, it just forces the icon to rotated so that in the
same direction as the points in the line.
Ticker
On Fri, 2021-05-14 at 06:09 +, Gerd Petermann wrote:
> Hi all,
>
> I just noticed the UseOrientation=Y/N setting in TYP files. Is this
> related to the direction flag
the code which tries to propagate the direction flag to
> underlying roads for now. Let's see first how often this is really
> needed.
>
> Gerd
>
>
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 13. Mai 2021 23:36
> An: Development lis
ann_muenc...@hotmail.com> wrote:
> > Hi Ticker,
> >
> > I meant I want to remove the evaluation of the special tag
> > mkgmap:has-direction=true and only rely on the new option --line
> > -types-with-direction
> >
> > Do you see a need to have both?
> &
ants to prevent that - then add no
> reverse for resolution up to XX and only reverse the other lines
> associated with it from resolution XX or lower. The third setting
> would be never merge the other lines (could also be set by setting
> resolution to 00 or lower than your lowes
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
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
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
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 ext
s rule file.
> At 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: [mkgma
the
> 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
r extended line types?
>
> 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 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 lin
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,
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
> rev
sDirection flag.
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,
ets
>
> Do you 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
>
> ___
res about it because the
> LineMerger in trunk doesn't reverse-merge.
>
> Gerd
>
> ____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 17. Mai 2021 19:37
> An: Development list for mkgmap
> Betreff: Re:
Hi Gerd
The code in low-res-opt looks like ignore-oneway-for-lines.patch. The
disadvantage of this, as I see it, is that has-direction can't be
forced false for one-way roads.
I think my version is clearer.
Considering substitute lines from /overlays:
I had intended that they all (first and dup
at 14:01 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I don't see that oneway forces direction flag when the tag mkgmap:has
> -direction=no is set in the branch. Did you try it?
>
> Gerd
>
> ____
> Von: mkgmap-dev im Auftrag
>
>
> So, I think we need a flag in MapLine which stores the info that
> mkgmap:has-direction=no was used and we have to evaluate the list
> for each generated replacement type.
> The attached patch for the branch should do that.
>
> Gerd
>
>
>
> __
Hi Gerd
Yes
Ticker
On Tue, 2021-05-18 at 15:56 +, Gerd Petermann wrote:
> Hi Ticker,
>
> which "existing behaviour" do you mean? That before r4703?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berki
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 s
ate it.
>
> I've committed your patch with small changes reg. oneway evaluation.
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 18. Mai 2021 17:51
> An: Development list f
________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 19. Mai 2021 12:46
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Problems with sea in overview map
>
> Hi Gerd
>
> I often see other polygons beco
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
ways to merge shapes, 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: Mit
ll continue
> tomorrow...
>
> 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 m
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:
> Hi
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:
L
e where it improves something 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
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 Coo
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 http://gis.19327.n8.nabbl
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 through
e triangles with the branch
> 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 A
f intersecting shapes. I think this is
> not a problem 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 fo
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!
Ticke
mpletely?
>
> 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
: [mkgmap-dev] 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
&
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 th
e problem 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
> v
enableLineCleanFilters
>
> 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
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 g
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, 2021-05-2
__________
> 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
>
>
1 - 100 of 1134 matches
Mail list logo
