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

Mon Aug 1 15:05:58 BST 2016

Hi Ticker,

A quick look shows that the problem is the mapping and not Mkgmap, there are no relationships in play there, the lakes should be inners of the scrub etc etc. I have done quite a bit of mapping on OSM, and I am still not up to speed on relationships ( inners outers and how to specify correctly ) I do see the problem, but that is quite a complex area to set about sorting out.

Gary

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

Hi Gary

I'm looking at the scrub area (osm 405465966) at N51.06838 W001.30381
In this area are 3 lakes: Peewit (sorry - didn't note the OSM ref),
Kingham (osm 45437710) and Judges (osm 45437709).

Before Gerd's patch to sort by size, none of the lakes showed at high
resolution - they were overwritten by the scrub. After the patch my
device shows Peewit and Kingham, but Judges is still overwritten.
I can't see any reason why 2 of the lakes would now show (be rendered
last) and 1 is rendered before the scrub.

I don't think any of them
were part of a multi-polygon relationship - It occurred to me that if
the scrub was having to be cut-up to expose holes because it as an
outer in some other relationship, and the sorting by size was based on
the pieces rather than the original area, the lake could be larger than
(some of) these pieces of the background scrub and hence they would
show instead.

With the patch, I am seeing a lot more area features. eg there is a
college nearby (N51.06971 W001.32724) that encompasses playing fields
and woods - I now see both.

Ticker

On Sun, 2016-07-31 at 13:51 +0000, Gary Bamford wrote:
> Hi Ticker,
>
> Garmins approach to maps is layered, OSM is built on relationships,
> both have their flaws, and converting from relationships to layers is
> problematic at best.
>
> Point me to an area you are having problems with and i will check it
> out to see what my set up shows,
>
> Regards
>
> Gary
>
>
> From: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> on behalf
> of Ticker Berkin <ticker at jagIT.co.uk>
> Sent: 28 July 2016 16:41
> To: mkgmap-dev at lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] Option to output polygons in size order
>
> 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<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 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
> > _______________________________________________
> > 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/20160801/60b773b7/attachment-0001.html>