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

Wed Jul 27 12:35:05 BST 2016

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 +0000, 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-bounces at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> Gesendet: Mittwoch, 27. Juli 2016 11:57:17
> An: mkgmap-dev at 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 +0000, 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-bounces at lists.mkgmap.org.uk> im Auftrag
> > von Felix Hartmann <extremecarver at 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_muenchen at 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-bounces at lists.mkgmap.org.uk> im
> Auftrag
> > > von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> > > Gesendet: Sonntag, 24. Juli 2016 20:23:41
> > > An: mkgmap-dev at 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() <
> > > 1000000" 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/imgform
> > > at.p
> > > > df/download
> > > > Other sources:
> > > > 
> http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/IMG_File_For
> > > mat
> > > > (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 at lists.mkgmap.org.uk
> > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > > _______________________________________________
> > > mkgmap-dev mailing list
> > > mkgmap-dev at lists.mkgmap.org.uk
> > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > > 
> > > _______________________________________________
> > > mkgmap-dev mailing list
> > > mkgmap-dev at lists.mkgmap.org.uk
> > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > > 
> > 
> > 
> > _______________________________________________
> > mkgmap-dev mailing list
> > mkgmap-dev at lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>  _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev