[mkgmap-dev] [Patch v1] sorted tags in echotags and log files

Fri Feb 10 10:44:21 GMT 2017

Hi Gerd, you read my mind - I had been intending to look at that, but not
got round to it. Looks good to me. My only question would be whether a
similar thing could be achieved and at the same time possibly improve
performance by storing the tags in sorted order in the first place
(SortedMap?). However, as normally the number of tags is only a handful, I
suspect there would be little or no improvement in performance by storing
the tags sorted.

Cheers,
Mike

From: Gerd Petermann [mailto:GPetermann_muenchen at hotmail.com] 
Sent: 10 February 2017 08:47
To: mkgmap-dev at lists.mkgmap.org.uk
Subject: [mkgmap-dev] [Patch v1] sorted tags in echotags and log files

Hi all,

while comparing results of the patches for the "unpaved problem" I noticed
(again) that the echotags function 
has no specific order, this makes it difficult to compare different outputs
of mkgmap.
Attached is a patch which changes the way how tags are printed in logs or
with the echotags style function.
A binary is here:
http://files.mkgmap.org.uk/download/333/mkgmap.jar

The patch places the tags (key=val) in a SortedSet and uses the toString()
method of that set.
Effect:
- tags are sorted by key
- a blank is added as a separator
Sample:
old:  Way 28312451
[highway=path,bicycle=yes,foot=yes,mkgmap:unpaved=1,mtb:scale=1,sac_scale=mo
untain_hiking,mkgmap:label:1=29,ref=29] 
new:Way 28312451 [bicycle=yes, foot=yes, highway=path, mkgmap:label:1=29,
mkgmap:unpaved=1, mtb:scale=1, ref=29, sac_scale=mountain_hiking] 

If you analyse the logs with scripts, please check if the additional blanks
will cause problems in your tool chain.

The patch is quite large because the change allows to remove a lot of code.
If I hear no complains, I'll commit this patch next Monday.

Gerd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20170210/676a8220/attachment-0001.html>