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

Thu Jul 28 14:11:32 BST 2016

Hi Ticker.

When i see any errors they are consistent, by consistent I mean, the final result is always the same, whatever the visible error is.

when I see them, I check them out on OSM, to see how things are related on there.

There are some tricky ones, and I am not sure what the "best practice" approach should be,.

Imagine a residential area, within that area is a golf course, on the golf course there are bunkers, also a lake and in the middle of the lake is an island which has a wood on it, and a pond and also more sand( bunkers ), I am not sure what the relationships on OSM are meant to be, but from what I have seen that is where most of the problems lie, it is a lack of that consistent approach that causes the problems,

Regards

Gary

________________________________
From: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> on behalf of Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Sent: 24 July 2016 17:59
To: mkgmap-dev at lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Option to output polygons in size order

Hi Gary

I wasn't proposing to change priority of anything or make rendering
priority lists, just to change the order of polygons in the output
file. I don't see that this would make any difference to the map size.

You mention the "existing system" and the occasional problems you find
when you have to correct the OSM data. How does this system work
correctly most of the time, showing, say, lakes in marshland correctly,
except, just occasionally, the rendering of the lake flashes briefly
before being hidden by the rendering of the marshland.

Ticker

On Sun, 2016-07-24 at 05:44 +0000, Gary Bamford wrote:
> Hi Ticker.
>
> I have been think about this, and changing the priority to be based
> on polygon size would not only slowdown the gps rendering it would
> also increase the memory size of the final map. I am also not sure it
> would work correctly.
>
> Imagine a scenario whereby you have a series of partially overlapping
> polygons, with some polygons fully inside another polygon, some of
> the overlapping polygons could be the same size, but given they
> aren't using size as a guide you would end up having to reference
> each polygon individually in a rendering priority list, this could
> easily end up being a massive list, taking a huge amount of time to
> process.
>
> I do think the existing system works, but I also know that some of
> the existing base data on OSM needs to be corrected. so that multi
> polygons have been set up correctly.
>
> All my maps are of the UK, and I have no real problems with polygons,
> except for where I find the base data to be incorrect, and to find
> these errors, you have to go them them individually. I am sure Gerd
> will correct me on this, but if you don't specify a typ/style file
> then it will use the default typ/style.
>
> A very useful change in mkgmap would be to indicate a a multipolygon
> that would never be visible due to draw order and or bad multipolygon
> data, but this is more about data integrity than it is about
> rendering a map. So I am not sure if it fits within the mkgmap remit.
>
> Regards
>
> Gary
>
>
>
>
> From: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> on behalf
> of Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> Sent: 23 July 2016 19:44
> To: mkgmap-dev at lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] Option to output polygons in size order
>
> Hi Gary
>
> Experimenting with my device, using the in-build area representations
> (ie no TYP section in my map) it seems as if different areas don't
> have
> a particular priority; it just draws things as they arrive,
> overwriting
> as it goes along.
>
> What I'm hoping for, as a new option, is that (individual) polygons
> are
> output in size order, big to small. Then all your examples work
> perfectly, regardless of any order that OSM generates.
>
> I'm just guessing that splitter effects the order of polygons that
> cross tile boundaries, because the big islands in the input map that
> are getting split mask all the land features, but for other islands I
> am getting greenery, lakes...
>
> Ticker
>
> On Sat, 2016-07-23 at 18:52 +0000, Gary Bamford wrote:
> > Hi Ticker,
> >
> > The draw order dies have an effect, the Legend is a pretty slow
> > device ( I can see mine drawing and then overwriting ), but this
> can
> > only work correctly if the data on OSM is correct, the Multi
> polygons
> > is the base effect, if this is wrong, then it doesn't matter what
> the
> > Garmin device tries to do,.
> >
> > let's assume the multi polygons are not correct, and they don't
> refer
> > to each other.
> >
> > Think about it, imagine a big wood and within it a lake, lets say
> the
> > wood is defined by an area, and so is the lake, in this case you
> > would want the lake to have a higher draw order than the forest,.
> >
> > now imagine a lake with a forest in the middle of it, in this case
> > you would want the forest to have a higher draw order than the
> lake.
> >
> > Basically you can't have both, the multiploygon has to be correct
> > with it's relationships,.
> >
> > if the OSM information is correct draw order works fine.
> >
> > Not sure what you mean by splitter delaying things.
> >
> > Gary
> >
> > From: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> on behalf
> > of Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> > Sent: 23 July 2016 18:42
> > To: mkgmap-dev at lists.mkgmap.org.uk
> > Subject: 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<http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev>
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 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 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 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
> > _______________________________________________
> > 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/20160728/90711d11/attachment-0001.html>