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

Wed Jul 27 10:57:17 BST 2016

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