[mkgmap-dev] Option to output polygons in size order

Wed Jul 27 11:33:31 BST 2016

Hi Ticker,

here is a patch that contains my latest findings to fix

the problems reg. "preserved" points plus the experimental code for the sorting,

after applying the patch to r3683 see MapBuilder line 1123 and below.

I still want to fix minor problems with the overview map,

that's why I did not yet publish the patch.

Gerd

________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Mittwoch, 27. Juli 2016 11:57:17
An: mkgmap-dev at lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Option to output polygons in size order

Hi all

Gerd, do you have a patch I can try - I have some examples where this
should fix things.

I've started to look at the code and, regardless of --preserve-element
order, mkgmap will chop up and change the processing order of polygon,
relating to overlap, inclusion, bounding box and multi-polygons.

The relevant code is in ./mkgmap/reader/osm/MultiPolygonRelation.java

I can't work out all of what it is doing, but it
does seem to have bits  that work out a hierarchy of polygon
inclusion/overlap. I suspect that multi-polygons and maybe overlaps
sometimes cause this to process a contained simple polygon before
processing one that contains it.

My idea of sorting by size was to avoid trying to calculate this
inclusion hierarchy - a polygon can't contained a larger one!

I don't think I'd like to touch any code in MultiPolyonRelation, so I
still think the best solution is sorting somewhere in Mapbuilder, after
area splitting.

Ticker

On Wed, 2016-07-27 at 07:29 +0000, Gerd Petermann wrote:
> Hi Felix,
>
> reg. the idea of "cutting out overlaps": I guess it would consume
> quite a lot of CPU and it would heavily increase the img size
> because we would have to write many more points. Think of a shape for
> "place=village" with hundreds of holes for each building
> shape. Up to now we save the shape for the village and the shapes for
> the buildings. With cutting we have to calculate what
> remains of the village shape, this would be a very complex shape with
> many holes, so it would have many points.
> I don't think that would be a good idea.
>
> reg. sorting by size: I've not noticed any visible change in Basecamp
> or on my Oregon, so I don't think this is a solution.
>
> I looked at maps produced by Garmin and 1st got the impression that
> they are sorted by type, highest types coming first,
> but I also found exceptions. Don't know if this means that the order
> is not important or if there is a complex rules behind this.
>
> Gerd
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Felix Hartmann <extremecarver at gmail.com>
> Gesendet: Sonntag, 24. Juli 2016 21:40:47
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Option to output polygons in size order
>
> That is not really a good approach. Basecamp orders the polygons
> opposite to most gps devices. So it will still be broken.
>
>
> There is however a proper way to do - but that would be much much
> more complicated: Create a list of polygons that may not overlap (in
> the style-file). Then if mkgmap finds that 2 of these polygons do
> overlap - mkgmap should cut out the smaller polygon shape from the
> bigger. Basically the result of that approach would mimic how a
> Mapnik map looks in this case. Still the real solution however would
> be to fix the underlying OSM data. I have no clue how code and time
> intensive the "mimic Mapnik" approach would be, but everything else
> won't really solve much.
>
> On 24 July 2016 at 20:42, Gerd Petermann <
> GPetermann_muenchen at hotmail.com> wrote:
> > Hi Ticker,
> >
> > with the current algo the order is either "unpredictable" or
> > the order in the input file (osm.pbf is typically sorted by id).
> > This depends on the --preserve-element-order
> > If I see this right this order will have an influence on the result
> > of the so-called shape merger which tries to combine shapes
> > with similar attributes.
> > I still don't understand why the size should matter, but it should
> > be easy to add a sort after the line
> > shapes = mergedShapes;
> > in MapBuilder.java
> >
> > I don't have the time today, so try on your own or wait a little
> > for a patch .
> >
> >
> > Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> > von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> > Gesendet: Sonntag, 24. Juli 2016 20:23:41
> > An: mkgmap-dev at lists.mkgmap.org.uk
> > Betreff: Re: [mkgmap-dev] Option to output polygons in size order
> >
> > Hi Gerd
> >
> > Looking at the meaning of the sub-division, this looks like just
> > the
> > place to try and order the polygons by size! What governs the order
> > they appear in at the moment? The size should be the full size of
> > the
> > individual polygon.
> >
> > Concerning the new thread "Why do we render place=island polygons
> > in
> > the default style", I have used "place=island & size_of() <
> > 1000000" to
> > get around the major problem but it seemed a bit arbitrary, and
> > when I
> > found other examples where, just sometimes, large polygons mask all
> > features within I thought there must be a more general solution
> >
> > Ticker
> >
> > On Sun, 2016-07-24 at 00:05 -0700, Gerd Petermann wrote:
> > > Hi Ticker,
> > >
> > > Ticker Berkin wrote
> > > > I'd understood and hoped that, for areas with the same level it
> > > > rendered areas in file order, and I see on my device it
> > > > overwriting,
> > > > sometimes woods with island, sometimes the other way around,
> > > > depending
> > > > on, I presumed, the input ordering. I see the exactly the same
> > > > overwriting effect zooming in or scrolling in any direction.
> > > >
> > > > What is the scale of the 'sub areas' you mention?
> > >
> > > I should have said sub division , and they have no specific
> > scale.
> > > They are used to group nearby elements, and they have several
> > limits
> > > like "not more than 255 points and not more than 255 lines in one
> > sub
> > > div"
> > > For details see first the imgformat-1.0.pdf from Mechalas:
> > > http://sourceforge.net/projects/garmin-img/files/OldFiles/imgform
> > at.p
> > > df/download
> > > Other sources:
> > > http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/IMG_File_For
> > mat
> > > (which has more links at the end)
> > >
> > > Reg. the British Islands polygon: If I got that right this is the
> > > very complex mp-relation
> > > https://www.openstreetmap.org/relation/6038068
> > > (don't use the link, the thing is too complex)
> > > It was added 2016-03-09 so maybe the problem is rather new and
> > nobody
> > > noticed it. I think it makes no sense to render that polygon, the
> > > rules
> > > in the default style should be changed to check the
> > > area_size() for place=island so that large polygons are ignored.
> > > I'll try to find a reasonable value.
> > >
> > > Gerd
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > http://gis.19327.n5.nabble.com/Option-t
> > > o-output-polygons-in-size-order-tp5878989p5879011.html
> > > Sent from the Mkgmap Development mailing list archive at
> > Nabble.com.
> > > _______________________________________________
> > > mkgmap-dev mailing list
> > > mkgmap-dev at lists.mkgmap.org.uk
> > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > _______________________________________________
> > mkgmap-dev mailing list
> > mkgmap-dev at lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >
> > _______________________________________________
> > mkgmap-dev mailing list
> > mkgmap-dev at lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20160727/c2fe2944/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sortShapes.patch
Type: application/x-download
Size: 14468 bytes
Desc: sortShapes.patch
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20160727/c2fe2944/attachment-0001.bin>