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

Sun Jul 24 19:42:13 BST 2016

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/imgformat.p
> df/download
> Other sources:
> http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/IMG_File_Format
> (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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20160724/6423ea7f/attachment-0001.html>