Hi Ticker,
Ticker Berkin wrote
> I think the reason why the buildings look different is because, without
> --order-by-decreasing-area, they get merged into a single area and then
> a filter (DouglasPeucker), finding the intermediate points are within
> the tolerance of a straight line, removes
Hi Gerd
I think the reason why the buildings look different is because, without
--order-by-decreasing-area, they get merged into a single area and then
a filter (DouglasPeucker), finding the intermediate points are within
the tolerance of a straight line, removes all but the 4 corners of the
Hi Ticker,
sorry, still some problems:
1) I think I found an error in method Area.roundPof2(int val, int shift)
I wanted to find out why you did not use Util.roundUp(int val, int shift).
For val=-9567 and shift=4 I see
-9568 from your routine and
-9552 from the other
So it seems your routine
ovember 2016 13:35
> An: Gerd Petermann
> Betreff: Re: AW: [mkgmap-dev] patch to write polygons in decreasing
> order
>
> Hi Gerd
>
> I hope this version of the patch will fix all the issues you have
> raised with the previous ones except performance.
>
> Regards
> Tic
Hi Gerd
1/
I hadn't discovered 'ant test' - Sorry. I'll fix ShapeMergeFilterTest.
2/
To see what is happening with ShapeMergeFilter not doing anything I
tried fixing all the equal coordinates to be identical simply by
calling prepShapesForMerge() just before invoking ShapeMergeFilter each
time.
Hi Gerd
Thinking about simple rectangle clipping, PolygonClipper.java and
ShapeSplitter.java, quite a lot of the cost must be converting the
points representation to Path2D and back (preserving coords) and
handling the multiple output shapes. Given the pseudocode for
Sutherland-Hodgman, I might
Hi Ticker,
okay, I will try on my own later. Please review the patch:
1) log messages esp. those with log.warn. I think most are debug messages ?
This one looks wrong to me: ""Area single pixel shifted so can't split at
"
What does it mean?
2) Comments / javadoc : Please remove commented
Hi Gerd
I've been looking at ShapeSplitter and clipping to a rectangle
algorithms generally. I don't feel I know enough about how to use the
java.awt.geom package to implement this effectively, and so I'd rather
keep to using Java2DConverter and .intersect(), even though it is most
likely much
Hi Ticker,
Gerd Petermann wrote
> Alternative would be to implement a clipper which doesn't need
> area.intersect(). I've once coded the "Sutherland-Hodgman algorithm" but
> didn't use it yet as it failed with special cases like self-intersecting
> ways or concave shapes producing spikes, but I
Hi Ticker,
I've started to run some tests. No crash until now. A few remarks so far:
1) please use ant test before producing patches. This will show you that
ShapeMergeFilterTest needs changes.
2) You already mentioned that ShapeMergeFilter doesn't work as you would
expect. I think the reason is
Hi Gerd
I've fixed it and the test case now runs. I've also incorporated your 3
other points.
I've added the following comment to mkgmap/build/MapArea.java
/*
Failed to split!
This happens easily when doing low resolution overview
levels (have a high shift value) and we are insisting that
. But this is no
problem as long as you can make sure that polygons like intertidal zones, depth
areas or fairways are drawn on top of the sea/riverbank polygons and not
covered by them.
Von: nwillink
Gesendet: Samstag, 29. Oktober 2016 07:12
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] patch to write
Having examined a 'blue' map more closely the polygon type structure is more
complicated:
My blue map of the Southwest coast of England only uses extended types: ie
Here are some of the polygons:
0x10104 base map similar to 0x4a or 0x4b (Interestingly I can't detect any
4a or 4b)
0x10101 =
519-p1.html
> Currently it is even very problematic to draw just simple buildings
> on those devices. Not to mention water depth areas or intertidal
> zones.
>
> Jürgen
>
>
> Von: Ticker Berkin
> Gesendet: Freitag, 28. Oktober 2016 16:31
> An: mkgmap-dev@li
>
> Jürgen
>
>
> Von: Ticker Berkin
> Gesendet: Freitag, 28. Oktober 2016 16:31
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] patch to write polygons in decreasing order
>
> I maintain that there isn't a universal _draworder that will render a
>
@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] patch to write polygons in decreasing order
I maintain that there isn't a universal _draworder that will render a
map from OpenStreetMap data on the Garmin device in a similar way to
how it is shown by www.openStreetMap.org - there are so many examples
I maintain that there isn't a universal _draworder that will render a
map from OpenStreetMap data on the Garmin device in a similar way to
how it is shown by www.openStreetMap.org - there are so many examples
of nested areas of pasture, woods, grass, playgrounds, etc in any order
of overlaying.
OK
Point taken.
There is a mystery about some if not most TOPO TYP files containing
draworders which are not linked to polygon .
Either they are left overs, which is very unusual, or they imply another
purpose as yet undefined - the word container was used to describe such
draworders but its
to 15.000 EUR need maps without
TYP.
So it´s really, really important not to rely on TYP draworder.
Von: nwillink
Gesendet: Sonntag, 23. Oktober 2016 16:28
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] patch to write polygons in decreasing order
Just an observation.
To me it only
Just an observation.
To me it only makes sense to order polygons if the user is not using a TYP
file.
TYP files effectively attribute a draworder to different types of polygons.
Sorting polygons into size will work if the user has plotted two polygons of
the same type, ie buildings on top of
Hi Ticker,
great, enjoy your holidays!
Gerd
Ticker Berkin wrote
> Hi Gerd
>
> I've reproduced the crash.
>
> I think the problem is that area.getEstimatedSizes() (called from
> MapSplitter.addAreasToList) doesn't reflects what will go into the area
> when the option is in effect and so
Hi Gerd
I've reproduced the crash.
I think the problem is that area.getEstimatedSizes() (called from
MapSplitter.addAreasToList) doesn't reflects what will go into the area
when the option is in effect and so addAreasToList might keep
recursing.
I need to think about this more deeply. There is
Hi Ticker,
I reviewed the patch, it looked good but the patched version crashes in a
recursion because of an
java.lang.StackOverflowError. I think the problem is in the rounding in Area
class.
I've uploaded test data that should allow you to reproduce the problem:
Hi
I have a patch that outputs polygons into the map file in decreasing
size order, so that, assuming equal _drawOrder, the Garmin device
renders small details over larger areas, much like how they appear on
OpenStreetMap.org.
As well as sorting by size, polygons that straddle subDivisions
are
24 matches
Mail list logo
