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

Thu Jul 28 17:41:16 BST 2016

Hi Gary

For my problem areas I'll look at the OSM relationships in exact detail
- I'm only just working out how to do this.

Judging by how OpenStreetMap.org displays an area with overlapping
polygons not in a relationship, it is making a consistent choice about
how to show them. I haven't been able to find anything in the OSM data
structures that defines what hides what, but, since Gerd's patch to
sort by size, I'm seeing a lot more that matches OpenStreetMap, but not
completely.

The type of scenario you describe could	be specified with nested
multi-polygon relationships (ie the hole/inner of one relationship is
the outer of another relationship) but this would be complicated and
error-prone and, when taken to its conclusion (eg every building
punching a hole in its area, etc etc) would be totally unwieldy.

Ticker

On Thu, 2016-07-28 at 13:11 +0000, Gary Bamford wrote:
> 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 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
> > 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
> > > 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
> > > > 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
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev