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

Sun Jul 24 20:40:47 BST 2016

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/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 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
>

-- 
Felix Hartman - Openmtbmap.org & VeloMap.org
Schusterbergweg 32/8
6020 Innsbruck
Austria - Österreich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20160724/37a09f8a/attachment.html>