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

Sat Jul 23 20:23:26 BST 2016

Hi Ticker,

mkgmap analyses multipolygon relations and cuts inner parts, so correct mp-relations

should not be a problem. I've seen overlapping polygons, e.g. when you chose to render

place=island and also the land polygons created by the sea generator.

You suggest to write the larger polygon first, but in those cases this would not help.

I think this solution would also not help when polygons partially overlap.

Gerd

________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Samstag, 23. Juli 2016 20:42:02
An: mkgmap-dev at lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Option to output polygons in size order

Hi

I'm sure that the order in the map has some effect on the Legend; as I
zoom in or scroll across areas with greenery they appear briefly and
are then cleared, by the island polygon that covers everything, as it
starts drawing the ways...

Generally, the openStreetMap data order is OK, but I have found
examples where there are lakes, within the same meadow, that occur both
before and after it. Not sure if this is related to multi-polygons, but
if sorting was performed on the individual polygons there wouldn't be
any problem.

Also it looks like splitter is delaying the British Isles (and other
large) polygons because they occurs on multiple tiles.

Typ _drawOrder cannot solve the problem when there are nested polygons
with more that one instance of the same type, whereas drawing outer
ones first solves it completely.

I have seen mention somewhere that areas with the same _draworder are
rendered in file order

Ticker

On Sat, 2016-07-23 at 17:17 +0000, Gary Bamford wrote:
> Hi Ticker/Gerd
>
> The draw order does work for the Legend ( it is the device I have ).
> I also came across problems with multiple polygons, the problem can
> be one of several things, not all multi polygons are correct on
> openstreetmap, I cam across one today "fairhaven lake"  golf course,
> was hiding, due to draw order, but the problem was, it is contained
> within a polygon for a residential area, so I had to change the data
> on openstreetmap, to make it an inner polygon. when i download the
> new OSM data I expect it to work correctly.
>
> if the polygons are set correctly on openstreetmap, then draw order
> will will as you expect.
>
> Gary
>
> From: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> on behalf
> of Gerd Petermann <GPetermann_muenchen at hotmail.com>
> Sent: 23 July 2016 17:05
> To: Development list for mkgmap
> Subject: Re: [mkgmap-dev] Option to output polygons in size order
>
> Hi Ticker,
>
> are you sure that the order matters? I've never heard that theory
> and I would be surprised when that is true.
> The normal way to handle the draw order is to use a typ file, not
> sure
> if this works on your device, but it seems to work well for others.
>
> Gerd
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> Gesendet: Samstag, 23. Juli 2016 18:45:59
> An: mkgmap development
> Betreff: [mkgmap-dev] Option to output polygons in size order
>
> Hi
>
> I'm using splitter-r437/mkgmap-r3676 to make a map for Etrex Legend
> from british-isles-latest.osm.pbf from geofabric.de.
>
> Using "default" style and not using a TYP file, no land features
> (woods,marsh,green) show because an island polygon for "British
> Isles"
> is rendered near the end, on top of everything else. I guess that the
> Etrex has all area types as the same draworder and renders them in
> file
> order.
>
> I presume I could use TYP / _DrawOrder to change this behaviour
> slightly but I keep finding examples of woods in islands in lakes in
> marsh in islands etc etc, so _DrawOrder can't solve the problem.
>
> What would make everything show correctly would be to output polygons
> in size order, largest to smallest. Could this be done easily? either
> in splitter then --preserve-element-order, or in mkgmap, possibly
> after
> style processing because there will be a lot fewer polygons at this
> point.
>
> Regards
> Ticker Berkin
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>   mkgmap-dev Info Page www.mkgmap.org.uk<http://www.mkgmap.org.uk>
> This is a general development list for mkgmap. To see the collection
> of prior postings to the list, visit the mkgmap-dev Archives.
>
> _______________________________________________
> 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/20160723/b106db54/attachment-0001.html>