Hi Ticker,
yes, looks better. I think we can / must disable massive merging when
isOverviewCombined is true.
I found no way to make sure that shape merger doesn't "jump around". It might
be a problem of the sorting for "byCenter".
I guess it can happen when several small bits are glued to the
Hi all,
the thread
http://gis.19327.n8.nabble.com/Proof-of-concept-for-better-sea-in-overview-map-tp5992781.html
got too confusing because posts with attached pictures where blocked for a
while, and in the end it went private.
Anyhow, I think the results are good now. For normal maps the
Hi Mike,
some answers:
- the unit is metre, it is scaled with this formular: maxErrorDistance =
filterDistance * (1<< (24 - resolution)), so factor 4 for resolution 22, 8 for
21, 16 for 20 and so on.
- The default is 2.6 if the option is not given or given without a value. The
--no prefix
I think polygons can be higher value except at level=0. In general I think
it is better to have a bit higher values for higher levels. However then
again lower for the overview map. However if the improve-overview filter
chain would apply in general - then values need to be much lower. There is
Hi Gerd,
I think the original documentation for --reduce-point-density and
--reduce-point-density-polygon could do with some improvement. It also seems
bizarre to have a recommended value that is not the default. Is 2.6 the
default if --reduce-point-density is specified without a value, or is it
Hi Gerd
Looking at the first few GBR problems, it is shapeMergeFilter trying to
merge lots of adjacent, irregular, fields. They are all simple
polygons. It seems to be generating backward and forward lines all over
the place that don't make much sense, mostly not having a hole at the
end of them.
Hi Ticker,
reg. my test which compares area sizes: It is normal that the size of the area
changes a bit when the cut adds points in the middle of long segments. You can
see the difference in JOSM when you zoom in.
Besides that I think that ShapeSplitter should not drop anything that is
But going back to running GBR, I'm getting more errors - I'll have to
see if there is a compromise.
Ticker
On Mon, 2021-06-14 at 16:39 +0100, Ticker Berkin wrote:
> Hi Gerd
>
> Made some progress! I needed to disable the EPS_HP=2 tolerance along
> the cut line otherwise there were correct
Hi Gerd
Made some progress! I needed to disable the EPS_HP=2 tolerance along
the cut line otherwise there were correct cases that could be
interpreted incorrectly. I also needed not to chuck away very small
areas otherwise your test complained. The major problem was valid
shapes that had parts
Hi Ticker,
I am still testing with the files in
https://files.mkgmap.org.uk/download/507/xxx.zip
I applied the attached patch to enable massive merging and simulating possible
splits and your splitShapeFix_10_lowRes.patch and I see several error messages.
The previously attached example comes
Hi Gerd
Any form of self-intersection might cause problems to ShapeSplitter.
Not sure what you mean by "connected hole visited.." - I presume
something like the outer edge of the shape is clockwise, with a cut
leading to a hole that is also clockwise; for this to happen the in/out
lines from the
Hi all,
I've now added documentation for these new options, see:
https://www.mkgmap.org.uk/websvn/diff.php?repname=mkgmap=%2Fbranches%2Flow-res-opt%2Fresources%2Fhelp%2Fen%2Foptions=4775=4775
Is it clear enough?
I think the recommend value --reduce-point-density-polygon=8 is far too high at
low
12 matches
Mail list logo
