logo separator

[mkgmap-dev] MultiPolygon code optimisation

From Gerd Petermann gpetermann_muenchen at hotmail.com on Wed Aug 15 14:38:05 BST 2018

Hi Ticker,

last year I've improved the mp code in JOSM, this year I plan to improve the code in mkgmap, see new branch mp-cut.

If you think that you can use the inner/outer roles: forget it. I think they are used for the human user, but an algo should
not depend on them. They are often empty or wrong but the MP is otherwise okay.


Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Mittwoch, 15. August 2018 14:59
An: mkgmap development
Betreff: [mkgmap-dev] MultiPolygon code optimisation

Hi Gerd

A while ago, when I was trying to understand the multi-polygon code,
one of the first things to strike me was that it seems to make things
more complicated that they should be by not keeping the inner and outer
ways parts separate during the initial processing in
MultiPolygonRelation done by getSourceWays() and joinWays().

Instead, could have two instances (inner & outer) of a class that code
like getSourceWays() can add() a way to, after choosing the correct
class based on role/r_e.getKey().

The class holds unclosedWays, closedWays and the add() method will:
1/ test if already closed and add to closedWays & return
2/ test if either end joins to one or two elements in unclosedWays. if
so, join in appropriate direction, remove second unclosedWay if joined
both ends to different unclosedWays. if now closed, remove from
unclosedWays and add to closedWays & return
3/ add to unclosedWays

Another method to call at end to flag error for each unclosedWay

Now the logic can proceed with working out which outers contain inners
and start cutting...

Feel free to ignore all of this.


mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk

More information about the mkgmap-dev mailing list