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

[Gary Bamford]

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-boun...@lists.mkgmap.org.uk> on behalf of Ticker 
Berkin <rwb-mkg...@jagit.co.uk>
Sent: 01 August 2016 13:47
To: mkgmap-dev@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 +, 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-boun...@lists.mkgmap.org.uk> on behalf
> of Ticker Berkin <tic...@jagit.co.uk>
> Sent: 28 July 2016 16:41
> To: mkgmap-dev@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 +, 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-boun...@lists.mkgmap.org.uk> on behalf
> > of Ticker Berkin <rwb-mkg...@jagit.co.uk>
> > Sent: 24 July 2016 17:59
> > To: mkgmap-dev@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 th

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

[Ticker Berkin]

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 +, 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-boun...@lists.mkgmap.org.uk> on behalf
> of Ticker Berkin <tic...@jagit.co.uk>
> Sent: 28 July 2016 16:41
> To: mkgmap-dev@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 +, 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-boun...@lists.mkgmap.org.uk> on behalf
> > of Ticker Berkin <rwb-mkg...@jagit.co.uk>
> > Sent: 24 July 2016 17:59
> > To: mkgmap-dev@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 +, Gary Bamford wrote:
> > > Hi Ticker.
> > > 
> > > I have been think abou

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

[Gary Bamford]

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-boun...@lists.mkgmap.org.uk> on behalf of Ticker 
Berkin <tic...@jagit.co.uk>
Sent: 28 July 2016 16:41
To: mkgmap-dev@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 +, 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-boun...@lists.mkgmap.org.uk> on behalf
> of Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Sent: 24 July 2016 17:59
> To: mkgmap-dev@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 +, 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

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

[Ticker Berkin]

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 +, 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-boun...@lists.mkgmap.org.uk> on behalf
> of Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Sent: 24 July 2016 17:59
> To: mkgmap-dev@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 +, 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-boun...@lists.mkgmap.org.uk> on behalf
> > of Ticker Berkin <rwb-mkg...@jagit.co.uk>
> > Sent: 23 July 2016 19:44
> > To: mkgmap-dev@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

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

[Thorsten Kukuk]

On Sun, Jul 31, Gerd Petermann wrote:

> The only other input file is the bounds file. I cannot think of a good reason 
> why that would
> change the result unless it is somehow corrupted.

The coastlines where several times broken in the last weeks and I saw
a flooding of europe.  Somebody was so clever to tag buildings with 
natural=coastline ...
But in this case, not only the islands, but the whole land area should
be flooded.

  Thorsten

-- 
Thorsten Kukuk, Senior Architect SLES & Common Code Base
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Felix Hartmann]

well I have no other rules with 0x3c and resolution 18-21 in my style. So I
don't know how else it can happen. And yes - mapdata is up to date from
geofabrik as of yesterday. Strangely the europe map is fine, Germany and
Alps are not fine - so it's kinda random.
Oh yeah - the name for the water is not Chieemsee but Herreninsel.

However for island the only rule that should fit is:
place=island & layer!=* & 20resolution!=yes & name:en!="North Island" &
name:en!="South Island" & natural!=coastline & area_size() < 200 [0x0d
resolution 20]

but it clearly puts 0x3c and starts at resolution 18. The actual island
does not end up in the map - as I guess 20resolution=yes is set further up
in the style.

On 29 July 2016 at 13:40, Gerd Petermann <gpetermann_muenc...@hotmail.com>
wrote:

> Hi Felix,
>
>
> I have no idea why the Herreninsel
> http://www.openstreetmap.org/way/4605746
>
> should  trigger any of these rules. Are you sure that your input file
> contains the current
>
> OSM data?
>
> To make sure I suggest to download the relation
> http://www.openstreetmap.org/relation/32246
>
> in JOSM, safe it to a file and use that as input for mkgmap.
>
> Next, you can enable logging so that you see what happens in mkgmap.
>
>
> Gerd
>
> --
> *Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von
> Felix Hartmann <extremecar...@gmail.com>
> *Gesendet:* Freitag, 29. Juli 2016 13:12:05
>
> *An:* Development list for mkgmap
> *Betreff:* Re: [mkgmap-dev] Option to output polygons in size order
>
> I guess the area_size() function kinda checks if it's big enough - and in
> turn does not check anymore if it is part of the multipolygon or not. Else
> I really cannot explain the flooding. I can change all lines which have
> 0x3c to a unique number - and check which line it is. Will do so tomorrow.
> However there is clearly some bug.
>
> On 29 July 2016 at 12:05, Gerd Petermann <gpetermann_muenc...@hotmail.com>
> wrote:
>
>> Hi Felix,
>>
>>
>> I suggest to use echotags to find out if a rule fires or not. What kind
>> of error
>>
>> do you expect with the area_size() function?
>>
>>
>> Gerd
>> ------------------
>> *Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
>> von Felix Hartmann <extremecar...@gmail.com>
>> *Gesendet:* Freitag, 29. Juli 2016 11:45:47
>>
>> *An:* Development list for mkgmap
>> *Betreff:* Re: [mkgmap-dev] Option to output polygons in size order
>>
>> Nope - it's not the splitter - it's fully within one tile. I guess there
>> is a bug in the style parser together with area_size() filter and continue
>> command?
>>
>> I actually looked at it with gpsmapedit - and I see the island is cut out
>> - but additionally to the cut out water is put into it. The only lines in
>> my polygons file that can be related to it are as follows:
>> (note the flooded island also exists at resolution 18 as 0x3c - so all
>> other lines are only relevant for the key 20resolution!=yes).
>> I put those lines which should not fire in grey. Chiemsee is
>> natural=water & water=lake.
>>
>> ( natural=forest | landuse=wood | natural=forrest | landuse=forrest )
>> {set landuse=forest}
>> ( landuse=forest | natural=wood ) {set 20resolution=yes} [0x50 resolution
>> 18-20 continue with_actions]
>> ( natural=glacier | landuse=glacier ) & 20resolution!=yes {set
>> 20resolution=yes} [0x4d resolution 18-21 continue with_actions]
>>
>> ( natural=lake | ( natural=water & water=lake)) & 20resolution!=yes {set
>> 20resolution=yes} [0x3c resolution 18-21 continue with_actions]
>> natural=water & water=oxbow & 20resolution!=yes {set
>> 20resolution=yes} [0x3c resolution 20-21 continue with_actions]
>> natural=water & ( water=cove | water=lagoon )& 20resolution!=yes {set
>> 20resolution=yes} [0x3c resolution 21-21 continue with_actions]
>> natural=water & water=* & water!=lake & water!=reservoir & water!=canal &
>> water!=river & water!=yes & water!=Cove & water!=bay & water!=Lake  &
>> area_size() < 1000 & 20resolution!=yes {set 20resolution=yes}
>> natural=water & water=reflecting_pool & 20resolution!=yes {set
>> 20resolution=yes}
>> natural=water & water=lock & 20resolution!=yes {set 20resolution=yes}
>> natural=water & water=moat & 20resolution!=yes {set 20resolution=yes}
>> natural=water & water=wastewater & 20resolution!=

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

[Gerd Petermann]

Hi Felix,


I have no idea why the Herreninsel http://www.openstreetmap.org/way/4605746

should  trigger any of these rules. Are you sure that your input file contains 
the current

OSM data?

To make sure I suggest to download the relation 
http://www.openstreetmap.org/relation/32246

in JOSM, safe it to a file and use that as input for mkgmap.

Next, you can enable logging so that you see what happens in mkgmap.


Gerd


Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Felix 
Hartmann <extremecar...@gmail.com>
Gesendet: Freitag, 29. Juli 2016 13:12:05
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Option to output polygons in size order

I guess the area_size() function kinda checks if it's big enough - and in turn 
does not check anymore if it is part of the multipolygon or not. Else I really 
cannot explain the flooding. I can change all lines which have 0x3c to a unique 
number - and check which line it is. Will do so tomorrow. However there is 
clearly some bug.

On 29 July 2016 at 12:05, Gerd Petermann 
<gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>> wrote:

Hi Felix,


I suggest to use echotags to find out if a rule fires or not. What kind of error

do you expect with the area_size() function?


Gerd


Von: mkgmap-dev 
<mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Felix Hartmann 
<extremecar...@gmail.com<mailto:extremecar...@gmail.com>>
Gesendet: Freitag, 29. Juli 2016 11:45:47

An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Option to output polygons in size order

Nope - it's not the splitter - it's fully within one tile. I guess there is a 
bug in the style parser together with area_size() filter and continue command?

I actually looked at it with gpsmapedit - and I see the island is cut out - but 
additionally to the cut out water is put into it. The only lines in my polygons 
file that can be related to it are as follows:
(note the flooded island also exists at resolution 18 as 0x3c - so all other 
lines are only relevant for the key 20resolution!=yes).
I put those lines which should not fire in grey. Chiemsee is natural=water & 
water=lake.

( natural=forest | landuse=wood | natural=forrest | landuse=forrest ) {set 
landuse=forest}
( landuse=forest | natural=wood ) {set 20resolution=yes} [0x50 resolution 18-20 
continue with_actions]
( natural=glacier | landuse=glacier ) & 20resolution!=yes {set 
20resolution=yes} [0x4d resolution 18-21 continue with_actions]

( natural=lake | ( natural=water & water=lake)) & 20resolution!=yes {set 
20resolution=yes} [0x3c resolution 18-21 continue with_actions]
natural=water & water=oxbow & 20resolution!=yes {set 20resolution=yes} 
[0x3c resolution 20-21 continue with_actions]
natural=water & ( water=cove | water=lagoon )& 20resolution!=yes {set 
20resolution=yes} [0x3c resolution 21-21 continue with_actions]
natural=water & water=* & water!=lake & water!=reservoir & water!=canal & 
water!=river & water!=yes & water!=Cove & water!=bay & water!=Lake  & 
area_size() < 1000 & 20resolution!=yes {set 20resolution=yes}
natural=water & water=reflecting_pool & 20resolution!=yes {set 
20resolution=yes}
natural=water & water=lock & 20resolution!=yes {set 20resolution=yes}
natural=water & water=moat & 20resolution!=yes {set 20resolution=yes}
natural=water & water=wastewater & 20resolution!=yes {set 20resolution=yes}
natural=water & ( water=shallow | water=drain | water=well | water=salt_pool | 
water='Salt_pool' ) & 20resolution!=yes {set 20resolution=yes}
natural=water & ( water=intermittent | intermettent=yes ) & 
20resolution!=yes {set 20resolution=yes}
natural=water & ( water=reservoir | water=canal )& 20resolution!=yes {set 
20resolution=yes} [0x3c resolution 19-21 continue with_actions]
natural=water & 20resolution!=yes & area_size() > 2000 {set 20resolution=yes} 
[0x3c resolution 18-21 continue with_actions]



Is there maybe a bug related to the area_size() filter and Multipolygons?

(not I did not use yet this mornings patch). Right now my server is blocked - I 
can try out things only from tomorrow onwards.

On 29 July 2016 at 07:07, Gerd Petermann 
<gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>> wrote:

Hi Felix,


okay. In case that you also used splitter to calculate new tiles a possible 
explanation

might be a special case at tile boundaries, although the --keep-complete option 
should

avoid that.


Gerd


Von: mkgmap-dev 
<mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Felix Hartmann

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

[Felix Hartmann]

I guess the area_size() function kinda checks if it's big enough - and in
turn does not check anymore if it is part of the multipolygon or not. Else
I really cannot explain the flooding. I can change all lines which have
0x3c to a unique number - and check which line it is. Will do so tomorrow.
However there is clearly some bug.

On 29 July 2016 at 12:05, Gerd Petermann <gpetermann_muenc...@hotmail.com>
wrote:

> Hi Felix,
>
>
> I suggest to use echotags to find out if a rule fires or not. What kind of
> error
>
> do you expect with the area_size() function?
>
>
> Gerd
> --
> *Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von
> Felix Hartmann <extremecar...@gmail.com>
> *Gesendet:* Freitag, 29. Juli 2016 11:45:47
>
> *An:* Development list for mkgmap
> *Betreff:* Re: [mkgmap-dev] Option to output polygons in size order
>
> Nope - it's not the splitter - it's fully within one tile. I guess there
> is a bug in the style parser together with area_size() filter and continue
> command?
>
> I actually looked at it with gpsmapedit - and I see the island is cut out
> - but additionally to the cut out water is put into it. The only lines in
> my polygons file that can be related to it are as follows:
> (note the flooded island also exists at resolution 18 as 0x3c - so all
> other lines are only relevant for the key 20resolution!=yes).
> I put those lines which should not fire in grey. Chiemsee is natural=water
> & water=lake.
>
> ( natural=forest | landuse=wood | natural=forrest | landuse=forrest ) {set
> landuse=forest}
> ( landuse=forest | natural=wood ) {set 20resolution=yes} [0x50 resolution
> 18-20 continue with_actions]
> ( natural=glacier | landuse=glacier ) & 20resolution!=yes {set
> 20resolution=yes} [0x4d resolution 18-21 continue with_actions]
>
> ( natural=lake | ( natural=water & water=lake)) & 20resolution!=yes {set
> 20resolution=yes} [0x3c resolution 18-21 continue with_actions]
> natural=water & water=oxbow & 20resolution!=yes {set 20resolution=yes}
> [0x3c resolution 20-21 continue with_actions]
> natural=water & ( water=cove | water=lagoon )& 20resolution!=yes {set
> 20resolution=yes} [0x3c resolution 21-21 continue with_actions]
> natural=water & water=* & water!=lake & water!=reservoir & water!=canal &
> water!=river & water!=yes & water!=Cove & water!=bay & water!=Lake  &
> area_size() < 1000 & 20resolution!=yes {set 20resolution=yes}
> natural=water & water=reflecting_pool & 20resolution!=yes {set
> 20resolution=yes}
> natural=water & water=lock & 20resolution!=yes {set 20resolution=yes}
> natural=water & water=moat & 20resolution!=yes {set 20resolution=yes}
> natural=water & water=wastewater & 20resolution!=yes {set
> 20resolution=yes}
> natural=water & ( water=shallow | water=drain | water=well |
> water=salt_pool | water='Salt_pool' ) & 20resolution!=yes {set
> 20resolution=yes}
> natural=water & ( water=intermittent | intermettent=yes ) &
> 20resolution!=yes {set 20resolution=yes}
> natural=water & ( water=reservoir | water=canal )& 20resolution!=yes
> {set 20resolution=yes} [0x3c resolution 19-21 continue with_actions]
> natural=water & 20resolution!=yes & area_size() > 2000 {set
> 20resolution=yes} [0x3c resolution 18-21 continue with_actions]
>
>
>
> Is there maybe a bug related to the area_size() filter and Multipolygons?
>
> (not I did not use yet this mornings patch). Right now my server is
> blocked - I can try out things only from tomorrow onwards.
>
> On 29 July 2016 at 07:07, Gerd Petermann <gpetermann_muenc...@hotmail.com>
> wrote:
>
>> Hi Felix,
>>
>>
>> okay. In case that you also used splitter to calculate new tiles a
>> possible explanation
>>
>> might be a special case at tile boundaries, although the --keep-complete
>> option should
>>
>> avoid that.
>>
>>
>> Gerd
>> --
>> *Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
>> von Felix Hartmann <extremecar...@gmail.com>
>> *Gesendet:* Freitag, 29. Juli 2016 00:11:45
>> *An:* Development list for mkgmap
>> *Betreff:* Re: [mkgmap-dev] Option to output polygons in size order
>>
>> Well - recompiled and this time the Chieemsee is fine. Really do wonder
>> why it missed the islands. Next time someone reports somethink like this -
>> or I notice a problem somewhere I'll report on time...
>>
>> On 27 July 2016 at 16:08, Thorsten Kukuk <ku...@

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

[Gerd Petermann]

Hi Felix,


I suggest to use echotags to find out if a rule fires or not. What kind of error

do you expect with the area_size() function?


Gerd


Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Felix 
Hartmann <extremecar...@gmail.com>
Gesendet: Freitag, 29. Juli 2016 11:45:47
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Option to output polygons in size order

Nope - it's not the splitter - it's fully within one tile. I guess there is a 
bug in the style parser together with area_size() filter and continue command?

I actually looked at it with gpsmapedit - and I see the island is cut out - but 
additionally to the cut out water is put into it. The only lines in my polygons 
file that can be related to it are as follows:
(note the flooded island also exists at resolution 18 as 0x3c - so all other 
lines are only relevant for the key 20resolution!=yes).
I put those lines which should not fire in grey. Chiemsee is natural=water & 
water=lake.

( natural=forest | landuse=wood | natural=forrest | landuse=forrest ) {set 
landuse=forest}
( landuse=forest | natural=wood ) {set 20resolution=yes} [0x50 resolution 18-20 
continue with_actions]
( natural=glacier | landuse=glacier ) & 20resolution!=yes {set 
20resolution=yes} [0x4d resolution 18-21 continue with_actions]

( natural=lake | ( natural=water & water=lake)) & 20resolution!=yes {set 
20resolution=yes} [0x3c resolution 18-21 continue with_actions]
natural=water & water=oxbow & 20resolution!=yes {set 20resolution=yes} 
[0x3c resolution 20-21 continue with_actions]
natural=water & ( water=cove | water=lagoon )& 20resolution!=yes {set 
20resolution=yes} [0x3c resolution 21-21 continue with_actions]
natural=water & water=* & water!=lake & water!=reservoir & water!=canal & 
water!=river & water!=yes & water!=Cove & water!=bay & water!=Lake  & 
area_size() < 1000 & 20resolution!=yes {set 20resolution=yes}
natural=water & water=reflecting_pool & 20resolution!=yes {set 
20resolution=yes}
natural=water & water=lock & 20resolution!=yes {set 20resolution=yes}
natural=water & water=moat & 20resolution!=yes {set 20resolution=yes}
natural=water & water=wastewater & 20resolution!=yes {set 20resolution=yes}
natural=water & ( water=shallow | water=drain | water=well | water=salt_pool | 
water='Salt_pool' ) & 20resolution!=yes {set 20resolution=yes}
natural=water & ( water=intermittent | intermettent=yes ) & 
20resolution!=yes {set 20resolution=yes}
natural=water & ( water=reservoir | water=canal )& 20resolution!=yes {set 
20resolution=yes} [0x3c resolution 19-21 continue with_actions]
natural=water & 20resolution!=yes & area_size() > 2000 {set 20resolution=yes} 
[0x3c resolution 18-21 continue with_actions]



Is there maybe a bug related to the area_size() filter and Multipolygons?

(not I did not use yet this mornings patch). Right now my server is blocked - I 
can try out things only from tomorrow onwards.

On 29 July 2016 at 07:07, Gerd Petermann 
<gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>> wrote:

Hi Felix,


okay. In case that you also used splitter to calculate new tiles a possible 
explanation

might be a special case at tile boundaries, although the --keep-complete option 
should

avoid that.


Gerd


Von: mkgmap-dev 
<mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Felix Hartmann 
<extremecar...@gmail.com<mailto:extremecar...@gmail.com>>
Gesendet: Freitag, 29. Juli 2016 00:11:45
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Option to output polygons in size order

Well - recompiled and this time the Chieemsee is fine. Really do wonder why it 
missed the islands. Next time someone reports somethink like this - or I notice 
a problem somewhere I'll report on time...

On 27 July 2016 at 16:08, Thorsten Kukuk <ku...@suse.de<mailto:ku...@suse.de>> 
wrote:
On Wed, Jul 27, Felix Hartmann wrote:

> Ah - I guess the Chieemsee will be taken from the sea input files - won't
> it?

No, it does not. Lakes are natural=water and most of the time multipolygones.

> I never really now what water features are taken from which input.

Quite easy: coastline, and only coastlines, are taken from the sea input.
Lakes are no sea.

> If
> not I would really wonder why all islands in the Chieemsee are flooded for
> me. The Chieemsee was updated last time 20 days ago - so I should have the
> correct data if it is taken from the normal osm.pbf file.

On my map, the Chiemsee including the three islands, is correct, no flooding
anywhere.

  Thorsten

> I used them since 10.06.2016 without update. I just uploaded the version 

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

[Felix Hartmann]

Nope - it's not the splitter - it's fully within one tile. I guess there is
a bug in the style parser together with area_size() filter and continue
command?

I actually looked at it with gpsmapedit - and I see the island is cut out -
but additionally to the cut out water is put into it. The only lines in my
polygons file that can be related to it are as follows:
(note the flooded island also exists at resolution 18 as 0x3c - so all
other lines are only relevant for the key 20resolution!=yes).
I put those lines which should not fire in grey. Chiemsee is natural=water
& water=lake.

( natural=forest | landuse=wood | natural=forrest | landuse=forrest ) {set
landuse=forest}
( landuse=forest | natural=wood ) {set 20resolution=yes} [0x50 resolution
18-20 continue with_actions]
( natural=glacier | landuse=glacier ) & 20resolution!=yes {set
20resolution=yes} [0x4d resolution 18-21 continue with_actions]

( natural=lake | ( natural=water & water=lake)) & 20resolution!=yes {set
20resolution=yes} [0x3c resolution 18-21 continue with_actions]
natural=water & water=oxbow & 20resolution!=yes {set 20resolution=yes}
[0x3c resolution 20-21 continue with_actions]
natural=water & ( water=cove | water=lagoon )& 20resolution!=yes {set
20resolution=yes} [0x3c resolution 21-21 continue with_actions]
natural=water & water=* & water!=lake & water!=reservoir & water!=canal &
water!=river & water!=yes & water!=Cove & water!=bay & water!=Lake  &
area_size() < 1000 & 20resolution!=yes {set 20resolution=yes}
natural=water & water=reflecting_pool & 20resolution!=yes {set
20resolution=yes}
natural=water & water=lock & 20resolution!=yes {set 20resolution=yes}
natural=water & water=moat & 20resolution!=yes {set 20resolution=yes}
natural=water & water=wastewater & 20resolution!=yes {set
20resolution=yes}
natural=water & ( water=shallow | water=drain | water=well |
water=salt_pool | water='Salt_pool' ) & 20resolution!=yes {set
20resolution=yes}
natural=water & ( water=intermittent | intermettent=yes ) &
20resolution!=yes {set 20resolution=yes}
natural=water & ( water=reservoir | water=canal )& 20resolution!=yes
{set 20resolution=yes} [0x3c resolution 19-21 continue with_actions]
natural=water & 20resolution!=yes & area_size() > 2000 {set
20resolution=yes} [0x3c resolution 18-21 continue with_actions]



Is there maybe a bug related to the area_size() filter and Multipolygons?

(not I did not use yet this mornings patch). Right now my server is blocked
- I can try out things only from tomorrow onwards.

On 29 July 2016 at 07:07, Gerd Petermann <gpetermann_muenc...@hotmail.com>
wrote:

> Hi Felix,
>
>
> okay. In case that you also used splitter to calculate new tiles a
> possible explanation
>
> might be a special case at tile boundaries, although the --keep-complete
> option should
>
> avoid that.
>
>
> Gerd
> --
> *Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von
> Felix Hartmann <extremecar...@gmail.com>
> *Gesendet:* Freitag, 29. Juli 2016 00:11:45
> *An:* Development list for mkgmap
> *Betreff:* Re: [mkgmap-dev] Option to output polygons in size order
>
> Well - recompiled and this time the Chieemsee is fine. Really do wonder
> why it missed the islands. Next time someone reports somethink like this -
> or I notice a problem somewhere I'll report on time...
>
> On 27 July 2016 at 16:08, Thorsten Kukuk <ku...@suse.de> wrote:
>
>> On Wed, Jul 27, Felix Hartmann wrote:
>>
>> > Ah - I guess the Chieemsee will be taken from the sea input files -
>> won't
>> > it?
>>
>> No, it does not. Lakes are natural=water and most of the time
>> multipolygones.
>>
>> > I never really now what water features are taken from which input.
>>
>> Quite easy: coastline, and only coastlines, are taken from the sea input.
>> Lakes are no sea.
>>
>> > If
>> > not I would really wonder why all islands in the Chieemsee are flooded
>> for
>> > me. The Chieemsee was updated last time 20 days ago - so I should have
>> the
>> > correct data if it is taken from the normal osm.pbf file.
>>
>> On my map, the Chiemsee including the three islands, is correct, no
>> flooding
>> anywhere.
>>
>>   Thorsten
>>
>> > I used them since 10.06.2016 without update. I just uploaded the
>> version I
>> > use here: https://openmtbmap.org/sea.zip
>> >
>> >
>> > Felix
>> >
>> >
>> >
>> > On 27 July 2016 at 15:14, Gerd Petermann <
>> gpetermann_muenc..

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

[Felix Hartmann]

Well - recompiled and this time the Chieemsee is fine. Really do wonder why
it missed the islands. Next time someone reports somethink like this - or I
notice a problem somewhere I'll report on time...

On 27 July 2016 at 16:08, Thorsten Kukuk <ku...@suse.de> wrote:

> On Wed, Jul 27, Felix Hartmann wrote:
>
> > Ah - I guess the Chieemsee will be taken from the sea input files - won't
> > it?
>
> No, it does not. Lakes are natural=water and most of the time
> multipolygones.
>
> > I never really now what water features are taken from which input.
>
> Quite easy: coastline, and only coastlines, are taken from the sea input.
> Lakes are no sea.
>
> > If
> > not I would really wonder why all islands in the Chieemsee are flooded
> for
> > me. The Chieemsee was updated last time 20 days ago - so I should have
> the
> > correct data if it is taken from the normal osm.pbf file.
>
> On my map, the Chiemsee including the three islands, is correct, no
> flooding
> anywhere.
>
>   Thorsten
>
> > I used them since 10.06.2016 without update. I just uploaded the version
> I
> > use here: https://openmtbmap.org/sea.zip
> >
> >
> > Felix
> >
> >
> >
> > On 27 July 2016 at 15:14, Gerd Petermann <
> gpetermann_muenc...@hotmail.com>
> > wrote:
> >
> > > Hmm,
> > >
> > >
> > > the way 4605746 is an inner member of mp-relation
> > > https://www.openstreetmap.org/relation/32246
> > >
> > > I see no problems with the default style. Do you still have the 18.07.
> > > data ?
> > >
> > >
> > > Gerd
> > >
> > >
> > > ------
> > > *Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> von
> > > Felix Hartmann <extremecar...@gmail.com>
> > > *Gesendet:* Mittwoch, 27. Juli 2016 14:59:51
> > >
> > > *An:* Development list for mkgmap
> > > *Betreff:* Re: [mkgmap-dev] Option to output polygons in size order
> > >
> > > Oh - check the Herreninsel Chieemsee. It was flooded based on 18.07
> data
> > > and already flodded in June. Was fine in March though.
> > >
> > > http://www.openstreetmap.org/way/4605746
> > >
> > > It should be a multipolygon but it's not. It's much smaller than the
> lake
> > > however. Basically right now in my map the whole forest is flooded.
> Also
> > > Fraueninsel flooded. Mapnik get'r it right however!
> > >
> > > On 27 July 2016 at 14:52, Felix Hartmann <extremecar...@gmail.com>
> wrote:
> > >
> > >> Know - sadly not. Usually such places are fixed up sooner or later -
> and
> > >> then sometimes destroyed again. It's kinda hard to find them too -
> because
> > >> you will either give lake or water preference (or give it same
> > >> draw-priority and end up with chance). I just know since I
> implemented a
> > >> limited layer approach - complaints about something "missing" are
> much more
> > >> rare.
> > >>
> > >> On 27 July 2016 at 14:44, Gerd Petermann <
> gpetermann_muenc...@hotmail.com
> > >> > wrote:
> > >>
> > >>> Hi Felix,
> > >>>
> > >>>
> > >>> okay, I like the idea reg. layer, but I was not yet able to find an
> > >>> example in OSM.
> > >>>
> > >>> I assume the problem appears only in specific regions wheres such an
> > >>> unexperienced
> > >>>
> > >>> mapper is active. Do you know such a region?
> > >>>
> > >>>
> > >>> Gerd
> > >>>
> > >>>
> > >>> --
> > >>> *Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im
> Auftrag
> > >>> von Felix Hartmann <extremecar...@gmail.com>
> > >>> *Gesendet:* Mittwoch, 27. Juli 2016 14:31:28
> > >>>
> > >>> *An:* Development list for mkgmap
> > >>> *Betreff:* Re: [mkgmap-dev] Option to output polygons in size order
> > >>>
> > >>> Well the smaller polygon in usual is the one that people expect to
> end
> > >>> up on top. HOWEVER - before even checking for size - there could be
> a check
> > >>> for the layer tag. It is still commonly used by people who do not
> > >>> understand how to use multipolygons.
&

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

[Ticker Berkin]

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 +, 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-boun...@lists.mkgmap.org.uk> on behalf
> of Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Sent: 24 July 2016 17:59
> To: mkgmap-dev@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 +, 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-boun...@lists.mkgmap.org.uk> on behalf
> > of Ticker Berkin <rwb-mkg...@jagit.co.uk>
> > Sent: 23 July 2016 19:44
> > To: mkgmap-dev@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

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

[Gary Bamford]

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-boun...@lists.mkgmap.org.uk> on behalf of Ticker 
Berkin <rwb-mkg...@jagit.co.uk>
Sent: 24 July 2016 17:59
To: mkgmap-dev@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 +, 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-boun...@lists.mkgmap.org.uk> on behalf
> of Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Sent: 23 July 2016 19:44
> To: mkgmap-dev@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 +, 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, le

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

[Thorsten Kukuk]

On Wed, Jul 27, Felix Hartmann wrote:

> Ah - I guess the Chieemsee will be taken from the sea input files - won't
> it?

No, it does not. Lakes are natural=water and most of the time multipolygones.

> I never really now what water features are taken from which input.

Quite easy: coastline, and only coastlines, are taken from the sea input.
Lakes are no sea.

> If
> not I would really wonder why all islands in the Chieemsee are flooded for
> me. The Chieemsee was updated last time 20 days ago - so I should have the
> correct data if it is taken from the normal osm.pbf file.

On my map, the Chiemsee including the three islands, is correct, no flooding
anywhere.

  Thorsten

> I used them since 10.06.2016 without update. I just uploaded the version I
> use here: https://openmtbmap.org/sea.zip
> 
> 
> Felix
> 
> 
> 
> On 27 July 2016 at 15:14, Gerd Petermann <gpetermann_muenc...@hotmail.com>
> wrote:
> 
> > Hmm,
> >
> >
> > the way 4605746 is an inner member of mp-relation
> > https://www.openstreetmap.org/relation/32246
> >
> > I see no problems with the default style. Do you still have the 18.07.
> > data ?
> >
> >
> > Gerd
> >
> >
> > --
> > *Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von
> > Felix Hartmann <extremecar...@gmail.com>
> > *Gesendet:* Mittwoch, 27. Juli 2016 14:59:51
> >
> > *An:* Development list for mkgmap
> > *Betreff:* Re: [mkgmap-dev] Option to output polygons in size order
> >
> > Oh - check the Herreninsel Chieemsee. It was flooded based on 18.07 data
> > and already flodded in June. Was fine in March though.
> >
> > http://www.openstreetmap.org/way/4605746
> >
> > It should be a multipolygon but it's not. It's much smaller than the lake
> > however. Basically right now in my map the whole forest is flooded. Also
> > Fraueninsel flooded. Mapnik get'r it right however!
> >
> > On 27 July 2016 at 14:52, Felix Hartmann <extremecar...@gmail.com> wrote:
> >
> >> Know - sadly not. Usually such places are fixed up sooner or later - and
> >> then sometimes destroyed again. It's kinda hard to find them too - because
> >> you will either give lake or water preference (or give it same
> >> draw-priority and end up with chance). I just know since I implemented a
> >> limited layer approach - complaints about something "missing" are much more
> >> rare.
> >>
> >> On 27 July 2016 at 14:44, Gerd Petermann <gpetermann_muenc...@hotmail.com
> >> > wrote:
> >>
> >>> Hi Felix,
> >>>
> >>>
> >>> okay, I like the idea reg. layer, but I was not yet able to find an
> >>> example in OSM.
> >>>
> >>> I assume the problem appears only in specific regions wheres such an
> >>> unexperienced
> >>>
> >>> mapper is active. Do you know such a region?
> >>>
> >>>
> >>> Gerd
> >>>
> >>>
> >>> --
> >>> *Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> >>> von Felix Hartmann <extremecar...@gmail.com>
> >>> *Gesendet:* Mittwoch, 27. Juli 2016 14:31:28
> >>>
> >>> *An:* Development list for mkgmap
> >>> *Betreff:* Re: [mkgmap-dev] Option to output polygons in size order
> >>>
> >>> Well the smaller polygon in usual is the one that people expect to end
> >>> up on top. HOWEVER - before even checking for size - there could be a 
> >>> check
> >>> for the layer tag. It is still commonly used by people who do not
> >>> understand how to use multipolygons.
> >>>
> >>> So an approach could be - take polygon overlap check for values defined
> >>> in "overlap" style-file - after multipolgyon overlap is gone.
> >>> Check if layer tag is present on either of the polygons. If yes - then
> >>> cut out according to layer.
> >>> If not - cut out the smaller from the bigger. Usually it's the smaller
> >>> polygon that should appear.
> >>>
> >>> I guess it needs to happen quite late therefore. Why smaller - well
> >>> quite often people contacted me about islands missing/flooded or similar -
> >>> and usually it was the smaller polygon that should have been on top. I
> >>> guess with layer tag however 90% of all cases can already be resolved. (

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

[Gerd Petermann]

I would be surprised to find a lake in the saa data, the input should be from 
natural=coastline.

Anyway, I tried with your version and still sea the island .

Tested with r3683 and (unchanged) default style.


Gerd


Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Felix 
Hartmann <extremecar...@gmail.com>
Gesendet: Mittwoch, 27. Juli 2016 15:30:09
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Option to output polygons in size order

Ah - I guess the Chieemsee will be taken from the sea input files - won't it? I 
never really now what water features are taken from which input. If not I would 
really wonder why all islands in the Chieemsee are flooded for me. The 
Chieemsee was updated last time 20 days ago - so I should have the correct data 
if it is taken from the normal osm.pbf file.

I used them since 10.06.2016 without update. I just uploaded the version I use 
here: https://openmtbmap.org/sea.zip


Felix



On 27 July 2016 at 15:14, Gerd Petermann 
<gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>> wrote:

Hmm,


the way 4605746 is an inner member of mp-relation 
https://www.openstreetmap.org/relation/32246

I see no problems with the default style. Do you still have the 18.07. data ?


Gerd



Von: mkgmap-dev 
<mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Felix Hartmann 
<extremecar...@gmail.com<mailto:extremecar...@gmail.com>>
Gesendet: Mittwoch, 27. Juli 2016 14:59:51

An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Option to output polygons in size order

Oh - check the Herreninsel Chieemsee. It was flooded based on 18.07 data and 
already flodded in June. Was fine in March though.

http://www.openstreetmap.org/way/4605746

It should be a multipolygon but it's not. It's much smaller than the lake 
however. Basically right now in my map the whole forest is flooded. Also 
Fraueninsel flooded. Mapnik get'r it right however!

On 27 July 2016 at 14:52, Felix Hartmann 
<extremecar...@gmail.com<mailto:extremecar...@gmail.com>> wrote:
Know - sadly not. Usually such places are fixed up sooner or later - and then 
sometimes destroyed again. It's kinda hard to find them too - because you will 
either give lake or water preference (or give it same draw-priority and end up 
with chance). I just know since I implemented a limited layer approach - 
complaints about something "missing" are much more rare.

On 27 July 2016 at 14:44, Gerd Petermann 
<gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>> wrote:

Hi Felix,


okay, I like the idea reg. layer, but I was not yet able to find an example in 
OSM.

I assume the problem appears only in specific regions wheres such an 
unexperienced

mapper is active. Do you know such a region?


Gerd



Von: mkgmap-dev 
<mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Felix Hartmann 
<extremecar...@gmail.com<mailto:extremecar...@gmail.com>>
Gesendet: Mittwoch, 27. Juli 2016 14:31:28

An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Option to output polygons in size order

Well the smaller polygon in usual is the one that people expect to end up on 
top. HOWEVER - before even checking for size - there could be a check for the 
layer tag. It is still commonly used by people who do not understand how to use 
multipolygons.

So an approach could be - take polygon overlap check for values defined in 
"overlap" style-file - after multipolgyon overlap is gone.
Check if layer tag is present on either of the polygons. If yes - then cut out 
according to layer.
If not - cut out the smaller from the bigger. Usually it's the smaller polygon 
that should appear.

I guess it needs to happen quite late therefore. Why smaller - well quite often 
people contacted me about islands missing/flooded or similar - and usually it 
was the smaller polygon that should have been on top. I guess with layer tag 
however 90% of all cases can already be resolved. (I do this in a very limited 
way already - by having some polygons like water and forest in several versions 
with different priority based on layer tag - this did help a lot)

Felix

On 27 July 2016 at 13:41, Gerd Petermann 
<gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>> wrote:

Hi Felix,


okay, maybe I'll add this as an experimental option as well.

One big question here is: At what point would the cutting

happen? Before style processing (as we do with mp-relations)

or maybe as a new stage before the img data is written.


What I don't yet understand is the idea that a smaller

polygon is more important. Do you have examples for that,

esp. cases where shapes do only partially o

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

[Felix Hartmann]

Ah - I guess the Chieemsee will be taken from the sea input files - won't
it? I never really now what water features are taken from which input. If
not I would really wonder why all islands in the Chieemsee are flooded for
me. The Chieemsee was updated last time 20 days ago - so I should have the
correct data if it is taken from the normal osm.pbf file.

I used them since 10.06.2016 without update. I just uploaded the version I
use here: https://openmtbmap.org/sea.zip


Felix



On 27 July 2016 at 15:14, Gerd Petermann <gpetermann_muenc...@hotmail.com>
wrote:

> Hmm,
>
>
> the way 4605746 is an inner member of mp-relation
> https://www.openstreetmap.org/relation/32246
>
> I see no problems with the default style. Do you still have the 18.07.
> data ?
>
>
> Gerd
>
>
> --
> *Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von
> Felix Hartmann <extremecar...@gmail.com>
> *Gesendet:* Mittwoch, 27. Juli 2016 14:59:51
>
> *An:* Development list for mkgmap
> *Betreff:* Re: [mkgmap-dev] Option to output polygons in size order
>
> Oh - check the Herreninsel Chieemsee. It was flooded based on 18.07 data
> and already flodded in June. Was fine in March though.
>
> http://www.openstreetmap.org/way/4605746
>
> It should be a multipolygon but it's not. It's much smaller than the lake
> however. Basically right now in my map the whole forest is flooded. Also
> Fraueninsel flooded. Mapnik get'r it right however!
>
> On 27 July 2016 at 14:52, Felix Hartmann <extremecar...@gmail.com> wrote:
>
>> Know - sadly not. Usually such places are fixed up sooner or later - and
>> then sometimes destroyed again. It's kinda hard to find them too - because
>> you will either give lake or water preference (or give it same
>> draw-priority and end up with chance). I just know since I implemented a
>> limited layer approach - complaints about something "missing" are much more
>> rare.
>>
>> On 27 July 2016 at 14:44, Gerd Petermann <gpetermann_muenc...@hotmail.com
>> > wrote:
>>
>>> Hi Felix,
>>>
>>>
>>> okay, I like the idea reg. layer, but I was not yet able to find an
>>> example in OSM.
>>>
>>> I assume the problem appears only in specific regions wheres such an
>>> unexperienced
>>>
>>> mapper is active. Do you know such a region?
>>>
>>>
>>> Gerd
>>>
>>>
>>> --
>>> *Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
>>> von Felix Hartmann <extremecar...@gmail.com>
>>> *Gesendet:* Mittwoch, 27. Juli 2016 14:31:28
>>>
>>> *An:* Development list for mkgmap
>>> *Betreff:* Re: [mkgmap-dev] Option to output polygons in size order
>>>
>>> Well the smaller polygon in usual is the one that people expect to end
>>> up on top. HOWEVER - before even checking for size - there could be a check
>>> for the layer tag. It is still commonly used by people who do not
>>> understand how to use multipolygons.
>>>
>>> So an approach could be - take polygon overlap check for values defined
>>> in "overlap" style-file - after multipolgyon overlap is gone.
>>> Check if layer tag is present on either of the polygons. If yes - then
>>> cut out according to layer.
>>> If not - cut out the smaller from the bigger. Usually it's the smaller
>>> polygon that should appear.
>>>
>>> I guess it needs to happen quite late therefore. Why smaller - well
>>> quite often people contacted me about islands missing/flooded or similar -
>>> and usually it was the smaller polygon that should have been on top. I
>>> guess with layer tag however 90% of all cases can already be resolved. (I
>>> do this in a very limited way already - by having some polygons like water
>>> and forest in several versions with different priority based on layer tag -
>>> this did help a lot)
>>>
>>> Felix
>>>
>>> On 27 July 2016 at 13:41, Gerd Petermann <
>>> gpetermann_muenc...@hotmail.com> wrote:
>>>
>>>> Hi Felix,
>>>>
>>>>
>>>> okay, maybe I'll add this as an experimental option as well.
>>>>
>>>> One big question here is: At what point would the cutting
>>>>
>>>> happen? Before style processing (as we do with mp-relations)
>>>>
>>>> or maybe as a new stage before the img data is written.
>>>>
>>>>
>>>&

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

[Gerd Petermann]

Hmm,


the way 4605746 is an inner member of mp-relation 
https://www.openstreetmap.org/relation/32246

I see no problems with the default style. Do you still have the 18.07. data ?


Gerd



Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Felix 
Hartmann <extremecar...@gmail.com>
Gesendet: Mittwoch, 27. Juli 2016 14:59:51
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Option to output polygons in size order

Oh - check the Herreninsel Chieemsee. It was flooded based on 18.07 data and 
already flodded in June. Was fine in March though.

http://www.openstreetmap.org/way/4605746

It should be a multipolygon but it's not. It's much smaller than the lake 
however. Basically right now in my map the whole forest is flooded. Also 
Fraueninsel flooded. Mapnik get'r it right however!

On 27 July 2016 at 14:52, Felix Hartmann 
<extremecar...@gmail.com<mailto:extremecar...@gmail.com>> wrote:
Know - sadly not. Usually such places are fixed up sooner or later - and then 
sometimes destroyed again. It's kinda hard to find them too - because you will 
either give lake or water preference (or give it same draw-priority and end up 
with chance). I just know since I implemented a limited layer approach - 
complaints about something "missing" are much more rare.

On 27 July 2016 at 14:44, Gerd Petermann 
<gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>> wrote:

Hi Felix,


okay, I like the idea reg. layer, but I was not yet able to find an example in 
OSM.

I assume the problem appears only in specific regions wheres such an 
unexperienced

mapper is active. Do you know such a region?


Gerd



Von: mkgmap-dev 
<mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Felix Hartmann 
<extremecar...@gmail.com<mailto:extremecar...@gmail.com>>
Gesendet: Mittwoch, 27. Juli 2016 14:31:28

An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Option to output polygons in size order

Well the smaller polygon in usual is the one that people expect to end up on 
top. HOWEVER - before even checking for size - there could be a check for the 
layer tag. It is still commonly used by people who do not understand how to use 
multipolygons.

So an approach could be - take polygon overlap check for values defined in 
"overlap" style-file - after multipolgyon overlap is gone.
Check if layer tag is present on either of the polygons. If yes - then cut out 
according to layer.
If not - cut out the smaller from the bigger. Usually it's the smaller polygon 
that should appear.

I guess it needs to happen quite late therefore. Why smaller - well quite often 
people contacted me about islands missing/flooded or similar - and usually it 
was the smaller polygon that should have been on top. I guess with layer tag 
however 90% of all cases can already be resolved. (I do this in a very limited 
way already - by having some polygons like water and forest in several versions 
with different priority based on layer tag - this did help a lot)

Felix

On 27 July 2016 at 13:41, Gerd Petermann 
<gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>> wrote:

Hi Felix,


okay, maybe I'll add this as an experimental option as well.

One big question here is: At what point would the cutting

happen? Before style processing (as we do with mp-relations)

or maybe as a new stage before the img data is written.


What I don't yet understand is the idea that a smaller

polygon is more important. Do you have examples for that,

esp. cases where shapes do only partially overlap?


Gerd


Von: mkgmap-dev 
<mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Felix Hartmann 
<extremecar...@gmail.com<mailto:extremecar...@gmail.com>>
Gesendet: Mittwoch, 27. Juli 2016 13:24:37
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Option to output polygons in size order


On 27 July 2016 at 09:29, Gerd Petermann 
<gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>> wrote:

reg. the idea of "cutting out overlaps": I guess it would consume quite a lot 
of CPU and it would heavily increase the img size

because we would have to write many more points. Think of a shape for 
"place=village" with hundreds of holes for each building

shape. Up to now we save the shape for the village and the shapes for the 
buildings. With cutting we have to calculate what

remains of the village shape, this would be a very complex shape with many 
holes, so it would have many points.

I don't think that would be a good idea.

Well that's why I wrote we will need an additional file in the style-file for 
this. So only for certain polygons this should be done

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

[Felix Hartmann]

Oh - check the Herreninsel Chieemsee. It was flooded based on 18.07 data
and already flodded in June. Was fine in March though.

http://www.openstreetmap.org/way/4605746

It should be a multipolygon but it's not. It's much smaller than the lake
however. Basically right now in my map the whole forest is flooded. Also
Fraueninsel flooded. Mapnik get'r it right however!

On 27 July 2016 at 14:52, Felix Hartmann <extremecar...@gmail.com> wrote:

> Know - sadly not. Usually such places are fixed up sooner or later - and
> then sometimes destroyed again. It's kinda hard to find them too - because
> you will either give lake or water preference (or give it same
> draw-priority and end up with chance). I just know since I implemented a
> limited layer approach - complaints about something "missing" are much more
> rare.
>
> On 27 July 2016 at 14:44, Gerd Petermann <gpetermann_muenc...@hotmail.com>
> wrote:
>
>> Hi Felix,
>>
>>
>> okay, I like the idea reg. layer, but I was not yet able to find an
>> example in OSM.
>>
>> I assume the problem appears only in specific regions wheres such an
>> unexperienced
>>
>> mapper is active. Do you know such a region?
>>
>>
>> Gerd
>>
>>
>> --
>> *Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
>> von Felix Hartmann <extremecar...@gmail.com>
>> *Gesendet:* Mittwoch, 27. Juli 2016 14:31:28
>>
>> *An:* Development list for mkgmap
>> *Betreff:* Re: [mkgmap-dev] Option to output polygons in size order
>>
>> Well the smaller polygon in usual is the one that people expect to end up
>> on top. HOWEVER - before even checking for size - there could be a check
>> for the layer tag. It is still commonly used by people who do not
>> understand how to use multipolygons.
>>
>> So an approach could be - take polygon overlap check for values defined
>> in "overlap" style-file - after multipolgyon overlap is gone.
>> Check if layer tag is present on either of the polygons. If yes - then
>> cut out according to layer.
>> If not - cut out the smaller from the bigger. Usually it's the smaller
>> polygon that should appear.
>>
>> I guess it needs to happen quite late therefore. Why smaller - well quite
>> often people contacted me about islands missing/flooded or similar - and
>> usually it was the smaller polygon that should have been on top. I guess
>> with layer tag however 90% of all cases can already be resolved. (I do this
>> in a very limited way already - by having some polygons like water and
>> forest in several versions with different priority based on layer tag -
>> this did help a lot)
>>
>> Felix
>>
>> On 27 July 2016 at 13:41, Gerd Petermann <gpetermann_muenc...@hotmail.com
>> > wrote:
>>
>>> Hi Felix,
>>>
>>>
>>> okay, maybe I'll add this as an experimental option as well.
>>>
>>> One big question here is: At what point would the cutting
>>>
>>> happen? Before style processing (as we do with mp-relations)
>>>
>>> or maybe as a new stage before the img data is written.
>>>
>>>
>>> What I don't yet understand is the idea that a smaller
>>>
>>> polygon is more important. Do you have examples for that,
>>>
>>> esp. cases where shapes do only partially overlap?
>>>
>>>
>>> Gerd
>>> --
>>> *Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
>>> von Felix Hartmann <extremecar...@gmail.com>
>>> *Gesendet:* Mittwoch, 27. Juli 2016 13:24:37
>>> *An:* Development list for mkgmap
>>> *Betreff:* Re: [mkgmap-dev] Option to output polygons in size order
>>>
>>>
>>> On 27 July 2016 at 09:29, Gerd Petermann <
>>> gpetermann_muenc...@hotmail.com> wrote:
>>>
>>>> reg. the idea of "cutting out overlaps": I guess it would consume quite
>>>> a lot of CPU and it would heavily increase the img size
>>>>
>>>> because we would have to write many more points. Think of a shape for
>>>> "place=village" with hundreds of holes for each building
>>>>
>>>> shape. Up to now we save the shape for the village and the shapes for
>>>> the buildings. With cutting we have to calculate what
>>>>
>>>> remains of the village shape, this would be a very complex shape with
>>>> many holes, so it would have many points.
&

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

[Felix Hartmann]

Know - sadly not. Usually such places are fixed up sooner or later - and
then sometimes destroyed again. It's kinda hard to find them too - because
you will either give lake or water preference (or give it same
draw-priority and end up with chance). I just know since I implemented a
limited layer approach - complaints about something "missing" are much more
rare.

On 27 July 2016 at 14:44, Gerd Petermann <gpetermann_muenc...@hotmail.com>
wrote:

> Hi Felix,
>
>
> okay, I like the idea reg. layer, but I was not yet able to find an
> example in OSM.
>
> I assume the problem appears only in specific regions wheres such an
> unexperienced
>
> mapper is active. Do you know such a region?
>
>
> Gerd
>
>
> --
> *Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von
> Felix Hartmann <extremecar...@gmail.com>
> *Gesendet:* Mittwoch, 27. Juli 2016 14:31:28
>
> *An:* Development list for mkgmap
> *Betreff:* Re: [mkgmap-dev] Option to output polygons in size order
>
> Well the smaller polygon in usual is the one that people expect to end up
> on top. HOWEVER - before even checking for size - there could be a check
> for the layer tag. It is still commonly used by people who do not
> understand how to use multipolygons.
>
> So an approach could be - take polygon overlap check for values defined in
> "overlap" style-file - after multipolgyon overlap is gone.
> Check if layer tag is present on either of the polygons. If yes - then cut
> out according to layer.
> If not - cut out the smaller from the bigger. Usually it's the smaller
> polygon that should appear.
>
> I guess it needs to happen quite late therefore. Why smaller - well quite
> often people contacted me about islands missing/flooded or similar - and
> usually it was the smaller polygon that should have been on top. I guess
> with layer tag however 90% of all cases can already be resolved. (I do this
> in a very limited way already - by having some polygons like water and
> forest in several versions with different priority based on layer tag -
> this did help a lot)
>
> Felix
>
> On 27 July 2016 at 13:41, Gerd Petermann <gpetermann_muenc...@hotmail.com>
> wrote:
>
>> Hi Felix,
>>
>>
>> okay, maybe I'll add this as an experimental option as well.
>>
>> One big question here is: At what point would the cutting
>>
>> happen? Before style processing (as we do with mp-relations)
>>
>> or maybe as a new stage before the img data is written.
>>
>>
>> What I don't yet understand is the idea that a smaller
>>
>> polygon is more important. Do you have examples for that,
>>
>> esp. cases where shapes do only partially overlap?
>>
>>
>> Gerd
>> --
>> *Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
>> von Felix Hartmann <extremecar...@gmail.com>
>> *Gesendet:* Mittwoch, 27. Juli 2016 13:24:37
>> *An:* Development list for mkgmap
>> *Betreff:* Re: [mkgmap-dev] Option to output polygons in size order
>>
>>
>> On 27 July 2016 at 09:29, Gerd Petermann <gpetermann_muenc...@hotmail.com
>> > wrote:
>>
>>> reg. the idea of "cutting out overlaps": I guess it would consume quite
>>> a lot of CPU and it would heavily increase the img size
>>>
>>> because we would have to write many more points. Think of a shape for
>>> "place=village" with hundreds of holes for each building
>>>
>>> shape. Up to now we save the shape for the village and the shapes for
>>> the buildings. With cutting we have to calculate what
>>>
>>> remains of the village shape, this would be a very complex shape with
>>> many holes, so it would have many points.
>>>
>>> I don't think that would be a good idea.
>>>
>>>
>> Well that's why I wrote we will need an additional file in the style-file
>> for this. So only for certain polygons this should be done.
>> Prime examples are: any kind of forest, most kind of water, and maybe a
>> handful more. However definitely not buildings or for example poygons you
>> can put semi-transparent.
>>
>> I'm quite sure with this limited approach 90% of problems would be gone.
>> And mapsize only a couple percent bigger. However I have no clue about
>> complexity and CPU cycles for such a limited approach.
>>
>>
>> --
>> Felix Hartman - Openmtbmap.org & VeloMap.org
>> Schusterbergweg 32/8
>> 6020 Innsbruck
>> Austria - Österreich
>>

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

[Gerd Petermann]

Hi Felix,


okay, I like the idea reg. layer, but I was not yet able to find an example in 
OSM.

I assume the problem appears only in specific regions wheres such an 
unexperienced

mapper is active. Do you know such a region?


Gerd



Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Felix 
Hartmann <extremecar...@gmail.com>
Gesendet: Mittwoch, 27. Juli 2016 14:31:28
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Option to output polygons in size order

Well the smaller polygon in usual is the one that people expect to end up on 
top. HOWEVER - before even checking for size - there could be a check for the 
layer tag. It is still commonly used by people who do not understand how to use 
multipolygons.

So an approach could be - take polygon overlap check for values defined in 
"overlap" style-file - after multipolgyon overlap is gone.
Check if layer tag is present on either of the polygons. If yes - then cut out 
according to layer.
If not - cut out the smaller from the bigger. Usually it's the smaller polygon 
that should appear.

I guess it needs to happen quite late therefore. Why smaller - well quite often 
people contacted me about islands missing/flooded or similar - and usually it 
was the smaller polygon that should have been on top. I guess with layer tag 
however 90% of all cases can already be resolved. (I do this in a very limited 
way already - by having some polygons like water and forest in several versions 
with different priority based on layer tag - this did help a lot)

Felix

On 27 July 2016 at 13:41, Gerd Petermann 
<gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>> wrote:

Hi Felix,


okay, maybe I'll add this as an experimental option as well.

One big question here is: At what point would the cutting

happen? Before style processing (as we do with mp-relations)

or maybe as a new stage before the img data is written.


What I don't yet understand is the idea that a smaller

polygon is more important. Do you have examples for that,

esp. cases where shapes do only partially overlap?


Gerd


Von: mkgmap-dev 
<mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Felix Hartmann 
<extremecar...@gmail.com<mailto:extremecar...@gmail.com>>
Gesendet: Mittwoch, 27. Juli 2016 13:24:37
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Option to output polygons in size order


On 27 July 2016 at 09:29, Gerd Petermann 
<gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>> wrote:

reg. the idea of "cutting out overlaps": I guess it would consume quite a lot 
of CPU and it would heavily increase the img size

because we would have to write many more points. Think of a shape for 
"place=village" with hundreds of holes for each building

shape. Up to now we save the shape for the village and the shapes for the 
buildings. With cutting we have to calculate what

remains of the village shape, this would be a very complex shape with many 
holes, so it would have many points.

I don't think that would be a good idea.

Well that's why I wrote we will need an additional file in the style-file for 
this. So only for certain polygons this should be done.
Prime examples are: any kind of forest, most kind of water, and maybe a handful 
more. However definitely not buildings or for example poygons you can put 
semi-transparent.

I'm quite sure with this limited approach 90% of problems would be gone. And 
mapsize only a couple percent bigger. However I have no clue about complexity 
and CPU cycles for such a limited approach.


--
Felix Hartman - Openmtbmap.org & VeloMap.org
Schusterbergweg 32/8
6020 Innsbruck
Austria - ?sterreich

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



--
Felix Hartman - Openmtbmap.org & VeloMap.org
Schusterbergweg 32/8
6020 Innsbruck
Austria - ?sterreich
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Felix Hartmann]

Well the smaller polygon in usual is the one that people expect to end up
on top. HOWEVER - before even checking for size - there could be a check
for the layer tag. It is still commonly used by people who do not
understand how to use multipolygons.

So an approach could be - take polygon overlap check for values defined in
"overlap" style-file - after multipolgyon overlap is gone.
Check if layer tag is present on either of the polygons. If yes - then cut
out according to layer.
If not - cut out the smaller from the bigger. Usually it's the smaller
polygon that should appear.

I guess it needs to happen quite late therefore. Why smaller - well quite
often people contacted me about islands missing/flooded or similar - and
usually it was the smaller polygon that should have been on top. I guess
with layer tag however 90% of all cases can already be resolved. (I do this
in a very limited way already - by having some polygons like water and
forest in several versions with different priority based on layer tag -
this did help a lot)

Felix

On 27 July 2016 at 13:41, Gerd Petermann <gpetermann_muenc...@hotmail.com>
wrote:

> Hi Felix,
>
>
> okay, maybe I'll add this as an experimental option as well.
>
> One big question here is: At what point would the cutting
>
> happen? Before style processing (as we do with mp-relations)
>
> or maybe as a new stage before the img data is written.
>
>
> What I don't yet understand is the idea that a smaller
>
> polygon is more important. Do you have examples for that,
>
> esp. cases where shapes do only partially overlap?
>
>
> Gerd
> --
> *Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von
> Felix Hartmann <extremecar...@gmail.com>
> *Gesendet:* Mittwoch, 27. Juli 2016 13:24:37
> *An:* Development list for mkgmap
> *Betreff:* Re: [mkgmap-dev] Option to output polygons in size order
>
>
> On 27 July 2016 at 09:29, Gerd Petermann <gpetermann_muenc...@hotmail.com>
> wrote:
>
>> reg. the idea of "cutting out overlaps": I guess it would consume quite a
>> lot of CPU and it would heavily increase the img size
>>
>> because we would have to write many more points. Think of a shape for
>> "place=village" with hundreds of holes for each building
>>
>> shape. Up to now we save the shape for the village and the shapes for the
>> buildings. With cutting we have to calculate what
>>
>> remains of the village shape, this would be a very complex shape with
>> many holes, so it would have many points.
>>
>> I don't think that would be a good idea.
>>
>>
> Well that's why I wrote we will need an additional file in the style-file
> for this. So only for certain polygons this should be done.
> Prime examples are: any kind of forest, most kind of water, and maybe a
> handful more. However definitely not buildings or for example poygons you
> can put semi-transparent.
>
> I'm quite sure with this limited approach 90% of problems would be gone.
> And mapsize only a couple percent bigger. However I have no clue about
> complexity and CPU cycles for such a limited approach.
>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
> Schusterbergweg 32/8
> 6020 Innsbruck
> Austria - Österreich
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Felix Hartman - Openmtbmap.org & VeloMap.org
Schusterbergweg 32/8
6020 Innsbruck
Austria - Österreich
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Gerd Petermann]

Hi Ticker,


please note that the patch also contains a change to the style file.

If you compare results you should create one map with enabled sorting

and one without, don't compare with the output of r3683.


Gerd


Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Ticker 
Berkin <rwb-mkg...@jagit.co.uk>
Gesendet: Mittwoch, 27. Juli 2016 13:35:05
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Option to output polygons in size order

Hi Gerd

Thanks for this. I've just tested it and a see quite a few land-use
type features that I didn't see before, and changes in my suspect area
but I still don't see the lake (for more than a fraction of a second) I
was expecting.

I'm going to compare some of what I see with how 
www.openStreetMap.org<http://www.openStreetMap.org>
renders the same area - I know it shows the lake.

Ticker

On Wed, 2016-07-27 at 10:33 +, Gerd Petermann wrote:
> Hi Ticker,
>
> here is a patch that contains my latest findings to fix
> the problems reg. "preserved" points plus the experimental code for
> the sorting,
> after applying the patch to r3683 see MapBuilder line 1123 and below.
>
> I still want to fix minor problems with the overview map,
> that's why I did not yet publish the patch.
>
> Gerd
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Gesendet: Mittwoch, 27. Juli 2016 11:57:17
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] Option to output polygons in size order
>
> Hi all
>
> Gerd, do you have a patch I can try - I have some examples where this
> should fix things.
>
> I've started to look at the code and, regardless of --preserve
> -element
> order, mkgmap will chop up and change the processing order of
> polygon,
> relating to overlap, inclusion, bounding box and multi-polygons.
>
> The relevant code is in ./mkgmap/reader/osm/MultiPolygonRelation.java
>
> I can't work out all of what it is doing, but it
> does seem to have bits  that work out a hierarchy of polygon
> inclusion/overlap. I suspect that multi-polygons and maybe overlaps
> sometimes cause this to process a contained simple polygon before
> processing one that contains it.
>
> My idea of sorting by size was to avoid trying to calculate this
> inclusion hierarchy - a polygon can't contained a larger one!
>
> I don't think I'd like to touch any code in MultiPolyonRelation, so I
> still think the best solution is sorting somewhere in Mapbuilder,
> after
> area splitting.
>
> Ticker
>
> On Wed, 2016-07-27 at 07:29 +, Gerd Petermann wrote:
> > Hi Felix,
> >
> > reg. the idea of "cutting out overlaps": I guess it would consume
> > quite a lot of CPU and it would heavily increase the img size
> > because we would have to write many more points. Think of a shape
> for
> > "place=village" with hundreds of holes for each building
> > shape. Up to now we save the shape for the village and the shapes
> for
> > the buildings. With cutting we have to calculate what
> > remains of the village shape, this would be a very complex shape
> with
> > many holes, so it would have many points.
> > I don't think that would be a good idea.
> >
> > reg. sorting by size: I've not noticed any visible change in
> Basecamp
> > or on my Oregon, so I don't think this is a solution.
> >
> > I looked at maps produced by Garmin and 1st got the impression that
> > they are sorted by type, highest types coming first,
> > but I also found exceptions. Don't know if this means that the
> order
> > is not important or if there is a complex rules behind this.
> >
> > Gerd
> > Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> > von Felix Hartmann <extremecar...@gmail.com>
> > Gesendet: Sonntag, 24. Juli 2016 21:40:47
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Option to output polygons in size order
> >
> > That is not really a good approach. Basecamp orders the polygons
> > opposite to most gps devices. So it will still be broken.
> >
> >
> > There is however a proper way to do - but that would be much much
> > more complicated: Create a list of polygons that may not overlap
> (in
> > the style-file). Then if mkgmap finds that 2 of these polygons do
> > overlap - mkgmap should cut out the smaller polygon shape from the
> > bigger. Basically the result of that approach would mimic how a
> > Mapnik map looks in this case. Still the real solution however
> would
> > be to fix the underlying OSM

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

[Gerd Petermann]

Hi Felix,


okay, maybe I'll add this as an experimental option as well.

One big question here is: At what point would the cutting

happen? Before style processing (as we do with mp-relations)

or maybe as a new stage before the img data is written.


What I don't yet understand is the idea that a smaller

polygon is more important. Do you have examples for that,

esp. cases where shapes do only partially overlap?


Gerd


Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Felix 
Hartmann <extremecar...@gmail.com>
Gesendet: Mittwoch, 27. Juli 2016 13:24:37
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Option to output polygons in size order


On 27 July 2016 at 09:29, Gerd Petermann 
<gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>> wrote:

reg. the idea of "cutting out overlaps": I guess it would consume quite a lot 
of CPU and it would heavily increase the img size

because we would have to write many more points. Think of a shape for 
"place=village" with hundreds of holes for each building

shape. Up to now we save the shape for the village and the shapes for the 
buildings. With cutting we have to calculate what

remains of the village shape, this would be a very complex shape with many 
holes, so it would have many points.

I don't think that would be a good idea.

Well that's why I wrote we will need an additional file in the style-file for 
this. So only for certain polygons this should be done.
Prime examples are: any kind of forest, most kind of water, and maybe a handful 
more. However definitely not buildings or for example poygons you can put 
semi-transparent.

I'm quite sure with this limited approach 90% of problems would be gone. And 
mapsize only a couple percent bigger. However I have no clue about complexity 
and CPU cycles for such a limited approach.


--
Felix Hartman - Openmtbmap.org & VeloMap.org
Schusterbergweg 32/8
6020 Innsbruck
Austria - ?sterreich
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Ticker Berkin]

Hi Gerd

Thanks for this. I've just tested it and a see quite a few land-use
type features that I didn't see before, and changes in my suspect area
but I still don't see the lake (for more than a fraction of a second) I
was expecting.

I'm going to compare some of what I see with how www.openStreetMap.org
renders the same area - I know it shows the lake.

Ticker

On Wed, 2016-07-27 at 10:33 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> here is a patch that contains my latest findings to fix 
> the problems reg. "preserved" points plus the experimental code for
> the sorting, 
> after applying the patch to r3683 see MapBuilder line 1123 and below.
> 
> I still want to fix minor problems with the overview map,
> that's why I did not yet publish the patch.
> 
> Gerd
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Gesendet: Mittwoch, 27. Juli 2016 11:57:17
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] Option to output polygons in size order
>  
> Hi all
> 
> Gerd, do you have a patch I can try - I have some examples where this
> should fix things.
> 
> I've started to look at the code and, regardless of --preserve
> -element
> order, mkgmap will chop up and change the processing order of
> polygon,
> relating to overlap, inclusion, bounding box and multi-polygons.
> 
> The relevant code is in ./mkgmap/reader/osm/MultiPolygonRelation.java
> 
> I can't work out all of what it is doing, but it
> does seem to have bits  that work out a hierarchy of polygon
> inclusion/overlap. I suspect that multi-polygons and maybe overlaps
> sometimes cause this to process a contained simple polygon before
> processing one that contains it.
> 
> My idea of sorting by size was to avoid trying to calculate this
> inclusion hierarchy - a polygon can't contained a larger one!
> 
> I don't think I'd like to touch any code in MultiPolyonRelation, so I
> still think the best solution is sorting somewhere in Mapbuilder,
> after
> area splitting. 
> 
> Ticker
> 
> On Wed, 2016-07-27 at 07:29 +, Gerd Petermann wrote:
> > Hi Felix,
> > 
> > reg. the idea of "cutting out overlaps": I guess it would consume
> > quite a lot of CPU and it would heavily increase the img size
> > because we would have to write many more points. Think of a shape
> for
> > "place=village" with hundreds of holes for each building
> > shape. Up to now we save the shape for the village and the shapes
> for
> > the buildings. With cutting we have to calculate what
> > remains of the village shape, this would be a very complex shape
> with
> > many holes, so it would have many points.
> > I don't think that would be a good idea.
> > 
> > reg. sorting by size: I've not noticed any visible change in
> Basecamp
> > or on my Oregon, so I don't think this is a solution.
> > 
> > I looked at maps produced by Garmin and 1st got the impression that
> > they are sorted by type, highest types coming first,
> > but I also found exceptions. Don't know if this means that the
> order
> > is not important or if there is a complex rules behind this.
> > 
> > Gerd
> > Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> > von Felix Hartmann <extremecar...@gmail.com>
> > Gesendet: Sonntag, 24. Juli 2016 21:40:47
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Option to output polygons in size order
> >  
> > That is not really a good approach. Basecamp orders the polygons
> > opposite to most gps devices. So it will still be broken.
> > 
> > 
> > There is however a proper way to do - but that would be much much
> > more complicated: Create a list of polygons that may not overlap
> (in
> > the style-file). Then if mkgmap finds that 2 of these polygons do
> > overlap - mkgmap should cut out the smaller polygon shape from the
> > bigger. Basically the result of that approach would mimic how a
> > Mapnik map looks in this case. Still the real solution however
> would
> > be to fix the underlying OSM data. I have no clue how code and time
> > intensive the "mimic Mapnik" approach would be, but everything else
> > won't really solve much.
> > 
> > On 24 July 2016 at 20:42, Gerd Petermann <
> > gpetermann_muenc...@hotmail.com> wrote:
> > > 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 --pr

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

[Felix Hartmann]

On 27 July 2016 at 09:29, Gerd Petermann 
wrote:

> reg. the idea of "cutting out overlaps": I guess it would consume quite a
> lot of CPU and it would heavily increase the img size
>
> because we would have to write many more points. Think of a shape for
> "place=village" with hundreds of holes for each building
>
> shape. Up to now we save the shape for the village and the shapes for the
> buildings. With cutting we have to calculate what
>
> remains of the village shape, this would be a very complex shape with many
> holes, so it would have many points.
>
> I don't think that would be a good idea.
>
>
Well that's why I wrote we will need an additional file in the style-file
for this. So only for certain polygons this should be done.
Prime examples are: any kind of forest, most kind of water, and maybe a
handful more. However definitely not buildings or for example poygons you
can put semi-transparent.

I'm quite sure with this limited approach 90% of problems would be gone.
And mapsize only a couple percent bigger. However I have no clue about
complexity and CPU cycles for such a limited approach.


-- 
Felix Hartman - Openmtbmap.org & VeloMap.org
Schusterbergweg 32/8
6020 Innsbruck
Austria - Österreich
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Gerd Petermann]

Hi Ticker,


here is a patch that contains my latest findings to fix

the problems reg. "preserved" points plus the experimental code for the sorting,

after applying the patch to r3683 see MapBuilder line 1123 and below.


I still want to fix minor problems with the overview map,

that's why I did not yet publish the patch.


Gerd


Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Ticker 
Berkin <rwb-mkg...@jagit.co.uk>
Gesendet: Mittwoch, 27. Juli 2016 11:57:17
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Option to output polygons in size order

Hi all

Gerd, do you have a patch I can try - I have some examples where this
should fix things.

I've started to look at the code and, regardless of --preserve-element
order, mkgmap will chop up and change the processing order of polygon,
relating to overlap, inclusion, bounding box and multi-polygons.

The relevant code is in ./mkgmap/reader/osm/MultiPolygonRelation.java

I can't work out all of what it is doing, but it
does seem to have bits  that work out a hierarchy of polygon
inclusion/overlap. I suspect that multi-polygons and maybe overlaps
sometimes cause this to process a contained simple polygon before
processing one that contains it.

My idea of sorting by size was to avoid trying to calculate this
inclusion hierarchy - a polygon can't contained a larger one!

I don't think I'd like to touch any code in MultiPolyonRelation, so I
still think the best solution is sorting somewhere in Mapbuilder, after
area splitting.

Ticker

On Wed, 2016-07-27 at 07:29 +, Gerd Petermann wrote:
> Hi Felix,
>
> reg. the idea of "cutting out overlaps": I guess it would consume
> quite a lot of CPU and it would heavily increase the img size
> because we would have to write many more points. Think of a shape for
> "place=village" with hundreds of holes for each building
> shape. Up to now we save the shape for the village and the shapes for
> the buildings. With cutting we have to calculate what
> remains of the village shape, this would be a very complex shape with
> many holes, so it would have many points.
> I don't think that would be a good idea.
>
> reg. sorting by size: I've not noticed any visible change in Basecamp
> or on my Oregon, so I don't think this is a solution.
>
> I looked at maps produced by Garmin and 1st got the impression that
> they are sorted by type, highest types coming first,
> but I also found exceptions. Don't know if this means that the order
> is not important or if there is a complex rules behind this.
>
> Gerd
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> von Felix Hartmann <extremecar...@gmail.com>
> Gesendet: Sonntag, 24. Juli 2016 21:40:47
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Option to output polygons in size order
>
> That is not really a good approach. Basecamp orders the polygons
> opposite to most gps devices. So it will still be broken.
>
>
> There is however a proper way to do - but that would be much much
> more complicated: Create a list of polygons that may not overlap (in
> the style-file). Then if mkgmap finds that 2 of these polygons do
> overlap - mkgmap should cut out the smaller polygon shape from the
> bigger. Basically the result of that approach would mimic how a
> Mapnik map looks in this case. Still the real solution however would
> be to fix the underlying OSM data. I have no clue how code and time
> intensive the "mimic Mapnik" approach would be, but everything else
> won't really solve much.
>
> On 24 July 2016 at 20:42, Gerd Petermann <
> gpetermann_muenc...@hotmail.com> wrote:
> > 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-boun...@lists.mkgmap.org.uk> im Auftrag
> > von Ticker Berkin <rwb-mkg...@jagit.co.uk>
> > Gesendet: Sonntag, 24. Juli 2016 20:23:41
> > An: mkgmap-dev@lists.mkgmap.org.uk
> > Betreff: Re: [mkgmap-dev] Option to output polygons in size order
> >
> > Hi Gerd
> >
> > Looking at the meaning of 

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

[Ticker Berkin]

Hi all

Gerd, do you have a patch I can try - I have some examples where this
should fix things.

I've started to look at the code and, regardless of --preserve-element
order, mkgmap will chop up and change the processing order of polygon,
relating to overlap, inclusion, bounding box and multi-polygons.

The relevant code is in ./mkgmap/reader/osm/MultiPolygonRelation.java

I can't work out all of what it is doing, but it
does seem to have bits  that work out a hierarchy of polygon
inclusion/overlap. I suspect that multi-polygons and maybe overlaps
sometimes cause this to process a contained simple polygon before
processing one that contains it.

My idea of sorting by size was to avoid trying to calculate this
inclusion hierarchy - a polygon can't contained a larger one!

I don't think I'd like to touch any code in MultiPolyonRelation, so I
still think the best solution is sorting somewhere in Mapbuilder, after
area splitting. 

Ticker

On Wed, 2016-07-27 at 07:29 +, Gerd Petermann wrote:
> Hi Felix,
> 
> reg. the idea of "cutting out overlaps": I guess it would consume
> quite a lot of CPU and it would heavily increase the img size
> because we would have to write many more points. Think of a shape for
> "place=village" with hundreds of holes for each building
> shape. Up to now we save the shape for the village and the shapes for
> the buildings. With cutting we have to calculate what
> remains of the village shape, this would be a very complex shape with
> many holes, so it would have many points.
> I don't think that would be a good idea.
> 
> reg. sorting by size: I've not noticed any visible change in Basecamp
> or on my Oregon, so I don't think this is a solution.
> 
> I looked at maps produced by Garmin and 1st got the impression that
> they are sorted by type, highest types coming first,
> but I also found exceptions. Don't know if this means that the order
> is not important or if there is a complex rules behind this.
> 
> Gerd
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> von Felix Hartmann <extremecar...@gmail.com>
> Gesendet: Sonntag, 24. Juli 2016 21:40:47
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Option to output polygons in size order
>  
> That is not really a good approach. Basecamp orders the polygons
> opposite to most gps devices. So it will still be broken.
> 
> 
> There is however a proper way to do - but that would be much much
> more complicated: Create a list of polygons that may not overlap (in
> the style-file). Then if mkgmap finds that 2 of these polygons do
> overlap - mkgmap should cut out the smaller polygon shape from the
> bigger. Basically the result of that approach would mimic how a
> Mapnik map looks in this case. Still the real solution however would
> be to fix the underlying OSM data. I have no clue how code and time
> intensive the "mimic Mapnik" approach would be, but everything else
> won't really solve much.
> 
> On 24 July 2016 at 20:42, Gerd Petermann <
> gpetermann_muenc...@hotmail.com> wrote:
> > 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-boun...@lists.mkgmap.org.uk> im Auftrag
> > von Ticker Berkin <rwb-mkg...@jagit.co.uk>
> > Gesendet: Sonntag, 24. Juli 2016 20:23:41
> > An: mkgmap-dev@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() <
> > 100" to
> > get around the major problem but it seemed a bit arbitrary, and
> > when I
> > found other examples where, just sometimes, large p

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

[Gerd Petermann]

Hi Felix,


reg. the idea of "cutting out overlaps": I guess it would consume quite a lot 
of CPU and it would heavily increase the img size

because we would have to write many more points. Think of a shape for 
"place=village" with hundreds of holes for each building

shape. Up to now we save the shape for the village and the shapes for the 
buildings. With cutting we have to calculate what

remains of the village shape, this would be a very complex shape with many 
holes, so it would have many points.

I don't think that would be a good idea.


reg. sorting by size: I've not noticed any visible change in Basecamp or on my 
Oregon, so I don't think this is a solution.


I looked at maps produced by Garmin and 1st got the impression that they are 
sorted by type, highest types coming first,

but I also found exceptions. Don't know if this means that the order is not 
important or if there is a complex rules behind this.


Gerd


Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Felix 
Hartmann <extremecar...@gmail.com>
Gesendet: Sonntag, 24. Juli 2016 21:40:47
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Option to output polygons in size order

That is not really a good approach. Basecamp orders the polygons opposite to 
most gps devices. So it will still be broken.


There is however a proper way to do - but that would be much much more 
complicated: Create a list of polygons that may not overlap (in the 
style-file). Then if mkgmap finds that 2 of these polygons do overlap - mkgmap 
should cut out the smaller polygon shape from the bigger. Basically the result 
of that approach would mimic how a Mapnik map looks in this case. Still the 
real solution however would be to fix the underlying OSM data. I have no clue 
how code and time intensive the "mimic Mapnik" approach would be, but 
everything else won't really solve much.

On 24 July 2016 at 20:42, Gerd Petermann 
<gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>> wrote:

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-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Ticker Berkin 
<rwb-mkg...@jagit.co.uk<mailto:rwb-mkg...@jagit.co.uk>>
Gesendet: Sonntag, 24. Juli 2016 20:23:41
An: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@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() < 100" 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<tel:05%20-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
>

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

[Gerd Petermann]

I was curious and coded the sort. The result was a bit surprising, because the 
change of the order

has an effect on the shapes. This is of course not wanted, the reason is that 
we set some

flags on point objects which are shared by different shapes, depending on the 
order sometimes

a flag is set by a previously processed shape. I think this is a bug and should 
be corrected first.

I am not yet sure how, I think I tried to solve this problem before without 
success.


For the experts: I am talking about the "preserved" flag which tells the 
Douglas-Peucker filter and

other line simplification filters to keep a point. It is used for special nodes 
on roads and for shapes to

"preserve horizontal and vertical lines" which are on the boundary of the shape.

So, the flag is very important for routing and has an effect on shapes to avoid

holes (e.g. white areas in the sea).


I guess it would be better to use two different flags for the shapes and the 
routing nodes.



Gerd




Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Felix 
Hartmann <extremecar...@gmail.com>
Gesendet: Sonntag, 24. Juli 2016 21:40:47
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Option to output polygons in size order

That is not really a good approach. Basecamp orders the polygons opposite to 
most gps devices. So it will still be broken.


There is however a proper way to do - but that would be much much more 
complicated: Create a list of polygons that may not overlap (in the 
style-file). Then if mkgmap finds that 2 of these polygons do overlap - mkgmap 
should cut out the smaller polygon shape from the bigger. Basically the result 
of that approach would mimic how a Mapnik map looks in this case. Still the 
real solution however would be to fix the underlying OSM data. I have no clue 
how code and time intensive the "mimic Mapnik" approach would be, but 
everything else won't really solve much.

On 24 July 2016 at 20:42, Gerd Petermann 
<gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>> wrote:

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-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Ticker Berkin 
<rwb-mkg...@jagit.co.uk<mailto:rwb-mkg...@jagit.co.uk>>
Gesendet: Sonntag, 24. Juli 2016 20:23:41
An: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@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() < 100" 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<tel:05%20-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 

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

[Felix Hartmann]

That is not really a good approach. Basecamp orders the polygons opposite
to most gps devices. So it will still be broken.


There is however a proper way to do - but that would be much much more
complicated: Create a list of polygons that may not overlap (in the
style-file). Then if mkgmap finds that 2 of these polygons do overlap -
mkgmap should cut out the smaller polygon shape from the bigger. Basically
the result of that approach would mimic how a Mapnik map looks in this
case. Still the real solution however would be to fix the underlying OSM
data. I have no clue how code and time intensive the "mimic Mapnik"
approach would be, but everything else won't really solve much.

On 24 July 2016 at 20:42, Gerd Petermann <gpetermann_muenc...@hotmail.com>
wrote:

> 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-boun...@lists.mkgmap.org.uk> im Auftrag von
> Ticker Berkin <rwb-mkg...@jagit.co.uk>
> *Gesendet:* Sonntag, 24. Juli 2016 20:23:41
> *An:* mkgmap-dev@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() < 100" 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@lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Felix Hartman - Openmtbmap.org & VeloMap.org
Schusterbergweg 32/8
6020 Innsbruck
Austria - Österreich
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Gerd Petermann]

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-boun...@lists.mkgmap.org.uk> im Auftrag von Ticker 
Berkin <rwb-mkg...@jagit.co.uk>
Gesendet: Sonntag, 24. Juli 2016 20:23:41
An: mkgmap-dev@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() < 100" 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@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Ticker Berkin]

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() < 100" 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@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Ticker Berkin]

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 +, 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-boun...@lists.mkgmap.org.uk> on behalf
> of Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Sent: 23 July 2016 19:44
> To: mkgmap-dev@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 +, 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-boun...@lists.mkgmap.org.uk> on behalf
> > of Ticker Berkin <rwb-mkg...@jagit.co.uk>
> > Sent: 23 July 2016 18:42
> > To: mkgmap-dev@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

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

[Gerd Petermann]

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.pdf/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-to-output-polygons-in-size-order-tp5878989p5879011.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Gary Bamford]

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-boun...@lists.mkgmap.org.uk> on behalf of Ticker 
Berkin <rwb-mkg...@jagit.co.uk>
Sent: 23 July 2016 19:44
To: mkgmap-dev@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 +, 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-boun...@lists.mkgmap.org.uk> on behalf
> of Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Sent: 23 July 2016 18:42
> To: mkgmap-dev@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 +, Gary Bamford wrote:
> > Hi Ticker/Gerd
> >
> > 

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

[Ticker Berkin]

Hi Gerd

I'll need to some digging and understanding to get you IDs.
I don't think multi-polygons are the cause of my problems, rather the
standard British Isles map has an polygon place=island that covers the
whole of the mainland. Within it are many other areas, including nested
woods containing lakes, containing islands, containing ...
None of these show because "British Isles" is rendered on top of
everything. For some of the smaller islands around the coast of
Britain, features show correctly.

If I hack the style to suppress island when nam="British Isles" then
things show better.

If I was to have a Typ section with different _drawOrder levels,
imagine something like:
  Sea1
  Island 2
  Woods/Forest...  3
  Lake   4
if the lake contains an Island with woods, they won't show because the
lake has higher level and is drawn on top.

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?

Ticker

On Sat, 2016-07-23 at 20:31 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> okay, can you give an example where areas are causing problems?
> For example the id of a mp-relation?
> I ask because I assume that the problem is in the data.
> 
> Besides that the img format isn't that simple, it has different sub
> areas
> for one resolution, each can contain many polygons which don't have
> to
> fit into the sub area, in fact it is quite likely that a polygon in
> one sub area
> overlaps polygons in other sub areas. I assume that the order in
> which these
> sub areas are rendered depends on the direction you are moving.
> 
> Gerd
> 
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Gesendet: Samstag, 23. Juli 2016 22:00:12
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] Option to output polygons in size order
>  
> Hi Gerd
> 
> I don't understand how multi-polygon processing works, but was
> presuming that, if my idea works, sorting on the size of each
> individual polygon is the correct thing to do.
> 
> Partial overlap of polygons is generally not a problem I'm trying to
> solve here, and it is unlikely that, say, if there is a field next to
> a
> wood with a lake spanning the two, the mapping data would have 2 land
> areas fully abutted with the lake overlapping both; I'd expect there
> to
> be 3 distinct, non-overlapping, areas.
> 
> Ticker
> 
> On Sat, 2016-07-23 at 19:23 +, Gerd Petermann wrote:
> > 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-boun...@lists.mkgmap.org.uk> im Auftrag
> > von Ticker Berkin <rwb-mkg...@jagit.co.uk>
> > Gesendet: Samstag, 23. Juli 2016 20:42:02
> > An: mkgmap-dev@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 

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

[Gerd Petermann]

Hi Ticker,


okay, can you give an example where areas are causing problems?

For example the id of a mp-relation?

I ask because I assume that the problem is in the data.


Besides that the img format isn't that simple, it has different sub areas

for one resolution, each can contain many polygons which don't have to

fit into the sub area, in fact it is quite likely that a polygon in one sub area

overlaps polygons in other sub areas. I assume that the order in which these

sub areas are rendered depends on the direction you are moving.


Gerd



Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Ticker 
Berkin <rwb-mkg...@jagit.co.uk>
Gesendet: Samstag, 23. Juli 2016 22:00:12
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Option to output polygons in size order

Hi Gerd

I don't understand how multi-polygon processing works, but was
presuming that, if my idea works, sorting on the size of each
individual polygon is the correct thing to do.

Partial overlap of polygons is generally not a problem I'm trying to
solve here, and it is unlikely that, say, if there is a field next to a
wood with a lake spanning the two, the mapping data would have 2 land
areas fully abutted with the lake overlapping both; I'd expect there to
be 3 distinct, non-overlapping, areas.

Ticker

On Sat, 2016-07-23 at 19:23 +, Gerd Petermann wrote:
> 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-boun...@lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Gesendet: Samstag, 23. Juli 2016 20:42:02
> An: mkgmap-dev@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 +, 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-boun...@lists.mkgmap.org.uk> on behalf
> > of Gerd Petermann <gpetermann_muenc...@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-boun...@lists.mkgmap.org.uk> im Auftrag
> > von Ticker Berkin <rwb-mkg...@jagit.co.uk>
> > Gesendet: S

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

[Ticker Berkin]

Hi Gerd

I don't understand how multi-polygon processing works, but was
presuming that, if my idea works, sorting on the size of each
individual polygon is the correct thing to do.

Partial overlap of polygons is generally not a problem I'm trying to
solve here, and it is unlikely that, say, if there is a field next to a
wood with a lake spanning the two, the mapping data would have 2 land
areas fully abutted with the lake overlapping both; I'd expect there to
be 3 distinct, non-overlapping, areas.

Ticker

On Sat, 2016-07-23 at 19:23 +, Gerd Petermann wrote:
> 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-boun...@lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Gesendet: Samstag, 23. Juli 2016 20:42:02
> An: mkgmap-dev@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 +, 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-boun...@lists.mkgmap.org.uk> on behalf
> > of Gerd Petermann <gpetermann_muenc...@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-boun...@lists.mkgmap.org.uk> im Auftrag
> > von Ticker Berkin <rwb-mkg...@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 wo

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

[Ticker Berkin]

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 +, 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-boun...@lists.mkgmap.org.uk> on behalf
> of Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Sent: 23 July 2016 18:42
> To: mkgmap-dev@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 +, 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-boun...@lists.mkgmap.org.uk> on behalf
> > of Gerd Petermann <gpetermann_muenc...@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-boun...@lists.mkgmap.org.uk> im Auftrag
> > von Ticker Berkin <rwb-mkg...@jagit.co.uk>
> > Gesendet: Samstag, 23. Juli 2016 18:45:59
> > An: mkgmap development
> > Betreff: [mkgmap-d

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

[Gerd Petermann]

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-boun...@lists.mkgmap.org.uk> im Auftrag von Ticker 
Berkin <rwb-mkg...@jagit.co.uk>
Gesendet: Samstag, 23. Juli 2016 20:42:02
An: mkgmap-dev@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 +, 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-boun...@lists.mkgmap.org.uk> on behalf
> of Gerd Petermann <gpetermann_muenc...@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-boun...@lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkg...@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@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@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Gary Bamford]

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-boun...@lists.mkgmap.org.uk> on behalf of Ticker 
Berkin <rwb-mkg...@jagit.co.uk>
Sent: 23 July 2016 18:42
To: mkgmap-dev@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 +, 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-boun...@lists.mkgmap.org.uk> on behalf
> of Gerd Petermann <gpetermann_muenc...@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-boun...@lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkg...@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
>

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

[Ticker Berkin]

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 +, 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-boun...@lists.mkgmap.org.uk> on behalf
> of Gerd Petermann <gpetermann_muenc...@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-boun...@lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkg...@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@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 mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Gary Bamford]

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-boun...@lists.mkgmap.org.uk> on behalf of Gerd 
Petermann <gpetermann_muenc...@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-boun...@lists.mkgmap.org.uk> im Auftrag von Ticker 
Berkin <rwb-mkg...@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@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 mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Gerd Petermann]

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  im Auftrag von Ticker 
Berkin 
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@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev